はじめに
筆者はこのブログ「社内SE3割増し」で、主に社内SEや情シス担当者向けあるいは興味のある向きに、Microsoft 365、Windows、WordPress、セキュリティ、業務効率化などの記事を書いている。
ブログを書き続けていると、次第に次のような悩みが出てくるものだ。
- 次に何の記事を書くべきか分からない
- Google Search Consoleの検索語句をうまく活用できていない
- 既存記事をリライトすべきか、新規記事を書くべきか判断しにくい
- AIで記事を作れそうだが、そのまま公開するのは不安である
- WordPressへの下書き登録まで自動化したいが、公開事故は避けたい
そこで筆者は、CodexとPythonを使って、ブログ運営を支援する自動化ツールを作ることにした。正確にはchatGPTにやりたいことを伝えてプロンプトを作ってもらい、codexにそれを投げてツールを作った。codex様々である。
今回作成したものは、単純に「AIに記事を書かせるツール」ではない。Search ConsoleやWordPress既存記事の情報を使ってテーマ候補を集め、既存記事と照合し、人間が承認したものだけを記事構成案、本文下書き、品質チェックへ進め、最終的にWordPressへ下書き登録する仕組みである。
本記事では、まずその全体像を紹介する。
作った仕組みの全体像
今回作った仕組みは、大きく分けると以下の流れである。
テーマ収集
↓
既存記事との照合
↓
記事候補の分類
↓
人間による承認
↓
記事構成案の生成
↓
本文下書きの生成
↓
品質チェック
↓
WordPressへ下書き登録
重要なのは、最後まで自動公開しないことである。
WordPressへ登録する場合も、投稿ステータスは必ず draft とする。公開はWordPress管理画面で人間が最終確認したうえで行う。
AIを使えば記事作成の速度は上がる。しかし、技術記事では誤情報や古い情報が混ざる可能性がある。特に社内SE向けの記事は、読者が実際の業務で参考にする可能性がある。誤った手順や不正確な仕様をそのまま公開するわけにはいかない。
そのため、今回の自動化では「AIに任せる部分」と「人間が確認する部分」を明確に分けることを重視した。
Search Consoleから記事テーマ候補を集める
最初に作ったのは、Google Search Console APIから検索パフォーマンスデータを取得する機能である。
取得する主な項目は以下である。
- 検索クエリ
- 表示されたページ
- クリック数
- 表示回数
- CTR
- 平均掲載順位
Search Consoleを見れば、どの検索語句で自分のサイトが表示されているか分かる。しかし、画面で眺めるだけでは次の行動に落とし込みにくい。
そこで、次のような条件を満たす検索語句を記事候補として拾うようにした。
表示回数はある
順位はそこそこ
クリック率が低い
既存記事で十分に扱えていない
たとえば、社内SEブログであれば以下のような検索語句が候補になり得る。
Teams 添付ファイル 開けない
Outlook 文字化け UTF-8
SharePoint 404 復旧
Windows.old 削除していい
Microsoft Authenticator 強制
これらはAIの思いつきではなく、実際に検索結果に表示されているデータを元にした候補である。ここが重要である。
AIに「ブログテーマを考えて」と依頼するだけでも候補は出る。しかし、それだけでは読者の実需要とつながっているか分からない。Search Consoleのデータを使うことで、実際の検索行動に近いテーマ候補を集められる。
WordPress既存記事と照合する
次に、WordPress REST APIを使って既存記事の一覧を取得する機能を作った。
取得対象は、記事タイトル、URL、本文の一部、カテゴリ、タグなどである。これをSearch Consoleの検索クエリと照合することで、各キーワードに対して次のような判定ができる。
既存記事をリライトする
既存記事に追記する
新規記事として作成する
優先度が低いので保留する
たとえば、すでにTeamsの添付ファイルに関する記事があるなら、新規記事を作るよりも既存記事に追記した方がよい場合がある。逆に、似た記事がまったくない場合は、新規記事候補になる。
この段階で重要なのは、AIにいきなり本文を書かせないことである。まずは「この記事は新しく作るべきか」「既存記事を直すべきか」「追記で足りるのか」を整理する必要がある。
ブログ運営では、記事数を増やすことだけが正解ではない。既存記事を育てた方がよい場面もある。今回の仕組みでは、その判断を支援することを重視した。
外部テーマも収集できるようにした
Search Consoleだけを見ていると、当然ながら既存記事や既存流入に近いテーマしか見つかりにくい。
そこで、外部テーマ収集機能も追加した。
筆者が今後扱いたいテーマとして、以下のようなものも候補に含めている。まあ個人的な興味ということだ。
- ガジェット
- PC周辺機器
- 3Dプリンタ
- 3DCG
- Blender
- 3ds Max
- ComfyUI
- AI画像生成
- AI動画生成
- Python自動化
ただし、何でも同じブログに入れると、サイトの軸が散らかる。
そこで、テーマを以下のように分類するようにした。
core
社内SE・情シスに直結するテーマ
adjacent
ガジェットや作業環境など、社内SEブログに自然に混ぜやすいテーマ
creator_tech
3DCG、3Dプリンタ、AI制作など、筆者の個人スキルや制作活動に近いテーマ
separate_site_candidate
今のブログとは読者層が異なり、別サイト化も検討すべきテーマ
たとえば、モニターやドッキングステーションの記事は「社内SEの作業環境改善」として扱いやすい。一方で、Blenderや3Dプリンタの記事は、社内SEブログに入れるとしてもカテゴリを分けた方がよい。
このように、AIでテーマを広げつつも、ブログの方向性がぼやけないようにした。
承認キューを作り、人間の判断を残す
さて、テーマ候補が増えるのはいいが、すべてを記事化するわけにはいかない。
そこで、承認キューを作った。具体的には、approved_topic.csv みたいなCSVを生成し、人間が approved 列に yes を入れたテーマだけを次の工程へ進めるようにする。
approved = yes
↓
記事構成案生成へ進む
approved が空欄または no
↓
処理しない
この仕組みにより、AIが拾ってきたテーマをそのまま記事化しないようにした。
ブログ運営では、検索需要だけでなく、以下のような判断も必要である。
- 筆者が書けるテーマか
- サイトの方向性に合っているか
- 読者に役立つか
- 今すぐ書くべきか
- 別カテゴリや別サイトに分けるべきか
こうした判断は、現時点では人間が行った方が安全である。AIは候補を広げるのは得意だが、ブログ全体の方針や読者との距離感までは完全には判断できないのだ。
記事本文の前に構成案を作る
承認されたテーマは、いきなり本文にせず、まず記事構成案をMarkdownで生成する。
構成案には、以下の情報を含めるようにした。
- 想定読者
- 検索意図
- 読者の悩み
- タイトル案
- 見出し構成
- 本文で触れるべきポイント
- 内部リンク候補
- 公式確認が必要な点
AIで記事本文を作ると、見た目は整っていても、検索意図からずれていたり、実務で使える情報が薄かったりすることがある。
そのため、本文生成の前に、まず「何を書くべきか」を構成案として整理することにした。
これは、AIにいきなり筆を持たせるのではなく、先に設計図を渡すようなものである。
OpenAI APIで本文下書きを生成する
記事構成案ができたら、OpenAI APIを使って本文下書きを生成する。
ここでも、生成された文章を完成記事としては扱わない。あくまでレビュー前の下書きである。
本文生成時には、大体以下のような方針を入れる。
社内SE・情シス担当者向けに書く
最初に結論を書く
確認手順を具体的にする
不確かな仕様は断定しない
公式確認が必要な箇所は要確認として残す
架空のURLを作らない
特に重要なのは、AIに「分からないことを分かったように書かせない」ことである。
技術記事では、少しの断定ミスが読者の作業ミスにつながることがある。したがって、確実ではない部分は「要確認」として残す設計にした。
下書きの品質チェックを行う
本文下書きを作った後は、品質チェックを行う。
チェック項目は以下である。
- 検索意図に合っているか
- 社内SE向けの記事になっているか
- 見出し構成が自然か
- 実務で使える確認手順があるか
- 断定しすぎていないか
- 要公式確認の箇所が残っているか
- 内部リンク候補があるか
レビュー結果は、pass、needs_revision、fail のように判定する。
また、WordPress下書き登録へ進めるかどうかを wordpress_ready として出力するようにした。
wordpress_ready = yes
↓
WordPress下書き登録候補
wordpress_ready = after_revision
↓
修正後に登録候補
wordpress_ready = no
↓
登録しない
この品質チェックを入れることで、AIが生成した記事をそのままWordPressへ流し込まないようにしている。
AIを使うほど、最後の検品は重要になる。自動化されたベルトコンベアの先に、必ず検品台を置くイメージである。
WordPressには必ず下書きとして登録する
品質チェックを通った記事は、WordPress REST APIを使って下書き登録する。
ここでも、自動公開はしない。投稿ステータスは必ず draft とする。
status = draft
WordPress管理画面で最終確認し、タイトル、本文、内部リンク、アイキャッチ、カテゴリ、タグ、広告表記などを確認してから公開する。
今回、WordPress REST API連携ではいくつか詰まった。
- Application Password認証で401になる
/wp-json/形式で404になる- 実記事の本文だけ403になる
- WAFに本文がブロックされる
最終的には、?rest_route= 形式、フォーム送信、WAF対策モードなどを使うことで、下書き投稿できるようになった。
このあたりは、別記事で詳しく書く予定である。WordPress REST APIのエラー対応でやたらと引っ掛かったので。
GitHubで管理するようにした
codexで色々と作っていくと次第に自動化ツールが大きくなってきたため、GitHubで管理することにした。
ただし、以下のような秘密情報や生成物はGitHubに上げない方針である。
.env- OpenAI APIキー
- WordPress Application Password
- Google OAuthの認証情報
- Search Consoleの取得データ
- 未公開の記事下書き
- ログファイル
- 仮想環境
.venv
代わりに、.env.example にはダミー値を書き、必要な設定項目だけ分かるようにした。
APIキーを扱うPythonツールでは、GitHubに何を上げてよいか、何を上げてはいけないかを最初に整理しておく必要がある。
これはブログ自動化に限らず、社内ツールや個人用Pythonツールでも同じである。
今回作って感じたこと
今回の自動化で感じたのは、AIブログ自動化は「全部自動で記事を公開する仕組み」にしない方がよいということである。
むしろ、以下のように分けた方が現実的である。
AIに任せること
- テーマ候補の整理
- 構成案作成
- 本文下書き生成
- 品質チェックの補助
人間が見ること
- テーマを採用するか
- 内容が正しいか
- サイト方針に合っているか
- 公開してよいか
AIはかなり便利である。しかし、ブログの方向性や読者への責任まで丸投げするのは危険である。
特に社内SE向けの記事では、読者が実際の業務で手順を試す可能性がある。だからこそ、自動化しつつも、人間の確認ポイントを残す設計にした。
今後やりたいこと
現時点では、テーマ収集からWordPress下書き登録までは一通り動くようになった。
今後は、以下を改善していきたい。
- フォルダ構成の整理
- 実行コマンドの統一
- READMEと運用手順の整備
- アイキャッチ画像や記事内画像の扱い
- 複数記事の一括生成
- カテゴリ戦略の改善
- 既存記事リライトの自動支援
特に、機能を追加し続けると、スクリプトや出力ファイルが増えて分かりにくくなる。今後は、実行入口を整理し、運用しやすい形にしていく必要がある。
まとめ
筆者はCodexとPythonを使って、ブログ運営を支援する自動化ツールを作成した。
今回の仕組みでは、Search ConsoleやWordPress既存記事を使ってテーマ候補を集め、承認済みテーマだけを記事構成案、本文下書き、品質チェックへ進め、最終的にWordPressへ下書き登録する。
ポイントは、AIにすべてを任せないことである。
自動化する部分と、人間が確認する部分を分けることで、作業効率を上げつつ、記事品質や安全性も守りやすくなる。
次回以降は、Search Console API連携、WordPress REST API投稿、AI記事品質チェック、GitHub管理などを個別に紹介していく予定である。
コメント