登壇者の自己紹介とアジェンダ紹介
坂部広大氏：「Azure OpenAI Serviceリファレンスアーキテクチャからみる、本番システムレベルのLLMアプリに必要な検討項目の解説」というテーマで、日本マイクロソフトの坂部と申します。時間としては25分、お付き合いいただければと思います。それではよろしくお願いします。
（会場拍手）
「このセッションでわかることと、話さないこと」ですね。今回のセッションでわかること。昨今の生成AIという部分で、マイクロソフトが出しているもので「GitHub」には、やたらとチャット（Microsoft から公開されている生成AIを使ったチャットのサンプルアプリケーション）が出ていますが、その中で、リファレンスアーキテクチャというのもしっかり出しています。
ただし、めちゃくちゃ量があって、昨日の夜もまた増えているぐらいにどんどん増えていっているんですね。よくある話としては、リファレンスアーキテクチャだとこう書いてあるんだけど、「あれ、ちょっと違う。こっちでは違うことを言っているな」みたいな声が聞こえてくるというものです。
また、リファレンスアーキテクチャの中身も、実は大きく3種類に分類できるかなと思っています。そのあたりをお話ししつつ、この会場のみなさまは、みんなきっともう「Azure」が大好きだと信じながら話していますが、仮にそうではない方のための最初の一歩ですね。
一歩目はやはり難しいんですよ。なので、この25分で、そのハードルを極限まで下げたいと思っています。GitHubのアカウントとクレジットカードを持っていると、サブスクリプションがすぐできます。本人確認などは必要ありません。クレジットカードがあればいいです。現ナマとPCとGitHubがあればすぐできます。
というところで、「最初の一歩のハードルを下げていきます」というところです。とはいえ、対象者はふだんから論文を読まれる方……あっ、みなさん実践している専門の方ですね。私はふだんから論文を読むほうではないのですが、昨今のAIを用いた本番環境の中でも、やはりいくつかAI要素の技術的な部分をキャッチアップしながら開発や運用に関わるというのはけっこう大変であると（言われています）。
ただし、そういった状況の中でも事業としてプロダクトを良くするためにAIを使っていくということが今後増えていくと思うんですね。そのために、今後開発運用に携わる方向けにお話できればと思います。
ここまで、ゴールの部分についてお話ししました。それでですね、自己紹介をせねばというと……めちゃめちゃ（スライドの）字が小さいですね。読み上げません（笑）。「Speaker Deck」に上げておきますね。
実は日本マイクロソフトという場所以外で登壇するのはものすごく久しぶりです。というのも、ウォンテッドリーで勤めていた時は、「CloudNative Days Tokyo」などで、主に「Kubernetes」や「Docker」の周りで登壇していました。
今は、パートナー事業本部というところで、ひたすら変化に強いインフラというのを言い続けている人です。
ちょっとホームページを見ていたのですが、404エラーが返ってきてしまいました。インフラ担当と言いながら、404を見過ごすという悲しい事件がありました。気がついたら「koudaiii.com」が、失効されていたんですよ。ロックされていて、「あれ、なんでだ？ 誰だ？」と思ったら、（犯人は）私だったんですね。
何をやっていたかというと、自分のやつを移管したことをすっかり忘れていてドメインが切れていたという事件がありました。大丈夫です。今朝7時58分に直しました。今は見えています。
じゃあ、今の職で何をやっているかというと、お客さまの中でお話しすることもありますが、OSSの活動も同時にやっています。
いくつか大きな部分だと、Azureを使った時もほかのクラウドベンダーを使った時も同じだと思いますが、「Terraform」を使った時に、既存のものをどうしてもTerraform化したいという需要があるという部分で、社内のハッカソンに出てツールを作っていました。
2023年に入ってリブランドされて、しっかりマイクロソフトの公式ドキュメントの使い方も入って、そこで正式に私の汚いコードの半分以上が消されましたが、きちんとツールとして旅立ってくれてよかったなと思っています。
それ以外に、本を書いたりレビューに参加したりしています。インタビューは（スライドの）下のところに書いています。
（今日の）アジェンダとしては、やはりリファレンスアーキテクチャについて話そうと思っています。その前に、Azureの紹介をちょっとしないと「何言ってんだ？」みたいなことにならないように、ちょっとだけAzureの紹介にお時間いただければと思います。
その後に、リファレンスアーキテクチャも今は3種類に分かれているという話ができればと思います。
App Service+DBによる接続方法
では、キャッチアップのお時間をいただければと思います。（スライドを示して）よくあるWebアプリケーションとデータベースです。
これは、コンテナとかWebアプリとかは関係ないですね。関係なく、純粋な一般的なアプリケーション、3層構造と言われている部分です。
「App Service」と言った時に、実際になにか動かすものを指しているわけではない場合があります。具体的に何を言っているかというと、App Serviceというものの中には、ランタイムとして動かすPythonのコードや、Goのコードを動かすものがあったり、コンテナで動かすということもできます。
App Serviceの中で、それぞれコンテナで動かす時は「Web App for Containers」と言っています。ランタイムでそのまま動かす時は、App Serviceの「Web Apps」と、ちょっとわかりやすく明示的に分けています。
この中に、App Serviceの「Azure Functions」というものがあります。2019年当時、牛尾さん（牛尾剛氏）が来て話されてたかなと思いますが、もしご存じの方（これまでの 「ServerlessDays」 に参加された方）はそこで「あぁ」となるかなと思います。
そこ（当時の「ServerlessDays」）からのアップデートで、ちょっと付け足しがあります。「Container Apps」というものが増えたんですね。Container Appsがなにかというと、App Serviceとはまったく関係ない基盤で、「AKS」、Azure Kubernetes Serviceの上で動かしているマネージドサービスです。
Kubernetesのデータプレーンのマネージドサービスみたいなかたちですね。なので、「ワンショットのジョブを打ちたい」とか「Webサービスを常時動かしたい」とかも含めて、いわゆるKubernetesで利用しているようなものが、本当にデータプレーンの部分のYAMLを書いて出します。Kubernetesのメンテナンスは、マネージドサービスにお任せしますといったものです。
名前が似ていますが、これは別物なので動いている基盤すら違います。App Serviceは、あくまでもVMというところにご注意ください。
（スライドを示して）このアイコンたちですね。このアイコンたちがこれからたくさん出てきます。リファレンスアーキテクチャ、めっちゃ出てきます。
アイコンもどうかとは思いますが、名前が書いていなかったりするので、これは良くないですね。Web Appsも丸い色の地球みたいなマークで、さっそく名前が付いていません。（スライドを示して）こちらに至ってはSQLとは書いてあるのですが、これはDBですね。雲マークとか出ていたり、AIのサービス（「Azure OpenAI Service」）とか、そういった部分もいくつか出てくるんですね。
複雑になればなるほど、どうしても名前を書いていられないので、どんどんアイコンだけになっている状態。そのあたりをうまくひもとくようにできればというところが、今日のゴールですね。
まず、App ServiceとDBのところで「X」と書いてありますが、これは「バツ」です。WebアプリケーションからデータベースやほかのPaaSへ接続する際に、プライベートでインターネットを通らずに使いたいという要望は必ず出てきます。
その時に、接続の仕方にいくつか選択肢があるのはいいところでもあり、ちょっとかゆいところに手が届くという部分です。
具体的にどういったところかというと、インバウンドとアウトバウンド、これを別々に分けて機能をマネージドサービスとして提供しています。
アプリケーション側からはデータベースの中に入っていけるのですが、このVNETというのは、ネットワークのいわゆるVPCだったり、そういったレイヤーになります。
そこの中に、いくつかサブネットというネットワークを切っているので、VMなどいろいろなものを立てることができます。
そこからWebアプリケーションの、この地球マークの経路は、「いや、ブロックしちゃえ」と。あくまでもエンドユーザーからの通信に絞りたいとか、そういったことができる部分です。
向かって右手ですね。Private Endpoint、Private Linkがあります。このPrivate Linkというのは、PaaSが持っているサービス名なのですが、そこにエンドポイントというかたちで……棒がピンと入っているだけですが、このアイコンです。1個NICが追加になったと言うと、わかりやすいかなと思います。
つまり、数あるPaaSのサービスの中で、Private Linkのサポートがあって、Private Endpointとして、このサブネットに通信できる口を出しますよといった場合に、それ用のNICがもう1個くっついたというふうに考えてください。
ここは双方向で通信できる部分で、右と左はVNETという枠で見るとつなげるというかたちです。つなげ方がちょっと違うだけで、経路のインバウンド、アウトバウンドができる、できないという部分ですね。
ここがけっこう複雑になる場合があって、企業機密や個人情報などデータの内容の部分で、こういったいろいろな機能があります。
「Azure Private Endpoint 」と「Azure Private Link」の説明
Private EndpointとPrivate Link、2つ名前が出てきましたが、「これ何？」というのがよくある問い合わせです。これ、問い合わせのページにそのまま書いてあるんです。
Private Endpointはなにかというと、ネットワークインターフェイス、やはりNICです。そのまま書いています。Private Linkはなにかというと、サービスプロバイダーによって作成されるサービスです。このような関係になっています。
Private Endpointを使っている場合、絶対Private Linkがそこにあります。これ、1対1の関係なので、何が起こるかというと、気がついたらアイコンが消えているんですよ。Private Endpointが、ポンッて描いてあったりなかったりします。初めて見た人は本当に誤解して、何が違うのかまったくわからないというものがよく出てくる。そこだけでけっこうハードルは上がっちゃいますよね。
「何だこれ？ なんでこっちの図はこう描いてあって、こっちの図はこう描いていないんだ？」って。こういった関係性になります。1対1なので絶対あるだろうと省略されていることがあります。
このあたりは、プライベート化という部分でいくつかほかの方法があるのですが、実際にリファレンスアーキテクチャで、「なんでこれが出てきたんだろう？」というのを見つつでもいいのかなと思います。
具体的には、外から来るものが内部で通信する時の状態がそれぞれ違うという部分です。一番上は外に行って外へ出るし、真ん中は外から来て中に入るよとか、中からしか受け付けないとか、そういったものになります。
表にするとわかりやすいのですが、ここでは図を引用しています。これもリファレンスアーキテクチャにきちんと説明が入っています。
Azure App ServiceはEasy Authと言われている
みなさん、青色のピラミッドの形を見たことがありますか？ 「Azure AD」、Active Directoryは、ピラミッドみたいな三角なんですね。
あれが出てくると、どうしても難しく感じてしまうというか、けっこうハードルがぐんと上がってしまいます。（スライドを示して）ここですね、実際に今からお見せするいくつかのリファレンスアーキテクチャでたくさん出てきます。認証やセキュリティを見ていると必ず出てきます。
URLのところを見ると、実際にこの絵がアーキテクチャの図と描いてあるんですが、どこまでがマネージドサービスの話で、どこまでが自分たちで実装していないかがちょっとわかりにくいので、青色の枠と青色のアイコンを追加しました。
要は、設定できるんですね。「Azure ADを使います」とボタンをポチってやれば、自分の所属しているAzure ADでログイン認証できる。（スライドを示して）ここですね、「AuthN/AuthZ」のところです。ミドルウェアが入ります。Facebookログイン、Googleログインがあります。うれしいのはGitHubログインですかね。ここが重要です。GitHubログインができるんですね。
なので、Web Appsでデモを触ってみて、LLMでちょっとチャットができます。「社内の文章を作ってみた」みたいな場合、社内の文章でやりたいじゃないですか。そのへんの野良のデータじゃなくて、やはり手元にあるふだんから見えているものが、LLM、AIを通すとどう変わるのかをみなさん知りたいはずなんですよね。
それをワイルドに、グローバルにバッと渡すわけにはいかない。じゃあ、閉じよう、認証を入れよう、「Azure ADが」となりやすいんですが、もうAzureを立てている時点で、あなたはAzure ADのアカウントを持っていますし、なんでしたらGitHubのアカウントも持っているはずです。
App Serviceには認証と承認というメニューがあるのですが、そこにチェックボックスを入れて、何に使いますか？ というのを選ぶだけで、ここの緑色のところが差し込んで入ってきます。サイドカーとして入るみたいなかたちですね。
使う人たちは、特に意識しなくても認証という部分が手軽にできるんだよという部分でEasy Authと言われています。
Azure OpenAI Serviceのリファレンスアーキテクチャ
では、リファレンスアーキテクチャを見ていきましょう。
まず日本語ですね。日本語のリファレンスアーキテクチャとして、日本マイクロソフトの中で実は今ページができています。またここには、弊社以外のパートナーさまで実際に使ったものや、こういったいろいろな事例も含めて、今後アップロードをされていく場所があります。
今は、さまざまなユースケースに合ったものや、考え方、こういった設定は考えましょうねというのが入っています。
このあたりは後ほどダウンロードできますので、見ていただければと思います。リファレンスの利用方法、注意事項などが入っています。詳しい中身はそこまで重要なことではないので、ここでは飛ばします。
「何が書いてあるの？」というと、アレです。今日出ていた、まさに図のアイコンたちですね。まだみなさん、覚えていますよね。先ほどの復習ですよ。
青色の真ん丸のやつがそれぞれの場所にいたり、右上のところには、このピラミッド型のものが出ています。これは、先ほど説明したものを使っているんですね。さらに、雲マークのもの。これがなにかというと、「Azure OpenAI Service」のマークです。
こうやって1つずつ見ていくと違うのは、「S3」相当の「Blob Storage」と言われるものを使っていたり、データベースが入っていたり、「Redis」が付いていたりといった部分です。なので、基本的なWebアプリケーションの作りとしては、さほど変わりません。
リファレンスアーキテクチャは3種類に分かれている
これらを見た時、「うーん、なんか簡単そうだな」と思いつつ、実はリファレンスアーキテクチャは、冒頭にあったとおり、今だいたい3つに大きく分かれているなという印象を持っています。今現在ですね。今後は、もう少し整理される可能性がぜんぜんあります。
日本の資料として出ているものは、基本的に価値を中心に進めているんですね。ユースケースがメインになっています。なので、そのあたりでけっこう早くできるもので、その後に基盤を固めましょうと。
それ以外には、基盤を固めてからじっくり価値検証しましょう、がっつりセキュリティ対策などをしてからやりましょうといったものです。
あとは最後に、最近直近出ているものとしては、アーキテクチャのざっくりとした図だけでは、特定の課題がわからないという部分で、ある特定の課題にフォーカスしたリファレンスも出ています。
各リファレンスにおける共通事項と特徴的な違い
共通事項としては、ユーザーの認証。あと、OpenAIのサービスを利用したAPIのそのままのルールに近いのですが、やはりそのままエンドポイントを表に出さないように、きちんとなにかしらマスクするかたちでWebアプリケーションを入れていたり、「API Management」を入れたりなど、そういったものです。
ログの取得だったり、なにかフィルターをかけたり、AIのモデルを変えたりと、裏でいろいろ操作ができるという部分で、共通事項としていつも書かれているものは、（スライドを示して）この中に書かれているものが網羅されています。
じゃあ、どこに違いが出るかというと、もちろんユースケースは出てきますが、一番大きなところは非機能要件です。具体的に扱いたいデータの特徴ですね。機密性だったり、そもそもデータセンターにしかないとか、そういったものになります。
セキュリティの考え方もそうです。「インターネットに一切出さないんだ、全部プライベートでしたいんだ」という場合や、ネットワークのインバウンド、アウトバウンドにも制限を入れて統制を取っていきたい場合ですね。
最後の2つの部分は、ちょっと違っていて品質保証に近いものです。そもそも扱うデータが大きくてトークンが溢れてしまうとか、そもそもアクセスがたくさん来てクォータを超えてしまうとか。
あとは、そもそもの、AIというアプリができた時の品質改善へのアプローチですよね。DBに溜めてみたり、A/Bテストをやってみたり、ユニットテストを入れてみたりなど、そういったものになります。「Prompt Flow」は、まさにいい例ですね。
リファレンスアーキテクチャの活用法
GitHubの「Codespaces」を使ったものの例として、これが一番ミニマムでできます。このGitHubのところに行ってCodespacesを開いてやると、サブスクリプションとOpenAIのエンドポイントがわかっていれば、本当にその場でチャットのデモができます。
「いやいやいや、それだけじゃ飽き足らないんだ」といった場合でも、大丈夫です。ファイルのアップロードをするだけです。ファイルのアップロードをするものも追加されています。ディレクトリの中にPDFを入れるとできます。
それだけだと、あまりいいサマライズにならなかったり、ほかの文章とカニバっていてなんか変な文章になっているということが起こります。そういった場合には、どうしたらいいかというと、サマライズをやりましょう。
右と左はぜんぜん違うリファレンスアーキテクチャの図を取ってきています。左は最初に出ていたものですね。右は、最近新しく出てきたものです。サマライズの方法というのが出ています。
それ以外に、コールセンターというのも先ほど出していたのですが、コールセンターの中でも、左側はかなりライトに書かれていて、実際にやろうと思うとここまでやらないとダメだよねという部分で、CRMなどエンリッチなものもどんどん追記しています。
それだけではありません。ログだけでもこれだけ特化していっています。ログの置き方も、全部プライベートに外に一切出さないようにするという部分はどうしたらいいのかというのも入っています。
今週（※登壇当時）、一番いい例が出ていて、なにかというと、フルフルのセキュリティを入れたバージョンです。アイコンも基本的には青色のアプリケーションがあって、雲があって、DBがあって、という関係は変わりません。
じゃあ、増えているのはなにかというと、「Application Gateway」という、「ALB」みたいなものですね。それで、APIを管理する。「じゃあ、左は何？」というと、社内とAIサービスをどうやってつなぐかという部分にポイントを絞って追記されているものです。
これ、全部作る必要はないんですよ。「いやいや、ここから来るんですよ」といった場合、もう外からのアクセス前提なので、そこはもう左の奥側の分は考えなくてよくて、そこは削っていきましょうとか、そういったものができると思います。
といった部分で、駆け足ですがリファレンスアーキテクチャの部分をバッと一気に紹介しましたが、シェアする資料を一つひとつ見ていくと、「あぁ、なるほど」というのがなんとなくわかってくるかなと思っています。
今日はゴールとして、リファレンスアーキテクチャにどういうものがあって、最初の一歩を下げるためのものという部分で、中心に話させていただきました。
ちょうど、25分になりました。ご清聴いただきありがとうございました。
（会場拍手）
