Azure AI Foundryで新しくAIアプリやエージェントを展開するなら、最初に押さえるべき結論は「Foundryリソースをガバナンスの中心に置き、プロジェクト単位で開発を分離し、Storage・Key Vault・Azure AI Searchなどの接続先は別リソースとして管理する」という点です。公式記事「Microsoft Foundry architecture – Microsoft Foundry」は、単なる構成説明ではなく、Azure OpenAIからの移行、RBAC、ネットワーク分離、データ所在地、監視設計まで影響するアーキテクチャ指針として読む必要があります。(Microsoft Learn)
特に管理者は「Foundryリソースを作れば関連リソースまで一括で安全になる」と考えないことが重要です。接続されたStorage、Key Vault、Azure AI Searchはそれぞれ独立したAzureリソースであり、ネットワーク、アクセス権、コンプライアンス設定は個別に確認する必要があります。(Microsoft Learn)
Microsoft Foundry architectureで押さえるべき変更点
Microsoft Foundry architectureの中心は、Azure AI Foundryのワークロードを次の3層で整理する考え方です。
| 層 | 役割 | 実務上の意味 |
|---|---|---|
| Foundryリソース | ネットワーク、セキュリティ、モデルデプロイなどを管理する最上位のAzureリソース | 管理者がガバナンス、ポリシー、共通設定を集約する場所 |
| プロジェクト | Foundryリソース内の開発境界 | チームやユースケースごとにアクセス権、ファイル、エージェント、評価を分離する場所 |
| 接続されたAzureサービス | Storage、Key Vault、Azure AI Searchなど | Foundryとは別のガバナンス境界を持つため、個別に権限・ネットワークを管理する対象 |
従来のAzure OpenAI中心の構成では、「モデルをデプロイしてAPIを呼ぶ」ことに焦点が当たりがちでした。Foundry architectureでは、エージェント、評価、ファイル、検索、シークレット、監視まで含めたAIアプリ基盤として設計する必要があります。公式情報でも、エージェント構築、モデルデプロイ、評価ワークフローを含む多くのAI開発シナリオではFoundryリソースが推奨される開始点とされています。(Microsoft Learn)
一方で、すべてをプロジェクトスコープで扱えるわけではありません。多くの新しいAPIはプロジェクトスコープで利用できますが、一部の機能はFoundryリソースレベルでのみ利用できます。公式例では、Translator APIはプロジェクトスコープではなくFoundryリソースレベルから利用する機能として示されています。既存アプリを移行する場合は、APIの呼び出し先スコープを必ず確認してください。(Microsoft Learn)
影響を受ける対象者
Microsoft Foundry architectureの影響は、開発者だけに限られません。むしろ、運用・セキュリティ・クラウド管理者が先に設計を固めないと、後から権限やネットワークを直すコストが大きくなります。
| 対象者 | 主な確認ポイント |
|---|---|
| Azure管理者 | Foundryリソース、プロジェクト、接続リソースの責任範囲を分ける |
| セキュリティ担当者 | RBAC、Entra ID認証、Key Vault、CMK、プライベートアクセスを確認する |
| 開発者 | プロジェクトスコープ、利用API、モデルデプロイ、評価・エージェント機能を確認する |
| SRE・運用担当 | Azure Monitor、診断ログ、リージョン、クォータ、フェールオーバー方針を確認する |
| Azure OpenAI移行担当 | 既存のRBAC、Azure Policy、ネットワーク、APIスコープの継続可否を確認する |
特に複数チームでAzure AI Foundryを使う企業では、「1つのFoundryリソースに複数プロジェクトを作るのか」「部署・環境・リージョンごとにFoundryリソースを分けるのか」を早めに決めておくべきです。プロジェクトは開発境界として便利ですが、接続リソースやリージョン要件まで自動的に分離するものではありません。
RBACとID管理で確認すべきポイント
Foundry architectureでは、管理操作と開発操作が明確に分けられています。プロジェクトやデプロイを作成するようなコントロールプレーン操作と、エージェント構築、評価実行、ファイルアップロードなどのデータプレーン操作は別物として扱われます。RBACの割り当ては、Foundryリソーススコープとプロジェクトスコープの両方で設計できます。(Microsoft Learn)
まず確認したいのは、開発者とプロジェクトのマネージドIDにFoundry Userロールが適切に付与されているかです。公式のRBAC情報では、最小限の開始構成として、ユーザープリンシパルとプロジェクトのマネージドIDにFoundry Userロールを割り当てることが示されています。(Microsoft Learn)
また、Foundry RBACロールは名称変更が進んでいます。Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前はAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerという名称でした。名称変更中は古い名前が表示される場合がありますが、ロールIDと中核権限は変更されないと説明されています。(Microsoft Learn)
実務で失敗しやすいのは、次の3点です。
| 確認項目 | 失敗しやすい例 | 対応 |
|---|---|---|
| 認証方式 | APIキー認証のまま運用し、細かいRBAC制御が効かない | 可能な範囲でMicrosoft Entra ID認証へ寄せる |
| ロール選択 | Cognitive Services系ロールやAzure AI DeveloperをFoundry用に流用する | Foundry User、Foundry OwnerなどFoundry向けロールを使う |
| デプロイ方法 | CLIやSDKで作成したため、想定した自動ロール割り当てが入っていない | デプロイ後にIAMでユーザーとマネージドIDを確認する |
公式RBAC情報では、キーベース認証ではロール制限なしのフルアクセスになり得るため、細かなアクセス制御にはEntra ID認証が推奨されています。また、CLIやSDKからFoundryをデプロイする場合、ポータル経由とは異なり一部の自動割り当てが適用されない点にも注意が必要です。(Microsoft Learn)
ネットワーク分離とプライベートアクセスの注意点
Azure AI Foundryを社内システムや機密データと接続する場合、ネットワーク設計は最初から確認すべき項目です。Foundryでは、エージェントが外部システムへ接続する際にコンテナーインジェクションを使い、仮想ネットワーク内のAzureリソースとローカル通信できる構成が説明されています。(Microsoft Learn)
公式情報では、送信分離のネットワークモデルとして「Customer-managed VNet」と「Managed VNet」が示されています。Customer-managed VNetは利用者がVNetと専用サブネットを用意する方式で、制御性が高い一方、ネットワーク管理の負担も増えます。Managed VNetはFoundry側がVNetを管理する方式ですが、プレビューとして扱われ、カスタマイズ性に制限があります。(Microsoft Learn)
特に注意したいのは、ポータルだけで完結しない構成があることです。公式情報では、すべてのパブリックアクセスをブロックするプライベートエンドポイント構成など、一部のネットワーク分離シナリオではポータルUIではなくSDKまたはCLIが必要になると説明されています。(Microsoft Learn)
ネットワーク面では、最低限次を確認してください。
| 確認項目 | 確認内容 |
|---|---|
| Foundryリソースの公開範囲 | パブリックアクセスを許可するか、Private Link中心にするか |
| 接続先Storage | ストレージアカウントのファイアウォール、プライベートエンドポイント、RBAC |
| Key Vault | ネットワーク制限、アクセスポリシーまたはAzure RBAC、論理削除と消去保護 |
| Azure AI Search | インデックス利用時のアクセス権、ネットワーク到達性、ロール割り当て |
| エージェントの外部接続 | ツール呼び出し先、社内API、VNet統合の要否 |
データストレージと暗号化で確認すべきポイント
Foundry architectureでは、データの保存場所とストレージ構成も重要です。既定では、FoundryはMicrosoft管理のストレージを使い、一部のOpenAIモデルやエージェント用途でファイルアップロードをサポートします。一方で、評価やバッチ処理などの用途では、自社のAzure Storageアカウントを接続して入力・出力を扱う構成も選べます。(Microsoft Learn)
エージェントの状態保存にも注意が必要です。基本的なエージェントセットアップでは、スレッド、メッセージ、ファイルがMicrosoft管理のマルチテナントストレージに論理分離されて保存されます。標準エージェントセットアップでは、ファイル、会話、ベクターストアなど顧客データに自社Azureリソースを使用でき、データはストレージアカウント内でプロジェクトごとに分離されます。(Microsoft Learn)
カスタマー マネージド キーを使う場合は、Key VaultがFoundryリソースと同じAzureリージョンにあること、Key Vaultで論理削除と消去保護が有効であること、マネージドIDにKey Vault Crypto Userなど必要な権限があることを事前に確認します。これらを後から直すと、環境再作成や権限再設計が必要になる場合があります。(Microsoft Learn)
データ所在地とモデルデプロイの判断基準
モデルデプロイの種類は、性能や料金だけでなく、データ処理場所にも影響します。Foundryでは、グローバル、データゾーン、単一リージョン、プロビジョニング済み、バッチ、Developerなど複数のデプロイ種別が示されています。グローバル系はリージョンをまたぐ処理、データゾーン系は定義されたゾーン境界内、StandardやRegional Provisionedは単一リージョンでの処理として整理されています。(Microsoft Learn)
判断基準は次のように考えると実務で迷いにくくなります。
| 要件 | 優先して検討する方向 |
|---|---|
| 検証・PoCを早く始めたい | Standardや小規模なFoundryリソース構成 |
| データ所在地を重視する | 単一リージョンまたはデータゾーンの可否を確認 |
| 高スループットが必要 | Provisioned系の適合性を確認 |
| 非同期処理でコストを抑えたい | Batch系の利用可否を確認 |
| 本番利用前の一時検証 | Developer系は制約やSLAの有無を確認して限定利用 |
公式情報では、Foundryの保存データは指定されたAzure geographyに保存される一方、推論データの処理場所はデプロイ種別によって異なると説明されています。また、Foundryはリージョン間の自動フェールオーバーをサポートしていないため、複数リージョン可用性が必要な場合は、各リージョンにFoundryリソースを個別に展開し、アプリケーション層で同期とルーティングを管理する必要があります。(Microsoft Learn)
Azure OpenAIから移行する場合の確認ポイント
Azure OpenAIからAzure AI Foundryへ移行する場合、既存のAzure PolicyやRBACがそのまま使えるかどうかは重要な関心事です。公式情報では、FoundryリソースはAzure OpenAI、Speech、Vision、Languageなどと同じMicrosoft.CognitiveServicesプロバイダー名前空間を共有し、Azure OpenAIからFoundryへアップグレードする場合、既存のカスタムAzure PolicyとAzure RBACアクションは引き続き適用されると説明されています。(Microsoft Learn)
ただし、「既存ポリシーが適用される」と「移行作業が不要」は同じではありません。Foundryではプロジェクトスコープ、接続リソース、エージェント、評価、ストレージ、Key Vaultなどの設計対象が増えます。移行時は、既存のAPI呼び出しだけでなく、開発チームの作業場所と管理境界を見直してください。
| 確認項目 | 具体的に見る場所 | 注意点 |
|---|---|---|
| リソース構成 | Azureポータル、リソースグループ | Foundryリソースとプロジェクトの分け方を決める |
| APIスコープ | アプリのエンドポイント設定、SDK設定 | プロジェクトスコープかFoundryリソーススコープか確認する |
| RBAC | Access control（IAM） | ユーザーとマネージドIDの両方を確認する |
| Azure Policy | サブスクリプション、リソースグループ、リソース | 既存ポリシーがプロジェクトや接続リソースにも適切か確認する |
| ネットワーク | Private Link、VNet、ファイアウォール | ポータルだけで設定できない構成がないか確認する |
| データ保存 | Storage、Key Vault、Search | 接続リソース側の権限とネットワークを個別に確認する |
| 監視 | Azure Monitor、診断設定 | リソースレベルとプロジェクトレベルの両方を見る |
| クォータ | モデルデプロイ、レート制限 | 本番移行前に上限とリージョン可用性を確認する |
監視と運用で見るべきメトリック
Foundry architectureでは、監視もリソースレベルとプロジェクトレベルで分けて考えます。公式情報では、Azure Monitorのメトリックはスコープごとに分割され、トークン消費量、モデル待機時間、要求数、エラー率などはリソースレベルで確認でき、評価実行結果、エージェント呼び出し数、ファイル操作アクティビティなどはプロジェクトレベルで確認できると説明されています。(Microsoft Learn)
運用開始前には、診断設定を有効にし、ログをLog Analytics、Storage、Event Hubsのどこへ送るか決めておきます。PoC段階ではポータル上の確認で足りることもありますが、本番では障害調査、監査、コスト分析のためにログ保持先を明確にしておくべきです。(Microsoft Learn)
新規展開時のおすすめ構成
小規模な検証なら、1つのFoundryリソースに1つのプロジェクトを作り、Entra ID認証、最小限のFoundry Userロール、既定ストレージ、基本的な診断ログから始めるのが現実的です。早く検証しつつ、あとで本番設計へ移れるように、リソース名、リージョン、タグ、ログ出力先だけは最初から整えておきます。
企業利用では、次のような分け方が扱いやすくなります。
| 設計対象 | 推奨される考え方 |
|---|---|
| Foundryリソース | 環境、リージョン、データ分類、管理責任で分ける |
| プロジェクト | チーム、プロダクト、ユースケース単位で分ける |
| Storage | 機密度や保持要件に応じてBYOを検討する |
| Key Vault | シークレット管理責任が明確な場合は自社Key Vault接続を検討する |
| Azure AI Search | RAGや社内検索を使う場合、インデックス単位の権限とネットワークを設計する |
| 監視 | Log Analyticsを中心に、監査・障害調査・コスト分析の用途を分ける |
避けたいのは、全チームを1つのプロジェクトに詰め込む構成です。ファイル、エージェント、評価、権限の境界が曖昧になり、後から「誰がどのデータにアクセスできるのか」を説明しにくくなります。逆に、開発者ごとにFoundryリソースを乱立させると、モデルデプロイ、クォータ、監視、コスト管理が煩雑になります。
管理者と開発者のチェックリスト
展開前、またはAzure OpenAIからの移行前に、次の項目を確認してください。
| チェック項目 | 管理者 | 開発者 |
|---|---|---|
| Foundryリソースとプロジェクトの分離方針を決めたか | はい | 影響確認 |
| Foundry Userなど適切なRBACを割り当てたか | はい | はい |
| プロジェクトのマネージドIDに必要な権限があるか | はい | 影響確認 |
| APIキーではなくEntra ID認証を使えるか検討したか | はい | はい |
| Storage、Key Vault、Searchの権限を個別に確認したか | はい | 影響確認 |
| プライベートアクセスやVNet統合の要否を確認したか | はい | 影響確認 |
| デプロイ種別とデータ処理場所を確認したか | はい | はい |
| 対象リージョンでモデル、エージェント、評価が使えるか確認したか | はい | はい |
| Azure Monitorと診断ログの出力先を決めたか | はい | 影響確認 |
| クォータ、レート制限、モデルデプロイ上限を確認したか | はい | はい |
よくある誤解と注意点
Foundryリソースを作れば接続先も自動的に安全になるわけではない
Storage、Key Vault、Azure AI Searchは独立したAzureリソースです。Foundry側で接続できても、接続先のネットワーク、RBAC、ファイアウォール、監査ログが適切とは限りません。(Microsoft Learn)
プロジェクト分離だけでコンプライアンス要件を満たせるとは限らない
プロジェクトは開発境界として有効ですが、データ所在地、暗号化、シークレット管理、プライベートアクセスは別途設計が必要です。特に規制業種では、プロジェクト単位の分離とAzureリソース単位の分離を混同しないようにしてください。
グローバルデプロイは常に最適とは限らない
グローバル系のデプロイは性能や可用性の観点で有効な場合がありますが、データ処理場所の要件がある場合は慎重に判断する必要があります。推論データの処理場所はデプロイ種別によって変わるため、法務・セキュリティ部門と確認してから本番利用に進めるべきです。(Microsoft Learn)
ポータル操作だけで本番ネットワーク構成を完了できるとは限らない
プライベートエンドポイントで全パブリックアクセスをブロックするような構成では、ポータルUIだけでは構成できないケースがあります。本番ネットワーク要件が厳しい場合は、SDK、CLI、IaCを前提に設計してください。(Microsoft Learn)
まず取るべき次のアクション
Azure AI Foundryをこれから導入する場合は、最初に「誰が管理し、誰が開発し、どのリソースに接続し、どのリージョンで処理するのか」を1枚の構成図に落とし込んでください。そのうえで、Foundryリソース、プロジェクト、接続リソース、RBAC、ネットワーク、監視の順に確認すると、設計漏れを減らせます。
既にAzure OpenAIを使っている場合は、既存のモデルデプロイやAPI設定だけでなく、Azure Policy、RBAC、Private Link、Key Vault、Storage、Azure AI Search、診断ログまで棚卸しすることが重要です。Microsoft Foundry architectureは、Azure AI Foundryを単体サービスではなく、企業向けAI基盤として安全に展開するための設計図として活用してください。
コメント