「AXプロジェクト実践ガイド」シリーズの第3回目となる本稿は、エンタープライズ環境でAIを活用したソリューションを開発・展開するための体系的なアプローチを詳述する全5回のガイドです。本シリーズは、企画 (第1回)、開発 (第2回)、ツールとModel Context Protocol (MCP) (第3回)、ガードレール (第4回)、およびセキュリティ、ガバナンス、運用 (第5回) を網羅しています。本稿では、SIプロジェクトにおけるインターフェース設計と構築フェーズに焦点を当て、主要な成果物としてインターフェース仕様書、MCPツールのアローリスト、AIエージェントインタラクションのためのパーミッションマトリックスを扱います。その目的は、AIエージェントが内部システムにアクセスし操作するための安全で管理されたメカニズムを確立することであり、これはエンタープライズAI導入の重要な要素です。
AXプロジェクト実践ガイド 連載目次
- AXプロジェクト実践ガイド 第1回 — 戦略的なAIユースケースの選定と要件定義
- AXプロジェクト実践ガイド 第2回 — 既存システム向けオープンソースAI統合パターン
- AXプロジェクト実践ガイド 第3回 — AIエージェントの安全な接続：MCPツール設計、OAuth、防御策のプレイブック (この記事)
- AXプロジェクト実践ガイド 第4回 — LLMガードレール：セキュアなAI導入のための必須設計とレッドチームテスト
- AXプロジェクト実践ガイド 第5回 — AIセキュリティガバナンスの要：LLMOps、脅威モデリング、本番稼働のための規制遵守
MCPの基本 (クライアント/サーバー；ツール、リソース、プロンプト)
AIエージェントを企業内の内部システムと統合することは、重大なセキュリティ上および運用上の課題を提示します。Model Context Protocol (MCP) は、エージェントが定義された「ツール」と「リソース」を通じてバックエンドサービスと対話するための構造化されたフレームワークを提供し、操作が予測可能、観測可能、制御可能であることを保証します。MCPは、AIエージェントがクライアントとして機能し、内部システムロジックをカプセル化するMCPサーバーによって公開される機能を呼び出すクライアント/サーバーアーキテクチャを促進します。
MCPの基本：クライアント、サーバー、ツール、リソース
MCPサーバーは、特定の動作またはクエリ機能を表す一連のツールを公開します。これらのツールは、その名前、説明、厳密に型付けされたパラメーターを含むメタデータで記述され、AIエージェントはこれらを解釈していつどのように呼び出すかを決定します。リソースは、エージェントがクエリできるデータエンティティまたはデータアクセスパターンを表します。MCPツールとリソースの構造化された性質は、プロンプトを介した大規模言語モデル (LLM) からの任意のコード実行や曖昧な指示に関連するリスクを軽減するのに役立ちます。
公式PythonおよびTypeScript SDKとMCP Inspector
開発を効率化するために、PythonやTypeScriptなどの一般的なプログラミング言語向けに公式SDKが提供されています。これらのSDKは、MCPクライアントとサーバーの両方の実装を簡素化し、ツール登録、呼び出し、応答処理のための抽象化を提供します。デバッグおよび運用監視のためには、MCP Inspectorのようなツールが非常に貴重です。MCP Inspectorは、ツールの発見、エージェントの意思決定、ツールの実行フローに対する可視性を提供し、開発中および本番環境における重要なオブザーバビリティ層を提供します。
読み取り専用DBビュー、チケット、ドキュメント検索のためのMCPサーバーの例
AIエージェントが対話する可能性のある内部システムの具体的な例を考えてみましょう：
- 読み取り専用データベースビュー： MCPサーバーは、在庫データベースをクエリするツールを公開し、エージェントが書き込みアクセスなしで製品の詳細を取得できるようにします。
- チケットの作成/更新： 課題追跡システムでチケットを作成または更新するツールは、エージェントがサービスリクエストやインシデント報告を自動化することを可能にします。
- ドキュメント検索： エージェントは、内部のナレッジベースや文書管理システムを検索するツールを使用して、ユーザーのクエリに関連する情報（例：RAGパイプライン）を取得することができます。
ツール設計の原則 (狭いスコープ、型付きパラメーター、冪等性、ドライラン、明示的な副作用)
MCPツールの設計は、システム整合性とセキュリティを維持するために最も重要です。各ツールは、攻撃対象領域を最小限に抑え、制御を最大化する原則に準拠し、特定の明確に定義された目的を果たすように慎重に作成されるべきです。
MCPツールを設計する際には、以下の原則への準拠が不可欠です：
- 狭いスコープ： 各ツールは、単一の明確に定義された責任を持つべきです。複数の無関係な操作を実行するモノリシックなツールを作成することは避けてください。
- 型付きパラメーター： 厳密に型付けされたパラメーターを使用して、厳格な入力検証を強制します。これにより、エージェントが悪意のあるデータや不正な形式のデータを注入するのを防ぎます。
- 冪等な操作： 可能な限り、ツールを冪等に設計します。これは、同じパラメーターでの繰り返し実行が意図しない副作用なしに同じ結果をもたらすことを意味します。これは、再試行や偶発的な重複操作を防ぐために不可欠です。
- ドライラン機能： 書き込み操作や破壊的な操作を実行するツールについては、「ドライラン」モードを実装します。これにより、エージェントや人間のオペレーターは、実際の実行前に意図された変更をプレビューできます。
- 明示的な副作用： ツールが持つ可能性のある副作用を明確に文書化し、伝達します。エージェントは、ツールを呼び出すことの影響を認識している必要があります。
以下は、製品情報を取得するためのシンプルなPython MCPツール定義の例です。
from mcp_sdk.tool import Tool, Parameter
from typing import Dict
class GetProductInfoTool(Tool):
name = "get_product_info"
description = "Retrieves detailed information for a given product ID."
parameters = [
Parameter(name="product_id", type=str, description="The unique identifier of the product.", required=True)
]
def execute(self, product_id: str) -> Dict[str, any]:
# Example data retrieval logic
if product_id == "P1001":
return {"id": "P1001", "name": "Wireless Mouse", "price": 25.99, "stock": 150}
elif product_id == "P1002":
return {"id": "P1002", "name": "Mechanical Keyboard", "price": 89.00, "stock": 75}
else:
return {"error": "Product not found"}
Keycloak、ユーザーごとの委任トークン、最小権限、OPAポリシーを用いたOAuth
効果的な認可は、不正なAIエージェントの行動を防ぐために不可欠です。OAuthをOpen Policy Agent (OPA) のようなポリシーエンジンと組み合わせることで、強力で柔軟なアクセス制御フレームワークが提供されます。
KeycloakとのOAuth
KeycloakのようなIdentity Provider (IdP) とともに実装されることが多いOAuth 2.0は、安全な委任アクセスを可能にします。AIエージェントがユーザーに代わって行動する必要がある場合、ユーザーごとの委任トークンが不可欠です。ユーザーはエージェントに同意を与え、エージェントは特定のスコープを持つアクセストークンを受け取り、そのアクションをユーザーが明示的に認可したものに制限します。これにより、エージェントのパーミッションが人間のユーザーの特権から派生し、それに制約されることが保証され、最小権限の原則が遵守されます。
最小権限の原則とパーミッションマトリックス
最小権限の原則は、AIエージェントとそれに関連するツールには、指定された機能を実行するために必要な最小限のパーミッションのみが付与されるべきであると定めています。これには、各エージェントが呼び出しを許可されたMCPツールにマッピングされ、各ツールが必要とする特定のOAuthスコープまたは基盤となるシステムパーミッションにマッピングされる、慎重に構築されたパーミッションマトリックスが必要です。エージェントの機能が進化するにつれて、このマトリックスを定期的に監査し更新することが不可欠です。
OPAポリシー
Open Policy Agent (OPA) は、クラウドネイティブスタック全体でのポリシー強制のための統一されたフレームワークを提供します。OPAの宣言型ポリシー言語であるRegoにより、セキュリティチームはアプリケーションロジックとは独立して、きめ細かな認可ルールを定義できます。MCPの場合、OPAはツール呼び出しリクエストにポリシーを適用するために使用でき、エージェントのID、リクエストされたツール、パラメーター、ユーザーの委任パーミッションなどの属性をチェックします。これにより、動的でコンテキストを認識した認可決定が可能になります。
ツールアクセスを強制するOPAポリシーのスニペット例：
package mcp.authz
default allow = false
allow {
input.user.roles[_] == "admin"
input.tool.name == "create_ticket"
}
allow {
input.user.roles[_] == "support"
input.tool.name == "get_product_info"
}
allow {
input.user.roles[_] == "marketing"
input.tool.name == "search_documents"
input.tool.parameters.category == "public_content"
}
脅威 (不正なツール記述、ツール結果を介したプロンプトインジェクション、Confused Deputy、信頼できないサードパーティサーバー)
AIエージェントと内部システムの統合は、いくつかの明確なセキュリティ上の脅威をもたらします：
- 不正なツール記述： 悪意のあるアクターが誤解を招く、または有害なツール記述を注入し、エージェントに意図しない、または危険なツールを呼び出させる可能性があります。
- ツール結果を介したプロンプトインジェクション： エージェントの出力が、悪意のあるツール応答によって操作され、その後のエージェントのアクションが不正または有害なものになる可能性があります。これは間接的なプロンプトインジェクションの一形態です。
- Confused Deputy Problem (混乱した代理問題)： 正当だが昇格された特権（例：サービスアカウントを介して）で動作するAIエージェントが、悪意のある入力（ユーザーまたは他のエージェントから）によって、入力の発信元が認可されていないアクションを実行するようにだまされる可能性があります。
- 信頼できないサードパーティサーバー： サードパーティのMCPサーバーでホストされているツールを統合すると、サプライチェーンのリスクが生じます。サードパーティサーバーが侵害された場合、機密データが公開されたり、悪意のあるツールが提供されたりする可能性があります。
防御策 (アローリスト、固定バージョン、書き込み前のユーザー確認、サンドボックス化、ログ記録)
これらの脅威を軽減するには、多層防御戦略が必要です：
- ツールのアローリスト： エージェントが発見および呼び出しを許可されているMCPツールを指定する厳格なアローリストを実装します。アローリストにないツールはすべて拒否されます。
- 固定されたツールバージョン： 重要なツールについては、そのバージョンを固定し、脆弱性や悪意のある機能を導入する可能性のあるサイレントアップデートを防ぎます。
- 書き込み操作前のユーザー確認 (HITL)： 機密性の高いまたは破壊的な書き込み操作を実行するツールについては、実行前に明示的なユーザー確認を必要とするHuman-In-The-Loop (HITL) ワークフローを実装します。
- サンドボックス化： MCPツールロジックを隔離された環境（例：コンテナ、最小限のパーミッションを持つサーバーレス関数）内で実行します。これにより、ツールが侵害された場合の被害範囲が制限されます。
- ログ記録と監査： すべてのエージェントの決定、ツール呼び出し、パラメーター、応答について包括的なログ記録を実装します。これにより、フォレンジック分析および異常検出のための監査証跡が提供されます。
以下の表は、AIエージェントとツールの統合における一般的な脅威とそれに対応する防御策をまとめたものです。
| 脅威カテゴリ | 説明 | 主要な防御策 |
|---|---|---|
| 不正なツール記述 | 悪意のある記述がエージェントを意図しない行動に誘導する。 | ツールのアローリスト、固定されたツールバージョン、コードレビュー |
| プロンプトインジェクション (ツール結果を介して) | 悪意のあるツール出力がその後のエージェントの挙動に影響を与える。 | 入出力のサニタイズ、文脈フィルタリング、ユーザー確認 |
| Confused Deputy Problem | 高い特権を持つエージェントが、低特権の入力によってだまされる。 | 最小権限、OPAポリシー、ユーザー委任トークン |
| 信頼できないサードパーティサーバー | 侵害された外部ツールプロバイダーからのリスク。 | ベンダーデューデリジェンス、ネットワークセグメンテーション、サンドボックス化 |
| 不正なツールアクセス | 適切な認可なしにツールを呼び出すエージェント。 | OAuth、OPAポリシー、パーミッションマトリックス |
LangfuseおよびOpenTelemetryを用いたトレース
AIエージェントのランタイム挙動とツールインタラクションを理解することは、セキュリティと運用上の卓越性にとって不可欠です。分散トレースおよびオブザーバビリティツールは、深い洞察を提供します。
- Langfuse： LLMアプリケーションに特化したプラットフォームであるLangfuseは、エージェントの推論、LLM呼び出し、ツール利用、および全体的なエージェントワークフローのトレースを可能にします。これにより、問題の特定、意思決定パスの理解、パフォーマンスの監視に役立ちます。
- OpenTelemetry： ベンダーニュートラルな標準として、OpenTelemetryはさまざまなコンポーネントからテレメトリーデータ（トレース、メトリクス、ログ）を計測および収集することを可能にします。MCPサーバーとAIエージェントをOpenTelemetryと統合することで、マイクロサービスアーキテクチャ全体でエンドツーエンドの可視性が確保され、エージェントのアクションをバックエンドシステムのパフォーマンスやセキュリティイベントと関連付けることができます。
この回の成果物サンプル
以下は、オープンソースのAXラボを基にしたこのフェーズの成果物サンプルです。組織の環境に合わせて調整してご利用ください。要件定義書の全体(Excel)はAXプロジェクト実践ガイドのハブからダウンロードできます。
MCPツール許可リスト — エージェントに公開するツールと遮断するツール — 副作用と権限範囲に基づく表で見る: MCPツール許可リスト
| ツール(Tool) | 目的 | 主な入力(Args·Schema) | 副作用 | 許可/遮断 | 権限範囲(Scope) | 検証ケース(正常 / 悪用) | 状態 |
|---|---|---|---|---|---|---|---|
| search_documents(query, scope) | ナレッジ検索(RAG) | query:str, scope:dept|public | read-only | 許可 | 委任ユーザーの部署 | 正常: 出典付きの回答 / 悪用: scope=all の要求 → 部署に縮小 | 適用 |
| get_order_status(order_id) | ERPの受注照会(読み取り専用ビュー) | order_id:str | read-only | 条件付き | 担当取引先の受注のみ | 悪用: 他取引先IDの列挙 → 404・レート制限 | 適用 |
| query_db(sql) | 任意のSQL実行 | sql:str | 破壊的な可能性 | 遮断 | — (定義済みクエリのツールで代替) | ツールを非公開 | 未適用 |
| create_ticket(title, body) | 業務チケットの作成 | title:str, body:str | 保存(mutating) | 条件付き | 委任ユーザーの名義 | ユーザー確認後に作成 / 悪用: 大量作成 → 確認・レート制限 | 適用 |
| update_ticket_status(id, status) | チケットのステータス変更 | id:str, status:enum | 保存(mutating) | 条件付き | 本人担当のチケット | 悪用: 他人のチケットをクローズ → 拒否 | 一部 |
| send_notification(channel, text) | 社内通知の送信 | channel:enum, text:str | 外部・副作用 | 条件付き | 許可チャネルのリスト | 悪用: 外部Webhook・社外秘の本文 → 遮断・承認 | 適用 |
| request_decision(case) | 判定要求(ルールエンジンのelse) | case:json(schema) | 保存(mutating) | 許可 | decisions:write | 低信頼度 → レビューキュー / 悪用: スキーマ外フィールド → 拒否 | 適用 |
| read_secret(name) | シークレットの参照 | name:str | 機微 | 遮断 | — (Vaultによる実行時注入) | ツールを非公開 / シークレット開示の要求を拒否 | 未適用 |
| run_shell(cmd) | コマンド実行 | cmd:str | 破壊的・実行 | 遮断 | — (サンドボックス作業のみ) | ツールを非公開 | 未適用 |
FAQ (よくある質問)
Q1: AIエージェントのセキュリティにおけるModel Context Protocol (MCP) の主な目的は何ですか？
A1: MCPの主な目的は、AIエージェントが内部エンタープライズシステムと対話するための、標準化され、構造化され、安全な方法を提供することです。これは、型付きパラメーターを持つ明確なツールとリソースを定義することにより達成され、エージェントのアクションに対するより良い制御、観測性、および認可を可能にします。
Q2: OAuthはAIエージェントとツールのインタラクションのセキュリティにどのように貢献しますか？
A2: OAuthは委任された認可を可能にし、AIエージェントが特定の時間制限されたパーミッション（スコープ）で人間のユーザーに代わって行動できるようにします。これにより、エージェントがユーザーの権限の下で動作し、最小権限の原則に準拠することが保証され、不正なアクセスや行動を防ぎます。
Q3: AIエージェントの文脈における「Confused Deputy Problem (混乱した代理問題)」とは何ですか？
A3: Confused Deputy Problemは、正当だが昇格された特権を持つAIエージェントが、より低い特権を持つユーザーまたはエンティティによって、リクエストの発信元が実行を認可されていないアクションを実行するようにだまされるときに発生します。これは、強力な認可ポリシーとユーザー委任トークンを通じて軽減できます。
Q4: ツールのアローリストと固定されたツールバージョンは、なぜ重要な防御策と見なされますか？
A4: ツールのアローリストは、AIエージェントが明示的に承認され検証されたツールとのみ対話することを保証し、未知または悪意のある機能の実行を防ぎます。固定されたツールバージョンは、脆弱性を導入したり整合性を損なう可能性のあるツールのサイレントアップデートを防ぎ、安定性とセキュリティ保証を提供します。
Q5: LangfuseとOpenTelemetryは、AIエージェントシステムのセキュリティ体制をどのように強化しますか？
A5: Langfuseは、LLMの操作とエージェントの意思決定に関する深い可視性を提供し、疑わしい挙動やプロンプトインジェクションの試みを特定するために不可欠です。OpenTelemetryはシステム全体にわたるエンドツーエンドの分散トレースを提供し、セキュリティチームがエージェントのアクションをバックエンドシステムイベントと関連付け、異常検出とフォレンジック分析を支援します。
「AXプロジェクト実践ガイド」シリーズの次のパートである第4回では、AIエージェントに対する堅牢なガードレールを確立することに深く入り込み、倫理的考慮事項、コンテンツモデレーション、運用上の境界線をカバーして、責任ある管理されたAI展開を確実にします。
← 前の記事: AXプロジェクト実践ガイド 第2回 — 既存システム向けオープンソースAI統合パターン
次の記事: AXプロジェクト実践ガイド 第4回 — LLMガードレール：セキュアなAI導入のための必須設計とレッドチームテスト →
AXプロジェクトのご相談
既存システムにAIを加えるAXプロジェクトを、ユースケースの選定・要件定義から構築まで、SeekersLabがSI方式でご支援します。導入をご検討中の方はお気軽にお問い合わせください。
- メール: contact@seekerslab.com
- 電話: +82-2-2039-8160(平日 09:00〜18:00、韓国時間)