ai-agents-for-beginners

本番環境におけるAIエージェント：観測性と評価

AI Agents in Production

AIエージェントが試験的なプロトタイプから実際のアプリケーションへと移行する中で、その動作を理解し、性能を監視し、出力を体系的に評価する能力が重要になります。

学習目標

本レッスンを修了すると、以下のことを理解できるようになります：

目標は、「ブラックボックス」のようなエージェントを透明性があり、管理可能かつ信頼できるシステムへと変えるための知識を提供することです。

注: 安全かつ信頼できるAIエージェントを展開することが重要です。 Building Trustworthy AI Agents のレッスンも参照してください。

トレースとスパン

Langfuse や Microsoft Foundry などの観測性ツールは、通常、エージェントの実行をトレースとスパンで表現します。

Trace tree in Langfuse

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

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

AIエージェントを本番環境に移行することは、新たな課題や要件を伴います。観測性は「あったら良い」ものではなく、重要な能力です：

追跡すべき主要指標

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

観測性ツールがモニターする主な指標を以下に示します：

レイテンシー: エージェントの応答速度はどうか？長い待機時間はユーザー体験に悪影響を及ぼします。タスクや個別のステップのレイテンシーをエージェント実行のトレースで測定すべきです。例えば、モデル呼び出しに合計20秒かかるエージェントは、高速なモデルの使用や並列実行で高速化可能です。

コスト: エージェント実行あたりの費用はいくらか？AIエージェントはトークン単位のLLM呼び出しや外部APIに依存しがちで、頻繁なツール使用や複数のプロンプトはコストを急増させます。例えば、品質向上のために5回もLLMを呼び出す場合、そのコストが妥当か、呼び出し回数を減らすか、より安価なモデル利用の検討が必要です。リアルタイム監視で予期しない急増（バグでAPIループが増加など）も検知できます。

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

ユーザーフィードバック: 直接的なユーザー評価は貴重な洞察をもたらします。明示的評価（👍いいね/👎バッド, ⭐1-5スター）やテキストコメントが含まれます。一貫して否定的なフィードバックは、エージェントが期待通りに動作していない兆候です。

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

正確性: エージェントが正しいまたは望ましい出力をどの程度頻繁に生成しているか？正確性の定義は問題解決の正誤、情報検索の精度、ユーザー満足度など異なります。まず成功の定義を設定し、自動チェック、評価スコア、タスク完了ラベルで追跡します。例：トレースを「成功」か「失敗」にマークするなど。

自動評価指標: 自動評価も設定可能です。例えば、LLMを使ってエージェントの出力が役立つか、正確かなどをスコア化します。エージェントのさまざまな側面を評価するオープンソースライブラリもあります。例：RAGAS（RAGエージェント向け）やLLM Guard（有害言語やプロンプトインジェクション検出）。

実際には、これらの指標の組み合わせがAIエージェントの健全性を最も網羅的にカバーします。本章の 例のノートブック で実際の例を示しますが、まずは典型的な評価ワークフローを学びましょう。

エージェントの計測設定

トレースデータを収集するにはコードに計測を組み込む必要があります。目標は、エージェントコードがトレースや指標を発行し、観測プラットフォームで取得・処理・可視化できるようにすることです。

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種類があります。両方とも価値があり、補完し合います。通常はオフライン評価から始めます。これはエージェントを展開する前の最低限のステップです。

オフライン評価

Dataset items in Langfuse

これは制御された環境でエージェントを評価するもので、通常はテスト用データセットを使い、ライブのユーザー問い合わせは含みません。期待される出力や正しい動作が既知のキュレーションされたデータセットを用いてエージェントを実行します。

例えば、数学の文章題エージェントを作った場合、100問の答えが分かっている テストデータセット を使います。オフライン評価は開発中に実施し（CI/CDパイプラインに組み込むことも可能）、改善や劣化防止をチェックします。利点は再現可能で、正解があるため正確な精度指標を得られることです。ユーザー問い合わせをシミュレートし理想回答と比較したり、自動評価指標を利用することもあります。

オフライン評価の課題は、テストデータセットを包括的かつ関連性のある状態に保つことです。固定のテストセットで良好でも、本番では非常に異なる問い合わせに遭遇する可能性があります。そのため、新しい境界ケースや実世界シナリオを反映した例を定期的に追加すべきです。小規模な「スモークテスト」と大規模な評価セットを組み合わせることが有効です：小規模は迅速なチェック用、大規模は広範な性能指標用。

オンライン評価

Observability metrics overview

これはライブの実際の使用環境、つまり本番でエージェントを評価することです。実際のユーザーとのやり取りにおけるエージェントの性能を継続的に監視し、成果を分析します。

例えば、成功率やユーザー満足度スコアなどをライブトラフィックで追跡します。オンライン評価の利点は、実験室では予期できなかった事象も捉えられることです。例えば、モデルのドリフト（入力パターンの変化による性能劣化）やテストデータになかった異常問い合わせを検出できます。本番環境での実際の振る舞いをリアルに把握可能です。

オンライン評価には、前述の暗黙的・明示的ユーザーフィードバックの収集や、シャドウテストやA/Bテスト（新バージョンを並行稼働させ旧バージョンと比較）の実施も含まれます。課題はライブインタラクションに対して信頼性のあるラベルやスコアを得るのが難しいことです。ユーザーフィードバックや下流の指標（ユーザーが結果をクリックしたかどうかなど）に依存することがあります。

併用

オンライン評価とオフライン評価は排他的ではなく、非常に補完的です。オンラインモニタリングで得られたインサイト（エージェントが苦手な新種の問い合わせ）を用いてオフラインのテストデータセットを強化できます。逆に、オフラインテストで良好なエージェントはより自信を持って本番に配備し、オンラインで監視できます。

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

オフライン評価 -> 展開 -> オンライン監視 -> 新しい失敗例収集 -> オフラインデータに追加 -> エージェント改良 -> 繰り返し。

よくある課題

AIエージェントを本番に展開するときに直面しやすい課題とその解決策を示します：

課題 解決策の例
AIエージェントが一貫してタスクを遂行しない - エージェントに与えるプロンプトを改善し、目的を明確にする。
- タスクを細分化し、複数エージェントで処理する方法を検討。
AIエージェントが無限ループに陥る - 明確な終了条件を設定し、処理の停止を認識させる。
- 推論や計画を要する複雑タスクには、推論特化の大規模モデルを使用。
AIエージェントのツール呼び出しがうまく機能しない - ツールの出力をエージェント外でテスト・検証。
- パラメータ、プロンプト、ツール名の定義を改善。
複数エージェントシステムの挙動が安定しない - 各エージェントへのプロンプトを見直し、特異的かつ区別可能にする。
- 「ルーティング」やコントローラー的エージェントを使い適切なエージェントを選定する階層システムを構築。

観測性を導入すると、多くの課題がより効果的に検出可能となります。前述のトレースや指標は、エージェントのワークフローのどの部分で問題が発生しているか正確に特定でき、デバッグや最適化が大幅に効率化されます。

コスト管理

AIエージェントを本番環境に展開する際のコスト管理のためのいくつかの戦略を紹介します：

小さいモデルの使用： 小型言語モデル（SLM）は特定のエージェント的なユースケースで良好な性能を発揮し、コストを大幅に削減できます。前述のように、評価システムを構築して大きなモデルとの性能比較を行うことが、SLMがあなたのユースケースでどれだけうまく機能するかを理解する最善の方法です。意図分類やパラメータ抽出のようなより簡単なタスクにはSLMを利用し、複雑な推論にはより大きなモデルを使うことを検討してください。

ルーターモデルの使用： 同様の戦略として、多様なモデルやサイズを利用する方法があります。複雑さに応じてリクエストを最適なモデルにルーティングするために、LLM/SLMやサーバーレス関数を使用できます。これによりコストを削減しつつ、適切なタスクでの性能も保証されます。例えば、単純なクエリはより小型で高速なモデルにルーティングし、複雑な推論タスクには高価な大規模モデルのみを使用します。

レスポンスのキャッシュ： 共通するリクエストやタスクを特定して、エージェントシステムに渡す前にレスポンスを提供することは、類似したリクエストの量を減らす良い方法です。より基本的なAIモデルを使って、リクエストがキャッシュ済みのものとどれくらい類似しているかを判別するフローを実装することもできます。この戦略は、よくある質問や共通のワークフローのコストを大幅に削減できます。

実際にどのように機能するか見てみましょう

このセクションのサンプルノートブックでは、オブザーバビリティツールを使ってエージェントの監視と評価を行う例を見ていきます。

AIエージェントの本番運用についてさらに質問がありますか？

他の学習者と交流し、オフィスアワーに参加し、AIエージェントに関する質問に答えてもらうには、Microsoft Foundry Discordに参加してください。

前のレッスン

メタ認知デザインパターン

次のレッスン

エージェントプロトコル

免責事項： 本書類は AI 翻訳サービス Co-op Translator を使用して翻訳されています。正確性を期していますが、自動翻訳には誤りや不正確な部分が含まれる可能性があることをご承知おきください。原文の原語版が正式な情報源とみなされるべきです。重要な情報については、専門の人間による翻訳を推奨します。本翻訳の利用により生じたいかなる誤解や解釈違いについても、当方は責任を負いかねます。

This site is open source. Improve this page.