上司から「このサイトを上から順にやっていって」とサイトを渡された初日に、どこから手をつけるかを書きます。
結論から書きます。最初の1週間は、記事を直すのではなく、AIに任せる前の「前提」を9本分そろえます。前提がファイルとして置いてあれば、以降の診断・修正・公開の作業は、短い指示でAIが同じ判断をします。前提が無いまま指示を細かくしても、セッションが変わるたびに判断がぶれます。
この記事は、散らかったサイトをAIで作り変えるマニュアルのPart 0（AIに渡す前提）のまとめです。9本の作業を、どの悩みのときにどの記事を読めばよいかの地図として並べます。全部を1日で終わらせる必要はありません。上から順に読み、該当する作業から着手します。
目次
この1週間で決まること
9本を終えると、次の状態になります。
- サイトを支えている作業の全数と、止まっても気づかない自動処理が1枚の表になっている
- 仕事と個人、サイトごとに、AIが読んでよいフォルダと読んではいけないフォルダがパスで決まっている
- AIが毎回ライブで、本番のサイトと検索の実績を読み書きできる
- AIが迷ったときに参照する判断の基準（戦略・ルール・禁止事項）がファイルで置かれている
- 作業の失敗がログとして自動で積み上がり、書く役と検査する役が分かれ、モデルの使い分けが1行で切り替わる
以降のPart 1（診断）以降は、ここでそろえた前提の上に乗ります。
9本の作業の地図
9本は、取りかかる順に並んでいます。最初の3本は「スコープを決める」、次の2本は「AIの手を本番につなぐ」、残りの4本は「AIが迷わないための基準」です。
1. 動いているものを数える
引き継ぎ初日にやる棚卸し｜記憶でなく動いているスクリプトから作業を取り出す
前任者の記憶や画面の見た目ではなく、サーバーで動いているスクリプトと定期ジョブを機械で一覧にします。目的は、止まっても画面に出ない自動処理を先に特定することです。自分のサイトでスクリプト約290本・定期ジョブ約40本・失敗の記録134件・過去のメモ約120件を機械で一覧にしたら594件になり、頭で組んだ目次に無かった「毎週動いているのに失敗していないので記録に残らない作業」が、スクリプトと定期ジョブからだけ出てきました。
2. 仕事と個人を物理的に分ける
仕事用と個人用でAIのアカウントと情報を分ける｜混ざらない作業環境
AIから見ると、同じディスクに置かれたファイルの名前からは「仕事」か「個人」かを判別できません。言葉で分ける方針では守られないので、アカウント・設定ディレクトリ・参照できるフォルダのパス、の3つを分けます。禁止事項は抽象的な言葉でなく、具体的なパスで書きます。
3. サイトごとに分ける
AIに複数サイトの情報を混ぜない｜アカウントとフォルダで分ける手順
仕事と個人を分けたあと、同じ立場の中でサイトが複数ある場合は、サイトごとにさらに分けます。AIが毎回最初に読むファイルの冒頭に、「このプロジェクトの作業範囲は〈このフォルダ〉のみ」「他のフォルダは絶対に参照しない」「不明な点があればフォルダを勝手に横断せず、人に確認する」の3点を書きます。作業フォルダに版違いのバックアップを量産しないことも、ここで決めます。
4. 4つの前提をファイルにする
AIにSEOを任せる前に渡す4つの前提｜細かいプロンプトより先に用意するもの
AIに渡すのは、戦略1枚・今のデータ・判断の基準・禁止事項、の4つです。この4つがファイルとして置いてあれば、指示は「SEOを回して」程度で足ります。会話の中だけで伝えると、セッションが終わると消えます。決まった内容は、その日のうちに決定の台帳に1行書きます。
5. AIの手をWordPressにつなぐ
AIにWordPressを操作させる準備｜REST APIの最小構成と事故を防ぐ3つの型
REST APIで接続し、関数モジュールを1枚作ります。事故を防ぐ3つの型は、「書いて読み返して確かめる」「副作用の前に状態を書く」「下書きの関数と公開の関数を別名で分ける」です。このサイトの最初の公開で、本文は通ったのにテーマのSEOタイトルとメタディスクリプションだけ書けなかったとき、関数の中の読み返し検証がその場で気づかせてくれました。公開は止めず、WordPress標準の抜粋欄に説明文を入れて代替し、未設定であることだけを台帳に記録しました。
6. 本番の「今」を正にする
計画書やキーワード一覧の「下書き済み」「既存」といった列は信用しません。本番のサイトから毎回ライブで全記事を引き直し、1枚のCSV（またはJSON）にまとめます。勤務先のサイトでは、計画CSVが「下書き済み・既存」と書いていた記事のうち、30件分のURLが本番に存在しませんでした。「存在しない記事を直そうとする」事故は、AIの注意力ではなく、取得の自動化で止めます。
7. 作業ログを続ける仕組みにする
AI作業の失敗ログを残す仕組み｜設計だけでは続かない記録のつくり方
ログを人が書く運用は、忙しい週にゼロになります。目的を1行で決め（例：本やコンテンツの素材として残す）、書く軸を4つ（失敗・有効・原則・対象読者）にそろえ、書くのはAIにします。自分のログは、設計があったのに2週間以上ゼロ本だった時期があり、同じ裏で別の自動処理が11日間落ち続けていました。横断的に見える仕組みが無いと、気づけません。
8. 書く役と検査する役を分ける
AIで書く役と検査する役を分ける｜同じAIが書いて検査すると見逃す
同じAIに「書いたものに問題がないか確認して」と頼むと、自分の前提をそのまま正しいとみなします。別のセッション（できれば別の種類のAI）に、原稿と根拠ファイルだけを渡すと、この引き継ぎが切れます。検査役の指摘は候補であって事実ではないので、重大なものほど親の役が一次記録を自分で開いて確かめます。勤務先のリポジトリ監査で「認証情報が漏れている。最重大」と報告されたとき、30秒の一次検証で誤報だと分かったことがありました。
9. モデルを合格点で選ぶ
AIのコストを抑えるモデルの使い分け｜最新・最高級に寄せない判断の基準
最新版・上位版は昇格の理由になりません。作業ごとの合格点を満たす範囲で、一番安くて速いものを使います。モデル名を1か所にまとめて書き、昇格はそのファイルの1行書き換え、ロールバックは環境変数1つで戻せるようにします。自分のサイトで新しい版のローカルモデルを試したときは、採点が0点に見えたのが「悪い」ではなく「判定者のJSONパース失敗」で、実際には現行と実質同等、ただし2.4倍遅いという結果でした。
読む順番の目安
- まだ何も触っていないなら、1 → 2 → 3 の順でスコープを決めます
- 画面の中身を直したくなっていても、まず4で戦略・ルール・禁止事項をファイルにします
- 本番を書き換える前に、5と6で「AIの手」と「今の正」を用意します
- ここまでで、以降の作業の土台ができます。7・8・9は、作業を続ける中で止まらないための仕組みです
全部を1週間で終わらせる必要はありません。4までを初週、5〜6を翌週、7〜9を運用に乗せながら、という進め方で足ります。
よくある質問
Q. 9本のうち、1本だけ先に読むとしたらどれですか？
A. 「引き継ぎ初日にやる棚卸し」です。前任者が在席している間しかできない作業（アカウントの移管、スクリプトと定期ジョブの置き場所の確認）が入っています。他は後からでも進められます。
Q. まだAIを触っていなくても、この9本は要りますか？
A. 要ります。4の「4つの前提」と6の「本番の台帳」は、AIを使わなくても、担当者が1人で判断する足場として役に立ちます。AIを入れるときに、同じファイルをそのまま渡せます。
Q. 使っているCMSがWordPressではありません。この順番で進められますか？
A. 5番だけはWordPress前提です。それ以外は、どのCMSでも同じ順番で進められます。5番は、使っているCMSの管理APIに置き換えて読みます。
関連記事
- サイトに必要なのは大規模・中規模・小規模どの修正か｜AIで診断して順番を決める手順
- AIに既存記事をリライトさせると劣化する理由と、外科手術に分解する手順
- 順位に依存しないサイト復活オーディット
- AIに任せる範囲・人が決める範囲
次の作業
- 診断：サイトに必要な修正が大規模・中規模・小規模のどれかを判定する
- 止まっても気づかない自動処理に死活監視を足す
- 公開前に通す接地監査（根拠のない主張を1件も通さない仕組み）を作る
