AIエージェントの可観測性: 生成AIアプリケーションとエコシステムにおけるAIエージェントの動作の理解 (2026/07/07)
AIエージェントの可観測性: 生成AIアプリケーションとエコシステムにおけるAIエージェントの動作の理解 (2026/07/07)
投稿者：Royce Fu | Master Principal Cloud Architect
AIエージェントの導入で難しいのは、印象的なデモを一つ成功させることではありません。難しいのは、エージェントが予期せぬ判断を下し、何の警告もなく予想をはるかに超えるトークンを消費し、いくつかのツールを20回も再試行し、スキルの読み込みをループさせ続け、最終的に間違ったドキュメントを取得し、機密データにアクセスし、それでもなお自信満々に回答を返した後に何が起こったのかを
説明することです。従来のアプリケーション監視では、APIが遅いか、エンドポイントが失敗したか、データベースクエリがタイムアウトしたかがわかります。これは依然として重要です。しかし、エージェントシステムは、プロンプト、取得されたコンテキスト、モデルの選択、ツールの呼び出し、再試行、ガードレール、評価スコア、フィードバック、コスト、データ漏洩といった新たな動作レイヤーを追加します。これらの手順を再現できないのであれば、AIシステムを運用しているとは言えません。単に結果が届くのを待ち、その背後にあるプロセスが理にかなっていることを願っているだけです。
AIエージェントの可観測性とは、その動作を追跡可能、測定可能、管理可能、そして改善可能にするための規律です。これは単にトラブルシューティングのためだけのものではありません。品質、安全性、コスト管理、リリース管理、プライバシー、そして信頼性にも関わるものです。
エージェントの可観測性が重要な理由
エージェントの可観測性が重要なのは、運用チームが最終的な回答以上の情報を必要としているからです。エージェントが何を見て、何を判断したのか、何を行ったのか、どれだけのコストがかかったのか、そしてポリシーやデータ保護の範囲内に収まっていたのかを理解するための十分な証拠が必要なのです。
- デバッグ：トレースによって、複数ステップのLLMワークフロー全体にわたる因果関係が明らかになるため、チームはプロンプト、取得、ツール、ガードレール、オーケストレーション全体にわたって、失敗している範囲と根本原因となるエラーを特定できます。
- 評価：プロンプトと完了イベントは、非決定論的なモデルの動作を捉えます。これらのトレースは、正確性、妥当性、フォーマット準拠、安全性、その他の品質特性に関する自動評価に利用できます。特定の出力に関連付けられたユーザーフィードバックは、品質とエンゲージメントを理解するためのもう一つの指標となります。
- AIの安全性：GenAIのテレメトリと専門的な評価ツールを組み合わせることで、安全でない出力、バイアス、プロンプトの注入、プライバシー侵害、ポリシーの回避、機密データの漏洩などを検出するのに役立ちます。
- コスト追跡：使用状況の指標とトークン数により、モデル、ワークフロー、テナント、機能、プロンプトバージョン、ツールパス、または障害パスごとの運用コストが明らかになります。
- パフォーマンスの最適化：レイテンシ、スループット、エラー率、キュー時間、再試行回数、ツール依存のタイミングなどにより、エージェントは従来のアプリケーションに期待されるのと同等の運用パフォーマンス基準を満たすことができます。
- インシデント対応の自動化：可観測性データによって、インシデントの起票、トレースの添付、担当者への通知、リソースのスケーリング、リスクの高いパスのスロットリング、障害が発生したコンポーネントの再起動といった運用ワークフローをトリガーできます。ただし、リスクの高いアクションには、ポリシー、承認、監査による管理が必要です。
- バージョン管理とロールバック：モデルバージョン、プロンプトバージョン、ツールスキーマバージョン、取得インデックス、およびデプロイメントバージョンを追跡することで、リリース後に品質や信頼性が変化したかどうかを確認したり、新しいバージョンによって動作が劣化した場合に迅速にロールバックしたりすることが可能になります。
ビジネス上の根拠は単純明快だ。説明のつかないエージェントには重要な業務を任せることはできないし、測定できないエージェントは最適化できない。
リファレンスアーキテクチャ
実用的な本番アーキテクチャは、以下の5つの層から構成されます。
- 計測レイヤー：アプリケーション、オーケストレーションフレームワーク、モデルゲートウェイ、取得レイヤー、ツール、ガードレール、評価器、フィードバックUIからトレースとスパンをキャプチャします。
- データ保護レイヤー：テレメトリが別の機密データストアになる前に、マスキング、編集、アクセス制御、ポリシーチェック、保持ルール、サンプリングを適用します。
- テレメトリパイプライン：SDK、OpenTelemetry、ベンダーAPI、またはデータベースネイティブの履歴ビューを介して構造化イベントを出力します。リクエストID、ユーザー/セッションID、テナントID、プロンプトバージョン、モデルバージョン、およびデプロイメントバージョンを保持します。
- 分析レイヤー：トレース検査、迅速な比較、評価、データセット、フィードバック、コスト分析、リリース回帰チェックのために、LLMオブザーバビリティプラットフォームを使用します。
- 運用レイヤー：エージェントのテレメトリをAPM、ログ、メトリクス、監査、SIEM、データベーステレメトリ、およびインシデント管理ワークフローと関連付けます。
ツール環境
あらゆる状況で最適なツールは存在しません。最適な選択は、詳細な評価ワークフロー、オープンソースのセルフホスティング、フレームワークネイティブのトレース、ゲートウェイレベルの可観測性、エンタープライズレベルの本番環境サポート、データ所在地の制御、またはOpenTelemetryの移植性のどれを優先するかによって異なります。
| ツールのアプローチ | トレースと評価適合 | セキュリティとプライバシーに関する姿勢 | 最適なフィット感 |
|---|---|---|---|
| Langfuse | LLM呼び出し、チェーン、エージェント、ツール、メタデータ、セッション、データセット、スコア、実験、プロンプト管理、およびユーザーフィードバックに関する強力なトレース。 | マスキングの制御を重視するチームにとって強力な機能です。クライアント側のマスキングにより、機密データがアプリ外に流出するのを防ぐことができ、自社ホスト型のエンタープライズ向けデータ取り込みマスキングにより、ポリシーの適用を一元化できます。 | オープンソースによる制御と、LLMの広範な可観測性カバレッジを求めるチーム。 |
| LangSmith | LangChainおよびLangGraphアプリケーションに非常に適しており、詳細なトレース、スレッド、データセット、プロンプト、オンライン評価、オフライン評価、および本番環境の監視機能を備えています。 | 入力、出力、メタデータの非表示またはマスク機能に加え、一部のリクエストを一切トレースしない場合の条件付きトレース機能をサポートしています。 | 既にLangChain/LangGraphを使用して開発を行っているチーム、またはフレームワークとの緊密な統合を必要とするチーム。 |
| Helicone | ゲートウェイ中心の強力なリクエスト監視機能、コスト、レイテンシ、キャッシング、セッション、プロンプト、ユーザー、およびプロパティ。 | 集中型ゲートウェイ制御と使用状況の可視化に最適です。生のプロンプトやツールペイロードを送信する前に、マスキング、データ保持、およびセルフホストの姿勢がコンプライアンス要件に合致していることを確認してください。 | ゲートウェイの迅速な導入、利用状況の可視化、およびコスト管理を求めるチーム。 |
| Arize Phoenix とArize AX | LLM、検索、ツール、エージェント、OpenTelemetry、OpenInference、データセット、実験、評価ツールのための強力なオープンソース追跡機能。 | OpenTelemetryスタイルのスパンと属性の制御。Arizeのドキュメントには、機密データの取り扱いにおけるスパン属性のマスキングまたは編集方法が記載されています。 | オープンソースのAI可観測性を求め、エンタープライズAIモニタリングへの道筋を模索しているチーム。 |
| OpenLIT | LLM、エージェント、ベクトルデータベース、MCP、GPU、プロンプト、メトリクス、ログ、ダッシュボード、評価のための強力なOpenTelemetryネイティブトレース機能。 | OpenTelemetryを優先的に採用するチームには適していますが、機密性の高い情報の取得は慎重に設定する必要があります。OpenLITは、データベースパラメータの取得によってパスワード、APIキー、個人情報が漏洩する可能性があると警告しています。 | OpenTelemetryを最優先とし、幅広い計測機器に対応したセルフホスト型のAIエンジニアリングプラットフォームを求めるチーム向け。 |
| Oracle Autonomous AI Database Select AI Agent | 計画、ツール使用、振り返り、会話記憶、ツール履歴、およびエージェント/チーム/タスク履歴ビューを備えた、データベース常駐型エージェントフレームワーク。透明性を確保します。 | 強力なデータ重力パターン：エージェントは自律型AIデータベース内で実行され、データベースのセキュリティ制御と監査を継承し、データ移動を削減し、RBAC、CBAC、権限、VPD、RAS、データマスキング、暗号化、データセーフなどの制御を使用できます。 | 規制されたワークフローやデータ中心のワークフローでは、スタンドアロンのエージェントフレームワークを使用するよりも、ツール、データ、ポリシー、および可観測性をデータベースの近くに保持することがより重要になります。 |
| LoganAIによるOCI Log Analytics | エンタープライズログの分析、相関分析、クラスタリング、ダッシュボード作成、および構造化されたエージェントランタイムログのAI支援による説明に優れています。ただし、単体では専用のLLMスパン追跡製品ではありません。 | OCIを中心とした運用、監査、セキュリティ相関分析、およびデータ保持ガバナンスに最適です。機密性の高い生のプロンプトではなく、構造化されマスクされたエージェントテレメトリデータを使用するのが最適です。 | OCIを中心とした企業で、本番運用、セキュリティ、監査、およびアプリケーションテレメトリを同一の調査ワークスペースで必要とする場合。 |
最も一般的なパターンはハイブリッド型となるでしょう。つまり、プロンプト、トレース、評価、フィードバックの深度には専用のLLMオブザーバビリティツールを使用し、重要なシグナルをより広範なエンタープライズオブザーバビリティスタックにエクスポートまたは相関させるというものです。
効率性とデータセキュリティのバランス
効率性に関する問題は、「どのツールが最適なダッシュボードを提供してくれるか？」というだけではありません。「データはどこで監視、削減、マスキング、保存されるべきか？」という問題も含まれます。
スピードを重視するチームにとって、OpenAI互換のゲートウェイやオープンソースのLLMオブザーバビリティツールは、プロンプト、トークンの使用状況、レイテンシ、セッション、ツール呼び出し、評価などを迅速に可視化できます。これは、多くの実用的なLangfuseスタイルの実装で示されているアプローチです。まずトレースの可視化から始め、スコアリングを追加し、本番環境での障害をデータセットとテストに変換します。
より強力なデータ制御を必要とするチームの場合、アーキテクチャを左シフトする必要があります。テレメトリのエクスポート前にマスキングを行い、生の顧客レコードは管理されたシステムに保持します。可能な場合は、完全なペイロードではなく、参照、ポリシー決定、ハッシュ、行ID、および要約された観測結果を保存します。運用チームが保持、パッチ適用、アクセス制御、バックアップ、および監査を管理する準備が整った場合にのみ、自己ホスト型のオブザーバビリティを使用します。
こうした場面で、Autonomous AI Database Select AI Agent は強力なエンタープライズパターンとなり得ます。エージェントの主な役割が、データベースに存在するデータに対する推論、データベースツールの実行、または統制されたビジネスロジックの呼び出しである場合、Autonomous AI Database 内でエージェントフレームワークを実行することでデータ移動が削減され、エージェントはデータベースのセキュリティと監査制御を継承できます。ただし、より高度な実験、データセット管理、人間による注釈付け、およびアプリケーション間トレース分析のために、専用の LLM オブザーバビリティまたは評価プラットフォームが必要になる場合もあります。その場合は、機密性の高い生データではなく、マスク処理または要約されたテレメトリをエクスポートしてください。
つまり、ADB Select AI Agentは単なるダッシュボードのオプションの一つではありません。それは配置に関する決定であり、管理対象データの近くにエージェントの実行環境を配置し、安全な運用シグナルを外部に発信するということです。
OCI Log AnalyticsとLoganAIの活用方法
OCI Log Analyticsは、エンタープライズAI運用において特に興味深いツールです。なぜなら、エージェントの動作はLLMの境界で終わらないからです。エージェントは、IDシステム、データベース、統合サービス、チケット発行プラットフォーム、クラウドAPI、ネットワークパス、ビジネスアプリケーションなど、さまざまなシステムと連携します。これらのシステムは既にログ、イベント、運用シグナルを生成しています。
OCI のお客様にとって、実用的なパターンは、構造化されマスクされたエージェント ランタイム ログを OCI Log Analytics に出力することです。出力すべきログには、トレース ID、スパン ID、ユーザーまたはテナントのコンテキスト、プロンプト バージョン、モデル名、取得元、ツール名、レイテンシ、トークン使用状況、エラー クラス、ガードレール結果、マスキング ポリシー結果、および最終的な障害分類が含まれます。これらのフィールドにインデックスが付けられると、チームは Log Explorer、ダッシュボード、クラスタ、リンク ビジュアライゼーションを使用して、エージェントの動作を OCI 監査ログ、アプリケーション ログ、インフラストラクチャ ログ、データベース テレメトリ、およびセキュリティ イベントと関連付けることができます。
LoganAIは、テレメトリの上にAIによる調査レイヤーを追加します。LoganAIは、ログおよびログ由来のデータを分析し、単一のログ、複数のログ、クラスタ、チャートに対するAIによる説明を提供します。また、MQLを使用してOCI Monitoringからメトリックを取得し、ログと組み合わせて分析することも可能です。
そのため、LoganAIはLLMトレースプラットフォームの有用な運用コンパニオンとなります。専用のLLM監視ツールは、取得ステップが失敗したことやツール呼び出しが再試行されたことを通知します。OCI Log Analyticsは、次の企業側の疑問、つまり、その時点で環境内で他に何が起こっていたのか、どのテナントまたはコンパートメントが影響を受けたのか、関連する監査イベントが発生したのか、マスキングポリシーが発動したのか、同様の障害が他の場所でも発生しているのか、といった疑問に答えるのに役立ちます。
実践例：Langfuse で Codex エージェントを追跡する
Langfuseは、トレース、生成、ツール呼び出し、セッション、トークン使用状況、スコア、データセット、フィードバックワークフローなどをチームに提供するため、LLMに特化した可観測性を実証する実用的な方法です。特にCodexの場合、Langfuse Codex可観測性プラグインは、エージェントのターン、モデル呼び出し、ツール実行、トークン使用状況、サブエージェントスレッドをLangfuseにトレースします。
まず、開発環境または管理された環境での例としてご利用ください。このプラグインは、プロンプト、アシスタントメッセージ、推論サマリー、ツール呼び出しの入力と出力、モデルメタデータ、トークン使用状況など、Codexのトランスクリプトデータをアップロードできます。Langfuseに保存することに抵抗のあるデータを含むセッションでは、このプラグインを有効にしないでください。
1. Langfuseプロジェクトを作成する
Langfuse Cloudプロジェクトを作成するか、セルフホスト型のLangfuseインスタンスを使用します。プロジェクトの公開鍵と秘密鍵を生成します。
データ領域に適したベースURLを選択してください。例：
2. オプション：Codex 用の Langfuse スキルをインストールします
Langfuseスキルは、Codex Langfuse固有のガイダンスとドキュメント作成ワークフローのサポートを提供します。
python3 ~/.codex/skills/.system/skill-installer/scripts/install-skill-from-github.py \
--repo langfuse/skills \
--path skills/langfuseスキルを検証する：
ls -la ~/.codex/skills/langfuse想定されるファイルは以下のとおりです。
SKILL.md
references/3. Langfuseプラグインマーケットプレイスを追加する
codex plugin marketplace add langfuse/codex-observability-plugin4. トレースプラグインを有効にする
Codexのビルドによっては、マーケットプレイスプラグインを明示的にインストールする必要がある場合があります。
codex plugin add tracing@codex-observability-plugin次に、以下を確認します。
codex plugin list予想されるエントリー数：
tracing@codex-observability-plugin installed, enabled5. プラグインフックを有効にする
編集する ~/.codex/config.tomlか、 <project>/.codex/config.toml プロジェクト固有のトレースに使用します。
plugin_hooks = true ブロックの下に 敷く [features] ：
[features]
plugin_hooks = trueプラグインを有効にする：
[plugins."tracing@codex-observability-plugin"]
enabled = true6. 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.json7. Codexを再起動する
プラグインまたはフックの設定を変更した後は、Codexを再起動してください。フックの設定はCodexの起動時に読み込まれます。
8. テスト旋回を行い、トレースを確認する
機密データを含まないシンプルなCodexタスクを実行します。次に、Langfuseプロジェクトを開き、新しいトレースを探します。
Langfuseの ホーム ビューでは、プロジェクトレベルでの総トレース数、モデルコスト、経時的な観測結果、スコアの概要が表示されるため、個々の実行の詳細を確認する前に、テレメトリが正しく流れていることを確認できます。
トレースビューには、実行されたすべてのエージェントとそのタイムスタンプ、名前、入力、出力、レイテンシ、コスト、トークン使用量が一覧表示されるため、処理速度が遅い、コストが高い、または失敗したトレースを一目で確認できます。
検査:
単一のCodex Turnトレースを開くと、その実行のスパンツリー（モデル呼び出し、、、およびサブエージェントスレッド）が、プロンプト、出力、およびスパンごとのメタデータとともに表示されますexec_command。apply_patchこれは、どのステップが実行され、何が生成されたか、そして実行が期待からどのように逸脱したかなど、動作の根本原因を特定するための単位です。
同じ詳細ビューでは、各スパンの完全な出力と構造化されたメタデータ（モデル名、トークンの使用状況、サービス属性、バージョンタグなど）が表示されます。これは、インシデントレビュー時にまさに必要な証拠です。
テスト中にデバッグモードとより厳密なエラー報告を有効にして実行することもできます。
export LANGFUSE_CODEX_DEBUG="true"
export LANGFUSE_CODEX_FAIL_ON_ERROR="true"通常の対話型使用時には、アップロードエラーの追跡によってワークフローが中断されるのを避けたい場合を除き、これらの機能をオフにしてください。
9. データを活用して行動とコストを管理する
トレースが流れ始めたら、まず4つのダッシュボードまたは保存済みビューから始めます。
- モデル別およびプロンプトバージョン別のコスト：高額なプロンプト、モデルのアップグレード、および回帰バグを検出します。
- トレース結果別のコスト：成功したリクエスト、失敗したリクエスト、再試行されたリクエスト、およびユーザーによって拒否されたリクエストを比較します。
- ツールとデータ取得のオーバーヘッド：ツールが過剰なデータを返す場合や、取得手順で過剰なコンテキストが詰め込まれている場合を特定します。
- 品質と安全性のシグナル：評価者のスコア、ユーザーからのフィードバック、ガードレールブロック、および機密データのマスキングに関する決定を関連付けます。
コストダッシュボードは、これらのビューを1か所に集約し、支出状況を監視できるようにします。すべてのトレースの合計コスト、モデル名と環境別のコスト、コスト上位のユーザー、トレース、および観測値などが表示されるため、コストの急増が発生した場合は、その原因となったワークフローを直接特定できます。
目的は単にエージェントの行動履歴を保存することではありません。目的はフィードバックループを構築することです。つまり、行動を観察し、無駄やリスクを特定し、プロンプト／ツール／ルーティング／取得方法を変更し、再度評価を行い、改善を証明する履歴を保持することです。
まとめ
AI運用の次の段階は、最も見栄えの良いダッシュボードを持つチームが勝つわけではありません。エージェントの行動の全容を再構築できるチームが勝つでしょう。つまり、エージェントが何を見て、何を決定し、何を行い、どれだけのコストがかかり、なぜ失敗したのか、どのようなデータが漏洩したのか、そしてその失敗がどのようにして明日のより良いシステムにつながるのかを解明できるチームです。
エージェントがデモ段階からエンタープライズワークフローへと移行するにつれ、可観測性は単なるトラブルシューティングにとどまらず、信頼性、品質、安全性、コストを管理するための制御プレーンへと進化する。
問題は、エージェントが回答できるかどうかではありません。問題は、制作側から証拠を求められた際に、エージェントがどのように回答したかを説明できるかどうか、大規模な運用でもそのワークフローを維持できるかどうか、そしてその説明によって新たなプライバシー問題が発生しなかったことを証明できるかどうかです。
コメント
コメントを投稿