KPMGが本番運用する50以上のAIエージェント — Foundryアーキテクチャ徹底解剖

はじめに

こんにちは！最近Microsoft Foundryのマルチエージェントアーキテクチャにどっぷりハマっている横浜情報機器株式会社のロホマン シャヒンです。

MicrosoftのAzure & AI MVP である Dave R 氏が書いた「KPMGの本番AIエージェント」を扱った記事（Medium/CodeXで136いいね以上）が気になって、公式ドキュメントを深掘りしてみました。

「デモは作れる、でも本番は別の話」——これを正面から解決するアーキテクチャがFoundryに揃っています。

1. なぜ今「本番運用AIエージェント」が話題なのか

AIエージェントはもうPoCの段階を超えています。Microsoftは今後2年以内におよそ13億のエージェントが本番環境に移行すると予測しており、すでに本番稼働している企業の数字がそれを裏付けています。

ただし、デモエージェントと本番エージェントはまったくの別物です。本番で動かすには、適切なモデルへのアクセス・エンタープライズデータへのグラウンディング・業務システムとの統合・マルチエージェントのオーケストレーション・ガバナンスが全部必要で、どれか一つ欠けても破綻します。KPMGはこの「本番のハードル」を全部超えて、50以上のエージェントを実際に動かしています。

2. KPMGの本番運用事例：50以上のエージェントが動いている現実

KPMGが選んだのがMicrosoft Foundryです。監査・コンサル・税務という厳格なコンプライアンス要件を持つ業界で、50を超えるエージェントが本番稼働しています。

KPMGが取り組んだ用途の例：

• 監査レポート自動化：複数の財務データソースを横断して要約・比較するエージェント
• 税務コンプライアンスチェック：規制ドキュメントを参照しながら申告内容を検証するエージェント
• カスタマーサービス（返品処理）：後述するマルチエージェントアーキテクチャの典型例

規模が大きくなるにつれて3つの壁にぶつかった——これはKPMGに限った話じゃないと思います。

3. 3つの壁：スピード・コンテキスト・ガバナンス

壁 1：スピード（応答速度）

大量のドキュメントをエージェントが毎回読み込むと、レスポンスが遅くなります。ユーザー体験としては致命的です。

解決策： Foundry Agent Serviceのベクトルストア + File Search ツールを使い、必要な情報だけをコンテキストに差し込む。毎回全文を読ませるのではなく、関連チャンクだけをリアルタイム検索して渡す構造にします。

壁 2：コンテキスト（業務知識の組み込み）

「汎用モデルに社内固有のルールを覚えさせる」のは思ったより難しいです。ファインチューニングは時間とコストがかかり、プロンプトに全部書くのはコンテキスト上限に引っかかります。

解決策： MCP（Model Context Protocol） + Foundry Toolboxesの組み合わせ。社内システム・ドキュメント・APIへのアクセスをMCPサーバーとして外に出し、エージェントが必要なときだけ呼び出す構造にします。コードを触らずにツールを入れ替えられるのが地味に便利です。

壁 3：ガバナンス（50以上のエージェントを安全に管理する）

エージェントが増えると「誰がどのエージェントをいつ使っているか」「コストはどこに出ているか」「ポリシー違反はないか」が追えなくなります。

解決策： Foundry Control Plane + AI Gateway。これが今回の記事の核心です。後ほど詳しく解説します。

4. カスタマー返品処理マルチエージェントのアーキテクチャ解剖

KPMGが実際に本番で動かしているマルチエージェントの典型が「カスタマー返品処理」ワークフローです。シングルエージェントでは難しい複雑な判断を、役割分担したエージェントチームで処理しています。

エージェントの構成：

[ユーザーリクエスト]
        ↓
 ① オーケストレーターエージェント
   ・入力を解析し、適切なサブエージェントに割り振る
   ・全体フローの状態管理
        ↓
 ② 分類エージェント
   ・返品タイプを分類（不良品 / サイズ違い / 単純返品 など）
        ↓
 ③ データ取得エージェント          ④ ポリシー参照エージェント
   ・注文履歴・顧客情報を取得          ・返品ポリシーをMCPで参照
   （SAP / CRM 連携）               （社内ドキュメントストア）
        ↓                                ↓
 ⑤ 判定エージェント
   ・取得データ + ポリシーを照合して解決策を決定
        ↓
 ⑥ 通知エージェント
   ・顧客・担当者に結果を通知（Teams / メール）

それぞれのエージェントがFoundry Toolboxesを通じてツールにアクセスしています。オーケストレーターは agent_ids でサブエージェントを参照するだけ——実装はシンプルです。

実際のオーケストレーターエージェントの設定画面（return-orchestrator-demo）：

A2A（Agent2Agent）ツールの追加手順：

Python SDKでも同じ操作ができます。ポータルから接続設定を作った後、A2APreviewToolでエージェントに追加するだけです。

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition, A2APreviewTool
from azure.identity import DefaultAzureCredential

project = AIProjectClient(
    endpoint="https://{account}.services.ai.azure.com/api/projects/{project}",
    credential=DefaultAzureCredential(),
)

# ポータルで作成した A2A 接続を取得してツール化
classifier_conn = project.connections.get("a2a-classifier")
fetcher_conn    = project.connections.get("a2a-fetcher")

# オーケストレーターエージェントに A2A ツールを追加
agent = project.agents.create_version(
    agent_name="return-orchestrator-demo",
    definition=PromptAgentDefinition(
        model="gpt-4o",
        instructions="返品リクエストを分類・判定してください。",
        tools=[
            A2APreviewTool(project_connection_id=classifier_conn.id),
            A2APreviewTool(project_connection_id=fetcher_conn.id),
        ],
    ),
)

ポータルで作った接続名（a2a-classifierなど）をSDK内でそのまま参照できるのが地味に便利です。このA2A機能は2026年8月時点でpreviewなので、本番犰境での利用は公式ドキュメントの最新情報を確認することをおすすめします。

Foundryには1,500以上のMCPコネクターが用意されています（2026年8月時点）。これをToolboxesという概念でバンドルして使えます。

Foundry Toolboxesとは

複数のツール（Web Search、Code Interpreter、File Search、Azure AI Search、MCP サーバー、OpenAPI ツール、エージェント間連携）を単一のMCP互換エンドポイントにまとめる仕組みです。

# toolbox.yaml のイメージ
name: customer-support-toolbox
tools:
  - id: order-history-mcp
    type: mcp
    server_url: https://internal-api.contoso.com/mcp/orders
    auth_type: managed-identity
  - id: return-policy-search
    type: azure-ai-search
    index: return-policies
  - id: crm-connector
    type: mcp
    server_url: https://crm.contoso.com/mcp
    auth_type: oauth2

エージェントコードはToolboxのエンドポイントを指すだけ。ツールを追加・削除してもエージェントコードは変わりません。

# エージェントからToolboxを使う（Python SDK）
agent = project_client.agents.create_agent(
    model="gpt-4o",
    name="return-processor",
    instructions="顧客の返品リクエストを処理してください。",
    tools=[{"type": "mcp", "server_url": toolbox_endpoint}]
)

対応するランタイム

Toolboxesは以下すべてから利用できます：

• Foundry Agent Service
• Microsoft Agent Framework
• LangGraph
• GitHub Copilot SDK
• その他MCP対応クライアント

6. AI Gateway Control Plane による一元管理

50以上のエージェントになると「個別管理」は限界です。FoundryのControl PlaneとAI Gatewayがここを解決します。

Foundry Control Planeでできること

AI Gateway がMCPツールに何をするか

AI Gatewayが間に入ることで、MCPツールへのアクセスに以下のポリシーを適用できます：

<!-- レート制限ポリシー例 -->
<inbound>
  <base />
  <rate-limit-by-key calls="60" renewal-period="60"
    counter-key="@(context.Request.Headers.GetValueOrDefault('X-Agent-Id','default'))" />
</inbound>

• レート制限：エージェントIDごとに1分60リクエスト上限など
• 認証強制：Managed Identity / OAuth2 / APIキーの統一
• IP制限：特定エージェントからのみアクセス許可
• 監査ログ：すべての呼び出しを記録
• 地域ルーティング：ヘッダーを見てEUバックエンド / USバックエンドに振り分け

特に X-Correlation-Id を付与することで、マルチエージェントのリクエストチェーンを追跡できるようになります。これはKPMGのような監査が厳しい環境では必須です。

実際のポリシー設定画面（Azure Portal）：

7. 実際に試して気づいたアーキテクチャ判断ポイント

ドキュメントを読んだだけじゃわからなくて、実際に動かしてみて「ここは設計段階で決めないと後で詰まる」と感じた箇所をメモしておきます。

エージェントタイプの選択

KPMGのような本番ケースでは、オーケストレーター = Hosted Agent + サブエージェント = Prompt/Connected Agent の組み合わせが多いみたいです。最初Prompt Agentだけで済ませようとしたんですが、ロジックが複雑になってきたタイミングでHosted Agentに切り替えるほうがすっきりしました。

AI Gatewayの設定タイミング

AI GatewayはFoundryリソースレベルで有効化します。1つのリソース配下の全プロジェクトが同一ゲートウェイを共有する構造です。プロジェクトごとにトークン上限は独立して設定できます。

厳格な分離が必要な場合（規制業種・部門ごとのコスト分離など）は、Foundryリソース自体を分けるのが正解です。

8. まとめ

KPMGが50以上のエージェントを本番で動かせている理由は、技術の強さだけじゃなくてガバナンスの仕組みが揃っているからだと整理できました。

• デモと本番の差を埋めるのは「3つの壁」への対処：スピード（ベクトル検索）、コンテキスト（MCP Toolboxes）、ガバナンス（AI Gateway）
• マルチエージェントは役割分担が鍵：オーケストレーター + 専門サブエージェントの構成で複雑な判断を分散処理
• Foundry Toolboxesでコードを変えずにツールを差し替えられるのが地味に大きい
• AI Gateway Control Planeがないと50エージェントは管理できない：トークン管理・監査・ガードレールの一元化が必須
• 他クラウドやオンプレのエージェントもControl Planeに登録できる：既存資産との共存が現実的

正直、「AIエージェントを本番で動かすのはまだ早い」と思っていた時期もありましたが、KPMGの事例を見てその考えは変わりました。ツールは揃っています。あとは設計と判断です。

この記事が少しでも参考になったら、ぜひシェアしていただけると嫌しいです！

出典

• Building Production AI Agents with Microsoft Foundry — Dave R, Microsoft Azure & AI MVP (Medium/CodeX)
• What is Microsoft Foundry Control Plane? — Microsoft Learn
• AI gateway in Azure API Management — Microsoft Learn
• Govern MCP tools by using an AI gateway — Microsoft Learn
• Use Foundry Toolboxes as MCP endpoints — Microsoft Learn
• Configure AI Gateway in Foundry resources — Microsoft Learn