AIデジマ研究所

全記事の台帳を作り「今のサイト」をAIの判断の正にする手順

2026-10-02 ・ AIに渡す前提

AIにサイトの修正を任せていると、「この記事、もう公開されてませんでしたっけ？」とこちらが毎回訂正する状況が起きます。原因はAIの注意力ではなく、AIが見ている台帳が古いことです。

結論から書きます。全記事の台帳を1枚作り、それを本番のサイトから毎回ライブで引き直します。AIには「計画書に書いてある状態」ではなく、「今、本番にある状態」を正として渡します。計画書やキーワード一覧の「下書き済み」「既存」といったステータス列は信用しない、と明記します。

この記事は、散らかったサイトをAIで作り変えるマニュアルの、AIに渡す4つの前提のうち「今のデータ」をファイルとして用意する作業です。ここを飛ばすと、以降の診断・リライトの作業は、存在しない記事に手を入れたり、すでに直した記事をまた直したりします。

この作業で決まること

この作業が終わると、AIが「サイトに今どんな記事があるか」を毎回同じ方法でつかめるようになります。

よくある失敗：AIに「現状を把握してね」と言葉で伝えること。AIは言われたとおり把握しようとしますが、根拠にする情報源が複数あると、計画書・古いクロール結果・セッションのメモの3つの間で揺れます。把握は注意力ではなく、取得の自動化で担保します。

前提：この記事の前に必要なもの

AIに渡すもの

AIに渡すのは次の2つのファイルです。

  1. 全記事の台帳（ライブ）：本番のサイトから引いた、公開中・非公開・下書きを含む全記事の一覧
  2. 台帳の読み方のルール：どのファイルが「正」で、どのファイルは「願望」として扱うか

2つ目は忘れられがちです。サイト運用を続けていると、計画書・キーワード一覧・AIが作った中間ファイルなど、記事の状態を書いた表が複数できます。どれを信じるかをファイルに書いておかないと、AIは一番最初に見つけたものを信じます。

手順

  1. 本番から全記事を引くスクリプトを1つ作る

WordPress なら REST API の /wp/v2/posts と /wp/v2/pages を叩き、公開・非公開・下書きを含めて全件取得します。1記事につき最低限、ID・URL・タイトル・カテゴリ・公開日・公開状態の6項目を出します。

  1. 出力は1枚のCSV（またはJSON）に揃える

チャネルごと・ピラーごとに別ファイルにしない。別ファイルにすると、どれが最新かを人間が覚える仕事が発生します。

  1. AIがセッション開始時に必ず読む場所から、この台帳を参照させる

Claude Code なら CLAUDE.md に「作業開始時にこのスクリプトを走らせ、台帳を読み直す」と明記します。

  1. 計画書・キーワード一覧の「ステータス列」を信用しないと明記する

「下書き済み」「既存」と書かれていても、本番に無ければ無いものとして扱う、と1行書きます。

  1. 台帳と計画書の差を自動で炙り出す

「計画にあるが本番に実在しない」「本番に実在するが計画に無い」の2つのリストを、台帳の生成と同じスクリプトで出します。

  1. 破壊防止の注記を1行入れる

公開中の記事を、台帳側のステータスで上書きしてしまうと公開が落ちる、といった事故が起きうる操作を、スクリプトのコメントかREADMEに警告として残します。

台帳に入れる項目

最低限、次の項目があれば以降の作業が回ります。

最後の1項目は、同じ記事を短い間に何度も直すのを防ぐために入れます。自分のサイトの保守の仕組みでは、最後に触ってから28日未満の記事には何があっても触らない、という安全床を置いています。

完了条件

実際に起きた失敗

計画書を正と思い込み、存在しない記事を直そうとしていた

勤務先のサイトで、AIに記事制作と修正を任せていたときのことです。「この記事、もう存在しないのでは」とこちらが毎回指摘して訂正する状況が続きました。

原因を掘ると、AIは3つの食い違う情報源から現在地を推測していました。キーワード計画のCSV（「下書き済み」「既存」と書いてある）、2か月前のサイトクロールの結果、そして現在のセッションのうろ覚えのメモです。

実際に本番のサイトを取得して確認したところ、計画CSVが「下書き済み・既存」と書いていた記事のうち、30件分のURLが本番に存在しませんでした。逆に、実際に検索流入を担っている公開中の記事が計画CSVには登録されていませんでした。さらに、旧バージョンの重複記事（URLの末尾に「222」が付いたもの）が放置されていました。

計画書は、書いた瞬間から現実とズレ始めます。人は更新を忘れますが、AIは書かれていることを疑わずに正として使います。だから毎回同じズレで人間が訂正コストを払うことになります。

解決は、AIにもっと注意させることではなく、仕組みを変えることでした。本番から現状を毎回その場で取得し、それを唯一の正とする台帳を自動生成し、計画CSVとの差を自動で炙り出す。そして起動時に読むファイルに「計画CSVのステータス列は信用しない」と明記する。この4つで、「存在しない記事を直そうとする」事故は止まりました。

台帳が複数あって、どれが最新かを人間が覚えていた

もう1つ、台帳そのものが複数できていた失敗があります。チャネルごとに別の管理ファイルがあり、それぞれ独立に更新されていました。どれを見れば今の全体像がわかるかを、人間が記憶で判断していました。

これを、全チャネルを1枚に集約した一元台帳に作り直し、個別の管理ファイルはあくまでソース、1枚の台帳をマスターと決めました。AIが読むのはマスターだけ、個別ファイルの状態はマスター生成のときに自動で取り込む、という形にすると、「どれが最新か」を人間が覚える仕事がなくなりました。

よくある質問

Q. 記事数が少ないうちは、手で一覧を作ってもいいですか？
A. 手で作れますが、おすすめしません。更新を忘れるのが人間だからです。本番から引くスクリプトは、記事が10本でも1,000本でも作業量は変わりません。最初に1回作ってしまうほうが、長期的にはずっと楽です。

Q. 計画書を捨てていいのですか？
A. 捨てなくて大丈夫です。計画書は「これから何を作るか」のためのもので、「今サイトに何があるか」のためのものではありません。役割を分けて、AIに「ステータス列は本番側のものだけを信用する」と明記すれば両方残せます。

Q. 台帳は毎日作り直すべきですか？
A. セッション開始時と、サイトを更新したあとに作り直せば十分です。AIに作業を頼むたびに最新を取るのが基本で、固定の間隔で動かすというより、作業の起点で動かすものです。

関連記事

次の作業