構造化されたロールアウト計画を使用すると、Microsoft Foundry を大規模に導入するときに、セキュリティのギャップ、コストオーバーラン、アクセスのスプロールを回避できます。 このガイドでは、環境のセットアップ、データの分離、他のAzure サービスとの統合、容量管理、監視など、Foundry のロールアウトに関する主要な決定事項について説明します。 このガイドを出発点として使用し、ニーズに合わせて調整します。 実装の詳細については、リンクされた記事を参照してください。
[前提条件]
ロールアウト計画を開始する前に、次の準備が完了していることを確認します。
- 開発、テスト、運用環境向けのターゲット Azure サブスクリプションおよびリソース グループの戦略。
- Microsoft Entra IDグループ (または同等の ID グループ) は、管理者、プロジェクト マネージャー、およびプロジェクト ユーザーに対して定義されます。
- モデルと機能の可用性に基づく初期リージョン 計画。 詳細については、 クラウド リージョン間の機能の可用性に関するページを参照してください。
- 組織内のネットワーク、暗号化、およびデータ分離のセキュリティ要件に関する契約。
ベースラインロールアウトチェックリスト
最初の運用ロールアウトの前に、次のチェックリストを使用します。
- 開発、テスト、運用の間で環境の境界を定義します。
- Foundry リソースとprojectスコープごとに所有権を割り当てます。
- 使用する Foundry 機能を決定します。 すべての機能 API がプロジェクト コンテキストで使用できるわけではありません。 ユース ケースの分離のために最も低いプロジェクト スコープでアクセス許可を割り当てる予定がある場合、Translator などの従来のAzure AI API ではサポートされない可能性があります。 これらのユーザーには、すべてのユーザーが親 Foundry リソース レベルに対するアクセス許可を持っている必要があります。 このような場合は、Foundry リソースによる分離をお勧めします。
- 管理者、project マネージャー、およびproject ユーザーの RBAC 割り当てを定義します。
- 各環境 (パブリック access、プライベート エンドポイント、またはハイブリッド) のネットワーク アプローチを定義します。
- ポリシーでカスタマー マネージド キーが必要かどうかを決定します。
- 各ビジネス グループのコストと監視の所有権を定義します。
- 必要な共有接続とプロジェクトスコープ接続を特定します。
組織の例
Contoso は、異なるニーズと技術的成熟度を持つ 5 つのビジネス グループ間で GenAI の導入を検討しているグローバル企業です。
Contoso Enterprise IT は、監視を維持しながら導入を加速するために、ネットワークや一元化されたdata managementを含む共通の共有リソースを持つモデルを有効にし、管理されたセキュリティで保護された環境内の各チームの Foundry へのセルフサービス accessを有効にしてユース ケースを管理することを目的としています。
ロールアウトに関する考慮事項
Foundry リソースは、チームの環境を構成、セキュリティ保護、監視するためのスコープを定義します。 Foundry ポータルと Azure API を使用して使用できます。 プロジェクトは、このリソース コンテキスト内で作業を整理するためのフォルダーに似ています。 また、プロジェクトは、Foundry 開発者 API とツールへのアクセスおよびアクセス許可を制御します。
Important
プロジェクトは、エージェントの作成と Foundry ネイティブ機能用に最適化された事前構成済みのサンドボックス環境を提供します。 ただし、Foundry は多数のクラシック Azure AI サービスに基づいて構築されているため、すべてのクラシック API がプロジェクト コンテキストで使用できるわけではありません。 チームが使用する予定の機能を特定し、チームがプロジェクト レベルのアクセスをサポートしているかどうかを確認します。 親 Foundry リソース レベルでアクセス許可を必要とする Translator などのサービスの場合は、コストの分離とアクセス制御に個別の Foundry リソースを使用することを検討してください。
チーム間の一貫性、スケーラビリティ、ガバナンスを確保するには、Foundry を展開するときに、次の環境セットアップ プラクティスを検討してください。
開発、テスト、運用のための個別の環境を確立します。 個別のリソース グループまたはサブスクリプションと Foundry リソースを使用して、ワークフローを分離し、accessを管理し、制御されたリリースでの実験をサポートします。
ビジネス グループごとに個別の Foundry リソースを作成します。 デプロイをデータ ドメインやビジネス機能などの論理境界に合わせて調整し、自律性、ガバナンス、コスト追跡を確保します。 また、プロジェクト スコープのアクセスをサポートしていない従来の Azure AI API がチームに必要な場合は、個別の Foundry リソースも検討してください。
プロジェクトをユース ケースに関連付けます。 Foundry プロジェクトは、特定のユース ケースを表し、アプリケーションのエージェントやファイルなどのコンポーネントを整理するためのコンテナーを提供します。 親リソースからセキュリティ設定を継承する一方で、独自のaccessコントロール、データ統合、およびその他のガバナンス コントロールを実装することもできます。 プロジェクト スコープのアクセス許可を割り当てる前に、チームがプロジェクト レベルのアクセスをサポートすることを計画している API を確認します。
Foundry 環境のセキュリティ保護
Foundry はAzure プラットフォーム上に構築されているため、組織のニーズに合わせてセキュリティ制御をカスタマイズできます。
アイデンティティ
Microsoft Entra IDを使用して、ユーザーとサービスのアクセスを管理します。 Foundry では、他のAzure サービスに対する安全なパスワードレス認証を許可するマネージド ID がサポートされています。 マネージド ID は、Foundry リソース レベルで割り当てることができ、必要に応じてproject レベルできめ細かく制御できます。 詳細については、Foundry の ロールベースのアクセス制御 を参照してください。
ネットワーク
Foundry をVirtual Networkにデプロイし、ネットワーク セキュリティ グループ (NSG) を使用してトラフィックを分離し、アクセスを制御します。 プライベート接続のシナリオでは、プライベート エンドポイントを使用し、DNS とエンドポイントの承認の状態を検証します。 実装の詳細と制限事項については、「 Foundry のprivate linkを構成する方法を参照してください。
Important
エージェントや評価などの一部の機能では、エンドツーエンドの分離のために追加のネットワーク構成が必要です。 実装の詳細と現在の制限事項については、「 Foundry のネットワーク分離を構成する方法」を参照してください。
カスタマー マネージド キー
Azureでは、保存データを暗号化するためのカスタマー マネージド キー (CMK) がサポートされます。 Foundry では、厳密なコンプライアンスニーズを持つお客様に対して、必要に応じて CMK がサポートされます。 詳細については、 Foundry のカスタマー マネージド キーを参照してください。
認証と承認
Foundry では、単純な統合では API キーベースのアクセスと、きめ細かな制御のための Azure RBAC の両方がサポートされています。 API キーを使用するとセットアップを簡略化できますが、RBAC を使用したMicrosoft Entra IDと同じロールベースの細分性は提供されません。 Azureでは、control plane (リソースの作成や構成などのリソース管理操作) と、data プレーン (モデルの呼び出しやデータへのアクセスなどのランタイム操作) の間に明確な分離が適用されます。 組み込みのロールから開始し、必要に応じてカスタム ロールを定義します。 詳細については、Foundry の ロールベースのアクセス制御 を参照してください。
テンプレート
ARM テンプレートまたはBicepを使用して、セキュリティで保護されたデプロイを自動化します。 サンプル インフラストラクチャ テンプレートについて説明します。
Storage
Foundry で組み込みのストレージ機能を使用するか、独自のストレージ リソースを使用するかを選択できます。 エージェント サービスの場合、スレッドとメッセージは、必要に応じて、ユーザーが管理リソースに格納できます。
例: Contoso のセキュリティ アプローチ
Contoso は、中央ハブ ネットワークを管理するエンタープライズ IT とプライベート ネットワークを組み合わせて使用し、自社の Foundry デプロイをセキュリティで保護します。 各ビジネス グループは、スポーク virtual network経由で接続します。 組み込みのロールベースのアクセス制御 (RBAC) を使用して、アクセスを分離します。
- 管理者が デプロイ、接続、共有リソースを管理する
- Projectマネージャー特定のプロジェクトを監督する
- ユーザーが GenAI ツールを操作する
ほとんどのユース ケースでは、Contoso は既定でMicrosoft管理された暗号化に依存しており、
ユーザーアクセスを計画する
効果的なaccess管理は、セキュリティで保護されたスケーラブルな Foundry セットアップの基礎となります。
アクセス ロールと責任を定義する
Foundry 環境のさまざまな側面にaccessする必要があるユーザー グループを特定します。 次のような責任に基づいて、組み込みまたはカスタムAzure RBAC ロールを割り当てます。
- アカウント所有者: セキュリティや共有リソース接続などの最上位の構成を管理します。
- Projectマネージャー: Foundry プロジェクトとその共同作成者を作成および管理します。
- Project ユーザー: 既存のプロジェクトに投稿します。
ロールアウト計画のために、このスターター ロールからスコープのマッピングを使用してください。
| ペルソナ | 初級ポジション | 推奨されるスコープ |
|---|---|---|
| 管理者 | 所有者または Azure AI アカウント所有者 | サブスクリプションまたは Foundry リソース |
| Project マネージャー | Azure AI プロジェクト マネージャー | ファウンドリー リソース |
| プロジェクトユーザー | Azure AI ユーザー | 鋳造プロジェクト |
最小特権の要件とエンタープライズ ポリシーに基づいて割り当てを調整します。
アクセス スコープを決定する
アクセス割り当ての適切なスコープを選択します。
- サブスクリプション レベル: 最も広範なアクセス。通常、中央の IT チームまたはプラットフォーム チームや小規模な組織に適しています。
- リソース グループ レベル: 共有アクセス ポリシーを使用して関連リソースをグループ化する場合に便利です。 たとえば、Foundry 環境と同じアプリケーション ライフサイクルに従うAzure関数です。
- リソースまたはプロジェクト レベル: 特に機密データを処理する場合やセルフサービスを有効にする場合に、きめ細かい制御に最適です。
ID 戦略を調整する
Foundry と統合されたデータ ソースとツールの場合は、ユーザーが次を使用して認証する必要があるかどうかを判断します。
- マネージド ID または API キー: ユーザー間の自動サービスと共有アクセスに適しています。
- ユーザー ID: ユーザー レベルのアカウンタビリティまたは監査が必要な場合に推奨されます。
Microsoft Entra ID グループを使用して、アクセス管理を簡素化し、環境間の一貫性を確保します。
最小限の特権のオンボードを行う場合は、開発者とプロジェクトマネージド ID の Azure AI User ロールから開始し、必要な場合にのみ昇格されたロールを追加します。 詳細については、Foundry の ロールベースのアクセス制御 を参照してください。
他のAzure サービスとの接続を確立する
Foundry では、connections がサポートされています。これは、Azureおよび非Azure サービス上のアプリケーション コンポーネントへのアクセスを可能にする再利用可能な構成です。 これらの接続は identity brokers としても機能し、Foundry は、マネージド ID またはサービス プリンシパルを使用して、projectユーザーの代わりに外部システムに対して認証を行うことができます。
Azure StorageやKey Vaultなどの共有サービスのFoundry リソース レベルで接続を作成します。 機密性の高い統合またはプロジェクト固有の統合のために、特定のプロジェクトへの接続のスコープを設定します。 この柔軟性により、チームはニーズに基づいて再利用と分離のバランスを取ることができます。 Foundry の接続の詳細を確認します。
管理とオンボードを簡素化するために、Microsoft Entra IDマネージド ID や API キーなどの共有アクセス トークンを使用するように接続認証を構成するか、機密データ ソースにアクセスするときの制御を強化する Entra ID パススルー経由のユーザー トークンを構成します。
例: Contoso の接続戦略
- Contoso は、すべてのビジネス グループに対して Foundry リソースを作成し、同様のデータを持つプロジェクトで同じ接続リソースを共有する必要があります。
- 既定では、接続されているリソースは共有認証トークンを使用し、すべてのプロジェクトで共有されます。
- 機密データ ワークロードを使用するプロジェクトは、プロジェクト スコープ接続とMicrosoft Entra IDパススルー認証を使用してデータ ソースに接続します。
Governance
Foundry の効果的なガバナンスにより、ビジネス グループ全体でセキュリティで保護され、準拠し、コスト効率の高い運用が保証されます。
-
Model Access Controlと Azure Policy Azure Policy は、Azure リソース間で規則を適用します。 Foundry では、ポリシーを使用して、特定のビジネス グループがaccessできるモデルまたはモデル ファミリを制限します。
Example : Contoso のFinance&リスク グループは、ビジネス グループのサブスクリプション レベルでポリシーを適用することで、プレビュー モデルまたは非準拠モデルの使用が制限されます。 - 事業グループ別コスト管理 Contoso は、ビジネス グループごとに Foundry をデプロイすることで、コストを個別に追跡および管理できます。 Azure料金計算ツールを使用して、デプロイ前の見積もりとMicrosoft Cost Managementを使用して、継続的な実際の使用状況と傾向の追跡を行います。 Foundry コストは、ソリューションの総コストの 1 つの部分として扱います。
- Usage Tracking with Azure Monitor Azure Monitor には、Foundry リソースの使用パターン、パフォーマンス、正常性を追跡するためのメトリックとダッシュボードが用意されています。
- Azure Log Analytics Azure Log Analytics を使用したVerbose ログにより、操作上の分析情報を得るためのログの詳細な検査が可能になります。 たとえば、監査と最適化をサポートするためのログ要求の使用状況、トークンの使用状況、待機時間などです。
ロールアウトの決定を検証する
ロールアウト計画を定義したら、次の結果を検証します。
- IDとアクセス: ロールの割り当ては、認証されたペルソナとスコープにマップされます。
- ネットワーク: 接続パスと分離モデルは、環境ごとに文書化されています。
- ネットワーク検証: プライベート エンドポイントの接続状態は Approved であり、DNS は Foundry エンドポイントをvirtual network内からプライベート IP アドレスに解決します。
- データ保護: 暗号化アプローチ (Microsoft マネージド キーまたはカスタマー マネージド キー) が文書化され、承認されます。
- 運用: コストと監視の所有者は、ビジネス グループごとに割り当てられます。
- 運用検証: コスト ビューとダッシュボードはMicrosoft Cost Managementで定義され、監視は運用プロジェクトごとに Application Insights に接続されます。
- モデル操作: デプロイ戦略 (標準またはプロビジョニング済み) は、ユース ケースごとに文書化されています。
- リージョンの準備: ロールアウトの前に、必要なモデルとサービスがターゲット リージョンで確認されます。
モデルデプロイの構成と最適化
Foundry でモデルをデプロイする場合、チームは標準デプロイの種類とプロビジョニングされた デプロイの種類を選択できます。 標準デプロイは、開発と実験に最適で、柔軟性とセットアップの容易さを提供します。 予測可能なパフォーマンス、コスト管理、モデル バージョンのピン留めが必要な運用シナリオでは、プロビジョニングされたデプロイをお勧めします。
リージョンをまたがるシナリオをサポートし、既存のモデル デプロイにアクセスできるようにするために、Foundry では、他の Foundry または Azure OpenAI インスタンスでホストされているモデル デプロイにconnectionsを提供しています。 接続を使用することで、チームは、分散プロジェクトからのaccessを有効にしながら、実験のためにデプロイを一元化できます。 運用ワークロードの場合は、モデルのライフサイクル、バージョン管理、ロールバック戦略をより厳密に制御できるように、ユース ケースで独自のデプロイを管理することを検討してください。
過剰使用を防ぎ、公平なリソース割り当てを確保するために、 デプロイ レベルで 1 分あたりのトークン数 (TPM) の制限を適用できます。 TPM の制限は、消費を制御し、偶発的な急増から保護し、使用量をprojectの予算またはクォータに合わせて調整するのに役立ちます。 共有デプロイでは保守的な制限を設定し、重要な運用サービスのしきい値を高くすることを検討してください。
詳細情報
Foundry 環境をセキュリティで保護する
- 認証と RBAC: Foundry におけるロールベースのアクセス制御
- ネットワーク: Foundry でvirtual networkを使用する
- カスタマー マネージド キー (CMK): Foundry のカスタマー マネージド キー
- インフラストラクチャの例: テンプレート リポジトリとサンプル インフラストラクチャ テンプレート
- 削除された Foundry リソースを復旧または消去します
他のAzure サービスとの接続を確立する
- 接続の概要: Foundry に新しい接続を追加する