組織全体への Microsoft Foundry のロールアウト

構造化されたデプロイ計画は、Microsoft Foundry を大規模に導入するときに、セキュリティのギャップ、コスト超過、アクセスのスプロールを回避するのに役立ちます。 このガイドを使用して、ワークロードの境界を定義し、リソース トポロジを選択し、セルフサービス チームのガバナンスを確立します。

前提 条件

計画を開始する前に、次の内容があることを確認します。

  • 組織におけるベースラインの Azure サブスクリプションとリソース グループの構成に関する理解。
  • ネットワーク、暗号化、およびデータ分離に関する組織のセキュリティ要件に関する入力。
  • モデルと機能の可用性に基づく初期リージョン 計画。 詳細については、 クラウド リージョン間での機能の可用性に関するページを参照してください。
  • 組織内のネットワーク、暗号化、およびデータ分離のセキュリティ要件に関する契約。
  • チームが使用する予定の Foundry の機能と API のインベントリ。

分離境界を定義する

まず、AI プラットフォーム共有に関する クラウド導入フレームワーク の意思決定ガイダンスから始めて、次にその決定内容を Foundry に適用します。

すべての状況は一意ですが、一般的な組織では次の順序をお勧めします。

  1. 部署、データ ドメイン、製品所有権、環境レベルをまたがる、ネゴシエーション不可能な共有境界を定義します。
  2. 文書化された例外でコロケーションが許可されていない限り、既定で分離に設定される prod ポリシーを設定します。
  3. コンプライアンスまたは検証で分離が必要でない限り、実験を高速化するために既定でコロケーションに設定される探索ポリシーを設定します。
  4. セキュリティ、コスト、インシデント対応の所有権など、各境界に所有権を割り当てます。

機能とアクセス要件を特定する

トポロジを完了する前に、各ワークロードに必要な Foundry の機能と API を決定します。

Note

すべての Foundry API で、さまざまな認証モード、ストレージ暗号化レベル、およびプロジェクト レベルの分離がサポートされているわけではありません。 Foundry Tools API の一部では、親 Foundry リソース スコープでロールの割り当てが必要な場合があります。

1 つの Foundry リソースを共有する併置ユース ケースの場合は、各ユース ケースの分離ワークスペースとして Foundry プロジェクトを使用します。 たとえば、アイデアを試しているチームは、セキュリティ、モデルデプロイ、ツール アクセスのためのインフラストラクチャのセットアップを繰り返すことなく、コヒーレントアセットを整理するプロジェクトを作成できます。

エージェント中心の最新の Foundry API では、プロジェクト スコープのアクセス許可がサポートされています。 音声テキスト変換など、一部の従来の Foundry Tools API (旧 Azure AI サービス) には、引き続き親リソース スコープのアクセスが必要です。 目的のアクセス管理スコープで必要なすべての機能にアクセスできるように、境界と RBAC を計画します。

機能領域 プロジェクト別に整理する プロジェクトレベルでのRBAC分離 ご自身でストレージを用意してください ネットワーク/暗号化のサポート 計画への影響
エージェントの機能 (エージェント、応答、評価、データセット、インデックス、ファイル、プレイグラウンドアセット) はい はい はい 基本セットアップ (マネージド ストレージ) では制限されます。 全体をカバーするには、"standard" を使用します。 共有環境でのプロジェクトごとのユース ケースのセグメント化に適しています。
トレーニングを微調整する いいえ (既定のプロジェクトのみ) いいえ 一部(入力のみ) はい 各チームで個別の微調整が必要な場合は、個別の Foundry リソースを使用します。 微調整されたデプロイは、リソース内のプロジェクト間で共有され、使用できます。
OpenAI イメージ、ビデオ、バッチ いいえ いいえ 部分 (バッチのみ) はい 分離されたワークロードのセットアップを使用し、マネージド ストレージが必要な場合は、早期に RBAC 制約を検証します。
コンテンツ理解 はい いいえ はい はい ユース ケースごとの厳密なアクセス分離が必要な場合は、個別の Foundry リソースを使用します。
音声 はい (微調整) いいえ はい 基本セットアップ (マネージド ストレージ) では制限されます。 完全な CMK 暗号化カバレッジの場合は、BYO Storage を使用します。
Language はい (微調整) いいえ はい 基本セットアップ (マネージド ストレージ) では制限されます。 完全な CMK 暗号化カバレッジの場合は、BYO Storage を使用します。
Translator いいえ いいえ いいえ はい 分離が必須の場合は、個別の Foundry リソースを使用します。

重要

ロールアウトの前に、正確な機能の組み合わせを確認します。 必要な API が Foundry リソース スコープでのみ機能する場合は、そのスコープでロールを割り当てるか、ワークロードを個別の Foundry リソースに分離します。

Foundry リソース トポロジの選択

境界と機能のニーズを定義したら、環境ごとにトポロジを選択します。

判断経路 Foundry の推奨設定 最適 主なトレードオフ
同一場所に配置されたワークロード 複数のプロジェクトを含む 1 つの Foundry リソース (通常、ユース ケースごとに 1 つのプロジェクト) 実験の負荷の高い環境、初期のプロトタイプ、および共有デプロイと共有接続されたデータまたはツールの利点を活用するチーム 本番環境のインシデント、クォータ枯渇、設定ミスに共通する影響範囲
完全に分離されたワークロード 運用環境のワークロード境界あたり 1 つの Foundry リソース (多くの場合、ワークロードごとに 1 つのプライマリ プロジェクト) 厳格な運用分離、独立したアクセス制御、ならびに独立したクォータまたはコストの境界を必要とする本番ワークロード 管理するリソースが増え、セットアップのオーバーヘッドが高くなり、セルフサービスの有効化が困難になります

Tip

運用環境では、分離を既定として扱います。 ワークロードの境界、データ要件、およびリスクの受け入れが一致する場合にのみ、コロケーションを意図的な例外として使用します。

Foundry リソースを示す図のスクリーンショット。

セキュリティ ベースラインを計画する

この参照表は、セキュリティ設計上の決定のためのチェックリストとして使用します。

Area 決定する内容 次から開始
ID とアクセス 管理者、プロジェクト マネージャー、およびプロジェクト ユーザーペルソナを定義します。 各ペルソナを最小特権ロールとMicrosoft Entra ID グループにマップします。 Foundry でのロールベースのアクセス制御
ネットワーク 環境ごとにネットワーク モデルを選択します。 より安全で簡単なセットアップには、マネージド仮想ネットワークを使用します。 高度なネットワーク制御とカスタム ルーティング要件には、Bring Your Own (BYO) 仮想ネットワークを使用します。 運用環境の前にプライベート DNS とエンドポイント承認フローを検証します。 マネージド仮想ネットワークの構成Foundry のプライベート リンクの構成ネットワークで保護されたセットアップ (BYO 仮想ネットワーク)
データ保護とキー Microsoftマネージド キーがポリシー要件を満たしているかどうか、またはカスタマー マネージド キーが必要かどうかを決定します。 Foundry の顧客管理キー
認証モデル ユーザーとサービスのMicrosoft Entra IDと RBAC を優先します。 ロールの細かな制御が不要な場合にのみ、API キーを使用してください。 Foundry でのロールベースのアクセス制御

モデル、リージョン、容量の戦略を計画する

ワークロードごとに、次を定義します。

  • ユース ケースで必要なモデル ファミリとデプロイの種類。
  • データ処理の要件 (グローバル制約やリージョン制約など)。
  • 対話型シナリオとバッチ シナリオのスループットと待機時間のターゲット。
  • 安定した状態とピーク時の負荷に対するクォータとプロビジョニングされた容量の要件。

次の参照を使用します。

接続とデータ統合を計画する

ワークロードごとに、外部の依存関係と接続パターンを特定します。

  • データ ソースとデータ ストア。
  • 内部 API と基幹業務システム。
  • エージェントまたはオーケストレーション フローで必要なAzure以外の SaaS ツール。
  • プライベート エンドポイント、DNS 解決、エグレス制御、マネージド ネットワークと BYO 仮想ネットワークのどちらが必要かを含むネットワーク要件。

接続のセットアップを標準化するには、 Foundry で [接続の追加] を使用します。

接続は、目的の分離スコープに応じて、親 Foundry リソース レベルと子プロジェクト レベルの両方で作成できます。 親レベルで構成された接続は、すべてのプロジェクトで使用できます。

自動化と運用を計画する

チームが環境間で一貫してリソースを作成および管理する方法を定義します。

  • コードとしてインフラストラクチャを使用して、コア リソースとポリシーの既定値をプロビジョニングします。
  • プロジェクト、接続、モデルデプロイ、および構成変更のデプロイ パイプラインを標準化します。
  • モデルとポリシーの変更のロールバックとインシデント対応の手順を定義します。

自動化パターンとスターター実装の場合は、次のコマンドを使用します。

サンプル テンプレートには、プライベート ネットワーク、カスタマー マネージド キー、ロールベースのアクセス制御など、一般的なセキュリティ シナリオのエンド ツー エンド パターンが含まれています。

セルフサービス ガードレールを定義する

明確な制約内でのみセルフサービスを有効にします。

  • プロジェクトの作成、モデルのデプロイ、外部ツールの接続を行うことができるロールを定義します。
  • どのモデル プロバイダー、およびどのツール接続が許可されているかなど、モデルのデプロイとランタイムの動作にポリシー 制御を適用します。
  • 共有環境と分離環境のコスト管理と予算アラートを設定します。
  • Microsoft Foundry、Microsoft Copilot Studio、Microsoft 365全体の一元的な可観測性にトレース ログを適用します。

次の参照を使用します。

所有権とガバナンスを割り当てる

この手順は、プロビジョニングされたインフラストラクチャから運用開発者の使用への移行として扱います。

ほとんどの組織は既に、事前に作成されたMicrosoft Entra ID グループを使用してアクセスを管理しています。 これらのグループを必要なスコープで Foundry ロールにマップし、管理アクセス パスと開発アクセス パスの両方を検証します。

Foundry は、次の対象ごとにアクセスを分離します:

  • リソース管理のためのコントロール プレーン RBAC アクション
  • 開発ワークロード向けのデータ プレーンの RBAC アクション

重要

所有者や共同作成者などの管理ロールでは、すべての開発シナリオでは十分ではありません。 たとえば、ユーザーはリソースを管理できますが、Foundry でエージェントとチャットするにはデータ プレーンロールが必要です。

ロール マッピングのガイダンスと必要なロールの組み合わせについては、 Foundry でのロールベースのアクセス制御に関するページを参照してください。

ユーザー グループをオンボードした後、Foundry の使用状況、信頼性、系列、コンプライアンスを追跡するためのガバナンス ダッシュボードの確立または拡張を検討します。

サンプル プラットフォームのデプロイ

Contoso の IT 組織は、次の 2 つの優先順位のバランスを取りながら、複数のチームをサポートする必要があります。

  • 開発者が非運用データを使用して最新の AI テクノロジを厳密にテストできる迅速なイノベーション。
  • 運用化のための資金を受け取る実証済みのユース ケース向けに、完全に分離された開発/テスト環境と運用環境。

この図は、Contoso が共有探索 Foundry インスタンスを併置して、すべてのチームが利用できるイノベーションを実現する方法を示しています。容量と事前に接続されたデータとツールは限られています。 サンプル バックログには、カスタマー サポート、従業員ヘルプデスク、財務業務、調達、販売などの一般的なエンタープライズ機能が反映されています。 これまで、開発/テストのロールアウトのために実証済みの実現可能性またはセキュリティで保護された資金に進むユース ケースはわずかです。 それらから、さらに小さなサブセットが prod に進みます。また、このサンプルでは、同じ CRM データ、ユーザー ペルソナ、接続されたシステムを共有するため、探索と開発/テストを通じて併配置された 2 つの関連する販売ユース ケースも示しています。 ユース ケースが成熟すると、チームには段階的に強力な分離環境が割り当てられ、必要に応じて完全な prod グレードの分離が実現します。

Contoso のユース ケースが、共有探索 Foundry 環境から分離または併配置された開発/テスト環境に移行した後、より少数のワークロード用に分離された prod 環境に移行する様子を示す図。

詳細情報

次の手順