この記事はRoyce FuとALEXANDRU-ADRIAN BirzuによるAI Agent Observability: Understand How AI Agents Behave in Gen AI Applications and Ecosystemsの日本語翻訳版記事です。

AIエージェントを導入するうえで難しいのは、印象的なデモを1つ動かすことではありません。本当に難しいのは、エージェントが不可解な判断を下し、何の警告もないまま想定を大幅に超えるトークンを消費し、いくつかのツール呼び出しを20回も再試行し、スキルをループ状に読み込み続け、最終的に誤った文書を取得し、機密データにアクセスしたにもかかわらず自信満々の回答を返したあとで、何が起きたのかを説明することです。

従来のアプリケーション監視では、APIの応答が遅かったか、エンドポイントで障害が発生したか、データベースクエリがタイムアウトしたかを把握できます。これらは今でも重要です。しかし、エージェント型システムには、さらに新しい観測対象が加わります。たとえば、プロンプト、取得されたコンテキスト、モデルの選択、ツール呼び出し、再試行、ガードレール、評価スコア、フィードバック、コスト、データへのアクセス状況などです。これらの一連の処理を再現できないのであれば、AIシステムを運用しているとは言えません。単に出力が返ってくるのを眺め、その背後の処理が妥当だったと期待しているだけです。

AI Agent Observabilityとは、こうしたエージェントの振る舞いを追跡可能、測定可能、統制可能、かつ改善可能なものにするための取り組みです。これは単なるトラブルシューティングのための仕組みではありません。品質、安全性、コスト管理、リリース管理、プライバシー、信頼性にも関わるものです。

AI Agent Observability

エージェントのObservabilityが重要な理由

エージェントのObservabilityが重要なのは、運用チームが最終的な回答以上の情報を必要としているからです。エージェントが何を見て、何を判断したのか、何を行ったのか、どれだけのコストがかかったのか、そしてポリシーやデータ保護の範囲内に収まっていたのかを理解するための十分な証拠が必要です。

  • デバッグ：トレースによって、複数ステップのLLMワークフロー全体にわたる因果関係が明らかになるため、チームはプロンプト、取得、ツール、ガードレール、オーケストレーション全体にわたって、失敗している範囲と根本原因となるエラーを特定できます。
  • 評価：プロンプトと完了イベントは、非決定論的なモデルの動作を捉えます。これらのトレースは、正確性、妥当性、フォーマット準拠、安全性、その他の品質特性に関する自動評価に利用できます。特定の出力に関連付けられたユーザーフィードバックは、品質とエンゲージメントを理解するためのもう一つの指標となります。
  • AIの安全性：GenAIのテレメトリと専門的な評価ツールを組み合わせることで、安全でない出力、バイアス、プロンプトの注入、プライバシー侵害、ポリシーの回避、機密データの漏洩などを検出するのに役立ちます。
  • コスト追跡：使用状況の指標とトークン数により、モデル、ワークフロー、テナント、機能、プロンプトバージョン、ツールパス、または障害パスごとの運用コストが明らかになります。
  • パフォーマンスの最適化：レイテンシ、スループット、エラー率、キュー時間、再試行回数、ツール依存のタイミングなどにより、エージェントは従来のアプリケーションに期待されるのと同等の運用パフォーマンス基準を満たすことができます。
  • インシデント対応の自動化：可観測性データによって、インシデントの起票、トレースの添付、担当者への通知、リソースのスケーリング、リスクの高いパスのスロットリング、障害が発生したコンポーネントの再起動といった運用ワークフローをトリガーできます。ただし、リスクの高いアクションには、ポリシー、承認、監査による管理が必要です。
  • バージョン管理とロールバック：モデルバージョン、プロンプトバージョン、ツールスキーマバージョン、取得インデックス、およびデプロイメントバージョンを追跡することで、リリース後に品質や信頼性が変化したかどうかを確認したり、新しいバージョンによって動作が劣化した場合に迅速にロールバックしたりすることが可能になります。

ビジネス上の根拠は単純明快です。説明のつかないエージェントには重要な業務を任せることはできないし、測定できないエージェントは最適化することはできません。

リファレンス・アーキテクチャ

実用的なアーキテクチャは、以下の5つの層から構成されます。

  1. 計測レイヤー：アプリケーション、オーケストレーションフレームワーク、モデルゲートウェイ、取得レイヤー、ツール、ガードレール、評価器、フィードバックUIからトレースとスパンをキャプチャします。
  2. データ保護レイヤー：テレメトリが別の機密データストアになる前に、マスキング、編集、アクセス制御、ポリシーチェック、保持ルール、サンプリングを適用します。
  3. テレメトリパイプライン：SDK、OpenTelemetry、ベンダーAPI、またはデータベースネイティブの履歴ビューを介して構造化イベントを出力します。リクエストID、ユーザー/セッションID、テナントID、プロンプトバージョン、モデルバージョン、およびデプロイメントバージョンを保持します。
  4. 分析レイヤー：トレース検査、迅速な比較、評価、データセット、フィードバック、コスト分析、リリース回帰チェックのために、LLM Observability Platformを使用します。
  5. 運用レイヤー：エージェントのテレメトリをAPM、ログ、メトリクス、監査、SIEM、データベーステレメトリ、およびインシデント管理ワークフローと関連付けます。

ツール環境

あらゆる状況において、1つのツールが常に最適というわけではありません。

どのツールを選ぶべきかは、何を重視するかによって変わります。たとえば、高度な評価ワークフロー、オープンソースでのセルフホスト、特定フレームワークとの統合トレーシング、ゲートウェイ層での可観測性、エンタープライズ向けの本番サポート、データレジデンシー管理、OpenTelemetryによる可搬性などです。

ツール／アプローチトレーシング・評価への適合性セキュリティとプライバシーの観点最適な利用ケース
LangfuseLLM呼び出し、チェーン、エージェント、ツール、メタデータ、セッション、データセット、スコア、実験、プロンプト管理、ユーザーフィードバックを幅広くトレースできます。マスキング制御を重視するチームに適しています。クライアント側でマスキングすれば、機密データがアプリケーション外へ出るのを防げます。セルフホスト型のエンタープライズ機能では、取り込み時のマスキングポリシーを一元管理できます。オープンソースによる管理性と、幅広いLLM Observability機能の両方を求めるチーム
LangSmithLangChainおよびLangGraphアプリケーションに非常に強く、詳細なトレース、スレッド、データセット、プロンプト、オンライン評価、オフライン評価、本番監視を提供します。入力、出力、メタデータの非表示やマスキングに対応します。また、一部のリクエストをトレースしない条件付きトレーシングも利用できます。LangChainやLangGraphをすでに利用しているチーム、またはフレームワークとの密接な統合を必要とするチーム
Heliconeゲートウェイを中心としたリクエスト監視、コスト、レイテンシ、キャッシュ、セッション、プロンプト、ユーザー、カスタムプロパティの可視化に強みがあります。集中型ゲートウェイによる制御や利用状況の可視化に適しています。ただし、生のプロンプトやツールのペイロードを送る前に、マスキング、保持期間、セルフホスト構成が自社のコンプライアンス要件を満たすか確認する必要があります。素早くゲートウェイを導入し、利用状況とコストを管理したいチーム
Arize Phoenix  / Arize AXLLM、検索、ツール、エージェント、OpenTelemetry、OpenInference、データセット、実験、評価処理を対象とした強力なトレーシングを提供します。Phoenixはオープンソースです。OpenTelemetry型のSpanや属性を細かく制御できます。Arizeのドキュメントでは、機密データを扱うためにSpan属性をマスキングまたは編集する方法も案内されています。オープンソースのAI Observabilityから始め、将来的にエンタープライズAI監視へ拡張したいチーム
OpenLITOpenTelemetryを基盤として、LLM、エージェント、Vector Database、MCP、GPU、プロンプト、メトリクス、ログ、ダッシュボード、評価を幅広く計測できます。OpenTelemetryを中心に運用するチームに適していますが、機密情報を取得しないよう明示的な設定が必要です。OpenLITは、データベースパラメータの取得によってパスワード、APIキー、個人情報が露出する可能性があると注意喚起しています。OpenTelemetryを中心とした、セルフホスト可能で幅広い計装機能を持つAIエンジニアリング基盤を求めるチーム
Oracle Autonomous AI Database Select AI Agentデータベース内で動作するエージェントフレームワークです。計画、ツール利用、振り返り、会話メモリ、ツール履歴、エージェント、チーム、タスクの履歴表示などを提供し、処理の透明性を確保します。Data Gravityの観点で優れています。エージェントがAutonomous AI Database内で動作し、既存のデータベースセキュリティと監査機能を継承します。データ移動を抑えながら、RBAC、CBAC、権限管理、VPD、RAS、データマスキング、暗号化、Data Safeなどを利用できます。独立したエージェントフレームワークよりも、ツール、データ、ポリシー、Observabilityをデータベースの近くに置くことを重視する、規制対応またはデータ中心のワークフロー
OCI Log Analytics + LoganAI構造化されたエージェント実行ログに対して、企業向けログ分析、相関分析、クラスタリング、ダッシュボード、AIによる説明を提供します。ただし、単体ではLLM専用のSpanトレーシング製品ではありません。OCI中心の運用、監査、セキュリティ相関、データ保持管理に適しています。生の機密プロンプトではなく、構造化・マスキング済みのエージェントテレメトリを送信する構成が適しています。本番運用、セキュリティ、監査、アプリケーションテレメトリを同じ調査環境で扱いたいOCI中心の企業

最も一般的な構成は、ハイブリッド型になるでしょう。

つまり、プロンプト、トレース、評価、フィードバックを詳細に確認するためには、専用のLLM Observabilityツールを使いながら、重要なシグナルは企業全体のObservability基盤へエクスポートしたり、そこで関連付けて分析したりする形です。

注：私の友人であるPaul Parkinsonは、私が知る中でも特に優れたデータベースアーキテクトの一人です。彼は、Java Observability ProviderとサーバーサイドのOpenTelemetryエクスポーターを使い、エージェントからOracle AI Databaseまでをどのようにトレースするかについて、非常に良いブログ記事を書き、自身の見解を共有しています。

効率性とデータセキュリティのバランス

効率性について考える際の問いは、単に「どのツールが最も優れたダッシュボードを提供するか」ではありません。「データをどこで観測し、削減し、マスキングし、保存するべきか」も重要です。

迅速な可視化を必要とするチームにとっては、OpenAI互換ゲートウェイやオープン・ソースのLLM Observabilityツールを使うことで、プロンプト、トークン使用量、レイテンシ、セッション、ツール呼び出し、評価結果を素早く把握できます。多くの実践的なLangfuse型の導入で示されているのは、まずトレースを可視化し、次にスコアリングを追加し、その後、本番環境で起きた失敗をデータセットやテストへ変換していく進め方です。

より強いデータ統制を必要とするチームでは、アーキテクチャをより上流側へ寄せるべきです。テレメトリを外部へ送信する前にマスキングを行い、生の顧客データは統制されたシステム内に保持します。可能な限り、完全なペイロードではなく、参照情報、ポリシー判定、ハッシュ、行ID、要約済みの観測情報を保存します。セルフホスト型のObservability基盤を利用する場合も、保持期間、パッチ適用、アクセス制御、バックアップ、監査を運用チームが管理できる体制が整っている場合に限るべきです。

ここで、Autonomous AI Database Select AI Agentは、企業向けの有力な構成パターンになり得ます。エージェントの主な役割が、データベース内のデータをもとに推論すること、データベースのツールを実行すること、または統制された業務ロジックを呼び出すことであるなら、エージェントフレームワークをAutonomous AI Database内で動作させることで、データ移動を減らし、データベースのセキュリティおよび監査制御をそのまま活用できます。

一方で、より高度なプロンプト実験、データセット管理、人手によるアノテーション、複数アプリケーションを横断したトレース分析を行うために、専用のLLM Observabilityまたは評価プラットフォームが引き続き必要になる場合があります。その場合は、生の機密データではなく、マスキング済みまたは要約済みのテレメトリを外部へ送るべきです。

つまり、ADB Select AI Agentは、単なる別のダッシュボード製品ではありません。これは配置に関する設計判断です。エージェントの実行を統制されたデータの近くに置き、安全な運用シグナルだけを外部へ公開するという考え方です。

OCI Log AnalyticsとLoganAIの活用方法

OCI Log Analyticsが企業向けAI運用において特に注目される理由は、エージェントの振る舞いがLLMの境界内だけで完結しないためです。エージェントは、ID管理システム、データベース、統合サービス、チケッティングプラットフォーム、クラウドAPI、ネットワーク経路、業務アプリケーションなどにアクセスします。これらのシステムは、すでにログ、イベント、各種の運用シグナルを生成しています。

OCI利用者にとって現実的な構成は、構造化され、マスキングされたエージェント実行ログをOCI Log Analyticsへ送信することです。対象となる項目には、Trace ID、Span ID、ユーザーまたはテナントのコンテキスト、プロンプトのバージョン、モデル名、検索元、ツール名、レイテンシ、トークン使用量、エラー分類、ガードレールの判定結果、マスキングポリシーの適用結果、最終的な障害分類などがあります。

これらの項目がインデックス化されると、チームはLog Explorer、ダッシュボード、クラスタ分析、リンク可視化を使い、エージェントの振る舞いをOCI Auditログ、アプリケーションログ、インフラログ、データベースのテレメトリ、セキュリティイベントと関連付けて分析できます。

LoganAIは、こうしたテレメトリの上にAI支援型の調査レイヤーを追加します。LoganAIは、単一ログ、複数ログ、クラスタ、チャートを対象に、AIによる説明を含むログ分析やログ由来データの分析を行えます。また、MQLを使ってOCI Monitoringからメトリクスを取得し、それらをログと組み合わせて分析することもできます。

このため、LoganAIはLLMトレーシングプラットフォームを補完する有用な運用ツールになります。専用のLLM Observabilityツールは、検索処理が失敗した、あるいはツール呼び出しが再試行されたといった事実を示してくれます。一方、OCI Log Analyticsは、その次に企業が知りたい問いに答えるのに役立ちます。たとえば、その時刻に環境内でほかに何が起きていたのか、どのテナントやコンパートメントが影響を受けたのか、関連する監査イベントが発生していたか、マスキングポリシーが作動したか、同様の障害がほかの場所でも集中して発生しているか、などに役立ちます。

実践例：LangfuseでCodex エージェントをトレース

Langfuseは、トレース、生成処理、ツール呼び出し、セッション、トークン使用量、評価スコア、データセット、フィードバックワークフローなどをチームに提供できるため、LLMに特化したObservabilityを実証するための実用的な方法です。

特にCodexでは、Langfuse Codex Observability Pluginを使うことで、エージェントの各ターン、モデル呼び出し、ツール実行、トークン使用量、サブエージェントのスレッドをLangfuseへトレースできます。

まずは、開発環境や管理された環境での利用例として試すのが適切です。このプラグインは、プロンプト、アシスタントのメッセージ、推論の要約、ツール呼び出しの入力と出力、モデルのメタデータ、トークン使用量などを含むCodexのトランスクリプトデータをアップロードする可能性があります。

そのため、Langfuseに保存したくないデータを含むセッションでは、このプラグインを有効にしないでください。

1. Langfuse プロジェクトを作成

Langfuse Cloudプロジェクトを作成するか、セルフホスト型のLangfuseインスタンスを使用します。プロジェクトの公開鍵と秘密鍵を生成します。

データリージョンに合ったBase URLを選択します。例：

  • https://cloud.langfuse.com
  • https://us.cloud.langfuse.com
  • https://jp.cloud.langfuse.com

2. オプション：Codex 用の Langfuse スキルをインストール

Langfuseスキルは、Codex Langfuse固有のガイダンスとドキュメント作成ワークフローのサポートを提供します。

python3 ~/.codex/skills/.system/skill-installer/scripts/install-skill-from-github.py \
  --repo langfuse/skills \
  --path skills/langfuse

Skillがインストールされたことを確認します。

ls -la ~/.codex/skills/langfuse

次のファイルが含まれていることを確認します。

SKILL.md
references/

3. Langfuse Plugin Marketplaceを追加

codex plugin marketplace add langfuse/codex-observability-plugin

4. Trace Pluginを有効化

Codexのビルドによっては、Marketplace　Plugin を明示的にインストールする必要がある場合があります。

codex plugin add tracing@codex-observability-plugin

続いて、インストール状況を確認します。

codex plugin list

次のエントリが表示されることを確認します。

tracing@codex-observability-plugin  installed, enabled

5. Pluguin Hooksを有効化

~/.codex/config.tomlを編集します。プロジェクト単位でトレーシングを設定する場合は、<project>/.codex/config.tomlを使用します。

[features]ブロックに、次の設定を追加します。

[features]
plugin_hooks = true

続いて、プラグインを有効にします。：

[plugins."tracing@codex-observability-plugin"]
enabled = true

6. Langfuseの認証情報を設定

公開サンプルや自動化では、通常、環境変数を使用する方法が最も分かりやすく管理しやすいです。

export TRACE_TO_LANGFUSE="true"
export LANGFUSE_PUBLIC_KEY="pk-lf-..."
export LANGFUSE_SECRET_KEY="sk-lf-..."
export LANGFUSE_BASE_URL="https://us.cloud.langfuse.com"

 また、他の Langfuse ツールに影響を与えない Codex 固有の設定が必要な場合はLANGFUSE_CODEX_PUBLIC_KEY、 LANGFUSE_CODEX_SECRET_KEYおよび LANGFUSE_CODEX_BASE_URLを使用することもできます 。

JSON設定ファイルの場合は、 ~/.codex/langfuse.json または<project>/.codex/langfuse.json を作成します。

{
  "enabled": true,
  "public_key": "pk-lf-...",
  "secret_key": "sk-lf-...",
  "base_url": "https://us.cloud.langfuse.com"
}

設定ファイルのアクセス権を制限します。

chmod 600 ~/.codex/langfuse.json

7. Codexを再起動

プラグインまたはフックの設定を変更した後は、Codexを再起動してください。フックの設定はCodexの起動時に読み込まれます。

8. テストを行い、トレースを確認

プラグインやフックの設定を変更した後は、Codexを再起動します。

フックの設定は、Codexの起動時に読み込まれます。

Langfuseのホーム・ビューでは、プロジェクトレベルでの総トレース数、モデルコスト、経時的な観測結果、スコアの概要が表示されるため、個々の実行の詳細を確認する前に、テレメトリが正しく流れていることを確認できます。

トレース・ビューには、実行されたすべてのエージェントとそのタイムスタンプ、名前、入力、出力、レイテンシ、コスト、トークン使用量が一覧表示されるため、処理速度が遅い、コストが高い、または失敗したトレースを一目で確認できます。

確認するポイント：

  • トレース全体の実行時間
  • 使用したモデル名とトークン使用量
  • ツール呼び出しとエラー
  • 失敗したコマンドや再試行
  • モデル呼び出し、または生成処理ごとのコスト
  • 長すぎるプロンプト、大きすぎる出力、過剰なツール応答

1つのCodex Turnトレースを開くと、その実行に含まれるSpan Treeを確認できます。そこには、モデル呼び出し、exec_command、apply_patch、サブエージェントの各スレッドに加え、プロンプト、出力、Spanごとのメタデータが表示されます。

この単位で、エージェントの振る舞いの原因を調査します。つまり、どの処理が実行され、何を出力し、どの時点で期待された動作から外れたのかを確認します。

同じ詳細画面では、各Spanの完全な出力と構造化メタデータも確認できます。たとえば、モデル名、トークン使用量、サービス属性、バージョンタグなどです。

これらは、インシデント・レビューの際に、何が起きたのかを説明するための重要な証拠になります。

テスト中は、デバッグ出力と、より厳格なエラー処理を有効にして実行することもできます

export LANGFUSE_CODEX_DEBUG="true"
export LANGFUSE_CODEX_FAIL_ON_ERROR="true"

通常の対話的な利用では、トレースのアップロード・エラーによって作業を中断させたい場合を除き、これらの設定は無効にしてください。

・9. データを活用して行動とコストを管理

トレースが収集できるようになったら、まず次の4つのダッシュボード、または保存済みビューを用意します。

モデル別・プロンプトバージョン別のコスト
コストの高いプロンプト、モデル変更による影響、性能やコストの悪化を見つけます。

トレース結果別のコスト
成功、失敗、再試行、ユーザーに拒否されたリクエストのコストを比較します。

ツール呼び出しと検索処理のオーバーヘッド
過剰なデータを返すツールや、必要以上に多くのコンテキストを詰め込んでいる検索処理を特定します。

品質と安全性のシグナル
評価スコア、ユーザー・フィードバック、ガードレールによるブロック、機密データのマスキング判定を関連付けて分析します。

コストダッシュボードでは、これらの情報を1か所にまとめて支出を監視できます。たとえば、全トレースの総コスト、モデル名や環境別のコスト、コストが高いユーザー、トレース、観測データなどを確認できます。コストが急増した場合は、その原因となったワークフローをすぐに特定できます。

目的は、単にエージェントのトレースを保存することではありません。

重要なのは、次のような改善サイクルを作ることです。

振る舞いを観測→ 無駄やリスクを特定→ プロンプト、ツール、ルーティング、検索処理を変更→ 再評価→ 改善を証明するトレースを保存

結論

AI運用の次の段階で成果を上げるのは、最も見栄えのよいダッシュボードを持つチームではありません。エージェントの振る舞いについて、その全容を再構成できるチームです。つまり、エージェントが何を見て、何を判断し、何を実行し、どれだけのコストがかかり、なぜ失敗し、どのデータを露出させ、その失敗をどのように翌日のより良いシステムへつなげるのかを説明できるチームです。

AIエージェントがデモの段階を離れ、企業の業務フローに組み込まれていくにつれて、Observabilityは単なるトラブル・シューティングの仕組みではなくなります。それは、信頼性、品質、安全性、コストを統制するためのコントロールプレーンになります。

問うべきなのは、エージェントが回答できるかどうかではありません。本番環境で説明責任を求められたときに、どのように回答へ至ったのかを説明できるか。そのワークフローを大規模に運用できるだけのコスト余力があるか。そして、その説明のために集めた情報が、新たなプライバシー問題を生み出していないことを証明できるかどうかです。

参考文献