Share via


マルチテナント機能と Azure OpenAI Service

Azure OpenAI を使用すると、OpenAI の強力な言語モデルにアクセスできます。 この記事では、マルチテナント ソリューションに役立つ Azure OpenAI の主な機能について説明します。 推奨リソースを確認して、アプローチの計画と Azure OpenAI の使用に役立ててください。

分離モデル

Azure OpenAI を使用するマルチテナント システムがある場合は、必要な分離レベルを決定します。 次の要素に基づいて分離モデルを決定します。

  • テナントはいくつある予定ですか?
  • 複数のテナント間でアプリケーション層を共有しますか? "はい" の場合、シングルテナント アプリケーション インスタンスをデプロイしますか、それともテナントごとに個別のデプロイを作成しますか?
  • テナントには、別のインスタンスへのアクセスを必要とするコンプライアンス要件がありますか?

次の表は、Azure OpenAI の主なテナント モデルをまとめたものです。

考慮事項 プロバイダーのサブスクリプション内のテナントごとの Azure OpenAI テナントのサブスクリプション内のテナントごとの Azure OpenAI 共有 Azure OpenAI
データの分離 非常に高
パフォーマンスの分離 低から中 (各テナントの 1 分あたりのトークン数 (TPM) による)
配置の複雑性 低から中 (テナントの数による) 高。 テナントは、プロバイダーにアクセス権を正しく付与する必要があります。
操作の複雑さ プロバイダーの場合は低、テナントの場合は高
サンプル シナリオ テナントごとの個々のアプリケーション インスタンス。 特定のコンプライアンス要件またはカスタム モデルを持つテナント。 共有アプリケーション層を備えた大規模なマルチテナント ソリューション。

プロバイダーのサブスクリプション内のテナントごとの Azure OpenAI

サービス プロバイダーの場合は、Azure サブスクリプション内のテナントごとに Azure OpenAI インスタンスをデプロイすることを検討してください。 このアプローチでは、テナントごとにデータが分離されます。 テナントの数を増やすにつれて、Azure OpenAI リソースの数を増やしてデプロイおよび管理する必要があります。

このアプローチは、テナントごとに個別のアプリケーション デプロイがある場合、またはクォータや 1 分あたりの要求などの制限を回避する必要がある場合に使用します。 詳細については、Azure OpenAI のクォータと制限に関する記事をご覧ください。

次の図は、プロバイダーのサブスクリプション内のテナントごとの Azure OpenAI モデルを示しています。

Diagram that shows the model for Azure OpenAI for each tenant in the provider's subscription.

テナントのサブスクリプション内のテナントごとの Azure OpenAI

場合によっては、テナントが自分の Azure サブスクリプションに Azure OpenAI インスタンスを作成し、それに対するアクセス権をアプリケーションに付与することがあります。 このアプローチは、テナントに特定のクォータや Microsoft からのアクセス許可 (最新のモデルへのアクセス、厳密でないフィルター処理、プロビジョニングされたスループットの使用など) がある場合に適しています。 テナントに微調整モデルがある場合も、このアプローチを使用できます。 または、顧客が管理する処理用 Azure OpenAI インスタンスを介してデータを処理して送信するコンポーネントが環境に必要な場合も使用できます。

テナントのサブスクリプション内の Azure OpenAI インスタンスにアクセスするには、テナントがアクセス権をアプリケーションに提供する必要があります。 アプリケーションの認証は、Microsoft Entra インスタンスを介して行う要があります。 1 つのアプローチは、マルチテナント Microsoft Entra アプリケーションを発行することです。 次のワークフローで、この方法の手順の概要を示します。

  1. テナントが、マルチテナント Microsoft Entra アプリケーションを自分の Microsoft Entra テナントに登録します。
  2. テナントが、マルチテナント Microsoft Entra アプリケーションに、Azure OpenAI リソースへの適切なレベルのアクセス権を付与します。 たとえば、テナントは、ロールベースのアクセス制御 (RBAC) を使用して、"Azure AI サービス ユーザー" ロールにアプリケーションを割り当てることができます。
  3. テナントが、作成する Azure OpenAI リソースのリソース ID を提供します。
  4. アプリケーション コードで、独自の Microsoft Entra インスタンスのマルチテナント Microsoft Entra アプリケーションに関連付けられているサービス プリンシパルを使って、テナントの Azure OpenAI インスタンスにアクセスできます。

または、各テナントに、サービスで使用するサービス プリンシパルを作成し、その資格情報を提供するように求めることもできます。 このアプローチでは、潜在的なセキュリティ責任として、テナントごとに資格情報を安全に格納および管理する必要があります。 テナントが Azure OpenAI インスタンスに対するネットワーク アクセス制御を構成する場合、それらにアクセスできることを確認します。

次の図は、テナントのサブスクリプション内のテナントごとの Azure OpenAI モデルを示しています。

Diagram that shows the model for Azure OpenAI for each tenant in the tenant's subscription.

共有 Azure OpenAI

複数のテナント間で Azure OpenAI のインスタンスを共有することもできます。 Azure OpenAI リソースは、ユーザーの Azure サブスクリプションまたはソリューション プロバイダーの Azure サブスクリプションにデプロイされます。 管理する責任はユーザーにあります。 このソリューションは実装が最も簡単ですが、提供されるデータ分離とパフォーマンスの分離は最小限です。

Azure OpenAI を共有すると、モデル デプロイのレベルではアクセス セキュリティが提供されません。 他のテナントは、承認されていないモデルを使用できます。 微調整モデルを使用する場合は、Azure OpenAI インスタンスを共有することは極力避けるようにしてください。 機密情報が公開され、テナント固有のリソースへの未承認のアクセスが許可されることがあります。

複数のテナント間で Azure OpenAI のインスタンスを共有すると、ノイズの多い近隣の問題も発生する可能性があります。 これにより、一部のテナントで待機時間が長くなることがあります。 また、アプリケーション コードをマルチテナント対応にする必要もあります。 たとえば、共有 Azure OpenAI インスタンスの従量課金コストを顧客に請求する場合、アプリケーション内のテナントごとにトークンの合計数を追跡するロジックを実装します。

複数の共有 Azure OpenAI インスタンスをデプロイすることもできます。 たとえば、デプロイ スタンプ パターンに従う場合、各スタンプ内に共有 Azure OpenAI インスタンスをデプロイします。 マルチリージョン ソリューションをデプロイする場合は、次の目的のために、各リージョンに Azure OpenAI をデプロイする必要があります。

  • リージョン間トラフィックの待ち時間を回避する。
  • データ所在地の要件をサポートする。
  • 同じリージョン デプロイを必要とする他のサービス内でリージョン Azure OpenAI を使用できるようにする。

共有 Azure OpenAI インスタンスがある場合は、その制限を考慮して、クォータを管理することが重要です。

次の図は、共有 Azure OpenAI モデルを示しています。

Diagram that shows the shared Azure OpenAI model.

テナントごとに同じモデルの共有 Azure OpenAI インスタンス

共有 Azure OpenAI インスタンスを使用する場合は、テナントごとに同じモデルのインスタンスをそれぞれデプロイすると、大きな利点が得られます。 このアプローチでは、各デプロイのパラメーターのカスタマイズが強化されます。 各モデルで使用するトークンの数が追跡されるため、テナント固有の TPM の割り当てが容易になります。これにより、正確にコストを割り当てて各テナントの使用状況を管理できます。 このアプローチではリソース使用率を最適化できるため、各テナントは必要なリソースに対してのみ支払いを行い、コスト効率の高いソリューションを確保できます。 テナントは、変化するニーズと使用パターンに基づいてリソースの割り当てを調整できるため、スケーラビリティと適応性も向上します。

Note

固有のニーズに合わせてモデルをカスタマイズする場合は、使用可能なアプローチについて検討する必要があります。 テナントごとに、個別の要件とユース ケースがある場合があります。 ほとんどのユース ケースで、微調整を使用しないこともあります。 グラウンディングなどの他のオプションについても調べてみてください。 時間を取ってこれらの要素を評価し、ニーズに最も適したアプローチを確実に選択してください。

マネージド ID

Microsoft Entra のマネージド ID を使って、Microsoft Entra ID によって認証された他のリソースから Azure OpenAI へのアクセスを提供します。 マネージド ID を使用する場合は、Azure OpenAI API キーを使用する必要はありません。 マネージド ID を使用すると、RBAC を使って Azure OpenAI の ID にきめ細かいアクセス許可を付与することもできます。

マネージド ID を使用する場合は、分離モデルを検討してください。 詳細については、マネージド ID を使用した Azure OpenAI に関する記事を参照してください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

  • Sofia Ferreira |ソフトウェア エンジニア、ISV および DN CoE

その他の共同作成者:

  • John Downs | プリンシパル プログラム マネージャー
  • Landon Pierce | カスタマー エンジニア、ISV および DN CoE
  • Paolo Salvatori | プリンシパル カスタマー エンジニア、ISV および DN CoE
  • Daniel Scott-Raynsford | パートナー テクノロジ ストラテジスト
  • Arsen Vladimirskiy | プリンシパル カスタマー エンジニア、ISV および DN CoE

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。