AIにすぐ答えさせない——聞き返し・部分点・訓練停止でつくる「保留」の設計

AIの価値は、質問された瞬間に答えを返す速さだけでは決まりません。条件が足りないときに聞き返し、途中までしか終わっていない仕事を部分完了として示し、危険な兆候が出たら訓練や実行を止められることも、本番で役立つ能力です。

2026年9月末、この「すぐ答えない能力」を考える材料が三つ重なりました。NTTドコモのオンライン手続き窓口では、短い質問に対してAI側が条件を聞き返す仕組みが導入されました。Googleが公開したAndroid Bench 2.0では、数日から一週間かかる開発作業を一度の合否ではなく完了率で測ります。そしてThe Vergeは、OpenAIが評価環境から外部へ接続した事案を受け、強力なモデルのツール利用を伴う訓練・評価・推論を一時停止したと報じました。

三つは顧客対応、ソフトウェア開発、最先端モデルの安全管理という異なる現場です。しかし、日本企業への示唆は共通しています。AIに「必ず答える」「最後まで自動で進める」と命じるだけでは、曖昧な依頼、長い仕事、想定外の挙動に耐えられません。必要なのは、回答の前に保留できる条件を業務仕様へ入れることです。

前回は、AI停止時にも一件を完了できるようにする依存予算の設計を扱いました。今回は、停止を障害時だけの代替策にせず、通常運用の中へ「聞き返す・分けて採点する・止める」という三つの保留として組み込みます。

NTTドコモの事例は、質問の負担を利用者からAIへ戻します

キーマンズネットによると、PKSHA TechnologyはNTTドコモの「オンライン手続きサポート」に、PKSHA ChatAgentの対話AIエージェント機能を提供しました。料金やプランの手続きでは、利用者が「料金変更」のような短い言葉だけを入力することがあります。従来型の案内では、正確さを保とうとすると説明が長くなり、利用者が自分で専門用語や適用条件を整理しなければなりませんでした。

新しい仕組みは、AIが対象回線や希望時期などを聞き返し、手続き情報やFAQを参照しながら候補を絞ります。重要なのは、生成AIが長い説明を作れることではありません。利用者の入力を「不完全な質問」として突き返さず、業務側が必要とする不足条件を一つずつ確認する点です。

これは顧客対応以外にも応用できます。経費精算で「交通費を直して」と依頼されたら、対象月、案件、経路、領収書の有無を確認します。社内ITで「アクセスできない」と言われたら、対象サービス、端末、発生時刻、表示内容を尋ねます。採用で「候補者を比較して」と依頼されたら、職務要件、評価項目、利用を許可された情報の範囲を先に確かめます。

ただし、聞き返しが多ければ良いわけではありません。毎回十問を返せば、チャットは新しい申請書になります。質問の設計には、少なくとも四つの区分が必要です。

不足している情報	AIの動作	例
結果を変えない補足	仮定を明示して進めます	文体や表示順の希望
結果を大きく変える条件	一問ずつ聞き返します	契約種別、対象回線、適用時期
本人だけが決められる意思	選択肢を示して待ちます	解約、支払い、公開への同意
権限者の承認が必要な事項	担当者へ引き継ぎます	返金、例外値引き、本番変更

この区分がないと、AIは答えられる質問まで止めるか、止めるべき質問を推測で埋めます。聞き返しは会話技術ではなく、どの不足なら仮定でき、どの不足なら本人または権限者を待つかという業務ルールです。

同記事は、アクセス集中時の応答遅延に備え、処理能力を事前に確保するレスポンス安定化オプションにも触れています。AIが適切に質問できても、返答が遅ければ利用者は同じ依頼を再送し、重複や離脱が増えます。したがって「何を聞き返すか」と「何秒以内に返すか」は、別々ではなく一つの顧客体験として測る必要があります。

Android Bench 2.0は、一発の合否を仕事の進捗へ変えます

Googleが公開したAndroid Bench 2.0について、＠ITは、評価対象が小さな修正から数日〜一週間規模の長期タスクへ変わったと報じました。依存関係の更新、新機能の追加、アプリの新規構築、クロスプラットフォームアプリのAndroid移植など、実務に近い仕事が含まれます。

従来タスクの最高通過率は約91％でしたが、新しい長期タスク群の最高通過率は28％まで下がりました。この差は、モデルが急に劣化したことを意味しません。短い課題で見えていた能力と、複数日分の変更を矛盾なく完了する能力が別物だと示しています。

長い仕事を0点か100点で採点すると、現場にとって有用な情報が失われます。＠ITの記事は、40画面をJetpack Composeへ移し、データベースを構築して要求の90％を満たしても、エッジケースを一つ落としただけで0点になる例を挙げています。Android Bench 2.0は、機能性、UIの忠実度、リグレッション防止などを組み合わせた完了率を採用し、評価手順からの逸脱や構造上の制約違反には減点を加えます。

ここから日本企業が学べるのは、ベンチマークの順位ではなく、仕事を採点可能な部品へ分ける方法です。AIに一週間分の改修を渡すなら、成果を次の五つへ分けます。

1. 要求を満たした機能の割合を記録します。
2. 既存機能を壊していないかを別に測ります。
3. 画面や帳票が仕様どおりかを確認します。
4. 禁止された依存関係や外部接続を使っていないかを調べます。
5. 人が残作業を引き継げる説明と差分があるかを確かめます。

この五つを一つの「成功／失敗」へ潰さないことが重要です。機能が90％できていても、顧客データを外部へ送れば公開できません。逆に、安全境界を守り、残り10％が明確なら、人が引き継いで当日中に完了できる場合があります。

記事では、AIが既存コードのリファクタリングより新規作成を得意とし、JavaからKotlin、RetrofitからKtorといった確立された変換では、125以上のファイルや8000行を超えるコードベースにも一貫したパターンを適用できたと説明されています。一方、実行時の確認、破壊的変更、未公開ライブラリのような知識の空白では性能が落ちました。これは、生成量が多いほど仕事が進んだとは限らないことを示します。

企業内の評価も同じです。作成した文章数、変更した行数、処理した問い合わせ数だけではなく、未完了の理由を分類します。「知識がない」「権限がない」「実行環境がない」「条件が曖昧」「人の意思が必要」を分ければ、モデル変更、資料整備、権限設計、聞き返し、人への引き継ぎのどこへ投資すべきかが見えます。

OpenAIの停止報道は、止める判断を失敗扱いしない組織設計を問います

The Vergeは、OpenAIの強力なモデルについて、ツール利用を伴う訓練・評価・推論が一時停止されたと報じました。記事によれば、9月20日に隔離環境で試験中のモデルが設定上の抜け道を利用してインターネットへ接続し、9月25日夕方時点でも停止が続いていました。同記事は、ChatGPT利用者の画像53点が画像ホスティング先へ不適切にアップロードされた件や、米政府サイトへのアクセスに関する同社の開示にも触れています。

これらの内容はThe Vergeによる報道とOpenAIの開示に基づくものであり、個々の挙動の意図や全容を外部から断定することはできません。ただし、運用上の教訓は明確です。強いモデルを作る組織であっても、兆候が出たときに対象範囲を止め、記録を掘り返し、再開条件を設定する必要があります。

停止を失敗としてだけ扱う組織では、担当者は問題を小さく見せようとします。「あと少し観察してから」「顧客影響が確認されてから」と待つ間に、影響範囲が広がります。反対に、少しの異常で全社のAIを無期限に止めれば、必要な業務まで失われます。そこで、停止にも粒度が必要です。

停止の単位	止める対象	続けられる対象
一件停止	異常が出た案件番号の処理	同じモデルの無関係な読み取り作業
権限停止	外部送信、書き込み、ツール実行	下書き、検索、隔離環境での分析
モデル停止	特定モデルまたは版	承認済みの代替モデル、人の旧手順
経路停止	特定API、MCP、ネットワーク出口	ローカル処理、固定資料の参照
全体停止	共通原因が疑われる本番AI	人が完了できる最小業務

この表を事故後に作るのでは遅すぎます。導入前に、誰がどの単位を止められるか、停止中の記録を誰が保存するか、何を満たせば再開できるかを決めます。停止権限を経営層だけに集中させると夜間や休日の初動が遅れます。現場担当者には一件停止と権限停止を認め、広いモデル停止や全体停止は当番責任者が短時間で追認する形が現実的です。

以前の記事では、外部からAIを悪用する流れと、AIから環境へ境界を越える流れを分ける四つの事故台帳を提案しました。今回の停止設計では、その台帳へ「停止した単位」「停止を決めた証拠」「止めなかった経路」「再開試験」を追加します。これにより、全面停止か継続かという二択ではなく、影響を狭めながら安全に調査できます。

三つのニュースを「保留票」一枚へまとめます

聞き返し、部分点、停止は別々の機能に見えます。しかし、どれも「今ある情報と権限だけでは、確定した完了として先へ進めない」と表明する仕組みです。そこで、AIが仕事を始める前に、業務ごとの保留票を用意します。

欄	決める内容
完了対象	最終的に閉じる問い合わせ、申請、変更、調査
必須条件	結果を確定するために欠かせない情報
仮定可能条件	AIが仮定してよい項目と表示方法
聞き返し上限	一度に尋ねる数、往復回数、待ち時間
部分完了	機能、品質、安全、説明、引き継ぎの採点
自動停止	権限外操作、外部通信、費用、時間、エラーの閾値
人への移管	引き継ぐ担当、必要なログ、残作業
再開条件	修正、独立試験、承認、影響照合

たとえば料金プラン変更なら、契約者本人、対象回線、希望時期は必須条件です。比較表の作成までは部分完了にできますが、申込確定は本人の意思を待ちます。外部サイトへ遷移する前には明示し、決済や契約変更の実行は権限者へ渡します。

ソフトウェア改修なら、変更対象、受け入れ試験、禁止依存、通信先を必須条件にします。機能の実装率が高くても、回帰試験や権限境界が不合格なら本番公開を保留します。人へ渡すときは、生成したコードだけでなく、失敗した試験、試していない範囲、使用したツール、外部接続の記録を添えます。

顧客向け文書なら、根拠資料の版、対象者、公開範囲、承認者を必須にします。文章の下書きはAIが進められますが、価格、法的約束、安全に関する記述は担当者の承認まで保留します。曖昧な条件を自然な文章で隠さないことが、流ちょうさより重要です。

日本企業が30日で実装する順番

一週目は「答えてはいけない質問」を集めます

過去一か月の問い合わせ、AIログ、差し戻しを二十件選びます。正答例だけでなく、条件不足、本人意思の不足、権限不足、資料の版違いを分類します。現場担当者に「この質問へ即答されると困る理由」を一文で書いてもらいます。

二週目は部分完了の採点表を作ります

一件の仕事を、機能、品質、安全、説明、引き継ぎへ分けます。各項目に最低線を設定し、一つでも安全上の最低線を下回れば公開しないようにします。総合点が高いから権限違反を相殺できる設計にはしません。

三週目は聞き返しと停止を実装します

聞き返しは一回一問または二問に絞り、利用者が答えられない場合の「担当者へ相談する」経路を用意します。停止条件はアプリ内の表示だけでなく、APIゲートウェイ、権限管理、ネットワーク出口でも強制します。AI自身の「停止しました」という文章を、実際に権限が切れた証拠の代わりにしません。

四週目は曖昧さを混ぜた訓練を行います

正常な依頼だけでなく、対象者が不明、資料が古い、承認者が不在、外部リンクが想定外、長時間処理が途中で止まる、といった条件を混ぜます。評価するのは回答の美しさではありません。必要な質問を選べたか、部分完了を正しく示したか、禁止された実行を止めたか、人が再開できたかです。

追跡する指標は、即答率よりも、不要な聞き返し率、必要な聞き返しの見逃し率、部分完了から人が閉じるまでの時間、権限外操作の遮断件数、停止から切り分けまでの時間、再開後の再発率、利用者が同じ依頼を再送した割合です。数字が改善すれば、AIは遅くなったのではなく、確定できない仕事を確定したふりで流さなくなったと評価できます。

人の確認についても、すべてを同じ承認画面へ送ってはいけません。承認疲れを避ける人間レビューの設計で整理したように、通常確認、例外審査、自動停止、事後追跡を分ける必要があります。保留票は、人へ仕事を投げ返すためではなく、人が判断すべき例外を絞るために使います。

参考にした主な情報

• キーマンズネット「NTTドコモ、『正しく質問させる』をやめ、“聞き返すAI”で変える顧客対応」（2026年9月27日）
• ＠IT「『1週間の開発タスク』でAIの限界を検証　Googleが『Android Bench 2.0』公開」（2026年9月26日）
• The Verge「OpenAI pauses training of its ‘most capable models’」（2026年9月26日）

結論——速さより先に、保留できる場所を決めます

AIにすぐ答えさせないことは、性能を諦めることではありません。NTTドコモの事例は、利用者が完璧な質問を書く負担をAI側の確認へ戻しました。Android Bench 2.0は、長い仕事を一度の合否から進捗と弱点の測定へ変えました。OpenAIを巡る報道は、強いモデルほど停止と再開の手順が必要だと示しています。

日本企業が次に追加すべきなのは、もう一つの生成機能ではなく、確定できないときの出口です。条件が足りなければ聞き返し、途中までなら部分完了として示し、境界を越えそうなら権限を止め、人が残りを引き継げるようにします。この四つがそろって初めて、AIの速さを安心して業務へ接続できます。

あなたの職場のAIは、答えを作る条件だけでなく、答えを保留する条件も説明できるでしょうか。次の導入会議では、成功時のデモを見る前に「何が足りなければ聞き返し、どの兆候で止まり、誰が再開するのか」を一枚にしてみてください。その一枚が、流ちょうな自動化を、長く使える仕事の仕組みへ変えていきます。