なぜ回答範囲を制限した方がよいのか

種別：設計原則 / 選択的予測 / 評価方法適用対象：RAG、QAチャット、コード生成、AIエージェント対象工程：範囲判定 / 生成 / 回答拒否 / 移管 / 評価

前ページでは、ハルシネーションを次の三段階で制御しました。

誤答を生成しにくくする
誤答を検出する
誤答を採用・実行しない

このうち、生成前と回答時の両方に関係するのが回答範囲の制限です。

ただし、「範囲を狭めればAIが迷わなくなり、必ず正しくなる」という意味ではありません。

回答範囲を制限するとは、AIが回答してよい条件を定義し、条件外では回答しないようにすることである。

重要なのは、回答の自由度を小さくすること自体ではありません。

評価可能な領域だけをAIへ担当させることです。

「回答範囲」には複数の境界がある

回答範囲という言葉は、話題の範囲だけを指すように見えます。

実務では、少なくとも次の境界を分けて設計します。

境界	定義例
対象	製品Aに関する質問だけ
時点・版	現行バージョンだけ
根拠	承認済みの仕様書だけ
入力条件	製品名・版・エラーコードが揃っている
行為	回答案の生成まで。本番操作はしない
利用者・権限	閲覧権限のある情報だけ

例えば「Javaについて回答する」という定義だけでは広すぎます。

実務のコード生成なら、次のような定義が必要です。

対象     : このリポジトリの保守
実行環境 : Java 17 / Spring Boot 3.3
根拠     : 現行コード、承認済み設計書、公式API仕様
依存関係 : 既存の依存ライブラリだけ
出力     : 差分案、影響箇所、テスト観点
禁止     : 未承認ライブラリの追加、本番反映
停止条件 : 仕様と実装が矛盾する、必要なテストが実行できない

これで初めて、「このAIは何に答えるシステムなのか」を評価できます。

範囲制限は、モデルの確率空間を単純に小さくすることではない

言語モデルは、入力 $X$ とコンテキスト $C$ などを条件として、出力 $Y$ の確率分布を形成します。

P(Y \mid X,C,I,M,D)

ここで、回答候補全体を $\Omega$ 、業務上有効な回答の集合を $V \subseteq \Omega$ とします。

制約 $C$ を与えたときに有効な回答が出る確率は、概念的には次のように表せます。

P(Y \in V \mid X,C) = \sum_{y \in V} P(Y=y \mid X,C)

適切なコンテキストや制約は、確率質量を有効な回答へ寄せる可能性があります。

しかし、候補の数を減らしただけで、この確率が必ず上がるわけではありません。

必要な正解まで禁止した
古い仕様を正として与えた
制約同士が矛盾した
対象外の質問を対象内と誤判定した

この場合、制約が強くても回答は誤ります。

したがって、「範囲を狭めるほど正確になる」は一般法則ではありません。

より正確には、次のように整理できます。

正解と検証基準が存在する領域を定義し、その領域へ回答を限定すると、品質を測定し制御しやすくなる。

また、プロンプトによる指示はモデルの条件付き分布を変えるソフトな制約です。

許可リスト、JSON Schema、型検査、権限制御のように、条件外の出力や実行を機械的に拒否するものはハードな制約です。

両者を同一視しないことが重要です。

回答するかどうかを、生成とは別に設計する

入力の全集合を $\mathcal{X}$ とします。

そのうち、必要な根拠と検証手段が揃っており、AIに回答させる領域を $S \subseteq \mathcal{X}$ とします。

回答可否を決める関数を、次のように置きます。

g(x)= \begin{cases} 1 & x \in S \text{ かつ回答条件を満たす} \\ 0 & \text{それ以外} \end{cases}

$g(x)=1$ のときだけ回答し、 $g(x)=0$ のときは追加質問、回答拒否、人への移管を行います。

入力
  ↓
対象領域か
  ├─ いいえ → 回答しない
  └─ はい
       ↓
必要な情報と根拠が揃っているか
  ├─ いいえ → 追加質問または人へ移管
  └─ はい → 生成・検証・回答

これは、機械学習でいう選択的予測またはreject optionに近い考え方です。

モデルに常に答えさせるのではなく、条件を満たす入力にだけ予測を返します。

回答率と誤答率は分けて測る

AIが回答した割合をCoverageとします。

Coverage = E[g(X)] = P(g(X)=1)

回答したものの中での損失をSelective Riskとします。

損失関数を $L(f(X),Y)$ とすると、

Selective\ Risk = \frac {E[L(f(X),Y)g(X)]} {E[g(X)]}

これは、回答した案件だけに条件付けた平均損失です。

回答条件を厳しくすれば、一般にはCoverageが下がり、Selective Riskを下げられる可能性があります。

ただし、両者の関係は実測が必要です。

設計	Coverage	Selective Risk	起きやすい問題
ほぼ必ず回答する	高い	高くなり得る	対象外にも答える
条件付きで回答する	中程度	抑えやすい	回答可否判定が必要
厳しく拒否する	低い	低くなり得る	使える質問まで拒否する

目標は回答率を最大化することではありません。

業務上許容できるリスクを満たしながら、必要なCoverageを確保することです。

境界判定にも二種類の誤りがある

回答範囲を定義しても、入力が範囲内かどうかを完全には判定できません。

特に見るべきなのは、次の二種類です。

False Accept

本来は対象外なのに、回答してしまう誤りです。

P(g(X)=1 \mid X \notin S)

例えば、廃止済みバージョンの質問に現行仕様で回答する場合です。

False Reject

本来は対象内なのに、回答を拒否する誤りです。

P(g(X)=0 \mid X \in S)

こちらは安全側の失敗に見えますが、多すぎると利用者はシステムを使わなくなります。

したがって、回答内容の正誤だけでなく、回答可否の判定そのものも評価対象です。

コード生成では「自由度」より「適合条件」を定義する

既存システムへ例外処理を追加する場面を考えます。

次の依頼だけでは、AIは一般的に妥当そうな実装を返せても、このプロジェクトで正しいとは限りません。

通信エラー時のリトライ処理を書いてください。

実務上必要なのは、例えば次の条件です。

リトライ対象となる例外
最大回数と待機方式
二重実行を防げる処理か
既存の共通部品を使うか
ログへ残す項目
タイムアウトとの関係
テストで確認すべき異常系

ここでAIの役割を、次の範囲へ限定します。

許可:
- 現行コードから関連箇所を抽出する
- 既存の実装方式に沿った差分案を作る
- 影響箇所とテスト観点を列挙する

禁止:
- 仕様不明の条件を補完して確定する
- 未承認の依存ライブラリを追加する
- テスト未実行のコードを本番へ反映する

停止:
- リトライ対象の例外が仕様化されていない
- 二重実行の安全性を確認できない
- 既存実装と設計書が矛盾している

この設計の目的は、AIの創造性を下げることではありません。

人間が正しさを検証できる成果物だけを生成・採用することです。

ソフトな制約とハードな制約を使い分ける

自然言語で「してはいけない」と書くだけでは、確実な禁止になりません。

制約は、実装位置によって強さが異なります。

種類	例	性質
プロンプト	公式資料にないことは答えない	モデルが従わない可能性がある
検索	承認済み文書だけを取得する	参照範囲を制限できる
出力検証	Schema、型、静的解析、テスト	条件違反を検出できる
Tool制御	許可したAPIだけ公開する	実行可能な行為を制限できる
権限制御	読み取り専用、本番権限なし	危険な実行を遮断できる
人間承認	高影響処理を承認待ちにする	責任ある判断を分離できる

高い影響を持つ処理ほど、プロンプトだけに依存せず、モデルの外側で制約します。

回答範囲と実行権限も分けます。

AIが「実行案を回答できる」ことと、「その操作を実行できる」ことは同じではありません。

評価データには範囲外の質問も入れる

対象内の質問だけで評価すると、回答範囲の設計は検証できません。

評価データは少なくとも次の四種類へ分けます。

評価区分	期待する動作
対象内・情報十分	根拠に沿って回答する
対象内・情報不足	追加質問または保留する
対象外	回答を拒否または移管する
境界・曖昧	対象を確認してから処理する

その上で、次を測ります。

Coverage
Selective Risk
False Accept率
False Reject率
根拠の支持率
人への移管後に完了できた割合

回答範囲は、仕様書に一度書いて終わりではありません。

利用ログと失敗事例から、境界を継続的に修正します。

結論

回答範囲を制限する目的は、単にAIの候補を減らすことではありません。

AIが回答してよい領域、回答に必要な条件、回答してはいけない境界を定義する。

これにより、回答した領域での誤りを測り、対象外の入力を拒否し、危険な実行をモデルの外側で止められます。

ただし、範囲を狭めても正しさは保証されません。

範囲内では根拠と検証が必要であり、範囲外を正しく検知できるかも評価しなければなりません。

対象領域を定義する
        ↓
回答条件を定義する
        ↓
回答・拒否・移管を分ける
        ↓
範囲内の品質と境界判定を測る
        ↓
実行権限を別に制御する

AIへ何でも答えさせることが、AIの能力を最大限に使うことではありません。

正しさを評価できる範囲へ役割を限定し、その外側では答えない仕組みを持たせること。

それが、回答範囲を設計する理由です。

参考資料

Yonatan Geifman, Ran El-Yaniv, Selective Classification for Deep Neural Networks, NeurIPS 2017
Yonatan Geifman, Ran El-Yaniv, SelectiveNet: A Deep Neural Network with an Integrated Reject Option, ICML 2019
Dan Hendrycks, Kevin Gimpel, A Baseline for Detecting Misclassified and Out-of-Distribution Examples in Neural Networks, ICLR 2017
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, 2024