AIに毎朝アクセス解析をさせたら、初回に事実を誤って報告した｜手順書の先頭に工程0を足した

🧭 この記事の前提 個人サイトのアクセス解析を、AIエージェント（Claude Code）に毎朝8時の定時実行で任せています。数字を取り、変化を書き、翌日の打ち手を3つまで出す、という役です。
困ったのは、初回の実行で事実を誤って報告したこと。しかも間違えたのは計算ではなく、前提の把握でした。
持ち帰れるもの：AIに定型の分析作業を任せている人向けに、手順書の先頭に置くべき工程と、それを増やしていく運用を出します。手で数字を見ている人には不要です。

結論：AIが最初に読むファイルは、たいてい古い

📌 先に結論 ① 初回の誤報告は計算ミスではなく前提の取り違え ② 原因は、AIが読んだ設定ファイルが実態より遅れていたこと ③ 対策は工程0として「数字を見る前に、実体ファイルで現状を確かめる」を先頭に置くこと

① 初回に何を間違えたか

エージェントは初回の分析で、こう報告しました。

Pinterestは未稼働。

実際には9枚のピンが公開済みでした（3日間で5枚・1枚・3枚）。

計算の誤りではありません。AIが最初に読んだプロジェクト指示ファイルに「Pinterestは準備中」という趣旨の記述が残っていただけです。そのファイルは人間（と別のAI）が更新するもので、実際の投稿状況より遅れていました。

この誤りが厄介なのは、その後の判断が全部ずれることです。実際、初回のレポートには「Pinterestのアウトバウンドクリックが0なのは問題だ」という趣旨の分析が入りかけていました。Pinterestの当面の役割は流入ではなくクロールの入口を作ることなので、クリック0は失敗ではありません。 見るべきだったのは「Pinterestのクローラが来ているか」でした（実測で日12リクエスト来ていました）。

② 足した工程0

そこで、数字を見る前の工程を手順書の先頭に置きました。

確認すること	どこで確かめるか
ピンが何枚公開済みか	投稿計画ファイルの「済」欄
どの導線をやる／やらないか・目標値	SNS戦略のドキュメント
その導線の役割は流入か、インデックス促進か	インデックス戦略のドキュメント

そして、手順書に次の一文を書きました。

⚠ プロジェクト指示ファイルは実態より遅れることがある。実体ファイルで確かめる。

AIが最初に読むファイルほど、更新が遅れます。 全体を要約したファイルは、日々の作業では更新されないからです。だから工程0は「要約を読む」ではなく「実体を数える」にしました。この種の「毎回守らせたい前提」を指示ファイル側に固定する考え方はCLAUDE.mdの書き方と同じです。

③ 手順書は「その日に踏んだ穴」だけで増やす

工程0の後、手順書に追加した規則を数えたら、全部その日に実際に踏んだ穴でした。 一般論から書いたものが1つもありません。

追加した規則	きっかけになった実際の出来事
11〜30位が該当なしでも終わらせず、クエリと記事の語のズレを見る	「配線」で書いた記事に、「コード」「充電ケーブル」で表示がついていた（表示24回中17回が「コード」系、「配線」は2回）
初回・移行直後は「変化なし」ではなく現在地を置く	差分の土台が無い日に「変化なし」と書いて、何も分からないレポートになった
すべての数字にボット込みか実読者かを明示する	「Organic 12セッション」の内訳が、実読者6と滞在0秒のボット6だった
1つのツールだけで結論を出さない	アクセス解析の数字とサーバログで桁が2つ違った（→GA4だけ見るとクローラは見えない）
打ち手は3つまで。4つ以上出さない	出しても実行されないので、優先順位が消える

⚠ 覚えておく一行 手順書に一般論を書かない。 一般論はAIが元から知っているので足す意味がなく、量だけ増えて全体が読まれなくなります。書くのは「今日そこで転んだ」ことだけです。

④ 追加した規則に、さらに実行下限を付けた

「クエリと記事の語のズレを見る」という規則は、そのままだと危険でした。後日、別の観点から突き返されています。

この規則の元になった診断は、表示24回中17回という母数があったから成立したものです。表示1〜2回では「ズレの有無」は言えても「ズレが原因」は言えません。

そこで下限を付けました。

条件	やること
そのクエリの実オーガニック表示が5回未満	判定しない。「母数不足で判定不能」と書いて終える
5回以上	判定する。ただし修正案が「個人では1位を取れない」と判定済みのキーワードに寄るなら却下

さらに、「語が合っていない」と「直せば流入が増える」は別物なので、必ず分けて書くことにしました。34〜90位＝4〜9ページ目では、語を合わせても1ページ目には届きません。

規則を足すと、その規則自体が誤用されます。 手順書の更新は1回で終わりません。

⑤ cronの時刻が深夜2時になっていた

運用の側でも1つ間違えていました。定時実行の設定が

13 2 * * *

になっていて、深夜2時13分に走る設定でした。「毎朝8時」と手順書に書いてあるのに、です。

このプロジェクトの実行環境はPCなので、深夜2時はPCが起動している保証がありません。 実行されない日が出ます。0 8 * * * に直しました。

さらに悪いことに、この食い違いはしばらく発覚しませんでした。 記録ファイルは生成されていたので、「動いている」ように見えていたからです。出力があること自体は、設計どおりに動いている証拠になりません。（この構造をもっと大きく踏んだ話が自動化は静かに壊れるです）

⑥ 「毎日やる」と決めたことを、実際に毎日出させる

手順書には、こう書いてあります。

「流入が少ないから」で省略しない。 ①どの記事が見られたか ②どの記事のどのボタンが押されたか ③回遊の3つは毎回出す。少ないなら少ないまま名指しで書く

数字が小さいときほど、AIは「有意な変化なし」でまとめようとします。ところが小さい数字こそ名指しで残す価値があります。 実際、記事→記事の送客が1件から6件に増えたことも、その6件のうち5件が同じ枠から出ていたことも、件数が一桁だから分かったことです。

自分でやる手順

工程0を作る。 数字を見る前に、実体ファイルで現状を確かめる手順を先頭に置く
「要約ファイルは遅れる」と明記する。 AIが最初に読むファイルほど古い
手順書には、その日に転んだことだけを足す。 一般論を書かない
足した規則に実行下限を付ける。 「母数が◯未満なら判定しない」
cronの時刻を実際の実行環境で確認する。 記録が生成されていても、意図した時刻とは限らない
打ち手は3つまでに制限する
数字が小さくても省略させない。 名指しで書かせる

やりがちな失敗

失敗	何が起きるか	直し方
要約ファイルを前提にして分析させる	初回から事実を誤る	工程0で実体を数えさせる
手順書に一般論を書く	量が増えて全体が読まれなくなる	その日に踏んだ穴だけ足す
規則を足して終わりにする	母数が無い場面で規則が誤用される	実行下限を付ける
記録が生成されていることで安心する	深夜2時に走っていても気づかない	実行時刻を実環境で確認する
数字が小さい日を「変化なし」で埋める	一桁だから見えた事実を捨てる	少ないまま名指しで書かせる

AIが持っていたタスク自体の前提が誤っていた話は存在しないタスクが数週間残っていた件にあります。

まとめ

AIの誤りは計算ではなく前提に出る。 最初に読むファイルほど古い
工程0＝実体を数える、を先頭に置く
手順書は、その日に転んだことだけで育てる。 一般論は足さない
足した規則には実行下限を付ける。 規則そのものが誤用される