Foundry の監視と可観測性を運用に落とす設定編

Microsoft Foundry の監視と可観測性に関する設定・運用編が公開されました。AI アプリの品質監視、障害対応、ログ設計に関係します。

要点

• 記事は Microsoft Foundry の監視と可観測性について、設定と運用に焦点を当てています。
• AI アプリでは、通常の可用性だけでなく、モデル応答、評価、失敗時の原因、利用者体験を運用側が追える必要があります。
• Part 2 という位置づけから、概念紹介ではなく実際の運用設定に踏み込む内容として読むのが自然です。

今回のブログ記事で語られていること

記事は、稼働率だけではAIエージェントを運用できないという前提から始まります。モデル、プロンプト、検索インデックスが変化し、本番通信でテスト時に見えなかった例外が現れるため、正確性、安全性、効率、一貫性を継続して確かめる必要があります。そのためMicrosoft Foundryは「評価・監視・トレース」を一つの運用循環として扱います。この記事は概念編に続く実務編で、Foundryの新しい画面にあるBuild、Operate、Adminを使い、Azure Monitorのアプリケーション監視リソース接続からアラート、継続評価、CI/CD、コンプライアンス、費用管理までをつなげています。

最初の必須作業は Operate > Admin > Connected resources でAzure Monitorのアプリケーション監視リソースをプロジェクトへ接続することです。ここが監視、トレース、品質表示に使う通信記録の保存・相関基盤になります。接続しただけでは不十分で、障害を調べる運用担当者が監視リソースを読める権限も必要です。接続後は Build > Agents > Monitor から本番通信の一部を継続評価します。会話エージェントなら一貫性と関連性、検索拡張生成なら根拠性と検索品質、安全性が重要な業務なら安全指標を選びます。評価は追加のモデル実行を伴うため、通信量、リスク、予算に応じてサンプリング率を決め、プロジェクトのマネージドIDへ評価実行権限を付けます。

監視画面では、品質、遅延、失敗、トークン消費、安全性の変化を並べて見ます。たとえば遅延が変わらなくても根拠性だけが低下する場合や、品質低下より先にトークン量が膨らむ場合があります。異常を見つけたら画面の数値だけで結論を出さず、OpenTelemetryのトレースでモデル呼び出し、ツール実行、検索、処理の分岐、各段階の時間とトークンを追います。独自エージェントでも同じAzure Monitorの監視リソースへ標準形式のトレースを送れば、Foundryを開発者向け画面、Azure Monitorを保存・検索・相関基盤として使えます。

トレースにはプロンプト、回答、ツール引数などの機微情報が入り得ます。内容記録を有効にする前に、保存期間、閲覧権限、個人情報や秘密情報を送らない処理を決める必要があります。異常検出後の対応はAzure Monitorのアラートとアクショングループへつなぎ、継続的な遅延増加、実行失敗の急増、異常なトークン消費、利用者へ影響する品質・安全性低下に絞って通知します。Foundryで原因候補を見つけ、既存のSRE運用で担当者への通知や自動処理を実行する役割分担です。

品質評価は本番後だけでなくCI/CDにも組み込みます。開発、リリース判定、本番監視で同じ評価器と基準値を使い、基準を下回った変更を昇格させない構成です。運用後は Operate > Compliance で要求するガードレールと実際の配備設定の差を確認し、Defender for Cloudでセキュリティ状態と脅威、Microsoft Purviewでプロンプトや回答の分類・監査を既存の統制へ統合します。利用できる機能や導入手順は契約、権限、テナントによって異なる点には注意が必要です。

費用も品質と別には扱えません。Operate > Overview で全体のトークンと費用傾向、Operate > Assets で大量消費・不調な資産、Operate > Quota で容量とスロットリングの兆候を確認します。Foundryの監視機能自体に追加プラットフォーム料金はないとしていますが、Azure Monitor側の保存・保持と継続評価のモデル実行には費用が発生します。すべてを記録・評価するのではなく、利用者被害や運用負荷へ直結する信号を選び、品質、安全性、費用を同じ運用会議で判断することがこの記事の結論です。

今回のブログ記事が関係する人

Microsoft Foundryの運用担当、SRE、AIアプリ開発者、監査・品質管理チームに関係します。テスト時の評価は行っていても、本番品質のサンプリング、トレース、アラート、リリース判定が別々になっている組織には特に有用です。

どう読むと価値があるか

Azure Monitorの監視リソース接続が出発点ですが、重要なのは評価・監視・トレースを分断しないことです。異常な指標から該当トレースへ進み、Azure Monitorで通知し、同じ評価基準をCI/CDへ戻せるかを確認します。豊富なトレースと機微情報の過剰保存は表裏一体です。

実務へのつながり

まず1つのエージェントでAzure Monitorの監視リソース、継続評価、トレースを接続し、品質低下を意図的に起こした検証からアラート通知まで追います。プロンプトやツール引数に個人情報が残らないこと、運用担当者だけが読めること、保存期間と評価費用が予算内に収まることも同時に確認します。

結局、今回のブログ記事をどう読むべきか

この記事が示す完成形は、監視画面を増やすことではありません。品質低下を検出し、トレースで原因を調べ、既存の運用経路へ通知し、同じ評価基準で次の不良変更を止める循環です。そこへコンプライアンスと費用を加えることで、エージェントが本番で正しく動き続けていると説明できるようになります。