最終更新：2026年4月25日
※本記事は継続的に最新情報へアップデートしています。

AIエージェントセキュリティとは？MCP/A2A時代の安全設計

AIは「答えるソフトウェア」から「動くソフトウェア」へと変わった。MCPやA2Aを通じて外部ツールや他のAIと接続し、業務を実行する存在になっている。今求められるのは誤回答対策ではなく、誤実行・権限濫用・監査不能を前提に、業務プロセスと権限設計を組み替える安全設計である。本記事では、つながったAIを企業がどう統制すべきか、リスクと設計原則を整理する。

📖 読了時間 10分｜🎯対象：AIエージェント導入を検討する経営者・CTO・情シス｜🛠 難易度：★★☆

✅ 先に結論

結論：AIエージェントセキュリティとは「実行するAI」を統制するための安全設計であり、誤回答対策とは別物である
判断軸：最小権限・人間承認(HITL)・監査ログ・サンドボックス・ゼロトラストの5つで設計する
注意点：AIは社員ではない。権限を持つソフトウェアとして、業務範囲と責任分界を先に決める

この記事の著者・監修者　ケニー狩野(Kenny Kano)

Arpable 編集部(Arpable Tech Team)

株式会社アープに所属するテクノロジーリサーチチーム。人工知能の社会実装をミッションとし、最新の技術動向と実用的なノウハウを発信している。
役職：(株)アープ取締役。Society 5.0振興協会・AI社会実装推進委員長。中小企業診断士、PMP。著書『リアル・イノベーション・マインド』▶ 詳細はこちら

Toggle

何が変わったのか

AIは「答えるソフトウェア」から「動くソフトウェア」へと進化した。MCPとA2Aによって、外部ツールや他エージェントと接続する力を手にしている。

かつて生成AIは、質問に答える存在でした。しかし今のAIは、社内データを読み、外部ツールを操作し、他のAIエージェントと連携しながら、業務の一部を実行する存在へと変わっています。便利さだけの話ではありません。AIに「手足」と「権限」が与えられた瞬間、セキュリティの前提も大きく変わります。

変化の起点

ある朝、営業支援AIエージェントが顧客リストを読み込み、過去の提案書を参照し、見積書を作成し、社内チャットで承認依頼を出していたとします。そこまでは理想的です。

しかし、平穏な業務の裏側で「見えない汚染」は始まります。取引先を装ったメールの末尾に、人間には気づきにくい形で、AIだけが読み取る追加指示が紛れ込む。実直なAIエージェントはそれを「優先度の高い追加タスク」と解釈し、自分に与えられた権限で処理を進めてしまう。

これは近年、AIエージェント時代の主要リスクとして扱われる間接プロンプトインジェクションと同じ構造のリスクです。

人間にはただの文章に見える一文が、AIには「次に実行すべき命令」として読まれてしまう。問題はAIが間違えたことではなく、間違えたAIに、実行する権限が与えられていたことです。

これは仮想の話ではありません。2025年に公開されたEchoLeak（CVE-2025-32711）は、ユーザー操作なしにAIエージェントを悪用できるゼロクリック型のAIエージェント攻撃として注目されました。攻撃者が用意した外部入力をAIが読み取り、社内情報を外部へ漏えいさせ得る構造は、まさに「見えない命令」をAIが自分の権限で実行してしまうリスクを示しています。OWASPはこの種のリスクを、ASI01：Agent Goal Hijackに代表されるエージェントの目的乗っ取りリスクの一種として位置づけています。

従来との違い

AIエージェントは、業務利用の文脈で次の4つの力を持ち始めています。これが従来の「答えるだけのAI」との決定的な違いです。

表1：AIエージェントが持つ4つの力とセキュリティ論点
AIエージェントの力	意味	セキュリティ上の論点
読む力	社内文書、メール、Web、DBを参照	機密情報・個人情報のアクセス制御
考える力	目的を分解し、作業手順を組み立てる	判断根拠、説明責任、意図の逸脱
実行する力	API、SaaS、RPA、コードを操作	誤実行、権限濫用、外部送信
連携する力	他のエージェントへ依頼・委任	なりすまし、責任分界、指示改ざん

AIエージェントが外部ツールや社内データに接続する基盤については、MCPとは？AIツール連携の仕組み・APIとの違い・安全な始め方を解説で解説しています。エージェント同士の連携前提は、A2Aとは？MCPとの違いと日本企業が見落とす前提条件にまとめています。

なぜ今重要なのか

リスクの重心は「誤回答」から「誤実行」へ移った。AIに権限を与える以上、設計されていない自由度は事故を生む。

生成AIの時代、主なリスクは「間違った回答」「機密情報の入力」「著作権や倫理問題」でした。AIエージェントの時代になると、リスクの重心が変わります。問いはこう変化します。「AIは正しい答えを返すか?」から、「AIにどこまで実行させてよいのか?」へ。

事業への影響

AIが提案・支払い・契約の周辺で動き始めると、誤実行は売上の損失や信用毀損に直結します。たとえば、AIが誤った相手に見積書を送る、間違った金額で発注を進める、解約処理を誤って実行する。これらは「AIの間違い」というより業務プロセスの事故として扱うべきものです。

開発への影響

開発側の関心は「モデルの精度」から「実行環境の安全性」へ広がります。プロンプト品質だけでなく、AIが呼び出すツール、APIキー、認証スコープ、ログの取り方、停止手段までを設計対象に含める必要があります。AIアプリは従来のWebアプリより攻撃面が広いと捉えるのが現実的です。

たとえば、MCPやツール呼び出し基盤を設計する際には、ツールそのものに「人間承認が必要か」「操作上限はいくらか」「どの範囲にだけ実行できるか」をメタデータとして持たせる発想が重要になります。以下は概念例です。

{
  "name": "prepare_vendor_payment",
  "description": "取引先への支払い申請案を作成する",
  "security_policy": {
    "require_hitl": true,
    "max_amount": 1000000,
    "scope": "restricted_to_approved_vendors",
    "execution_mode": "draft_only"
  }
}

ポイントは、AIに送金そのものを実行させるのではなく、申請案の作成までに留めることです。AIの自由度をコードレベルで制御し、人間が最終承認する構造を前提にします。

運用への影響

運用面では、AIエージェント用のID・権限管理、セッション分離、監査ログ、異常検知、緊急停止が新しい運用業務になります。AI時代のゼロトラストや脆弱性管理の考え方は、AIが変えるセキュリティ｜ゼロトラスト・RBVM・最新脅威を徹底解説でも整理しています。

どう捉えるべきか

AIエージェントは社員ではない。権限を持つソフトウェアとして、行動範囲と責任分界を定義すべきである。

AIエージェントは「優秀な部下」のように見えるかもしれません。しかし設計上は、AIを人間の社員ではなく、権限を持つソフトウェアとして扱う必要があります。そのため、人間のアカウントとは別に、AIエージェント専用のIDと権限を設計することが前提になります。新入社員にいきなり全社ファイルサーバーの編集権限を渡す会社はありません。AIにも同じ作法が必要です。

本質的な見方

生成AIセキュリティとAIエージェントセキュリティは、似ていて焦点が異なります。守るべき対象、攻撃経路、必要な対策が変わります。

表2：生成AIセキュリティとAIエージェントセキュリティの違い
観点	生成AIセキュリティ	AIエージェントセキュリティ
主な対象	LLM、チャットボット	ツールを使い行動するエージェント
主なリスク	誤回答、情報漏洩、不適切出力	誤実行、権限濫用、外部送信、連鎖影響
攻撃経路	プロンプト、入力、学習データ	プロンプト、ツール、API、メモリ、エージェント間通信
守るべきもの	出力品質、機密情報、利用ルール	業務プロセス、権限、実行環境、監査証跡
必要な対策	入力制御、出力検証、データ管理	最小権限、HITL、監査ログ、サンドボックス、停止手段
※ OWASP Top 10 for LLM Applications (2025) および OWASP Top 10 for Agentic Applications 2026（2025年12月9日公開版）を踏まえた整理（2026年4月時点）

限界と注意点

MCPは外部ツールへの「手」を、A2Aは他エージェントとの「会話」を与えます。便利さの基盤であると同時に、攻撃面の拡大でもあります。AIエージェント時代の主要リスクを以下に整理します。

表3：AIエージェント時代の主要リスク
リスク	概要	影響
プロンプトインジェクション	AIへの指示を外部入力で上書き・誘導	不正操作、機密出力、方針逸脱
間接プロンプトインジェクション	Web、メール、PDFに隠れた指示をAIが読む	気づかれない命令でAIが動く
Tool Misuse	AIがツールを意図外の形で使う	誤送信、誤更新、外部APIの不正利用
Goal Hijack	AIの目的が攻撃者側にすり替わる	目的逸脱、データ持ち出し
Identity & Privilege Abuse	AIエージェントのIDや権限が悪用される	なりすまし、権限昇格、不正アクセス
エージェントサプライチェーン汚染	第三者MCPサーバー、ツール記述子、外部エージェントなどが汚染される	起動時や実行時に不正な指示・ツール・依存先を取り込み、信頼境界が崩れる
エージェント間通信の脆弱性	A2Aなどのエージェント間通信で、認証不備、なりすまし、指示改ざんが起きる	偽メッセージによって複数エージェントが連鎖的に誤動作する
連鎖障害	ひとつのAIエージェントの誤判断や誤実行が、他のツールやエージェントへ波及する	自動化された業務フロー全体で被害が拡大する
Memory Poisoning	AIの記憶や参照データに悪意の混入	継続的な誤判断、業務ルールの汚染
過剰な自律性	広すぎる裁量と権限を与えてしまう	承認なしに重要操作が進む
監査不能	AIが何を読み、どう判断し、どのツールを実行したか追跡できない	事故後の原因究明・説明責任が困難になる

図解ポイント：MCPでは「AIエージェントと外部ツールの境界」、A2Aでは「自社エージェントと外部エージェントの境界」が信頼境界になります。ここを越える通信には、認証・認可・監査ログ・人間承認を置く必要があります。

これらのリスクは単独ではなく連鎖します。外部Webの隠し指示をAIが読み、MCP経由で社内DBを操作し、A2Aで別のエージェントへ結果を渡す。連鎖を断ち切る設計こそが、AIエージェントセキュリティの本質です。

実際に、A2Aのようなエージェント間通信では、Palo Alto Networksの研究が紹介するAgent Session Smugglingのような、セッション文脈を悪用する攻撃手法も報告されています。これは、AIエージェント同士が相手を信頼し、セッション文脈を引き継ぐ設計そのものが、新しい攻撃面になり得ることを示しています。

AIガバナンスや契約実務上の責任については、Agentic AIの暴走とAIガバナンスも合わせて読むと全体像がつかみやすくなります。

AIエージェントは、本当に暴走するのか

「AIエージェントが暴走する」と聞くと、SFのように感じるかもしれません。しかし企業で現実に問題になるのは、映画のような反乱ではありません。もっと静かで、もっと業務に近い暴走です。

本来送ってはいけない相手に、AIが見積書や顧客情報を送ってしまう
承認前のデータを、外部サービスや別エージェントに渡してしまう
古い社内文書を正しい前提として扱い、誤った判断を続けてしまう
複数のツールを組み合わせ、人間が想定していない操作を実行してしまう
本来は人間が確認すべき判断を、AIが自動で進めてしまう

これらは、AIが悪意を持つから起きるのではありません。設計されていない自由度、広すぎる権限、弱い監査、曖昧な責任分界が重なったときに起きます。だからこそ、AIエージェントセキュリティは「AIを止める技術」ではなく、AIを安全に働かせるための業務設計なのです。

実務ではどう判断するか

最小権限・人間承認・監査ログ・サンドボックス・ゼロトラスト。この5つを満たさない導入は、PoCで止まる。

AIエージェントを本番運用するか、見送るか、いつ着手するか。判断には設計原則と組織側の準備状況の両方が必要です。

立場によって見るべきポイントは違う

AIエージェントセキュリティは、情報システム部門だけのテーマではありません。経営、開発、法務、現場部門が同じ地図を持ち、それぞれの責任範囲で判断する必要があります。

表4：立場別に見るべきAIエージェントセキュリティの論点
立場	見るべきポイント	確認すべき問い
経営者	事業リスク、責任分界、導入判断	AIに任せる業務と任せない業務を決めているか
CTO・開発責任者	アーキテクチャ、権限設計、監査ログ	AIエージェントの実行環境を制御できているか
情報システム部門	ID管理、アクセス制御、SaaS連携	AIのアカウントと権限を管理対象に入れているか
法務・コンプライアンス	契約、個人情報、説明責任	AIが行った操作の責任範囲を定義しているか
現場部門	業務フロー、承認、例外処理	AIが止まるべき場面を定義しているか

判断基準

先ほどの問い「AIにどこまで実行させてよいのか?」に答えるための判断軸はこの5つです。技術そのものではなく、業務統制の観点から評価します。

最小権限：AIに業務に必要な範囲のデータとツールだけを許可する。読む・書く・送信・削除・外部連携を細かく分け、一括許可しない
人間承認(HITL)：外部送信、契約、支払い、削除、個人情報処理など重要操作は必ず人間が承認する構造にする
監査ログ：何を読み、どのツールを使い、どう判断し、何を実行したかを記録する。ログがなければ事故後の説明責任が果たせない
サンドボックス：いきなり本番接続せず、検証環境・読み取り専用環境・ダミーデータで行動パターンを確認してから段階的に権限を広げる
ゼロトラスト：AIだから信じるのではなく、出力・判断・実行要求を都度検証する。AIエージェント自身にIDを付与し、参加業務と権限を管理する

企業が最初に決めるべき5つのこと

AIエージェントを本格導入する前に、企業は少なくとも次の5つを決める必要があります。ここが曖昧なままPoCを始めると、最初は便利に見えても、本番移行の段階で止まります。

表5：AIエージェント導入前に決めるべき5項目
No	決めること	理由
1	AIに任せる業務範囲	業務境界が曖昧だと、権限設計も曖昧になる
2	AIがアクセスできるデータ	機密情報、個人情報、顧客情報を分類する必要がある
3	AIが使えるツール	読み取り、作成、更新、削除、外部送信を分けて管理する
4	人間承認が必要な操作	重要操作をAIだけで完結させない
5	ログと責任分界	事故時に、誰が何を判断したか追えるようにする

向いているケース

定型・反復作業で、入力と出力の品質が検証可能な領域。たとえば、社内ドキュメント検索、議事録要約、定型レポート作成、コード補助、データ整形などです。誤った場合の影響範囲が限定的で、人間がレビュー可能なフローに組み込めることが条件になります。

向いていないケース

外部送信、支払い、契約、解約、人事評価、医療判断など、誤実行が回復不能な領域。これらは原則「AIが提案、人間が承認・実行」の構造を崩さないことが推奨されます。AIには下書きや候補生成までを任せ、最終送信や決定は必ず人間が行う形が、現実的な落としどころです。

よくある失敗

失敗パターンは独自価値が最も出やすい領域です。現場で繰り返し見られる典型例を挙げます。

権限の一括付与：PoCで「とりあえず全部読めるように」と広い権限を与え、本番でも縮小されないまま放置される
承認ポイントの省略：「便利さが落ちる」という理由で人間承認を外し、誤送信・誤更新が起きる
ログの欠落：AIが使うツール側のログだけ取り、AIの判断履歴・入力プロンプト・参照データを残さない
本番直結のPoC：検証段階から本番DBに書き込み権限を付け、ロールバック手段を用意していない
責任分界の曖昧さ：AI起因の事故時に誰が説明責任を負うか決めていない

導入全体の流れと組織設計の観点は、2026年、AIエージェント「実装元年」へとAI活用はなぜ失敗するのか?「Agentic AI」時代の全社OS化と組織設計の教科書を参照すると、技術選定と組織側の整備を並行して進めやすくなります。

一次情報からどこまで言えるか

OWASPやNISTの一次資料が示すのは、エージェント時代のリスク再分類である。事実は出ているが、運用設計は各社の責務だ。

AIエージェントセキュリティは、まだ業界標準が固まりきっていない領域です。だからこそ、一次情報と解釈を分けて扱うことが重要になります。

一次情報

主要な一次情報源は次のとおりです。いずれもAIエージェント時代のリスクと対策を整理する公式資料です。まずリスク全体像を掴みたい場合はOWASPとNIST、公共部門の視点を知りたい場合はCISAから読むと効率的です。

OWASP Top 10 for LLM Applications：Prompt Injection、Insecure Output Handling、Sensitive Information Disclosure、Excessive Agency など、LLMアプリの主要リスクを定義
OWASP Top 10 for Agentic Applications 2026：エージェント特有の10大リスク（ASI01 Agent Goal Hijack、ASI02 Tool Misuse、ASI03 Identity & Privilege Abuse、ASI04 Agentic Supply Chain Vulnerabilities、ASI05 Unexpected Code Execution、ASI06 Memory & Context Poisoning、ASI07 Insecure Inter-Agent Communication、ASI08 Cascading Failures、ASI09 Human-Agent Trust Exploitation、ASI10 Rogue Agents）を体系化。EchoLeakや各種エージェント系インシデントを含む実在事例を引きながら、代表的な攻撃パターンと緩和策をカテゴリごとに解説している
OWASP GenAI Security Project, Agentic AI Threats and Mitigations：エージェント特有のリスク(Tool Misuse、Goal Hijack、Identity & Privilege Abuse 等)と緩和策を体系化
NIST AI Risk Management Framework：AIシステムのリスク管理を統治・マッピング・測定・管理の4機能で整理
CISA Artificial Intelligence：政府機関視点でのAIセキュリティガイダンス

解釈

これらの一次情報が共通して示しているのは、AIエージェントのリスクは従来のサイバーセキュリティの延長ではないということです。プロンプト・ツール・メモリ・エージェント間通信という新しい攻撃面が加わり、リスクが連鎖する点が特徴です。一方で、運用設計の具体は各社の業務に依存します。標準ガイドはあくまで地図であり、実装は自社の業務プロセス側で行う必要があります。

関連リスクとして、AI生成コンテンツによるなりすましや偽情報の影響については、ディープフェイク対策：あなたの会社が40億円を失う前にも参考になります。

AIエージェントセキュリティ4本シリーズの地図

本記事は、AIエージェントセキュリティ4本シリーズの入口である。物語はここから、脅威、設計、導入チェックリストへ進む。

このシリーズでは、「AIエージェントは危ない」と不安を煽るのではなく、企業が安全に使うための設計思想を順番に整理します。

表6：AIエージェントセキュリティ4本シリーズの構成
回	テーマ	役割
第1回	AIエージェントセキュリティとは？	全体像、リスク、防御原則を整理する入口
第2回	プロンプトインジェクション2.0	AIエージェントを操る「見えない命令」の脅威を解説
第3回	AIエージェントのゼロトラスト設計	ID、権限、監査ログ、人間承認の実装思想を整理
第4回	AIエージェント導入チェックリスト	経営者・CTO・情シスが使える実務チェックリスト