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

PPTは下記よりダウンロード（デモ動画付き）
https://www.microsoft.com/ja-jp/events/azurebase/contents/
【Azure OpenAI Service リファレンスアーキテクチャ】
Azure OpenAI Service (AOAI) リファレンスアーキテクチャとは、マイクロソフトが推奨するAOAIを使ったアプリケーション開発のシナリオ例とそのアーキテクチャイメージを詳しく記述したドキュメント群です。

Transcript

1. 0 章 はじめに Azure OpenAI リファレンスとは
2. 改定履歴 2 版 区分 改定時期 概要 1.0 新規 2023 年 6 月 第 1 稿を作成 ※ サービス内容やリリース状況 (GA／Preview 等) は本書改定時点での最新情報を元とする為、参照時点によっては内容／状況に変更が発生している可能性がある。 2
3. リファレンスの利用方法 3 本書は、Azure OpenAI Serviceを使ったアプリケーションを開発にあたり、具体的なプラットフォーム/サービス設計の指針となるテンプレー トとなることを目的としています。 可能な限り 「ベスト プラクティス」 としての実例をベースに提示しますが、ご利用いただく組織の体制や構築するシステム要件に応じてテー ラリングすることを前提としております。 Microsoft Azure のサービス変更、パブリック クラウドを取り巻く環境の変化により 「ベスト プラクティス」 も変化する事も前提としていま す。 3
4. リファレンス一覧 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. 制限事項 5 以下の制限、制約をご理解の上、本書を活用ください。 目的外利用の禁止 本書は Microsoft Azure 上において、システムやソリューションの円滑かつ安全な構築に資することを目的に作成されています。この目的に 反する利用はお断りいたします。 フィードバック 本書の記載内容へのコメントやフィードバックをいただけます場合は、担当の日本マイクロソフト社員にご連絡ください。なお、個別質問への 回答やフィードバックへの対応はお約束できないことを、ご了承いただけますようお願い申し上げます。 公式情報の確認 本書は日本マイクロソフトの有志のエンジニアによって、現場での経験を加えて執筆されたものです。そのため、この記載内容は Microsoft として公式に表明されたものではなく、日本マイクロソフトおよび米国 Microsoft Corporation は一切の責任を負いません。また、本書の 記載内容について Azure サポートへお問い合わせいただいても、回答することはできません。 Microsoft Azure の公式情報については、Azure のドキュメントをご確認ください。 免責 本書の記載内容によって発生したいかなる損害についても、日本マイクロソフトおよび米国 Microsoft Corporation は一切の責任を負い ません。 5
6. 1 章 コールセンター向け AI アシスタント
7. コンテンツ  シナリオ概要  アプリUI  アーキテクチャ  デプロイ方法  考慮事項
8. シナリオ概要
9. コールセンター向け AI アシスタント AI エージェントが顧客との会話をリアルタイムで文字に起こし同時翻訳をします。対話の感情 分析もリアルタイムに可視化します。会話が終了すると会話全体の内容を Azure Open AI サービスにより要約し、センチメントスコアやキーフレーズの抽出を行います。 以下のような状況で、役立つシステムを作成する事ができます  会話内容を指定した長さ、項目で要約し、主要キーワードやセンチメント情報を抽出する 事が可能です。  会話の全体内容および AI により抽出した要約やセンチメント情報等をデーターベースへ保 管し統計的な分析を可能とします。
10. デモUI
12. アーキテクチャ
13. On-premises Azure Web App Speech Service Language Service OpenAI Service 1 WEB アプリ にアクセス 2 マイクからの音 声を文字越し、 翻訳 3 会話のフレーズ毎 に感情分析 4 会話終了時に要 約やキーフレーズを 生成 コンポーネントとデータフロー
14. デプロイ手順
15. サンプルのデプロイ方法 ソースコードとデプロイ手順はGitHubに公開しています: https://github.com/Azure-Samples/jp-azureopenai-samples/tree/main/1.call-center
16. 考慮事項
17. 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
18. Azure Well-Architected Framework観点での考慮事項 (2) コスト最適化 • 不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。 オペレーショナルエクセレンス • システムの健全性の担保、トラブルの解決、利用動向の監視を行うためには適切な監視とログ収集が必要となります。 詳細は「ワークロードの監視」をご参照ください。API Managementを利用することで、API利用の監視やトレースを行うことが容易になりま す。 • ソフトウェアのアップデートや脆弱性への対応など、ソフトウェア/インフラ設計の改修を円滑に進められるよう、DevOpsプロセスを確立してく ださい。詳細は「リリース エンジニアリングの継続的インテグレーション」をご参照ください。 パフォーマンス効率 • アプリケーションの負荷が高まることを見越し、スケーラビリティの確保をあらかじめ検討することは重要です。詳細は「スケーリング用のアプリ ケーションを設計する」をご参照ください • App Serviceは負荷に応じて水平にスケールさせることが可能です。詳細については「自動スケーリングを有効にする方法」をご参照ください。 • 頻出のクエリについてはアプリ側でキャッシュする等のキャッシュ戦略もご検討ください。詳細は「キャッシュを使用する」をご参照ください。 • 特定のユーザーにAzure OpenAIの利用が集中することを避けたい場合には API Management によるスロットリング導入などをご検討く ださい。詳細は「Azure API Management を使用した高度な要求スロットル 」をご参照ください。
19. プロンプト制限について 本デモはレスポンス良く機能を可視化する目的で、Azure OpenAI 呼び出しの会話内容を3600トークン程度に制限しています。このため 会話内容が長くなると Azure OpenAI 呼び出しが制限に引っ掛かります。 トークン制限が緩和されている最新の GPT モデルなどに置き換えることで、より長い会話の要約や分析が可能と考えます。なお異なるモデ ルを利用する場合、app.py 内の正規表現による Q1 ～ Q4 の抽出処理を変更する必要があります。 長い会話内容を要約する場合、Azure OpenAI からの応答に時間を要します。そのような場合、非同期的なバッチ処理として要約情報 をデーターベースなどに収集し、あとから検索や分析情報として利用する方式が適切となる場合もあります。
20. 2章 料理メニュー提案
21. コンテンツ  シナリオ概要  アプリUI  アーキテクチャ  デプロイ方法  考慮事項
22. シナリオ概要
23. 料理メニュー提案 Azure OpenAI Serviceを活用し、家族構成や自宅にある食材から料理メニューを提案でき るアプリケーションを作成できます。 また、店舗の在庫状況と紐づけることで、食材を購入できるエリア、割引情報などを基に購買 を促進することができます。 以下のような状況で、役に立つアプリケーションを作成することができます  食材提案に基づく、スーパーマーケットと連携した販売促進  割引やポイントを最適化した購買を可能にし、ユーザの家計を補助  栄養バランスを考慮した料理メニューの提案 料理メニュー提案
24. デモUI
25. デモ動画
26. アーキテクチャ
27. 1 家族のプロフィール等を送信 2 OpenAI ServiceをTokenで認証 4 生成した文章・画像をレスポンス 3 文章・画像生成のプロンプトを送信 5 提案メニュー・料理画像を表示 Azure App Service Azure OpenAI Service 文章生成モデル (text-davinci-003) 画像生成モデル (DALL-E) Webブラウザ コンポーネントとデータフロー
28. デプロイ方法
29. サンプルのデプロイ方法 ソースコードとデプロイ手順はGitHubに公開しています: https://github.com/Azure-Samples/jp-azureopenai-samples/tree/main/2.recipe-adviser
30. 考慮事項
31. Azure Well-Architected Framework観点での考慮事項 (1) 信頼性(可用性) • Azureのサービスでは「可用性ゾーン」や「リージョン」といった単位で可用性を設計しており、 これらを適切に組み合わせることで、ビジネスクリティ カルなワークロードの信頼性を実現するように設計することが可能です。詳細は「Azure リージョンと可用性ゾーンとは」をご参照ください。 • このシナリオで用いられている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
32. Azure Well-Architected Framework観点での考慮事項 (2) コスト最適化 • 不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。 オペレーショナルエクセレンス • システムの健全性の担保、トラブルの解決、利用動向の監視を行うためには適切な監視とログ収集が必要となります。 詳細は「ワークロードの監視」をご参照ください。API Managementを利用することで、API利用の監視やトレースを行うことが容易になりま す。 • ソフトウェアのアップデートや脆弱性への対応などソフトウェア/インフラ設計の改修を円滑で安全に進められるよう、DevOpsプロセスの確立 について「リリース エンジニアリングの継続的インテグレーション」をご参照ください パフォーマンス効率 • アプリケーションの負荷が高まることを見越し、スケーラビリティの確保をあらかじめ検討することは重要です。詳細は「スケーリング用のアプリ ケーションを設計する」をご参照ください • App Serviceは負荷に応じて水平にスケールさせることが可能です。詳細については「自動スケーリングを有効にする方法」をご参照ください。 • 頻出のクエリについてはアプリ側でキャッシュする等のキャッシュ戦略もご検討ください。詳細は「キャッシュを使用する」をご参照ください。 • 特定のユーザーにAzure OpenAIの利用が集中することを避けたい場合にはAPI Managementによるスロットリング導入などをご検討くだ さい。詳細は「Azure API Management を使用した高度な要求スロットル 」をご参照ください。
33. 3章 目標達成アシスタント
34. コンテンツ  シナリオ概要  アプリUI  アーキテクチャ  デプロイ方法  考慮事項
35. シナリオ概要
36. 目標達成アシスタント Azure OpenAIを活用すると、アドバイザー/メンターのように、目標達成までの道筋をガイドす るようなアプリケーションを作成することができます。 また、目標達成のプランニングに必要な情報を収集し、体系的な形でまとめてくれるアプリケー ションを作成することができます。 以下のような状況で、役に立つアプリケーションを作成することができます  商品企画  パーソナルトレーニング  キャリアプランニング
37. デモUI（商品企画書の作成支援）
38. デモ動画
39. デモUI（パーソナルトレーニング）
41. デモUI（キャリアアドバイザー）
43. アーキテクチャ
44. コンポーネントとデータフロー ナレッジデータ (テキスト) 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 認証
45. デプロイ方法
46. サンプルのデプロイ方法 ソースコードとデプロイ手順はGitHubに公開しています: https://github.com/Azure-Samples/jp-azureopenai-samples/tree/main/3.goal-achievement-adviser
47. 考慮事項
48. 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
49. Azure Well-Architected Framework観点での考慮事項 (2) コスト最適化 • 不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。 オペレーショナルエクセレンス • システムの健全性の担保、トラブルの解決、利用動向の監視を行うためには適切な監視とログ収集が必要となります。 詳細は「ワークロードの監視」をご参照ください。API Managementを利用することで、API利用の監視やトレースを行うことが容易になりま す。 • ソフトウェアのアップデートや脆弱性への対応など、ソフトウェア/インフラ設計の改修を円滑に進められるよう、DevOpsプロセスを確立してく ださい。詳細は「リリース エンジニアリングの継続的インテグレーション」をご参照ください。 パフォーマンス効率 • アプリケーションの負荷が高まることを見越し、スケーラビリティの確保をあらかじめ検討することは重要です。詳細は「スケーリング用のアプリ ケーションを設計する」をご参照ください • App Serviceは負荷に応じて水平にスケールさせることが可能です。詳細については「自動スケーリングを有効にする方法」をご参照ください。 • Enterpriseレベル以上のRedis Cache for Azure（Search機能のご利用に必要）は優れたパフォーマンスを発揮しますが、さらなる性能 を必要とする場合にはRedis Cacheインスタンスを増やし負荷分散することも可能です。また、頻出のクエリについてはアプリ側でキャッシュ する等のキャッシュ戦略もご検討ください。詳細は「キャッシュを使用する」をご参照ください。 • 特定のユーザーにAzure OpenAIの利用が集中することを避けたい場合には API Management によるスロットリング導入などをご検討く ださい。詳細は「Azure API Management を使用した高度な要求スロットル 」をご参照ください。
50. 4章 企業分析
51. コンテンツ  シナリオ概要  アプリUI  アーキテクチャ  デプロイ方法  考慮事項
52. シナリオ概要
53. 企業分析シナリオ概要 法人営業が初回訪問する企業の基本情報や各種インサイトを提供することで、円滑な商談をサポートします。 現在の Azure Open AI のモデルは 2021年9月以降の知識は持っていませんが、Azure に構築したナレッジベー スに登録した企業情報を参照することで、最新情報を理解した自然な文章や適切なインサイトを生成します。 本アプリーケーションは以下の UI を提供します。 ・チャット: 企業の基本情報 (資本金, 直近3年の財務情報など) を検索して、チャットUIを通じて会話のコンテキ ストを理解した最新情報を提供します。参照元データソースから情報の正当性を検証できます。 ・レポート: 企業の分析情報 (事業内容, 財務情報など)をレポート形式で提供します。一部項目はフィードバック を送信することで文章を再生成できます。 情報の取得先は、例えば以下の3つが考えられます １．会社名などの一般的なスタティック情報 ２．仕掛中案件など社内CRM等の情報 ３．GPTに聞く情報
54. デモUI
55. デモUI (チャット)
56. アーキテクチャ
57. 企業情報 (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 アプリケーション コンポーネントとデータフロー
58. デプロイ方法
59. サンプルのデプロイ方法 ソースコードとデプロイ手順はGitHubに公開しています: https://github.com/Azure-Samples/jp-azureopenai-samples/tree/main/4.company-research
60. 考慮事項
61. 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
62. Azure Well-Architected Framework観点での考慮事項 (2) コスト最適化 • 不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。 オペレーショナルエクセレンス • システムの健全性の担保、トラブルの解決、利用動向の監視を行うためには適切な監視とログ収集が必要となります。 詳細は「ワークロードの監視」をご参照ください。API Managementを利用することで、API利用の監視やトレースを行うことが容易になりま す。 • ソフトウェアのアップデートや脆弱性への対応など、ソフトウェア/インフラ設計の改修を円滑に進められるよう、DevOpsプロセスを確立してく ださい。詳細は「リリース エンジニアリングの継続的インテグレーション」をご参照ください。 パフォーマンス効率 • アプリケーションの負荷が高まることを見越し、スケーラビリティの確保をあらかじめ検討することは重要です。詳細は「スケーリング用のアプリ ケーションを設計する」をご参照ください • App Serviceは負荷に応じて水平にスケールさせることが可能です。詳細については「自動スケーリングを有効にする方法」をご参照ください。 • Enterpriseレベル以上のRedis Cache for Azure（Search機能のご利用に必要）は優れたパフォーマンスを発揮しますが、さらなる性能 を必要とする場合にはRedis Cacheインスタンスを増やし負荷分散することも可能です。また、頻出のクエリについてはアプリ側でキャッシュ する等のキャッシュ戦略もご検討ください。詳細は「キャッシュを使用する」をご参照ください。 • 特定のユーザーにAzure OpenAIの利用が集中することを避けたい場合には API Management によるスロットリング導入などをご検討く ださい。詳細は「Azure API Management を使用した高度な要求スロットル 」をご参照ください。
63. 5章 企業内向けChatと社内文書検索
64. コンテンツ  シナリオ概要  アプリUI  アーキテクチャ  デプロイ方法  考慮事項
65. シナリオ概要
66. 企業内向けChatと社内文書検索 Azure OpenAI Serviceを利用して、ChatGPTのような生成AIを利用した企業社内向け チャットを作成することができます。 パブリックな環境で提供されているChatGPTとは異なり、プロンプト・エンジニアリングによるプロ ンプトの調整や、閉域網での提供が可能になります。 また、Azure Cognitive Searchを組み合わせることで、特定の社内文書などを検索し、生成 AIで返答を行うアプリケーションを作成することができます。 このようなアプリケーションにより、企業内の情報検索を会話ベースで行うことが容易になります。
67. デモUI
69. デモUI – 企業内向けChat ChatGPTライクなシンプルな会話 インターフェースです。
70. デモUI – 社内文書検索 会話ベースでAIが社内文書を検 索して、文書を提示します。
71. アーキテクチャ
72. コンポーネントとデータフロー 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
73. デプロイ方法
74. サンプルのデプロイ方法 ソースコードとデプロイ手順はGitHubに公開しています: https://github.com/Azure-Samples/jp-azureopenai-samples/tree/main/5.internal-document-search
75. 考慮事項
76. Azure Well-Architected Framework観点での考慮事項 (1) 信頼性(可用性) • Azureのサービスでは「可用性ゾーン」や「リージョン」といった単位で可用性を設計しており、 これらを適切に組み合わせることで、ビジネス クリティ カルなワークロードの信頼性を実現するように設計することが可能です。詳細は「Azure リージョンと可用性ゾーンとは」をご参照ください。 • このシナリオで用いられている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
77. Azure Well-Architected Framework観点での考慮事項 (2) コスト最適化 • 不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。 オペレーショナルエクセレンス • システムの健全性の担保、トラブルの解決、利用動向の監視を行うためには適切な監視とログ収集が必要となります。 詳細は「ワークロードの監視」をご参照ください。API Managementを利用することで、API利用の監視やトレースを行うことが容易になりま す。 • ソフトウェアのアップデートや脆弱性への対応など、ソフトウェア/インフラ設計の改修を円滑に進められるよう、DevOpsプロセスを確立してく ださい。詳細は「リリース エンジニアリングの継続的インテグレーション」をご参照ください。 パフォーマンス効率 • アプリケーションの負荷が高まることを見越し、スケーラビリティの確保をあらかじめ検討することは重要です。詳細は「スケーリング用のアプリ ケーションを設計する」をご参照ください • Azure App Serviceは負荷に応じて水平にスケールさせることが可能です。詳細については「自動スケーリングを有効にする方法」をご参照 ください。 • 頻出のクエリについてはアプリ側でキャッシュする等のキャッシュ戦略もご検討ください。詳細は「キャッシュを使用する」をご参照ください。 • また、特定のユーザーにAzure OpenAIの利用が集中することを避けたい場合にはAPI Managementによるスロットリング導入などをご検 討ください。詳細は「Azure API Management を使用した高度な要求スロットル 」をご参照ください。
78. 6章 共通基盤ガイド 認証/ロギング/クォータ制限
79. コンテンツ  このガイドの位置づけ  基盤の全体概要  ユーザーの認証認可  ログ取得  クォータ制限（利用制限）  デプロイ方法  補足情報  考慮事項
80. このガイドの位置づけ
81. このガイドの位置づけ 第1章~第5章では用途に応じたアーキテクチャ/アプリケーションの構成例を示しました。 第6章では、どのシナリオでも利用可能なAzure OpenAI利用基盤のアーキテクチャを取り上 げます。 この共通基盤を用いることにより  アプリケーション利用時の認証/認可  リクエスト/レスポンスBodyを含めたログの取得  ユーザー毎、IP毎など柔軟な単位での利用量制限（クォータ制限） などが可能となり、適正な利用の担保や監査を行うことが容易になります。 なお、本ドキュメントに対応するテンプレートは以下のリポジトリで公開されています。 https://github.com/Azure-Samples/jp-azureopenai-samples/tree/main/6.azureopenai-landing-zone-accelerator
82. 基盤の全体概要
83. 本章ご説明するアーキテクチャのサンプルは以下のように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
84. ユーザーの認証認可
85. 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
86. ログ取得
87. 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
88. クォータ制限（利用制限）
89. 同様に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
90. デプロイ方法
91. テンプレートデプロイされる範囲 本プロジェクトでは以下の範囲を自動構築するテンプレートを提供します。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 手動構築する範囲
92. 1. Azure ADへのアプリ登録 API Management上のAPIと対応するアプリをAzure AD上で登録アプリとして登録します  [Azure AD]アプリの登録 からアプリを追加します (リダイレクトURIにはアプリの認証エンドポイントを指定)
93. 2. 公開APIの設定 前ページで登録したアプリに対して、OAuth 2.0でユーザーが許可するスコープを設定します  [Azure AD]アプリの登録 > APIの公開 (Expose an API)からスコープの追加を行います これはTwitterを例にするとサードパー ティアプリに「ツイートを許可する」 「フォロワーの参照を許可する」などの 許可範囲にあたります このスコープをのちに使うので 記録します
94. 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)
95. 4. azdログインとテンプレートデプロイ 以下のコマンドを実行し、Azure Developer CLIでのログインAzure ADテンプレートデプロイを行います $ azd auth login ・ログイン $ azd auth login --use-device-code ブラウザのない環境では $ azd auth login --tenant-id テナントを明示的に指定したい場合には $ azd up ・デプロイの実行
96. 第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を利用するユーザーを識別する ・ユーザの認証認可の必須化 ・利用制限（ユーザー毎） ・ログの取得（ユーザーをログ出力）
97. 補足情報
98. Azure OpenAIの特定リージョンのクォータを回避するためにAPI Managementで複数のAzure OpenAI間でリクエストのラウ ンドロビン冗長化を行うことが可能です。設定の詳細についてはサンプルレポジトリのREADMEをご参照ください API Managementを用いたロードバランシング Azure OpenAI Service Azure API Management ログ出力 ラウンドロビン Azure OpenAI Service （別アカウント or 別 リージョン） リクエストをランダムに振り分け （パーシステントは不可） API Client or
99. 社内への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やバージョンを制御す ることも可能です
100. 本テンプレートのデフォルトでは①のように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
101. 考慮事項
102. Azure Well-Architected Framework観点での考慮事項 (1) 信頼性(可用性) • Azureのサービスでは「可用性ゾーン」や「リージョン」といった単位で可用性を設計しており、 これらを適切に組み合わせることで、ビジネスクリティ カルなワークロードの信頼性を実現するように設計することが可能です。詳細は「Azure リージョンと可用性ゾーンとは」をご参照ください。 • このシナリオで用いられている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
103. Azure Well-Architected Framework観点での考慮事項 (2) コスト最適化 • 不要な費用を削減し、運用効率を向上させる方法をご検討ください。 詳しくは、「コスト最適化の柱の概要」に関する記事をご覧ください。 オペレーショナルエクセレンス • システムの健全性の担保、トラブルの解決、利用動向の監視を行うためには適切な監視とログ収集が必要となります。 詳細は「ワークロードの監視」をご参照ください。本構成を用いることによりAPIの適切な利用を担保することが可能となります。 • ソフトウェアのアップデートや脆弱性への対応など、ソフトウェア/インフラ設計の改修を円滑に進められるよう、DevOpsプロセスを確立してく ださい。詳細は「リリース エンジニアリングの継続的インテグレーション」をご参照ください。 パフォーマンス効率 • API Managementを用いて複数のAzure OpenAI間でロードバランシングすることが可能です。Azure OpenAIのモデル毎Quotaを上限 まで引き上げても処理量が足りない場合にご検討ください • アプリケーションの負荷が高まることを見越し、スケーラビリティの確保をあらかじめ検討することは重要です。詳細は「スケーリング用のアプリ ケーションを設計する」をご参照ください • 特定のユーザーにAzure OpenAIの利用が集中することを避けたい場合には API Management によるクォータ導入などをご検討ください。 本構成にはクォータ制限の設定が含まれています。クォータ制限の設定変更方法についてはサンプルレポジトリのREADMEをご参照くださ い。設定の詳細は「Azure API Management を使用した高度な要求スロットル 」をご参照ください。
104. © Copyright Microsoft Corporation. All rights reserved. 本資料は情報提供のみを目的としており、本資料に記載されている情報は、本資料作成時点でのマイクロソフトの見解を示したものです。状況等の変化により、内容は変更される場 合があります。本資料の記載内容（提示されている条件等を含みます）は、弊社での社内承認、および/またはお客様との有効な契約を経たうえで最終的に確定されます。それまでは、 正式に発効するものではありません。また、本資料に記載されている価格はいずれも、別段の表記がない限り、参考価格となります。お客様の最終的な購入価格は、お客様のリセラー 様により決定されます。マイクロソフトは、本資料の情報に対して明示的、黙示的または法的な、いかなる保証も行いません。 © 2023 Microsoft Corporation. All rights reserved.