はじめに——「正規のツールが、悪意ある引数で実行される」という新しい脅威
MCPサーバー、Function Calling、コードインタプリタ——AIエージェントが外部ツールを呼び出す仕組みは、2026年のAI活用において不可欠なインフラとなりました。
しかし、ここに見落とされがちな攻撃面があります。
当サイトでは、これまでAIエージェントのセキュリティについて多角的に解説してきました。MCPツールポイズニングやMCPセキュリティの包括ガイドでは「悪意あるツール定義そのものの改ざん」を、設定ファイル攻撃では「設定ファイルの書き換え」を、Agent-to-Agent出力汚染では「エージェント間通信の汚染」を、権限エスカレーションでは「権限の膨張」をそれぞれ扱いました。
では、ツール自体は正規であり、エージェントの権限も正規であるにもかかわらず、「引数」が悪意ある内容に操作される攻撃についてはどうでしょうか？
2026年にOWASPが公開した「Top 10 for Agentic Applications（ASI Top 10）」では、ASI02：Tool Misuse & Exploitation（ツールの誤用と悪用）がASI01（Agent Goal Hijack）に次ぐ第2位のリスクとして位置づけられています。実際に、MCPサーバー経由でのSQLインジェクション的な引数操作、ファイルシステム操作ツールへのパストラバーサル引数、API呼び出しツールへのSSRF誘導といった攻撃が報告されています。
この記事で得られること：ツール呼び出しにおける引数インジェクション攻撃の仕組みを理解し、入力バリデーション・引数サニタイズ・実行サンドボックスによる防御設計を、中小企業でも実装可能な具体例とともに学ぶことができます。
ツール呼び出しの攻撃面——何が狙われるのか
「ツール呼び出し乗っ取り」の全体像
AIエージェントがツールを呼び出す際の処理フローは、大きく3段階に分かれます。
- 意図解釈：LLMがユーザーの指示を解釈し、どのツールをどんな引数で呼び出すかを決定する
- 引数構成：LLMがJSON形式などで引数を生成し、ツールに渡す
- ツール実行：MCPサーバーやFunction Callingの仕組みを通じて、実際にツールが引数を受け取り処理を実行する
「ツール呼び出し乗っ取り」攻撃は、このフローの主にステップ1〜2を操作し、正規のツールに悪意ある引数を渡すことで被害を発生させます。ツール定義の改ざん（ツールポイズニング）とは異なり、ツール自体は正規であり、エージェントの権限も正規のまま悪用される点が特徴です。
引数攻撃の4つの分類
| 攻撃タイプ | 概要 | 具体例 |
|---|---|---|
| 引数インジェクション | 引数フィールドにSQLやシェルコマンドなどの制御構文を埋め込む | DBクエリツールの引数に '; DROP TABLE users; -- を注入 |
| 過剰引数（Excessive Arguments） | ツールのスキーマに定義されていない追加引数を渡し、想定外の動作を誘発する | {"query": "SELECT ...", "admin_mode": true} のように未定義フィールドを追加 |
| 型混同（Type Confusion） | 引数の型を意図的に変えて、バリデーションのバイパスや異常動作を引き起こす | 数値を期待するフィールドに配列やオブジェクトを渡す |
| 連鎖呼び出し操作 | 複数ツールの呼び出し順序や引数の依存関係を操作し、個々のツール単体では安全でも組み合わせで被害を発生させる | ファイル読み取りツール → メール送信ツールの連鎖で機密ファイルを外部送信 |
なぜこの攻撃が特に危険なのか
従来のWebアプリケーション攻撃（SQLインジェクション、コマンドインジェクション等）との決定的な違いは、攻撃者が直接ツールのAPIを叩く必要がない点です。攻撃者はプロンプトインジェクション、汚染されたドキュメント、悪意あるメールなど、LLMが読み取る「データ」に攻撃ペイロードを仕込むだけで、LLM自身が攻撃用の引数を「正しい形式で」生成してツールに渡してくれます。
つまり、人間がフォームに入力する従来のインジェクション攻撃と違い、入力値のフォーマットは完璧であり、通常の入力バリデーション（型チェック、長さ制限など）ではすり抜けてしまう可能性があります。
実際に報告されている攻撃事例
事例1：MCPサーバー経由のSQLインジェクション
2025年後半、セキュリティ研究者がAnthropicのリファレンス実装であるPostgres MCPサーバーにSQLインジェクション脆弱性を発見しました。このMCPサーバーはread-only（読み取り専用）として設計されていたにもかかわらず、引数の不十分なサニタイズにより、攻撃者がトランザクション制御を操作して任意のSQL文を実行できる状態でした。
また、別の実例として、AIコーディングエージェント（Cursor）がSupabaseデータベースにMCP経由で接続していたケースでは、攻撃者がサポートチケットに隠し命令を埋め込み、エージェントがそれを読み取って機密テーブルからトークンを抽出するという攻撃が成功しています。
ポイント：MCPサーバー自体は正規であり、エージェントも正規の権限で動作しています。問題は「引数」が汚染されていたことです。データベースはクエリを正しく実行しただけであり、リクエストが侵害されたエージェント経由であることを知る術がありませんでした。
事例2：ファイルシステム操作ツールへのパストラバーサル
MCPサーバー実装のセキュリティ調査によると、調査対象の22%がディレクトリトラバーサルまたは任意のファイル読み取りの脆弱性を持っていました。ファイル操作ツールで ../../etc/passwd のようなパストラバーサル引数が処理されるケースです。
事例3：コマンドインジェクション
同じ調査では、調査対象の43%にコマンドインジェクション脆弱性が存在していました。シェルコマンドを引数として受け取るツールにおいて、引数のサニタイズが不十分であれば、任意のOS コマンドを実行される危険性があります。
事例4：連鎖呼び出しによる機密データ外部送信
OWASP ASI Top 10で紹介されている「EchoLeak」の攻撃パターンでは、攻撃者がメールに隠しペイロードを埋め込み、Microsoft 365 Copilotがそれを処理した結果、機密メールやチャットログがユーザーの認知なしに外部に送信されました。これは単一のツール呼び出しでは検知が難しい連鎖攻撃の典型例です。
防御設計①：入力バリデーション——JSON Schema厳格化と許可リスト
なぜ入力バリデーションが第一の防御線なのか
ツール呼び出し乗っ取り攻撃に対する最も基本的な防御は、ツールが受け取る引数を厳格に制限することです。LLMが生成した引数であっても、ツール実行前に必ずバリデーションを行う必要があります。
JSON Schemaによる引数定義の厳格化
MCP/Function Callingでは、ツールの引数をJSON Schemaで定義します。以下の原則で厳格化しましょう。
| 原則 | 設定方法 | 防げる攻撃 |
|---|---|---|
| 追加プロパティの禁止 | "additionalProperties": false | 過剰引数攻撃 |
| 型の厳格指定 | 各フィールドに "type": "string" 等を明示 | 型混同攻撃 |
| 列挙値による制限 | "enum": ["read", "list"] | 引数インジェクション |
| 文字列パターンの制限 | "pattern": "^[a-zA-Z0-9_]+$" | 特殊文字を含むインジェクション |
| 長さ・範囲の制限 | "maxLength": 100、"minimum": 0 | バッファオーバーフロー的な攻撃 |
実装例：ファイル読み取りツールの引数スキーマ
以下は、ファイル読み取りツールの引数を安全に定義するJSON Schemaの例です。
{
"type": "object",
"properties": {
"file_path": {
"type": "string",
"pattern": "^[a-zA-Z0-9_/\\-\\.]+$",
"maxLength": 200,
"description": "読み取るファイルのパス（英数字・スラッシュ・ハイフン・アンダースコア・ドットのみ）"
},
"encoding": {
"type": "string",
"enum": ["utf-8", "shift_jis", "euc-jp"],
"default": "utf-8"
}
},
"required": ["file_path"],
"additionalProperties": false
}重要："additionalProperties": false は必須です。これがないと、LLMが予期しないフィールドを追加して過剰引数攻撃が成立する可能性があります。
許可リスト（Allowlist）による制限
バリデーションの中でも最も強力なのが、許可リスト方式です。
- ファイルパス：アクセスを許可するディレクトリを明示的に列挙し、それ以外を拒否する
- SQLクエリ：SELECT文のみ許可し、INSERT/UPDATE/DELETE/DROPを拒否する。さらに、テーブル名を許可リストで制限する
- API呼び出し：呼び出し先のURLドメインやエンドポイントを許可リストで制限する
「何を禁止するか（拒否リスト）」ではなく「何を許可するか（許可リスト）」で考えることが鉄則です。攻撃者は常に新しいバイパス方法を見つけますが、許可されていないものは実行できません。
防御設計②：ツール種別ごとのサニタイズ実装
ツールの種類によって、必要なサニタイズ処理は異なります。ここでは代表的な3カテゴリについて、具体的なサニタイズ方針を示します。
ファイル操作ツールのサニタイズ
| チェック項目 | 実装方針 |
|---|---|
| パストラバーサル防止 | 引数に .. が含まれていたら拒否。パスを正規化（resolve）してからベースディレクトリ内かどうかを確認する |
| シンボリックリンク対策 | シンボリックリンクの解決後に、最終パスがベースディレクトリ内にあるか再確認する |
| ファイル拡張子制限 | 許可する拡張子（.txt, .csv, .json等）を明示的にリスト化し、それ以外を拒否する |
| ファイルサイズ上限 | 読み取りファイルのサイズに上限を設け、巨大ファイルの読み込みによるDoSを防ぐ |
DB操作ツールのサニタイズ
| チェック項目 | 実装方針 |
|---|---|
| パラメータ化クエリ | SQL文の構築に文字列結合を使わず、必ずパラメータ化クエリ（プリペアドステートメント）を使用する |
| クエリタイプ制限 | SELECT文のみ許可し、DDL（CREATE, DROP, ALTER）やDML（INSERT, UPDATE, DELETE）を禁止する |
| テーブル・スキーマ制限 | アクセス可能なテーブルとカラムを許可リストで明示的に制限する |
| 結果行数の制限 | クエリ結果の返却行数に上限を設け、大量データの抽出を防止する |
| 専用ユーザーの使用 | MCPサーバー用に最小権限の専用DBユーザーを作成し、READ-ONLYロールを付与する |
教訓：前述のPostgres MCPサーバーの脆弱性は、まさにパラメータ化クエリを使わず文字列結合でSQL文を構築していたことが原因でした。25年以上前から知られているベストプラクティスが、AIインフラでも同じように重要です。
API呼び出しツールのサニタイズ
| チェック項目 | 実装方針 |
|---|---|
| URL許可リスト | 呼び出し可能なドメイン・エンドポイントを許可リストで制限し、SSRF（サーバーサイドリクエストフォージェリ）を防止する |
| 内部ネットワーク遮断 | localhost、127.0.0.1、プライベートIPアドレス範囲（10.x.x.x、192.168.x.x等）への呼び出しを禁止する |
| リクエストヘッダー制限 | ツールが送信するHTTPヘッダーの種類と値を制限し、認証ヘッダーの不正挿入を防ぐ |
| レスポンスサイズ制限 | APIレスポンスのサイズに上限を設け、大量データの取得を防止する |
防御設計③：ツール実行のサンドボックス化
入力バリデーションとサニタイズは「攻撃を検知して拒否する」防御ですが、すべての攻撃をバリデーションで防ぐことは現実的には困難です。そこで必要になるのが、万が一攻撃が成功しても被害を最小限に抑える「サンドボックス」です。
サンドボックス化の3層構造
| 層 | 対策 | 目的 |
|---|---|---|
| プロセス分離 | ツール実行をDockerコンテナや専用プロセスで分離する | ツールが侵害されても、ホストシステムや他のツールに影響が及ばないようにする |
| ネットワーク制限 | ツール実行環境のネットワークアクセスを最小限に制限する（egress制御） | 侵害されたツールが外部に機密データを送信することを防ぐ |
| タイムアウト設計 | ツール実行に時間制限を設け、一定時間を超えた実行を強制終了する | 無限ループや再帰的なツール呼び出しによるリソース枯渇（DoS）を防ぐ |
中小企業でも実装可能なサンドボックス構成
大規模なKubernetesクラスタがなくても、以下のようなアプローチでサンドボックス化を実現できます。
- Docker Composeによるツール分離：MCPサーバーをDockerコンテナとして実行し、ファイルシステムのマウントを最小限にする。
read_only: trueでコンテナ内のファイルシステムを読み取り専用にする。 - ネットワークポリシーの設定：Dockerのネットワーク設定で、ツールコンテナが接続できるネットワークを制限する。外部への通信が不要なツールは
network_mode: "none"で完全に遮断する。 - リソース制限：CPUとメモリの上限を設定し、リソース枯渇攻撃を防ぐ。
- 実行タイムアウト：各ツール呼び出しに30秒〜60秒のタイムアウトを設定する。
OWASP ASI Top 10の推奨：OWASP ASI Top 10のASI02対策として、「ツールをサンドボックス環境で実行し、egress制御を適用する」「破壊的なアクションには明示的な確認を要求する」ことが推奨されています。
防御設計④：監査ログ設計と異常検知ルール
ツール呼び出しの監査ログに記録すべき項目
攻撃の検知と事後調査のために、すべてのツール呼び出しについて以下の情報をログに記録します。
| 項目 | 内容 | 記録の目的 |
|---|---|---|
| タイムスタンプ | ツール呼び出しの日時（UTC） | 時系列分析 |
| 呼び出し元 | どのエージェント/セッションが呼び出したか | 攻撃元の特定 |
| ツール名 | 呼び出されたツールの識別子 | 攻撃対象の特定 |
| 引数（完全な内容） | ツールに渡された引数のJSON全文 | 攻撃ペイロードの分析 |
| バリデーション結果 | 引数バリデーションの合否とエラー内容 | バイパスされたバリデーションの特定 |
| 実行結果 | 成功/失敗、返却値の概要 | 攻撃の成否確認 |
| 実行時間 | ツール実行にかかった時間 | DoS攻撃の検知 |
異常検知ルールの設計
以下のパターンを検知ルールとして設定し、アラートを発報する体制を構築しましょう。
| 検知パターン | 説明 | 想定される攻撃 |
|---|---|---|
| バリデーション失敗の急増 | 短時間にバリデーションエラーが一定回数以上発生 | 引数インジェクションの試行 |
| 通常と異なるツール呼び出しパターン | 普段呼び出されないツールが突然使用される、または呼び出し順序が異常 | 連鎖呼び出し操作 |
| 異常に長い引数 | 引数のサイズが通常の使用パターンから大幅に逸脱 | ペイロード埋め込み |
| 再帰的なツール呼び出し | 同じツールが短時間に繰り返し呼び出される | ループ攻撃によるDoS |
| 機密リソースへのアクセス試行 | システムファイル、環境変数、認証情報を含むパスやテーブルへのアクセス | データ窃取 |
レッドチーミングの手法を活用して、これらの検知ルールが実際に機能するかを定期的にテストすることも重要です。また、本番投入前のテスト段階で、異常検知ルールの網羅性を確認しましょう。
防御の全体設計——多層防御のフレームワーク
ここまでの防御設計を統合すると、以下の多層防御フレームワークになります。
| 層 | 対策 | 対応する攻撃 | 関連記事 |
|---|---|---|---|
| 第1層：スキーマ防御 | JSON Schema厳格化、型制約、許可リスト | 過剰引数、型混同 | — |
| 第2層：引数サニタイズ | パラメータ化クエリ、パス正規化、URL許可リスト | 引数インジェクション、パストラバーサル、SSRF | — |
| 第3層：権限制御 | 最小権限のDB/APIユーザー、ツールごとのスコープ制限 | 権限エスカレーション | 権限エスカレーション対策 |
| 第4層：実行サンドボックス | コンテナ分離、ネットワーク制限、タイムアウト | 被害拡大の抑止 | ガードレール設計 |
| 第5層：監査・検知 | 全呼び出しのログ記録、異常検知ルール | 攻撃の検知と事後分析 | レッドチーミング |
鍵管理やサプライチェーン攻撃対策、ステート管理と組み合わせることで、エージェントシステム全体のセキュリティ体制を構築できます。
中小企業が今すぐ実施すべきアクションリスト
| 優先度 | アクション | 所要時間の目安 |
|---|---|---|
| 即時 | 使用中のMCPサーバー/Function Callingツールの引数スキーマに additionalProperties: false を追加する | 30分〜1時間 |
| 即時 | DB操作ツールがパラメータ化クエリを使用しているか確認する | 1時間 |
| 今週中 | ファイル操作ツールにパストラバーサル防止のバリデーションを追加する | 2〜3時間 |
| 今週中 | API呼び出しツールにURL許可リストを実装する | 2〜3時間 |
| 今月中 | ツール実行のログ記録を実装する | 半日〜1日 |
| 今月中 | MCPサーバーをDockerコンテナで分離実行する構成に移行する | 1〜2日 |
| 今四半期中 | 異常検知ルールの設計・実装・テストを行う | 2〜3日 |
よくある質問（Q&A）
Q1. Function Callingだけを使っていてMCPは使っていません。この攻撃は関係ありますか？
関係あります。Function Callingでも、LLMが生成した引数がそのまま外部ツール（API、データベース、ファイルシステム）に渡される構造は同じです。MCPに限定された問題ではなく、AIエージェントが外部ツールを呼び出すすべての仕組みに共通するリスクです。
Q2. クラウドのマネージドMCPサーバーを使っていれば安全ですか？
クラウドプロバイダーのマネージドサービスは基盤レベルのセキュリティは提供しますが、引数のバリデーションはアプリケーション側の責任です。マネージドサービスを使っていても、ツールに渡す引数のスキーマ定義やサニタイズは自分で実装する必要があります。
Q3. LLMのプロンプトに「悪意ある引数を生成しないで」と書けば防げますか？
防げません。プロンプトインジェクション攻撃はまさにこのような指示を上書きする手法です。プロンプトレベルの防御は補助的な対策にはなりますが、入力バリデーションやサンドボックスといったコードレベルの防御が必須です。
Q4. 自社でAIエージェントを開発していない場合、どうすればいいですか？
SaaSとしてAIエージェントを利用している場合でも、そのサービスがどのようなツール連携を行っているか、引数のバリデーションがどう実装されているかをベンダーに確認しましょう。本番投入前のテストやガードレール設計の考え方を活用して、利用するサービスのセキュリティ体制を評価できます。
Q5. OWASP ASI Top 10のASI02とASI05（Unexpected Code Execution）の違いは何ですか？
ASI02はツール全般の引数操作による誤用・悪用を指し、ASI05はその中でも特にコード実行ツール（コードインタプリタ等）の悪用に特化しています。ASI05はASI02のサブカテゴリとして位置づけられており、コード実行を伴うツールには特に厳格なサンドボックスが必要です。
まとめ——「正規のツール」こそ最大の攻撃面になり得る
AIエージェントのツール呼び出し乗っ取り攻撃は、「ツール自体は正規」「権限も正規」「引数のフォーマットも正しい」という三重の正当性の裏に潜む脅威です。
防御の要点を3つにまとめます。
1. 引数を信頼しない：LLMが生成した引数であっても、ツール実行前に必ずバリデーションとサニタイズを行ってください。JSON Schemaの厳格化と許可リスト方式が第一の防御線です。
2. 被害を封じ込める：バリデーションを突破された場合に備え、ツール実行をサンドボックスで分離し、権限は最小限にしてください。Docker Composeによるコンテナ分離は、中小企業でも現実的に実装可能です。
3. 異常を検知する：すべてのツール呼び出しをログに記録し、異常パターンの検知ルールを設定してください。攻撃は「成功するまで気づかれない」ことが多く、検知の仕組みがなければ被害は拡大し続けます。
AIエージェントの能力が高まるほど、ツール呼び出しの攻撃面も拡大します。OWASP ASI Top 10が示すように、「ツールの誤用・悪用」は2026年のエージェントセキュリティにおいて最重要課題の一つです。今日から防御設計に着手しましょう。
参考リンク
- OWASP GenAI Security Project
- Trend Micro「Why a Classic MCP Server Vulnerability Can Undermine Your Entire AI Agent」
- Datadog Security Labs「MCP vulnerability case study: SQL injection in the Postgres MCP server」
- Akamai「How to Prevent Command Injection and SQL Injection Attacks over MCP」
免責事項：本記事は2026年3月時点の公開情報に基づく情報提供であり、特定製品・サービスの安全性を保証するものではありません。セキュリティ対策の実装にあたっては、自社の環境やリスクに応じた専門家への相談を推奨します。OWASP ASI Top 10やMCPの仕様は更新される可能性がありますので、最新情報は各公式ソースで確認してください。
コメント