境界のあるAIアシスタントを設計する――ツール、権限、コンテキストの実務

AIアシスタントの本当の境界は、「送信しないでください」と書いたプロンプトではなく、実行可能なサービス契約で決まります。送信ツールと有効な資格情報を持つモデルは、禁止文を誤って解釈しても操作できるからです。そこで、製品全体を一括して許可するのではなく、検索、要約、下書き、更新、送信など、利用者から見える機能ごとに情報、権限、操作上限、証跡、試験、責任者を分けます。

AIアシスタントには何を許可すべきか

まず、サービス憲章を一文で書きます。「対象利用者に対し、承認済みの情報範囲を使って許可された業務を行い、定めた成果物を作れるが、明示した判断や結果は扱わない」という形です。NIST AI RMFが扱う目的、利用環境、対応タスク、知識の限界、人の監督、リスク許容度も確認します。ただし、機能単位の設計法はNISTの必須様式ではなく、OWASPの最小機能原則などを基にした実務上の整理です。

• 「支援する」「管理する」を、検索、要約、提案、下書き、更新、送信、削除、承認へ分解する
• 対象利用者、利用場所、対応業務、参照できる知識、監督者を記録する
• 補償判断、権限付与、規制判断など、サービスが行わない結果を先に明示する
• ツール接続前に、サービス責任者、アクセス権限の責任者、リスクの引受者を決める

各機能が使える情報はどう区切るか

コンテキスト制限は、モデルに渡せる文字量ではなく、機能ごとの情報エンベロープとして定義します。対象システム、レコード種別、情報分類、部署や顧客などのオブジェクト条件、期間、鮮度、利用者本人の閲覧資格、禁止データを並べ、必要な証拠が取得不能、欠落、期限切れなら回答を限定または拒否します。大きなコンテキスト窓は、新しい権限も情報の正しさも生みません。

• 検索文書、添付、外部メッセージ、API応答は信頼できないデータとして命令から分離する
• 会話中だけ残す履歴と、次回以降も使う永続メモリを別々に設計する
• 永続化前の検証、利用者・セッション間の分離、有効期限、容量、削除、完全性保護を決める
• 認証情報、秘密情報、不要な機微データなど、保存してはならない情報を列挙する

本人確認、ツール、権限はどこで境界を守るか

境界は、認証、認可、承認を別々に判定し、ツールゲートウェイと下流システムで強制します。認証は誰または何が接続したか、認可はどの保護対象にどの操作が許されるか、承認は提示された一つの操作案を受け入れたかを答えます。モデルの判断や自然言語のガードレールは認可制御ではありません。利用者の委任権限か、制御されたワークロードIDかを明示し、特権管理者の権限を暗黙に引き継がせないことが重要です。

• 汎用メールボックスやデータベース接続ではなく、対象を限定した読み取り、下書き保存、承認済み送信を公開する
• 操作、対象資源、オブジェクト、項目、宛先、資格情報の有効期間を実行時に検査する
• MCP連携では、最小スコープや対象リソースに結び付いたトークンを使い、仕様を他方式の普遍的要件とはみなさない
• 回数、再試行、連鎖の深さ、処理量、費用、時間、重複防止、停止条件はサービス別に定める

会話は連続して見えても、その権限は小さく独立した機能へ分けて守るべきです。

一つの機能にどこまで実行させるか

各機能には、外部状態をどこまで変えられるかという操作上限を明示します。実務上は、回答・要約、提案、下書き、限定された可逆的更新、重大な外部操作、禁止判断の順に分けると整理しやすくなります。この段階はNISTやOWASP所定の等級ではなく、最小権限と判断・実行分離の原則を業務設計へ落とし込んだ編集上の枠組みです。

• 回答・要約：閲覧資格のある情報だけを使い、根拠がなければ停止する
• 提案：実行可能な形に整えても、決定や実行とは明確に分ける
• 下書き：非確定の保存先だけに作成し、外部への約束を成立させない
• 可逆的更新：対象項目、検証、重複防止、取消手段、監査記録を限定する
• 重大な外部操作：実行者、ツール、対象、正規化した内容、時刻、有効期限に承認を結び付ける
• 禁止判断：承認の有無にかかわらず機能を持たせず、適格な人と別管理の手続きへ送る

承認は不足する認可を補わず、恒常的に広すぎる権限を正当化しません。送信、支払い、アクセス付与、破壊的変更、本番変更、重要な外部約束、高い専門性を要する判断には、組織の影響度に応じて、適格な人の判断と決定論的な実行ポリシーを置きます。承認後に宛先や内容が変われば、以前の承認を流用せず、改めて検証します。

境界に達したとき、何を返し、どこへつなぐか

拒否、安全な範囲の部分回答、人への引き継ぎ、セキュリティ対応を、正式なサービス結果として設計します。理由は、対象外業務、利用不適格な情報、認可不足、承認待ち、証拠の欠落・期限切れ、専門判断の必要、依存先停止、運用上限、セキュリティ兆候などに分類します。内部ポリシーの機微な詳細は見せず、どの境界で止まったかを平易に伝え、失敗した検索や書き込みを成功したように表現してはいけません。

• 安全な範囲で、下書き、確認項目、足りない情報の依頼だけを返す
• 目的、非機微の関連情報、試みた機能、理由、利用できた証拠、次の対応、追跡IDを引き継ぐ
• 通常の利用者対応、業務上の承認、セキュリティインシデントを別経路にする
• 担当者の判断中は処理を停止し、操作内容が変わった場合は認可と承認を再確認する

境界を運用できる設計表へどう落とし込むか

利用者から見える操作ごとに設計表を一行作り、制御、証跡、試験、運用指標、責任者まで結び付けます。行には、対象者と認証、情報エンベロープ、会話履歴とメモリ、狭いツール操作、実行IDと資源範囲、操作上限と承認、運用制限、拒否、ログ、評価、引き継ぎ先を記録します。文書を埋めるだけで終えず、各項目を実行設定、試験ケース、監視画面、停止権限へ対応させることが要点です。

公開と継続運用にはどんな証拠が必要か

公開には、許可された業務が成功する証拠と、境界外の要求が拒否、停止、引き継ぎになる証拠の両方が必要です。通常の要求に加え、別アカウント、未許可ツール、期限切れ情報、汚染された検索文書、禁止データ、承認回避、パラメーター変更、重複再試行、依存先停止、データ流出の試み、止まらない処理連鎖を実環境に近い条件で試します。合格した試験一式も、将来の安全を永久に保証するものではありません。

• 誰が何を要求し、どの機能・ポリシー・情報源・ツール・認可・承認・版が適用され、何が起きたかを再構成できるようにする
• 秘密情報や無制限の会話本文を残さず、記録内容、保持、閲覧権限をプライバシーと記録管理の要件に合わせる
• 予期しないツール利用、拒否の増加、認可失敗、承認変更、異常な操作列、遅延、資源使用、失敗を機能単位で監視する
• サービス挙動、アクセス付与、業務引き継ぎ、インシデントに別々の責任者を置き、停止、改修、廃止の権限を明確にする

モデル、プロンプト、検索、メモリ、ツール、権限、ポリシー、データ、提供事業者、利用環境が実質的に変わったら、影響する試験と公開証拠を開き直します。最初は価値のある最小機能から始め、許可と拒否の双方を観測できてから、レビュー済みの変更として権限を広げます。機微情報、永続メモリ、特権アクセス、外部約束、破壊的変更、インシデント対応に触れる場合は、社内のセキュリティ、ID、プライバシー、記録管理、リスク、サービスの各責任者を参加させます。