次の方法で共有

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

このガイドでは、環境のセットアップ、データの分離、他のAzure サービスとの統合、容量管理、監視など、Microsoft Foundry のロールアウトに関する主要な決定事項について説明します。 このガイドを出発点として使用し、ニーズに合わせて調整します。 実装の詳細については、リンクされた記事で詳細なガイダンスを参照してください。

[前提条件]

ロールアウト計画を開始する前に、次の準備が完了していることを確認します。

  • 開発、テスト、運用環境向けのターゲットAzureサブスクリプションとリソースグループの戦略。
  • Microsoft Entra IDグループ (または同等の ID グループ) は、管理者、projectマネージャー、およびproject ユーザーに対して定義されます。
  • モデルと機能の可用性に基づく初期リージョン 計画。 詳細については、 クラウド リージョン間の機能の可用性に関するページを参照してください。
  • 組織内のネットワーク、暗号化、およびデータ分離のセキュリティ要件に関する契約。

ベースラインロールアウトチェックリスト

最初の運用ロールアウトの前に、次のチェックリストを使用します。

  1. 開発、テスト、運用の間で環境の境界を定義します。
  2. Foundry リソースとprojectスコープごとに所有権を割り当てます。
  3. 管理者、project マネージャー、およびproject ユーザーの RBAC 割り当てを定義します。
  4. 各環境 (パブリック access、プライベート エンドポイント、またはハイブリッド) のネットワーク アプローチを定義します。
  5. ポリシーでカスタマー マネージド キーが必要かどうかを決定します。
  6. 各ビジネス グループのコストと監視の所有権を定義します。
  7. 必要な共有接続とプロジェクトスコープ接続を特定します。

組織の例

Contoso は、異なるニーズと技術的成熟度を持つ 5 つのビジネス グループ間で GenAI の導入を検討しているグローバル企業です。

Contoso Enterprise IT は、監視を維持しながら導入を加速するために、ネットワークや一元化されたdata managementを含む共通の共有リソースを持つモデルを有効にし、管理されたセキュリティで保護された環境内の各チームの Foundry へのセルフサービス accessを有効にしてユース ケースを管理することを目的としています。

ロールアウトに関する考慮事項

Foundry リソースは、チームの環境を構成、セキュリティ保護、監視するためのスコープを定義します。 Foundry ポータルと Azure API を使用して使用できます。 プロジェクトは、このリソース コンテキスト内で作業を整理するためのフォルダーに似ています。 また、プロジェクトは、Foundry 開発者 API とツールへのアクセスおよびアクセス許可を制御します。

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

チーム間の一貫性、スケーラビリティ、ガバナンスを確保するには、Foundry を展開するときに、次の環境セットアップ プラクティスを検討してください。

  • 開発、テスト、運用のための個別の環境を確立します。 個別のリソース グループまたはサブスクリプションと Foundry リソースを使用して、ワークフローを分離し、accessを管理し、制御されたリリースでの実験をサポートします。

  • ビジネス グループごとに個別の Foundry リソースを作成します。 デプロイをデータ ドメインやビジネス機能などの論理境界に合わせて調整し、自律性、ガバナンス、コスト追跡を確保します。

  • プロジェクトをユース ケースに関連付けます。 Foundry プロジェクトは、特定のユース ケースを表すために設計されています。 これらは、アプリケーションのエージェントやファイルなどのコンポーネントを整理するためのコンテナーです。 親リソースからセキュリティ設定を継承する一方で、独自のaccessコントロール、データ統合、およびその他のガバナンス コントロールを実装することもできます。

Foundry 環境のセキュリティ保護

Foundry はAzure プラットフォーム上に構築されているため、組織のニーズに合わせてセキュリティ制御をカスタマイズできます。 主要な構成領域は次のとおりです。

  • Identity: Microsoft Entra IDを使用してユーザーとサービスのaccessを管理します。 Foundry では、他のAzure サービスに対する安全なパスワードレス認証を許可するマネージド ID がサポートされています。 マネージド ID は、Foundry リソース レベルで割り当てることができ、必要に応じてproject レベルできめ細かく制御できます。  マネージド ID の詳細を参照してください。

  • Networking: Foundry をVirtual Networkにデプロイし、ネットワーク セキュリティ グループ (NSG) を使用してトラフィックを分離し、accessを制御します。  ネットワークセキュリティについて詳しく知る

    プライベート接続のシナリオでは、プライベート エンドポイントを使用し、DNS とエンドポイントの承認の状態を検証します。 実装の詳細と制限事項については、「 Foundry のprivate linkを構成する方法を参照してください。

    Important

    エンド ツー エンドのネットワーク分離は、新しい Foundry ポータル エクスペリエンスでは完全にはサポートされていません。 ネットワーク分離デプロイの場合は、Foundry のプライベートリンクを構成する方法にあるクラシックエクスペリエンス、SDK、または CLI のガイダンスを使用します。

  • カスタマー管理キー (CMK): Azureでは、保存データを暗号化するためにCMKをサポートしています。 Foundry では、厳密なコンプライアンスニーズを持つお客様に対して、必要に応じて CMK がサポートされます。  CMK の詳細を確認してください。

  • 認証と承認: Foundry では、単純な統合のために API キーベースのaccess の両方がサポートされ、きめ細かな制御のために Azure RBAC がサポートされます。 API キーを使用するとセットアップを簡略化できますが、RBAC を使用したMicrosoft Entra IDと同じロールベースの細分性は提供されません。 Azureでは、control plane (リソース管理) と データプレーン (モデルとデータアクセス) の間に明確な分離が適用されます。 組み込みのロールから開始し、必要に応じてカスタム ロールを定義します。 認証の詳細について学んでください。

  • テンプレート: ARM テンプレートまたは Bicep を使用して、セキュリティで保護されたデプロイを自動化します。 サンプル テンプレートを調べる。

  • Storage リソース: Foundry で組み込みのstorage機能を使用するか、独自のstorage リソースを使用するかを選択できます。 エージェント サービスの場合、スレッドとメッセージは、必要に応じて、ユーザーが管理リソースに格納できます。

例: Contoso のセキュリティ アプローチ

Contoso は、中央ハブ ネットワークを管理するエンタープライズ IT とプライベート ネットワークを組み合わせて使用し、自社の Foundry デプロイをセキュリティで保護します。 各ビジネス グループは、スポーク virtual network経由で接続します。 組み込みのロールベースアクセス制御 (RBAC) を使用して、アクセスを分けます。

  • 管理者が デプロイ、接続、共有リソースを管理する
  • Projectマネージャー特定のプロジェクトを監督する
  • ユーザーが GenAI ツールを操作する

ほとんどのユース ケースでは、Contoso は既定で Microsoft が管理する暗号化に依存しており、 Customer-Managed キーは使用しません。

ユーザーアクセスを計画する

効果的なaccess管理は、セキュリティで保護されたスケーラブルな Foundry セットアップの基礎となります。

  • アクセス役割と責任を定義する

    • Foundry 環境のさまざまな側面にaccessする必要があるユーザー グループを特定します。
    • 次のような責任に基づいて、組み込みまたはカスタムAzure RBAC ロールを割り当てます。
      • アカウント所有者: セキュリティや共有リソース接続などの最上位の構成を管理します。
      • Project マネージャー: Foundry プロジェクトとその共同作成者を作成および管理します。
      • Projectユーザー: 既存のプロジェクトに貢献します。

    ロールアウト計画のために、このスターター ロールからスコープのマッピングを使用してください。

    ペルソナ 初級ポジション 推奨されるスコープ
    管理者 所有者または Azure AI アカウント所有者 サブスクリプションまたは Foundry リソース
    Project マネージャー Azure AIのプロジェクトマネージャー ファウンドリー リソース
    プロジェクトユーザー Azure AI ユーザー 鋳造プロジェクト

    最小特権の要件とエンタープライズ ポリシーに基づいて割り当てを調整します。

  • アクセス範囲を決定する

    • アクセス割り当ての適切なスコープを選択します。
      • サブスクリプション レベル: 最も広範なaccess。通常、中央の IT チームやプラットフォーム チームや小規模な組織に適しています。
      • リソース グループ レベル: 共有access ポリシーを使用して関連リソースをグループ化する場合に便利です。 たとえば、Foundry 環境と同じアプリケーション ライフサイクルに従うAzure関数です。
      • リソースレベルまたはprojectレベル: 特に機密データを処理する場合やセルフサービスを有効にする場合に、きめ細かい制御に最適です。

  • ID 戦略を調整する

    • Foundry と統合されたデータ ソースとツールの場合は、ユーザーが次を使用して認証する必要があるかどうかを判断します。
      • マネージド ID または API キー: ユーザー間の自動サービスと共有accessに適しています。
      • ユーザー ID: ユーザー レベルのアカウンタビリティまたは監査が必要な場合に推奨されます。
    • Microsoft Entra ID グループを使用して、access管理を簡素化し、環境間の一貫性を確保します。

    最小限特権でのオンボードを開始するには、開発者とプロジェクト マネージド ID の Azure AI User ロールを使い、必要に応じて昇格されたロールを追加します。 詳細については、Foundry の ロールベースのアクセス制御 を参照してください。

他のAzure サービスとの接続を確立する

Foundry では、connections がサポートされています。これは、Azureおよび非Azure サービス上のアプリケーション コンポーネントへのaccessを可能にする再利用可能な構成です。 これらの接続は identity brokers としても機能し、Foundry は、マネージド ID またはサービス プリンシパルを使用して、projectユーザーの代わりに外部システムに対して認証を行うことができます。

Azure StorageやKey Vaultなどの共有サービスのFoundry リソース レベルで接続を作成します。 機密性の高い統合またはプロジェクト固有の統合のために、特定のプロジェクトへの接続のスコープを設定します。 この柔軟性により、チームはニーズに基づいて再利用と分離のバランスを取ることができます。 Foundry の接続の詳細を確認します。

管理とオンボードを簡略化するために、Microsoft Entra IDマネージド ID や API キーなどの共有access トークンを使用するように接続認証を構成するか、Entra ID パススルー経由のユーザー トークンを使用します。これにより、機密データ ソースにアクセスするときの制御が強化されます。

Foundryプロジェクトの接続性と他のAzureサービスとの統合を示す図のスクリーンショット

例: 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 つの部分として扱います。
  • Azure Monitor を使用したUsage Tracking Azure Monitor には、Foundry リソースの使用パターン、パフォーマンス、正常性を追跡するためのメトリックとダッシュボードが用意されています。
  • Azure Log Analytics を使用した詳細ログにより、運用洞察を得るためのログの詳細な検査が可能になります。 たとえば、監査と最適化をサポートするためのログ要求の使用状況、トークンの使用状況、待機時間などです。

ロールアウトの決定を検証する

ロールアウト計画を定義したら、次の結果を検証します。

  • IDとアクセス: ロールの割り当ては、認証されたペルソナとスコープにマップされます。
  • ネットワーク: 接続パスと分離モデルは、環境ごとに文書化されています。
  • ネットワーク検証: プライベート エンドポイントの接続状態は Approved であり、DNS は Foundry エンドポイントをvirtual network内からプライベート IP アドレスに解決します。
  • データ保護: 暗号化アプローチ (Microsoft マネージド キーまたはカスタマー マネージド キー) が文書化され、承認されます。
  • 運用: コストと監視の所有者は、ビジネス グループごとに割り当てられます。
  • 操作の検証: コスト ビューとダッシュボードは Microsoft Cost Management で定義され、監視は運用projectごとに Application Insights に接続されます。
  • モデル操作: デプロイ戦略 (標準またはプロビジョニング済み) は、ユース ケースごとに文書化されています。
  • リージョンの準備: ロールアウトの前に、必要なモデルとサービスがターゲット リージョンで確認されます。

モデルデプロイの構成と最適化

Foundry でモデルをデプロイする場合、チームは標準デプロイの種類とプロビジョニングされた デプロイの種類を選択できます。 標準デプロイは、開発と実験に最適で、柔軟性とセットアップの容易さを提供します。 予測可能なパフォーマンス、コスト管理、モデル バージョンのピン留めが必要な運用シナリオでは、プロビジョニングされたデプロイをお勧めします。

リージョンをまたがるシナリオをサポートし、既存のモデル デプロイをaccessできるようにするために、Foundry では、他の Foundry インスタンスまたは Azure OpenAI インスタンスでホストされているデプロイをモデル化するために、connections を使用できます。 接続を使用することで、チームは、分散プロジェクトからのaccessを有効にしながら、実験のためにデプロイを一元化できます。 運用ワークロードの場合は、モデルのライフサイクル、バージョン管理、ロールバック戦略をより厳密に制御できるように、ユース ケースで独自のデプロイを管理することを検討してください。

過剰使用を防ぎ、公平なリソース割り当てを確保するために、 デプロイ レベルで 1 分あたりのトークン数 (TPM) の制限を適用できます。 TPM の制限は、消費を制御し、偶発的な急増から保護し、使用量をprojectの予算またはクォータに合わせて調整するのに役立ちます。 共有デプロイでは保守的な制限を設定し、重要な運用サービスのしきい値を高くすることを検討してください。

詳細情報

  • Last updated on