AIの誤りは2種類ある——ハルシネーションより怖い「範囲の取り違え」は、コードレビューでは見つからない
AIの誤りというと、存在しない機能を答えるハルシネーションを思い浮かべる。
だが実務で本当に怖いのは、事実がすべて正しいまま、適用する範囲だけが間違っている誤りだ。
こちらは個々の情報が正しいので、コードレビューをいくら重ねても浮かんでこない。
AI駆動開発で実際に起きた2件の事例から、成果物レビューの手前に必要な「前提監査」を整理する。
この記事は AI駆動開発の誤りは2種類ある｜ハルシネーションより怖い、範囲の取り違え のダイジェスト版です。
実例2の詳細な経緯や、本番変更前のゲート項目は、上記の完全版をどうぞ。
実例1：存在しない設定項目を案内された
作業中、AIツールから設定変更を求められた。
案内された場所を探したが、該当する項目が見つからない。
そこで、自分のPCに表示されている画面をそのまま共有した。
AIツールは別の設定画面を案内したが、そこにも目的の項目はなかった。
やり取りを重ねた結果、最初の項目名はAIツールの推測だったと判明した。
実際の本番画面を確認せず、「存在するんだろう」として手順を組み立てていた。
これは分かりやすいハルシネーションだ。
ただし、案内そのものは不自然ではなかった。
設定画面の階層にも、項目名にも、それらしい整合性があった。
文章を読んだだけでは、推測だと判断できない。
とはいえ、この種の誤りはまだ軽い。
探しても見つからないので、遅くとも数分で気づける。
本当に怖いのは、最後まで気づけない次のタイプだ。
実例2：正しい情報を、間違った範囲へ適用した
先に前提を書いておく。
サービス開発では、動作確認用の開発環境と、利用者が使う本番環境を分けて用意する。
開発環境は作りかけの画面を外部に見られると困るので、関係者だけが入れるよう認証をかけることが多い。
一方の本番環境は、そもそも誰でも使えるように公開するものだ。
つまりこの認証は、開発環境の事情から生まれた仕組みであって、サービスに必要な機能ではない。
AIツールは、本番環境でも同じ認証情報が必要だと判断した。
そしてその前提のまま、本番用の認証情報を更新しようとしていた。
手順は整っていた。
更新後の値を外部サービスへ登録する手順があった。
値を会話やログへ出さない対策も考えられていた。
失敗した場合の停止条件まで整理されていた。
安全に実行できるかという観点では、十分に検討されていた。
しかし、その手前に問題が残っていた。
「その認証情報は、本番環境でも本当に必要なのか？」
調べ直させた結果、本番環境では不要だと判明した。
開発環境だけに存在する要件を、本番環境へ適用していた。
さらに厄介なのは、この誤った前提が手順書や検証処理にも反映され始めていたことだ。
不要な設定が、本番環境の必須条件として扱われかけていた。
誤った前提は、放っておくと成果物の側へ固定される。
2つの誤りは、見つけやすさがまったく違う
| ①存在しない情報を案内する | ②正しい情報を間違った範囲へ適用する | |
|---|---|---|
| 例 | 実在しない設定項目 | 開発環境の認証を本番の要件として扱う |
| 個々の事実 | 誤っている | すべて正しい |
| 見つけ方 | コードを動かせば失敗する。画面を見れば項目がない | 事実確認を重ねても浮かんでこない |
| 気づくまで | 数分 | 本番へ反映されるまで気づけないことがある |
②が厄介なのは、個々の情報がすべて正しいので、全体の結論まで正しく見えることだ。
そして②のとき、AIツールはサボっていたわけではない。
むしろ、与えられた前提の中では積極的に作業を進めていた。
認証情報の更新方法を考える。
安全な受け渡し方法を考える。
検証手順を整える。
失敗時の停止条件を決める。
個々の作業には合理性がある。
誤った前提の中でも、手順は最適化できてしまう。
通常の開発でも、誤った仕様から正しいコードを作ることはある。
AIツールを使うと、その速度が大幅に上がる。
同時に、誤った方向へ進む速度も上がる。
しかも、作業量が増えるほど進捗が出ているように見える。
ファイルが更新される。
テストが追加される。
手順書が詳しくなる。
だが、成果物が増えたことと、目的へ近づいたことは同じではない。
AIが作ったものを確認するのが、通常のレビューだ。
AIがなぜその作業を始めたのかを確認するのが、前提監査になる。
正解を知らなくても、作業は止められる
本番作業を止めたとき、正解を証明できていたわけではない。
すべての設定ファイルを読んでいたわけでもない。
あったのは、仕組みに対する違和感だけだ。
開発環境で認証が必要なのは分かる。
しかし、本番環境にも同じ仕組みが要るのか。
この疑問で、作業を一度止めた。
人間の強みは、AIより多くを記憶することではない。
常にAIより優れたコードを書けることでもない。
目的や背景を踏まえ、いまの作業へ疑問を持てることだ。
そしてここが重要だが、AIを疑うことは、すべてを人間がやり直すことではない。
今回も、構成を手作業で調査したわけではない。
疑問を伝えたあとの調査は、AIツールが行った。
1. 人間が違和感を示す
2. AIツールが構成を調査する
3. 人間が根拠を確認し、進行の可否を判断する
この循環が、現実的な役割分担になる。
▶ 実例2の詳細な経緯や、本番変更前のゲート項目はこちら → AI駆動開発の誤りは2種類ある
作業を止めるべき5つの違和感
毎回すべてを細部まで確認するのは難しい。
そこで、中断のきっかけを決めておく。
- ①案内されたものが実際には存在しない — すぐ自分の見落としと判断せず、実在を確認したかAIへ問い直す
- ②当初なかった作業が途中から増えた — なぜ必要か／どの要件から導かれたか／やらないと何が失敗するかの3点を確認する
- ③環境ごとの差が説明されていない — 開発環境の都合で入れた仕組みを、本番へ機械的に適用していないか
- ④「念のため」で設定が追加される — 不要な認証や権限は運用を複雑にし、障害点を増やす
- ⑤目的より手順の消化が優先されている — 手順書やテストが増えているのに、目的へ近づいた説明がない
③が、実例2で起きたことだ。
開発環境の認証、動作確認用の仮データ、検証を楽にするための設定。
これらはサービスの要件ではなく、開発の事情から生まれたものだ。
両方で必要という結論には、環境別の根拠が要る。
AIには「事実・推論・仮説」を分けさせる
違和感を持ったとき、調査を依頼するなら結論だけを求めない。
回答を3つに分けさせる。
- 実際のコードや画面で確認した事実
- 確認した事実から導いた推論
- まだ確認できていない仮説
この区別がないと、推測が事実のように扱われる。
実例1の設定項目も、実在を確認した情報ではなかった。
しかし最初の案内では、推測だと示されていなかった。
作業を止めるときは、そのままこう投げる。
いったん作業を止めてください。
この変更が必要だと判断した根拠を確認してください。
確認済みの事実、事実からの推論、未確認の仮説を分けてください。
開発環境と本番環境で、前提が同じかも確認してください。
この変更を行わない場合、具体的に何が失敗するのか示してください。
変更せずに目的を達成する方法がないかも検討してください。
重要なのは、AIに反省文を書かせることではない。
作業の必要性を、検証可能な根拠へ戻すことだ。
そして根拠を求めるときも、説明の長さで判断してはならない。
どのファイルを確認したのか。
実際の挙動を確認したのか。
反対の可能性を検討したのか。
AIツールが自信を持っているかは重要ではない。
確認済みの事実から、結論を再構築できるかが重要だ。
本番変更の前には「そもそも必要か」を先に確認する
コードの読み取りや調査は、後からやり直せる。
一方、外部サービスの設定変更は影響が大きい。
認証情報の更新、Secretの登録、DBの変更、インフラ設定の適用、本番デプロイ。
こうした作業へ進む前には、実行方法だけでなく必要性を確認する。
安全に実行できるか、だけでは足りない。
実行する必要があるか、を先に確認する。
今回も、安全な認証情報の更新方法は検討されていた。
しかし、更新自体が不要だった。
不要な作業を安全に行う方法を考えても、目的には近づかない。
利用者データと本番環境に触れる操作だけは、最後の実行者を自分にしている。
AIを信用していないからではない。
誤りが起きる確率ではなく、起きたときに取り返せるかどうかで線を引いているからだ。
なお、こうして前提誤りを検出し、不要な本番変更を止めた経験は、そのまま実績になる。
ただし、この種の判断は記録しなければ残らない。
完成した機能は後からでも思い出せるが、どこで作業を止めたかは、その場で書き留めなければ消える。
Skillsheet-Port は案件を担当工程・期間・技術ごとにフォームへ入力していく作りなので、判断の記録も記憶が新しいうちに積める。
まとめ
- AIの誤りは2種類ある。①存在しない情報を案内する ②正しい情報を間違った範囲へ適用する
- ①は数分で気づける。②は個々の事実がすべて正しいので、成果物レビューでは見つからない
- 誤った前提の中でも手順は最適化できる。進捗が出ているように見えるのが厄介
- 止めるのに正解は要らない。違和感だけで一度止めていい
- 疑う＝全部やり直す、ではない。人間が違和感を示し、調査はAIにやらせ、人間が可否を判断する
- 5つの違和感を中断のきっかけにする（存在しない／作業が増えた／環境差の未説明／念のため／手順の消化）
- AIには事実・推論・仮説を分けさせる
- 本番変更の前は「安全に実行できるか」でなく**「実行する必要があるか」**を先に問う
次にAIツールから本番環境を触る手順が上がってきたら、実行方法を読む前に一度だけ問うてほしい。
それ、本番でも本当に必要か。
その一問が、取り返しのつかない変更を止める。
▶ 完全版ガイドはこちら → AI駆動開発の誤りは2種類ある｜ハルシネーションより怖い、範囲の取り違え
▶ 無料でスキルシートを作ってみる → https://www.skillsheet-port.com/