はじめに

昨今、生成AIが急速な進化を遂げるとともに世の中に浸透しつつあり、生成AIサービスを導入する企業も増えています。主要クラウドベンダ各社が生成AI基盤の提供を開始していますが、中でもMicrosoftとOpenAIのパートナーシップによって実現された、Azure上で提供されるOpenAIのREST APIサービスである「Azure OpenAI Service」が注目されています。Azure OpenAI Serviceの大きな特長の1つは、入力データが言語モデルそのものの学習に再利用されないため、企業のデータプライバシーを保護できる点です。

しかしながら生成AIをビジネスに活用するには、単にモデルを利用すればよいわけではなく、生成AI基盤の導入と運用それぞれにハードルがあります。導入の際には、データプライバシーの確保やお客様環境との接続ネットワークなどを考慮した構築が必要ですし、運用開始後も生成AI基盤特有の監視要件やシステム全体の統合運用管理の考慮が必要となります。

このうち生成AI基盤の導入に関しては、当社がAzure OpenAI Serviceの構築サービスを提供しており、OpenAIサービスのセキュアな環境を手間なくご利用いただけます。導入の課題解決についてはそちらに譲るとして、今回は生成AI基盤の運用管理、とりわけ監視にフォーカスして、Azure OpenAI Serviceの監視や統合運用管理のポイントをお伝えします。後半では、統合運用管理ソフトウェア「Hinemos」を用いて、Azure OpenAI Serviceの具体的な監視設定例をご紹介します。

生成AI基盤に必要な監視とは？

生成AI基盤を運用していくにあたってどのような監視をすべきなのか、一般に生成AI基盤において必要となる監視要件と、Azure OpenAI Serviceの場合の監視内容について解説します。

1. 稼働状況の監視

あたりまえと思われるかもしれませんが、生成AIサービスを利用するためには、AI基盤が正常に稼働していることが前提となります。クラウドサービスとして提供されるインフラであっても、障害が起こり得るということは認識しておく必要があります。システムで障害が発生した際に、それがクラウド側の問題なのか利用者側の問題なのかを切り分けることが早期解決につながるので、クラウドのサービス正常性も監視しておく必要があるのです。

AzureにおいてはAzure Portalの「サービス正常性（Service Health）」を監視します。各サービスに関する問題のほか、今後の計画メンテナンス等についても知ることができます。なお「Azureの状態」ページでも簡易的にサービス可用性についての情報を取得できますが、サービス正常性の方がパーソナライズされていたり通知を受け取れたりするためAzureではこちらがお勧めされています。

2. キャパシティの監視

クラウドサービスでは「クォータ」と呼ばれる制限が定められている場合があります。これは予期せぬ消費のリスクから顧客を守るために、クラウド側で使用量の上限が設定されているものです。
生成AIサービスに課されるクォータ制限としては、1分あたりのトークン数（TPM：Tokens Per Minute）や1分あたりの呼び出し数（RPM：Requests Per Minute）の上限が定められていることが多いです。トークンとは、テキストをAIモデルが理解できる形式に分割した単位を指します（日本語は英語に比べてトークン数が大きくなる傾向があります）。上限を超えた分はサービスを利用できなくなってしまうため、これらを監視し使用量が上限に迫っている場合には、モデルの見直しやクォータの引き上げ要求などの対策を検討します。
なお、トークン数は従量課金の単位でもあるため、サービス可用性の観点とコストの観点の両面で監視する必要があります。

Azure OpenAI Serviceのクォータ制限は、リージョン毎、モデル毎にTPMの上限が定められており、この範囲内でモデルの各デプロイに割り当てることができます。TPMのクォータはAzure OpenAI ServiceのWebベースのインターフェースである「Azure Open Studio」で確認でき、RPMはTPMに連動して1000TPMあたり6RPMに自動的に設定されます。
メトリックとしては、処理済み推論トークン（TokenTransaction）、Azure OpenAI 要求（Azure OpenAI Requests）がそれぞれTPMおよびRPMにあたるかと思います。

3. セキュリティの監視

前提として、Azure OpenAI Serviceの場合には入力データがモデル自体の学習に利用されないことは冒頭で述べたとおりです。またユーザ認証やアクセス制限を組み込んだセキュアな環境構築を行うことが重要です。そのうえで、セキュリティ調査のためにログを取得し、不正なアクセスやAPI利用、モデルとの入出力内容を追跡できるようにします。

Azure OpenAI Serviceのログは診断設定で取得できますが、呼び出し元IPアドレスややりとりの中身などの詳細は記録されないことに注意が必要です。システム構成に依りますが、App Service^[1]でアクセスログを取ったり、API Management^[2]を経由する構成であればモデルとの入出力を含めたログを取ったりできるので、ログ取得を考慮して構築するのがよいでしょう。

4. 課金状況の監視

API経由での生成AIモデルの料金体系は、利用量に応じた従量課金制であることが多く、「2. キャパシティの監視」でも登場したトークン数に応じて課金されることが一般的です。トークンの入力数および出力数あたりの単価は生成AIモデル毎に異なります。せっかく生成AIを導入して作業効率化を図っても運用コストが嵩んでは本末転倒ですし、予期せぬ消費に気づけるよう、継続的にコストを監視することは重要です。

Azure OpenAI Serviceではリソース毎にコストを確認できます。「コスト分析」でグループ化をMeterに設定すると、従量課金の測定量（モデル、入力/出力トークン）毎にコストの内訳を確認できます。

図1：Azure OpenAI Serviceのコスト分析画面

統合運用管理の必要性

ここまで生成AI基盤の監視要件について見てきました。クラウド大手であれば監視サービスを提供しているので、それで賄えると思われるかもしれません。しかし実際には生成AI基盤のみを利用する場合は少なく、IaaSやPaaSを含む様々なクラウドサービスで業務システムが構成されていることが多いかと思います。

クラウドが提供している監視サービスではクラウド側の責任範囲については監視できますが、利用者側でOS上に導入したミドルウェアや業務アプリケーションの監視は別途検討する必要があります。また、業務カレンダに従った監視制御やデータの長期保存など、システム独自の運用要件がある場合にも、クラウドの監視サービスでは満たせない場合があります。
またシステム運用では、監視だけでなくジョブ管理による業務自動化も不可欠です。さらにクラウドではリソース制御によるコスト最適化も図る必要があります。
これらをそれぞれ別のツールで管理すると運用が煩雑になってしまいます。そのため効率的な運用のためには、統合運用管理のしくみが必要となるのです。

HinemosでのAzure OpenAI Serviceの監視設定例

上述のAzure OpenAI Serviceの監視要件は、統合運用管理ソフトウェア「Hinemos」で実現できます。Azureとの連携を自前で作りこんで維持するとなると大変ですが、Hinemosはクラウド管理機能を持っているため容易に設定できます。ここではHinemosでの設定例を通じて、Azure OpenAI Serviceを監視する方法を紹介します。

0. 準備：HinemosとAzureの連携

まずはHinemosとAzureを連携します。Hinemosは「サービスプリンシパル」でAzureにアクセスします。サービスプリンシパルとは、システムがAzureを操作するためのアカウントのようなものです。Azure上でサービスプリンシパルを作成し必要な権限を付与したうえで、Hinemosにサービスプリンシパルの情報を登録します。

Azure Portalからサービスプリンシパルを作成する場合は、Entra ID^[3]からアプリの登録を行うことでサービスプリンシパルが自動作成されます。認証に使うのでクライアントシークレットも作成しておきます。その後、必要権限を含むロールを作成しサービスプリンシパルに割り当てます。クラウド管理機能のすべての機能を利用するためには、ロール割り当て対象のリソースとしてサブスクリプションのスコープに割り当てる必要があることに注意です。

Azureでサービスプリンシパルを作成したら、Hinemosにクラウドアカウントとして登録すれば、連携は完了です。

1. 稼働状況の監視

Azureサービスの稼働状況は、Hinemosでは以下の流れで監視します。

Azureで関数アプリとサービス正常性アラートを作成します。関数アプリでWebhookを行う関数を作成し、トラップ送信先としてHinemosマネージャの待ち受けIPアドレスとポートを指定します（HinemosマネージャはAzureから接続可能である必要があります）。
次にサービス正常性からサービス正常性アラートを作成します。デフォルトではすべてのサービスが選択されているので、監視したいサービス（Azure OpenAI Serviceのほか、利用しているサービス）を選択します。アクションとしてWebhookを選択し、関数アプリを呼び出すURLを指定します。

図2：サービス正常性アラートの設定

これでAzureからHinemosへアラートを飛ばす準備ができました。Hinemosのカスタムトラップ監視の設定はクラウド管理機能をインストールすると作成されるため、Hinemos側では特に追加設定なしでこの監視設定からAzureからのトラップを受け取れます。

2. キャパシティの監視

Azure OpenAI ServiceのメトリックをHinemosのリソース監視で監視します。リソース監視の設定は以下の流れで行います。

クラウド管理機能インストール時点ではAzure OpenAI Serviceのメトリックは登録されていないため、Hinemosのリソース監視マスタへの追加が必要です。マスタ追加用のSQLサンプルが用意されているため、これをもとにメトリックの情報等を書き換えます。メトリックのREST API名などの必要項目はAzureドキュメントで確認します。今回はAzure OpenAI 要求（Azure OpenAI Requests）を登録してみます。

対象のメトリックを監視項目として追加できたら、監視対象ノードとリソース監視設定を作成します。監視対象ノードのノード変数として、Azure OpenAI ServiceのリソースIDを設定します。これによって監視対象のリソースを特定します。IPアドレスは必須項目ですが利用しない項目なので適当でOKです。
リソース監視設定は、先ほど登録したメトリックの監視項目を選択します。監視間隔をメトリックのタイムグレイン（サンプリング間隔）と合わせないとうまく監視結果が取得できないので注意です。

図3：Azure Portalでの「Azure OpenAI 要求」メトリックの値

図4：Hinemosでの監視設定と監視結果

3. セキュリティの監視

Azure OpenAI Serviceや関連サービスのログの監視は、Hinemosではクラウドログ監視を使います。クラウドログ監視はAzureのLog Analytics ワークスペース上のテーブルのカラムに格納される文字列を監視します。Hinemosエージェントが定期的にAzureにログを取得しにいくポーリング型の監視のため、必ずしもログ出力直後に検知しないことには留意が必要です。

今回のAzure検証環境はApp ServiceからAzure OpenAI Serviceを呼び出している構成のため、これらのログを監視してみます。Azure Portalでそれぞれのリソースで診断設定を作成し、Log Analytics ワークスペースへ送信する設定を行います。Log Analyticsワークスペースのログ画面にログが格納されているテーブルが表示されるので、テーブル名でクエリを実行すればテーブル内のログデータを確認できます。

例えばApp ServiceのIPSecurity Audit logs はAppServiceIPSecAuditLogsテーブルに格納され、アクセス元IPアドレスやアクセス制限の結果等が記録されます。Azure OpenAI ServiceのRequest and Response Logsでは、AzureDiagnosticsテーブルのproperties_sカラムでどの生成AIのモデルを利用したか等が分かります。

Log Analyticsワークスペースのテーブルに格納されたログを、Hinemosのクラウドログ監視を作成して監視します。監視実行スコープには、Azureに到達できるHinemosエージェントが含まれるスコープを指定します。Log Analyticsワークスペース名やテーブル名、カラム名等を指定し、監視対象文字列を設定します。

図5：Hinemosの監視設定と監視結果。IPアドレスでのアクセス拒否を監視

なお、モデルとの入出力内容のログを取得するにはAPI Managementを経由する構成とし、API Managementの診断設定で「Logs related to ApiManagement Gateway」を指定することで、API Managementが中継するやりとりのログが記録されます（設定でNumber of payload bytes to logの値を設定しないと、入出力内容が記録されないので注意）。ログはApiManagementGatewayLogsテーブルに格納されます。

4. 課金状況の監視

Azure OpenAI Serviceの課金状況の監視は、Hinemosでは課金管理機能で把握、確認します。クラウド課金詳細監視でしきい値での通知も可能です。Hinemosでは、リソースIDをもとにリソースを特定し、Resource Usage APIおよびRateCard APIを用いて課金情報を算出しています。

Azure Portalからサブスクリプションの購入日や通貨等の情報を確認し（課金情報の取得にサブスクリプション単位での権限が必要なため、サービスプリンシパルへのサブスクリプション単位でのロール割り当てがここで効いてきます）、Hinemosで課金情報の収集設定を行います。

おわりに

生成AI基盤（とりわけAzure OpenAI Service）の監視と統合運用管理のポイントについてお伝えしました。生成AI基盤を含むシステム全体を効率的に運用していくためには、個々の監視要件と実現手段を検討したうえで、それらを一元的に管理するしくみをつくることが大切です。
今回は主にAzure OpenAI Serviceにフォーカスしてご紹介しましたが、他のAIサービスについても同様の観点が必要となるかと思います。他のクラウド上の生成AI基盤についてもHinemosで運用管理が可能です。

注釈