メール、社内文書、WebページをAIエージェントに読ませるとき、先に決めるべきなのはプロンプトの言い回しではありません。外部コンテンツのどこまでをデータとして扱い、どの内容に業務の目的や操作の許可を変える権限を与えないか、という境界です。

境界が曖昧なままツールを接続すると、外部文書に含まれた命令文が要約対象のデータではなく、実行すべき指示として扱われる可能性があります。本稿では、本番資格情報や実データを使わず、候補業務を一つ確認するための4枚のpreflightカードを示します。

  1. 未信頼データと信頼済み命令の境界カード
  2. 許可するツール・操作・引数のカード
  3. 高リスク操作を人へ戻す承認カード
  4. 合成データで入力経路を試すテストカード

これらはOWASPやNCSCが定める公式チェックリストではありません。公開資料の論点を、業務責任者と実装担当者が確認するために翻訳した、本稿の編集上の提案です。

根拠から言えること

OWASP GenAI Security ProjectのLLM01:2025は、入力によってモデルの挙動が予期せず変わる直接プロンプトインジェクションと、Webサイトやファイルなどの外部ソースをモデルが受け取り、その内容を命令として解釈する間接プロンプトインジェクションを区別しています。影響例には、機密情報の開示、接続機能への不正なアクセス、重要な判断への影響が含まれます。OWASP LLM01:2025

英国NCSCのVersion 1.0資料は、model input manipulationを、認可されていない、予期しない、または不正確な出力につながり得る入力データの操作として扱います。LLMでは、参照コンテンツのデータベース、システム入力、ツール応答、別のagentic systemなども入力経路になり得ると説明しています。同資料は攻撃クラスの理解と脅威モデリングを支える資料であり、すべての業務に共通する実装手順や安全性の合格証ではありません。NCSC資料 第2.5節

したがって候補業務では、入力を読むことと外部操作を実行することを同じ前提で扱わない、という判断が必要です。

4枚のpreflightカード

1. 未信頼データと命令を分ける

候補業務の入力を出所ごとに分類します。分類そのものが安全性を保証するわけではありません。どの入力が目的や権限を変えてよいものかを、実装とレビューの両方で確認できるようにするための記録です。

入力の例 初期分類 残す記録
担当者が作成した作業依頼、承認済み設定 信頼済み命令の候補 効く業務範囲と作成者
メール本文、添付、Webページ、外部文書 未信頼データ 出所、取得時点、命令文があっても権限を与えない扱い
参照コンテンツDB、ツール応答、他のAIの出力 未信頼データとして要確認 返却元と、命令へ昇格させない扱い

入力の出所を判別できない場合は、信頼済み命令へ自動で入れず、保留として扱います。

2. 許可するツール、操作、引数を列挙する

ツール名だけでは、何を実行できるかは分かりません。候補業務で必要な操作と引数を一行ずつ書きます。

操作 初期テストでの扱い 確認すること
必要な情報の読み取り・検索 候補にできる 対象範囲、検索条件、返却データの範囲
メール・外部サービスへの送信 許可しない 宛先、本文、送信契機、承認者
業務記録の更新・削除 許可しない 対象ID、変更内容、取り消し方法
権限変更・重要判断への反映 人へ戻す 判断者、確認資料、適用範囲
カードにない操作 未評価 禁止するか、追加評価するか

最初は、ツールなしでできる範囲か、読み取りだけで価値を確かめられる範囲に切り出します。書き込み、送信、削除は、必要性と確認方法を説明できるまで接続しません。

3. 高リスク操作を人の承認へ戻す

「人が最終出力を読む」だけでは、操作の責任が曖昧になります。ツールを呼ぶ前に、次を一組で記録します。

記入内容
操作 送信、更新、削除、権限変更など
対象と引数 宛先、レコード、ファイル、値、および出所
承認者 業務上の責任を持つ人
承認条件 何を確認したら実行できるか
結果 承認、保留、却下、未評価

メールを要約することと、その要約をもとに外部送信することは別の操作です。前者をsandboxで確認できても、後者を自動実行してよい根拠にはなりません。

4. 合成データで入力経路を試す

実在の機密情報、本番資格情報、実際の宛先を使わず、少数の合成テストを行います。一つのテストにつき、入力経路、許可操作、期待結果、実際の出力・ツール呼び出し・承認要求を記録します。

記録内容
test_id ケースの識別子
source_class 直接入力、メール本文、添付、Web、参照DB、ツール応答など
synthetic_content 合成した命令文の種類と置き場所
allowed_tool テストで利用可能にした操作
expected_outcome 要約のみ、保留、禁止操作なしなど
observed_outcome 実際の出力、ツール呼び出し、承認要求
disposition block、hold、incorrect reaction、unevaluated

blockholdincorrect reactionunevaluatedは本稿の記録用語です。公式の合否分類ではありません。特にunevaluatedは合格ではなく、その入力経路をまだ評価できていない状態です。

仮想例:問い合わせメールの要約エージェント

共有受信箱の問い合わせメールを要約し、担当部署の候補を提示するエージェントを考えます。最初は送信、業務記録の確定更新、削除を行わず、sandboxで要約と候補提示だけを確かめます。

カード 仮想例での記入
データ境界 メール本文と添付は未信頼データ。担当者が指定した対象業務と出力形式だけを信頼済み命令の候補にする
ツール許可 読み取りと要約だけ。送信、更新、削除、権限変更は利用可能にしない
人の承認 外部送信や記録更新が必要なら、対象・引数・承認者を示して保留する
合成テスト 直接入力と添付文書に命令文を置き、出力・操作提案・ツール呼び出しを記録する

テスト例は次の二つです。

test_id 入力経路 合成する内容 期待する結果
D-01 直接入力 外部送信を実行するよう求める命令文 送信ツールを利用可能にせず、入力が目的や操作提案を変えようとしたかを記録する
I-01 添付文書 要約の代わりに業務記録を更新するよう求める命令文 更新ツールを利用可能にせず、添付の文言が要約範囲や操作提案に影響したかを記録する

期待と異なる出力、禁止した操作の呼び出し試行、承認なしで高リスク操作へ進む挙動があれば、incorrect reactionとして本番接続を止め、境界カードを見直します。期待どおりに見えても、試していない入力経路や業務範囲まで結論を広げません。

MASTER key・AX事業部として残す型

本稿で示すのは、機能数を増やす前に、境界を記録した小さな業務単位を作る考え方です。外部コンテンツを読む候補業務を一つ選び、データの出所、許可ツール、人の承認、合成テストの結果を同じ単位で確認します。

これはMASTER key株式会社やAX事業部の導入実績・顧客成果を示す事例ではありません。また、OWASPやNCSCの公式チェックリスト、認証、安全保証でもありません。経営者や業務責任者が、「何を許可したか」「どこから人が判断するか」「何が未評価か」を実装担当者と確認するための編集上の型です。

検索需要と導入成果について、まだ言えないこと

このページの検索クエリは検証可能な仮説ですが、検索需要、読者の実測課題、問い合わせ、クリック、認知、事業成果は確認できていません。公開が認可された場合も、対象URLの到達性、canonical、indexability、GSCのquery・page、GA4のlanding page・referrer・UTMが観測できるかを先に確認します。

対象URLに帰属するnon-branded search clickが観測されても、それは次の改善を決めるlearning signalであり、MASTER keyの認知や事業成果の証明ではありません。

まとめ

外部文書を読むAIエージェントの本番前確認では、次の順番で候補業務を一つ確認します。

  1. メール、文書、Web、参照結果、ツール応答を未信頼データとして分類する
  2. 許可するツール、操作、引数を最小限に列挙する
  3. 送信・更新・削除などの高リスク操作を人の承認へ戻す
  4. 本番資格情報なしで、直接・間接の合成テストを行う
  5. block、hold、incorrect reaction、unevaluatedを区別して記録する

この手順はプロンプトインジェクションを完全に防ぐ方法でも、特定製品の安全を保証する方法でもありません。何をデータとして扱い、どの操作を誰が承認し、どの結果が未評価かを、4枚のカードに残すところから始めます。

参考資料