この記事で扱うこと
「AIエージェント」の導入が進むにつれ、多くの企業が「エージェントの乱立」という新たな課題に直面しています。この記事では、個別のユースケースに最適化されたエージェントアプリケーションと、それを支える共通基盤であるエージェントプラットフォームの違いを明確にします。
その上で、実際にシステム設計に落とし込むための3層リファレンスアーキテクチャ（Runtime / Context & Knowledge / Governance & Operations）を解説。特に、API連携、権限制御、監査、評価、ガードレールといった運用・ガバナンスの観点にフォーカスし、スケーラブルで安全なエージェント運用基盤の構築順序を提示します。
なぜ「エージェントアプリケーション」と「エージェントプラットフォーム」を区別すべきか
ある企業で、以下のような状況が起きていると想像してください。
- 経理チームが月次決算を40%短縮するエージェントを構築
- 購買部門がそれを見て、発注処理用のエージェントを別途開発
- カスタマーサービスが問い合わせ解決エージェントをプロトタイプ
- IT運用部門がインシデントトリアージ用のエージェントを設計
各チームは最善の意図で、それぞれ独自のスタックを選びました。経理はスプレッドシートでログ管理、購買は別のモデルゲートウェイ、カスタマーサービスはローカルファイルにコンテキスト保存、IT運用は独自の承認機構を実装。
個々の判断は合理的ですが、結果として「ツールを共有できない」「アクセス制御がバラバラ」「監査ログの形式が統一できない」「エージェント間の品質比較が不可能」という状態に陥ります。これはエージェントアプリケーションを量産した結果であり、エージェントプラットフォームの不在が原因です。
3層リファレンスアーキテクチャの全体像
以下の図は、エンタープライズエージェントプラットフォームの参照アーキテクチャです。3つの層が独立してスケールする設計になっています。
第1層：Runtime Layer（実行基盤）
この層は、エージェントが実際にタスクを実行するための基盤です。「モデルを呼び出して結果を返す」だけでは不十分で、エンタープライズで求められる5つのコンポーネントを理解する必要があります。
1. モデルゲートウェイ（Model Gateway）
最も過小評価されがちなコンポーネントです。単なるモデル接続のラッパーではなく、以下の責務を持ちます。
- タスクに応じたモデル選択: 単純な分類は軽量モデル、複雑な推論は高性能モデルを自動選択
- フォールバック処理: 特定モデルの障害時、自動的に代替モデルにルーティング
- コスト制御と可視化: 全モデル呼び出しのログ取得とコスト集計
# モデルゲートウェイのルーティング設定例（概念）
routing_rules:
- task_type: "classification"
priority: ["gpt-4o-mini", "claude-3-haiku"]
max_tokens: 500
- task_type: "complex_reasoning"
priority: ["gpt-4o", "claude-3-sonnet"]
max_tokens: 4000
fallback: "gpt-4o-mini"
2. ツールレジストリとツール実行（Tool Registry & Execution）
ツールレジストリはカタログです。各ツールのメタデータ（所有者、権限、リスクレベル）を管理します。ツール実行サービスは、実際の呼び出し前に以下のバリデーションを実施します。
- パラメータの型と範囲チェック
- 呼び出し元の権限確認
- ポリシー違反の有無
- 閾値を超える場合は承認フローへの誘導
# ツール実行前のポリシーチェック（疑似コード）
def execute_tool(tool_name: str, params: dict, user_context: dict):
tool = tool_registry.get(tool_name)
# 権限チェック
if not has_permission(user_context, tool.required_permission):
raise PermissionError("権限が不足しています")
# ポリシーチェック（例：承認閾値）
if tool.risk_tier == "high" and params["amount"] > 100000:
return ApprovalRequired("高額取引のため承認が必要です")
# 実行
return tool_executor.run(tool, params)
3. 状態管理とメモリ（State & Memory）
両者は混同されがちですが、明確に分離すべきです。
- State: ワークフローの進行状況（どのステップまで完了したか）。厳格なガバナンスと監査が必要。
- Memory: セッションを跨いだコンテキスト情報。柔軟性は高いが、権限と保持ポリシーに従う必要がある。
4. ポリシー適用（Policy Enforcement）
ポリシーはドキュメントやコードに散在させるのではなく、ツール呼び出し、データアクセス、アクション実行の直前に明示的なチェックポイントとして配置します。
第2層：Context & Knowledge Layer（コンテキストと知識基盤）
多くのエージェント障害の原因はモデルではなく、コンテキストの誤りです。情報が古い、不完全、または権限不足でアクセスできないケースが大半を占めます。
権限認識型検索（Permission-aware Retrieval）
最も重要な機能です。エージェントは「意味的に類似している」だけでドキュメントを取得してはいけません。以下の情報を考慮する必要があります。
- 誰が（ユーザーID）
- どのエージェントが（エージェントID）
- どのドメインの処理中か（ドメインコンテキスト）
- どのデータにアクセス権があるか（権限マトリクス）
-- 権限認識型検索の概念（疑似SQL）
SELECT content FROM documents
WHERE semantic_similarity(query, content) > 0.8
AND document_id IN (
SELECT document_id FROM document_permissions
WHERE user_id = :current_user
OR agent_id = :current_agent
)
AND sensitivity_level <= :user_clearance
3つのストレージタイプ
| ストレージ | 用途 | ユースケース例 |
|---|---|---|
| ベクターストア | 非構造化データのセマンティック検索 | 社内FAQ、ナレッジベース |
| メタデータカタログ | 構造化された属性検索 | ソース、所有者、有効期限、分類 |
| ナレッジグラフ | エンティティ間の関係性推論 | 取引先-契約、製品-顧客、インシデント-ポリシー |
すべてのケースでナレッジグラフが必要なわけではありません。シンプルなナレッジアシスタントならベクター＋メタデータで十分です。しかし、サプライチェーンの混乱分析や、複数エンティティに跨る経理例外処理では、グラフベースの推論が効果を発揮します。
第3層：Governance & Operations Layer（ガバナンスと運用基盤）
この層は「面倒だから後回し」にされがちですが、信頼できるエージェントと、デプロイできないエージェントの分かれ目です。
エージェントレジストリとポリシーレジストリ
エージェントレジストリは公式カタログです。以下の情報を一元管理します。
- エージェント名、目的
- ビジネスオーナー、テクニカルオーナー
- リスクレベル、使用ツール、データソース
- 自律性レベル（assist / semi-auto / auto）
- ライフサイクルステータス（開発/テスト/本番/廃止）
ポリシーレジストリは横断的なルールを管理します。
- 取引閾値（例：100万円以上の支払いは承認必須）
- ツール制限（例：外部API呼び出しは特定エージェントのみ許可）
- リスク分類基準
リスク階層化（Risk Tiering）
「すべてのエージェントに同じ制御」は非効率です。リスクレベルに応じて制御を変えます。
| リスクレベル | 例 | 必要な制御 |
|---|---|---|
| Low | 内部ナレッジ検索（assistモード） | 基本的なログ取得 |
| Medium | コメント作成、下書き生成 | 承認フロー、監査証跡 |
| High | ERP取引実行、払戻し処理 | 多段階承認、事前テスト必須、リアルタイム監視 |
評価ハーネス（Evaluation Harness）
エージェントの品質を担保するためのテスト環境です。以下の要素を含みます。
- ゴールデンデータセット: 正解が既知のテストケース
- シナリオテスト: 複数ステップのワークフローテスト
- ポリシーコンプライアンスチェック: ルール違反がないかの自動検証
- 回帰テスト: モデルやプロンプト変更時の品質低下検出
- 本番サンプリング: 実運用後の品質モニタリング
唯一機能する構築順序
プラットフォーム構築で最も多い失敗は「一度に全部作ろう」とすることです。結果として、時間がかかり、コストが膨らみ、ビジネスニーズと乖離します。
推奨する構築順序:
-
モデルゲートウェイ（最初）
- 全エージェントに標準的なモデルアクセス、ログ取得、フォールバック、コスト制御を提供
-
ツールレジストリと実行（エージェントが業務システムに触れるタイミング）
- 統合が野放図になり、監査不能になるのを防ぐ
-
ログ、トレース、可観測性（スケール前）
- エージェントの行動、コスト、応答時間を可視化
-
権限適用とポリシーチェック（機密データやアクション実行時）
- データ漏洩や不正操作を防止
-
評価ハーネス（モデル/プロンプト変更が頻繁になるタイミング）
- 品質劣化を早期発見
-
メモリサービスとエージェントレジストリ（必要に応じて）
- タスクベースのステートレスエージェントには当面不要
重要な原則: ケイパビリティは必ず実ユースケースから生まれさせること。ナレッジグラフを「いつか使うかも」で構築すると、誰も使わない高価な資産になります。まずはAP例外処理とITインシデントトリアージの2ユースケースから始めれば、モデルゲートウェイ、ツールレジストリ、可観測性、権限認識型検索、承認ワークフローが最優先で必要だと自然にわかります。
まとめ：良いアーキテクチャとは何か
良いリファレンスアーキテクチャとは、紙面上で最も完全なものではありません。以下の問いに自信を持って答えられるかどうかです。
「明日、経理、購買、カスタマーオペレーション、ITに10個の新エージェントを追加するとしたら、それらを安全に、スケーラブルに、エージェントスプロール（乱立）を起こさずに運用できる共有基盤はあるか？」
もし答えが「No」なら、次の優先順位はエージェントの量産ではなく、プラットフォームの強化です。
参考: Your Company Doesn’t Need More AI Agents. It Needs a Platform.