- 公開日
AIが回答範囲を超えたら、止める対象を具体的に示し、確認できた説明は残します。そのためには「どの業務について答えるか」だけでなく、使える資料、判断してよい事項、実行できる操作を先に定めておきます。情報が足りないための保留と、権限がないための停止を区別すると、利用者も次に何をすればよいか分かります。
例えば経費規程の説明ができても、支払いの可否を確定したり、振込先を更新したりできるとは限りません。同じ「経費」という話題の中でも、説明から個別判断、外部操作へ移るところに境界があります。話題が一致していることだけを理由に、依頼の続きを実行しない設計が必要です。
回答範囲は、資料・判断・操作に分けて書く
範囲を「経費の質問に答える」とだけ定めると、規程の要約、個別案件の承認、口座情報の変更が一つに見えてしまいます。次のように、回答の根拠と実施できることを分けて記述します。
以下は架空の企業の経費案内AIを設計する例です。実在する規程やサービスの仕様ではありません。AIには現行と確認された「経費案内A版」と正式な問い合わせ先一覧だけが与えられ、個人別の支払い状況や口座登録情報は参照できないとします。
| 範囲 | この例で認めること | 越えてはいけない境界 |
|---|---|---|
| 説明 | 提供された規程の申請手順を要約する | 記載のない期限や例外を作らない |
| 個別判断 | 判断に必要な資料と確認先を案内する | 支払可否、本人確認の完了、反映日を確定しない |
| 操作 | 質問事項や申請文の下書きを作る | 口座登録の変更や送信を実行しない |
| 入力 | 承認された資料の範囲で質問を受ける | 案内に不要な口座番号や認証情報を集めない |
この定義は利用者向け表示と、AIの指示、使える機能の設定で対応させます。画面に「案内専用」と書いても、裏側で更新ツールを自由に呼べるなら、表示と構成が食い違います。設計変更で新しい操作を加えるときは、範囲の記述だけでなく、権限と確認方法も見直します。
NIST AI RMF 1.0のCoreは、MAP 2.2でAIシステムの知識の限界と、出力を人がどう使い監督するかを記録すること、MAP 3.3で対象とする適用範囲を定めて記録することを挙げています。NISTは任意利用の枠組みと説明しています。上の表は、その観点を経費案内へ落とした設計例であり、NISTが指定する定型様式ではありません。
「説明して」から「変更して」への移行を捉える
架空の経費案内A版には、次の三点が書かれているとします。
- 経費申請には領収書を添付し、所属長の承認を受ける
- 支払いには登録済みの振込先を使用する
- 振込先の変更は正式な変更窓口で申請し、担当者の確認を受ける
反映までの日数、次回の支払い日、本人確認に必要な個別書類は、この資料からは確認できません。正式な問い合わせ先一覧では、変更窓口が経理チームに対応付けられているとします。
最初の依頼が「経費の申請手順を教えて」であれば、領収書と所属長承認を説明できます。その後「では振込先を変えて、次回から新しい口座に入るようにして」と続いた場合、依頼は説明から登録更新と反映結果の確約へ広がっています。元の話題の続きでも、最初に定めた範囲を越えています。
兆候は特定の単語だけで判断しません。「変更方法を説明して」は説明の依頼ですし、「前の口座では困るので、そちらで済ませて」は「変更」という語がなくても操作を求めています。対象、求める結果、外部状態を変える必要があるかを見て、依頼の動作を捉えます。
個別の支払日を断言する、本人と確認せず登録情報を使う、送付先が不明なまま担当者へ送る、といった移行も確認点です。AIが不足を埋めるために新しい個人情報を求め始めた場合は、その情報が今の案内に必要で、収集してよいものかを先に確かめます。
同じ依頼への回答を、状態が分かる形へ直す
よくない回答例は、「変更しました。次回の支払いから反映されます」です。ここには更新を行ったという報告と、反映時期の確約が混ざっています。この例のAIは更新権限も結果を照会する機能も持たないため、どちらも裏付けられません。
範囲に沿って修正すると、次のようになります。
「この窓口では経費規程の説明はできますが、振込先の変更は行えません。規程では、正式な変更窓口への申請と担当者の確認が必要です。反映時期と次回の支払いへの適用は、手元の資料では確認できません。経理チームの正式な変更窓口で、申請方法と適用時期を確認してください。ここへ口座番号を入力する必要はありません。」
この回答で止めたのは口座更新です。申請手順の説明は続けています。もし回答形式に状態を付けるなら、次のように意味を固定すると、言葉だけが独り歩きしにくくなります。
| 状態 | この例で言えること | 使い方の条件 |
|---|---|---|
| 確認済み | A版には変更窓口への申請と担当者確認が必要とある | 資料の記載を確認した事実。個別案件の処理完了を意味しない |
| 推定 | 利用者は次回の支払い前に変更を済ませたいと考えられる | 依頼から読んだ意図の推定。期限や反映日を推定しない |
| 未確認 | 反映日、次回の支払いへの適用、当人の登録状況 | 資料・照会結果を入手するまで確約しない |
推定を残す価値がなければ、利用者向けの回答では省いて構いません。すべての回答を三分類で埋めることが目的ではないからです。ただし、引き継ぎで「次回前の変更が必要」と確定事項に変えるなら、本人の希望と実際の締切を取り違えます。「次回への適用を希望している」と依頼内容を保ちます。
停止するときは、対象と理由、次の確認を残す
単に「対応できません」と返すと、規程の説明まで使えないのか、追加情報があれば進めるのかが分かりません。停止の記録には、止めた操作、理由、確認済みの範囲、不足情報、確認先を残します。引き継ぎに必要のない個人情報を増やす必要はありません。
この例の引き継ぎ用下書きは、「経費規程の説明後、利用者から振込先変更と次回支払いへの適用希望があった。案内AIでは更新していない。規程A版に正式窓口での申請・確認が必要とある。反映時期と登録状況は未確認。経理チームの変更窓口で確認をお願いしたい」とまとめられます。口座番号そのものを一般の引き継ぎ文へ載せることは避け、必要な情報は正式な受付で扱います。
「更新していない」と書けるのは、この設計では更新機能を持たず、更新処理を実施していない前提だからです。実際のシステムで更新要求をすでに送って応答が不明になったなら、「更新結果は未確認」と書きます。停止を宣言しても、先に送った要求が取り消されたことにはなりません。その場合は追加の変更要求を送らず、担当者が状態を照会します。
下書きの作成は、経理チームへ送ったことも意味しません。送信機能がある環境でも、送信先、共有内容、実行の承認を別途確認します。許可された範囲の回答を残すことと、別の人やシステムへ処理を移すことを分けて扱います。
文言だけで止めず、再開条件まで確かめる
AIには「規程の説明と確認事項の整理までを行い、口座の登録・変更は実行しない。資料にない反映時期は未確認とし、確認済みの窓口を案内する」という指示を与えられます。差し替えるのは、対象規程、許可する説明範囲、扱わない操作、正式な確認先です。口座変更以外の業務へ使うときも、この四点をその業務に合わせて定めます。
ただし、指示文だけで操作停止を保証しません。OWASPのLLM06:2025は、機能と権限の最小化や、下流システムでの認可を推奨しています。案内専用なら更新機能を外し、対象サービスにも書き込み権限を持たせない構成を検討します。モデルの回答と、実際に呼ばれた機能の記録を照合することが必要です。
確認では、通常の規程質問には答える、変更方法の説明は続ける、実際の更新要求は止める、反映日が不明なら確約しない、という違いをダミー入力で点検します。本稿は試験設計の例であり、これらの動作を実測した報告ではありません。
新しい資料が届けば反映時期の説明は更新できるかもしれませんが、それだけで口座更新の権限は増えません。情報不足の解消と、許可範囲の変更は別です。どちらが解消したときに何を再開できるかを記録しておくと、停止の後も同じ境界を保って引き継げます。
答えられる部分まで断らないようにする方法は「AIの過剰拒否を減らし答えられる部分を残す方法」、業種固有のルールで一般情報と個別判断を分ける考え方は「業種固有のルールと人への影響を扱う 一般情報と個別判断の境界」で解説しています。
