ブログのネタ出しをAIに任せていると、「そのテーマ、前にも書かなかったっけ？」と引っかかる瞬間はないでしょうか。
その不安が、先日ほんとうに現実になりました。いつものようにChatGPTと次の記事の相談をしていたら、「MoonlightでRTX 4090機をリモート化した話」というテーマが候補として返ってきたのです。一見、悪くない提案です。ただ、その記事はすでに公開済みでした。
この記事は、AIが公開済みの記事をもう一度候補に出してしまった失敗と、それを仕組みで防げるようにするまでの話です。AIと一緒にWordPressブログを運用している人ほど、同じ落とし穴にはまりやすいと思います。
公開済みの記事が、また候補に出てきた
FGLのブログは、ChatGPT、Claude Code、Codexを編集部のように使って運用しています。ネタ出しや記事化の相談はChatGPT、下書き作成やWordPress操作は通常Claude Codeが担当し、使えないときはCodexが同じ作業を代行しています。
その日もChatGPTに次の記事候補を出してもらったところ、返ってきた候補のひとつが、公開したばかりのMoonlight記事とほぼ同じテーマでした。
提案そのものは筋が悪くありません。読者の需要も切り口も妥当でした。妥当だからこそ、過去の私が一度「これは記事にしよう」と判断して、実際に書いて公開していたわけです。
もし気づかずに書き始めていたら、ほとんど同じ内容の記事が2本並ぶところでした。それ以上に、読者に「この人は自分のブログを把握していないのか」と思われる方が痛い。
悪いのはAIではなく、確認できる正本がなかったこと
最初は「AIなんだから、過去の会話くらい覚えていてほしい」と思いました。でも冷静に振り返ると、これはAIの問題ではなく、私の運用設計の問題でした。
当時の運用には、穴が3つありました。
- 公開済み記事の管理を、AIとの会話履歴だけに頼っていた
- 公開済みの記事はいつの間にか14本になっていて、私自身も全件をそらで言えなくなっていた
- 記事企画の前に「ここを確認する」という基準になるファイルがなかった
AIとの会話は、続けているうちに古いやり取りから流れていきます。人間の記憶も、10本を超えたあたりから「どのテーマをどの切り口で書いたか」が曖昧になってきます。つまり、AIも人間も記憶に頼っていて、確認できる「正本」がなかったのです。
ここでいう正本とは、判断の前にAIと人間が確認する基準ファイルのことです。会話の記憶は流れますが、ファイルは何度読んでも同じ内容を返してくれます。
WordPressから公開済み記事の一覧を自動で取り出す
そこでClaude Codeに、WordPressから公開済み記事の一覧を自動で取ってくる小さなスクリプトを作ってもらいました。
使ったのはWordPressのREST APIです。APIというと難しそうに聞こえますが、要するに「WordPressの記事情報を外から取得するための窓口」です。仕組みは単純で、ブログのURLの後ろに /wp-json/wp/v2/posts を付けたアドレスを読みに行くだけ。WordPressブログなら、ブラウザで開くだけでも公開済み記事の情報が返ってくるのを確認できます。公開済みの記事はもともと誰でも読める情報なので、ログイン情報を渡す必要もありません。
このスクリプトは読み取り専用にしました。WordPressへの書き込みは一切せず、記事の更新も削除も公開もできません。取得するだけです。長く使う道具ほど、「壊せない作りにしておく」ことが安心につながります。
取得しているのは、記事ごとの次の情報です。
- 投稿ID
- タイトル
- slug（URLの一部になる英語名）
- 公開日
- URL
- カテゴリー
- タグ
一覧は1つのMarkdownファイル（fgl-published-posts.md）に保存します。実行するたびに公開済みの全記事を取得して、ファイルを丸ごと作り直すだけの単純な仕組みです。細かい工夫としては、投稿IDが重複していないかを検査することと、取得に失敗したときは既存の一覧を壊さずにそのまま終了する作りにしたことくらいです。実装した時点で、公開済みの14本がこの一覧に入りました。
記事企画の前に、必ず一覧を読むルールにした
道具を作っただけでは、また同じ失敗をします。大事なのはここからで、「記事企画の最初に必ずこの一覧を読む」ことを編集部の固定ルールにしました。
新しい記事候補を出すときは、まず一覧を読み、公開済み記事のタイトル・投稿ID・slugと重複していないかを照合します。逆に言えば、一覧を確認していない状態では、新しい記事候補を断定しない。ここまで含めてルールです。
実際、いま読んでいただいているこの記事も、書き始める前に一覧と照合して、公開済みの14本と重複していないことを確認してから企画を通しました。早速ルールが1回働いたことになります。
AIに「過去の記事を全部覚えておいて」と期待するのは、やめました。代わりに、判断のたびに正しい資料を読ませる。覚えさせるより、毎回読ませる。この発想の転換が今回の一番の収穫です。
公開したら一覧も更新する工程を追加した
もうひとつ、放っておくといずれ開く穴があります。一覧の更新忘れです。新しい記事を公開したのに一覧が古いままだと、その記事だけ照合から漏れて、いずれ同じ事故が起きます。
そこで、記事を公開した後の標準フローに「公開済み記事一覧を更新する」という工程を正式に追加しました。公開後の表示チェックが終わったらスクリプトを実行し、一覧が更新されたこと、公開したばかりの記事のIDが一覧に入っていることを確認してから、次の作業（Xでの告知など）へ進みます。
AIの記憶を信じるより、毎回正本を確認させる
今回の自動化で、記事作りが速くなったわけではありません。それでも、作ってよかったと思っています。自動化の価値は作業を速くすることだけではなく、同じ失敗を繰り返さない仕組みを残せることにもあると感じたからです。
もちろん、これで重複の可能性が完全になくなるとは考えていません。切り口が近い記事をどこまで別記事と判断するかは、今も人間の仕事です。ただ、「公開済みのテーマをそのまま候補に出す」という一番わかりやすい事故は、企画前の照合で止められる運用になりました。
AIと長く付き合うほど、AIの記憶に頼る場面を減らして、確認できるファイルを用意する方が安全だと感じています。もしあなたがChatGPTやClaude Codeと一緒にブログを運用しているなら、まず公開済み記事の一覧を1つ作って、企画のたびにAIへ読ませてみてください。AIの提案の質は、AIに渡す資料で変わります。
コメント