Upgrade to Pro — share decks privately, control downloads, hide ads and more …

アプリ開発者のための Azure OpenAI 利用ガイド 2023/07/24

アプリ開発者のための Azure OpenAI 利用ガイド 2023/07/24

2022年11月に ChatGPTが発表されて以降、その汎用性の高さから AI の利用が急速に普及しています。翌年1月には Azure OpenAI Service が一般提供となることで、エンタープライズ領域においても同様のトレンドが加速しています。
Azure OpenAI Service はあくまでも Web API としての提供形態であるため、その活用にはアプリ開発が必須です。本資料では API を既存・新規のアプリに組み込むことで、新たな価値を生み出す開発者向けの技術解説を行います。

なお本資料は主に AOAI を利用するアプリを開発する上で必要な知識を習得することを主眼としているため、各種モデルの特性や以下のような高度な応用については対象外としています。
- プロンプト エンジニアリング
- Embedding
- Fine Tuning
- Semantic Kernel、etc…

Ayumu Inaba

July 25, 2023
Tweet

More Decks by Ayumu Inaba

Other Decks in Technology

Transcript

  1. はじめに 2022年11月に ChatGPTが発表されて以降、その汎用性の高さ から AI の利用が急速に普及しています。 翌年1月には Azure OpenAI Service

    が一般提供となることで、 エンタープライズ領域においても同様のトレンドが加速しています。 Azure OpenAI Service はあくまでも Web API としての提供形 態であるため、その活用にはアプリ開発が必須です。 本資料では API を既存・新規のアプリに組み込むことで、新たな 価値を生み出す開発者向けの技術解説を行います。 本資料は主にアプリを設計する上で必要な知識を習得することを主眼としているため、各種モデルの 特性や下記のような高度な応用については対象外としています。 プロンプト エンジニアリング、Embedding、Fine Tuning、Semantic Kernel、etc… 2
  2. 留意事項 本資料は Azure OpenAI サービスの API を利用するアプリ の開発者向けに作成しています AOAI そのものはある程度ブラックボックス的に扱うことで、

    その解説は最小限に抑えています 2023年6月現在 AOAI は変化が極めて激しく、本書の記載 内容は古くなっている可能性がありますので、適宜公式ドキュ メントもご確認ください 4
  3. アカウント、モデル、API AOAI では GPT-3.5 および GPT-4 系の言語生成モデルが提 供されており、Chat Completion API

    で利用するのが一般的 AOAI を利用するクライアントアプリは AOAI アカウント内にデプロイされた特定のモデルに対して HTTP ベースの Web API を呼び出すことができる GPT-4 は申請ベースでの利用となるが 2023 年 7 月現在は申請数が多くなかなか承認されない ため、まずは GPT-3.5 系のモデルを利用するとよい GPT-3.5 は Completion API にも対応しているが GPT-4 が Chat Completion API のみ対応 しているため、 Chat Completion API を前提にすることで、後日切り替えが容易になる 6 AOAI アカウント GPT-35-Turbo および GPT-4 モデルの操作方法 gpt-4 gpt-4-32k gpt-35-turbo gpt-35-turbo-16k Chat Completion API クライアントアプリ 実際には1つのアカウント内に 1つ以上の異なるバージョンの モデルをデプロイすることができる
  4. Chat Completion API の例 最初に System メッセージが記載された後、User と Assistant の発

    言を「まるごと」送信するステートレスな APIであることがわかる いわゆる “チャット” のように自分の最後のメッセージだけを送信するの ではなく、過去の履歴も含めて送信することで文脈を維持している 裏を返せば「チャット」としての機能をアプリに持たせるためには過去の 発話履歴を残す機能が別途必要になる また Chat Completion API を使用するアプリが必ずしもチャット形式 のサービスである必要もない 7 POST https://{accountName}.openai.azure.com/openai/deployments/{modelDeployName}/chat/completions?api-version=2023-03-15-preview HTTP/1.1 Content-Type: application/json api-key: your-api-key { "messages": [ {"role":"system", "content":"XBOX カスタマーサポートです。XBox に関連する質問のみに回答し、XBOX 以外の機能やサービスには回答しないでください。 性別は女性で口調はツンデレです。XBOXに関する回答ではツンツンしてください。それ以外の質問への対応ではデレてください。"}, {"role":"user", "content":"XBOX で一番人気のあるおススメゲームを教えて"}, {"role":"assistant", "content":"ふん、そんなことは自分で調べればいいじゃない。でも、せっかく聞くんだから、 私が思うには「Halo」シリーズが一番人気があると思うわよ。 あなたも一度プレイしてみるといいわ。"}, {"role":"user", “content”:“PS5 でもプレイできる?"} ], "max_tokens": 800, "temperature": 0.3, "frequency_penalty": 0, "presence_penalty": 0, "top_p": 1, "stop": null } HTTP/1.1 200 OK Cache-Control: no-cache, must-revalidate Content-Length: 569 Content-Type: application/json access-control-allow-origin: * openai-model: gpt-35-turbo openai-processing-ms: 3281.5579 x-ms-region: East US Date: Thu, 18 May 2023 02:36:11 GMT Connection: close { "id":"chatcmpl-7HNmqQFDMgLpHvVfjariBtvyb3Fsl", "object":"chat.completion", "created":1684377368, "model":"gpt-35-turbo", "choices":[{ "index":0, "finish_reason":"stop", "message":{ "role":"assistant", "content":"あら、そんなことも知らないの?「Halo」シリーズはXboxの独占タイトルよ。 PS5でプレイすることはできないわ。Xboxでしかプレイできない貴重なゲームなのよ。" } }], "usage": {"completion_tokens":97,"prompt_tokens":258,"total_tokens":355} } Request Response 会話の文脈を踏まえた出 力が生成される (=Chat Completion) 実際のアプリ開発では各言語向けの SDK を利用するのが一般的だが、API の 通信内容もある程度理解しておくと良い Azure OpenAI Service の REST API リファレンス
  5. Chat Completion API のプロンプト Chat Completion ではユーザーメッセージで終わることで、モデルの回答を促している リクエストのたびにシステムメッセージおよび会話履歴も含めて送信することで、モデルはコンテキストを理解した回答が可能 API 自体はステートレスなので、履歴をアプリ側から送信してやらないと「チャット」として成り立たないということでもある

    会話履歴は実際のものである必要はなく、アプリ側で組み込んでおくことでモデルに動作方法の例として学習させることもできる 8 初回リクエスト 回答 2回目のリクエスト 回答 3回目のリクエスト 学習データとして利用 学習データとして利用
  6. [補足] レガシモデルと Completion API 2023年7月6日から旧来のレガシーモデルの一部が非推奨およびデ プロイ出来なくなっている text-davinci-001/002/003, text-ada/babbage/curie-001, code-davinci-002, code-

    cushman-001 デプロイ済みのレガシーモデルは現時点でも利用は可能だが、2024年7月にリタイア予定のため、余裕をもっ て現行モデルへの移行を検討するよい 上記のモデルを利用しているアプリは Completion API 利用している ため gpt-35-turbo モデルと互換性がある API 互換のためアプリの接続先を切り替えるだけで対応は可能だが、API としての挙動が変わる可能性があ るため注意すること ただし GPT-4 系のモデルは Completion API に非対応のため中長期的には Chat Completion API への 変更も検討する必要が出てくる 9 AOAI アカウント text-davinci-003 gpt-35-turbo gpt-4-32k Completion Azure OpenAI Service legacy models
  7. 不確実で不安定な API (一般的な API とは異なり) OpenAI の API は確率的な挙動を 示すことに注意

    全く同じプロンプトとパラメータを使用しても、得られる結果が毎回異なる可能性もあるということ アプリ開発者は OpenAI とはそういう特性をもつ API であることを理解してアプリに組み込む必要 がある 12 以下は同一のシステムメッセージおよびユーザーメッセージに対して得られた回 答の例(文章も内容も異なる) • 生徒さん、トイレに行きたいということですね。授業中はできるだけ我慢してく ださい。授業が終わったらトイレに行くことができますので、我慢してくださいね。 • 生徒さん、トイレに行きたいということですね。授業が進んでいる最中ですが、 お急ぎの場合は許可します。静かに教室を出て、トイレに行ってください。ただ し、できるだけ授業を途中で抜けることは避け、授業が落ち着いたタイミング で行ってくださいね。 • わかりました。トイレに行きたいのですね。許可しますので、早く行ってきてくだ さい。
  8. ユーザー入力と「プロンプト」 適切な結果を得られる可能性を高めるために、各 API を呼 び出す際に様々な情報を付与する必要がある Chat Completion API ではシステムメッセージやチャット履歴を利用して役割やサンプル 回答などを付与するコンテキスト内学習を行うことが多い

    このような技法を昨今はプロンプト エンジニアリング などと呼ぶが、アプリを利用する一般 ユーザーにこの技能を期待することは現実的ではない このため単純なユーザー入力だけを OpenAI に送信するのではなく、アプリ側で適切なプロ ンプトとなるように調整する必要がある 13 教師代行サービス ユーザー入力 “先生トイレ” gpt-35-turbo プロンプト S: あなたは学校の教師です U: 先生トイレ ※ 前述の例でシステムメッセージを割愛すると
  9. ChatGPT ≠ Chat ChatGPT モデルおよび Chat Completion API を使用す る場合も、アプリがチャットサービスである必要はない

    会話履歴もコンテキスト内学習のための入力データでしかなく、単なる会話の例なのか、実 際にユーザーが直前に発話した内容なのか区別していない(できない) Chat Completion API を使用する観点では「対話形式のデータをもとにコンテキスト学習 を行い最後のユーザーメッセージに続く文字列が返ってくる」という意味しかない 14
  10. まずは API の挙動に慣れる 従来型の Web API とはかなり使い勝手の異なる API であるため、ま ずは挙動に慣れる必要がある

    いきなりアプリに組み込もうとすると、結果が安定しない、答えが間違っているなどの問題だけでなく、OpenAI の結果に基づいた処理で問題を引き起こす可能性もある まずはプロンプトをいろいろ試して得られる結果を観察する必要があるが、そのために気軽に試すためのツール として Playground が提供されている 実際に Azure にデプロイされた本物の OpenAI サービスおよびモデルを利用する既成の UI なので、評価版 として無償で使えるといったものではない点に注意 15 Chat Completion API を試している - 左側でシステムメッセージと回答例とし てコンテキスト学習データを入力 - 右側で実際のユーザー入力と結果を 得ている
  11. サンプルコードの生成 Playground で実行した結果は各種言語のサンプルコードとして 出力することが出来る json : Web API としての HTTP

    リクエストボディのみ python, c# : 各言語向けの OpenAI SDK を利用して呼び出すサンプルコード Curl : コマンドラインから curl で呼び出すサンプルコード 16
  12. 呼び出し元アプリを制限する API キー 各モデルを API として呼び出すためにはアカウントレベルで 共通の API キーを付与する必要がある Cognitive

    Service アカウント名 > ホスト名部分 モデルのデプロイ名 > URL パス 呼び出す API の種類 > URL パス API キー > api-key リクエストヘッダー 17 POST https://{accountName}.openai.azure.com/openai/deployments/{modelDeployName}/chat/completions?api-version=2023-03-15-preview HTTP/1.1 Content-Type: application/json api-key: your-api-key { 各モデルに渡すための情報 } Request API キーの値は Azure Portal 等で確認できるので、 クライアント アプリに渡して利用する このキーが漏洩すると問題なので厳密な管理が必要になる Open AI 呼び出すの認証はこの共有キーだけではなく、 後述の Azure AD 認証も利用可能(かつ推奨) Playground は自動的に API キー を取得して OpenAI を呼び出して いるため、この意味でもエンドユー ザーに利用を開放しないほうが良い
  13. クォータ制限 2023年6月時点では AOAI サービスのクォータ制限が厳し く、既定のクォータで不足する場合には対応が必要 クォータ拡張リクエストも可能だが、現状は需要も多くリクエストがすぐに通るとは限らない このため複数の AOAI サービスをデプロイしてクォータを加算し負荷分散したいところだが、 クォータの定義(per

    model and region)に注意 18 Azure OpenAI Service quotas and limits - Azure Cognitive Services | Microsoft Learn Manage Azure OpenAI Service quota - Azure Cognitive Services | Microsoft Learn 例えば ChatGPT はリージョンおよびモデル単位で1分間あたり のトークン数(TPM)が240k が上限 同じリージョンに複数の AOAI サービスおよび ChatGPT をデプ ロイしても各々はクォータの総量は増えない クォータを加算するには「複数リージョン」ないしは「複数サブスク リプション」を使う必要があある 複数リージョンを使用する場合は、AOAI の利用可能リージョン数 (現状5つ)が最大値となる 上記とは別に Requests Per Minute (RPM) に関しては 1K TPM あたり 6 RPM という値が適用される
  14. REST Client for Visual Studio Code プロンプトの調整などで何度も API コールを行う場合には REST

    APIを直接呼び出した方が便利 Playground は便利だがパラメータやプロンプトといった諸条件を保存できないため再現性の確認 などには不向き HTTP 呼び出したできるツールならば AOAI は利用できるが、掲題のツールはリクエストパラメータ をテキストファイルとして保存できるというメリットがある 20 HTTP Request の内容 をテキストファイルで保 存・管理 “Send Request” で 送信 HTTP Response データが表示される プロンプトやパラメータ を調整して保存しておく
  15. クライアント アプリケーション AOAI は API なので最低でも OpenAI を呼び出すクライア ントアプリの開発が必須 Azure

    OpenAI Studio に含まれる Playground は Azure を利用する開発者が利用する ことを想定したものなので、エンドユーザーには直接使わせるべきではない ユーザーインタフェースを持つ“画面”提供することが多いが、ユーザーの入出力を伴わない デーモン型のサービスや、バッチ処理としての利用も考えられる ユーザーが直接触るユーザーインタフェース側に API キーを持たせると漏洩リスクが大きく なるため、サーバーサイドで AOAI をラップするサービス層は必須 22 Power Apps や SPA のようなクライアントアプリから 直接 API を呼び出すことはもちろん可能だが・・・ 入力値チェック、プロンプトの構築、会話履歴の保持、ユーザー認証とアク セス制御、スロットリング、API キーの秘匿、運用や監査のためのログ記 録など、カスタムアプリでやるべきことは多い
  16. 会話履歴の管理 Web アプリのようなステートレス サービスから ChatGPT を呼び 出す場合には会話履歴の管理が重要 実装上はステートフルなクライアント側の情報として保持することももちろん可能だが、 エラーや障害発生時の継続性を重視すならばサーバーサイドで永続化して状態管理するとよい 23

    CosmosDB Redis Cache 会話ID : XXX ユーザー入力 #6 { id: xxxx, user: “Yamada“, history [ { message : “基本指示 #0” }, { message : “ユーザー入力 #1"} , { message : “ChatGPT 応答 #2"} , { message : “ユーザー入力 #3"} , { message : “ChatGPT 応答 #5"}, ] } #0 ~ #6 までを マージして送信 ChatGPT 応答#7 #7 を会話履歴に追加 ここではカスタム DB を使用しているが Web アプリがセッション管理機能を持つなら そちらを利用しても良い
  17. OpenAI による入出力の補完 他の API の入出力情報を補完するために OpenAI を利用 するケースも非常に多い OpenAI の各モデルとユーザーが直接的に対話するのではなく、自然言語によるユーザー

    入出力と他の API の入出力を変換するためのパイプラインとして活用する この場合カスタムアプリは OpenAI とその他の API のオーケストレーターとしての役割を持 つことになる 24 顧客の売り上げ Top 3 を教えて SQL を生成して SELECT TOP 3 * FROM … XXX, YYY, ZZZ 参考 : Azure Open AI Service で SQL を 生成するプロンプト例 日付指定 気象データ取得 温度と湿度から考 察して 気温は平年並みですが 湿度が低く過ごしやすい 気候と考えられます XXX, YYY, ZZZ
  18. クォータを共有するアプリ 複数のアプリから AOAI サービスを利用する場合には個別に クォータを割り当てることで一方的な消費を防ぐことができる 前述の通りクォータ制限は「モデル」および「リージョン」の単位に適用されるため、単一リージョンに 複数のAOAI アカウントを作成しても TPM クォータの総量が共有される

    あるアプリがクォータを極端に消費するような状況では別のアプリが全く利用できなくなる可能性があ るため、各モデルに対してクォータを配分することで上限を設定する 25 gpt-35-turbo gpt-35-turbo App1 East US Region App3 200TPM 40TPM App2 各リージョンで ChatGPT は 240TPM まで
  19. ラッパー API としての機能提供 アプリではなく API をそのまま(あるいはサブセット)を提供したいケー スでは API Management を挟むとよい

    PowerApps のようなローコードツールから利用する市民開発のシナリオなどが該当する API Management の機能を活用することで生の AOAI に対して各種の付加価値を提供することができる カスタムスロットリング、高度なログと監視、各種パラメータの固定、AOAI キーの隠蔽、開発者ポータルによるサブスクリプション の払い出し、etc… 開発者に提供する OpenAPI 仕様を定義しておくと PowerApps のカスタムコネクタも自動生成できる 26 アプリやユーザー個別の API サブスクリプション ログと監視 開発者ポータル API 仕様確認 キーの払い出し テスト実行 カスタムコネクタ生成と データ損失防止ポリシー制御 Azure OpenAI (オリジナルAPI) AOAI キー ガバナンス IT管理者 AI 活用推進 市民開発者
  20. クォータの加算と負荷分散 最大クォータで不足する場合には、複数リージョンに AOAI サービスを デプロイしてクォータの総量を増やし、負荷分散を行う Azure で提供される負荷分散サービスを使用する場合には、その特性に応じて使い分けること 現状 AOAI が利用できるリージョンは5つまでなので、単一サブスクリプションで実現するためには5倍が限界

    ただし 5 リージョン全てで利用可能なモデルは gpt-35-turbo(0301) のみ 例えば gpt-35-turbo(0613) は 3 リージョンでしか利用できないため 3 倍が限界 27 AOAI (East US) AOAI (UK South) クライアントアプリと同一リージョンに配置する L7 ロードバランサーとして Application Gateway を 利用 Application Gateway (Japan East) AOAI (East US) AOAI (UK South) L7 グローバル ロードバランサーとして Front Door を利用 各サービス間通信のネットワークは閉域化できない Front Door (Global) App (Japan East) App (Japan East) AOAI (East US) App (Japan East) Traffic Manager (Global) DNS ベースのロードバランサーとして Traffic Manager を利用 重み付けに基づいたルーティングにすることで負荷 を分散する サービス間通信のネットワークは閉域化できない AOAI (UK South) ※ Azure の負荷分散サービスを利用せずに、アプリケーションのロジックとして複数の AOAI の URL をラウンドロビン方式で呼び分けてしまっても良い
  21. 広域災害対策 フロント側のアプリも含めて複数リージョンの Active-Active 構 成にすることで、広域災害対策と負荷分散を兼ねることもできる ただし現状ペアリージョンで AOAI を利用することができないため、一般的な Azure の広域災害対

    策構成とは異なってくることに注意 28 Front Door (Global) App + AOAI (East US) App + AOAI (UK South) App + AOAI (East US) App + AOAI (UK South) API Management (Multi Region) API Management は最も短い待機時間になるように各リージョ ンゲートウェイにルーティングするため、アクセス元によっては負荷 が偏る可能性がある 負荷分散を兼ねる場合には重みつけのルーティングを使用 して各リージョンに均等にリクエストを分散する
  22. API キーによる認証とアクセス制御 既定では AOAI のアクセス制御には API キー(文字列)が利用さ れるが、以下のような課題がある API キーが漏洩するとアクセス経路さえ確保すればいくらでも呼び出せてしまうため、対策としては定

    期的なローテーション運用とアクセス元アプリへの配布が必要になる アカウント全体でキーが共通のため部分的な許可/拒否が出来ず、キーの漏洩が疑われるような状 況では全アクセス元のキーを同時に切り替える必要がある 30 API キーは共通のため アクセス元の判別が出来ない ※ 前述の API-M を挟むパターンでも共有キーとしての漏洩リスクは依然として残る
  23. Managed ID + RBAC による認証とアクセス制御 アクセス元となるクライアントアプリが Azure Compute リ ソース上で動作する場合は

    Managed ID が利用できる アプリのコードから動作環境である Azure リソースのアクセストークンを取得し、AOAI を呼 び出す際に認証情報として付与する AOAI 側は各リソースに付与された Manage ID に対して RBAC ロールを使用したアクセ ス制御を行うことが出来る 31 IDENTITY_ENDPOINT クライアントアプリ ① アクセストークンを要求 ② アクセストークンを付与してリクエスト Azure Active Directory RBAC ロール 割り当て モデル AAD に登録された各 アプリに対して 個別にアクセス許可を行う
  24. Managed ID + RBAC による認証とアクセス制御 App Service に Manage ID

    を割 り当てる Microsoft Entra ID 上に同名のサービスプリンシ パルが作成される システム割り当て or ユーザー割り当て AOAI 側で App Service にアクセ スを許可する App Service を表すサービスプリンシパルに対して Cognitive Services OpenAI User ロールを付与 32
  25. Managed ID + RBAC による認証とアクセス制御 前述の設定が終わっていれば、各種言語向けの対応するライブラリ を使用して API を呼び出すコードを実装すればよい C#用の

    Azure Open AI SDK: NuGet Gallery | Azure.AI.OpenAI 1.0.0-beta.5 C#用の Azure Identity SDK : NuGet Gallery | Azure.Identity 1.9.0 33 // プロンプトの構築 var completionParam = new CompletionsOptions(){ Prompts = { prompt }, MaxTokens = 1000, ChoicesPerPrompt = 3 }; // 認証情報とクライアントの生成 var aoaiclient = new OpenAIClient( new Uri($"https://{_config["AoaiAccountName"]}.openai.azure.com/"), new DefaultAzureCredential() ); // 呼び出すモデルのデプロイ名 var modelDeploy = _config["ModelDeployName"]; // 実際の OpanAI WebAPI の呼び出し var result = await aoaiclient.GetCompletionsAsync(modelDeploy, completionParam); C# DefaultAzureCredential の挙動は Azure Identity クライアント ライブラリ を参照 アプリがデプロイされた実行環境に応じて資格情報を自動取得するため、パスワード等の記載が不要
  26. Service Principal による認証とアクセス制御 クライアントアプリを Azure 外部で動作させる場合にも、API キーではなく Service Principal (SP)を使用すると良い

    SP を使用する場合にはクライアント側に証明書、クライアントシークレット、フェデレーション資格情報等の設定が必要 になるため Managed ID のように管理不要とはならないが、、、 ユーザーやアプリの認証アクティビティに対して Microsoft Entra ID が提供する各種のセキュリティ機能が活用で きるようになり、AOAI へのアクセスに対する保護強度を高めることができる 認証用ライブラリとしては Managed ID と同様に Azure Identity (DefaultAzureCredntial 等)が利用可能 34 アプリ登録 A アプリ登録 B アプリ登録 C Microsoft Entra ID ① トークンを要求 ② リクエスト RBAC ロール割り当て モデル Azure OpenAI On-Premise
  27. ユーザー認証とアプリ認証 AOAI が Microsoft Entra ID 認証に対応しているため、アプリ (SP)だけでなくユーザーに対するアクセス制御も可能 しかし現実的には AOAI

    のフロントエンドを担うクライアントアプリがユーザー認証とアクセス制御を することになるはずなので、AOAI 側がユーザーレベルでアクセス制御を行う意味があまりない AOAI 側でユーザーレベルでのアクセス制御をするには、RBAC ロールの割り当てでアクセス制御を し、かつ、アプリに対するユーザー委任の許可が必要になるため実装が複雑になる 35 ユーザー認証と アクセス制御 クライアント アプリ 不正アクセス対策としてフロント側にユーザー認証と アクセス制御の仕組みがあるはず App Service 等の EasyAuth 機能を利用すると 比較的簡単に実装できる バックエンド側は 信頼するアプリからの 呼出しのみを許可 ユーザー認証と アクセス制御 クライアント アプリ ユーザー単位で アクセス許可 クライアントアプリがユーザーのフリをして AOAI にアクセスするため権限を委譲する 設定および作りこみが必要 AOAI はユーザーの個人情報を管理 しているわけではないため、ユーザー が識別できるメリットが少ない (挙動も変わらない)
  28. [補足] ユーザーレベルの制御が必要になるケース いくつかのケースではユーザー単位での認証が便利な場合もある - 本番環境にデプロイする前に、開発環境で動作するアプリから AOAI を呼び出したい場合には、 開発者のユーザーアカウントに対して RBAC ロールを割り当ててアクセスを許可すると便利

    - Power Apps から直接 AOAI にアクセスする場合には、ユーザー情報で認証・認可を行わざるを 得ない(カスタムコネクタがアプリでの認証に対応していないため) 36 DefaultAzureCredenital を使うと、Az login や VS/VS Code で認証したユーザーアカウント でAOAI にアクセス可能 アプリ開発者が Azure 上のリソースに 直接のアクセス権を持つのであれば、 管理上の問題も出にくい 開発端末 本番環境のアプリ ※ 通信経路の問題は別途考慮すること
  29. [補足] Playground を使用できるユーザー AOAI Studio や Playground を使用するユーザーはアプリと同様に RBAC ロールの割り当てが必要

    通常は Cognitive Services OpenAI User ロールを使用するが、AOAI リソースの参照権限も含むため、開発者 はともかくエンドユーザー割り当てには不向き どうしてもエンドユーザーに直接のアクセス権付与が必要な場合はカスタムロールの作成を検討すると良い 前述の通りフロント側のアプリを認証すればよいケースも多いため、 AOAI においてユーザーレベルでのアクセス制 御が必要か否かは検討すること 37 { "id": "/subscriptions/3dedf418-2574-41e1-87f9-f7ea51f53648/providers/Microsoft.Authorization/roleDefinitions/5e0bd9bd-7b93-4f28-af87-19fc36ad61bd", "properties": { "roleName": "Cognitive Services OpenAI User", "description": "Ability to view files, models, deployments. Readers can't make any changes They can inference", "assignableScopes": [ "/" ], "permissions": [ { "actions": [ "Microsoft.CognitiveServices/*/read", "Microsoft.Authorization/roleAssignments/read", "Microsoft.Authorization/roleDefinitions/read" ], "notActions": [], "dataActions": [ "Microsoft.CognitiveServices/accounts/OpenAI/*/read", "Microsoft.CognitiveServices/accounts/OpenAI/engines/completions/action", "Microsoft.CognitiveServices/accounts/OpenAI/engines/search/action", "Microsoft.CognitiveServices/accounts/OpenAI/engines/generate/action", "Microsoft.CognitiveServices/accounts/OpenAI/engines/completions/write", "Microsoft.CognitiveServices/accounts/OpenAI/deployments/search/action", "Microsoft.CognitiveServices/accounts/OpenAI/deployments/completions/action", "Microsoft.CognitiveServices/accounts/OpenAI/deployments/chat/completions/action", "Microsoft.CognitiveServices/accounts/OpenAI/deployments/extensions/chat/completions/action", "Microsoft.CognitiveServices/accounts/OpenAI/deployments/embeddings/action", "Microsoft.CognitiveServices/accounts/OpenAI/deployments/completions/write" ], "notDataActions": [] } ] } } モデルの参照や呼び出し に必要な権限 Azure Portal や Studio の利用に必要な権限
  30. 閉域ネットワークアクセス AOAI は既定ではインターネットに公開された Public IP アドレス を持つ Web API であることに注意

    アクセスには API キーや後述の Azure AD 認証が必要なため、簡単に外部から悪用されるような ことはないが、多層防御の観点からネットワーク アクセス制御は考慮しておくこと 特にオンプレミス環境との連携要件がある場合には、Private Endpoint や Service Endpoint を 使用した VNET への閉域化の考慮が重要になってくる 39 不正なインターネット アクセスは拒否したい Private Endpoint Service Endpoint ExpressRoute or VPN On-premise Public IP アドレス Internet サービス エンドポイントとプライ ベート エンドポイントの違い
  31. Public ネットワーク + AOAI Firewall AOAI へのアクセスを特定の Public IP アドレスからのみに制限

    する方法 通信経路を閉域化しない(できない)場合には、オンプレミス環境のインターネット エッジや Azure 以 外のクラウドサービスといった 「IP アドレスが限定できるアクセス元」からのアクセス制御に利用する 40
  32. Private Endpoint + AOAI Firewall 特定の AOAI アカウントに接続するための専用の Private IP

    アドレス を仮想ネットワークに設置する方式 AOAI 側ではPrivate Endpoint 以外からのアクセスを拒否するための Firewall 設定と組み合わせる Private Endpoint の IP アドレスにルーティング可能なオンプレミス ネットワークから、同一 VNET 内リソース から、Peering された VNET からアクセスが可能なため、使い勝手が良い 41 Private Endpoint ExpressRoute or VPN On-premise Azure OpenAI Service の利用を VNet 経由に限定する方法 - Qiita
  33. Service Endpoint + AOAI Firewall 仮想ネットワーク内のサブネットから AOAI サービス Public IP

    アドレ スへの通信経路を最適化する方式 AOAI 側では特定のサブネット以外からのアクセスを拒否するための Firewall 設定と組み合わせる VM や VNET 統合された App Service といった特定のサブネットに設置されたリソースに対して効果がある 逆に言えば、オンプレミスからの直接アクセスや別のVNET/Subnet からのアクセスには利用できない 42 Service Endpoint Firewall
  34. Japan East リージョン East US リージョン 各種 PaaS と閉域ネットワーク構成する例 ネットワーク設計は

    AOAI 単独で考えるのではなく、周辺サービスとの連携も 踏まえて全体設計をすること 現状 AOAI が提供されているリージョンが限定的であるため、マルチリージョン構成になりがち 下記の例では AOAI のみ海外リージョンに設置し、Private Endpoint を利用してリージョン間通信を行っている またクライアントアプリや保守用 VM アクセス用の VNET と、AOAI を含む各種バックエンドリソース用の VNET を 分離することでオンプレミスのネットワークへの影響を極小化している 43 ExpressRoute VNET統合 一般利用者 保守担当者 Private Environment
  35. Power Apps + AOAI 大規模言語モデルは応用範囲が極めて広く PoC が重要になるため、 ローコードツールとの相性が良い が、実運用を見据えると Power

    Apps から AOAI を直接呼び出すアーキテクチャは課題がいくつかある Chat Completion API の定義から生成されるコネクタの「関数」は市民開発者には難易度が高く、プロンプトエンジニアリング スキルも要求されるため、より便利で簡単に利用できるカスタム API として提供したほうが良い カスタムコネクタは OAuth 2.0 Client Credential Flow に対応していないため、API キーの配布やユーザー認証によるアク セス制御(RBAC)の運用に難がある オンプレ連携などバックエンドの閉域化が必要な場合には何らかの Azure サービスを利用して VNET 内に通信を通す必要が ある 44 ユーザーの認証認可/パブリックネットワーク アプリの認証認可/ プライベートネットワーク APIM 開発者ポータル 開発・共有 Express Route
  36. [補足]AOAI Firewall と Playground AOAI に対して Firewall ルールを有効にした場合は、 Playground からのアクセスも阻害されがち

    Azure OpenAI Studio は oai.azure.com ドメインでホストされているが、モデルを呼び出すために は Playground を表示したブラウザから AOAI のエンドポイント account.openai.azure.com に 直接アクセスできる必要がある 回避策はいくつか考えられるが、 Private Endpoint や Service Endpoint を使用した場合は閉域 化したネットワーク内に踏み台の仮想マシンを設置し、Firewall 設定をピンポイントで緩めると良い 45 https://oai.azure.com Playground を表示 モデルを呼び出し 開発者端末 エンドユーザー クライアント アプリ https://account.openai.azure.com