【Azure OpenAI Service リファレンスアーキテクチャ】

0 章はじめに Azure OpenAI リファレンスとは

改定履歴 2 版区分改定時期概要 1.0 新規 2023 年
6 月第 1 稿を作成 ※ サービス内容やリリース状況 (GA／Preview 等) は本書改定時点での最新情報を元とする為、参照時点によっては内容／状況に変更が発生している可能性がある。 2

リファレンスの利用方法 3 本書は、Azure OpenAI Serviceを使ったアプリケーションを開発にあたり、具体的なプラットフォーム/サービス設計の指針となるテンプレートとなることを目的としています。可能な限り「ベストプラクティス」としての実例をベースに提示しますが、ご利用いただく組織の体制や構築するシステム要件に応じてテー
ラリングすることを前提としております。 Microsoft Azure のサービス変更、パブリッククラウドを取り巻く環境の変化により「ベストプラクティス」も変化する事も前提としています。 3

リファレンス一覧 4 章カテゴリーガイドライン 0 はじめに 1. Azure Openリファレンスとは
1 コールセンター向けAIアシスタントシナリオ 1. シナリオ概要 2. アプリUI 3. アーキテクチャ 4. デプロイ方法 5. 考慮事項 2 料理メニューの提案シナリオ 1. シナリオ概要 2. アプリUI 3. アーキテクチャ 4. デプロイ方法 5. 考慮事項 3 目標達成アシスタントシナリオ 1. シナリオ概要 2. アプリUI 3. アーキテクチャ 4. デプロイ方法 5. 考慮事項章カテゴリーガイドライン 4 企業分析シナリオ 1. シナリオ概要 2. アプリUI 3. アーキテクチャ 4. デプロイ方法 5. 考慮事項 5 企業内向けChatと社内文書検索シナリオ 1. シナリオ概要 2. アプリUI 3. アーキテクチャ 4. デプロイ方法 5. 考慮事項 6 共通基盤ガイド 1. このガイドの位置づけ 2. 基盤の全体概要 3. ユーザーの認証認可 4. ログ取得 5. クォータ制限（利用制限） 6. デプロイ方法 7. 補足事項 8. 考慮事項 4

制限事項 5 以下の制限、制約をご理解の上、本書を活用ください。目的外利用の禁止本書は Microsoft Azure 上において、システムやソリューションの円滑かつ安全な構築に資することを目的に作成されています。この目的に反する利用はお断りいたします。フィードバック
本書の記載内容へのコメントやフィードバックをいただけます場合は、担当の日本マイクロソフト社員にご連絡ください。なお、個別質問への回答やフィードバックへの対応はお約束できないことを、ご了承いただけますようお願い申し上げます。公式情報の確認本書は日本マイクロソフトの有志のエンジニアによって、現場での経験を加えて執筆されたものです。そのため、この記載内容は Microsoft として公式に表明されたものではなく、日本マイクロソフトおよび米国 Microsoft Corporation は一切の責任を負いません。また、本書の記載内容について Azure サポートへお問い合わせいただいても、回答することはできません。 Microsoft Azure の公式情報については、Azure のドキュメントをご確認ください。免責本書の記載内容によって発生したいかなる損害についても、日本マイクロソフトおよび米国 Microsoft Corporation は一切の責任を負いません。 5

1 章コールセンター向け AI アシスタント

コンテンツ  シナリオ概要  アプリUI  アーキテクチャ  デプロイ方法 
考慮事項

シナリオ概要

コールセンター向け AI アシスタント AI エージェントが顧客との会話をリアルタイムで文字に起こし同時翻訳をします。対話の感情分析もリアルタイムに可視化します。会話が終了すると会話全体の内容を Azure Open AI サービスにより要約し、センチメントスコアやキーフレーズの抽出を行います。
以下のような状況で、役立つシステムを作成する事ができます  会話内容を指定した長さ、項目で要約し、主要キーワードやセンチメント情報を抽出する事が可能です。  会話の全体内容および AI により抽出した要約やセンチメント情報等をデーターベースへ保管し統計的な分析を可能とします。

デモUI

アーキテクチャ

On-premises Azure Web App Speech Service Language Service OpenAI Service
1 WEB アプリにアクセス 2 マイクからの音声を文字越し、翻訳 3 会話のフレーズ毎に感情分析 4 会話終了時に要約やキーフレーズを生成コンポーネントとデータフロー

デプロイ手順

サンプルのデプロイ方法ソースコードとデプロイ手順はGitHubに公開しています: https://github.com/Azure-Samples/jp-azureopenai-samples/tree/main/1.call-center

考慮事項

Azure Well-Architected Framework観点での考慮事項 (1) 信頼性(可用性) • Azureのサービスでは「可用性ゾーン」や「リージョン」といった単位で可用性を設計しており、これらを適切に組み合わせることで、ビジネスクリティカルなワークロードの信頼性を実現するように設計することが可能です。詳細は「Azure リージョンと可用性ゾーンとは」をご参照ください。
• このシナリオで用いられている Azure App Service はゾーン冗長、リージョン冗長、geoレプリケーションなど高可用性のオプションや構成を利用可能です。必要となる可用性に応じて導入を検討してください。複数リージョン間で Act-Act 構成を取る場合には Azure Front Door や Traffic Manager などの利用を推奨します。信頼性(回復性) • アプリケーションの正常性を監視するために、Application Insights を使用すると、カスタマーエクスペリエンスや可用性に影響を及ぼすパフォーマンスの問題についてアラートを生成し、対応することができます。詳細については、「Application Insights とは何か?」を参照してください。 • 回復性に関するその他の記事については、「信頼性の高い Azure アプリケーションを設計する」を参照してください。セキュリティ • セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。詳細については「セキュリティの重要な要素の概要」を参照してください。 • このシナリオでは、Managed ID を使用して特定の Azure App Service からのみアクセスを許可しています。 • セキュリティで保護されたソリューションの設計に関する一般的なガイダンスについては、「Azure のセキュリティのドキュメント」を参照してください。 • エンドユーザの認証認可について、社外ユーザはAzure AD B2C、社内ユーザはAzure ADのご利用をご検討ください。 Microsoft Azure Well-Architected Framework

Azure Well-Architected Framework観点での考慮事項 (2) コスト最適化 • 不要な費用を削減し、運用効率を向上させる方法を検討することです。詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。オペレーショナルエクセレンス •
システムの健全性の担保、トラブルの解決、利用動向の監視を行うためには適切な監視とログ収集が必要となります。詳細は「ワークロードの監視」をご参照ください。API Managementを利用することで、API利用の監視やトレースを行うことが容易になります。 • ソフトウェアのアップデートや脆弱性への対応など、ソフトウェア/インフラ設計の改修を円滑に進められるよう、DevOpsプロセスを確立してください。詳細は「リリースエンジニアリングの継続的インテグレーション」をご参照ください。パフォーマンス効率 • アプリケーションの負荷が高まることを見越し、スケーラビリティの確保をあらかじめ検討することは重要です。詳細は「スケーリング用のアプリケーションを設計する」をご参照ください • App Serviceは負荷に応じて水平にスケールさせることが可能です。詳細については「自動スケーリングを有効にする方法」をご参照ください。 • 頻出のクエリについてはアプリ側でキャッシュする等のキャッシュ戦略もご検討ください。詳細は「キャッシュを使用する」をご参照ください。 • 特定のユーザーにAzure OpenAIの利用が集中することを避けたい場合には API Management によるスロットリング導入などをご検討ください。詳細は「Azure API Management を使用した高度な要求スロットル」をご参照ください。

プロンプト制限について本デモはレスポンス良く機能を可視化する目的で、Azure OpenAI 呼び出しの会話内容を3600トークン程度に制限しています。このため会話内容が長くなると Azure OpenAI 呼び出しが制限に引っ掛かります。トークン制限が緩和されている最新の GPT
モデルなどに置き換えることで、より長い会話の要約や分析が可能と考えます。なお異なるモデルを利用する場合、app.py 内の正規表現による Q1 ～ Q4 の抽出処理を変更する必要があります。長い会話内容を要約する場合、Azure OpenAI からの応答に時間を要します。そのような場合、非同期的なバッチ処理として要約情報をデーターベースなどに収集し、あとから検索や分析情報として利用する方式が適切となる場合もあります。

2章料理メニュー提案

考慮事項

シナリオ概要

料理メニュー提案 Azure OpenAI Serviceを活用し、家族構成や自宅にある食材から料理メニューを提案できるアプリケーションを作成できます。また、店舗の在庫状況と紐づけることで、食材を購入できるエリア、割引情報などを基に購買を促進することができます。以下のような状況で、役に立つアプリケーションを作成することができます  食材提案に基づく、スーパーマーケットと連携した販売促進
 割引やポイントを最適化した購買を可能にし、ユーザの家計を補助  栄養バランスを考慮した料理メニューの提案料理メニュー提案

デモUI

デモ動画

1 家族のプロフィール等を送信 2 OpenAI ServiceをTokenで認証 4 生成した文章・画像をレスポンス 3 文章・画像生成のプロンプトを送信 5
提案メニュー・料理画像を表示 Azure App Service Azure OpenAI Service 文章生成モデル (text-davinci-003) 画像生成モデル (DALL-E) Webブラウザコンポーネントとデータフロー

デプロイ方法

サンプルのデプロイ方法ソースコードとデプロイ手順はGitHubに公開しています: https://github.com/Azure-Samples/jp-azureopenai-samples/tree/main/2.recipe-adviser

考慮事項

• このシナリオで用いられているApp Service、Azure OpenAI等のコンポーネントはそれぞれゾーン冗長、リージョン冗長、geoレプリケーションなど高可用性のオプションや構成を利用可能です。必要となる可用性に応じて導入を検討してください。複数リージョン間/複数ゾーン間でAct-Act 構成を取る場合にはAzure Front Door、Azure Application Gatewayなどの利用をご推奨します。信頼性(回復性) • アプリケーションの正常性を監視するために、Application Insights を使用すると、カスタマーエクスペリエンスや可用性に影響を及ぼすパフォーマンスの問題についてアラートを生成し、対応することができます。詳細については、「Application Insights とは何か?」を参照してください。 • 回復性に関するその他の記事については、「信頼性の高い Azure アプリケーションを設計する」を参照してください。セキュリティ • セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。詳細については、「セキュリティの重要な要素の概要」を参照してください。セキュリティで保護されたソリューションの設計に関する一般的なガイダンスについては、「Azure のセキュリティのドキュメント」を参照してください。 • 本シナリオはB2Cシナリオであるため、Azure AD B2Cによるエンドユーザの認証認可をご検討ください。 Microsoft Azure Well-Architected Framework

システムの健全性の担保、トラブルの解決、利用動向の監視を行うためには適切な監視とログ収集が必要となります。詳細は「ワークロードの監視」をご参照ください。API Managementを利用することで、API利用の監視やトレースを行うことが容易になります。 • ソフトウェアのアップデートや脆弱性への対応などソフトウェア/インフラ設計の改修を円滑で安全に進められるよう、DevOpsプロセスの確立について「リリースエンジニアリングの継続的インテグレーション」をご参照くださいパフォーマンス効率 • アプリケーションの負荷が高まることを見越し、スケーラビリティの確保をあらかじめ検討することは重要です。詳細は「スケーリング用のアプリケーションを設計する」をご参照ください • App Serviceは負荷に応じて水平にスケールさせることが可能です。詳細については「自動スケーリングを有効にする方法」をご参照ください。 • 頻出のクエリについてはアプリ側でキャッシュする等のキャッシュ戦略もご検討ください。詳細は「キャッシュを使用する」をご参照ください。 • 特定のユーザーにAzure OpenAIの利用が集中することを避けたい場合にはAPI Managementによるスロットリング導入などをご検討ください。詳細は「Azure API Management を使用した高度な要求スロットル」をご参照ください。

3章目標達成アシスタント

考慮事項

シナリオ概要

目標達成アシスタント Azure OpenAIを活用すると、アドバイザー/メンターのように、目標達成までの道筋をガイドするようなアプリケーションを作成することができます。また、目標達成のプランニングに必要な情報を収集し、体系的な形でまとめてくれるアプリケーションを作成することができます。以下のような状況で、役に立つアプリケーションを作成することができます  商品企画 
パーソナルトレーニング  キャリアプランニング

デモUI（商品企画書の作成支援）

デモ動画

デモUI（パーソナルトレーニング）

デモUI（キャリアアドバイザー）

コンポーネントとデータフローナレッジデータ (テキスト) Redis Enterprise RediSearch ナレッジベース Embedding コントソ社 Embedding
市場動向 Embedding IT 用語 … Azure App Services Web Browser Python Console (PCで実行) 1 GPT に渡すための付加情報を収集/登録シナリオによってデータソースの種別や取得方法が異なるため、システム構築の検討は必要・Cognitive Service (Speech / Form Recognizer) ・ Synapse Analytics / Databricks ・AKS / Container Apps ・Azure Open AI (文章要約/加工方法の判断など) 2 ナレッジデータから GPT Embedding(ベクトル)を生成 3 Embeddingとナレッジデータを Redis Cache に登録達成したい目標を入力 3 4 設定目標から GPT Embedding (ベクトル)を取得設定目標 Embeddingから関連ナレッジを検索 (コサイン類似度) 5 6 OpenAI とのチャット/文章生成目標達成に曖昧な部分を AI から利用者に質問するデータソース - DBMS - PDF - HTML - etc… ナレッジベースの準備 Azure OpenAI とナレッジベースによるアプリケーション Azure Open AI Service GPT-4-32k for chat text-embedding-ada-002 for embedding Azure Active Directory 1 URLを開く 2 認証

デプロイ方法

サンプルのデプロイ方法ソースコードとデプロイ手順はGitHubに公開しています: https://github.com/Azure-Samples/jp-azureopenai-samples/tree/main/3.goal-achievement-adviser

考慮事項

Azure Well-Architected Framework観点での考慮事項 (1) 信頼性(可用性) • Azureのサービスでは「可用性ゾーン」や「リージョン」といった単位で可用性を設計しており、これらを適切に組み合わせることで、ビジネスクリティカルなワークロードの信頼性を実現するように設計することが可能です。詳細は「Azure
リージョンと可用性ゾーンとは」をご参照ください。 • このシナリオで用いられているApp Service、Azure OpenAI、Azure Cache for Redis (Enterprise) 等のコンポーネントはそれぞれゾーン冗長、リージョン冗長、geoレプリケーションなど高可用性のオプションや構成を利用可能です。必要となる可用性に応じて導入を検討してください。複数リージョン間/複数ゾーン間でAct-Act構成を取る場合にはAzure Front Door、Azure Application Gatewayなどの利用をご推奨します。信頼性(回復性) • アプリケーションの正常性を監視するために、Application Insights を使用すると、カスタマーエクスペリエンスや可用性に影響を及ぼすパフォーマンスの問題についてアラートを生成し、対応することができます。詳細については、「Application Insights とは何か?」を参照してください。 • 回復性に関するその他の記事については、「信頼性の高い Azure アプリケーションを設計する」を参照してください。セキュリティ • セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。詳細については、「セキュリティの重要な要素の概要」を参照してください。 • セキュリティで保護されたソリューションの設計に関する一般的なガイダンスについては、「Azure のセキュリティのドキュメント」を参照してください。 • エンドユーザの認証認可について、社外ユーザはAzure AD B2C、社内ユーザはAzure ADのご利用をご検討ください。 Microsoft Azure Well-Architected Framework

システムの健全性の担保、トラブルの解決、利用動向の監視を行うためには適切な監視とログ収集が必要となります。詳細は「ワークロードの監視」をご参照ください。API Managementを利用することで、API利用の監視やトレースを行うことが容易になります。 • ソフトウェアのアップデートや脆弱性への対応など、ソフトウェア/インフラ設計の改修を円滑に進められるよう、DevOpsプロセスを確立してください。詳細は「リリースエンジニアリングの継続的インテグレーション」をご参照ください。パフォーマンス効率 • アプリケーションの負荷が高まることを見越し、スケーラビリティの確保をあらかじめ検討することは重要です。詳細は「スケーリング用のアプリケーションを設計する」をご参照ください • App Serviceは負荷に応じて水平にスケールさせることが可能です。詳細については「自動スケーリングを有効にする方法」をご参照ください。 • Enterpriseレベル以上のRedis Cache for Azure（Search機能のご利用に必要）は優れたパフォーマンスを発揮しますが、さらなる性能を必要とする場合にはRedis Cacheインスタンスを増やし負荷分散することも可能です。また、頻出のクエリについてはアプリ側でキャッシュする等のキャッシュ戦略もご検討ください。詳細は「キャッシュを使用する」をご参照ください。 • 特定のユーザーにAzure OpenAIの利用が集中することを避けたい場合には API Management によるスロットリング導入などをご検討ください。詳細は「Azure API Management を使用した高度な要求スロットル」をご参照ください。

4章企業分析

考慮事項

シナリオ概要

企業分析シナリオ概要法人営業が初回訪問する企業の基本情報や各種インサイトを提供することで、円滑な商談をサポートします。現在の Azure Open AI のモデルは 2021年9月以降の知識は持っていませんが、Azure に構築したナレッジベースに登録した企業情報を参照することで、最新情報を理解した自然な文章や適切なインサイトを生成します。
本アプリーケーションは以下の UI を提供します。・チャット: 企業の基本情報 (資本金, 直近3年の財務情報など) を検索して、チャットUIを通じて会話のコンテキストを理解した最新情報を提供します。参照元データソースから情報の正当性を検証できます。・レポート: 企業の分析情報 (事業内容, 財務情報など)をレポート形式で提供します。一部項目はフィードバックを送信することで文章を再生成できます。情報の取得先は、例えば以下の3つが考えられます１．会社名などの一般的なスタティック情報２．仕掛中案件など社内CRM等の情報３．GPTに聞く情報

デモUI

デモUI (チャット)

企業情報 (JSON) Redis Enterprise RediSearch 企業情報はAzure Cosmos DB のようなストアに配置することも有効です
ナレッジベース Embedding 企業情報 Embedding 企業情報 Embedding 企業情報 … Azure App Services Web Browser Python Console (PCで実行) Azure Active Directory 1 データソースから企業分析に必要な情報を収集。企業によってデータソースの種別や取得方法が異なるため、システム構築の検討は必要・Cognitive Service (Speech / Form Recognizer) ・ Synapse Analytics / Databricks ・AKS / Container Apps ・Open AI (文章要約/加工方法の判断など) 2 企業情報から GPT Embedding(ベクトル)を生成 3 Embeddingと企業情報を Redis Cache に登録 1 URLを開く企業名を検索 3 4 企業名から GPT Embedding (ベクトル)を取得企業名の Embeddingから企業情報を検索 5 2 認証 8 OpenAI とのチャット/文章生成 OpenAI に送信するプロンプトには、ナレッジベースから取得した企業情報を含める (それにより Open AI は企業の最新情報を認識した回答を作成) データソース - DBMS - PDF - HTML - etc… Azure Open AI Service gpt-35-turbo for chat text-embedding-ada-002 for embedding 7 チャット入力から関連情報を検索 (コサイン類似度) 6 チャット入力 (事前準備) ナレッジベースの構築企業分析 Web アプリケーションコンポーネントとデータフロー

デプロイ方法

サンプルのデプロイ方法ソースコードとデプロイ手順はGitHubに公開しています: https://github.com/Azure-Samples/jp-azureopenai-samples/tree/main/4.company-research

考慮事項

リージョンと可用性ゾーンとは」をご参照ください。 • このシナリオで用いられているApp Service、Azure OpenAI、Azure Cache for Redis (Enterprise) 等のコンポーネントはそれぞれゾーン冗長、リージョン冗長、geoレプリケーションなど高可用性のオプションや構成を利用可能です。必要となる可用性に応じて導入を検討してください。複数リージョン間/複数ゾーン間でAct-Act構成を取る場合にはAzure Front Door、Azure Application Gatewayなどの利用をご推奨します。信頼性(回復性) • アプリケーションの正常性を監視するために、Application Insights を使用すると、カスタマーエクスペリエンスや可用性に影響を及ぼすパフォーマンスの問題についてアラートを生成し、対応することができます。詳細については、「Application Insights とは何か?」を参照してください。 • 回復性に関するその他の記事については、「信頼性の高い Azure アプリケーションを設計する」を参照してください。セキュリティ • セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。詳細については、「セキュリティの重要な要素の概要」を参照してください。 • セキュリティで保護されたソリューションの設計に関する一般的なガイダンスについては、「Azure のセキュリティのドキュメント」を参照してください。 • エンドユーザの認証認可について、社外ユーザはAzure AD B2C、社内ユーザはAzure ADのご利用をご検討ください。 Microsoft Azure Well-Architected Framework

システムの健全性の担保、トラブルの解決、利用動向の監視を行うためには適切な監視とログ収集が必要となります。詳細は「ワークロードの監視」をご参照ください。API Managementを利用することで、API利用の監視やトレースを行うことが容易になります。 • ソフトウェアのアップデートや脆弱性への対応など、ソフトウェア/インフラ設計の改修を円滑に進められるよう、DevOpsプロセスを確立してください。詳細は「リリースエンジニアリングの継続的インテグレーション」をご参照ください。パフォーマンス効率 • アプリケーションの負荷が高まることを見越し、スケーラビリティの確保をあらかじめ検討することは重要です。詳細は「スケーリング用のアプリケーションを設計する」をご参照ください • App Serviceは負荷に応じて水平にスケールさせることが可能です。詳細については「自動スケーリングを有効にする方法」をご参照ください。 • Enterpriseレベル以上のRedis Cache for Azure（Search機能のご利用に必要）は優れたパフォーマンスを発揮しますが、さらなる性能を必要とする場合にはRedis Cacheインスタンスを増やし負荷分散することも可能です。また、頻出のクエリについてはアプリ側でキャッシュする等のキャッシュ戦略もご検討ください。詳細は「キャッシュを使用する」をご参照ください。 • 特定のユーザーにAzure OpenAIの利用が集中することを避けたい場合には API Management によるスロットリング導入などをご検討ください。詳細は「Azure API Management を使用した高度な要求スロットル」をご参照ください。

5章企業内向けChatと社内文書検索

考慮事項

シナリオ概要

企業内向けChatと社内文書検索 Azure OpenAI Serviceを利用して、ChatGPTのような生成AIを利用した企業社内向けチャットを作成することができます。パブリックな環境で提供されているChatGPTとは異なり、プロンプト・エンジニアリングによるプロンプトの調整や、閉域網での提供が可能になります。また、Azure Cognitive Searchを組み合わせることで、特定の社内文書などを検索し、生成
AIで返答を行うアプリケーションを作成することができます。このようなアプリケーションにより、企業内の情報検索を会話ベースで行うことが容易になります。

デモUI

デモUI – 企業内向けChat ChatGPTライクなシンプルな会話インターフェースです。

デモUI – 社内文書検索会話ベースでAIが社内文書を検索して、文書を提示します。

コンポーネントとデータフロー Blob Storage 参照用文書 Azure App Services Web Browser Azure
Active Directory 1 データソースとなるPDFを分割し、 Blob Storageにアップロード 2 分割したPDFからCognitive Searchのインデックスを作成 1 URLを開く問い合わせ 3 4 問い合わせからCognitive Search の検索クエリを生成（Davinciモデルを使用） 5 2 認証 7 Azure OpenAI で回答生成（GPT-35-Turboモデルを使用） PDF 文書検索の準備 Azure OpenAI とナレッジベースによるアプリケーション Azure OpenAI Service Davinci/GPT-35-Turbo/(GPT-4) pdf Azure Cognitive Search Index (gptkbindex) Cognitive Searchで文書を検索 7 必要に応じて引用元文書をプレビュー/ダウンロード 6 プロンプトをCosmos DBに保存 Azure Cosmos DB

デプロイ方法

サンプルのデプロイ方法ソースコードとデプロイ手順はGitHubに公開しています: https://github.com/Azure-Samples/jp-azureopenai-samples/tree/main/5.internal-document-search

考慮事項

リージョンと可用性ゾーンとは」をご参照ください。 • このシナリオで用いられているAzure App Service、Azure OpenAI、Azure Cognitive Search, Azure Cosmos DB 等のコンポーネントはそれぞれゾーン冗長、リージョン冗長、geoレプリケーションなど高可用性のオプションや構成を利用可能です。必要となる可用性に応じて導入を検討してください。複数リージョン間/複数ゾーン間でAct-Act構成を取る場合にはAzure Front Door、Azure Application Gatewayなどの利用をご推奨します。信頼性(回復性) • アプリケーションの正常性を監視するために、Application Insights を使用すると、カスタマーエクスペリエンスや可用性に影響を及ぼすパフォーマンスの問題についてアラートを生成し、対応することができます。詳細については、「Application Insights とは何か?」を参照してください。 • 回復性に関するその他の記事については、「信頼性の高い Azure アプリケーションを設計する」を参照してください。セキュリティ • セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。詳細については、「セキュリティの重要な要素の概要」を参照してください。 • セキュリティで保護されたソリューションの設計に関する一般的なガイダンスについては、「Azure のセキュリティのドキュメント」を参照してください。 • 本シナリオは企業内ユーザを前提としているので、認証認可にはAzure ADのご利用をご検討ください。Azure App ServiceのEasy Auth機能を使用したAzure ADを使用してユーザーを認証することができます。 Microsoft Azure Well-Architected Framework

システムの健全性の担保、トラブルの解決、利用動向の監視を行うためには適切な監視とログ収集が必要となります。詳細は「ワークロードの監視」をご参照ください。API Managementを利用することで、API利用の監視やトレースを行うことが容易になります。 • ソフトウェアのアップデートや脆弱性への対応など、ソフトウェア/インフラ設計の改修を円滑に進められるよう、DevOpsプロセスを確立してください。詳細は「リリースエンジニアリングの継続的インテグレーション」をご参照ください。パフォーマンス効率 • アプリケーションの負荷が高まることを見越し、スケーラビリティの確保をあらかじめ検討することは重要です。詳細は「スケーリング用のアプリケーションを設計する」をご参照ください • Azure App Serviceは負荷に応じて水平にスケールさせることが可能です。詳細については「自動スケーリングを有効にする方法」をご参照ください。 • 頻出のクエリについてはアプリ側でキャッシュする等のキャッシュ戦略もご検討ください。詳細は「キャッシュを使用する」をご参照ください。 • また、特定のユーザーにAzure OpenAIの利用が集中することを避けたい場合にはAPI Managementによるスロットリング導入などをご検討ください。詳細は「Azure API Management を使用した高度な要求スロットル」をご参照ください。

6章共通基盤ガイド認証/ロギング/クォータ制限

コンテンツ  このガイドの位置づけ  基盤の全体概要  ユーザーの認証認可  ログ取得 
クォータ制限（利用制限）  デプロイ方法  補足情報  考慮事項

このガイドの位置づけ

このガイドの位置づけ第1章~第5章では用途に応じたアーキテクチャ/アプリケーションの構成例を示しました。第6章では、どのシナリオでも利用可能なAzure OpenAI利用基盤のアーキテクチャを取り上げます。この共通基盤を用いることにより  アプリケーション利用時の認証/認可  リクエスト/レスポンスBodyを含めたログの取得
 ユーザー毎、IP毎など柔軟な単位での利用量制限（クォータ制限）などが可能となり、適正な利用の担保や監査を行うことが容易になります。なお、本ドキュメントに対応するテンプレートは以下のリポジトリで公開されています。 https://github.com/Azure-Samples/jp-azureopenai-samples/tree/main/6.azureopenai-landing-zone-accelerator

基盤の全体概要

本章ご説明するアーキテクチャのサンプルは以下のようにAPIクライアントとなるアプリでAzure AD認証を行いAzure OpenAI APIリクエストを発行するというものになります（アプリ部分は任意のアプリを想定）リポジトリ: https://github.com/Azure-Samples/jp-azureopenai-samples/tree/main/6.azureopenai-landing-zone-accelerator API Client Azure Active
Directory (B2C) 2 アプリ画面を返却 & 認証を要求 5 6 7 Azure OpenAI Service Azure API Management or Azure App Service 1 URLを開く Registered App 3 認証& アプリによるAppの使用許可 4 JWTを返却 OpenAI APIリクエスト (w/ JWT) ①OAuth 2.0 JWTに基づく権限確認 ②ユーザー識別子のログ出力 ③リクエスト/レスポンスBodyのログ出力 ④ユーザー毎のAPI利用回数制限 API Management ポリシー処理 OpenAI APIリクエスト (w/ OpenAIキー) ログ出力 Azure Static Apps or Browser

ユーザーの認証認可

Azure AD (もしくはAzure AD B2C) での認証を行います。あらかじめAzure上にAzure OpenAIのAPI利用を表すアプリとスコープの登録を行い、アプリが認証要求を出す際にはそのスコープを指定して認証を要求します。取得したJWT (JSON
Web Token)をリクエストヘッダに付与し、API Managementにリクエストを行います API Client Azure Active Directory (B2C) 2 アプリ画面を返却 & 認証を要求 5 6 7 Azure OpenAI Service Azure API Management or Azure App Service 1 URLを開く Registered App 3 認証& アプリによるAppの使用許可 4 JWTを返却 OpenAI APIリクエスト (w/ JWT) ①OAuth 2.0 JWTに基づく権限確認 ②ユーザー識別子のログ出力 ③リクエスト/レスポンスBodyのログ出力 ④ユーザー毎のAPI利用回数制限 API Management ポリシー処理 OpenAI APIリクエスト (w/ OpenAIキー) ログ出力 Azure Static Apps or Browser

ログ取得

API Managementはすべてのリクエストとレスポンスの内容を保存することが可能です。リファレンス実装ではLog Analytics（分析用）とストレージ（長期保存・蓄積用）の両方に出力を行っています API Client Azure Active Directory (B2C)
2 アプリ画面を返却 & 認証を要求 5 6 7 Azure OpenAI Service Azure API Management or Azure App Service 1 URLを開く Registered App 3 認証& アプリによるAppの使用許可 4 JWTを返却 OpenAI APIリクエスト (w/ JWT) ①OAuth 2.0 JWTに基づく権限確認 ②ユーザー識別子のログ出力 ③リクエスト/レスポンスBodyのログ出力 ④ユーザー毎のAPI利用回数制限 API Management ポリシー処理 OpenAI APIリクエスト (w/ OpenAIキー) ログ出力 Azure Static Apps or Browser

クォータ制限（利用制限）

同様にAPI Managementでクォータ制限を実施します。リファレンス実装ではユーザー毎（ユーザ識別子毎）に一日あたりの利用回数を制限していますが、設定を変更することでIPやアプリなど様々な対象毎に任意の期間に利用できるAPI回数・帯域幅を設定することができます API Client Azure Active Directory (B2C)
2 アプリ画面を返却 & 認証を要求 5 6 7 Azure OpenAI Service Azure API Management or Azure App Service 1 URLを開く Registered App 3 認証& アプリによるAppの使用許可 4 JWTを返却 OpenAI APIリクエスト (w/ JWT) ①OAuth 2.0 JWTに基づく権限確認 ②ユーザー識別子のログ出力 ③リクエスト/レスポンスBodyのログ出力 ④ユーザー毎のAPI利用回数制限 API Management ポリシー処理 OpenAI APIリクエスト (w/ OpenAIキー) ログ出力 Azure Static Apps or Browser

デプロイ方法

テンプレートデプロイされる範囲本プロジェクトでは以下の範囲を自動構築するテンプレートを提供します。Azure ADはテンプレートで設定を行えないため、以降の手順ページに則ってください。またアプリについては各シナリオに準じたものを用いてください。アプリはAzure ADからOAuth JWTを取得し、Authorizationヘッダに付与してリクエストを行ってください API Client Azure Active
Directory (B2C) 2 アプリ画面を返却 & 認証を要求 5 6 7 Azure OpenAI Service Azure API Management or Azure App Service 1 URLを開く Registered App 3 認証& アプリによるAppの使用許可 4 JWTを返却 OpenAI APIリクエスト (w/ JWT) ①OAuth 2.0 JWTに基づく権限確認 ②ユーザー識別子のログ出力 ③リクエスト/レスポンスBodyのログ出力 ④ユーザー毎のAPI利用回数制限 API Management ポリシー処理 OpenAI APIリクエスト (w/ OpenAIキー) ログ出力 Azure Static Apps or Browser 手動構築する範囲

1. Azure ADへのアプリ登録 API Management上のAPIと対応するアプリをAzure AD上で登録アプリとして登録します  [Azure AD]アプリの登録からアプリを追加します
(リダイレクトURIにはアプリの認証エンドポイントを指定)

2. 公開APIの設定前ページで登録したアプリに対して、OAuth 2.0でユーザーが許可するスコープを設定します  [Azure AD]アプリの登録 > APIの公開 (Expose
an API)からスコープの追加を行いますこれはTwitterを例にするとサードパーティアプリに「ツイートを許可する」「フォロワーの参照を許可する」などの許可範囲にあたりますこのスコープをのちに使うので記録します

3. パラメータの設定 https://github.com/Azure-Samples/jp-azureopenai-samples/tree/main/6.azureopenai-landing-zone-accelerator を取得し、 infra/main.parameters.jsonファイルに以下のようにパラメータを設定しますパラメータ名投入する値値の例 environmentName デプロイ時に指定するため編集不要です
- location デプロイ時に指定するため編集不要です - corsOriginUrl 認証を行うシングルページアプリ（SPA）のドメインを指定します。シングルページアプリケーションのドメインが確定していない場合、デフォルトの"*"を指定することも可能ですが、確定次第具体的なドメインを指定することをおすすめします *, example.com, yourapp.azurewebsites.net など audienceAppId JWTを取得する対象となる登録アプリの登録アプリID 登録アプリID(UUID) scopeName スコープ名 chat tenantId 認証対象となるAzure ADのテナントID Azure ADのテナントID (UUID)

4. azdログインとテンプレートデプロイ以下のコマンドを実行し、Azure Developer CLIでのログインAzure ADテンプレートデプロイを行います $ azd auth login
・ログイン $ azd auth login --use-device-code ブラウザのない環境では $ azd auth login --tenant-id テナントを明示的に指定したい場合には $ azd up ・デプロイの実行

第1 ~ 5章との連携方法第1~5章のアプリを本章の基盤と接続するためには第1~5章のアプリをデプロイしたのちに第6章をデプロイし、その後に第1~5章のアプリに以下のような変更を行ってください # 変更ポイント変更の目的実現される機能 1
エンドポイントをAzure OpenAIからAPI Managementに変更する Azure OpenAIへのAPIリクエストをAPI Managementを経由させるようにする・ログの取得・複数AOAI間のラウンドロビン・利用制限（IP毎） 2 リクエストヘッダにAPI Managementのサブスクリプションキーを付与する API Managementを利用するアプリを識別する・アプリごとの利用量分計・利用制限（アプリ毎） 3 リクエストヘッダにOAuth 2.0 JWTを付与する API Managementを利用するユーザーを識別する・ユーザの認証認可の必須化・利用制限（ユーザー毎）・ログの取得（ユーザーをログ出力）

補足情報

Azure OpenAIの特定リージョンのクォータを回避するためにAPI Managementで複数のAzure OpenAI間でリクエストのラウンドロビン冗長化を行うことが可能です。設定の詳細についてはサンプルレポジトリのREADMEをご参照ください API Managementを用いたロードバランシング Azure OpenAI Service
Azure API Management ログ出力ラウンドロビン Azure OpenAI Service （別アカウント or 別リージョン）リクエストをランダムに振り分け（パーシステントは不可） API Client or

社内へのAPI公開 99 社内にAzure OpenAIのAPIを公開し、「APIの利用権利」をAPI Managementのサブスクリプションとして払い出す運用が可能ですこれにより、単一のAzure OpenAIアカウントを複数のアプリから安全に利用し、利用量を管理することが可能です Azure OpenAI Service
Azure API Management 〇〇部アプリC ログ出力 △△部アプリB □□部アプリA ・サブスクリプションキー毎（≒アプリ毎）のAPIコール数やToken数をログに出力し集計・サブスクリプション毎にAPIコール数をクォータ制限 API Managementではサブスクリプションキーに対して利用できるAPIやバージョンを制御することも可能です

本テンプレートのデフォルトでは①のようにVNetを用いない構成となっていますが、②のようにPrivate Linkを用いてAPI ManagementからAzure OpenAIへのアクセスをプライベート化することも可能です。また、③④のようにAPI ManagementをVNetに統合することも可能ですが、Premium SKUの API Managementが必要となりますネットワーク構成のプライベート化 Azure
API Management Azure OpenAI Service API Client Azure API Management Azure OpenAI Service API Client ①VNetを用いない構成 ②Private Linkを用いてバックエンドアクセスをプライベート化する構成 VNet Public IP Azure API Management Azure OpenAI Service Browser ③API Managementを含めプライベート化 Public IP Azure API Management Azure OpenAI Service Browser ④ユーザ環境含めたプライベート化 optional optional or or

考慮事項

• このシナリオで用いられているAPI Management、Azure OpenAI 、ストレージアカウント等のコンポーネントはそれぞれゾーン冗長やリージョン冗長、geoレプリケーションなど高可用性のオプションや構成を利用可能です。必要となる可用性に応じて導入を検討してください。複数リージョン間/複数ゾーン間でAct-Act構成を取る場合にはAzure Front Door、Azure Application Gatewayなどの利用をご推奨します。信頼性(回復性) • アプリケーションの正常性を監視するために、このシナリオでは Log Analytics を使用します。 Log Analytics を使用すると、異常時のログを迅速に分析し対応することができます。 • 回復性に関するその他の記事については、「信頼性の高い Azure アプリケーションを設計する」を参照してください。セキュリティ • セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。詳細については、「セキュリティの重要な要素の概要」を参照してください。 • このシナリオでは、Azure AD B2CまたはAzure ADを使用してユーザーを認証します。 • セキュリティで保護されたソリューションの設計に関する一般的なガイダンスについては、「Azure のセキュリティのドキュメント」を参照してください。 Microsoft Azure Well-Architected Framework

Azure Well-Architected Framework観点での考慮事項 (2) コスト最適化 • 不要な費用を削減し、運用効率を向上させる方法をご検討ください。詳しくは、「コスト最適化の柱の概要」に関する記事をご覧ください。オペレーショナルエクセレンス •
システムの健全性の担保、トラブルの解決、利用動向の監視を行うためには適切な監視とログ収集が必要となります。詳細は「ワークロードの監視」をご参照ください。本構成を用いることによりAPIの適切な利用を担保することが可能となります。 • ソフトウェアのアップデートや脆弱性への対応など、ソフトウェア/インフラ設計の改修を円滑に進められるよう、DevOpsプロセスを確立してください。詳細は「リリースエンジニアリングの継続的インテグレーション」をご参照ください。パフォーマンス効率 • API Managementを用いて複数のAzure OpenAI間でロードバランシングすることが可能です。Azure OpenAIのモデル毎Quotaを上限まで引き上げても処理量が足りない場合にご検討ください • アプリケーションの負荷が高まることを見越し、スケーラビリティの確保をあらかじめ検討することは重要です。詳細は「スケーリング用のアプリケーションを設計する」をご参照ください • 特定のユーザーにAzure OpenAIの利用が集中することを避けたい場合には API Management によるクォータ導入などをご検討ください。本構成にはクォータ制限の設定が含まれています。クォータ制限の設定変更方法についてはサンプルレポジトリのREADMEをご参照ください。設定の詳細は「Azure API Management を使用した高度な要求スロットル」をご参照ください。

© Copyright Microsoft Corporation. All rights reserved. 本資料は情報提供のみを目的としており、本資料に記載されている情報は、本資料作成時点でのマイクロソフトの見解を示したものです。状況等の変化により、内容は変更される場合があります。本資料の記載内容（提示されている条件等を含みます）は、弊社での社内承認、および/またはお客様との有効な契約を経たうえで最終的に確定されます。それまでは、正式に発効するものではありません。また、本資料に記載されている価格はいずれも、別段の表記がない限り、参考価格となります。お客様の最終的な購入価格は、お客様のリセラー
様により決定されます。マイクロソフトは、本資料の情報に対して明示的、黙示的または法的な、いかなる保証も行いません。 © 2023 Microsoft Corporation. All rights reserved.

【Azure OpenAI Service リファレンスアーキテクチャ】

【Azure OpenAI Service リファレンスアーキテクチャ】

More Decks by Daiki Kanemitsu

Other Decks in Technology

Featured

Transcript