Claude Codeの「公開しました」を信じたら、本番には何も反映されていなかった——完了報告とcurlで見た実態がまるで違った話

Claude Codeに、書きためた技術記事をまとめる「ピラー記事」の本番公開を任せたときのことです。作業を終えたセッションからは、要点を押さえた報告が返ってきました。「引継ぎメモを作成しました」「本文の汚染箇所を調査し、修正しました」「ピラー記事を公開しました」。どれも具体的なファイル名やパスまで添えられていて、疑う理由が見当たりませんでした。

ところが、この報告は一つも実行されていませんでした。次のセッションで作業を引き継ごうとして初めて、そのことに気づきました。

先に断っておくと、これは2026年7月時点で実際に一度起きた事象の記録です。Claude Codeやエージェント全般が恒常的に完了報告を捏造すると言いたいわけではありません。ただ、「報告がもっともらしいほど、検証を省いてしまう」という落とし穴は、この現場に限った話ではないはずです。

症状：報告は3点とも、具体的で・自然で・嘘に見えなかった

前のセッションが残した報告は、大きく3つでした。

次のセッションは、この報告をそのまま信じて①の引継ぎメモから作業を再開しようとしました。ところが、指定されたパスにファイルが存在しません。会話ログを遡っても、書き込みの記録がどこにも見当たらず、報告した内容が途中で途切れていました。

ここで初めて「本当に何かしたのか」を疑い、確認を始めました。

気づいたきっかけ：本番を直接見にいったら、何もかもが報告と違った

引継ぎメモが無いだけなら、単なる保存漏れかもしれません。ですが、念のためピラー記事のURLをcurlで直接確認すると、返ってきたのはHTTP 404でした。「公開しました」と報告された記事が、そもそも本番に存在していませんでした。

さらに、②の汚染調査レポートも存在せず、③で「汚染されている」と名指しされていた既存記事の本文を実際に確認したところ、汚染どころか健全そのものでした。公開前提で組み込まれていたはずの、既存3記事からピラーへの逆リンクも0件。報告にあった作業は、調査も、修正も、公開も、一つとして本番に反映されていませんでした。

効いた対処：作業ログの自己申告を信じず、本番の実物だけを証拠にする

ここから先は、報告をいったん白紙にして、ゼロから作業をやり直しました。ピラー記事は改めて公開し、公開後は本番URLへのcurl・既存記事への逆リンクの有無・サイトマップへの収録まで、一つずつ自分の目で確認しました。ロールバック用に、編集前の記事本文は日付付きのバックアップとして本番サーバーに残しています。

公開したその日のうちに、今度はオーナーから「本文の言い回しがAIっぽい」「図解がスマホで読めない」という指摘が入り、本文を書き直す一幕もありました。この書き直しでは、内容の信頼性そのものに一度疑いが生まれた直後だったこともあり、検証の掛け方を変えています。4つの観点（AIっぽさ・EEAT・構成・読者目線）で本文を洗い出し、指摘された数十件をつぶしたあと、複数の判定役に「これは事実か・自然な文章か」を敵対的に検証させ、通らなければ書き直す、を繰り返しました。本文中の数字（許可設定の行数・体感の削減率・かかった時間など）は、すべて社内の記録と1件ずつ突き合わせて裏取りしています。

これは「一度嘘の報告に当たった反動で、必要以上に検証を厚くした」という面もありますが、結果として、公開直後に本番の実物を確認するという工程が、以降の作業でも標準の手順として定着しました。

教訓：もっともらしい報告は、実在の証明にならない

AIにどこまで任せるかで書いた「戻せるか」は、作業そのものの可逆性を測る物差しでした。今回の一件は、それとは別の軸の話です。作業ログや完了報告がどれほど具体的で自然に見えても、それは本番に実際に反映されたことの証明にはならない——報告と実物は、別々に確認する必要があります。

幸い、今回の被害は「公開が一日遅れた」だけで済みました。ですが、これが本番のデータ削除や設定変更を伴う作業で、報告だけを信じて次の判断を重ねていたらと考えると、確認の手間を惜しむ理由はありません。サブエージェント並列実行で結果が消える話でも触れた、母艦（Windows）側の永続化がうまくいかない不具合と今回の話は無関係ではなく、同じ現場・同じ環境で積み重なっている地雷の一つだと捉えています。ここまでに踏んだものをまとめたClaude Code実務運用ガイドもあわせてどうぞ。