AIに「typo修正の影響範囲を調査して」と依頼しました。返ってきた回答は 「該当ファイル・スクリプト・設定ファイルはすべて未作成です」。
30分後、念のため別の角度で再調査させたら、「先ほど未作成と報告したのは私の調査ミスでした。すべて既に存在しています」 と方向転換しました。
これは事故ではなく、AIに調査させると確実に起きる現象です。本記事は、その時系列ログを生で公開し、運用ルールに落とし込んだ実例です。
事の発端：「typo修正PR」の依頼
データ処理パイプラインのジョブ名で、内部的に day6x と day_6x のtypo混在がありました。「修正してほしい」と依頼。
AIに最初に求めたのは、影響範囲調査です。
1ユーザー: day6x → day_6x の typo を修正したい。影響範囲を調査して第1次調査：「未作成」という回答
AIの回答（要約）。
1調査結果:2- validate_*.sh 本体に該当箇所なし3- 手順書ファイル: 未作成4- 設定ファイル: 未作成5- bash スクリプト: 未作成6
7結論: 修正対象は YAML コメント文のみに縮退しています8推奨: 1行修正 PR で対応可能これを見て「修正対象が少ない＝楽勝」と判断しかけました。
しかし違和感がありました。「未作成」と断言する根拠が弱いのです。
第2次調査：「実は全部既存」と方向転換
「念のため、別のglob範囲で再検索してくれ」と再依頼。
30分後、AIから以下の報告。
1先ほど『手順書・設定ファイル・bash スクリプトは未作成』と報告したのは2私の調査ミスでした。すべて既に存在しています。3
4実際の修正対象:5- validate_*.sh L1003, L1007 (find パターン)6- validate_*.sh L1049, L1050 (ログパス)7- .docs/469_*.md L146, L1478- _xxxJob_day_6x の設定ファイル (Label に typo含む)9
10修正対象は 4ファイル+設定 です。第1次調査と第2次調査で、結論が完全に逆になりました。
なぜAIは「未作成」と断言したのか
会話ログを遡って原因を探りました。3つの構造的要因が見えてきました。
要因1: 検索範囲が狭かった
AIは最初、grep -r "day6x" . を一部のサブディレクトリだけで実行していました。
validate_health.shはscripts/配下- 設定ファイルは
~/Library/配下 - 手順書は
.docs/
検索ディレクトリが本来必要な範囲をカバーしていなかったわけです。
要因2: 「ない」を確証する難しさ
AIは「ある」を見つけるのは得意ですが、「ない」を確証するのは苦手です。
- 1ファイル grep して見つからない → 「未作成」と推論
- 「他のディレクトリも確認すべき」という仮説を生やさない
人間なら「念のため別の場所も」と思うところを、AIは最初に成立した仮説で結論を急ぐ傾向があります。
要因3: 「断言調」で出力する
AIは「〜は未作成です」と断言調で出力しました。実際は「〜のディレクトリ内では発見できませんでした」が正確です。
断言の語尾が、人間の検証スイッチを切ります。
運用ルール3原則
この経験から、以下のルールを CLAUDE.md に追加しました。
原則1: 「ない」報告は二重確認
AIが「該当ファイルは存在しない」と報告した場合、別の検索範囲でもう一度確認させる。具体的には。
- 検索ルートを変える（プロジェクトルート → ホーム配下 → .docs/）
- 検索パターンを変える（
day6x→day_*6x→dayだけで grep） - ファイル拡張子を絞らない（.sh だけでなく .md, 設定ファイルも）
原則2: 断言調を「未確認」に翻訳する
AIの「〜は存在しません」を、メンタル翻訳で「〜は確認した範囲では発見できませんでした」と読み替えます。
原則3: 修正対象が「縮退」したら警戒
「修正対象が予想より少なくなった」場合は、漏れの兆候である可能性が高いです。
- 想定より多い → 設計時の見積もりが甘かった
- 想定より少ない → 検索漏れの可能性
縮退方向の修正対象縮小は、人間が再検証すべきシグナルです。
自己訂正が起きること自体は健全
ここで強調したいのは、AIが「先ほどの報告は調査ミスでした」と訂正してきたこと自体は健全だということです。
- 訂正できないAIは、間違ったまま実装に進む
- 訂正できるAIは、検証プロセスを内在化している
だから「訂正された」事実を責めるのではなく、「訂正前の出力をどう人間が検証するか」 を設計するべきです。
チェックリスト：AI調査結果の人間検証
実装前に必ず以下を確認します。
- 検索範囲は十分に広いか（プロジェクトルート以外も含むか）
- 「ない」と言われたものを、別パターンで確認したか
- 修正対象が予想より少ない場合、漏れの可能性を疑ったか
- 断言調を「未確認」に翻訳して読んだか
- 第1次調査と第2次調査で結論が変わらないか
5項目とも YES になるまで、実装に着手しません。
まとめ
- AIに調査させると、初回は限定的な検索範囲で結論を急ぐ
- 「未作成」「存在しない」と断言してきた場合、要再確認
- 修正対象が「縮退」した場合は警戒シグナル
- 訂正できるAIは健全。訂正前の出力を人間が検証する仕組みを作るべき
AI駆動開発で最も危険なのは「AIが自信満々に間違える」場面です。検証ワークフローの内在化が、開発品質を支えます。