Azure AI Foundryを複数チームで使っているなら、Microsoft Foundry Control Planeは「AIエージェント、モデル、ツールをプロジェクト単位ではなく、組織・サブスクリプション単位で見えるようにする管理画面」と考えると分かりやすいです。
結論として、今回確認すべきポイントは AI Gateway、Application Insights、RBAC、ガードレールポリシー、既存プロジェクトの有効化状況 の5つです。特に、既存プロジェクトはAI Gatewayが自動的に有効にならない場合があるため、管理者は「作成済みのFoundryプロジェクトがControl Planeの管理対象になっているか」を早めに確認する必要があります。
Microsoft Learnでは、2026年5月12日に更新された「What’s new in Microsoft Foundry?」の新規記事として「What is Microsoft Foundry Control Plane?」が掲載されています。なお、該当記事自体のページ下部では最終更新日が2026年5月11日と表示されています。公式情報の扱いでは、更新一覧と個別ページの表示日が異なる場合があるため、社内資料では「2026年5月中旬に公開・更新された公式情報」と表現すると安全です。(Microsoft Learn)
Microsoft Foundry Control Planeとは
Microsoft Foundry Control Planeは、Foundry環境全体にあるAIエージェント、モデル、ツールを横断的に管理するための統合管理インターフェースです。公式ドキュメントでは、可視性、ガバナンス、制御を提供し、AIエージェントの構築から本番運用までを一元管理するものと説明されています。(Microsoft Learn)
従来のように「プロジェクトごとの画面」「個別のAzureポータル画面」「個別の監視リソース」を見に行く運用では、AIエージェントが増えたときに全体像を把握しにくくなります。Foundry Control Planeは、この課題に対して、複数プロジェクトに分散したエージェントやモデルを1つの運用ビューに集約します。
ポイントは、単なるダッシュボードではないことです。エージェントの一覧表示だけでなく、監視、評価、コスト、トークン使用量、コンプライアンス、セキュリティシグナル、ガードレールポリシーまで扱います。Microsoft Defender、Microsoft Purview、Microsoft EntraなどのMicrosoft系ガバナンス基盤との連携も前提にした設計です。(Microsoft Learn)
何が変わるのか
Microsoft Foundry Control Planeの重要な変化は、Azure AI Foundryの運用単位が「個別プロジェクト」から「AIフリート全体」へ広がる点です。AIフリートとは、組織内で稼働する複数のAIエージェント、モデル、ツール、関連リソースの集合と考えるとよいでしょう。
| 観点 | これまで起きやすかった運用 | Foundry Control Planeでの考え方 | 実務上の影響 |
|---|---|---|---|
| 資産管理 | プロジェクトごとにエージェントやモデルを確認 | Assetsペインでサブスクリプション内のAI資産を横断表示 | 放置されたエージェント、古いバージョン、未管理リソースを見つけやすくなる |
| 監視 | Application Insightsや個別画面を別々に確認 | OverviewやAssetsから実行状況、エラー率、トークン使用量、コストを確認 | 障害調査やコスト異常の初動が早くなる |
| ガバナンス | チームごとにルールがばらつく | Complianceペインでガードレールポリシーを定義・適用 | 本番展開前の安全基準を統一しやすくなる |
| セキュリティ | DefenderやPurviewのアラートを別画面で確認 | Control Plane上でセキュリティ・コンプライアンスのシグナルを確認 | セキュリティ担当と開発担当の連携がしやすくなる |
| コスト・クォータ | モデルデプロイ単位で確認 | Quotaペインやトークン使用量で利用状況を把握 | 特定プロジェクトの使い過ぎやリージョンごとの容量不足を早期に確認できる |
公式ドキュメントでは、Foundry Control Planeを使う場面として、複数プロジェクトや複数チームにまたがるAIエージェント管理、集中管理されたコンプライアンス可視化、Microsoft DefenderやMicrosoft Purviewとの統合、コスト・トークン使用量・リソース消費の追跡などが挙げられています。(Microsoft Learn)
対象者は管理者だけではない
Foundry Control Planeは「管理者向けの画面」と見られがちですが、実際には管理者、AI開発者、セキュリティ担当、コスト管理担当の全員に関係します。
| 対象者 | 主な確認ポイント | 具体的に見る場所 |
|---|---|---|
| Azure管理者・Foundry管理者 | RBAC、AI Gateway、プロジェクト、接続済みリソース、クォータ | Operate > Admin、Quota |
| AI開発者 | エージェントの状態、バージョン、トレース、エラー率、評価結果 | Operate > Assets、Monitoring、Evaluation |
| セキュリティ担当 | 禁止動作、Defenderアラート、Purview連携、ガードレール | Overview、Compliance |
| コンプライアンス担当 | ポリシーの適用範囲、例外、監査性、非準拠リソース | Compliance |
| コスト管理担当 | トークン使用量、推定コスト、コストスパイク、クォータ | Overview、Assets、Quota |
特に開発者にとって重要なのは、Control Planeが「作ったエージェントを運用側が勝手に見る仕組み」ではなく、開発時点から監視・評価・ガードレールを組み込む前提の仕組みであることです。Application InsightsやOpenTelemetryの設定を後回しにすると、実行履歴やエラー分析、トークン使用量の確認が不十分になります。
利用前に確認すべき前提条件
Foundry Control Planeを利用するには、Azureサブスクリプション、Foundryプロジェクト、AI Gateway、適切なAzure RBAC権限が必要です。高度なガバナンス機能ではAI Gatewayの構成が前提になります。(Microsoft Learn)
実務では、次の順番で確認すると抜け漏れを防げます。
| 確認項目 | 確認する理由 | 見落とすと起きる問題 |
|---|---|---|
| Foundryの新しいポータルを使っているか | Control Plane関連機能はFoundryポータル側で提供される | 旧画面やクラシック環境で目的の項目が見つからない |
| RBAC権限が足りているか | 表示されるエージェントや操作可能範囲は権限に依存する | 管理対象の一部しか見えず、棚卸しが不完全になる |
| AI Gatewayが構成されているか | トークン制限、クォータ、ガバナンス、カスタムエージェント登録に関係する | ポリシー適用や制御が期待どおり動かない |
| Application Insightsが接続されているか | エラー率、実行履歴、トレース、コスト関連の可視化に関係する | ダッシュボードにメトリックが出ない |
| Cost Management Readerなどの権限があるか | コスト情報の確認に必要 | トークンや実行情報は見えてもコストが見えない |
監視機能については、Foundry Control PlaneがApplication Insightsのログやメトリックを集約して表示します。Application Insightsがないリソースでは、ヘルスメトリック、コスト追跡、ドリルダウントレースが利用できない点に注意が必要です。(Microsoft Learn)
AI Gatewayで確認すべき設定
AI Gatewayは、Foundry Control Planeを実務で使ううえで最も重要な構成要素の一つです。公式ドキュメントでは、AI GatewayはAzure API Managementを背後で利用し、モデルデプロイに対するトークン制限、クォータ、ガバナンスを提供すると説明されています。(Microsoft Learn)
管理者が最初に確認すべきなのは、AI Gatewayが「リソースに存在するか」だけではありません。対象プロジェクトに対して有効化されているかまで確認する必要があります。AI Gateway作成後に新規作成されるプロジェクトではデフォルトで有効になりますが、既存プロジェクトは手動で追加する必要があります。(Microsoft Learn)
既存のAPI Managementを使う場合の注意点
既存のAzure API ManagementをAI Gatewayとして使う場合、公式ドキュメントでは、同じMicrosoft Entraテナント、同じサブスクリプション、アクセス可能なサブスクリプション、v2 tier、他のAI Gatewayに関連付けられていないことなどが条件として示されています。(Microsoft Learn)
本番環境では、単に「既存APIMを流用できるか」ではなく、次の観点で判断してください。
| 判断基準 | 確認ポイント |
|---|---|
| ネットワーク | Foundryリソースのパブリックアクセスを無効にしている場合、APIM側もプライベート接続できる構成か |
| 性能 | 開発・検証用途か、本番の高スループット用途か |
| 管理境界 | 複数チームで共用するAPIMにAI Gatewayを載せてよいか |
| 可用性 | リージョン障害時の経路や冗長化をどう設計するか |
| 権限 | APIMに対してAPI Management Service ContributorまたはOwner相当の権限があるか |
失敗しやすいのは、AI Gateway自体は作成したものの、既存プロジェクトを追加していないケースです。この状態では、プロジェクトの通信が期待どおりゲートウェイを通らず、トークン制限やガバナンス制御が適用されない可能性があります。
Operate画面の各ペインで見るべきこと
Foundry Control Planeの主要機能は、Foundryワークスペース右上のOperateから利用します。公式ドキュメントでは、Operateからサブスクリプション内のエージェント、モデル、デプロイを監視、統制、最適化できると説明されています。(Microsoft Learn)
Overviewでは全体の異常を早く見つける
Overviewペインでは、アクティブなエージェント、コスト傾向、実行完了率、阻止された動作、ヘルススコア、アラート概要などを確認できます。最初に見るべき場所はここです。
たとえば、前日まで安定していたエージェントのエラー率が急に上がった場合、Overviewで傾向を確認し、Assetsから該当エージェントにドリルダウンします。さらにトレースやログを見れば、ツール呼び出しの失敗、プロンプト変更、モデルバージョン変更、外部API障害などの切り分けに進めます。
AssetsではAI資産の棚卸しを行う
Assetsペインでは、サブスクリプション内のプロジェクトを横断して、エージェント、モデル、ツールを検索・並べ替えできます。バージョン、タグ、ヘルススコア、コスト、アラート、トークン使用量などの属性で絞り込めるため、月次の棚卸しにも向いています。(Microsoft Learn)
特に確認すべき項目は次の通りです。
| 項目 | 見るべき理由 |
|---|---|
| エージェント名・ソース | どの基盤やプロジェクト由来のエージェントかを把握する |
| ステータス | Running、Stopped、Blocked、Unknownなどの状態を確認する |
| バージョン | 本番利用中のバージョンと開発中の最新版を区別する |
| エラー率 | 障害や品質低下の兆候を見つける |
| 推定コスト・トークン使用量 | 予算超過や異常利用を早期に検知する |
| Entra ID | エージェントIDとアクセス管理を確認する |
Foundry Control Planeでは、Foundryエージェント、Azure SRE Agent、Azure Logic Appsのagent loop、手動登録したカスタムエージェントを対象として扱えます。一方で、Foundry classic agentsとAzure OpenAI assistantsはサポート対象外と記載されています。(Microsoft Learn)
Complianceではガードレールを統一する
Complianceペインでは、モデルデプロイに対するガードレールポリシーを作成・適用できます。公式クイックスタートでは、コンテンツ安全性、プロンプトインジェクション、保護されたマテリアルなどのガードレールコントロールを選択し、サブスクリプションまたはリソースグループ単位でポリシーを適用する流れが示されています。(Microsoft Learn)
ここで重要なのは、例外設定の扱いです。ポリシーを厳しくしすぎると検証環境の作業が止まり、例外を広げすぎると本番環境の統制が形だけになります。
おすすめは、次のように段階を分ける方法です。
| 環境 | ポリシー運用の考え方 |
|---|---|
| 開発環境 | 警告や可視化を中心にし、例外を明示する |
| 検証環境 | 本番に近いガードレールを適用し、非準拠を洗い出す |
| 本番環境 | 原則として必須ガードレールを適用し、例外は期限付きで管理する |
ポリシー作成後、Azure Policyのコンプライアンススキャンには時間がかかる場合があり、初期結果がすぐに表示されないことがあります。公開直前の確認ではなく、展開計画の前半で設定しておくべきです。(Microsoft Learn)
Quotaでは展開前に容量を確認する
Quotaペインでは、モデルデプロイが消費しているクォータや利用状況を確認できます。デフォルトではアクティブなデプロイがあるモデルのみ表示されますが、Show allを有効にすると、未デプロイのモデルやリージョンも含めて確認できます。(Microsoft Learn)
本番展開前には、次の確認を行うと安全です。
| 確認内容 | 目的 |
|---|---|
| 利用予定モデルの対象リージョン | そのリージョンで必要な容量があるか確認する |
| 既存デプロイの消費量 | 他プロジェクトの利用と競合しないか確認する |
| トークン制限 | 1プロジェクトが容量を使い切らないようにする |
| 増枠申請の要否 | リリース直前に容量不足になるのを避ける |
開発者が確認すべき実装上の注意点
開発者が最も注意すべきなのは、Control Planeで見える情報の多くが、事前の計測設定に依存することです。エージェントを作るだけでは、運用に必要な情報が自動的に十分そろうとは限りません。
Application Insightsを早めに接続する
Foundry Control Planeは、Application Insightsを使ってエージェントの実行、エラー率、トークン使用量、コスト、トレースを扱います。メトリックやトレースが表示されない場合は、Application Insightsの接続、権限、設定後に実行されたデータかどうかを確認する必要があります。公式ドキュメントでは、設定前の過去実行はさかのぼって取得されず、初回実行後にデータ反映まで時間がかかる場合があると説明されています。(Microsoft Learn)
つまり、リリース後に「障害が起きたから今から監視を入れる」では遅いということです。PoC段階では簡易設定でも構いませんが、検証環境に上げる前にはApplication Insightsを接続し、最低限のトレースが見える状態にしておくべきです。
カスタムエージェントは登録後のURL変更に注意する
カスタムエージェントをFoundry Control Planeに登録すると、FoundryはAzure API Managementをプロキシとして利用し、アクセス制御やアクティビティ監視を行います。登録対象のエージェントは到達可能な専用エンドポイントを持ち、HTTPまたはA2Aプロトコルに対応し、必要に応じてOpenTelemetryの生成AI向けセマンティック規約でデータを出力する必要があります。(Microsoft Learn)
重要なのは、登録後にFoundry Control Planeが新しいURLを生成し、クライアントやユーザーはそのURLを使ってエージェントと通信する必要がある点です。既存のアプリケーションが元のエージェントURLを直接呼び続けると、Control Plane側の制御や監視を通らない運用になりかねません。(Microsoft Learn)
移行時は、次の順番で進めると安全です。
| 手順 | 作業内容 |
|---|---|
| 事前確認 | エージェントのエンドポイント、認証、ネットワーク到達性を確認する |
| 計測設定 | Application InsightsとOpenTelemetryの出力を確認する |
| Control Plane登録 | Operateからカスタムエージェントを登録する |
| URL切り替え | クライアント側の呼び出し先をFoundry側の新URLへ変更する |
| 動作確認 | 実行、トレース、エラー率、ブロック制御を確認する |
| 旧経路整理 | 直接呼び出し経路を残す必要があるか判断する |
ライフサイクル操作はエージェント種別で異なる
Foundry Control Planeでは、エージェントの開始、停止、ブロックなどの操作ができます。ただし、すべてのエージェントで同じ操作ができるわけではありません。
| 種別 | 主な操作 | 注意点 |
|---|---|---|
| 未公開のFoundry prompt agent / workflow | なし | 専用デプロイがないため、停止するには削除が必要 |
| Hosted agent | Start / Stop | 停止すると関連するデプロイやコンピュートが停止・割り当て解除される |
| 公開済みFoundry agent | Start / Stop | 本番利用中の場合、停止前に利用者影響を確認する |
| Azure SRE Agent | Start / Stop | 監視や運用支援への影響を確認する |
| Azure Logic Apps agent loop | Start / Stop | Logic Appsリソース停止により関連ワークフロー全体へ影響する |
| Custom agent | Block / Unblock | 基盤自体は停止できず、Control Plane経由の受信リクエストをブロックする |
カスタムエージェントの場合、Foundryはエージェントが動作している基盤インフラへ直接アクセスできないため、Start/StopではなくBlock/Unblockで制御します。Block状態のエージェントは基盤上では動き続けますが、Foundryはそのエージェントへの通信をブロックします。(Microsoft Learn)
移行・展開時に失敗しやすいポイント
Foundry Control Planeは便利ですが、導入時に誤解しやすい点があります。特に、既存のAzure AI Foundry環境を運用している組織では、次の点を確認してください。
旧環境のすべてが対象になるわけではない
Foundry classic agentsとAzure OpenAI assistantsは、Foundry Control Planeのサポート対象外と記載されています。クラシック環境や旧APIを前提にした運用が残っている場合、Control Planeだけで一元管理できると考えるのは危険です。(Microsoft Learn)
移行計画では、まず既存資産を次の3つに分けて整理します。
| 分類 | 対応方針 |
|---|---|
| Control Planeで自動検出される資産 | Assetsで確認し、監視・ポリシー対象にする |
| カスタム登録できる資産 | AI Gateway、到達可能エンドポイント、OpenTelemetry設定を確認して登録する |
| 対象外の資産 | 別途移行、廃止、または従来運用の継続を判断する |
監視データは後から完全には補えない
Application Insightsを後から接続しても、設定前の実行データが自動的に復元されるわけではありません。障害分析やコスト分析に必要なデータを残すには、検証段階から監視設定を入れておく必要があります。(Microsoft Learn)
ポリシー適用は本番直前に行わない
ガードレールポリシーを本番直前に適用すると、想定外の非準拠が見つかり、リリース判断が難しくなることがあります。特に、プロンプトインジェクション対策やコンテンツ安全性の設定は、アプリケーションの挙動に影響する可能性があります。
おすすめは、開発環境では可視化、検証環境では本番相当、本番環境では強制という段階的な適用です。例外を設定する場合も、対象、理由、期限、承認者を残しておくと監査対応がしやすくなります。
Preview機能を本番前提にしない
公式ドキュメントでは、previewと記載された項目はパブリックプレビューであり、サービスレベルアグリーメントなしで提供され、本番ワークロードには推奨されないと明記されています。(Microsoft Learn)
社内の設計書や運用手順では、preview機能を使う場合に次の条件を明記しておくと安全です。
| 確認項目 | 記載すべき内容 |
|---|---|
| 利用目的 | 検証用途か、本番補助用途か |
| 代替手段 | 機能変更や停止時にどう運用するか |
| 影響範囲 | どのプロジェクト、エージェント、利用者に影響するか |
| 判断者 | 本番利用を誰が承認したか |
| 見直し日 | 正式版移行や仕様変更の確認タイミング |
管理者向けチェックリスト
Azure AI Foundry環境でFoundry Control Planeを使い始める場合、管理者は次の順番で確認すると効率的です。
| 優先度 | 確認項目 | 作業内容 |
|---|---|---|
| 高 | 対象サブスクリプションの棚卸し | Operate > Assetsでエージェント、モデル、ツールを確認する |
| 高 | RBAC | Reader、Contributor、Owner、Foundry系ロール、Cost Management Reader、Application Insights参照権限を確認する |
| 高 | AI Gateway | Foundryリソースと既存プロジェクトにGatewayが有効か確認する |
| 高 | Application Insights | 各プロジェクトまたはエージェントに接続されているか確認する |
| 中 | Compliance | ガードレールポリシーの適用範囲と例外ルールを設計する |
| 中 | Quota | モデル、リージョン、デプロイごとの容量を確認する |
| 中 | カスタムエージェント | 登録対象、URL切り替え、OpenTelemetry設定を確認する |
| 低 | 運用手順 | Stop、Block、Unknown状態への対応手順を整備する |
まずは「見える化」を優先してください。最初からすべてのポリシーを強制しようとすると、既存プロジェクトの運用と衝突しやすくなります。Assetsで棚卸しし、Application Insightsで監視できる状態を作り、その後にガードレールやトークン制限を段階的に適用するのが現実的です。
開発者向けチェックリスト
開発者は、エージェントやモデルを作る段階で次の項目を確認しておくと、あとから運用チームとの手戻りを減らせます。
| 確認項目 | 推奨アクション |
|---|---|
| エージェント名・タグ | プロジェクト名、用途、環境、本番/検証の区別が分かる命名にする |
| バージョン管理 | 本番公開中のバージョンと開発中バージョンを区別する |
| 監視 | Application Insightsを早めに接続し、実行後にメトリックが出るか確認する |
| トレース | 障害調査に必要なTrace ID、Conversation ID、ツール呼び出し情報を確認する |
| カスタムエージェント | 登録後のFoundry生成URLをクライアントが使うようにする |
| ガードレール | 本番前にComplianceポリシーで非準拠にならないか確認する |
| コスト | トークン使用量が想定を超えていないか検証段階で見る |
開発者が特に意識したいのは、「Control Planeで管理されること」を前提にエージェントを作ることです。ログやトレースが出ないエージェントは、問題が起きたときに原因を追いにくく、結果として本番運用に乗せづらくなります。
まず何から始めるべきか
Microsoft Foundry Control Planeは、Azure AI Foundryをチーム単位の実験環境から、組織全体のAI運用基盤へ広げるための管理レイヤーです。変更点の本質は、個々のプロジェクトを見に行く運用から、エージェント、モデル、ツールを横断して監視・統制する運用へ移ることにあります。
最初にやるべきことは明確です。
まず、Operate > Assetsで現在見えているAI資産を棚卸しします。次に、AI GatewayがFoundryリソースと既存プロジェクトに対して有効になっているか確認します。そのうえで、Application Insights、RBAC、Cost Management Reader、ガードレールポリシー、クォータを順番に確認してください。
本番展開を控えている場合は、特に「既存プロジェクトのAI Gateway有効化」「Application Insightsの接続」「ポリシー適用による非準拠の有無」「カスタムエージェント登録後のURL切り替え」を優先して確認すべきです。ここを後回しにすると、監視できない、制御できない、コストが見えない、リリース直前にポリシー違反が見つかるといった問題につながります。
Foundry Control Planeは、単なる新機能ではなく、AIエージェントを安全に増やすための運用設計そのものです。Azure AI Foundryを継続的に使う組織では、開発チームだけでなく、Azure管理者、セキュリティ担当、コンプライアンス担当、コスト管理担当を含めて、早めに確認項目を共有しておくことが重要です。
コメント