- はじめに——「何をしたか」のログでは、もう事故は防げない
- なぜ「行動ログ」では足りないのか——3つの典型的な失敗
- セマンティック・テレメトリと意図トレースとは
- OpenTelemetry GenAI Semantic Conventionsの最新動向
- Decision Provenance——「あの判断」を完全に再現するための7つの要素
- 反実仮想ログ（Counterfactual Log）——「もし違うルートを取っていたら」を記録する
- LangSmith／Langfuse／Helicone／Phoenix——意図トレース機能の比較
- 監査・規制対応——EU AI法第12条のログ要件との接続
- 中小企業向け——最小コストで始める意図トレース構成
- よくある質問（Q&A）
- まとめ——「観測性の次の段階」に行く3つのアクション
- 参考リンク
はじめに——「何をしたか」のログでは、もう事故は防げない
本番稼働中のAIエージェントが、顧客の重要なファイルを誤って削除した。承認すべきでない取引を承認してしまった。サポートチケットに不適切な回答を返した——こうしたインシデントは、すでに「もし起きたら」ではなく「いつ起きるか」の段階に入っています。
多くのチームは「行動ログ（action log）」を取っています。「いつ・どのツールを・どんな引数で呼び出したか」「どんな出力を返したか」。これは必要ですが、本番事故が起きた瞬間、こんな問いが必ず出てきます。
「なぜ、エージェントはそうしたのか？」
同じ入力に対して、エージェントは別の選択肢もあったはずです。なぜそのツールを選んだのか。なぜそのプロンプトに従ったのか。なぜそのモデルバージョンが使われていたのか。なぜRAGが返した5件の文書のうち、3番目を最重要視したのか。
この問いに答えられない限り、再発防止策は「祈り」になります。本記事では、行動ログの次のレイヤーとして注目されているセマンティック・テレメトリ（Semantic Telemetry）／意図トレース（Intent Trace）の設計フレームワークを、本番運用の視点から整理します。OpenTelemetry GenAI Semantic Conventions、Decision Provenance、反実仮想（カウンターファクチュアル）ログまで、2026年時点で実装可能な構成を順に見ていきます。
なぜ「行動ログ」では足りないのか——3つの典型的な失敗
具体的なシナリオから見ていきましょう。いずれも実在のAIエージェント運用で報告されているパターンです。
パターン1：同じ入力で、違う出力
カスタマーサポートのAIエージェントが、月曜日には「返金可能」と回答し、水曜日には同じ質問に「返金不可」と回答した。行動ログを見ると、どちらも同じツール（ナレッジベース検索）を呼んでおり、引数もほぼ同じ。なぜ違う回答になったのか分からない。
真因は、モデルバージョンのサイレントアップデート、システムプロンプトのA/B分岐、検索結果の順序のごく僅かな差——どれもありえます。行動ログには「何が違ったか」を再現する情報が含まれていません。
パターン2：同じ出力で、違う理由
2件のRAGクエリが、どちらも「文書Aを引用して回答X」を返した。一見、同じ振る舞いです。しかし片方は「文書Aを根拠に確信を持って」、もう片方は「文書Aしか見つからなかったので消去法で」回答していた——出力テキストだけ見ていては区別がつきません。
後者は、検索結果のスコアが低かった、再ランキングで他の候補が落ちていた、コンテキストウィンドウから文書Bが切り捨てられた——こうした「裏側の事情」が原因です。これを記録していなければ、本番で「実は信頼度の低い回答を量産していた」事実に気づけません。
パターン3：複数ステップの意思決定で、どこで折れたのか分からない
マルチステップのエージェント（計画 → ツール呼び出し → 結果評価 → 再計画）で、3ステップ目の判断が誤った。行動ログには各ステップの入出力はあっても、「2ステップ目の結果のうち、どの部分が3ステップ目の判断材料になったか」が記録されていない。エージェントの推論パス（reasoning path）が失われています。
これら3つはすべて、「行動の事実は記録しているが、意図と理由が再現できない」という同じ問題に帰着します。
セマンティック・テレメトリと意図トレースとは
「セマンティック・テレメトリ」とは、システムが出した数値・イベントだけでなく、「その意味（semantics）」——つまり、なぜそうしたかの構造化された情報——を併せて記録する観測性の考え方です。AIエージェントの文脈では、これが「意図トレース（Intent Trace）」として具体化されます。
意図トレースに含むべき情報を、行動ログとの対比で整理すると以下のようになります。
| 記録対象 | 行動ログ | 意図トレース |
|---|---|---|
| 呼び出したツール名 | ○ | ○ |
| ツールの引数 | ○ | ○ |
| ツールの出力 | ○ | ○ |
| そのツールを選んだ理由（推論ステップ） | × | ○ |
| 選ばれなかった候補ツール（rejected alternatives） | × | ○ |
| 使用したシステムプロンプト・バージョン | △ | ○ |
| モデル名・バージョン・サンプリングパラメータ | △ | ○ |
| RAGの検索結果上位N件と各スコア | × | ○ |
| コンテキストウィンドウの実構成（切り捨て情報を含む） | × | ○ |
| 同じ入力で別パスを取った場合の推定（反実仮想） | × | ○ |
「△」は「取っていることもあるが標準化されていない」を意味します。意図トレースの本質は、事後に「あの判断を再現・再検証できる」状態を作ることです。
OpenTelemetry GenAI Semantic Conventionsの最新動向
意図トレースを「自分の現場だけのカスタム実装」で終わらせないために、業界標準が必要です。それが現在進行中のOpenTelemetry GenAI Semantic Conventionsです。
2026年時点でのステータス
2026年4月時点で、OpenTelemetry GenAI Semantic ConventionsはSemantic Conventions 1.40.0に含まれており、ステータスは「Development」（開発中）です。クライアントスパンに関する一部の規約は実運用上は安定して使われていますが、仕様全体としてはまだ実験的（experimental）な属性が多く残っています。
ただし、本番運用を始めるうえで重要なのは、すでに主要なベンダーとフレームワークがこの仕様に集約しつつあることです。Datadog、Honeycomb、Grafana、Langfuse、LangSmith、Phoenix——いずれもOTel GenAI Conventionsをネイティブに（またはマッピング経由で）取り込む方向に動いています。
つまり、いま自前で「llm.model」「openai.model」「anthropic.model」のような独自属性を作るより、OTelのgen_ai.*名前空間に合わせておけば、後でバックエンドを差し替えやすいという実利的なメリットがあります。
記録対象として標準化されている主な要素
GenAI Conventionsは大きく4つの観測対象を定義しています。
| カテゴリ | 内容 | 意図トレースとの関係 |
|---|---|---|
| クライアントスパン | LLM呼び出し、Embedding、Retrieval、ツール実行 | 「何をしたか」の基盤 |
| エージェントスパン | create_agent、invoke_agent、フレームワークレベルの呼び出し | マルチステップ判断の階層を保存 |
| イベント | プロンプト・補完内容のキャプチャ（オプトイン） | 「なぜそうしたか」の証拠 |
| メトリクス | gen_ai.client.token.usage、gen_ai.client.operation.duration等 | コスト・性能・劣化検知 |
プロンプトと出力の取り扱い——重要な設計判断
注意すべきは、GenAI Conventionsはデフォルトでプロンプトと出力本文をキャプチャしません。これは個人情報（PII）漏洩を防ぐための設計原則です。
本番運用での推奨パターンはこうです。
- スパン本体には低カーディナリティのメタデータのみ——モデル名、トークン数、レイテンシ、エラー種別など
- プロンプト・出力本文は外部オブジェクトストレージ（S3、GCSなど）に格納し、スパンにはそのポインタ（URI／ハッシュ）のみを記録
- PIIマスキングはCollector層で実施（OpenTelemetry Collectorのredaction processor、またはMicrosoft Presidioをサイドカーで）
- プロンプト本文のキャプチャはpre-production・限定的なデバッグ環境のみで有効化し、本番では外部ストレージ＋スパン上のリファレンス方式を使う
「とりあえずプロンプト全文をスパンに入れる」は、PIIリスクとコスト（スパンサイズ）の両方で本番には不適切です。
バージョン移行——OTEL_SEMCONV_STABILITY_OPT_IN
OTel GenAI Conventionsはまだ進化中のため、属性名や仕様が変わる可能性があります。これに備えて、OpenTelemetryは環境変数 OTEL_SEMCONV_STABILITY_OPT_IN による段階的移行をサポートしています。値に gen_ai_latest_experimental を指定すると、計装ライブラリは最新の実験版を発行し、デフォルトでは旧バージョン（v1.36.0以前）を維持する——という二重発行（dual emission）の方式が用意されています。本番では「旧仕様を維持しつつ、ステージング環境で新仕様をテスト」する運用がしやすくなっています。
Decision Provenance——「あの判断」を完全に再現するための7つの要素
Decision Provenance（意思決定の出自・由来）とは、エージェントが特定の判断を下した瞬間の「状態のスナップショット」を、後から再現可能な形で保存する考え方です。OTelスパンの上に、以下の7要素を意図的に乗せることで実現します。
意図トレースに必須の7要素
| # | 要素 | 具体的に記録するもの |
|---|---|---|
| 1 | プロンプト・スナップショット | システムプロンプト、ユーザー入力、Few-shot例の全文（または外部ストレージへのハッシュリンク） |
| 2 | コンテキスト構成 | RAGの検索結果上位N件、スコア、再ランキング後の順序、コンテキストウィンドウへの最終投入分（切り捨て情報を含む） |
| 3 | モデルアイデンティティ | モデル名（例：claude-opus-4-7）、プロバイダー、デプロイメントID、API endpointバージョン |
| 4 | サンプリングパラメータ | temperature、top_p、top_k、max_tokens、stop sequence、seed（指定可能なら） |
| 5 | ツール定義スナップショット | そのリクエスト時にエージェントが利用可能だったツールの定義（名前、説明、JSON schema）。後から「あの時、このツールは存在したか」を再現するため |
| 6 | 意思決定の根拠 | Chain-of-Thought出力（取れるモデルなら）、選ばれなかった候補ツール、検索したが採用しなかった文書、信頼度スコア |
| 7 | 外部状態の参照 | 呼び出し時点でアクセスしたDB、APIレスポンス、フィーチャーフラグの値（変動する外部依存をすべてフリーズ） |
このうち、3〜5は「ほぼ全リクエストで取るべき」、1・2・7は「サンプリングまたは外部ストレージ」、6は「モデルが返してくれる範囲で」というのが現実的な落としどころです。すべてをスパン本体に詰め込むとコストが破綻するので、「スパンに入れるメタデータ」と「外部ストレージに入れる本文」の分離設計が肝になります。
「サイレント変更」を検出するためのバージョン署名
システムプロンプトが本番に対して「サイレントに」更新される事故は頻発します。これを防ぐため、各リクエストのDecision Provenanceには以下のハッシュを乗せます。
- システムプロンプトのSHA-256
- ツール定義セット全体のSHA-256（順序を正規化してから）
- モデルバージョン文字列のSHA-256
これらをまとめて「Provenance Fingerprint」とすれば、ダッシュボード上で「Fingerprintごとの誤答率」を集計できます。Fingerprintが変わった瞬間にエラー率が急上昇した——これが、原因がモデル変更かプロンプト変更かを切り分ける最速の手段になります。
反実仮想ログ（Counterfactual Log）——「もし違うルートを取っていたら」を記録する
Decision Provenanceが「実際に何をしたか」の完全な記録だとすれば、反実仮想ログはその一歩先——「あの瞬間、別の選択肢を取っていたら、何が起きていたか」を後から再現可能にする設計です。
なぜ必要か
本番で誤判断が起きたとき、エンジニアは「もし別のツールを呼んでいたら正解だったのか」「もし別のモデルだったらどうか」を検証したくなります。しかし、当時のコンテキスト・外部API状態・データベース内容は時間経過で変わっているため、「同じ条件で別の選択肢を試す」が事実上不可能になります。
反実仮想ログは、この再現を可能にするための「素材」を、実運用時に予め残しておく仕組みです。
反実仮想ログに含めるべき情報
| 情報 | 用途 |
|---|---|
| 呼び出し時点での全ツール定義（採用・非採用すべて） | 「他のツールを呼んだ場合」のリプレイ |
| RAG検索結果のトップN件（採用された3件だけでなく、見送られた7件も） | 「2位の文書を主に参照していたら」のリプレイ |
| 外部APIレスポンスのキャプチャ（呼んだものだけでなく、呼ぼうとして却下したものも） | 「別エンドポイントを叩いていたら」のリプレイ |
| モデル出力のlogprobs（取得可能なら） | 「次点の出力候補を選んでいたら」の確率的解析 |
| 判断分岐点のスナップショット（state machine遷移直前の完全状態） | 「あの分岐で逆方向に進んでいたら」の再シミュレーション |
低コストで始める「最小反実仮想ログ」
「全リクエストに反実仮想ログを付ける」は、データ量・コストの両面で現実的ではありません。実用的なのは以下の方針です。
- 重要判断のみフルキャプチャ——金銭・権限・顧客通知に関わる判断（critical decisions）に限定して反実仮想ログをフル取得
- 低リスク判断はサンプリング——通常の問い合わせ応答などは1〜5%サンプリング
- エラー時は遡及的にフルキャプチャ——直近30〜60分のコンテキストをリングバッファに保持しておき、エラー検知時にスナップショット化（pre-incident replay）
これは、航空機のフライトレコーダーと同じ思想です。常時全部録ると重すぎる。重要イベント時に直近を確保するのが現実的な解です。
LangSmith／Langfuse／Helicone／Phoenix——意図トレース機能の比較
意図トレースを支えるOSSとSaaSは、ここ1〜2年で急速に成熟しました。2026年時点での主要ツールを「意図トレース機能」の観点で整理します。
| ツール | 提供形態 | OTel GenAI対応 | 強み | 意図トレース観点での弱み |
|---|---|---|---|---|
| LangSmith | SaaS（LangChain） | ネイティブ対応進行中 | LangChain／LangGraphエコシステムとの統合、評価機能 | 非LangChainスタックでは旨味が減る |
| Langfuse | OSS／セルフホスト／SaaS | OTLP取り込み対応 | OSSでセルフホスト可、プロンプト管理＋評価＋トレースを一体提供 | 反実仮想ログの専用機能は薄い（カスタム属性で対応） |
| Helicone | OSS／SaaS | OTel経由対応 | プロキシ型でアプリ変更最小、コスト可視化が強い | 意思決定根拠の構造化は限定的 |
| Arize Phoenix | OSS／SaaS | OTel GenAIにコア依存 | 評価＋ドリフト検知が強い、研究系の機能が早い | 本番運用機能は他より新しい |
| Datadog LLM Obs | SaaS | ネイティブ（OTel GenAIをUIにマップ） | 既存APM／インフラ監視との統合 | 意図トレース専用設計ではない、コスト |
選択の指針として、以下の観点で決めるのが実務的です。
- すでにDatadogを使っているなら：Datadog LLM Observabilityを足がかりにし、必要に応じてLangfuse／Phoenixを併用
- セルフホスト前提・コンプライアンス重視なら：Langfuse（OSS）でフル制御。OTel経由で他のバックエンドにも流せる
- LangChain／LangGraphが主軸なら：LangSmithが最短経路
- 研究・評価機能を重視するなら：Arize Phoenix
どれを選ぶにせよ、「OTel GenAI Conventionsに準拠して計装する」を共通の前提にしておけば、後で乗り換えるコストが大きく下がります。
監査・規制対応——EU AI法第12条のログ要件との接続
意図トレースは「便利」だけの話ではなく、すでに規制要件になりつつあります。EU AI法（Regulation 2024/1689）は2026年8月2日から高リスクAIシステムへの本格適用が始まり、第12条（Record-keeping）が運用に直撃します。
第12条が要求している中身
| 条文の要点 | 運用への含意 |
|---|---|
| 「automatic recording of events」——自動でログを記録すること | 手動の運用ノート・スクリーンショットでは満たせない。技術的に組み込まれている必要がある |
| 「over the lifetime of the system」——システムのライフタイム全体 | デプロイから運用終了まで。「ログ取得を始めた時点から」では不十分 |
| リスクとなり得る状況の特定、市販後監視、運用監視を可能にすること | 事後に「なぜそうしたか」を検証できる粒度が必要 |
| 第26条（6）により、自動生成ログは最低6か月保持 | S3 Glacier等のコールドストレージ設計が現実的 |
| 監督当局の要求時にアクセス可能であること | プロバイダーだけが鍵を持つ暗号化では駄目（鍵管理の要件） |
「改ざん耐性」が要求される理由
第12条の条文自体には「tamper-proof」（改ざん不可能）の語はありませんが、「ログが密かに書き換えられ得るなら、証拠としての価値はゼロ」という解釈が業界では共通認識になっています。これに対応するため、各社は以下の方向に動いています。
- 各エージェントアクションを、エージェント自身が持たない鍵で署名する
- 各署名を前のエントリと連鎖（チェーン）させる
- レシート（署名済みログ）をエージェントが触れない場所に保存する
これにより「一箇所でも書き換えるとチェーンが壊れて検出される」状態を作ります。Ed25519署名＋ISO-8601タイムスタンプの組み合わせが軽量で実用的とされています。
日本企業の対応視点
「うちはEU向けじゃないから関係ない」と考えるのは早計です。EU市場にサービス提供している、またはEU住民のデータを扱う可能性がある時点で対象になり得ます。さらに、EU AI法はデファクトの国際標準として参照されることが多く、日本のAI事業者ガイドライン（経済産業省・総務省）の議論にも影響を与えています。
実務的には「将来的にEU基準が日本にも来る」前提で、最初から第12条相当のログ設計を組んでおくほうがコスト効率が良いです。
中小企業向け——最小コストで始める意図トレース構成
「LangSmith／DatadogをフルセットでBigCorp並みに導入するのは無理」というSMB（中小企業）の現場向けに、最小構成を提示します。
最小構成の3層
| 層 | 役割 | 推奨ツール（最小コスト） |
|---|---|---|
| 計装層 | OTel GenAI Conventionsに沿ったスパンを発行 | OpenTelemetry SDK + 自動計装（OpenAI／Anthropic／LangChain） |
| 収集・転送層 | PIIマスキング、サンプリング、複数バックエンドへのファンアウト | OpenTelemetry Collector（self-host、無料） |
| 保存・可視化層 | トレース閲覧、検索、評価 | Langfuse（self-host、OSS）または ClickHouse + Grafana |
運用ルールの最小セット
- 本文はスパンに入れない——プロンプト全文・出力全文はS3互換ストレージへ。スパンには7文字程度のオブジェクトキー＋SHA-256のみ
- サンプリングは「100% on error、5% on success」から始める——失敗時の情報を厚く、成功時は薄く
- Provenance Fingerprintを毎リクエストに付与——プロンプト＋モデル＋ツール定義のハッシュ。ダッシュボードで集計するだけで「サイレント変更」が見える
- 反実仮想ログは「critical decisions」のみ100%——金銭・通知・権限変更に関わる判断だけ。それ以外はサンプリング
- 保持期間は最低7か月——EU AI法の6か月要件＋安全マージン1か月
この構成は、月数万円〜十数万円のレンジで始められます。重要なのは、「意図トレースは大企業の贅沢ではない」という認識です。事故対応の人件費1回分で、年間のテレメトリ予算が回収できるケースのほうが多いはずです。
よくある質問（Q&A）
Q1. 既存のAPM（New Relic、Datadogなど）で十分では？
既存のAPMはトレース基盤としては優秀ですが、AIエージェント固有のセマンティクス——プロンプト、トークン使用量、ツール選択、RAGスコア——を「正しい属性名」で扱う設計にはなっていませんでした。2026年現在、DatadogをはじめとするAPMベンダーがOTel GenAI Conventionsを内部マッピングして取り込む方向に動いており、既存APM＋OTel GenAI計装の組み合わせが現実的なアップグレードパスです。
Q2. プロンプトを全部ログに残すと、PIIや機密情報が漏れませんか？
これが最大のリスクです。GenAI Conventionsがデフォルトでプロンプト本文をキャプチャしないのも、まさにこの理由です。本番運用では、(1) Collector層でPIIマスキング、(2) 本文は外部ストレージ＋スパンにはハッシュのみ、(3) プロンプトキャプチャ自体をpre-production限定にする——この3点セットを基本にしてください。
Q3. 反実仮想ログは結局シミュレーションでしょう？信頼できる？
完全な信頼はできません。反実仮想ログの目的は「絶対の真実を知る」ことではなく、「仮説検証のためのデバッグ材料を残す」ことです。「もしツールBを呼んでいたら、APIレスポンスはどうだった可能性が高いか」が示唆できるだけでも、事故調査の質は段違いに上がります。
Q4. OTel GenAI Conventionsはまだ「Development」ステータス。今採用していいの？
すでに主要ベンダー（Datadog、Langfuse、LangSmith、Phoenixなど）がこの仕様に集約しつつあるため、「待つコスト」のほうが大きくなっています。OTEL_SEMCONV_STABILITY_OPT_IN による二重発行の仕組みもあり、本番では旧仕様を維持しつつ新仕様への準備を進める運用が可能です。自前で独自属性名を作るより、いまから gen_ai.* 名前空間に寄せておくほうが移行コストは確実に下がります。
Q5. RAGとエージェントが多段化しすぎて、スパンの階層が深くなりすぎませんか？
はい、なります。実用的な対応は、(1) create_agent / invoke_agent でエージェントの境界を明示する、(2) ツール実行は execute_tool スパンで揃える、(3) スパンの深さに上限を設けてサンプリング戦略を変える——です。スパン階層をシンプルに保つ規律が、後の可視化と検索を救います。
まとめ——「観測性の次の段階」に行く3つのアクション
AIエージェントの本番運用は、「行動ログがある」段階から「意図と理由が再現できる」段階に進む必要があります。本記事で見てきた要点を、明日から始められる3アクションに圧縮します。
アクション1：すべての本番呼び出しに「Provenance Fingerprint」を付ける。 プロンプト・モデル・ツール定義のハッシュをまとめた1つの識別子を、全リクエストに付与する。これだけでサイレント変更による事故の検知速度が劇的に変わります。
アクション2：OTel GenAI Conventionsに沿った計装に統一する。 独自属性名（llm.model、app.prompt等）から gen_ai.* への移行を計画する。バックエンドを後で乗り換えても残る資産になります。
アクション3：critical decisionsだけ反実仮想ログをフルキャプチャする。 金銭・権限・通知に関わる判断について、当時のツール定義・RAG候補・外部API状態を全部スナップショットする。事故対応1回分のコスト回収だと考えれば、必ず元が取れる投資です。
観測性の文脈で言えば、メトリクス（数値の集約）、ログ（テキストの履歴）、トレース（リクエストの追跡）に続く「第4の柱」として、「意図と推論パスの再現可能性」が立ち上がりつつあります。本番AIエージェントを運用しているチームは、すでにこの第4の柱を組み込む段階に入っています。
参考リンク
- OpenTelemetry — Semantic conventions for generative AI systems
- OpenTelemetry — Semantic Conventions for GenAI agent and framework spans
- OpenTelemetry — Semantic conventions for Generative AI events
- OpenTelemetry — Semantic conventions for generative AI metrics
- EU AI Act — Article 12: Record-keeping
- European Commission — AI Act Article 12
免責事項： 本記事は2026年5月時点の公開情報に基づく情報提供であり、特定のベンダー・製品・規制対応を保証するものではありません。OpenTelemetry GenAI Semantic Conventionsは現在も「Development」ステータスにあり、属性名・仕様は今後変更される可能性があります。実装にあたっては必ず最新の公式ドキュメントを確認してください。EU AI法その他の規制への具体的な対応については、法務・コンプライアンスの専門家にご相談ください。
コメント