コンテンツへスキップ
スマートくらし
AI・テック

AIは答える前に止まれるか——行政電話・医療診断・コーディングから作る「聞き返し票」

AIの性能を正答率だけで測ると、曖昧な依頼に答え続ける危険を見落とします。行政電話、医療診断、DevOpsの三つの事例から、答える・聞き返す・人へ渡す境界を一枚にします。

【PR】当サイトはアフィリエイト広告(Amazonアソシエイト含む)を掲載しています。

📋目次

AI窓口の評価では、何件を自動回答できたかが最初に注目されます。しかし、相談者の言葉が曖昧なとき、必要な情報が足りないとき、答えを間違えると生活や業務へ大きな影響が出るときには、回答数を増やすほどよいとは限りません。

2026年10月に報じられた東京都大田区のAI電話実証、Microsoftの医療診断システム、曖昧なDevOps指示に対するコーディングAIの研究は、用途も利用者も異なります。それでも三つに共通する問いがあります。AIは「答えられない」と判断し、必要なことを聞き返し、状況を失わず人へ渡せるでしょうか。

この記事では、正答率や削減時間とは別に、止まる能力を測る「聞き返し・引き継ぎ票」を提案します。これはAIを使わないための表ではありません。AIが得意な定型処理を広げながら、解釈、診断、変更実行の責任を適切な人へ戻すための運用表です。

AIへの相談内容と人への引き継ぎ条件を同じ画面で確認するチーム

結論——回答率の隣に「正しく止まれた率」を置きます

日本の企業や自治体がAI窓口を導入するときは、次の三つを分けて測る必要があります。

  • 答えてよい範囲で、正しい情報を返せたか
  • 情報不足や曖昧さを見つけ、必要な質問を返せたか
  • 判断や実行を人へ渡す際、相談者に同じ説明を繰り返させなかったか

第一の数字だけを見ると、AIが何でも答えることを成功と誤認しやすくなります。第二と第三を加えると、AIは「自動回答装置」ではなく、定型情報を案内し、足りない条件を集め、専門家へ整えて渡す入口になります。

これは、複数のAI案件を同時に走らせる際に確認待ちの上限を決めた「同時稼働予算」の考え方ともつながります。AIが出力した時点を完了にせず、回答を受け入れるか、人へ戻すかが決まった時点を完了にします。

大田区のAI電話は、範囲を狭めることで次の実証へ進みました

大田区は2025年度、防災危機管理課で感震ブレーカーや家具転倒防止器具の支給要件に関するAI電話の実証を行いました。当初は職員対応の80%削減を目標にしましたが、AIによる有効対応率は約40%でした。

この差は、単にモデルが弱かったという話ではありません。住民が用件を明確な一文にできるとは限らず、言葉に詰まることもあります。声が小さい場合や複数人が同時に話す場合もあります。人なら曖昧な表現から意図を探り、質問の順番を変えられますが、AIでは聞き返しが連続し、途中で通話を終えられる場面がありました。

重要なのは、大田区が40%を失敗として捨てず、ログから難しさの構造を見つけたことです。2026年度は、年間約1000時間の電話対応がある建築審査課へ対象を移し、300時間の削減を目標にしました。同時に、AIが答える範囲を「まちマップおおた」で公開されている用途地域、建ぺい率、指定道路など、解釈の余地が小さい客観情報へ限定しました。

一方、「この規定が今回の建築計画へ適用されるか」のように個別判断を伴う質問は対象外です。想定問答へ俗称、専門用語、異なる言い回しをひも付けても、AIが解釈者になるわけではありません。言葉の入口を広げながら、判断の出口は狭く保っています。

この設計から学べるのは、自動化率を上げる前に、質問を三種類へ分けることです。

質問の種類AIの役割人の役割
公開情報の所在や客観値情報を探し、取得時点と対象を示す元情報と更新責任を管理する
条件が不足した質問不足項目を一つずつ聞き返す質問順と中断条件を決める
解釈・例外・個別判断判断を作らず、担当窓口へ渡す制度、事情、影響を踏まえて判断する

「分かりません」と切るだけでは、利用者は別の窓口で最初から説明し直します。住所、対象制度、確認済みの公開情報、聞き取れなかった項目を引き継げれば、自動化の失敗を相談の入口へ変えられます。

医療AIの高い正答率も、現場への引き継ぎなしでは完成しません

Microsoftは、複数のAIエージェントが症状や病歴を検討し、必要な検査を選び、診断候補へ到達する「Diagnostic Orchestrator」を報告しました。The Vergeによると、New England Journal of Medicineの症例を使った評価では、同システムの診断精度は約83%でした。資料を使える一般医は約36%、資料なしでは約22%とされています。

救急部門の過去データを使った別の評価でも、AIは80%、医師の平均は47%と報じられました。さらに、AIは推定検査費用を抑える傾向を示しました。これらは、単発の回答ではなく、質問と検査を順序立てる仕組みに価値があることを示します。

ただし、評価は過去の症例と記録を使ったものです。Microsoft側も臨床での確認が必要だと認め、病院環境での試験を計画しています。実際の患者には、記録に残らない痛みの表現、服薬の抜け、生活背景、急な状態変化があります。検査を注文できることと、患者が今すぐ救急を受診すべきかを安全に伝えることも同じではありません。

医療現場でデジタル記録と複数の判断材料を照合する担当者

医療で見るべきなのは、AI対医師の勝敗だけではありません。少なくとも次の境界が必要です。

  1. 入力された症状と病歴に不足があると気付けるか
  2. 追加質問や検査の理由を、患者と担当者が追えるか
  3. 緊急性が高い可能性を、平均的な診断精度とは別に扱えるか
  4. AIの候補、反対材料、未取得情報を医療者へ渡せるか
  5. 最終判断者と連絡先が患者に明確か

AIが候補を高精度で絞れても、引き継ぎ時に「AIがこの病気だと言った」という一文しか残らなければ、医療者は調査を最初からやり直します。何を聞き、何を除外し、どの不確実性が残ったかを渡すことが、診断精度を現場の価値へ変えます。

コーディングAIは、曖昧でも止まらず作業する場合があります

行政電話や医療相談では、AIが回答を返します。コーディングAIでは、回答がファイル削除、配備、通信切り替え、監視設定の変更として実行される場合があります。そのため、聞き返さない問題は文章の誤りより大きな影響を持ちます。

香港科技大学などの研究チームが2026年7月に発表したUnderspecBenchは、実際の障害報告を基に、曖昧なDevOps指示へAIがどう反応するかを調べました。ITmedia NEWSの紹介によると、不明点を質問する割合はモデルによって大きく異なり、あるモデルでは1.7%、別のモデルでは38.3〜44.5%でした。

実際に行動した事例の55.8〜67.8%では、誤った対象を操作したり、意図より広い範囲を変更したりするミスがありました。必要以上に広い操作が起きた割合は、配備やトラフィック制御で59.8%、インフラ設定や監視で77.2%と報告されています。

これらは特定のベンチマーク、ツール、モデル、指示条件で得られた結果であり、すべての開発AIへそのまま当てはめる数字ではありません。それでも、影響範囲が大きい仕事ほど自動的に慎重になるとは限らない、という設計上の警告になります。

変更対象と実行結果を分けて確認する開発作業画面

以前の記事では、AIが入力、閲覧、記憶、実行、送信のどこまで触れるかを「実行経路票」で整理しました。今回の聞き返し票は、その経路を進めてよい条件を追加します。対象、環境、期限、影響範囲、戻し方のどれかが欠けたら、実行経路へ入れず質問へ戻します。

「聞き返し・引き継ぎ票」は八欄で作れます

AI窓口ごとに複雑な規程を最初から作る必要はありません。まず、一つの用事につき次の八欄を用意します。

欄記録する内容
用事利用者が終えたい一件。回答ではなく目的を書く
答えてよい範囲公開値、定型案内、下書きなどAIが完結できる範囲
必須条件住所、対象年月、症状、環境名など回答前に必要な項目
曖昧さの印聞き取り失敗、対象未指定、条件矛盾、複数解釈
聞き返す質問一度に一項目だけ確認する具体的な問い
停止条件緊急性、個別判断、外部変更、本人確認不足など
引き継ぐ記録利用者の原文、確認済み事実、未確認項目、AIの操作履歴
受け手と期限担当部署、専門家、承認者、返答または対応の目安

「用事」を先頭に置くのは、AIの返答が目的ではないからです。住民は制度の説明を聞くためではなく、対象かを知って申請を進めるために電話します。患者は病名候補を集めるためではなく、安全な次の行動を決めるために相談します。開発者はコマンドを生成するためではなく、変更を安全に完了するためにAIを使います。

必須条件は、モデルへ自由に推測させず、入力欄として管理します。住所の番地がなければ用途地域を特定しません。本番か検証環境か不明なら配備しません。症状の開始時刻が不明なら、その不足を残したまま確定的な案内へ進みません。

曖昧さの印は、モデル自身の確信度だけにしないことが重要です。音声認識の失敗回数、対象名の候補数、情報源の日付差、利用者による訂正、外部操作の可逆性など、観測できる条件を組み合わせます。

聞き返しは一度に一つ、引き継ぎは一度で済む形にします

AIが慎重になるほど、質問が増え過ぎて利用者が離脱する問題も起きます。そこで、聞き返しには順序を設けます。

最初に、安全や対象を決める条件を聞きます。次に、回答を絞る条件を聞きます。最後に、利便性を高める任意情報を聞きます。最初から十項目を尋ねるのではなく、一つの返答で分岐が大きく変わる質問から始めます。

音声窓口では、同じ質問を二回聞いても認識できなければ、人への接続や別手段を提示します。開発AIでは、対象環境や変更範囲を一回確認し、明示されなければ読み取りと計画作成までに止めます。医療相談では、緊急性を示す条件を先に扱い、一般情報の説明より受診先の案内を優先します。

引き継ぎ時には、長い会話要約だけを渡しません。利用者の原文、AIが確認した事実、未回答の質問、参照した情報、すでに行った操作を分けます。人がAIの推測と利用者の発言を混同しないためです。

30日で試すなら、自動回答率を目標の中心にしません

最初の30日間は、対象を一つの窓口、一つの制度、一つの開発作業へ絞ります。導入手順は次のようにできます。

第1週:実際の曖昧さを集めます

過去の電話、チャット、作業依頼から、聞き取りにくい表現、対象不足、条件矛盾、例外相談を集めます。個人情報を除き、どの追加質問があれば解決できたかを担当者が記録します。

第2週:答える・聞く・渡すを分けます

各事例を、AIが答えてよい、追加質問が必要、人へ直ちに渡す、の三つへ分類します。正解文を増やすより先に、対象外の条件と引き継ぎ先を決めます。

第3週:影響を起こさない環境で試します

実際の利用者へ公開する前に、誤認識、言い直し、複数の対象名、古い資料、緊急語、外部変更を混ぜます。AIがそれらしく答えるかではなく、規定した境界で止まるかを確認します。

第4週:小さく公開し、七つの指標を見ます

見るべき数字は、自動回答率だけではありません。

  • 答えてよい範囲での正答率
  • 聞き返すべき事例で質問できた率
  • 人へ渡すべき事例で止まれた率
  • 不要な聞き返し率
  • 同じ説明を利用者に繰り返させた率
  • 引き継ぎ後に担当者が不足情報を取り直した率
  • 用事が安全に完了するまでの総時間

削減時間は最後に見ます。AIの通話時間が短くても、利用者が再度電話し、職員がログを読み直し、誤案内を訂正すれば、組織全体の時間は減っていません。

調達では「何%答えたか」だけでなく、停止の再現性を買います

AI製品を選ぶ際は、ベンチマークの正答率に加えて、次の質問をします。

  • 必須条件を管理者が項目として設定できますか
  • 音声認識と回答生成のどちらで失敗したかを分けて記録できますか
  • 回答対象外の条件を、モデル更新後も同じように再現できますか
  • 人へ渡すとき、利用者の原文とAIの要約を分離できますか
  • 外部操作は、確認が終わるまで技術的に実行不能にできますか
  • ログの保存先、保存期間、閲覧者、削除方法を設定できますか
  • 誤案内や過剰操作が起きた一件を、後から再生できますか

モデルが「慎重に振る舞う」という説明だけでは足りません。同じ不足条件を入れたとき、毎回同じ地点で止まり、同じ担当へ渡せることを試験します。モデル変更、プロンプト変更、情報更新のたびに、この停止試験を繰り返せることが調達条件になります。

日本では、無人化より「専門家へ届く入口」を先に作れます

人手不足が進む自治体、医療、IT運用では、定型的な確認に専門家の時間を使い続けることも持続的ではありません。だからこそ、AIか人かの二択ではなく、AIが入口を整え、人が例外と判断を引き受ける分業が必要です。

大田区の事例は、対象を客観情報へ狭め、実際の言い回しを学びながら進める方法を示します。Microsoftの研究は、複数の質問と検査を組み合わせるAIの可能性を示す一方、過去症例の成績と臨床運用の間に距離があることも示します。コーディングAIの研究は、曖昧さがあってもAIが自動的に止まるとは限らないことを示します。

三つを合わせると、AI導入の中心は「人を何人減らせるか」ではなくなります。客観情報をどこまで自動化し、何を聞き返し、どの判断を誰へ戻すかを先に決めることになります。

出典

まとめ——AIへ最初に教えるべき答えは「ここで人へ渡します」です

AI窓口を設計するとき、最初に理想の回答文を書くのではなく、答えてはいけない一件を置いてみてはどうでしょうか。必要な条件を聞き、対象外だと説明し、確認済みの情報を失わず担当者へ渡せるでしょうか。

その一件を毎回同じように止められれば、AIの回答範囲を少しずつ広げられます。止められないまま回答率だけを上げれば、曖昧さは利用者と現場へ押し戻されます。AIの賢さを競う前に、正しく質問し、正しく人へ戻る入口を一つ作ることから始めるのが、日本の組織にとって現実的な次の一歩です。

✍️ この記事を書いた人

ス
スマートくらし 編集部

スマートホーム愛好家として 50 台以上の IoT 製品を自宅でテストしてきた実務経験を持つ。HEMS、音声アシスタント、スマートロック、カメラセンサーなど、住まいに関わるあらゆる IoT 機器の導入・運用・比較評価を専門とする。

スマートホームIoTHEMS音声アシスタントAI 家電