エージェントAIの「判断ログ」設計 — なぜ今、監査可能性が問われるのか

1. 何が起きているか

マルチステップでツールを呼び出し、自律的にタスクを完了させるAIエージェントの導入が急速に進んでいる。一方で、エージェントが「なぜその手順を選んだか」「なぜそのAPIを呼んだか」を事後的に説明できないまま本番運用に入れているチームも少なくない。

2. 判断ログが持つべき3つの情報

• 入力コンテキスト: エージェントがその時点で参照していた情報の全体
• 選択肢と却下理由: 取り得た他の手段と、それを選ばなかった理由
• 実行結果の検証: 実行後に結果がどう検証され、次のステップにどう影響したか

これらを構造化ログとして残しておくことで、インシデント発生時の原因追跡だけでなく、エージェントの挙動そのものを継続的に改善するフィードバックループが成立する。

3. ゼロから設計しなくていい — 既存の標準規格を使う

「判断ログを構造化して残す」と言われても、独自のログ形式をゼロから設計する必要はない。OpenTelemetryプロジェクトが策定している「GenAI Semantic Conventions」という仕様は、まさにこの用途のために作られたものだ（詳しくは本誌のOpenTelemetry解説記事も参照）。

この仕様では、エージェント全体の処理を表すinvoke_agentという最上位の記録単位の下に、個々のLLM呼び出しを表すchat、ツール実行を表すexecute_toolといった子の記録が連なる構造で、判断ログが持つべき3つの情報を具体的な属性値として記録できる。

• 「入力コンテキスト」に対応する属性として、その時点でモデルに渡されたプロンプトやメッセージ履歴
• 「実行結果の検証」に対応する属性として、gen_ai.response.finish_reasons（なぜ応答が終了したか）や、ツール実行結果の成否
• 使用したモデル名（gen_ai.request.model）や入出力トークン数（gen_ai.usage.input_tokens／output_tokens）といった、コスト監査に必要な情報

これらを、既存の分散トレーシング基盤（OpenTelemetryのバックエンド）にそのまま送ることで、通常のマイクロサービスのリクエストトレースと同じ画面上で、エージェントの意思決定プロセスを時系列に沿って確認できるようになる。すでにOpenAI・Anthropic・LangChain・LlamaIndexなど主要なフレームワーク向けの自動計装パッケージが用意されており、ゼロからログ基盤を組む必要はない。

4. 「選択肢と却下理由」は自動では残らない

ただし、上記の標準規格でカバーされるのは主に「何を呼び出したか」「結果はどうだったか」という事実の記録であり、「なぜその選択肢を選び、他を選ばなかったか」という**理由づけ（reasoning trace）**は、多くの場合、追加の設計をしないと残らない。エージェントのプロンプト設計の段階で、モデルに「選択肢を検討した過程」を明示的に出力させ、それを構造化ログの一部として保存する、という一手間が必要になる。ここを省略すると、判断ログとしては「何が起きたか」は分かっても「なぜそうなったか」が分からない、片手落ちのログになってしまう。

5. 現場での実装

多くのチームは、LLMへのリクエスト・レスポンスをそのまま保存するだけで満足してしまう。しかし判断ログとして機能させるには、上記のようにツール呼び出しの前後関係と、なぜその判断に至ったかの中間表現を、標準化された形式で構造的に保持する必要がある。これは追加コストに見えるが、本番でエージェントが誤った判断をした際の調査時間を大幅に削減する投資でもある。既存のOpenTelemetry基盤を持つ組織であれば、GenAI Semantic Conventions対応の計装を追加するだけで、この土台の大部分は実現できる。