MicrosoftのクラウドAI開発プラットフォーム「Microsoft Foundry」のポータルが正式にGA（一般提供）へ移行し、パイロット用途から本番環境向けのエンタープライズグレードAI基盤としての利用が可能になった。

Microsoft Foundryとは何か

Microsoft Foundryは、AIモデルの展開・エージェント開発・本番運用をひとつのプラットフォームで完結させるMicrosoftのAI開発基盤だ。「Discover（探索）」「Build（構築）」「Operate（運用）」というエンドツーエンドのライフサイクルを統合することで、開発チームが信頼性・コンプライアンス・運用品質を犠牲にせずに迅速に動けることを目指している。

今回のGA移行により、以下の機能が本番利用可能となった：

  • RBAC（ロールベースアクセス制御）: チームごとの権限管理を細粒度で実現
  • 監査ログとコンプライアンスコントロール: 企業のガバナンス要件に対応
  • 監視・アラート機能: 本番AIワークロードの安定運用を支援
  • 仮想ネットワーク統合: セキュアなネットワーク環境でのAI実行

ポータル・API・SDK・CLIおよび開発者ツールにわたって、GAスコープの一貫したライフサイクル管理が提供される。

注意点：すべてが移行されたわけではない

GAのスコープは「Foundryプロジェクト」に限定されており、既存ユーザーは注意が必要だ。

新ポータルでサポートされないもの：

  • スタンドアロンのAzure OpenAIリソース（クラシックポータルの継続利用、またはFoundryプロジェクトへのアップグレードが必要）
  • ハブベースのクラシックプロジェクト（Foundryプロジェクトへの移行が必要）

認証についても整理が必要だ。多くの機能はAPIキー認証に対応しているが、評価（Evaluations）・データセット・Content Understanding・エージェント・ワークフローはMicrosoft Entra ID認証が必須となっている。ガバナンス重視の本番環境では、Entra IDとRBACの組み合わせが推奨される。APIキー認証はロールベースの権限粒度を提供しないため、企業用途では原則としてEntra IDを選ぶべきだ。

本番移行前に確認すべき事項

Microsoftは移行前に以下の確認を求めている：

  • モデル展開・エージェント開発・運用の必要シナリオを整理する
  • プレビュー専用機能やクラシックポータル依存箇所を洗い出す
  • 本番環境でGA機能のみを使用する組織ポリシーを定義する
  • 既存Azure OpenAI・クラシックFoundryワークロードの移行ガイダンスを確認する
  • チームとサービスアイデンティティに必要なロール割り当てを確認する

実務への影響

エンジニア・アーキテクト向け： 新規のAIエージェント開発プロジェクトは、Foundryプロジェクトをベースに設計するのが今後の標準になる。特にエージェント・ワークフロー系の機能はEntra ID認証が必須のため、セキュリティ設計の段階からID管理を組み込む必要がある。「とりあえずAPIキーで動かす」アプローチは開発初期には便利だが、本番移行時に設計の見直しを迫られる可能性がある。

IT管理者・セキュリティ担当向け： GAになったことで、監査ログとRBACが本番レベルでサポートされる。ゼロトラスト設計との親和性が高く、サービスアイデンティティ（Non-Human Identities）の管理も含めてEntra ID中心に統合できる体制が整いつつある。エージェントが自律的に動く環境では、人間のアカウントと同様にNHIへのJust-In-Timeアクセス制御を検討することを推奨する。

既存Azure OpenAIユーザー向け： 今すぐ移行が必須なわけではないが、新機能はFoundryプロジェクト側に集約されていく方向性は明確だ。移行タイミングを組織の開発ロードマップに組み込んでおくことを推奨する。

筆者の見解

Microsoft FoundryがGA到達によってエンタープライズAI基盤として形になってきたことは、正しい方向性だと思う。

特に注目しているのは、Foundryが特定のモデルに縛られない設計になっている点だ。Microsoftはモデル開発の競争で先頭を走っているわけではないが、「どのモデルでも安全に動かせるプラットフォーム」という立ち位置は長期的に見て非常に有利だ。Entra IDがAIエージェントの管制塔になるシナリオは、すでにMicrosoft基盤を持つ企業にとって現実的な最善手といえる。

一方で、クラシックポータルとの分断や移行パスの複雑さは、既存ユーザーにとって頭の痛い問題だ。「まずFoundryプロジェクトへ」という方針は理解できるが、既存資産の移行コストを丁寧にケアする姿勢を見せ続けてほしい。それだけのポテンシャルを持つ基盤だけに、移行の摩擦で採用が鈍ることがないよう期待したい。RBACや監査ログが揃ったいま、あとはユーザーがスムーズに乗り換えられる体験を磨くフェーズだ。

出典: この記事は New Microsoft Foundry portal general availability overview の内容をもとに、筆者の見解を加えて独自に執筆したものです。