はじめに
ブログ記事のテーマを考える作業は、思ったより難しい。
筆者はこのブログ「社内SE3割増し」で、社内SEや情シス担当者向けの記事を書いている。Microsoft 365、Windows、WordPress、セキュリティ、業務効率化など、扱えるテーマは多い。
しかし、扱えるテーマが多いことと、今書くべきテーマが分かることは別である。
AIに次のように聞けば、記事テーマはいくらでも出てくる。
社内SE向けブログの記事テーマを考えて
すると、AIはそれっぽい案を出してくれる。
- Teamsの便利な使い方
- Outlookのトラブル対処
- 情シス担当者の業務効率化
- Microsoft 365の管理ポイント
- セキュリティ教育の進め方
どれも悪くない。
しかし、筆者はこのやり方だけでは弱いと感じた。
理由は単純である。
AIが出したテーマには、実際の検索需要、既存記事との関係、サイト全体の方向性、筆者が本当に書けるかどうかが十分に反映されていないからである。
そこで筆者は、AIにテーマを考えさせるのではなく、Codexを使って「テーマを集める仕組み」そのものを作ることにした。
AIに聞くだけでは「それっぽいテーマ」で止まりやすい
AIにテーマを聞くと、きれいな候補は出る。
たとえば、社内SE向けの記事案として次のようなテーマが出てくる。
社内SEが知っておきたいMicrosoft 365管理の基本
Teamsを業務効率化に活用する方法
Outlookトラブルを解決するチェックリスト
中小企業の情シスがやるべきセキュリティ対策
どれも記事にはできそうである。
しかし、実際に検索している読者は、もっと具体的な悩みを持っている場合が多い。
Teams 添付ファイル 開けない
Outlook 文字化け UTF-8
SharePoint 404 復旧
Windows.old 削除していい
Microsoft Authenticator 強制
前者はテーマとしては整っている。
後者は読者の困りごとに近い。
ブログ記事として検索流入を狙うなら、後者の方が実務記事にしやすい場合がある。
AIに「テーマを考えて」と頼むだけでは、この違いを見落としやすい。
Codexには「テーマを考えて」ではなく「集める処理」を作らせた
そこで筆者は、Codexに対して「記事テーマを考えて」とは依頼しなかった。
代わりに、次のような処理を順番に実装させた。
Search Console APIから検索クエリを取得する
WordPress既存記事を取得する
検索クエリと既存記事を照合する
新規記事・追記・リライト候補に分ける
外部テーマも収集する
ブログとの相性で分類する
人間が承認したテーマだけ記事化する
ここが重要である。
AIにテーマを出させるのではなく、テーマ候補を判断するための材料を集める仕組みにした。
AIの役割を「思いつきの発案者」ではなく、「データを整理する補助者」に寄せたのである。
Search Console API取得をCodexに作らせた
最初に作ったのは、Google Search Console APIから検索クエリを取得する処理である。
Codexには、Search Consoleから次のデータを取得し、CSVに保存するスクリプトを作らせた。
- query
- page
- clicks
- impressions
- ctr
- position
この時点では、AIに記事案を出させていない。
まずは、実際に自分のブログがどの検索語句で表示されているかを取得することを優先した。
Search Consoleには、ブログ運営のヒントがかなり含まれている。
たとえば、次のような検索語句は記事候補になりやすい。
表示回数はある
平均掲載順位が8〜30位くらい
CTRが低い
既存記事で十分に扱えていない
この条件に合うクエリは、記事を追加したり、既存記事をリライトしたりすることで改善できる可能性がある。
AIの思いつきよりも、すでに検索結果に出ているクエリの方が、読者の実需要に近い。
既存記事との照合をCodexに作らせた
Search Consoleのクエリを取得できても、それだけでは不十分である。
なぜなら、そのクエリに対して新規記事を書くべきか、既存記事を直すべきかが分からないからである。
そこで次に、WordPress REST APIから既存記事一覧を取得する処理をCodexに作らせた。
取得したのは、主に次の情報である。
- 記事タイトル
- URL
- 本文の一部
- カテゴリ
- タグ
- 公開日
- 更新日
これにより、Search Consoleの検索語句と既存記事を照合できるようになった。
たとえば、ある検索語句が既存記事と近い場合は、新規記事ではなくリライト候補にする。
既存記事に関連しているが本文で十分に扱っていない場合は、追記候補にする。
既存記事とあまり重ならない場合は、新規記事候補にする。
このように分類することで、テーマ候補が単なる一覧ではなく、次の行動に変わる。
create_new_article
rewrite_existing
add_section_to_existing
ignore_low_priority
これはブログ運営ではかなり大きい。
テーマ案が100個あっても、次に何をすればよいか分からなければ使いにくい。
しかし、「この記事は追記」「これは新規」「これはリライト」と分類されていれば、作業に移しやすい。
外部テーマ収集もCodexに追加させた
Search Consoleは強力だが、弱点もある。
それは、すでに自分のサイトが検索結果に表示されているテーマしか拾いにくいことである。
つまり、まだブログで扱っていない新しい領域は見つかりにくい。
筆者は今後、社内SE系だけでなく、ガジェット、3Dプリンタ、3DCG、Blender、ComfyUI、AI制作、Python自動化なども扱いたいと考えている。
そこで、外部テーマ収集機能もCodexに作らせた。
ただし、外部テーマをそのまま全部記事化するわけではない。
Codexには、テーマを次のように分類する処理を作らせた。
core
社内SE・情シスに直結するテーマ
adjacent
ガジェットや作業環境など、自然に混ぜやすいテーマ
creator_tech
3DCG、3Dプリンタ、AI制作など、筆者の拡張テーマ
separate_site_candidate
今のブログとは分けた方がよさそうなテーマ
この分類を入れた理由は、ブログの軸を守るためである。
AIに自由にテーマを出させると、興味のある話題がどんどん混ざる。
それはそれで楽しいのだが、ブログ全体としては散らかりやすい。
そのため、外部テーマは「今のブログに入れる」「新カテゴリで試す」「別サイト候補にする」と分けるようにした。
承認キューを作り、人間の判断を残した
さらに、Codexには承認キューの仕組みも作らせた。
テーマ候補を自動で集めても、全部を記事化するのは危険である。
そこで、approved_topic.csv を出力し、人間が approved に yes を入れたテーマだけを次工程に進めるようにした。
approved = yes
→ 記事構成案を生成する
approved が空欄
→ 処理しない
この仕組みによって、AIが拾ったテーマをそのまま記事化しないようにした。
これはかなり重要である。
AIは候補を増やすのは得意である。
しかし、今のブログに合うか、読者に役立つかは別問題である。
承認キューは、その判断を人間側に残すための安全弁である。
記事本文ではなく、まず構成案を作らせた
承認されたテーマも、いきなり本文生成には進めなかった。
Codexには、承認済みテーマから記事構成案をMarkdownで生成する処理を作らせた。
構成案には、次のような項目を入れている。
- 想定読者
- 検索意図
- 読者の悩み
- タイトル案
- 見出し構成
- 本文で触れるべきポイント
- 内部リンク候補
- アフィリエイト導線候補
- 公式確認が必要な点
これにより、記事本文を作る前に、記事の設計図を確認できる。
AIで記事を書くときに失敗しやすいのは、いきなり本文を書かせることである。
見た目は文章になっていても、検索意図とずれていたり、実務で使える情報が薄かったりする。
そこで、筆者は本文生成の前に構成案を挟むことにした。
AIにペンを持たせる前に、何を書くかを決めるのである。
AIに任せたのは「発想」ではなく「処理の分解」である
今回のポイントは、AIにブログテーマの発想を丸投げしなかったことである。
筆者がCodexに依頼したのは、主に次のような処理である。
データを取得する
既存記事と照合する
候補を分類する
スコアを付ける
CSVに出力する
承認済みだけ次工程に流す
記事構成案を作る
つまり、AIに任せたのは「何となく良さそうなテーマを考えること」ではない。
テーマ選定に必要な作業を、処理として分解し、再現可能な流れにしたことである。
ここが、単なるAIテーマ出しとの違いである。
AIにテーマを聞くだけなら、その場限りの回答で終わる。
しかし、Codexで仕組みにしておけば、毎週同じ流れでテーマ候補を集められる。
これはブログ運営では大きい。
なぜ「仕組み」にする必要があったのか
ブログ運営で大変なのは、1回テーマを考えることではない。
継続してテーマを見つけ、記事化し、既存記事も育てることである。
そのためには、場当たり的にAIへ相談するだけでは足りない。
毎回次のような流れを回せる方がよい。
Search Consoleを見る
既存記事を見る
外部テーマを見る
候補を分類する
人間が承認する
構成案を作る
本文下書きを作る
品質チェックする
この流れを仕組みにすると、ブログ運営がかなり楽になる。
AIにテーマを聞くだけだと、その場の会話で終わる。
一方、Codexでツール化すれば、CSVやMarkdownとして結果が残る。
後から見返せるし、改善もできる。
つまり、AIの出力を一度きりの回答ではなく、運用フローの部品に変えたのである。
まとめ
AIにブログテーマを考えさせるだけでも、記事案はたくさん出る。
しかし、それだけでは弱い。
理由は、実際の検索需要、既存記事との関係、サイトの方向性、人間の判断が不足しているからである。
筆者はその弱点を補うために、Codexを使ってテーマ収集の仕組みを作った。
具体的には、Search Console API取得、WordPress既存記事取得、検索クエリと既存記事の照合、外部テーマ収集、カテゴリ分類、承認キュー、記事構成案生成という流れである。
AIにテーマを考えさせるのではなく、テーマ選定に必要な情報を集め、分類し、人間が判断できる形にする。
この方が、ブログ運営には向いている。
AIは発想の相手としても便利である。
しかし、継続的なブログ運営では、思いつきよりも仕組みが重要である。
今回の自動化では、AIの力を借りつつも、最終判断は人間に残す形にした。
その方が、記事品質とブログの方向性を守りやすいと考えている。
コメント