Microsoft Foundryとモデルコンテキストプロトコル（MCP）の統合が、着実に実用フェーズへ進んでいる。Azure FunctionsでホストしたMCPサーバーをFoundryエージェントのカスタムツールとして接続する手順が、Azure SDK Blogで公開された。単なる実装メモにとどまらず、エンタープライズ規模での「AIエージェントへのツール提供」というアーキテクチャの方向性を示す内容だ。

MCPサーバーをFoundryエージェントに繋ぐ意義

MCPはVS CodeやCursorなどの開発ツールで既に広く使われているプロトコルだ。自社のデータベースクエリやAPI呼び出し、業務ロジックをMCPツールとして実装している組織は少なくない。

ここで注目すべきは「そのMCPサーバーをそのままFoundryエージェントに繋げる」という点だ。開発者向けのツールをエンタープライズ向けのAIエージェントにも提供できる。ツールの実装は1回で済み、消費するクライアント側を増やすだけでよい。

Azure Functionsをホスティング基盤に選ぶ理由も明確だ。サーバーレス課金、スケーラブルなインフラ、そして後述する認証機構の充実——この3点が揃っている。

接続の全体像

接続手順は大きく4ステップだ。

  • ビルトインMCP認証の有効化: Azure Functionsのデフォルト（キーベース認証）を無効化し、MCP専用の認証に切り替える。サンプルをそのまま使った場合は設定済み。
  • エンドポイントURLの確認: MCP拡張ベースのサーバーであれば https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp が対象。
  • 認証方式に応じた資格情報を取得: 後述の4方式から選択。
  • Foundryポータルでエージェントにツールを追加: エンドポイントと資格情報を入力するだけ。

認証方式の選び方

本稿の実務的な核心はここだ。4つの認証方式が提供されており、フェーズに応じて使い分けることができる。

キーベース認証（デフォルト） HTTPリクエストヘッダーに共有のfunctionアクセスキーを含める方式。開発・検証フェーズで手っ取り早く試したいときに向く。ただし本番環境での使用は避けるべきだ。

Microsoft Entra認証 エージェント自身のマネージドID（エージェントID）またはFoundryプロジェクト共有のマネージドIDを使う方式。本番環境ではエージェントIDを使い、プロジェクト共有IDは開発に留める。エンタープライズ環境での標準的な選択肢になる。

OAuthアイデンティティパススルー ユーザーがサインインして認可し、そのトークンをエージェントが使って認証する方式。ユーザーごとのコンテキストが必要な業務シナリオ——たとえばユーザー別のデータアクセス権を持つAPIを呼び出す場合——で必須になる。設定手順は増えるが、本番の多くのケースでこれが正解だ。

未認証アクセス パブリックな情報にのみアクセスするMCPサーバーや、開発環境での動作確認に限定して使う。

実務への影響

日本のエンタープライズ環境で考えると、この構成が刺さる場面はいくつかある。

既存のMCPツール資産の活用: 社内ポータルやERPへのAPIアクセスをMCPツールとして実装している組織は、そのままFoundryエージェントに接続できる。「AIチャットボットのためだけに別のAPI連携を作り直す」という二重投資を避けられる。

認証の段階的強化: 開発初期はキーベース→ステージングはマネージドID→本番はOAuthパススルー、というように段階的に強化できる設計は、実際の開発サイクルに合っている。

Microsoft Entra IDとの自然な統合: エージェントIDやマネージドIDをベースにした認証は、既存のEntra ID管理に乗っかれる。新たなID管理体制を構築する必要がなく、既存のロールベースアクセス制御（RBAC）設計を使い回せる。

Azure Functionsの従量課金モデルも重要だ。MCPサーバーの呼び出しは間欠的になることが多く、常時起動のコンテナより大幅にコストを下げられる可能性がある。

筆者の見解

MCPをAzure Functionsでホストし、Foundryエージェントに繋ぐ——この構成は「AIエージェントの実装において、ツール提供側と消費側を分離する」という設計思想を体現している。

VS CodeやCursorで使っているMCPサーバーを、そのままエンタープライズ向けのFoundryエージェントにも流用できるのは、開発者にとって本質的な効率化だ。「AIの機能を足す」のではなく「既存の業務ロジックをAIが使えるようにする」という発想の転換でもある。

プラットフォームとしてのAzureとFoundryの組み合わせは、こういったエンタープライズ統合において強みを発揮する。特に認証周りをMicrosoft Entra IDに統一できる点は、ゼロトラストアーキテクチャを推進する組織にとって見逃せない。AIエージェントもID管理の対象として既存の統制フレームワークに組み込める。

MCPというプロトコル自体はオープンな仕様だ。Foundryに乗ることで、このエコシステムに広く投資できる。特定のクライアント環境に縛られずにツールを使い回せる設計は、中長期的なメンテナンスコストを下げる。

エンタープライズAIエージェントの実装を検討しているチームには、まずAzure Functionsでシンプルなカスタムツールを1つ作り、Foundryエージェントに繋いで動かしてみることを勧めたい。認証はキーベースから始めて、本番要件に合わせてEntra IDに移行すればいい。ゴールから逆算するより、動く状態を素早く作って反復するほうが、エージェント実装の感触をつかむには早い。

出典: この記事は Give your Foundry Agent Custom Tools with MCP Servers on Azure Functions の内容をもとに、筆者の見解を加えて独自に執筆したものです。