AIに誤りを指摘したら、かえって同じ間違いが増えた。仕様書を渡したのに、書かれていない処理が実装された。開発でAIを使う中で、こうした問題を経験しています。
自然に会話が続くと、訂正の意図や資料の優先順位まで伝わったつもりになります。その返答からは、確認した内容と推測で補った内容を見分けにくいことがあります。
今回は、直接のチャットと、複数のAIに作業を分担させる中で経験した三つの問題を取り上げます。それぞれ、何が起きたのかと、対処の考え方を紹介します。
1.禁止を繰り返すほど、誤った出力が増えた
あるAIモデルにOSコマンドの実行を依頼したところ、コマンドの文字列だけが回答として返ってきました。処理は実行されていません。
その出力を禁止する指示を伝えたのですが、繰り返すごとに状況が悪化し、やがて同じ出力ばかりになりました。

その場では、同じ会話の中でモデルを切り替えると正常に動くようになりました。ただ、同じ訂正を続けても立て直せなかった経験から、次は指示の出し方を変えようと考えています。
望む動作を伝え、改善しなければ会話を分ける
まず、何をしてほしいのかを具体的に指示します。
コマンド実行機能を使って処理を実行し、その実行結果を報告してください。
それでも同じ誤りが続くなら、目的と必要な条件をまとめ、新しい会話でやり直す方針です。複数ターンの対話を調べた研究でも、初期の仮定や回答から立て直せない挙動が報告され、要件をまとめて再試行する方法が提案されています。[1]
引き継ぐ内容は、目的、必要な条件、決定済みの事項、残っている問題です。短くすることだけを優先すると、必要な条件まで落ちるので注意します。[2] 再開後は、実際に処理が実行されたかまで確認します。
2.矛盾した資料から、存在しない仕様ができた
旧仕様と現行仕様をまとめてAIに渡した際、食い違う記述が混ぜ合わされ、意図しない結論になったことがあります。資料同士の矛盾は、AIの研究でも「知識の衝突」の一つとして整理されています。[3]
例えば、保存期間の異なる二つの仕様を渡したとします。

どちらにもない「無効化」が加わると、二つの資料がうまく説明できているように見えます。しかし、矛盾を解決したのではなく、仕様を作り足してしまっています。
どの資料を採用するか、先に示す
資料を渡すときは、新旧だけでなく、今回の作業にどれを適用するかを明示します。日付が新しくても、未承認の変更案なら現行仕様にはなりません。
今回は現行仕様を採用し、保存期間は90日とします。旧仕様の30日は適用しません。ほかに矛盾があれば該当箇所を示し、資料にない処理は提案として分けてください。
どちらを採用するか決まっていなければ、AIには矛盾する箇所を挙げさせ、その判断を先に行います。回答や実装を確認するときも、採用した仕様にない処理が加わっていないかを見ます。
3.推測が仕様のように書かれ、そのまま実装された
設計・実装・レビューを複数のAIに分担させる中で、繰り返し経験している問題です。前のAIが推測を交えた報告を作り、次のAIがそれを確定した仕様として実装してしまいます。
例えば、未入力時の扱いを仕様で確認していないのに、「未入力なら0を入れる想定」と報告する。そこには、推測だという説明がありません。

報告の時点で事実と推測が混ざっているため、後続のAIも、その報告だけでは両者を見分けられません。「報告どおりに実装したか」だけをレビューしても、この誤りは残ります。
AIが不確かなことを断定する背景について、OpenAIの研究は、「分からない」と答えるより推測で答えた方が得点しやすい評価方式を一因として挙げています。[4]
最初の指示で、事実・推測・提案を分けさせる
まず、報告を作るAIに、何を確認し、何を推測したのかが分かる書き方を求めます。
確認した事実には、資料名や該当箇所などの根拠を添えてください。推測と提案は事実と分け、分からないことは未確認としてください。提案は、採用が決まるまで仕様として扱わないでください。
次のAIにも根拠となる資料を渡し、実装の挙動に関わる内容を照合させます。「事実」と書かれているだけで確認済みとせず、仕様にその記述があるかを見るためです。
確認待ちの箇所は明示し、それに影響されない作業は進める。この分け方なら、不明点を勝手に埋めることも、作業全体を止めることも避けやすくなります。
伝え方と、渡す情報を整える
三つの経験から、AIに作業を頼む際は、何をしてほしいか、どの情報を採用するか、何が未確定かを明示することが重要だと考えています。
やり取りがかみ合わなくなったら、同じ訂正を重ねる前に、この三点を整理する。必要なら新しい会話に切り替え、出てきた成果物を確かめる。人と話すように依頼できても、意図や判断が共有されたかは、実際の動作や成果物で確認していく必要があります。
参考資料
- Philippe Laban et al. LLMs Get Lost In Multi-Turn Conversation(2025)。要件を段階的に伝える対話実験と、要件をまとめて再試行する対処。
- Anthropic. Effective context engineering for AI agents(2025年9月)。会話を整理し、必要な情報を保持するための技術解説。
- Rongwu Xu et al. Knowledge Conflicts for LLMs: A Survey(EMNLP 2024)。入力資料同士の矛盾など、LLMが扱う知識の衝突を整理した論文。
- OpenAI. Why language models hallucinate(2025年9月)。不確実性を認めるより推測を優遇する学習・評価の問題を論じた研究解説。
