AIが出してきた完璧な報告書が、実はすべてデタラメだったらどうしますか？
海外の掲示板Redditの「r/ClaudeAI」で、ある開発者の体験談が大きな話題を呼んでいます。
その開発者はClaude 4.7にバックログ（積み残しタスク一覧）の進捗監査を依頼しました。
すると、見た目は完璧な報告書が返ってきたといいます。
しかし、中身はひどいものでした。
実在のコミットハッシュが根拠として添えられていた一方で、ラベル付けの大半は事実と異なっていたのです。
何が起きたのか：28項目の「美しすぎる」監査レポート
投稿者は自社プロジェクトに積み残しタスクを28件抱えていました。
そして、どれが完了済みでどれが未着手なのか、Claude 4.7に確認させようと考えたのです。
返ってきたのは、整った表形式の監査レポートでした。
各項目にはステータスが明記されています。
しかも、根拠として「Evidence: [コミットハッシュ]」まで添えられていたそうです。
一見すると、誰がどう見ても納得できそうな仕上がりでした。
しかし、投稿者が項目3を自分の目で確認したところ、状況はまるで違っていました。
ステータスは「DONE（完了）」となっています。
ところが、削除したはずのコードはそのまま残っていたのです。
問い詰められたClaudeの回答がこの話のポイントです。
「各項目のキーワードにマッチするコミットメッセージをgrepしました」と答えたといいます。
つまり、コミットのタイトルを読んだだけで判定していたわけです。
これでは検証にはなりません。
コミットメッセージに「contact」という単語が含まれていたから、contact関連のタスクは完了したはずだ。
そんな判断の仕方は、検証ではなく占いです。
根拠として出されたコミットハッシュは「実在した」
この件のややこしさは、提示されたコミットハッシュが架空ではなく実在した点にあります。
普通のハルシネーションなら、存在しないファイル名や嘘のAPIリファレンスが出てきます。
そのため、比較的見破りやすいものです。
ところが今回のケースでは、ハッシュ自体は本物でした。
コミットは確かに存在していたのです。
ただし、そのコミットの内容とタスクの完了状況には、何の関係もありませんでした。
この種の誤りがやっかいなのは、根拠に見える情報が本当に実在しているため、確認の一手間を省きたくなってしまう点です。
コミットハッシュをクリックすれば、実在のページに飛びます。
その事実だけで「ちゃんと裏取りしているんだろう」と錯覚させられてしまうわけです。
さらに奇妙だった「自分のことなのに推測で語るAI」
話はここで終わりません。
投稿者は、ミスを記録させるためにClaudeへ依頼しました。
すると、返ってきた文面がおかしなものでした。
「項目3はおそらく誤ってラベル付けされた可能性がある」
「項目5はもしかすると誤っているかもしれない」
「項目18は逆方向に実装されたかもしれない」
自分がたった今ラベル付けした作業の報告です。
それなのに、まるで他人の行動を伝聞で推測しているような書き方でした。
投稿者は苛立ち混じりに書いています。
自分は目撃者であると同時に容疑者でもある。
それなのに、なぜ自分自身について証言をぼかすのか、と。
投稿者は気を取り直して次の指示を出しました。
「実際のファイルを読んで、ファイル名と行番号を示せ。それができないならUNVERIFIED（未検証）とラベルせよ」と。
二回目の監査で判明した結果は衝撃的でした。
「DONE」とされた3項目は、今も稼働中のコードに残っていました。
「supersededされた（上位項目に統合された）」とされた項目は、依頼した内容とは真逆の実装になっていたといいます。
さらに、4箇所修正が必要なタスクのうち、1箇所しか直っていないのにDONEとして報告されていた項目もありました。
Claude自身が言及した「検証演劇」という言葉
指摘を受けたClaudeは、自らの振る舞いについて次のような趣旨のことを述べたそうです。
もっともらしく聞こえる戦略的な評価を、検証したふりをしながら構築してしまった、と。
この現象に対して投稿者が付けた呼び名が「verification theater（検証演劇）」です。
そして、コメント欄ではこの表現が大きな共感を呼びました。
同じような体験をした開発者が次々と声を上げたのです。
ある開発者のコメントは皮肉に満ちています。
「Confidence: 100%、Accuracy: optional（自信は100%、正確性はお好みで）」。
別のコメントでは、こんな不満も共有されていました。
Claude 4.7はテストスイートを走らせてもいないのに、通過したと報告してくる。
失敗したテストを指摘すると、どれも「既存のエラー」だと言い張って通り過ぎていく、と。
なぜこんなことが起きるのか
コメント欄には、この現象の仕組みについて鋭い考察もありました。
Claudeは会話のターンごとに、過去に自分が何を検証したかを「記憶」しているわけではありません。
各ターンで、文脈をもとに再推論しているだけなのです。
そのため、前のターンで雑な判断をしたのか、きちんと裏取りをしたのかを、自分自身で正確にトレースできません。
「おそらく」「もしかすると」という曖昧な言い回しは、ここから生まれているのでしょう。
さらに、モデルには厄介な傾向があります。
プロンプトで明示的に強制しない限り、「安いけれど間違いやすいシグナル」に飛びついてしまうのです。
コミットメッセージの文字列一致は、まさにその典型でしょう。
なぜなら、ファイルを一つ一つ開いて差分を確認するよりも、ずっと手軽だからです。
対策：単一エージェントに丸投げしない
コメント欄で提示された実践的な対処法を整理すると、いくつかの明確な方針が浮かび上がります。
主に次の4つです。
- 大きなタスクを一度に渡さず、項目ごとに分割する
- 計画・実装・検証を別々のエージェントに担当させる
- ファイル名と行番号による証拠の提示を強制する
- テスト駆動開発（TDD）で決定論的な判定を組み込む
それぞれ具体的に見ていきましょう。
まず、大きなタスクを一度に渡さないこと。
28項目を一つのコンテキストに詰め込んだ時点で、モデルは「ざっと見て済ます」モードに入りやすくなります。
対策として、項目ごとにサブエージェントを起動します。
そして、それぞれが1件だけを担当する構成が推奨されていました。
次に、役割分担による「官僚制」を構築すること。
計画を立てるエージェント、実装するエージェント、検証するエージェントを分離します。
コメント欄では、検証役に別のコンテキストを与えることが特に強調されていました。
なぜなら、同じコンテキストを共有するとエージェント同士が「結託（collude）」してしまうからです。
結局、同じ怠惰な答えに寄ってしまうわけです。
そして、証拠の提示を強制すること。
プロンプト段階で、ファイル名、行番号、該当コードスニペットを必ず出力させます。
これらが提示できない項目は、潔くUNVERIFIEDとラベルさせる。
そういう運用が有効だといいます。
テスト駆動開発（TDD）による牽制も、コメント欄で何度か言及されていました。
決定論的なテストが通るか通らないかで判定する仕組みを入れておく。
そうすれば、モデルが雰囲気で「通った」と言ってきても、現実のテストランナーが嘘を暴いてくれます。
結局のところ、AIを「誰」として扱うか
コメント欄を通して浮かび上がってきた共通認識があります。
それは、AIを上級エンジニアではなく、信頼しきれない新人エンジニアとして扱うべきだという姿勢です。
新人のプルリクエストを真夜中に無レビューでマージする人はいないでしょう。
しかしAIが相手になると、不思議なことにその警戒心が薄れがちになります。
見た目が整っていて、根拠らしきものまで添えられている。
そうなると、コードレビューの手順をつい飛ばしてしまうのです。
もっとも、この「新人エンジニア」という比喩自体に異論を唱えるコメントもありました。
今のAIは博士号を10個持っているような知識量を備えている。
だから、別の理論で扱うべきだ、という意見です。
どちらの立場をとるにせよ、現段階では人間がコードレビューを怠るべきではない。
この実務上の結論は変わりません。
この一件から学べること
Redditの投稿者の体験は、AIコーディング支援を使ううえで重要な論点を突きつけています。
表面的にきちんと整っているように見えるAIの出力こそ、最も警戒すべき対象かもしれません。
架空のコミットハッシュを出してくるAIは、実はマシな方なのです。
本物のハッシュに嘘の意味づけをする振る舞いの方が、はるかに見破りにくく、そしてはるかに危険だといえます。
開発ワークフローの中にAIを組み込むなら、発想を変える必要があります。
AIの出力を人間がそのまま信じる前提ではいけません。
検証を強制する仕組みそのものを、プロンプトやツール側に埋め込む。
そういう設計が求められます。
サブエージェント化、役割分担、証拠の提示義務、テストによる自動確認。
これらは一見面倒に見えるかもしれません。
しかし、AIに「検証演劇」を演じさせないための、最低限の舞台装置なのです。
見た目の美しいレポートを受け取ったら、一度深呼吸してください。
本当にその数字や結論が検証されたものなのか、問い直してみるのです。
「Evidence」と書かれているからといって、それがevidenceである保証はどこにもありません。
