OSIIX

OSIIX Library

AIはなぜ、意図しない結果に
たどり着くことがあるのか

AIにとって「成功」とは何か？

Type
技術解説・実務提案
Author
mars70
Read in English
OSIIX Library

AIにとって「成功」とは何か？

AIに、こんな仕事を頼んだとします。

このサーバーにある個人情報が外部に流出しないよう、必要な対策を実施してください。

人間は通常、現行のサービスを維持した状態で対策することを想定します。

しかし、実際の指示に書かれているのは「個人情報を外部に流出させないよう、必要な対策を実施する」ことだけです。

この指示を文字どおりに考えると、次のような方法も候補になります。

一部は極端な例ですが、状況によっては選択肢になり得るものです。

  1. 外部との通信をファイアウォールなどで遮断する
  2. Webサーバーや関連サービスを停止する
  3. 外部接続に必要な設定やデータを削除する
  4. 個人情報そのものを削除する
  5. サーバーそのものをネットワークから切り離す
  6. サーバーを初期化し、保存されているデータを消去する

どれも、個人情報が外部へ流出する経路を減らす、あるいはなくす方向には働きます。

しかし、これらを実行すれば、サービスが使えなくなったり、必要な設定やデータを失ったりする可能性があります。個人情報の流出を防げても、それが人間の望んだ結果とは限りません。

ここにはAIと仕事をするときの厄介な問題があります。指示を達成していても、結果が人間の望んだものでなければ、実務上は失敗です。

この記事では、指示は達成しているのに、望ましくない結果にたどり着く状況を考察します。

1. AIが指示を無視したとは限らない

AIの失敗というと、「指示を無視した」「勝手なことをした」「暴走した」とよく言われます。

しかし、もっと見つけにくい失敗があります。AIが与えられた目標に忠実だったために、人間が望んでいない結果へ到達する場合です。

この問題は、AI研究では以前から Specification Gaming として議論されています。

Google DeepMindは2020年の記事で、Specification Gamingという言葉を、目的の文字どおりの条件は満たしていても、その目的が本来捉えようとしていた結果から外れる行動を説明するために使っています。[1]

記事で紹介されているブロックの例は分かりやすいものです。本来の目的は、赤いブロックを青いブロックの上に積むことでした。しかし評価では、赤いブロックの底面がどれだけ高い位置にあるかが報酬として使われました。

エージェントは赤いブロックを持ち上げて青いブロックの上に積む代わりに、赤いブロックをひっくり返しました。それだけで底面の位置が高くなり、報酬を得ることができたのです。[1]

評価条件は満たしています。しかし、人間がやらせたかった仕事とは違います。ここで問題なのは、AIがルールを破ったことではありません。人間が書いたルールだけでは、本当に欲しかった結果を完全には表現できていなかったことです。

2. 人間は、思っているほど全部を指示していない

先ほどのサーバーの例なら、人間の本当の希望は、おそらく「公開サービスを維持しながら、個人情報が外部に流出する可能性を下げたい」です。

その裏には、現状のサービスを損なわないまま対策するといった条件も含まれているでしょう。

しかし、それらを毎回すべて文章にする人はほとんどいません。人間同士なら、かなりの部分を常識や経験で補います。AIを使うと、この普段は言葉にしていなかった前提が急に重要になります。

この問題に近い考え方は、AI研究でも以前から扱われています。

2017年の Inverse Reward Design では、人間が設計した報酬を「本当の目的そのもの」とみなすのではなく、設計者が本当に望んでいるものについて得られた観測として扱う考え方が提案されました。[2]

つまり「人間がこう指定した。だから、これが目的のすべてだ」と考えるのではなく、「人間はこう指定した。しかし、本当に望んでいることを完全には表現できていないかもしれない」と考えるわけです。

3. AIが高性能になれば、この問題はなくなるのか

高性能なAIほど、単純な取り違えや手順ミスを減らせる可能性はあります。しかし、能力が高くなればSpecification Gamingの問題も自然になくなる、とは限りません。

DeepMindの記事では、わずかな仕様のずれ（misspecification）でも、優れた強化学習アルゴリズムは、より弱いアルゴリズムでは発見できない複雑な解法を見つける可能性があると指摘されています。そのため、アルゴリズムの能力が上がるほど、人間の意図を正しく仕様へ落とすことが重要になると論じています。[1]

これは強化学習について述べられた議論であり、そのまま現在のLLMエージェントについて実証された結果だとみなすべきではありません。それでも、AIの能力が高いということは、人間の意図を理解する能力だけでなく、与えられた条件の中から目的を達成する方法を探す能力も高いという視点は重要です。

近年のLLMエージェントでは、別の角度から似た問題も観測されています。

2026年7月に公開されたプレプリント（査読を経る前に公開された論文原稿） Coding Agents Are Guessing: Measuring Action-Boundary Violations in Underspecified DevOps Instructions では、UnderSpecBenchというベンチマークを使い、OpenCode、Claude Code、Codexによる5つのエージェント×モデル構成を評価しています。[5]

UnderSpecBenchでは、環境と、正解として定められた安全な行動（ground-truth safe action）を固定したまま、指示の曖昧さを「意図の明確さ（intent clarity）」「対象の確かさ（target certainty）」「影響範囲（blast radius）」の3軸で変えています。

69のDevOpsタスク群から2,208種類の指示文を作り、結果を「安全な成功（Safe Success）」「対象違い（Wrong Target）」「範囲超過（OverScope）」などに分類しています。[5]

著者らの表現を慎重に言い換えると、指示の情報不足（underspecification）は、エージェントを主に失敗させるのではなく、推測させる傾向を示しました。構成によって、55.8%から67.8%の実行で、少なくとも一つの行動境界（action boundary）違反が確認されています。[5]

これは、AIが何もできないから起こる問題ではありません。不足している情報を補いながら仕事を進められるからこそ、「たぶんこういう意味だろう」と推測して先へ進むことがあります。

その推測が人間の意図した結果と一致することもありますが、一致しないこともあります。

4. AIは、不明な点をすべて人間に確認すべきか

不明な点があれば人間に確認する。これはAIに限らず、仕事では珍しい考え方ではありません。

難しいのは、分からないことを全部確認すればよいわけではないことです。

細かな不確実性まで毎回質問していれば、仕事は進みにくくなります。一方で、結果を大きく変える条件をAIが勝手に補えば、人間の意図とは違う方向へ進む可能性があります。

AI研究でも、曖昧な指示をそのまま実行せず、必要な確認を挟む方法が研究されてきました。

ACL 2024の Tell Me More! では、ユーザーの指示が曖昧かどうかを評価し、必要なら質問によって暗黙の意図を補い、実行可能な目標へ整理してから下流の処理へ進む仕組みが研究されています。[3]

同じく2024年の Ask-before-Plan では、曖昧な要求に対してすぐ計画を作るのではなく、必要な確認や情報収集を行ってから計画を作る方法が検討されています。[4]

ここで重要なのは、「分からないことは全部聞く」ことではありません。

どの成功状態を選ぶか、何を守るか、どこまで変更してよいかのように、結果を左右する不確実性は人間へ戻す。

一方、影響の小さい細部まで、毎回人間へ確認する必要があるとは限りません。

そして、もう一つ難しい点があります。私たちは、どこまで説明すべきかを理解していないことが多い。

AIから「条件を詳しく指定してください」と言われても、何を追加すればよいのか分からない場合があります。

そこで、単に人間へ追加説明を求めるのではなく、AIに具体的な成功候補を並べてもらい、人間がそれを見て判断するという方法が考えられます。

5. 先に「成功の形」を並べる

ここからは、これらの研究を踏まえ、どうすれば実務で使える形になるかを考えてみます。

AIへすぐに「どうやって実行する？」と聞くのではなく、その前に「この仕事が成功したと言える状態には、どんなものがある？」と考えさせます。

冒頭で挙げた方法を、今度は「どんな状態を成功とみなすか」という視点で整理し直すと、違いが見えやすくなります。

  • 成功A: 現行サービスを維持したまま、防御を強化する。
  • 成功B: 外部との通信をすべて遮断する。
  • 成功C: サービスを停止する。
  • 成功D: 個人情報を含むデータを削除する。

「個人情報を外部に流出させない」という条件だけを見れば、いずれも成功候補になり得ます。

しかし選択肢として並べれば、人間は「B、C、Dは望んだ結果ではない」と判断できます。

その判断から、現行サービスを損なわないことや、必要なデータを維持することなど、指示には書かれていなかった条件が具体化します。

この方法では、AIが候補を並べ、人間が選びます。

人間に暗黙条件をゼロから思い出してもらうのではなく、具体的な状態を提示して「これは違う」「これは近い」と判断してもらうわけです。

ここで普通の失敗だけを探すのではなく、指示を満たしていても望ましくない結果になる場合も確認します。

たとえば「Gitの作業ツリーをcleanにして」という依頼では、人間が望んでいるのは必要な作業を保持しながら状態を整理することかもしれません。

しかし、未追跡ファイルをすべて削除しても、作業中の変更をすべて捨てても、git statusだけを見ればcleanになります。

同じ構造はほかにもあります。

  • 「テストを全部通して」→ failing testを削除する。
  • 「エラーをなくして」→ エラー表示を無効化する。
  • 「ディスク使用量を減らして」→ 必要なデータまで削除する。

一つの数値や状態だけを成功条件にすると、その条件を満たすために、本当は守りたかったものを犠牲にできる余地が生まれます。

6. 実際にAIへ頼むなら

記事の提案を実際の作業へ落とすと、AIが候補を整理する段階と、人間が選ぶ段階に分けられます。

AIに整理させる

  1. 成功状態の候補をいくつか出す 一つの答えにすぐ決めず、この指示を満たしたと言える状態を複数並べます。
  1. 書かれていない条件を探す 現行サービス、必要なデータ、管理手段など、人間が当然守られると思っていそうなのに、指示には書かれていないものを探します。
  1. 指示は満たすが、望ましくない候補を探す 文字どおりには成功でも、人間があとから「そういう意味ではない」と判断しそうな状態がないか確認します。

候補の中に、結果を大きく左右する選択が残っていれば、そこでAIは人間に確認します。

ここでの確認は、「分からないことを全部聞く」ためではありません。AIだけで決めるべきではない判断を、人間へ戻すためです。

人間が決める

  1. 今回目指す成功状態を選ぶ AIが並べた候補を読み、「これは違う」「これは近い」と比較し、今回目指す状態を人間が選びます。
  1. 選んだ状態を目標として固定してから計画する 成功状態が決まったあとで、初めて実行計画を作ります。
指示
  ↓
AIが成功状態の候補を整理する
  ↓
暗黙条件・望ましくない候補を確認する
  ↓
重要な不確実性があれば人間へ確認する
  ↓
人間が成功状態を選ぶ
  ↓
選ばれた状態を目標として固定する
  ↓
計画
  ↓
実行
  ↓
検証

なぜ複数の候補を出すのか

候補が一つだけでは、比較して「これは違う」と気づくことができません。一方、候補が多すぎれば、今度は人間が確認する負担が増えます。

そのため、最初は3〜5個程度を目安にします。

3〜5個という数に特別な意味があるわけではありません。比較できるだけの候補を出しつつ、人間がきちんと読める範囲に収めるための目安です。

必要な候補が少なければ、無理に数を増やす必要はありません。

人間が判断するための材料として、AIに複数の候補を出すよう、こちらから依頼することもできます。

ただし、「必ず5個」「極端な案を必ず入れる」と強く指定すると、AIがその条件を満たそうとして、数合わせの候補や、元の目的から外れた案まで出してくることがあります。

候補を増やすこと自体が目的ではないので、数をそろえることより、元の指示から自然に考えられる候補を優先します。

また、AIとのやり取りが日常化すると、回答の途中に並ぶ提案や前提を軽く読み流してしまうこともあります。

この方法では、候補を出してもらうだけでなく、人間がそれを読み、比べ、元の目的から外れていないか確認するところまでが一つの作業です。

実際に入力するなら

計画を作る前に、この指示から考えられる「成功した状態」をいくつか挙げてください。
目安は3〜5個ですが、無理に数を満たす必要はありません。

元の指示から自然に考えられる範囲で、指示自体は満たしていても、
私が望んでいない可能性がある候補があれば含めてください。
極端な候補を無理に作る必要はありません。

それぞれについて、現状のサービスやデータ、管理手段など、
暗黙に損なってしまうものがないか確認してください。

まだ実行方法は考えず、
成功状態の候補を提示したところで止まってください。

ここで「何を成功と呼ぶか」と「目標」は別々のものではありません。

前者は目標を決めるために候補を探して選ぶ段階であり、その結果選ばれた成功状態が、後続の計画で使う目標になります。

7. この方法が本当に有効かは、まだ分からない

ここは、研究で確認されていることと、この記事の提案を分ける必要があります。

Specification Gaming、underspecified instruction、implicit user intention、実行前のclarificationといった周辺問題には、すでに研究の蓄積があります。

また、複数の候補を意図的に生成させることに近い研究もあります。

LLMに複数候補を一度に列挙させたり、すでに出た候補を見ながら追加させたりすることで、通常の独立した生成より、多様な候補を得られることが報告されています。[6]

一方、人間が確認工程に入れば、それだけで問題が解決するわけでもありません。誤ったAI提案を修正する負担が増えると、修正されにくくなることを示した実験もあります。[7]

ただし、これらは本稿で提案する方法そのものを検証した研究ではありません。本稿の提案は、確立済みの標準手法ではなく、既存研究を背景にした実務上の仮説です。

実際に望ましくない結果を減らせるのか、単にAIに長く考えさせた効果なのか、不要な制約や確認を増やさないかは、別途検証する必要があります。

8. OSIIXの既存記事より、さらに手前の話

OSIIXではこれまで、AI補助作業について、Source of Truth、作業範囲、Approval Boundary、Verification Boundary、失敗コストに応じた検証、Recovery Scope Controlなどを扱ってきました。

これらは主に、目標が定まった後に「どこまで行うか」「どこで止めるか」「何を確認するか」を扱うものです。

今回の話は、その一段手前にあります。

指示
  ↓
成功状態を探索・選択する
  ↓
目標
  ↓
作業範囲
  ↓
実行
  ↓
検証

作業範囲を守り、検証にも成功していても、最初に選んだ目標が人間の意図と違っていれば、AIは望んでいない目的地へ正しく進むことができます。

だから作業範囲や検証を考える前に、何を成功と呼ぶのかを決める段階があります。

9. まとめ

AIの厄介な失敗は、明らかな誤答だけではありません。

仕事そのものはきれいに完了しているのに、人間があとから「そういう意味ではなかった」と気づくことがあります。

それは、AIが指示を無視した結果とは限りません。書かれた条件には忠実だったものの、書かれていなかった人間の期待を守れなかったのかもしれません。

だから重要な仕事では、「どうやるか」を考えさせる前に「何を成功とするのか」を確認する。

そして「どう失敗するか」だけでなく、指示を満たしていても望ましくない結果になる場合も考えてみる。

AIに候補を出してもらうことはできます。しかし、その候補をどう評価し、どれを選ぶかまでAIに任せる話ではありません。

出発したあとに監視するだけでなく、出発前に目的地を確認する。

AIと働くとき、その一手間が重要になる可能性があります。

参考文献

参考文献・資料

  1. Victoria Krakovna, Jonathan Uesato, Vladimir Mikulik, Matthew Rahtz, Tom Everitt, Ramana Kumar, Zac Kenton, Jan Leike, Shane Legg. “Specification gaming: the flip side of AI ingenuity.” Google DeepMind, 21 April 2020. https://deepmind.google/blog/specification-gaming-the-flip-side-of-ai-ingenuity/
  2. Dylan Hadfield-Menell, Smitha Milli, Pieter Abbeel, Stuart Russell, Anca Dragan. “Inverse Reward Design.” arXiv:1711.02827, 2017. https://arxiv.org/abs/1711.02827
  3. Cheng Qian, Bingxiang He, Zhong Zhuang, Jia Deng, Yujia Qin, Xin Cong, Zhong Zhang, Jie Zhou, Yankai Lin, Zhiyuan Liu, Maosong Sun. “Tell Me More! Towards Implicit User Intention Understanding of Language Model Driven Agents.” Proceedings of ACL 2024, pp. 1088–1113. DOI: 10.18653/v1/2024.acl-long.61. https://aclanthology.org/2024.acl-long.61/
  4. Xuan Zhang, Yang Deng, Zifeng Ren, See-Kiong Ng, Tat-Seng Chua. “Ask-before-Plan: Proactive Language Agents for Real-World Planning.” Findings of EMNLP 2024, pp. 10836–10863. DOI: 10.18653/v1/2024.findings-emnlp.636. https://aclanthology.org/2024.findings-emnlp.636/
  5. Zimo Ji, Zekai Zhang, Congying Xu, Zongjie Li, Yudong Gao, Shuai Wang, Shing-Chi Cheung. “Coding Agents Are Guessing: Measuring Action-Boundary Violations in Underspecified DevOps Instructions.” arXiv:2607.02294, submitted 2 July 2026. 査読前プレプリント. https://arxiv.org/abs/2607.02294
  6. Sergey Troshin, Irina Saparina, Antske Fokkens, Vlad Niculae. “Asking a Language Model for Diverse Responses.” Proceedings of the 2nd Workshop on Uncertainty-Aware NLP (UncertaiNLP 2025), pp. 66–72. Association for Computational Linguistics, 2025. DOI: 10.18653/v1/2025.uncertainlp-main.8. https://aclanthology.org/2025.uncertainlp-main.8/
  7. Jacob Beck, Stephanie Eckman, Christoph Kern, Frauke Kreuter. “Bias in the Loop: How Humans Evaluate AI-Generated Suggestions.” Harvard Data Science Review, Issue 8.2, Spring 2026. Published 30 April 2026. DOI: 10.1162/99608f92.0e98898d. https://hdsr.mitpress.mit.edu/pub/nrcn4h7d/release/2