Microsoft Foundry アーキテクチャ

Microsoft Foundry は、階層構造のアーキテクチャ (ガバナンスのための最上位の Foundry リソース、開発の分離のためのプロジェクト、ストレージ、検索、シークレット管理のための接続された Azure サービス) を通じて AI ワークロードを整理します。

この記事では、IT 運用チームとセキュリティ チームに、Foundry リソースと基になる Azure サービス アーキテクチャ、そのコンポーネント、およびその他の Azure リソースの種類との関係について詳しく説明します。 この情報を使用して、Foundry の展開を組織の要件に 合わせてカスタマイズ する方法について説明します。 組織で Foundry をロールアウトする方法の詳細については、「 Foundry ロールアウト」を参照してください。

このアーキテクチャを使用する場合

このシナリオに関連する場合は、Foundry リソース モデルを検討してください。

• 初回セットアップ: 新しい AI プロジェクトを開始し、モデルアクセス、エージェントホスティング、評価ツールをバンドルする単一のリソースが必要です。
• マルチチーム アクセス: 複数のチームには、共有モデルのデプロイと一元化されたガバナンスを備えた分離されたプロジェクトが必要です。
• コンプライアンスに基づく設計: 組織では、リソースレベルとプロジェクト レベルの両方でプライベート ネットワーク、カスタマー マネージド暗号化、または Azure RBAC スコープが必要です。
• Azure OpenAI の移行: スタンドアロンの Azure OpenAI リソースから移行しており、エージェントと評価機能を追加しながら、既存のポリシーと RBAC を維持したいと考えています。

単一開発者の探索では、1 つのプロジェクトを含む Foundry リソースが推奨される既定値です。 ワークロードでエージェントのホスティングや評価なしで Azure OpenAI の完了のみが必要な場合は、スタンドアロンの Azure OpenAI リソースで十分な場合があります。

Azure AI リソースの種類とプロバイダー

Azure AI 製品ファミリ内では、スタック内のさまざまなレイヤーでユーザーのニーズをサポートするこれらの Azure リソース プロバイダー を使用できます。

エージェントの構築、モデルのデプロイ、評価ワークフローなど、ほとんどの AI 開発シナリオでは、Foundry リソースが推奨される開始点です。 Foundry リソースは、Microsoft.CognitiveServices プロバイダー名前空間を Azure OpenAI、Speech、Vision、Language などのサービスと共有します。 この共有プロバイダー名前空間は、関連する AI リソース間で管理 API、アクセス制御パターン、ネットワーク、ポリシー動作を調整するのに役立ちます。

次の表を使用して、ワークロードに一致するリソースの種類を特定します。 Microsoft.CognitiveServices プロバイダー内の特定のリソースの種類と機能が表示されます。

同じプロバイダー名前空間の下にあるリソースの種類は、同じ管理 API を共有し、Azure Policy 構成に対して同様の Azure ロールベースのアクセス制御 (Azure RBAC) アクション、ネットワーク構成、エイリアスを使用します。 Azure OpenAI から Foundry にアップグレードする場合、既存のカスタム Azure ポリシーと Azure RBAC アクションは引き続き適用されます。

Foundry リソース階層

次の図は、モデルのデプロイ、セキュリティ設定、接続、および 2 つのプロジェクトを含む Foundry リソースを示しています。 Storage、Key Vault、Azure AI 検索 などの接続された Azure サービスは、独自のガバナンス境界の下で個別の Azure リソースです。

アーキテクチャとアクセス境界を計画するときは、次のモデルを使用します。

• Foundry リソース: ネットワーク、セキュリティ、モデルのデプロイなどのガバナンス設定を管理する最上位レベルの Azure リソース。
• プロジェクト: チームがユース ケースを構築して評価する Foundry リソース内の開発境界。 プロジェクトを使用すると、構成済みの環境内でチームのプロトタイプを作成し、IT セットアップを繰り返すことなく既存のモデルのデプロイと接続を再利用できます。
• プロジェクト資産: ファイル、エージェント、評価、およびプロジェクトにスコープが設定された関連成果物。
• 接続されたリソース: Foundry リソースが接続を介して参照するストレージ、Key Vault、Azure AI 検索 などの Azure サービス。 これらのリソースには個別のガバナンス境界があるため、ネットワーク ポリシーとアクセス ポリシーは個別に管理します。

この分離により、IT チームはリソース レベルで集中管理を適用し、開発チームはプロジェクト レベルの境界内で作業できます。

セキュリティ主導の懸念事項の分離

Foundry は、セキュリティで保護されたスケーラブルな AI ワークロードを確保するために、管理操作と開発操作を明確に分離します。

最上位レベルのリソース ガバナンス

最上位の Foundry リソースは、セキュリティの構成、他の Azure サービスとの接続の確立、デプロイの管理などの管理操作を対象とします。 専用のプロジェクト コンテナーは、開発アクティビティを分離し、アクセス制御、ファイル、エージェント、および評価の境界を提供します。

ロールベースのアクセス制御

Azure RBAC アクションは、この懸念事項の分離を反映しています。 デプロイやプロジェクトの作成などのコントロール プレーン アクションは、エージェントの構築、評価の実行、ファイルのアップロードなどのデータ プレーン アクションとは異なります。 RBAC の割り当てのスコープは、最上位レベルのリソースと個々のプロジェクト レベルの両方で行うことができます。 セキュリティで保護された自動化とサービス アクセスをサポートするために、いずれかのスコープで マネージド ID を 割り当てます。 詳細については、「 Microsoft Foundry のロールベースのアクセス制御」を参照してください。

最小限の権限導入の一般的な基本の割り当てには、次のようなものがあります。

• Foundry リソース スコープ内の各開発者用ユーザープリンシパルのAzure AI ユーザー。
• Foundry リソース スコープでのプロジェクトマネージド ID ごとの Azure AI ユーザー。

ロールの定義とスコープの計画ガイダンスについては、 Microsoft Foundry のロールベースのアクセス制御に関するページを参照してください。

監視と可観測性

Azure Monitor では、メトリックがスコープ別にセグメント化されます。 管理メトリックと使用状況メトリックは最上位レベルのリソースで表示できますが、評価パフォーマンスやエージェント アクティビティなどのプロジェクト固有のメトリックは、個々のプロジェクト コンテナーにスコープが設定されます。

主な監視機能は次のとおりです。

• リソース レベルのメトリック: トークン消費量、モデルの待機時間、要求数、およびすべてのプロジェクトのエラー率。
• プロジェクト レベルのメトリック: 評価実行の結果、エージェント呼び出し数、およびファイル操作アクティビティ。
• 診断ログ: 診断設定を有効にして、分析と保持のためにログを Log Analytics、Storage、または Event Hubs にルーティングします。

詳細については、 Azure Monitor の概要に関するページを参照してください。

コンピューティング インフラストラクチャ

Foundry は、モデルのホスティング、エージェントの実行、バッチ処理のためのコンピューティング インフラストラクチャを管理します。 このセクションでは、デプロイの種類、エージェントと評価インフラストラクチャ、仮想ネットワーク統合、テナントの分離、コンテンツの安全性制御、リージョンの可用性について説明します。

モデルデプロイの種類

Foundry では、データ処理スコープ (グローバル (リージョン間)、データ ゾーン (定義された境界内)、リージョン (単一リージョン) でグループ化された、モデル ホスティング用の複数のデプロイの種類がサポートされています。 各種類では、待機時間、スループット、およびデータ処理の場所のバランスが異なります。

適切なデプロイの種類を選択する方法の詳細については、「 Foundry モデルのデプロイの種類」を参照してください。

エージェント、評価、バッチ処理

エージェント、評価、バッチ ジョブは、Microsoft によって完全に管理されます。 エージェント ワークロードはプラットフォームのコンテナー インフラストラクチャ内で実行されます。これは、ネットワーク分離シナリオの 仮想ネットワーク統合 をサポートします。 評価では、モデル エンドポイントが呼び出され、出力が評価基準と比較され、プロジェクト スコープ内に結果が格納されます。 バッチ処理キューでは、トークンごとの価格が下がり、非同期実行の推論要求が行われます。 3 つのワークロードの種類すべてに対する結果には、ポータルまたは SDK を使用してアクセスできます。

仮想ネットワークの統合

エージェントが外部システムに接続する場合は、 コンテナーインジェクションを使用してネットワーク トラフィックを分離できます。この場合、プラットフォームによってサブネットが仮想ネットワークに挿入され、同じ仮想ネットワーク内の Azure リソースとのローカル通信が可能になります。

Foundry では、送信分離のために次の 2 つのネットワーク モデルがサポートされています。

テナントの分離

ワークロードは、Foundry リソースごとに論理的に分離された環境で実行されます。 顧客コードは、ランタイム コンテナーを他のテナントと共有しません。

コンテンツの安全性とガードレール

Foundry は、コンテンツの安全性コントロールをモデルとエージェントの推論パイプラインに統合します。 ガードレールは、検出するリスク、スキャンする介入ポイント (ユーザー入力、出力、ツール呼び出し (プレビュー))、およびツールの応答 (プレビュー))、およびリスクが検出されたときの対応アクションを定義します。 コンテンツ フィルターはモデル要求と共にインラインで実行され、デプロイごとに構成できます。 詳細については、「 ガードレールとコントロールの概要」および 「 コンテンツ フィルタリングの重大度レベル」を参照してください。

リージョン別の可用性

コンピューティング機能は、Azure リージョンによって異なります。 モデルの可用性、デプロイの種類のオプション、エージェントや評価などの機能のサポートは、リージョンによって異なる場合があります。 プロビジョニングする前に、ターゲット リージョンで必要な機能がサポートされていることを確認します。 現在の可用性については、 クラウド リージョン間の機能の可用性に関するページを参照してください。

データ ストレージ

Foundry には、幅広い AI ワークロードをサポートする柔軟で安全なデータ ストレージ オプションが用意されています。

ファイルアップロード用のマネージド ストレージ

既定のセットアップでは、Foundry は、論理的に分離された Microsoft が管理するストレージ アカウントを使用し、OpenAI モデルやエージェントなどの一部のユース ケースに対してファイルの直接アップロードをサポートします。顧客が提供するストレージ アカウントは必要ありません。

独自のストレージを持ち込む

必要に応じて、独自の Azure Storage アカウントを接続できます。 評価やバッチ処理などの Foundry ツールは、これらのアカウントから入力を読み取り、出力を書き込むことができます。 サポートされているシナリオの詳細については、「 エージェント サービスを使用した独自のリソースの持ち込み」を参照してください。

エージェント状態保存

• 基本的なエージェントのセットアップでは、エージェント サービスは、Microsoft が管理するマルチテナント ストレージにスレッド、メッセージ、およびファイルを論理的に分離して格納します。
• 標準エージェントのセットアップでは、ファイル、会話、ベクター ストアなど、すべての顧客データに対して独自の Azure リソースを使用できます。 この構成では、データはストレージ アカウント内のプロジェクトによって分離されます。

カスタマー マネージド キーの暗号化

既定では、Azure サービスは、FIPS 140-2 準拠の 256 ビット AES 暗号化を使用して、Microsoft マネージド キーを使用して保存中および転送中のデータを暗号化します。 コードの変更は必要ありません。

代わりに独自のキーを使用するには、Foundry のカスタマー マネージド キーを有効にする前に、次の前提条件を確認してください。

• Key Vault は、Foundry リソースと同じ Azure リージョンにデプロイされます。
• Key Vault では、論理的な削除と消去の保護が有効になっています。
• マネージド ID には、Azure RBAC を使用する場合の Key Vault Crypto User ロールなど、必要なキーアクセス許可があります。

独自の Key Vault を持ち込む

既定では、Foundry は、すべての API キーベースの接続シークレットをマネージド Azure Key Vault に格納します。 シークレットを自分で管理する場合は、キー コンテナーを Foundry リソースに接続します。 1 つの Azure Key Vault 接続によって、すべてのプロジェクトおよびリソース レベルの接続シークレットが管理されます。 詳細については、 Foundry への Azure Key Vault 接続を設定する方法を参照してください。

データ暗号化の詳細については、 Foundry での暗号化に関するカスタマー マネージド キーに関するページを参照してください。

データの保存場所とコンプライアンス

Foundry は、すべての保存データを指定された Azure 地域に格納します。 推論データ (プロンプトと入力候補) は、デプロイの種類に応じて処理されます。グローバル デプロイは、任意の Azure リージョンにルーティングされる可能性があり、データ ゾーンのデプロイは米国または EU ゾーン内に留まり、デプロイ リージョンでは標準またはリージョンのデプロイ プロセスが維持されます。 詳細については、「 デプロイの種類」を参照してください。 Foundry では、リージョン間の自動フェールオーバーはサポートされていません。 組織で複数リージョンの可用性が必要な場合は、各ターゲット リージョンに個別の Foundry リソースをデプロイし、アプリケーション 層でデータの同期とルーティングを管理します。 コンプライアンス認定の詳細については、 Azure コンプライアンスのドキュメントを参照してください。

アーキテクチャの決定を検証する

ロールアウトの前に、ターゲット環境に対して次の内容を検証します。

• デプロイ リージョンで必要なモデルと機能が使用可能であることを確認します。 詳細については、 クラウド リージョン間の機能の可用性に関するページを参照してください。
• Foundry リソース レベルとプロジェクト レベルの両方でロールの割り当てが正しくスコープ設定されていることを確認します。 詳細については、 Microsoft Foundry のロールベースのアクセス制御に関するページを参照してください。
• ネットワーク分離要件とプライベート アクセス パスを検証します。 詳細については、「 Foundry のプライベート リンクを構成する方法」を参照してください。
• カスタマー マネージド キーや Azure Key Vault の統合など、暗号化とシークレット管理の要件を確認します。 詳細については、Foundry を使用した 暗号化のためのカスタマー マネージド キー と、 Foundry への Azure Key Vault 接続を設定する方法に関するページを参照してください。
• モデルデプロイの制限やレート制限など、ターゲット リソースのクォータと制限を確認します。 詳細については、 Azure OpenAI のクォータと制限 、 エージェント サービスの制限、クォータ、リージョンに関するページを参照してください。

関連コンテンツ

• 組織全体での Foundry 導入
• Microsoft Foundry のロールベースのアクセス制御
• Foundry を使用した暗号化のためのカスタマー マネージド キー
• Foundry のプライベート リンクを構成する方法
• エージェント サービスを使用した独自のリソースの持ち込み
• Azure Monitor の概要
• Azure OpenAI のクォータと制限
• Foundry モデル展開の種類
• ガードレールとコントロールの概要
• クラウド リージョン間での機能の可用性