AIにSEOを任せる前に渡す4つの前提｜細かいプロンプトより先に用意するもの

AIにサイトの修正を任せて、思ったように動かないとき、多くの人はプロンプトを細かくします。私も最初はそうしていました。

結論から書きます。AIが正しく動くかどうかは、プロンプトの細かさではなく、AIに渡している「前提」で決まります。渡すのは次の4つです。

戦略1枚：このサイトは誰のために、何をするためにあるか
今のデータ：検索の実績と、サイトの今の状態（記憶やスナップショットではなくライブのもの）
判断の基準：どの記事から直すか、何点なら合格かを、数値やルールで書いたもの
禁止事項：AIが絶対にやってはいけないこと（赤線）

この4つがファイルとして置いてあれば、指示は「SEOを回して」程度で足ります。逆に、これが無いまま指示を細かくしても、AIは毎回違う判断をします。

この記事は、散らかったサイトをAIで作り変えるマニュアルの最初の作業です。ここを飛ばすと、以降の診断や修正の作業がすべて不安定になります。

この作業で決まること

この作業が終わると、AIに何を任せて、何を人が決めるかが決まります。

人に残るのは次の3つだけで、それ以外の作業はAIに任せます。

燃料：自分の一次体験（AIには作れない）
赤線：お金・リスク・ブランドに関わる判断
舵：どのゴールを目指すか

私はこの役割分担を、自分のサイト運用の立ち上げ時に決めました。AIが人に質問してよいのはこの3つだけで、AIが自分で決めるべきことを人に聞くと、人のほうがボトルネックになります。

よくある失敗：「AIが全部やる」と考えると、AIは間違った方向に効率よく最適化します。舵と燃料は人に残してください。

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

Claude Code などの、ファイルを読んで作業できるAI
自分のサイトの管理者権限（WordPress なら REST API が使える状態）
Google Search Console のデータ

AIにサイトを直接操作させる準備は別の記事で扱います。この記事では、AIに読ませるファイルを用意するところまでをやります。

AIに渡すもの①：戦略1枚

最初に、サイトの戦略を1枚のファイルに書きます。中身は次の3点で足ります。

このサイトは誰のためのものか（読者を1種類に絞る）
読者のどんな悩みを解決するか
やらないこと

ここで大事なのは、本人の強みや一次体験を最初にAIに渡すことです。需要（検索数）だけを渡すと、AIはどこにでもある記事を設計します。私がサイト戦略を作ったときは、まずAIに自分の強みと体験をヒアリングさせ、そのあとでキーワードAPIの需要データを渡しました。強みと需要が重なるところだけを作る対象にすると、他のサイトとの違いが出ます。

よくある失敗：戦略を会話の中だけで伝えること。会話はセッションが終わると消えます。必ずファイルに書いてください。

AIに渡すもの②：今のデータ

次に、AIがサイトの「今」を見られるようにします。

Search Console の検索実績（クエリ・表示回数・クリック・順位）
サイトの全記事の一覧（URL・タイトル・カテゴリ・公開日）

ポイントは、計画書やスナップショットではなく、ライブのデータを読ませることです。自動化を回していると、サイトの中身は裏で変わり続けます。古い一覧で判断すると、もう存在しない記事を直そうとしたり、すでに直した記事をまた直したりします。

また、キーワードツールの需要と Search Console の実績は一致しません。まだ取れていない領域を探すにはキーワードツール、すでにある実力を見るには Search Console、と両方を渡してください。

よくある失敗：カニバリ（同じクエリで自分の記事同士が競合すること）を推測で判断すること。Search Console で同じクエリに自分の URL が複数出ているかを実際に確かめてから対応します。

AIに渡すもの③：判断の基準

3つ目は、AIが迷ったときに使う基準です。これが一番効きます。

私が自分のサイトのリライト用に書いたルールファイルには、たとえば次のような基準があります。

順位やCTRでリライト対象を選ばない。選ぶ軸は「サイトの復活に必要な要素がその記事にどれだけ欠けているか」で、7つの項目の減点で採点する
公開を先にして、インデックスされてから磨く。下書きで止めると数が増えない
毎日の自動処理は、メタ・alt・内部リンク・FAQ など壊れにくい改善だけにする。本文や構造に踏み込む深いリライトは週1回にする

このように、「何を優先するか」「どこまでならAIが自分で進めてよいか」を数値やルールで書くと、AIは毎回同じ判断をします。

人が毎回「これで合ってる？公開していい？」と判断する設計にすると、作業はそこで止まります。私自身、確認の関門を挟むほど、完璧主義と心配が出て着手できなくなる経験をしました。安全は都度の承認ではなく、事前に決めた数値ルールと、少数の赤線で担保します。

AIに渡すもの④：禁止事項

最後に、AIが絶対にやってはいけないことを書きます。数は少なく、はっきり書きます。

お金がかかる操作を勝手にしない
複数のサイトや、仕事と個人の情報を混ぜない
一次記録にない体験や数字を書かない

禁止事項は、ルールとして文章に書くだけでは守られないことがあります。守られなかったときに機械で止める仕組みは、品質管理の記事で扱います。

手順

戦略1枚を書く（誰のため・何を解決するか・やらないこと）
Search Console とサイトの記事一覧を、AIが毎回ライブで取れるようにする
判断の基準をルールファイルに書く（優先順位・合格点・AIが自分で進めてよい範囲）
禁止事項を短く書く
AIが毎回最初に読む場所（Claude Code なら CLAUDE.md）から、この4つのファイルを参照させる
決めたことが増えたら、その日のうちに決定の台帳に1行書く

6番目が見落とされやすい手順です。次の「失敗」で理由を書きます。

完了条件

☐ 戦略・データ・判断基準・禁止事項の4つが、ファイルとして存在する
☐ AIが毎回最初に読むファイルから、4つが参照されている
☐ 「SEOを回して」程度の短い指示で、AIが何から手をつけるかを自分で説明できる
☐ 決定を書く台帳が1枚あり、AIの自動処理がそれを読む

実際に起きた失敗

ツールを配っても、前提は配られない

勤務先で、上司から「チーム全員がデータにアクセスできるようにしたい」という要望が出ました。同時に「私がやっている、AIで業務を最適化するやり方を、全員ができるようにならないか」という話も出ました。

考えてみると、生産性を作っていたのはAIのツールそのものではありませんでした。5か月かけて積み上げた、ルールファイル・プロファイル・一次情報・制作ガイド・メモリといった前提の束でした。同じツールを渡しただけの人には、これがありません。同じ指示を出しても、同じ答えは返りません。

決定がAIの記憶にだけ残り、議題が3か月前のままになった

私は週1回、AIに全プロジェクトの振り返りを自動で書かせています。この自動レビューは、1回も欠かさず12回正常に終わっていました。ところが、レビューが最優先の議題として出していたのは、すでに停止を決めた施策や、すでに出版を終えた本の話でした。

原因は、決めたことがそのセッションのAIの記憶にだけ残り、自動レビューが読むファイルには一度も書かれていなかったことです。AIの記憶はセッション単位で閉じます。

決定の台帳を1枚作り、「有効な決定」「失効した決定」「検討中」に分けてレビューの最初に読ませると、翌週の議題は現在の方針に切り替わりました。問題はAIの能力ではなく、決定の置き場所でした。

よくある質問

Q. プロンプトの書き方は覚えなくていいのですか？
A. 覚えて損はありませんが、優先順位は低いです。前提がファイルにあれば、指示は短くて済みます。前提が無いまま指示を細かくしても、セッションが変わるたびに判断がぶれます。

Q. 戦略1枚は、どのくらい書けばいいですか？
A. 誰のため・何を解決するか・やらないこと、の3点が書けていれば始められます。最初から完成させる必要はありません。決定が増えたら台帳に足していきます。

Q. 人が判断しなくて、事故は起きませんか？
A. 起きないように、赤線（お金・リスク・ブランド）と数値の基準を先に決めます。都度の承認を挟むより、事前の基準と機械のチェックで止めるほうが、止まるべきところで確実に止まります。