AIエージェントのプロンプトインジェクション対策｜情報漏えいを防ぐ権限・承認設計

2026年10月23日

AIエージェントにWebページを調べさせ、メールを読ませ、社内文書を検索させる。便利になる一方で、読ませた文章に紛れた「指示」が、本来の依頼より優先されたように扱われる危険があります。これがプロンプトインジェクションです。特にエージェントが外部サービスを操作できる場合、回答の誤りだけでなく、意図しない送信・更新・情報持ち出しにつながります。

結論は、怪しい文章をすべて見抜くことより、外部の文章が操作権限に変わらない設計を先に作ることです。外部コンテンツは資料として扱い、操作の可否はアプリケーション側で判定します。閲覧専用と更新可能なツールを分け、必要な範囲だけ権限を付け、送信や削除には具体的な確認を挟みます。さらに、実際に何を読んで何を操作したかを記録し、安全なテスト環境で繰り返し確かめます。

この記事は、社内でAIエージェントを使い始めた担当者、RAGやツール連携を実装する開発者、権限管理を担う情報システム部門に向けた防御ガイドです。実在サービスへの攻撃方法や侵入用の入力例は載せません。まず自社の連携と権限を棚卸しし、今日変えられる設定と、設計変更が必要な部分を分けて判断できるようにします。

AIエージェントへのプロンプトインジェクションとは

通常のチャットでは、人が直接入力した質問にAIが答えます。AIエージェントはそこから一歩進み、Web検索、ファイル検索、メールの閲覧、チケットの取得、外部APIの呼び出しなどを組み合わせます。すると、利用者が書いた依頼とは別に、第三者が作成または変更できる文章が作業途中で入ってきます。その文章は情報源であって、エージェントの新しい上司ではありません。しかしモデルは、同じ文脈に含まれた文章から次の行動を判断するため、データを指示と取り違える可能性があります。

OWASPは2025年版のLLMアプリケーション向けリスクで、プロンプトインジェクションを重要なリスクとして扱い、予防を完全に保証できる方法は明確ではないとしています。したがって「禁止文をシステムプロンプトに足したから安全」とは評価できません。防御はモデルの判断、アプリ側の権限、操作承認、ログという複数の層で考える必要があります。OWASP「LLM01:2025 Prompt Injection」

直接入力と、外部コンテンツ経由の間接入力は分ける

直接型は、会話の入力欄に書かれた文章がエージェントの行動を変えようとするものです。間接型は、Webページ、共有文書、メール、サポートチケット、検索結果、APIの応答など、正規の依頼を遂行するために読む資料から入ってきます。後者は「利用者は正しい依頼を出したのに、途中で読んだ資料に引っ張られる」という点が厄介です。攻撃者がエージェントのチャット画面に直接触れる必要もありません。

たとえば、担当者が「取引先から届いた問い合わせを要約して」と頼んだとします。メール本文は要約対象です。そこに別の作業を求める文章が混じっていても、メール差出人に社内ファイルの閲覧権限や送信権限が生まれるわけではありません。同じことは、採用応募書類を読むエージェント、競合サイトを調べるエージェント、GitHubのissueを整理するエージェントにも当てはまります。読む行為と従う行為を分けることが、設計上の最初の境界です。

Microsoftの公式ガイドも、サポートチケット、メール、Webページ、ファイルなどのツール応答を外部由来の入力として扱い、ラベル付け、最小権限、重要操作の承認、決定的なコードによる出力検証を勧めています。これは特定製品だけの話ではなく、外部テキストを取得してモデルへ渡す構成全般に当てはまる考え方です。Microsoft Learn「How to test whether your AI agent follows instructions hidden in tool responses」

被害はモデル単体ではなく、接続先と権限で決まる

同じ不審な文章を読んでも、閲覧専用のエージェントと、メール送信・ファイル削除・顧客データのエクスポートまで可能なエージェントでは影響が違います。前者は誤った要約や判断が中心かもしれません。後者は、操作が実行された時点で取り消しにくい影響が出ます。情報漏えいを考える際も、モデルが何を記憶しているかだけでなく、どのデータにアクセスでき、どの外部宛先へ送れるかを確認します。

ここで「外部入力を受ける場所」と「危険な操作ができる場所」を別々に地図化すると、優先順位が見えます。入力側にはメール、Web、クラウドストレージ、検索インデックス、外部プラグインが並びます。操作側には送信、共有設定変更、ファイル更新、購入、公開、権限変更などが並びます。一本のワークフローで両側がつながり、途中に独立した権限判定がない部分を最優先で直します。

「AIが賢くなれば解決する」と考えない

モデルの改善は重要ですが、それだけを唯一の安全策にはできません。OpenAIは、外部情報を読むAIに対するプロンプトインジェクションを未解決の課題として説明し、攻撃的な文章を完全に見分けるだけでなく、仮に操作を誘導されても影響を抑える設計が必要だと述べています。人間の担当者にも、メールの文面だけで経理権限を与えたり、確認なしに多額の支払いを実行させたりはしません。エージェントにも同じように、役割と承認の境界を置きます。OpenAI「Designing AI agents to resist prompt injection」

参考にしたHuman Hackerの検証記事は、意図的に弱点を設けた試験環境と合成データで行った同社の自己報告です。本記事はその実験を再現するものではなく、守る側の業務設計に焦点を当てます。実験結果を自社への攻撃成功率として読み替えず、対象、権限、データの種類、確認条件を自社の構成で点検してください。

外部データが「指示」に化ける経路を棚卸しする

対策を導入する前に、エージェントが何を読んで、どこへ出力し、何を変更できるのかを一覧にします。AI導入プロジェクトでは「利用するモデル」を先に決めがちですが、事故の影響を左右するのは、メール、文書、検索、APIと権限の結び付きです。まず本番で動いているエージェントを1つ選び、利用者の依頼から最終操作までを時系列で書き出します。

入力源、加工、判断、実行先を1本の線で追う

棚卸し表には、入力源の名称、誰が内容を書き換えられるか、エージェントに渡す形式、保持期間、利用者の認可の有無、呼び出せるツール、承認者、記録先を入れます。Web検索結果なら誰でも公開内容を変更し得ます。社内共有フォルダなら編集権限者が限定されますが、外部から送られた添付ファイルをそのまま保存する運用なら、実質的に外部入力が混ざります。検索インデックスも、元文書のアクセス権を保持していなければ、別の利用者の資料を返してしまう恐れがあります。

「入力されたら何でも要約する」という機能でも、要約結果をそのままCRMの顧客メモへ書き戻すなら、入力が次の担当者や別のエージェントへ伝わります。さらに、そのメモが新たな検索対象になると、誤った指示が何度も現れる可能性があります。入力、生成、保存、再取得の循環まで図にしてください。途中でソースURL、文書ID、作成者、取得時刻が失われると、後から何を根拠に判断したか追いにくくなります。

以下は棚卸しの例です。値は架空で、自社の権限・データ分類に置き換えてください。

処理	入力を編集できる人	許す操作	境界と確認
公開Webページの要約	サイト運営者、投稿者	閲覧と要約だけ	外部文面を命令として扱わず、出典URLを保持
問い合わせメールの分類	メール差出人	分類案の作成だけ	返信案は下書き、送信前に担当者が宛先と本文を確認
社内文書の検索	文書の編集者	利用者が閲覧できる文書の検索	検索時に利用者権限で絞り、参照文書IDを保存
顧客情報の更新	利用者と外部顧客	承認済み項目の更新	更新対象、旧値、新値を表示し、アプリ側で権限を再判定

信頼度はファイル形式ではなく出所と権限で決める

PDFだから安全、社内ドメインだから安全、検索上位だから安全という判断はできません。PDFにも第三者から届いたものがあります。社内の文書に外部記事の引用が貼られていることもあります。検索エンジンの順位は、そのページに指示権限を与えるものではありません。どの資料でも「誰が原文を作り、いつ変更でき、誰の承認で取り込んだか」を見ます。正規サイトの内容であっても、エージェントへの新しい業務指示として採用しない原則は変わりません。

画像の文字やOCR結果、HTMLの隠し要素、ツールのエラーメッセージなども、モデルに渡る時点では文章になります。見た目には業務メモに見えるものでも、後段のモデルにとっては処理対象です。全入力を単純なテキストとして連結する実装では、元の境界が失われます。資料の本文、出典、引用、メタデータを別のフィールドに保持し、モデルへ渡す際にも「この部分は外部資料」という区別を保つ必要があります。

ツールの一覧を「読む」「書く」「外へ出す」で分ける

ツール名だけを見ると、便利な連携に見えるかもしれません。実際には権限の種類が重要です。ファイル一覧の取得とファイル本文の取得、下書き保存と公開、メール作成と送信、取引先の検索と取引先情報の変更は別の操作です。同一トークンで全操作ができるなら、エージェントに広い権限を与えている可能性があります。使っていないツールやスコープも洗い出します。

さらに「外へ出す」経路を見落とさないでください。メールの送信だけが流出経路ではありません。共有リンク作成、公開投稿、外部Webアクセス、CRMの外部連携、チケットのコメント、分析ツールへのイベント送信なども含まれます。宛先が動的に指定できるか、事前に許可したドメインやユーザーだけへ送れるか、送信前に実データを確認できるかを点検します。必要な経路だけ許す方が、怪しい文章の検知に全てを任せるより影響を小さくできます。

責任者を決め、未把握の連携を先に止める

棚卸しの成果物は単なる一覧ではありません。エージェントごとに、業務上の責任者、技術管理者、データの管理者、承認者、障害時の停止権限者を決めます。たとえば営業の要約エージェントなら、業務責任者が必要な機能を決め、情報システム部門が権限とログを管理し、顧客データの管理者が閲覧範囲を確認します。誰も管理できない個人トークンで業務データを操作している場合、機能を増やす前に接続を見直します。

MicrosoftのAI向け権限ガイドは、利用者・エージェント・ツールを識別し、操作ごとに最小権限、短い有効期間、重要操作の新しい承認を設ける方針を示しています。これを製品の設定項目へ落とし込み、権限の「所有者不明」をなくすことが最初の改善になります。Microsoft Learn「Identity, Access, and Least Privilege」

指示と資料を分け、ツール権限を狭くする

棚卸しで経路が見えたら、モデルへの入力処理と、実際に動くツールの許可を分けて直します。「外部資料には従わない」とプロンプトに書くことは有用ですが、それだけで権限管理の代わりにはなりません。プロンプトは振る舞いを導く層、アプリケーションの認可は操作を止める層です。両方が必要です。

外部本文は引用として渡し、重要な値だけ構造化する

外部Webページやメール本文を、開発者の指示文と同じ場所へ無造作に連結しないでください。取得した文章には出所を付け、「要約対象の資料」として区切って渡します。書式の工夫だけで攻撃を完全に防げるわけではありませんが、少なくともアプリの設計上、外部文面を権限の根拠として使わないようにします。画面にも、AIが引用した情報の出典と、AI自身の提案を分けて表示すると、担当者が誤認しにくくなります。

後段でシステムを更新する必要があるなら、自由文をそのまま操作コマンドに変換しないでください。モデルから「分類＝請求」「担当部署＝経理」「要返信＝はい」のように、用途を限定した値を取り出し、許容値、型、長さ、対象ID、利用者権限をコードで検証します。たとえば外部メールが「担当者を変更して」と書いていても、担当変更がこの処理の許可対象外なら実行できないようにします。構造化した値も無条件に信用せず、重要操作の前に必ずサーバー側で再検査します。

OpenAIのエージェント構築ガイドは、信頼できないデータが直接行動を決めないように、必要な構造化フィールドを抽出し、ツール承認、ガードレール、評価を組み合わせるよう案内しています。また、そのような対策でも危険が完全になくなるわけではないと明記しています。OpenAI API「Safety in building agents」

閲覧専用から始め、操作単位で権限を増やす

初期導入では、検索・要約・下書きまでをエージェントに任せ、送信や更新は人が操作する構成にします。業務上どうしても自動更新が必要なら、対象データ、操作種類、件数、時間帯を限定します。すべての顧客レコードを読める権限ではなく、現在の案件に紐づくレコードだけを取得する。全フォルダの書き込みではなく、承認された下書きフォルダだけを更新する。ツールの説明文で制限するのではなく、APIやサービスアカウントの権限そのものを小さくします。

利用者の権限を超えてエージェントが資料を検索できてはいけません。RAGで社内文書を使う場合も、検索時に元文書のアクセス制御を適用し、取得後の段階で「見せない」だけに頼らないでください。共有文書の権限が変更された後に検索インデックスが古いままなら、どのタイミングで反映されるかも確かめます。インデックス、キャッシュ、エージェントの記憶に残る情報は、元データの削除・非公開化と連動して管理します。

APIキーや認証トークンを、モデルが読む文章やツール応答に埋め込まないことも基本です。秘密情報は実行環境の安全な保管先に置き、必要な時だけサーバー側のコードが利用します。エージェントごとに識別できるアカウントを用意し、用途の異なる複数のエージェントで同じ強い鍵を使い回さないでください。もし権限を狭められない外部サービスなら、その連携を自動化する範囲を小さくするか、承認を必須にします。

宛先と対象は承認の直前に再確認する

「送信前に確認」ボタンを置くだけでは不十分です。承認画面には、誰に送るか、どの件名・本文か、添付ファイルは何か、どのデータを参照して作成したかを表示します。削除なら対象の件数と名前、共有設定なら公開範囲の変更前後、公開なら公開先と表示内容が必要です。曖昧な「AIが次の作業を実行します」では、担当者が判断できません。

承認後にAIが内容を差し替えられるなら、その承認は意味を失います。承認した内容の識別子を固定し、送信や更新の直前に、承認時と同じ対象・内容かをコードで照合します。さらに、同じ承認を使い回して複数回送れないようにします。送信先ドメインやデータの種類が想定外なら、承認画面へ戻すだけでなく、システム側で実行を拒否する判断も必要です。承認は重要ですが、承認者が見落とす可能性も前提に、件数上限や送信先制限を併用します。

ツールの結果も、次のツールに渡す前に検査する

エージェントは複数のツールを連続して呼びます。検索結果の文章から「次はこのURLへアクセス」「このファイルを送る」という提案を生成し、そのまま別ツールへ渡すと、外部データが操作指示へ昇格します。危険な操作につながる値ほど、アプリが独立に検証します。URLは許可された用途と宛先か、ファイルIDは現在の利用者に許された範囲か、更新フィールドは事前定義されたものかを確認します。

エージェントが自分で書いた要約にも、元の外部資料の影響が残る可能性があります。「一度要約したから安全」とは扱わないでください。次の処理に必要な最小の事実だけを持ち越し、出典と信頼度を保ちます。自動化を二段階に分ける場合も、第一段階のモデル出力が第二段階のモデルに対する権威ある命令にならないよう、責任境界を設計します。

人の承認、監査ログ、停止手順を実装する

安全なエージェントを作る目的は、あらゆる文章を完璧に判定することではありません。利用者が意図していない操作が起きたとき、被害が広がる前に止め、何が起きたかを説明できる状態にすることです。そのために、重要操作の承認、操作ログ、緊急停止を製品導入時の必須項目として扱います。

「人が見るべき操作」を先に定義する

すべての閲覧に承認を求めると業務が止まり、担当者が機械的に許可するようになります。一方、顧客情報の外部送信やアクセス権の変更を自動実行するのは危険です。操作を影響度と取り消しやすさで分けます。閲覧・要約・社内下書きは低リスクの出発点です。外部への送信、公開、決済、削除、権限変更、機密情報の一括取得は高リスクとし、明確な承認を求めます。部門によって対象データが違うため、表を自社の情報区分に合わせて作り直してください。

操作の例	通常の扱い	承認画面に必要な情報	拒否・異常時
公開情報の検索と要約	許可した情報源で自動実行	出典と取得時刻を回答に表示	出典不明なら回答を保留
社内向け下書き作成	限定フォルダへ保存	保存先、参照元、文書名	下書きを破棄して再作成
外部メール送信	人が宛先と本文を承認	宛先、本文、添付、データの出所	送信せず記録して担当者へ戻す
大量更新・削除・権限変更	原則自動化しない。必要時は二重確認	対象一覧、件数、変更前後、復旧手段	実行停止、変更可能な権限も一時停止

OpenAIのエージェント構築ガイドは、MCPツールの操作を確認できるようツール承認を有効にすることを勧めています。利用するプラットフォームが異なっても、重要な操作を人が具体的に確認できること、承認前後に内容が変わらないこと、拒否できることを要件に置きます。承認が必要な操作を利用者が回避できる別経路がないかも確認します。

ログは「会話」だけでなく操作の因果を残す

単にプロンプトの全文を保存するだけでは、事故調査に足りず、逆に個人情報を増やしすぎることもあります。最低限、実行ID、利用者または業務ID、開始時刻、参照した資料の識別子と出所、呼び出したツール、対象、承認者、承認内容、結果、エラー、停止理由を追えるようにします。モデルやアプリケーションの設定バージョン、検索インデックスの版も記録すれば、同じ条件に近づけて再確認できます。

ログそのものに機密が含まれ得るため、閲覧権限、保存期間、マスキング、削除ポリシーを定めます。AIが閲覧した秘密情報を全て平文で残すことが目的ではありません。出典IDやハッシュなどで追跡可能にし、実データへのアクセスは必要な担当者に限ります。異常を検知する担当者が、業務時間外も含めてどの通知を受けるか、誰が連携を止められるかまで決めます。

特に監視したいのは、依頼と関係ないツール呼び出し、通常より大量のデータ取得、初めての外部宛先、権限変更、同じ承認の再利用、外部入力直後の操作種別の変化です。一件で即攻撃と断定するのではなく、業務の文脈と照らして調査します。監視ルールを厳しくしすぎて通常作業ができなくなる場合は、例外を無制限に許すのではなく、用途別のエージェントを分けて権限を調整します。

異常時は連携を止め、秘密情報と記録を保全する

不審な送信や更新が疑われたら、まずエージェントの実行を止め、該当ツールのトークンを無効化または権限を縮小します。次に、実行ID、時刻、参照元、送信先、更新対象、承認履歴を保全します。該当データが個人情報や取引先情報なら、社内の事故対応手順と契約上の連絡義務を確認します。疑わしい入力だけを削除してログも消してしまうと、影響範囲を特定できなくなります。

復旧は、原因を「モデルが変な答えを出した」で済ませず、なぜその入力を読んだか、なぜ操作できたか、承認が機能したか、監視がいつ検知したかを分解します。入力の隔離、権限変更、承認画面の修正、検索インデックスの再構築など、再発経路を塞いでから段階的に再開します。公開中のエージェントを一斉に戻す前に、同じ条件をテスト環境で再現し、危険な操作が止まることを確認します。

安全な検証環境で、対策が動くか確かめる

設定表が整っていても、実際のワークフローで承認や権限が機能するとは限りません。プロンプトインジェクションの検証は、許可されたテスト環境、自社が管理するテストアカウント、架空データで行います。第三者のサイトやシステムへ無断で試す必要はありません。目的は攻撃の再現性を競うことではなく、外部資料が行動を変えようとしても、高リスクの操作が止まり、担当者が異常を追えるかを見ることです。

成功条件を「AIが騙されたか」だけで決めない

テストケースは、入力源、正規の依頼、期待する安全な結果、失敗とみなす操作をセットで記録します。たとえば、正規の依頼が「問い合わせ内容を分類する」なら、期待する結果は分類案と出典です。失敗は、関係のない文書を検索する、外部へ送る、承認なしに顧客データを更新する、といった具体的な行動です。モデルが不審な文章を回答に引用しても、それと実際のツール実行は別の事象として評価します。

安全な検証では、テスト用の外部資料に、業務依頼とは異なる無害な指示が含まれていた場合を想定できます。実際の秘密情報や外部宛先は使わず、テスト環境だけに存在する目印で、回答やツール呼び出しへの混入を確かめます。大事なのは危険な入力文を量産することではなく、設計した境界が現実のツール連携で保たれるかを確かめることです。Microsoftは公式のテスト解説で、同じケースを複数回実行し、必要のないツール呼び出し、承認の有無、出力検証の動作を確認するよう案内しています。Microsoft Learnの検証ガイド

変更ごとに再試験する項目を固定する

モデルの変更、システムプロンプトの変更、検索対象の追加、ツール接続の追加、権限の変更は、いずれも結果を変える可能性があります。導入時だけ試すのではなく、変更前後で同じ評価セットを実行します。検証項目には、外部資料の出典保持、権限外文書の検索拒否、許可外の送信先拒否、重要操作の承認、承認内容の固定、ログの追跡、停止操作を含めます。日常の品質評価とセキュリティ評価は別々に扱い、要約が上手でも権限境界を越えたら不合格とします。

評価を一回の正答率だけで表さないことも重要です。モデルの応答には揺れがあり、同じ条件でも結果が変わる場合があります。複数回の結果、ツール呼び出しの履歴、権限判定の結果を保存し、重大な一回の失敗を平均値で埋めないでください。たとえば100回中99回安全でも、一回だけ承認なしの送信が通るなら、本番利用の許可条件を見直すべきです。小さな誤要約と、顧客情報の外部送信は同じ点数で相殺できません。

製品選定では「防止率」より運用可能性を見る

AIセキュリティ製品やガードレールを検討する際、「どの攻撃も完全に防ぐ」という表現だけで選ばないでください。自社の入力源を検査できるか、どの時点でブロックするか、誤検知時に業務を戻せるか、承認・権限・ログと連携できるかを確認します。単独の検知器が不審な文章を見逃したときも、データ取得と外部送信の制限で影響を抑えられる構成が望まれます。

ベンダーには、自社のユースケースに近い試験条件、評価データの種類、検知をすり抜けた際の動作、ログの保持、管理者の停止手段を質問します。「危険文を見つける」と「危険操作を止める」は違います。後者の境界を製品が担うのか、自社のアプリで実装するのかを明確にします。OWASPも、モデルへの指示、期待する出力形式、入力と出力の検査、最小権限、人の承認を重ねる緩和策を示しています。OWASPの緩和策

導入から運用までの実行チェックリスト

これから導入するチームと、すでに稼働しているチームでは着手順が違います。新規導入なら、接続するデータを絞り、閲覧専用から始めることができます。既存システムなら、稼働を急に止められない場合でも、最も影響が大きい送信・削除・権限変更の経路から一時停止や承認追加を検討します。以下は部門横断で使うための実務用チェックリストです。

初日から一週間：止めるべき経路を見つける

最初に、稼働中のエージェント名、業務責任者、接続先、サービスアカウント、ツールの操作権限を一覧にします。続いて、外部メールや公開Webページを読むエージェントが、同時に外部送信や顧客データの一括取得もできるかを確認します。該当するものは高優先です。すぐに設定で権限を外せるなら外し、業務に必要なら承認を付けるまで該当機能を一時停止します。変更前後の設定と理由を記録し、現場が困る作業は人手の代替手順を準備します。

一週間の完了条件は「全て解決した」ではありません。誰が管理しているか不明な連携がゼロ、最も危険な操作の一時的な境界が存在、連携停止の担当者と手順が判明、の三点です。トークンの権限が広すぎると分かった場合、ただちに削除できない事情があっても、使用先、期限、交換計画を決めます。現場に影響がある変更は、業務責任者と一緒に対象を確定して進めます。

二週間から一か月：認可と承認を実装する

次に、ワークフローごとに「資料を読む」「案を作る」「承認する」「実行する」を分離します。実行APIは、AIが提案した内容を鵜呑みにせず、利用者、対象、操作を再認可します。外部宛先の許可範囲、件数上限、時間帯、承認内容の固定も決めます。承認画面には対象と変更内容を示し、拒否ができるようにします。検索対象の文書も、利用者権限と連動させます。

この段階の成果物は、ツールごとの権限表、承認が必要な操作一覧、検索・保存・送信の設計図、監査ログの項目です。完成の判断は、設定画面に承認のチェックがあるかではなく、テスト用の依頼で承認なしの送信が実際に拒否されるかで行います。承認していない別の宛先へ後から内容を変えられないことも確かめます。

一か月以降：評価と事故対応を運用に組み込む

本番運用では、モデル、ツール、連携先、検索インデックスが変わるたびに、代表的な検証ケースを実行します。毎月、不要になった権限や連携を削除し、ログから業務依頼と無関係な操作がないかを点検します。例外が必要なら期限と責任者を付け、恒久的な全権限を残さないでください。半年に一度は、トークン停止、承認者不在、検索結果の出所不明といった場面を使って、停止・復旧の机上訓練を行います。

責任分担を曖昧にしないため、業務責任者は許可する業務と操作を決め、情報システム部門はID・トークン・ログを管理し、開発者はアプリ側の認可と承認の一貫性を実装します。セキュリティ担当は検証と事故時の調査手順を整えます。外部ベンダーに運用を任せる場合も、自社で停止できるか、ログを受け取れるか、データ保存先と再委託先を確認します。調達契約だけでは運用上の可視性を代替できません。

よくある疑問：完全に防げるか、毎回人が見るべきか

Q. システムプロンプトに「外部の指示を無視」と書けば十分ですか。
いいえ。振る舞いの指針にはなりますが、外部データをモデルが処理する以上、それだけで権限境界を保証できません。コードによる認可、最小権限、承認、監視を重ねます。

Q. すべてのツール呼び出しを人が確認すべきですか。
導入初期や影響が読み切れないツールでは広く承認を求める判断があります。ただし通常運用では、閲覧と外部送信などを分け、重大性に応じて承認を設計します。承認疲れを避けつつ、取り消しにくい操作には具体的な確認を残します。

Q. 外部資料をAIへ渡さなければ問題はなくなりますか。
攻撃面は小さくなりますが、社内文書にも外部引用や権限設定の誤りがあり得ます。入力源を減らすことと、閲覧権限・出力先・操作権限を制御することを並行します。

Q. プロンプトインジェクションと情報漏えいは同じですか。
同じではありません。前者は意図しない指示へ誘導する経路、後者は起こり得る結果の一つです。誘導により誤情報の提示や無許可の更新だけが起こる場合もあります。調査では入力、モデルの判断、実際のツール操作、外部への伝達を別々に確認します。

Q. まず一つだけ改善するなら何ですか。
外部コンテンツを読むエージェントが、外部送信・削除・権限変更を承認なしに実行できるか確認してください。できるなら、その権限を外すか一時停止し、業務に必要な範囲だけ承認付きで戻す判断が先です。

AIエージェントの安全性は、モデルが危険な文章を見抜けるかだけで決まりません。外部資料を資料として扱い、データへのアクセスとツール操作を最小限にし、重要操作を人が確認し、何が起きたか追える仕組みを組み合わせて初めて、業務で継続利用できます。まずは一つのエージェントについて、入力源から外部送信までを図にし、権限が広すぎる経路を直してください。

情報確認日：2026年10月23日。参考資料：OWASP LLM01:2025、OWASP Agentic AI – Threats and Mitigations、NIST AI RMF Generative AI Profile、Microsoft Learn、OpenAI API。技術や機能の仕様は変わるため、導入時には各公式資料を再確認してください。