Microsoft ecosystemでAIエージェント活用を進めるなら、2026年4月24日に更新された「MCP and Foundry Agents」は早めに確認すべきです。今回の要点は、Foundry AgentsからリモートMCPサーバーのツールを呼び出し、外部データ・外部サービス連携を承認、認証、ツール制限つきで運用しやすくなっていることです。Microsoft Learnの公式ページでは、Foundry AgentsにMCPツールを接続する方法、承認フロー、複数ツール構成、Toolboxesとの関係が具体例つきで整理されています。(Microsoft Learn)
IT管理者にとっては「AIエージェントに何を実行させるか」を統制する話であり、プロダクトオーナーにとっては「社内外のツールを使えるAI機能を、どこまで安全に業務へ組み込めるか」を判断する材料になります。単なるチャットボット強化ではなく、Microsoft ecosystem上でエージェントを業務アプリケーション化するための設計ポイントとして読むべき更新です。
Microsoft ecosystemの最新動向: MCP and Foundry Agentsで何が変わったか
2026年4月更新の「MCP and Foundry Agents」で重要なのは、Foundry AgentsがMCPを通じて外部ツールや外部データソースに接続する流れが、より実装ベースで説明されている点です。MCPは、アプリケーションがLLMにツールやコンテキストデータを提供するためのオープン標準として説明されており、Foundry Agent ServiceではリモートMCPサーバーをツールとして接続できます。(Microsoft Learn)
| 更新ポイント | 実務上の意味 | 最初に確認すべきこと |
|---|---|---|
| リモートMCPサーバーをFoundry Agentsのツールとして接続 | エージェントがMicrosoft Learn、GitHub、Azure DevOps、社内APIなどの外部機能を使える | 接続先MCPサーバーが信頼できるか |
server_labelとserver_urlでMCPツールを定義 | どのMCPサーバーを、どの名前でエージェントに渡すかを明確化できる | ラベルの命名規則と管理台帳 |
allowed_toolsで利用ツールを制限 | MCPサーバー全体ではなく、必要なツールだけを公開できる | 読み取り専用・更新系ツールの分類 |
| 承認フローを設定可能 | 高リスク操作を人間の確認後に実行できる | neverとalwaysの使い分け |
| Foundry Toolboxesとの連携 | 複数ツールをまとめて、再利用可能なMCP互換エンドポイントとして扱える | 部門共通のツールセット化 |
この更新は、開発者だけでなくIT admins、security owners、product ownersが一緒に読むべき内容です。AIエージェントが外部サービスへアクセスする場合、便利さより先に「どのデータが外に出るか」「誰の権限で実行されるか」「実行前に承認が必要か」を決める必要があります。
MCP and Foundry Agentsをひと言で理解する
MCP and Foundry Agentsは、Foundry Agentsに外部ツールを安全に持たせるための仕組みです。
従来の生成AIは、入力されたテキストに対して回答を返す使い方が中心でした。一方、MCPを使うFoundry Agentsでは、エージェントが必要に応じて外部ツールを呼び出せます。たとえば、Microsoft Learnを検索して最新ドキュメントを要約する、GitHubリポジトリを確認する、Azure DevOps上の情報を参照する、といった処理をエージェントのワークフローに組み込めます。Microsoft Learnのサンプルでも、Microsoft Learn MCPやGitHub MCPをツールとして接続する例が示されています。(Microsoft Learn)
ここで大切なのは、エージェントに「何でもできる権限」を与えるのではなく、必要なツールだけを明示し、承認ルールと認証方法を設計することです。MCPは便利な接続方式ですが、接続先が増えるほどデータ流出、過剰権限、誤操作のリスクも増えます。
今回の更新で押さえるべき「Using MCP with Foundry Agents」
Microsoft Learnの「Using MCP tools with Foundry Agents」は、Foundry-backedなエージェントにMCPサーバー連携を追加する流れを説明しています。サンプルでは、環境変数でFoundryプロジェクトのエンドポイントやモデルデプロイ名を設定し、エージェント定義にMCPツールを追加し、実行時に承認設定を渡す構成が示されています。(Microsoft Learn)
実装上の主要な構成要素は次のとおりです。
| 構成要素 | 役割 | 実務での注意点 |
|---|---|---|
| Foundry project endpoint | Foundryプロジェクトを識別する接続先 | 環境ごとにdev、staging、prodを分ける |
| model deployment name | エージェントが使うモデルのデプロイ名 | モデル名をコードに固定せず環境変数化する |
| agent instructions | エージェントの役割や制約 | 「Microsoft Learnのみ検索」など範囲を明記する |
server_label | MCPサーバーの識別名 | 同一エージェント内で一意にする |
server_url | MCPサーバーのURL | 信頼済みの公式エンドポイントを優先する |
allowed_tools | 利用可能ツールの制限 | MCPサーバー全体を渡さず、必要最小限にする |
| approval setting | ツール実行前の承認要否 | 書き込み・変更系は原則承認ありで始める |
| project connection | APIキーやBearerトークンなどの認証情報管理 | アプリコードに秘密情報を書かない |
特に重要なのは、MCPサーバーのURLを指定するだけで終わらせないことです。公式ドキュメントでも、複数のリモートMCPサーバーを追加する場合は各ツールに一意のserver_labelとserver_urlを設定し、どのMCPサーバーを追加するか慎重に確認する必要があると説明されています。(Microsoft Learn)
エージェントの価値は「回答」より「安全に実行できること」に移る
Foundry AgentsでMCPを使う価値は、AIが自然な文章で答えることだけではありません。より重要なのは、外部ツールを呼び出す業務操作を、ルールに沿って実行できることです。
たとえば、社内のMicrosoft ecosystemで次のような使い方が考えられます。
- Microsoft Learnを検索し、AzureやMicrosoft 365の設定手順を要約する
- GitHub上のリポジトリやREADMEを確認し、変更内容を説明する
- Azure DevOpsの作業項目を参照し、リリース前の確認事項を整理する
- 社内APIをMCPサーバー化し、問い合わせ対応エージェントから参照させる
- Foundry Toolboxesに承認済みツールをまとめ、複数のエージェントで再利用する
プロダクトオーナーは「AIに何を答えさせるか」だけでなく、「AIにどの操作まで任せるか」を要件として定義する必要があります。たとえば、ドキュメント検索は自動実行でよくても、Issue作成、チケット更新、ファイル変更、顧客データ参照は承認を必須にする、といった線引きが必要です。
承認フローはneverとalwaysを使い分ける
MCP and Foundry Agentsの運用で最も失敗しやすいのが、承認フローの設計です。公式ドキュメントでは、MCPツール呼び出しに対して承認を不要にする設定、常に承認を求める設定、カスタム承認ルールを構成できることが説明されています。(Microsoft Learn)
| ツールの種類 | 例 | 推奨する承認方針 |
|---|---|---|
| 公開ドキュメント検索 | Microsoft Learn検索 | 検証環境では自動承認、本番ではログ監査を前提に判断 |
| 読み取り専用の社内検索 | 社内FAQ、ナレッジベース | データ分類に応じて自動承認または初回のみ承認 |
| 個人情報・機密情報を含む参照 | 顧客情報、契約情報、セキュリティログ | 原則承認あり、アクセス権と監査ログを必須化 |
| 書き込み操作 | Issue作成、チケット更新、設定変更 | 常に承認ありから開始 |
| 外部サービスへの投稿・変更 | GitHub操作、外部SaaS更新 | 常に承認あり、操作内容を画面で確認 |
| 高額課金やリソース作成 | クラウドリソース作成、ジョブ実行 | 承認に加えてロール制御と上限管理 |
初期導入では、読み取り専用のツールでもalways相当の承認から始めると安全です。どのツールが、どの引数で、どのタイミングで呼ばれるかを確認したうえで、自動承認に切り替える範囲を決めるほうが事故を減らせます。
認証情報はコードに書かず、Project Connectionで管理する
MCPサーバーの多くは認証を必要とします。Foundry Agent Serviceでは、APIキーやBearerトークンなどの認証情報をアプリコードに直接書くのではなく、project connectionに保存して使う方法が説明されています。(Microsoft Learn)
これはIT管理者にとって重要です。コードにトークンを書いてしまうと、Gitリポジトリへの誤コミット、ログへの出力、退職者アカウントの残存など、運用上のリスクが増えます。Project Connectionを使えば、認証情報をFoundryプロジェクト側で管理し、アプリケーション側には接続IDを渡す設計にできます。
また、開発時によく使われるDefaultAzureCredentialについても注意が必要です。公式ドキュメントでは、開発には便利だが、本番では意図しない資格情報の探索やレイテンシ、フォールバックによるセキュリティリスクを考慮し、ManagedIdentityCredentialなど特定の資格情報を使う選択肢が示されています。(Microsoft Learn)
権限設計で確認すべき項目
| 確認項目 | 判断基準 |
|---|---|
| 誰の権限でMCPツールを実行するか | ユーザー代理か、アプリケーション権限かを明確にする |
| トークンのスコープ | 読み取りだけで足りる場合、書き込み権限を付けない |
| 接続先MCPサーバー | 公式提供元や信頼済み事業者のエンドポイントを優先する |
| 認証情報の保管場所 | コード、.env、ログに秘密情報を残さない |
| 監査ログ | 誰が、どのツールを、どの引数で呼んだかを追跡できるようにする |
Public、Private、Local MCPサーバーの違いを理解する
Foundry Agent Serviceは、公開エンドポイントとプライベートエンドポイントのMCPサーバー接続をサポートしています。公開エンドポイントはインターネットから到達できるMCPサーバーに接続する構成で、プライベートエンドポイントは外部公開しないMCPサーバーをVNet内で使う構成です。プライベートMCPではStandard Agent Setupと専用MCPサブネットが必要と説明されています。(Microsoft Learn)
| 構成 | 向いている用途 | 注意点 |
|---|---|---|
| Public MCP endpoint | Microsoft Learn、GitHubなど外部公式サービス連携 | データが外部サービスへ渡る可能性を確認する |
| Private MCP endpoint | 社内API、社内データベース、機密性の高い業務ツール | ネットワーク、VNet、サブネット設計が必要 |
| Local MCP server | 開発者PC上での検証 | Foundry Agent Serviceから直接利用するにはリモート化が必要 |
| Azure Container Appsでホスト | コンテナ化したMCPサーバーを運用したい場合 | 内部専用Ingressや専用サブネットを検討する |
| Azure Functionsでホスト | 軽量なHTTPベースのMCPサーバー | 対応言語や認証方式の制約を確認する |
ローカルMCPサーバーをそのままFoundry Agent Serviceに接続できると考えるのは、よくある誤解です。公式ドキュメントでは、Agent ServiceランタイムはリモートMCPサーバーエンドポイントを受け付けるため、ローカルMCPサーバーのツールを追加したい場合はAzure Container AppsやAzure Functionsなどでホストしてリモートエンドポイント化する必要があると説明されています。(Microsoft Learn)
Foundry Toolboxesは「承認済みツール群」を作るための考え方
今回の更新で見逃せないのが、Foundry Toolboxesとの関係です。Foundry Toolboxesはプレビューとして説明されており、Web Search、Code Interpreter、File Search、Azure AI Search、MCP servers、OpenAPI tools、Agent-to-Agent connectionsなど複数のツールを、単一のMCP互換エンドポイントとして束ねられます。(Microsoft Learn)
Toolboxesの価値は、エージェントごとにツール設定を繰り返さず、組織として承認済みのツール構成を再利用できる点にあります。たとえば、サポート部門向けには「Microsoft Learn検索、社内FAQ検索、チケット参照」をまとめたToolboxを作り、開発部門向けには「GitHub参照、Azure DevOps参照、API仕様検索」をまとめる、といった使い分けができます。
さらに、ToolboxはMCP互換エンドポイントとして扱えるため、Foundry Agent Serviceだけでなく、Microsoft Agent FrameworkやLangGraphなどMCP対応クライアントから利用できると説明されています。ツールを追加、削除、再構成しても、エージェントコードを変更せずに運用できる点は、複数チームでAIエージェントを展開する組織にとって大きなメリットです。(Microsoft Learn)
ただし、Toolboxesを使えば自動的に安全になるわけではありません。公式ドキュメントでも、Toolboxesは組織がFoundryプロジェクト内で作成・管理するリソースだが、ツール選定、データ処理、コンプライアンスについては利用者側の責任が残ると説明されています。(Microsoft Learn)
IT管理者が最初に作るべき運用ルール
MCP and Foundry Agentsを本番導入する前に、IT管理者は次のルールを文書化しておくべきです。
MCPサーバー登録ルール
信頼できるMCPサーバーだけを登録対象にします。特に非Microsoftサービスや第三者が提供するMCPサーバーを使う場合、プロンプト内容などのデータが外部サービスへ渡る可能性があります。公式ドキュメントでも、非Microsoftサービス利用時のデータ、料金、利用条件、保持場所について利用者側の責任があると説明されています。(Microsoft Learn)
登録時には、少なくとも次の情報を管理台帳に残します。
- MCPサーバー名
- 提供元
server_url- 利用目的
- 利用可能ツール
- 承認方針
- 認証方式
- データ分類
- 利用部門
- 管理者
ツール公開ルール
MCPサーバーに含まれるすべてのツールをエージェントへ渡すのは避けるべきです。公式のベストプラクティスでも、allowed_toolsによる許可リスト、リスクの高い操作への承認要求、ツール名と引数の確認、承認とツール呼び出しのログ取得が推奨されています。(Microsoft Learn)
実務では、次のように分類すると判断しやすくなります。
| 分類 | 例 | 公開方針 |
|---|---|---|
| Safe read | 公開ドキュメント検索 | 小さく始めてログ確認後に自動化 |
| Sensitive read | 顧客情報、社内レポート参照 | 権限確認と監査ログを必須化 |
| Low-risk write | 社内メモ作成、下書き生成 | 承認ありで開始 |
| High-risk write | 設定変更、外部投稿、削除 | 原則として人間の明示承認が必要 |
| Cost-generating | クラウドリソース作成、長時間ジョブ | 承認、上限、通知を組み合わせる |
ログと監査ルール
AIエージェントのログは、単なる会話履歴では不十分です。どのMCPサーバーに、どのツール名で、どの引数を渡し、承認者が誰で、結果がどうだったかを追跡できる必要があります。
特にグローバル組織では、国や地域によってデータ保護、監査、外部サービス利用のルールが異なります。Microsoft ecosystem全体で共通ルールを作る場合も、部門や地域ごとの例外を吸収できる設計にしておくと運用しやすくなります。
プロダクトオーナーが見るべき導入判断
プロダクトオーナーは、MCP and Foundry Agentsを「新しい技術」としてではなく、「業務プロセスをどこまでAIに任せられるか」という観点で評価する必要があります。
| 判断項目 | 導入に向いている状態 | まだ早い状態 |
|---|---|---|
| 業務プロセス | 参照、要約、分類、下書きなど反復業務が多い | 手順が人によって大きく異なる |
| データ管理 | 参照可能なデータ範囲が明確 | 機密情報の分類ができていない |
| 権限管理 | ユーザー権限、アプリ権限、監査が整理済み | 誰の権限で実行するか決まっていない |
| ツール選定 | 読み取り専用ツールから始められる | 最初から更新・削除系を自動化したい |
| 成果指標 | 回答時間、一次解決率、確認工数などを測れる | 効果測定の指標がない |
最初のユースケースは、書き込み操作よりも読み取り・検索・要約に寄せるのが現実的です。たとえば「Microsoft Learnを検索し、管理者向け手順を要約する」「GitHubのREADMEやIssueを確認し、リリース影響を整理する」といった用途なら、MCPの価値を確認しやすく、リスクも比較的管理しやすくなります。
実装を始めるときの最短ステップ
MCP and Foundry Agentsを試すなら、最初から大規模な業務システムに接続しないことが大切です。次の順序で進めると、技術検証とガバナンス設計を両立できます。
小さく始める手順
| ステップ | 作業内容 | 成功条件 |
|---|---|---|
| 1 | 読み取り専用のユースケースを選ぶ | 外部検索やドキュメント要約で検証できる |
| 2 | Foundryプロジェクトと権限を確認する | ContributorまたはOwnerなど必要なRBACを満たす |
| 3 | MCPサーバーを1つだけ接続する | server_labelとserver_urlを明確に管理する |
| 4 | allowed_toolsで利用ツールを絞る | 不要なツールをエージェントに渡さない |
| 5 | 承認フローを有効にして実行する | 呼び出されるツール名と引数を確認できる |
| 6 | ログを確認する | 予期しないツール呼び出しがない |
| 7 | 自動承認できる範囲を決める | 読み取り専用など低リスク操作に限定する |
| 8 | 複数エージェント化する場合はToolboxを検討する | 部門共通のツール構成として再利用できる |
公式ドキュメントでは、Python、C#、TypeScript、Java、REST APIでMCPツールを使う例が示されています。SDKやREST APIの選択は、既存システムの言語、運用チームのスキル、監査要件に合わせて決めるのがよいでしょう。(Microsoft Learn)
設定イメージ
実装の考え方は、次のように整理できます。
Foundry Agent
└─ MCP tool
├─ server_label: microsoft_learn
├─ server_url: Microsoft Learn MCP endpoint
├─ allowed_tools: microsoft_docs_search
└─ approval: read-onlyなら低リスク、更新系は承認必須このように、MCPサーバーを「エージェントに渡す外部能力」として扱い、能力ごとに名前、接続先、許可ツール、承認条件を定義します。曖昧な「AIに調べさせる」ではなく、「このエージェントは、このMCPサーバーの、このツールだけを、この条件で使える」と設計することが重要です。
失敗しやすいポイントと回避策
MCPサーバーを信頼性で選ばない
便利そうなMCPサーバーを見つけても、提供元が不明なプロキシや個人運営の中継サービスを本番環境で使うのは危険です。公式ドキュメントでも、信頼できるサービス提供者自身がホストするサーバーを使い、追加するMCPサーバーを慎重に確認・追跡することが推奨されています。(Microsoft Learn)
allowed_toolsを設定しない
MCPサーバーに複数のツールが含まれる場合、必要なツールだけを許可しないと、エージェントが想定外のツールを呼び出す可能性があります。まずは1つのツールだけで検証し、必要に応じて段階的に増やすのが安全です。
書き込み操作を自動承認にする
Issue作成、チケット更新、ファイル変更、外部投稿などは、誤実行時の影響が大きくなります。最初から自動承認にせず、ツール名、引数、対象リソースを人間が確認できる画面や運用フローを用意しましょう。
ローカルMCPサーバーをそのまま使えると思い込む
開発環境で動いたローカルMCPサーバーを、そのままFoundry Agent Serviceから使えるとは限りません。Agent ServiceではリモートMCPサーバーエンドポイントが必要になるため、Azure Container AppsやAzure Functionsなどでホストする構成を検討します。(Microsoft Learn)
PoCの認証方式を本番に流用する
開発時はAzure CLIやDefaultAzureCredentialで動作確認しやすい一方、本番運用ではマネージドID、明示的な資格情報、最小権限、監査ログを組み合わせる必要があります。PoCで動いたことと、本番で安全に運用できることは別物です。
2026年4月時点での導入優先度
2026年4月時点で、MCP and Foundry AgentsはMicrosoft ecosystemにおけるエージェント活用の重要テーマです。特に、Microsoft 365、Azure、GitHub、Azure DevOps、社内APIを横断してAIエージェントを設計したい組織では、早めに検証する価値があります。
ただし、最初から全社展開を狙うよりも、次のような順序が現実的です。
- 読み取り専用のMCP連携で技術検証する
allowed_toolsと承認フローを設計する- 認証情報をProject Connectionで管理する
- ログと監査の粒度を確認する
- 部門共通ツールはFoundry Toolboxesで再利用を検討する
- 機密データ連携はPrivate MCP endpointやネットワーク分離を検討する
MCP and Foundry Agentsの本質は、AIエージェントに外部ツールを接続することではなく、接続したツールを組織のルールに沿って安全に使わせることです。まずは1つの読み取り専用ユースケースを選び、接続先、権限、承認、ログを確認してください。その検証結果をもとに、書き込み操作、社内API連携、Toolboxesによる再利用へ段階的に広げるのが、Microsoft ecosystemで失敗しにくい進め方です。
コメント