マルチテナント機能と Azure OpenAI Service
Azure OpenAI を使用すると、OpenAI の強力な言語モデルにアクセスできます。 この記事では、マルチテナント ソリューションに役立つ Azure OpenAI の主な機能について説明します。 推奨リソースを確認して、アプローチの計画と Azure OpenAI の使用に役立ててください。
分離モデル
Azure OpenAI サービスを使用するマルチテナント システムがある場合は、テナントに必要な分離レベルを決定する必要があります。 分離モデルは、次の要因に基づいて決定する必要があります。
- テナントはいくつある予定ですか?
- テナントには、ネットワークまたはインフラストラクチャの分離を必要とするコンプライアンス要件がありますか?
- テナントには、独自のデータで微調整されたモデルが必要ですか?
- テナントには、異なるモデル バージョンまたはモデル ライフサイクルが必要ですか?
次の表は、マルチテナント システムで Azure OpenAI サービスを使用する場合に使用できるデプロイ方法をまとめたものです。
| 説明 | 専用の Azure OpenAI サービス | 共有 Azure OpenAI サービス、テナントごとの専用モデル デプロイ | 共有 Azure OpenAI サービス、共有モデルのデプロイ | テナント提供の Azure OpenAI サービス |
|---|---|---|---|---|
| データの分離 | 高 | Medium | 低 | 高 |
| パフォーマンスの分離 | 高 | 高 | 低から中 (各テナントの 1 分あたりのトークン数 (TPM) による) | 高 |
| 配置の複雑性 | 低から中 (テナントの数による) | 中、デプロイ名とクォータを管理する必要があります。 | 低 | 適用されず、顧客によって管理されます。 |
| 操作の複雑さ | 低 | Medium | 高 | プロバイダーの場合は低、テナントの場合は高 |
| サンプル シナリオ | 他のテナントからのネットワーク分離を必要とするシングル テナントデプロイ。 | 特定のモデル ライフサイクルまたは微調整要件を持つテナント。 | 共有アプリケーション層を持つ大規模なマルチテナント ソリューション。 | 特定のコンプライアンスまたは微調整要件を持つテナント。 |
専用の Azure OpenAI サービス
サービス プロバイダーの場合は、Azure サブスクリプション内のテナントごとに Azure OpenAI インスタンスをデプロイすることを検討してください。 このアプローチでは、テナントごとにデータが分離されます。 テナントの数を増やすにつれて、Azure OpenAI リソースの数を増やしてデプロイおよび管理する必要があります。
このアプローチは、テナントごとに個別のアプリケーション デプロイがある場合、またはクォータや 1 分あたりの要求などの制限を回避する必要がある場合に使用します。 詳細については、 Azure OpenAI のクォータと制限に関する記事をご覧ください。
次の図は、プロバイダーのサブスクリプション内のテナントごとの Azure OpenAI モデルを示しています。
共有 Azure OpenAI サービス
複数のテナント間で Azure OpenAI のインスタンスを共有することもできます。 Azure OpenAI リソースは、(サービス プロバイダーの) Azure サブスクリプションにデプロイされます。 管理する責任はユーザーにあります。 このソリューションは実装が最も簡単ですが、提供されるデータ分離とパフォーマンスの分離は最小限です。
Azure OpenAI リソースを共有しても、各モデル デプロイのセキュリティ セグメント化は提供されません。 テナントは、使用が許可されていないモデルを使用できる場合があります。 このため、微調整されたモデルを使用する場合は、機密情報を公開し、テナント固有のデータまたはリソースへの未承認のアクセスを許可する可能性があるため、Azure OpenAI インスタンスの共有は避けてください。
複数のテナント間で Azure OpenAI のインスタンスを共有すると、 ノイズの多い近隣 の問題も発生する可能性があります。 これにより、一部のテナントで待機時間が長くなることがあります。 また、アプリケーション コードをマルチテナント対応にする必要もあります。 たとえば、共有 Azure OpenAI インスタンスの従量課金コストを顧客に請求する場合、アプリケーション内のテナントごとにトークンの合計数を追跡するロジックを実装します。
複数の共有 Azure OpenAI インスタンスをデプロイすることもできます。 たとえば、 デプロイ スタンプ パターンに従う場合、各スタンプ内に共有 Azure OpenAI インスタンスをデプロイします。 マルチリージョン ソリューションをデプロイする場合は、次の目的のために、各リージョンに Azure OpenAI をデプロイする必要があります。
- リージョン間トラフィックの待ち時間を回避する。
- データ所在地の要件をサポートする。
- 同じリージョン デプロイを必要とする他のサービス内でリージョン Azure OpenAI を使用できるようにする。
共有 Azure OpenAI インスタンスがある場合は、その 制限 を考慮して、 クォータを管理することが重要です。
次の図は、共有 Azure OpenAI モデルを示しています。
共有 Azure OpenAI サービスをデプロイする場合は、サービス内のモデル デプロイも共有するか、特定の顧客専用にするかを決定できます。
テナント間での共有モデルのデプロイ
テナント間でモデルデプロイを共有すると、管理するデプロイが少なく、追跡するモデルバージョンが少なくなるため、運用上の負担が軽減されます。可能であれば共有モデル デプロイの使用を計画し、提供する機能が必要な場合にのみ専用のモデル デプロイを作成します。
テナントごとの専用モデルのデプロイ
各テナント、または共有モデルデプロイを使用して満たされない特別な要件を持つテナントに対して、モデルデプロイを作成できます。 テナントの専用モデル デプロイを使用する一般的な理由は次のとおりです。
クォータとコスト管理: 各モデルで使用されるトークンの数を追跡することで、テナント固有の TPM の割り当てを容易にします。これにより、各テナントの使用状況を正確にコスト割り当ておよび管理できます。 プロビジョニング済みスループット ユニット (PTU) を使用する場合は、特定の顧客に PTU を割り当て、他の顧客に対して他の課金モデルを使用できます。
コンテンツ フィルタリング ポリシー: 特定のテナントで、許可されていない単語のテナント固有のブロックリストなど、一意のコンテンツ フィルタリング ポリシーが必要になる場合があります。 コンテンツ フィルター ポリシーは、モデルのデプロイのスコープで指定します。
モデルの種類とバージョン: テナントごとに異なるモデルまたはモデル バージョンを使用することが必要になる場合があります。 テナントには、独自のモデル ライフサイクル管理プロセスが必要になる場合もあります。
テナント固有の微調整: テナントごとに個別の微調整されたモデルを作成する場合は、微調整されたモデルごとに個別のモデル デプロイを作成する必要があります。
ほとんどのユース ケースでは、微調整は必要ありません。 通常は、 Azure OpenAI On Your Data または別の取得拡張生成 (RAG) アプローチを使用してモデルを接地することをお勧めします。
データ所在地: このアプローチでは、個別のデータ所在地要件がサポートされます。 たとえば、厳密なデータ所在地のニーズを持つテナントのリージョン モデルデプロイを提供し、厳密なニーズを必要とせずに他のテナントにグローバル モデルデプロイを使用できます。
各モデル デプロイには独自の URL がありますが、基になるモデルが他の Azure のお客様と共有されていることを覚えておくことをお勧めします。 また、共有 Azure インフラストラクチャも使用します。
Azure OpenAI では、各モデル デプロイに対してアクセス制御が適用されないため、アプリケーションは、どのテナントがどのモデル デプロイに到達できるかを制御する必要があります。
テナント提供の Azure OpenAI リソース
場合によっては、テナントが自分の Azure サブスクリプションに Azure OpenAI インスタンスを作成し、それに対するアクセス権をアプリケーションに付与することがあります。 この方法は、次の状況で適切な場合があります。
- テナントには、さまざまなモデルへのアクセス、特定のコンテンツ フィルター ポリシー、プロビジョニングされたスループットの使用など、Microsoft からの特定のクォータとアクセス許可があります。
- テナントには、ソリューションから使用する必要がある微調整されたモデルがあります。
- 顧客が管理する Azure OpenAI インスタンスを介してデータを処理および送信して処理するには、環境内のコンポーネントが必要です。
テナントのサブスクリプション内の Azure OpenAI インスタンスにアクセスするには、テナントがアクセス権をアプリケーションに提供する必要があります。 アプリケーションの認証は、Microsoft Entra インスタンスを介して行う要があります。 1 つのアプローチは、マルチテナント Microsoft Entra アプリケーションを発行することです。 次のワークフローで、この方法の手順の概要を示します。
- テナントが、マルチテナント Microsoft Entra アプリケーションを自分の Microsoft Entra テナントに登録します。
- テナントが、マルチテナント Microsoft Entra アプリケーションに、Azure OpenAI リソースへの適切なレベルのアクセス権を付与します。 たとえば、テナントは、ロールベースのアクセス制御 (RBAC) を使用して、"Azure AI サービス ユーザー" ロールにアプリケーションを割り当てることができます。
- テナントが、作成する Azure OpenAI リソースのリソース ID を提供します。
- アプリケーション コードで、独自の Microsoft Entra インスタンスのマルチテナント Microsoft Entra アプリケーションに関連付けられているサービス プリンシパルを使って、テナントの Azure OpenAI インスタンスにアクセスできます。
または、各テナントに、サービスで使用するサービス プリンシパルを作成し、その資格情報を提供するように求めることもできます。 このアプローチでは、潜在的なセキュリティ責任として、テナントごとに資格情報を安全に格納および管理する必要があります。
テナントが Azure OpenAI インスタンスに対するネットワーク アクセス制御を構成する場合、それらにアクセスできることを確認します。
次の図は、テナントのサブスクリプション内のテナントごとの Azure OpenAI モデルを示しています。
マルチテナントをサポートする Azure OpenAI サービスの機能
Assistants API
Assistants API は、AI アシスタントの作成に適した機能を Azure OpenAI サービスに追加します。 これには、ツールと API を呼び出す機能と、モデルが生成する回答を検出する検索ファイルが含まれます。 これにより、永続的な会話スレッドをサービスによって管理でき、サンドボックス環境内でコードを生成して実行できます。 これらの機能をサポートするには、Assistants API にデータを格納する必要があります。
マルチテナント ソリューションで Assistants API を使用する場合は、1 つのテナント専用のアシスタントを作成するか、複数のテナント間でアシスタントを共有するかを選択できます。 特に共有アシスタントの場合は、保存されているすべてのデータでテナントの分離を検討することが重要です。 たとえば、会話型スレッドがテナントごとに個別に格納されるようにする必要があります。
Assistants API は関数呼び出しをサポートしています。関数呼び出しには、呼び出す関数と含める引数に関するアプリケーション命令が送信されます。 ダウンストリーム システムへの呼び出しにテナント ID を含めるなど、行う関数呼び出しがマルチテナント対応であることを確認します。 アプリケーション内のテナント ID を確認し、言語モデルに依存してテナント ID を伝達しないでください。
独自のデータに基づく Azure OpenAI
Azure OpenAI On Your Data を使用すると、大規模な言語モデルは、言語モデルからの応答の生成の一環として、インデックスやデータベースなどのナレッジ ソースに直接クエリを実行できます。
要求を行うときは、クエリを実行するデータ ソースを指定できます。 マルチテナント ソリューションでは、データ ソースがマルチテナント対応であり、要求にテナント フィルターを指定できることを確認します。 テナント ID をデータ ソースに適切に伝達します。 たとえば、Azure AI Search に対してクエリを実行しているとします。 1 つのインデックスに複数のテナントのデータがある場合は、取得した結果を現在のテナントの ID に制限するフィルターを指定します。 または、テナントごとにインデックスを作成した場合は、現在のテナントに適切なインデックスを指定してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Sofia Ferreira |ソフトウェア エンジニア、ISV & DN CoE
その他の共同作成者:
- John Downs | プリンシパル ソフトウェア エンジニア
- Landon Pierce | カスタマー エンジニア、ISV & DN CoE
- Paolo Salvatori | プリンシパル カスタマー エンジニア、ISV & DN CoE
- ダニエル・スコット=レインズフォード |パートナー ソリューション アーキテクト
- Arsen Vladimirskiy | プリンシパル カスタマー エンジニア、ISV & DN CoE
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。