Microsoft Foundry / Azure OpenAI のエージェントに外部ツールや社内データを安全につなぎたいなら、2026年4月更新の要点は「MCP server endpoint を追加できる」だけではありません。実務上は、Foundry Toolboxes で複数ツールを MCP 互換エンドポイントとして束ね、Project connection、Microsoft Entra、OAuth、承認フロー、監査ログまで含めて運用設計することが重要です。Microsoft Learn の該当ページは 2026年4月23日に更新され、GitHub の差分でも MCP と Tool catalog / Toolbox に関する更新が確認できます。(Microsoft Learn)
この記事では、IT管理者、プロダクトオーナー、Microsoft エコシステムを使う開発チーム向けに、Microsoft Foundry / Azure OpenAI のエージェント運用で今回の更新をどう読むべきか、どの構成を選ぶべきか、導入時にどこで失敗しやすいかを実務目線で整理します。
Microsoft Foundry / Azure OpenAIでMCP接続が重要になる理由
MCP、つまり Model Context Protocol は、AIアプリケーションを外部システムに接続するためのオープンな標準です。公式説明では、AIアプリケーションがデータソース、ツール、ワークフローに接続できる仕組みとして位置付けられています。Microsoft Foundry のエージェントでは、この MCP server endpoint を mcp tool として追加することで、モデル単体では扱えない外部ツールやデータをエージェントから利用できるようになります。(Model Context Protocol)
Azure OpenAI をすでに使っているチームにとって、この更新の価値は「LLMに回答させる」から「LLMが必要なツールを選び、外部システムを参照・実行する」へ運用範囲を広げられる点にあります。たとえば、GitHub、Azure DevOps、社内API、検索基盤、ファイル検索、業務データベースなどを、エージェントが必要に応じて呼び出す構成を検討できます。
ただし、MCP接続は便利な反面、外部サービスにプロンプトや業務データが渡る可能性があります。Microsoft Learn でも、非Microsoftサービスを接続する場合はサービス提供者との契約条件、データの保持場所、共有されるデータ、発生する料金を確認する必要があると説明されています。(Microsoft Learn)
2026年4月23日の更新で押さえるべきポイント
今回の更新は、単なるコードサンプルの修正ではなく、エージェント運用の設計に関わる内容が多いです。GitHub の差分では、model-context-protocol.md の日付が 2026年4月23日に更新され、Foundry Toolboxes を MCP endpoint として使う説明、Toolbox の認証管理、バージョニング、Azure DevOps MCP Server まわりの補足が追加されています。(GitHub)
| 更新ポイント | 実務での意味 | まず確認すること |
|---|---|---|
| Foundry Toolboxes を MCP endpoint として利用 | 複数のツールを1つの MCP 互換エンドポイントに束ねられる | チームごとに重複しているツール設定や資格情報がないか |
| MCP接続の認証を Project connection で管理 | APIキーやBearerトークンをコードに直書きしない構成にできる | 誰が Project connection を作成・閲覧・更新できるか |
| Toolbox の認証集中管理 | Toolbox 側で資格情報注入、トークン更新、ポリシー適用を扱える | エージェントごとに個別の認証情報を渡していないか |
| Toolbox versioning | 本番エージェントに影響を与えず、新しいツール構成を検証しやすい | consumer endpoint と version-specific endpoint を使い分けているか |
| Azure DevOps MCP Server preview のカタログ導入 | コード変更なしで Azure DevOps 連携を始めやすい | 公開するAzure DevOpsツールを最小限に絞っているか |
| Public / Private MCP endpoint の整理 | 公開MCPと社内向けPrivate MCPを使い分けられる | Basic setupかStandard setupか、VNet要件があるか |
| SDK / REST API のサポート明示 | Python、C#、JavaScript、Java、REST APIで導入を検討しやすい | 自社の標準開発言語と運用体制に合うか |
特に重要なのは、Foundry Toolboxes です。Toolbox は Web Search、Code Interpreter、File Search、Azure AI Search、MCP servers、OpenAPI tools、Agent-to-Agent connections などをまとめ、単一の MCP 互換エンドポイントとして公開できるプレビュー機能です。エージェント側は個別ツールを毎回設定するのではなく、Toolbox endpoint を server_url として参照する形にできます。(Microsoft Learn)
MCP toolで設定する主要項目
Microsoft Foundry のエージェントに MCP server endpoint を接続する場合、設定の中心になるのは server_url、server_label、allowed_tools、require_approval、project_connection_id です。公式ドキュメントでは、同じエージェント内で server_label は一意にする必要があり、allowed_tools を省略した場合は MCP server が公開するすべてのツールが対象になると説明されています。require_approval の既定値は always です。(Microsoft Learn)
| 項目 | 役割 | 実務での判断基準 |
|---|---|---|
server_url | 接続先のリモートMCP server endpoint | 信頼できる提供元か、社内ネットワーク内か、利用規約を確認する |
server_label | エージェント内でMCP serverを識別する名前 | github、azure-devops、sales-data など用途が分かる名前にする |
allowed_tools | エージェントが使えるMCPツールを制限する | 最初は必ず最小権限で始める。全ツール許可は検証環境だけに限定する |
require_approval | ツール呼び出し前の承認要否 | 書き込み、削除、権限変更、外部送信は always を基本にする |
project_connection_id | 認証情報を保持するProject connection | APIキーやPATをコードやプロンプトに埋め込まない |
構成イメージは次のようになります。実際のツール名は、接続先MCP serverが公開している名前に置き換えてください。
{
"type": "mcp",
"server_label": "github",
"server_url": "https://api.githubcopilot.com/mcp",
"allowed_tools": ["get_repository", "list_pull_requests"],
"require_approval": "always",
"project_connection_id": "github-mcp-connection"
}allowed_tools を設計せずに接続すると、エージェントが想定外のツールを選ぶ余地が広がります。PoCでは動いても、本番では監査や権限管理の説明が難しくなるため、最初から「どのツールを、どの目的で、誰の権限で使うか」を表にしておくのが安全です。
直接MCP接続か、Foundry Toolboxかを選ぶ判断基準
MCP server endpoint をそのままエージェントに追加する方法と、Foundry Toolbox にまとめてから接続する方法は、用途が少し異なります。1つのエージェントが1つのMCP serverを使うだけなら直接接続で十分な場合があります。一方、複数チーム・複数エージェントで同じツール群を使い回すなら、Toolbox のほうが運用しやすくなります。
| 構成 | 向いているケース | 注意点 |
|---|---|---|
| 直接Public MCP接続 | 信頼できるSaaSや公開MCP serverを少数のエージェントで使う | 非Microsoftサービスに渡るデータ、利用規約、料金、ログを確認する |
| 直接Private MCP接続 | 社内API、社内DB、閉域ネットワーク上のツールを使う | Private MCP は Standard Agent Setup と専用MCPサブネットが必要 |
| Foundry Toolbox経由 | 複数ツールを束ね、複数エージェントから再利用したい | Toolbox自体のバージョン管理、認証、公開範囲を設計する |
| カタログ経由のAzure DevOps MCP Server | Azure DevOps連携を素早く検証したい | 公開するAzure DevOpsツールを必要最小限に選ぶ |
Public endpoint は Basic setup と Standard setup の両方で使えますが、Private endpoint は public internet に公開しないMCP server向けで、Standard Agent Setup with private networking と専用MCP subnet が必要です。Microsoft Learn では、Private MCP server の検証済み構成として、Azure Container Apps の internal-only ingress と Microsoft.App/environments に委任された専用MCP subnet が示されています。(Microsoft Learn)
Toolbox を使う場合は、production agent には consumer endpoint を使い、検証時は version-specific endpoint を使うのが基本です。consumer endpoint は promoted default version を返すため、新しいToolboxバージョンを先に検証してから本番に昇格できます。(Microsoft Learn)
IT管理者が最初に決めるべき認証方式
MCP server の多くは認証を必要とします。Microsoft Foundry Agent Service では、APIキーやBearerトークンなどをアプリに直書きせず、Project connection に保存する構成が推奨されています。対応する認証方式には、key-based authentication、Microsoft Entra authentication、OAuth identity passthrough、unauthenticated access があります。(Microsoft Learn)
| 認証方式 | 向いているケース | 管理上の注意点 |
|---|---|---|
| Key-based authentication | PATやAPIキーでMCP serverに接続する | 共有シークレットとして扱い、権限を絞り、定期的にローテーションする |
| Microsoft Entra authentication | Microsoft Entraに対応する社内・Microsoft系サービスに接続する | agent identity または project managed identity のロール割り当てを確認する |
| OAuth identity passthrough | ユーザーごとの権限や文脈を維持したい | ユーザーごとの同意フロー、Azure AI Userロール、同一テナント要件を確認する |
| Unauthenticated access | 認証不要の公開MCPや閉域内ツールを使う | 認証が不要でも利用規約、レート制限、データ共有範囲を確認する |
OAuth identity passthrough は、ユーザー本人の権限を保ったままMCP serverを使いたい場合に有効です。ただし、Microsoft Learn では、ユーザーが少なくとも Azure AI User ロールを持つこと、ユーザーの Microsoft Entra tenant と Foundry project の tenant が一致すること、cross-tenant token exchange はサポートされないことが説明されています。グローバル企業で複数テナントを使っている場合は、ここが導入時の制約になりやすいです。(Microsoft Learn)
また、Project connection に保存したAPIキーは、そのプロジェクトにアクセスできるユーザーの管理対象になります。ユーザー個別の権限を保つべき業務では、共有PATではなくOAuth identity passthroughやMicrosoft Entraベースの構成を優先して検討しましょう。(Microsoft Learn)
プロダクトオーナーが見極めたいユースケース
MCP接続は「できること」が多いため、最初から大きな業務自動化を狙うと失敗しやすくなります。最初のPoCでは、読み取り中心で、成功・失敗を判定しやすく、監査ログを確認しやすいユースケースを選ぶのが現実的です。
| ユースケース | 初期導入しやすい形 | 本番前に追加すべき管理 |
|---|---|---|
| GitHubやAzure DevOpsの情報整理 | Issue、PR、README、作業項目の要約 | 書き込み系ツールの承認、対象リポジトリの制限 |
| 社内ナレッジ検索 | File Search、Azure AI Search、MCP serverを組み合わせたFAQ | 検索対象データの分類、個人情報・機密情報の扱い |
| 運用支援 | 障害手順書、ログ検索、チケット起票支援 | 実行コマンドや変更操作の承認フロー |
| 営業・CS支援 | 顧客情報、契約情報、問い合わせ履歴の参照 | ユーザーごとの権限継承、データ保持ポリシー |
| 開発者支援 | API仕様、リポジトリ、設計書の横断参照 | 外部MCP serverに送るプロンプト内容の制御 |
避けたいのは、初期段階で「エージェントに全部やらせる」設計です。削除、更新、権限変更、外部送信、課金が発生する操作は、require_approval を有効にし、承認画面で tool name と arguments を確認できるようにします。公式ドキュメントでも、リスクの高い操作には承認を求め、ツール名と引数を確認し、承認とツール呼び出しをログに残すことが推奨されています。(Microsoft Learn)
導入手順の実務フロー
MCP接続の導入は、コードを書く前に設計を固めると失敗が減ります。次の順序で進めると、IT管理者、開発者、プロダクトオーナーの責任範囲を分けやすくなります。
| 手順 | 作業内容 | 完了の判断基準 |
|---|---|---|
| 1 | 利用するMCP serverを選定する | 提供元、利用規約、データ送信範囲、料金が確認済み |
| 2 | Public / Private / Toolbox を選ぶ | データ分類とネットワーク要件に合っている |
| 3 | 認証方式を決める | 共有資格情報か、ユーザー個別認証か、Entra認証かが明確 |
| 4 | Project connection を作成する | シークレットをコードやプロンプトに書かずに済む |
| 5 | allowed_tools と require_approval を設定する | 使えるツールと承認対象が文書化されている |
| 6 | Foundry chat testing experience やAPIで検証する | tool call、承認、エラー時の挙動が確認済み |
| 7 | ログ・監査・ローテーションを設定する | 承認履歴、tool call、認証情報更新の運用が決まっている |
| 8 | 本番向けにToolbox versioningを使う | 検証済みバージョンだけをdefaultに昇格できる |
REST APIで扱う場合は、Foundry project endpoint、model deployment name、bearer token、必要に応じて MCP project connection name を用意します。MCP tool の承認が必要な場合は、最初のレスポンスに含まれる mcp_approval_request のIDを取得し、previous_response_id と mcp_approval_response を使って後続リクエストを送ります。(Microsoft Learn)
Azure OpenAI のResponses APIに慣れている開発者は、エージェント参照と会話コンテキストを意識すると理解しやすいです。公式サンプルでは、Foundry project client から OpenAI client を取得し、conversationを作成して、agent reference付きで response を作成する流れが示されています。(Microsoft Learn)
失敗しやすいポイントと対処法
MCP接続は、設定値が1つ違うだけで「モデルがツールを呼ばない」「認証エラーになる」「承認後に処理が進まない」といった問題が起きます。Microsoft Learn でも、よくあるエラーとして schema、認証、tool call、approval response に関する問題が整理されています。(Microsoft Learn)
| 症状 | よくある原因 | 対処 |
|---|---|---|
Invalid tool schema が出る | MCP server definition に anyOf や allOf、複数型パラメータが含まれる | MCP server 側のschemaを単純化し、パラメータ型を明確にする |
Unauthorized / Forbidden が出る | Project connection の資格情報、ヘッダー名、Bearer形式が合っていない | Authorization、X-API-Key、Api-Key など接続先の仕様を確認する |
| モデルがMCP toolを呼ばない | instructionが曖昧、server_labelやallowed_toolsが不一致 | instructionにツール利用条件を明記し、公開ツール名を確認する |
| 承認後に処理が進まない | previous_response_id や approval_request_id が誤っている | 最初のresponse IDと承認リクエストIDを正しく引き継ぐ |
| Private MCPに到達できない | 専用MCP subnet、subnet delegation、private DNS が不足 | Standard Agent SetupとVNet設計を確認する |
| 長時間処理で失敗する | non-streaming MCP tool call のタイムアウト | 100秒以内に応答するよう処理を分割・最適化する |
| ローカルMCP serverを直接つなげない | Agent Service runtime は remote endpoint を前提にしている | Azure Container Apps や Azure Functions などでリモート化する |
特に見落としやすいのは、ローカルで動くMCP serverをそのまま本番エージェントにつなげられると考えてしまう点です。Microsoft Learn では、Agent Service runtime は remote MCP server endpoint のみを受け付けるため、ローカルMCP serverを使う場合はクラウド上にホストする必要があると説明されています。(Microsoft Learn)
セキュリティと監査で必ず見るべき項目
MCPはエージェントの能力を広げますが、同時に外部実行面を増やします。MCP server がAPI、データベース、ファイル、業務システムに接続している場合、エージェントの出力だけでなく、ツール呼び出しの入力、ツールから返る出力、認証情報、ユーザー同意、監査ログまで管理対象に含める必要があります。
Microsoft Foundry Agent Service の tool best practices では、ツール出力を信頼できない入力として扱うこと、必要最小限の情報だけを送ること、キーやトークンをプロンプトに含めないこと、ログにシークレットを残さないことが推奨されています。(Microsoft Learn)
MCP固有のリスクとしては、過剰権限、間接プロンプトインジェクション、Tool poisoning、認証ロジックの不備などが問題になります。Microsoft Security Community Blog でも、MCP server に必要以上の権限を与えるとデータ流出や意図しない変更につながる可能性があり、最小権限の徹底が重要だと説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
実務では、次のチェックリストを本番前レビューに入れてください。
| チェック項目 | 確認する内容 |
|---|---|
| MCP serverの提供元 | 公式提供元か、代理サーバーか、社内管理か |
| データ送信範囲 | prompt、ユーザー入力、検索結果、添付ファイル、個人情報が外部に出るか |
| 権限範囲 | 読み取りだけか、書き込み・削除・権限変更が可能か |
| 承認フロー | high-risk tool call で人間の承認が入るか |
| ログ | tool name、arguments、approver、結果、エラーを追跡できるか |
| シークレット管理 | Project connectionやEntraを使い、コード・プロンプト・ログに秘密情報を残していないか |
| バージョン管理 | ToolboxやMCP server更新時に本番影響を検証できるか |
| 地域・契約 | グローバル展開時にデータ所在地、保持、利用規約を確認しているか |
非MicrosoftのMCP serverを使う場合、Microsoftは第三者が作成したリモートMCP serverをテストまたは検証しないと明記しています。信頼できる提供元のMCP serverを使い、プロキシ経由の不明なサーバーは避けるべきです。(Microsoft Learn)
IT管理者・プロダクトオーナー・開発者の役割分担
MCP導入は、開発者だけに任せると権限や監査の設計が後回しになりがちです。最初から役割を分けると、PoCから本番移行までの判断が速くなります。
| 役割 | 主な責任 | 成果物 |
|---|---|---|
| IT管理者 | 認証、RBAC、VNet、Project connection、ログ、監査 | 接続ポリシー、認証方式、承認ルール、監査設計 |
| プロダクトオーナー | ユースケース、利用者、成功指標、業務影響 | MVPスコープ、禁止操作、承認が必要な業務 |
| 開発者 | MCP tool設定、SDK/REST実装、エラー処理、テスト | agent定義、tool設定、検証コード、運用手順 |
| セキュリティ担当 | データ分類、脅威分析、プロンプトインジェクション対策 | リスク評価、例外承認、ログレビュー基準 |
PoCの成功条件は「エージェントが答えを返した」では不十分です。少なくとも、意図したツールだけを呼ぶこと、承認が必要な操作で承認要求が出ること、失敗時に安全に止まること、監査ログで後から説明できることを確認してください。
まとめ：次に取るべき行動
Microsoft Foundry / Azure OpenAI のエージェントで MCP server endpoint を使う場合、2026年4月更新の中心は「外部ツール連携を、再利用可能で管理しやすい形にする」ことです。直接MCP接続だけでなく、Foundry Toolboxes、Project connection、Microsoft Entra、OAuth identity passthrough、allowed_tools、require_approval、Toolbox versioning を組み合わせて設計する必要があります。
最初にやるべきことは、候補となるMCP serverを一覧化し、データ分類、認証方式、Public / Private要件、承認が必要な操作を整理することです。そのうえで、読み取り中心の小さなPoCを作り、tool call、承認、エラー、ログを確認します。複数チームで同じツールを使う見込みがあるなら、早い段階で Foundry Toolbox を前提に設計すると、後から認証情報やツール設定を作り直す手戻りを減らせます。
コメント