ai-agents-for-beginners

AIエージェントの本番運用：可観測性と評価

AIエージェントの本番運用

AIエージェントが実験的プロトタイプから実世界のアプリケーションへ移行するにつれて、その振る舞いを理解し、性能を監視し、出力を体系的に評価する能力が重要になります。

Learning Goals

After completing this lesson, you will know how to/understand:

目的は、あなたの「ブラックボックス」なエージェントを透過的で管理しやすく、信頼できるシステムへと変えるための知識を提供することです。

Note: It is important to deploy AI Agents that are safe and trustworthy. Check out the 信頼できるAIエージェントの構築 lesson as well.

トレースとスパン

可観測性ツール（例: Langfuse や Microsoft Foundry）は、通常エージェントの実行をトレースとスパンとして表現します。

Langfuseのトレースツリー

可観測性がないと、AIエージェントは「ブラックボックス」のように感じられ、内部状態や推論過程が不透明であるため、問題の診断や性能最適化が難しくなります。可観測性があれば、エージェントは「ガラス箱」になり、透明性を提供して信頼構築や意図通りに動作していることの確認に不可欠です。

本番環境で可観測性が重要な理由

AIエージェントを本番環境へ移行すると、新たな課題や要件が発生します。可観測性は「あると良いもの」ではなく、重要な機能です。

追跡すべき主要指標

エージェントの振る舞いを監視し理解するために、さまざまな指標やシグナルを追跡する必要があります。具体的な指標はエージェントの目的によって異なりますが、普遍的に重要なものがいくつかあります。

ここでは、可観測性ツールが監視する最も一般的な指標のいくつかを示します:

レイテンシ（待ち時間）: エージェントはどれくらい速く応答するか？長い待ち時間はユーザー体験に悪影響を与えます。エージェント実行のトレースによってタスクや個々のステップのレイテンシを測定するべきです。例えば、全てのモデル呼び出しに20秒かかるエージェントは、より高速なモデルを使うか、モデル呼び出しを並列化することで加速できます。

コスト: エージェント実行あたりの費用はいくらか？AIエージェントはトークン単位や外部API呼び出しで課金されるLLM呼び出しに依存します。頻繁なツール使用や複数のプロンプトはコストを急速に増加させる可能性があります。例えば、エージェントが品質向上がわずかなのにLLMを5回呼び出している場合、そのコストが正当化されるか、呼び出し回数を減らすか、安価なモデルを使えるかを評価する必要があります。リアルタイムの監視は、予期しないスパイク（例: バグによる過剰なAPIループなど）を特定するのにも役立ちます。

リクエストエラー: エージェントが失敗したリクエストはいくつか？これにはAPIエラーやツール呼び出しの失敗が含まれます。本番環境でこれらに対してエージェントをより堅牢にするために、フォールバックやリトライを設定できます。例: LLMプロバイダAがダウンした場合、バックアップとしてLLMプロバイダBに切り替える。

ユーザーフィードバック: 直接的なユーザー評価を導入すると貴重な洞察が得られます。これには明示的な評価（👍好評価/👎低評価、⭐1-5）やテキストによるコメントが含まれます。継続的な否定的フィードバックは、エージェントが期待通りに動作していない兆候であるためアラートとなるべきです。

暗黙のユーザーフィードバック: 明示的な評価がなくても、ユーザーの挙動は間接的なフィードバックを提供します。これには即時の質問の言い換え、繰り返しのクエリ、再試行ボタンのクリックなどが含まれます。例: ユーザーが同じ質問を繰り返し行う場合、それはエージェントが期待通りに動作していないサインです。

精度: エージェントはどれくらいの頻度で正しいまたは望ましい出力を生成するか？精度の定義は（問題解決の正確性、情報検索の正確さ、ユーザー満足度など）ケースによって異なります。まず、エージェントにとって成功とは何かを定義することが重要です。自動チェック、評価スコア、タスク完了ラベルなどで精度を追跡できます。例えば、トレースに「成功」または「失敗」とマークするなどです。

自動評価メトリクス: 自動評価を設定することもできます。例えば、LLMを使ってエージェントの出力が有用か、正確かどうかをスコアリングできます。エージェントのさまざまな側面をスコアリングするのに役立つオープンソースライブラリもいくつかあります。例: RAGAS はRAGエージェント向け、LLM Guard は有害な言語やプロンプトインジェクションを検出するためのものです。

実務では、これらの指標の組み合わせがエージェントの健全性を最もよくカバーします。この章のサンプルノートブックでは、これらの指標が実際の例でどのように見えるかを示しますが、まずは典型的な評価ワークフローを学びましょう。

エージェントに計測を組み込む

トレースデータを収集するには、コードに計測（インストルメンテーション）を組み込む必要があります。目的は、エージェントコードが可観測性プラットフォームによってキャプチャ、処理、可視化できるトレースやメトリクスを出力するようにすることです。

OpenTelemetry (OTel): OpenTelemetry はLLMの可観測性に関する業界標準として浮上しています。テレメトリデータを生成、収集、エクスポートするためのAPI、SDK、ツールのセットを提供します。

既存のエージェントフレームワークをラップし、OpenTelemetryスパンを可観測性ツールに簡単にエクスポートできる多くのインストルメンテーションライブラリがあります。Microsoft Agent FrameworkはOpenTelemetryとネイティブに統合されています。以下はMAFエージェントに計測を組み込む例です:

from agent_framework.observability import get_tracer, get_meter

tracer = get_tracer()
meter = get_meter()

with tracer.start_as_current_span("agent_run"):
    # エージェントの実行は自動的にトレースされます
    pass

この章のサンプルノートブックでは、MAFエージェントに計測を組み込む方法を実演します。

手動スパン作成: インストルメンテーションライブラリは良い基盤を提供しますが、より詳細またはカスタム情報が必要な場合がしばしばあります。カスタムアプリケーションロジックを追加するためにスパンを手動で作成できます。さらに重要なのは、自動的または手動で作成したスパンにカスタム属性（タグやメタデータとも呼ばれる）で情報を付加できることです。これらの属性には、user_id、session_id、model_version のようなビジネス固有のデータ、中間計算結果、あるいはデバッグや分析に役立つ任意のコンテキストが含まれます。

Langfuse Python SDK を使ってトレースとスパンを手動で作成する例:

from langfuse import get_client
 
langfuse = get_client()
 
span = langfuse.start_span(name="my-span")
 
span.end()

エージェント評価

可観測性は指標を提供しますが、評価はそのデータを分析（およびテストを実施）して、AIエージェントがどれだけうまく機能しているか、どのように改善できるかを判断するプロセスです。言い換えれば、トレースとメトリクスを取得したら、それらを使ってエージェントを評価し、意思決定を行うにはどうすればよいかということです。

定期的な評価は重要です。AIエージェントは非決定論的であり（アップデートやモデル挙動のドリフトを通じて）進化することが多いため、評価がなければ「スマートなエージェント」が本当にうまく機能しているか、あるいは性能が低下しているかを知ることができません。

エージェント評価には、オンライン評価とオフライン評価の2つのカテゴリがあります。どちらも価値があり、互いに補完します。通常はオフライン評価から始めます。これはエージェントをデプロイする前に最低限行うべきステップです。

オフライン評価

Langfuseのデータセット項目

これは制御された環境、通常はライブのユーザー問い合わせではないテストデータセットを使ってエージェントを評価することを指します。期待される出力や正しい挙動がわかっているキュレートされたデータセットを使い、エージェントを実行します。

例えば、数学の文章題エージェントを作ったなら、既知の解答がある100問のテストデータセットを用意するかもしれません。オフライン評価は開発中に行われることが多く（CI/CDパイプラインの一部にもなり得ます）、改善の確認や回帰防止に使います。利点は、再現可能であり、正解（グラウンドトゥルース）があるため明確な精度指標が得られることです。ユーザーのクエリをシミュレートしてエージェントの応答を理想回答と比較したり、前述の自動メトリクスを使ったりすることもできます。

オフライン評価の主な課題は、テストデータセットが包括的で関連性を保つことを確保することです—固定されたテストセットでうまく機能していても、本番では非常に異なるクエリに遭遇する可能性があります。したがって、テストセットを新しいエッジケースや実世界のシナリオを反映する例で更新し続けるべきです。小さな「スモークテスト」ケースと大規模な評価セットを混ぜるのが有用です: 小さいセットは迅速なチェック、大きいセットは広範な性能指標のために使います。

オンライン評価

観測性メトリクスの概要

これは、本番での実際の使用中、つまりライブ環境でエージェントを評価することを指します。オンライン評価は実際のユーザーインタラクションでのエージェントの性能を継続的に監視・分析することを含みます。

例えば、成功率、ユーザー満足度スコア、その他のメトリクスをライブトラフィックで追跡するかもしれません。オンライン評価の利点は、ラボ環境では予測できない事象を捉えられることです—（入力パターンの変化に伴う）モデルドリフトを観察したり、テストデータに含まれていなかった予期せぬクエリや状況を検出できます。本番でのエージェントの振る舞いをありのままに把握できます。

オンライン評価では、前述のように暗黙的および明示的なユーザーフィードバックを収集したり、シャドウテストやA/Bテスト（新しいバージョンのエージェントを並列実行して比較する）を実行したりすることがよくあります。課題は、ライブのインタラクションに対して信頼できるラベルやスコアを取得するのが難しいことです—ユーザーフィードバックや下流のメトリクス（例: ユーザーが結果をクリックしたかどうか）に頼ることになる場合があります。

両者の組み合わせ

オンライン評価とオフライン評価は相互排他的ではなく、非常に補完的です。オンライン監視から得られる洞察（例: エージェントが苦手とする新しい種類のユーザークエリ）は、オフラインのテストデータセットを拡充・改善するのに使えます。逆に、オフラインテストでうまく機能するエージェントは、オンラインでより自信を持ってデプロイして監視できます。

多くのチームは以下のループを採用します:

オフラインで評価 -> デプロイ -> オンラインで監視 -> 新しい失敗ケースを収集 -> オフラインデータセットに追加 -> エージェントを改善 -> 繰り返す.

よくある問題

AIエージェントを本番に展開すると、さまざまな課題に直面する可能性があります。ここでは一般的な問題とその潜在的な解決策を示します:

問題 考えられる解決策
AIエージェントがタスクを一貫して実行しない - AIエージェントに与えるプロンプトを改善し、目的を明確にする。
- タスクをサブタスクに分割して複数のエージェントで処理させることで助けになる箇所を特定する。
AIエージェントがループに陥る - エージェントがいつプロセスを終了すべきかを明確にする終了条件を用意する。
- 推論と計画が必要な複雑なタスクには、推論タスクに特化したより大きなモデルを使用する。
AIエージェントのツール呼び出しのパフォーマンスが良くない - エージェントシステム外でツールの出力をテストし検証する。
- ツールのパラメータ、プロンプト、名称を改善する。
マルチエージェントシステムが一貫して機能しない - 各エージェントに与えるプロンプトを具体的かつ相互に区別されるように改善する。
- どのエージェントが適切かを判断する「ルーティング」やコントローラーエージェントを用いた階層的システムを構築する。

これらの問題の多くは、可観測性があればより効果的に特定できます。前述したトレースとメトリクスは、エージェントワークフローのどの部分で問題が発生しているかを特定するのに役立ち、デバッグや最適化を大幅に効率化します。

コスト管理

Here are some strategies to manage the costs of deploying AI agents to production:

Using Smaller Models: 小規模言語モデル（SLMs）は特定のエージェント用途でうまく機能し、コストを大幅に削減できます。前述したように、評価システムを構築して大規模モデルと性能を比較・判定することが、SLMがあなたのユースケースでどれほど有効かを理解する最良の方法です。意図分類やパラメータ抽出のようなより簡単なタスクにはSLMsを検討し、複雑な推論には大規模モデルを割り当ててください。

Using a Router Model: 類似の戦略として、さまざまなモデルやサイズを組み合わせて使用する方法があります。LLM/SLMやサーバーレス関数を使って、リクエストの複雑さに応じて最適なモデルへルーティングすることができます。これによりコストを削減しつつ、適切なタスクでの性能を確保できます。たとえば、単純なクエリはより小さく高速なモデルにルーティングし、複雑な推論には高価な大規模モデルのみを使用する、という具合です。

Caching Responses: 共通のリクエストやタスクを特定し、それらをエージェント型システムを経由する前に応答を提供することで、類似リクエストの量を減らすことができます。より基本的なAIモデルを使って、あるリクエストがキャッシュされたリクエストとどれほど類似しているかを判定するフローを実装することも可能です。この戦略は、頻繁に尋ねられる質問や共通のワークフローに対するコストを大幅に削減できます。

Lets see how this works in practice

In the example notebook of this section, we’ll see examples of how we can use observability tools to monitor and evaluate our agent.

Got More Questions about AI Agents in Production?

Join the Microsoft Foundry Discord to meet with other learners, attend office hours and get your AI Agents questions answered.

Previous Lesson

Metacognition Design Pattern

Next Lesson

Agentic Protocols

免責事項: この文書はAI翻訳サービス「Co-op Translator」（https://github.com/Azure/co-op-translator）を使用して翻訳されました。正確性には努めておりますが、自動翻訳には誤りや不正確な表現が含まれる場合があることをご留意ください。原文（原言語で作成された文書）が正式な正本と見なされます。重要な情報については、専門の人間による翻訳をお勧めします。本翻訳の使用により生じたいかなる誤解や誤った解釈についても、当方は責任を負いません。

This site is open source. Improve this page.