Azure AI Foundry Agent（westus）でMCP（Model Context Protocol）ツールを追加しようとして「The tool ‘mcp’ is not supported」と表示される場合、原因はリージョンではなく“そのワークスペースにMCPが有効化されていない”ことがほとんどです。本記事では、エラーの読み解き方から有効化の依頼手順、承認待ちの間にできる代替構成まで、実務目線で整理します。
結論：westus対応でもMCPは自動で使えるとは限らない
結論から言うと、Azure AI Foundry AgentでのMCPサポートは「パブリック プレビュー」でもゲート付き（事前承認・段階的ロールアウト）として提供されることがあり、対応リージョン（例：westus）にリソースを作っただけでは有効化されないケースがあります。したがって、同じwestusでもMCPが使えるワークスペース／使えないワークスペースが混在します。
あなたの環境でmcpがツール一覧に出てこない、あるいは追加時にエラーになるのは、現時点でそのワークスペースにMCPが付与されていない（またはプレビュー機能がロールアウトされていない）可能性が高い、というのが第一の結論です。
発生しているエラーの意味を正しく読む
代表的なエラーメッセージは次の形式です。
The tool 'mcp' is not supported. It must be one of the following:
code_interpreter, file_search, function, bing_grounding, azure_ai_search, openapi, connected_agent, azure_functionこのメッセージが示しているのは「MCPの書き方が間違っている」ではなく、もっと根本的に現在のワークスペース（または利用しているAPI/SDK）では、ツール種別としてmcpが認識されていないという事実です。逆に言えば、MCPが有効な環境では、同じ操作をしてもmcpがサポートツールとして表示・選択でき、上記のような“候補一覧に含まれない”エラーにはなりません。
なぜ「westusでプレビュー」と書かれていても使えないのか
公式のブログやドキュメントに「westusでプレビュー提供」と書かれていると、westus＝全員が即日利用可能と受け取りがちです。しかし、Azureのプレビュー機能には次のような提供形態があり、ここを取り違えると混乱が起きます。
| 提供形態 | ユーザー側の体感 | 典型的な対応 |
|---|---|---|
| オープンなパブリック プレビュー | 対応リージョンなら作成直後から使えることが多い | UIやAPIで機能が選べる／設定すれば動く |
| ゲート付き（事前承認）プレビュー | 対応リージョンでも使えない環境が存在する | サポートや担当経由で有効化依頼が必要 |
| 段階的ロールアウト | 同条件でも利用可否がワークスペース単位でバラつく | 待つ／有効化依頼／別ワークスペースで試す |
今回のケースは、まさにこのゲート付きプレビュー＋段階的ロールアウトの典型です。つまり「westusに作れば自動でMCPがONになる」というより、「westusは“ロールアウト対象になり得るリージョン”であり、個別ワークスペースに機能フラグ（権限）が付くと利用できる」という理解が実態に近いです。
MCP（Model Context Protocol）とは何か：Foundry Agentで何が嬉しいのか
MCP（Model Context Protocol）は、エージェントが外部のツールやサービスに接続して“できること”を増やすための仕組みを、一定のルールで標準化しようとする考え方です。Foundry Agentの文脈では、MCPサーバーを通じて、社内システムや各種SaaS、独自のツール群と連携し、回答の根拠を増やしたり、アクション実行を自動化したりする用途で期待されます。
- ツール連携を標準化：個別実装を増やし過ぎずに、外部機能を追加しやすい
- エージェントの拡張性：RAGだけでなく「調査→実行→検証」まで一連の流れを作りやすい
- 運用の見通し：ツールの追加・差し替え・権限管理を整理しやすい
一方でプレビュー期間中は、機能の提供条件（リージョン、サブスクリプション、ワークスペース、APIバージョン、ロールアウト状況など）が揺れやすく、“使える前提で設計を固めてしまう”のは危険です。まずは利用可否を早期に確認し、使えない場合の代替案も並行して設計するのが安全です。
まずやるべき現状確認：本当に「未有効化」なのかを切り分ける
“MCPが使えない”と言っても、原因が1つとは限りません。とはいえ多くの場合、切り分けは次のチェックでほぼ決着します。
| チェック項目 | 確認する場所 | 未有効化のサイン | 補足 |
|---|---|---|---|
| ツール追加画面にmcpが出るか | FoundryのAgent作成UI / ツール選択 | mcpが選択肢に存在しない | 最短の判定材料。出なければまず未対応 |
| APIでmcpを指定できるか | Agent作成/更新のAPI呼び出し | The tool ‘mcp’ is not supported が返る | UIが追従していない場合もあるので両方見る |
| ワークスペース/リージョン | Azureポータルのリソース情報 | westusでも発生する | リージョンは“必要条件”であって十分条件ではない |
| 利用しているSDK/APIバージョン | コードやCLIの設定 | 古いSDK/安定版APIでプレビュー機能が見えない | 有効化後も症状が残る場合に疑う |
あなたの質問にあるように、ツール候補として列挙される中にmcpが含まれていない場合、まずは「そのワークスペースでMCPが有効化されていない」可能性を最優先で疑うのがセオリーです。
ツール定義のチェック（最小例）
Agentのツール定義に、次のようにtype: mcpを指定してもエラーになる場合は、現状その環境では未対応と判断できます。
{
"tools": [
{
"type": "mcp"
}
]
}ここで重要なのは、“JSONは正しいのに拒否される”＝環境側のサポートがまだという見方です。入力の誤りを疑って延々と試行錯誤するより、提供条件（ゲートやロールアウト）を疑って次のアクションへ進む方が早く解決します。
MCPを使えるようにする方法：Azureサポートに有効化を依頼する
MCPがゲート付きプレビューとして運用されている場合、やることはシンプルです。Azureサポートに「Azure AI Foundry AgentでMCPを使いたい」旨を伝え、対象ワークスペースへの有効化を依頼します。技術的な回避策で強引に突破する類の問題ではなく、権限・機能フラグの付与が必要になるためです。
サポート依頼前に用意しておく情報
やり取りを短縮するため、最初のチケットに必要情報をまとめて入れるのがコツです。次の表をチェックリストとして使ってください。
| 項目 | 例 | なぜ必要か |
|---|---|---|
| サブスクリプションID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | サポート側で対象環境を特定するため |
| リソースグループ名 | rg-foundry-prod | 同サブスク内に複数ワークスペースがある場合の識別 |
| Azure AI Foundryのワークスペース/プロジェクト名 | foundry-ws-westus | 有効化対象をピンポイントに指定するため |
| リージョン | westus | プレビュー提供範囲の確認とロールアウト判断のため |
| 発生しているエラー全文 | The tool ‘mcp’ is not supported … | 再現性確認と一次切り分けのため |
| 利用目的（ユースケース） | RAG、外部API連携、社内システム操作など | ゲート付きプレビューの承認判断に影響することがある |
サポート依頼の書き方（そのまま使えるテンプレ）
以下は、サポートへの依頼文の一例です。環境名などを自分の情報に置き換えて貼り付けてください。
件名：Azure AI Foundry AgentでMCP（Model Context Protocol）を有効化したい（westus）
本文：
Azure AI Foundry AgentでMCPツール（type: mcp）を利用したいのですが、Agent作成時に
"The tool 'mcp' is not supported. It must be one of the following: ..."
というエラーが発生し、mcpがツール種別として認識されません。
対象環境：
* Subscription ID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
* Resource Group：rg-xxxx
* Azure AI Foundry Workspace/Project：xxxx
* Region：westus
要望：
当該ワークスペースでMCP（Model Context Protocol）プレビュー機能の有効化（ゲート開放）をご支援ください。
ユースケース：
（例）社内ナレッジ＋外部システム連携を行うRAG/エージェントを構築したい。MCP経由で複数ツールを統合したい。ポイントは、「MCPを使いたい」だけでなく「どのワークスペースに、どのエラーが出ているか」まで一度に提示することです。サポートが追加質問を投げる回数が減り、結果として有効化までのリードタイムが短くなります。
有効化後の確認方法：UIと最小テストで“使える状態”を固める
サポート側で有効化が完了したら、次の順で確認します。
- FoundryのAgent作成UIでツールの選択肢に
mcpが現れるか確認する - API/SDKで
type: mcpを含むAgent作成が成功するか確認する - 最小構成（ダミーのMCPサーバー、または検証用の接続先）で呼び出しが成立するか確認する
“UIに出たからOK”で終わらせず、実際にAgentがツールとして認識し、実行フェーズまで到達するかを必ず確認してください。プレビュー機能は、表面上の選択肢が増えても、背後の許可・ネットワーク・認証の条件でつまずくことがあります。
MCPが使えない間の代替策：目的別に「近い構成」を組む
承認待ち・ロールアウト待ちの期間は、プロジェクトが止まりがちです。そこで、目的を分解して「MCPでやりたいこと」を既存ツールで仮実装し、後から差し替えられる設計にしておくと現実的です。
| 目的 | 推奨ツール | 向いている理由 | 注意点 |
|---|---|---|---|
| 社内文書検索を含むRAG | azure_ai_search | 検索拡張生成の王道。権限設計・運用が比較的整理しやすい | 索引設計が要。更新頻度が高い場合はパイプラインも検討 |
| 外部API（SaaS/社内API）を呼びたい | openapi | OpenAPI仕様でツール化でき、呼び出しの契約（I/F）が明確 | 認証方式やレート制限、エラーハンドリング設計が重要 |
| 独自ロジックをツールとして実装したい | function / azure_function | 軽量に実装でき、既存コード資産を取り込みやすい | 引数スキーマ・例外設計を丁寧にしないと運用が崩れる |
| 複数エージェントを連携させたい | connected_agent | 役割分担（調査役/実行役など）で品質と保守性を上げやすい | 責務境界とプロンプト設計が重要。無秩序に増やすと破綻 |
代替策の設計ポイントは、「ツール呼び出しのインターフェースを固定する」ことです。例えば、いまはopenapiで外部APIを叩いていても、後でMCPが有効化されたら“同じ入力→同じ出力”を保つ形で接続方式だけ差し替えられるようにしておくと、移行が最小限で済みます。
トラブルシューティング：有効化以外で詰まりやすいポイント
未有効化が最頻出とはいえ、実務では別の要因が重なることもあります。よくある詰まりどころを、症状→原因→対処の形で整理します。
| 症状 | 考えられる原因 | 対処 |
|---|---|---|
| サポートで有効化されたはずなのに、まだmcpが出ない | UIキャッシュ/反映遅延、別ワークスペースを見ている、API/SDKが古い | 対象リソースを再確認し、SDK更新やプレビューAPIの利用有無を確認する |
| UIにはmcpが出るが、実行時に接続で失敗する | ネットワーク制限、認証情報不足、接続先MCPサーバーの稼働/証明書 | 疎通確認、認証方式の整理、許可IP/Private Linkなどの構成を点検する |
| 一部ユーザーだけ使えない | RBACやプロジェクト権限の差、Key Vault等へのアクセス差 | 最小権限の見直しと、必要ロールの付与・監査ログ確認 |
| ツール実行が不安定（タイムアウト/失敗率が高い） | 接続先のスループット不足、レート制限、エラー再試行設計の欠如 | バックオフ再試行、タイムアウト設計、キューイング、監視メトリクス導入 |
特に「有効化後もまだ同じエラーが出る」場合は、未有効化ではなく“呼び出し経路が古い”可能性が上がります。Foundry周辺はプレビューの更新が早いため、SDKやAPIバージョンが古いと、サーバー側が有効でもクライアントが対応しておらず、結果としてmcpを未知のツールとして弾くことがあります。まずは、利用中のライブラリやAPI指定がプレビュー機能に追従しているかを確認してください。
設計のコツ：MCP前提で破綻しないエージェント構成にする
MCPの導入は、単にツールが増えるだけではありません。外部連携が増えるほど、セキュリティ・運用・監査・障害対応が難しくなります。プレビュー段階から堅牢にするために、次の観点を最初から入れておくと後悔しにくいです。
- ツール権限を分離：読み取り系（検索）と書き込み系（更新/実行）を分け、最小権限で運用する
- 失敗時のフォールバック：外部ツールが落ちても、最低限の回答は返せる設計にする
- 監査ログとトレーシング：いつ、誰が、どのツールに、どんな入力を投げたか追えるようにする
- スキーマを固定：ツールI/F（入力・出力）を早めに固め、接続方式の差し替えを容易にする
- 段階導入：最初は1ツール＋1ユースケースで成功パターンを作り、順に広げる
とくに社内システム連携では「便利だから全部つなぐ」が事故の元です。MCPが有効化されるまでの間に、代替ツールで同じ設計思想を先に固めておくと、MCP解禁後の拡張もスムーズになります。
まとめ：westusでも“使えない”のは珍しくない。まずは有効化ルートに乗せよう
Azure AI Foundry Agentでmcpが使えず、ツール一覧にも出てこない場合、原因の大半はゲート付きパブリック プレビューによる未有効化です。westusは対応リージョンであっても、ワークスペース単位でロールアウト状況が異なり、全員が自動で使えるわけではありません。
最短の解決策は、Azureサポートに「対象ワークスペースでMCPを有効化したい」と依頼し、必要情報（サブスクID、RG、ワークスペース、エラー全文、ユースケース）を最初から揃えて提示することです。承認待ちの間は、azure_ai_searchやopenapiなどの既存ツールを組み合わせて目的を前倒しで満たし、後から接続方式を差し替えられる設計で進めるのが現実的です。
コメント