観測とガバナンス ─ Eval・OTel・OWASP Agentic Top 10

2026/05/10

観測とガバナンス ─ Eval・OTel・OWASP Agentic Top 10

ch7 で durable に動かし、ch8 で常時稼働させると、ある日動いていることに誰も気づかないまま暴走することが起きる。あるいは、動いていることは知っているが、失敗の原因が特定できない。あるいは、動いているがコストがいつの間にか月 500 万円になる。

これらを解くのが Layer 7：観測とガバナンスだ。本シリーズではこれを「6 レイヤすべてを横串で貫く層」として位置付けている。本章では 5 つの軸で扱う。

軸 1：観測ツール 6 製品の住み分け

2026-05 時点で agent observability 市場を anchor するのは次の 6 つだ。

製品	立ち位置	強み	弱み
LangSmith	LangChain / LangGraph 純正	Polly（trace を要約する AI assistant）、Insights Agent、trace → eval → デプロイ一気通貫	Proprietary、self-host は Enterprise のみ
Langfuse	OSS（MIT）・API-first・OTel 互換	データ主権、フレームワーク中立、`@observe()` で任意関数を trace、self-host が first-class	LangChain ネイティブ統合は LangSmith より浅い
Arize Phoenix	OSS（Elastic L2.0）・OTel ベース	ML-grade な eval 原始要素、drift detection、embeddings 解析	自前で組む覚悟が必要
Helicone	proxy 型（base URL を変えるだけ）	最小コストで全リクエスト記録、SDK 改造不可な inference にも刺さる	深い trace 構造は弱い
OpenLLMetry / Traceloop	OTel 計装ライブラリ	1 行 init で各 LLM SDK を auto-instrument、backend 自由	バックエンドは別途必要
Datadog LLM Obs	エンプラ APM の延長	OTel pipeline にそのまま乗る。OTel GenAI semconv (v1.37+) ネイティブ対応	高コスト、SaaS 前提

選び方の指針：

LangChain / LangGraph 中心 → LangSmith
OSS で self-host、データ主権重視 → Langfuse
既存の Datadog / Grafana エンプラ APM がある → Datadog LLM Obs
proxy 型で最小工数 → Helicone
eval を本気で組む → Phoenix or Braintrust

軸 2：OpenTelemetry GenAI semantic conventions（v1.37）

エンプラで観測を組むなら、ベンダ独自仕様ではなく OpenTelemetry GenAI semantic conventions に従うのが将来安全だ。

2026-05 時点で v1.37 系が出ており、次の整理がされている：

GenAI spans / metrics / events が分離（Stable）
agent と framework の spans が別カテゴリ（Development ステータス）
gen_ai.operation.name gen_ai.provider.name が Required
gen_ai.agent.id / name / description / version、gen_ai.tool.definitions が Conditionally Required

ここで重要なのは **agent spans はまだ Development（実験段階）**だということだ。今ベンダ独自仕様で書くと数年後に書き直しコストが出る。OTel 互換層を一段挟むのが安全策だ。

✅ 観測スタックの分離設計（推奨）
─────────────────────
[Application] → OpenLLMetry で計装
                ↓ OTel 仕様
[Storage]    → Datadog or Langfuse or Phoenix
                ↓ Query API
[Eval]       → Braintrust or Phoenix

Application レイヤを OTel で書いておけば、Storage / Eval は後から差し替えられる。1 ベンダ全任せは lock-in リスクが大きい。

軸 3：3 層 Eval ── outcome / trajectory / meta

「LLM-as-judge だけ」では不十分、というのが 2026 の共通認識になった。実装は 3 層で組む。

1. Outcome eval（終端評価）

タスクの最終出力が目標を満たすか。end-to-end integration test に近い。

例：「PR レビューエージェントが、本来コメントすべき箇所に正しくコメントしたか」

2. Trajectory / step eval（経路評価）

途中の各 step が妥当か。unit test + 分散トレースに近い。

例：「途中で必要なツールを呼んだか」「LLM の呼び出し回数が想定範囲内か」「ツール呼び出しの引数が妥当か」

3. Meta-eval（評価器評価）

評価器自身の信頼性。評価が flaky になったときの diagnostic。

象徴的事例：Microsoft AgentPex の調査で「Claude 3.5 Sonnet の 58 trace のうち 48 件（83%）は『満点リワード』なのに、少なくとも 1 件のプロシージャ違反を含んでいた」[要検証]── outcome だけ見ると見落とす。

graph TB
    T[Task] --> A[Agent 実行]
    A --> O[Outcome]
    A --> Tr[Trajectory<br/>各 step の trace]

    O --> OE[Outcome Eval<br/>「正しい答えか」]
    Tr --> TE[Trajectory Eval<br/>「途中の振る舞いは妥当か」]

    OE --> ME[Meta-Eval<br/>「評価器自身は信頼できるか」]
    TE --> ME

実装の典型：

LangChain 公式 agentevals ライブラリで trajectory eval を組み立て
LangSmith / Langfuse / Datadog で online eval（production traffic に常時かける）
Braintrust で CI/CD ゲート（PR ごとに eval を回す）

Eval は dev だけでなく production traffic に常時かけるのが 2026 の標準。

軸 4：ガードレール ── NeMo + Guardrails AI の 2 段構え

業務投入では、エージェントの入力と出力を強制的にチェックするガードレール層が必要だ。2026-05 時点の standard は NeMo Guardrails と Guardrails AI の組み合わせだ。

製品	担当	実装
NeMo Guardrails (NVIDIA)	フロー制御	topic control / PII / RAG grounding / jailbreak / multilingual safety、設定ファイルベース
Guardrails AI	出力 validation	Pydantic 風スキーマで出力を検証、自動修正

「80% を NeMo で、20% を Guardrails AI で」というのが production の定石だ。CrowdStrike Falcon AIDR が NeMo Guardrails を v0.20.0 で正式統合した実績がある。

AI Red-teaming も組み込む

OWASP Top 10 for Agentic Applications（2025-12 公開）で「agent behavior hijacking / tool misuse / identity・privilege abuse」が新規に追加された。これらに耐えるには、CI/CD で red-teaming を自動化するのが現実解だ。

主要ツール：

DeepTeam（OSS, jailbreak / prompt injection / multi-turn）
LangWatch Scenario（multi-turn 自動 red-team）
Microsoft AI Red Teaming Agent（PyRIT ベース、Foundry 統合）
Mend AI

軸 5：OWASP Agentic Top 10 と監査ログ

OWASP Top 10 for Agentic Applications（2025-12）は、エージェント特有のリスクを 10 項目に整理した。代表的な項目：

ID	名前	概要
ASI01	Agent Behavior Hijacking	プロンプトインジェクションでエージェントの振る舞いを乗っ取る
ASI02	Tool Misuse	エージェントが不適切なツールを呼ぶ
ASI03	Identity / Privilege Abuse	エージェントの権限が広すぎる
ASI05	Unexpected Code Execution	sandbox 抜きで任意コード実行
ASI07	Memory Poisoning	メモリに悪意ある事実を注入されて長期的に判断が歪む

これらに対応するには、**「誰が・いつ・どの権限で・何を実行したか」**の監査ログが必須だ。

✅ 監査ログに含めるべき要素
─────────
- agent_id（どのエージェントか）
- session_id（どのセッションか）
- user_id（誰の代理として動いたか）
- tool_call（呼んだツール名と引数）
- tool_result_hash（出力の hash、PII を含む場合は full content を残さない）
- timestamp
- approval_id（HITL 承認が必要な操作の場合）
- cost_in_tokens（このアクションのコスト）

Sema4.ai Control Room、Anthropic Routines、OpenAI watch mode はいずれも、これらの要素を残す方向で設計されている。Routines / 長時間自律の登場で「Agent ID と監査ログ」が急務になったのが 2026 の状況だ。

ROI / コスト観測 ── 「tokens per feature」

2026 年に登場した R&D の予算指標が 「tokens per feature」（機能あたりトークン消費量）だ。production data の経験則として：

85% のクエリは budget-tier モデル（Haiku / GPT-4o-mini 級）で処理可能
85 / 10 / 5 split（budget / balanced / frontier）：tiered routing の経験則。RouteLLM 論文（Berkeley + Anyscale, ICLR 2025）は MT-Bench で 85% コスト削減 / 95% GPT-4 品質維持を実証。production では 30-60% 削減が現実的レンジ[要検証「92% 削減」の数字は二次ソース孫引きの可能性、慎重に扱う]

quadrantChart
    title モデルルーティングの判断
    x-axis 単純 --> 複雑
    y-axis 安価 --> 高価
    quadrant-1 frontier (5%)
    quadrant-2 不適 (避ける)
    quadrant-3 budget (85%)
    quadrant-4 balanced (10%)

trace-level cost breakdown（どの span が高いか）が Datadog / Langfuse / Phoenix で標準機能化している。「どの機能がどれだけ食っているか」を週次で見る運用が 2026 のコスト管理の基本だ。

❌ アンチパターン：Outcome eval だけで本番投入

症状
─────────
- 「動いている」ように見えるが、実は 83% のケースで procedural violation
- 失敗原因がコードを読み返さないと特定できない
- コストが月末に「あれ、こんなにいってたっけ」と気づく
- インシデント発生時に「誰が・いつ・何を実行したか」が追えない

根本原因
─────────
- Outcome eval だけで trajectory / meta eval がない
- OTel 互換の計装をしていない（ベンダ独自仕様で書いてしまった）
- 監査ログの要素を残していない
- コストの span 別 breakdown を見ていない

脱出法
─────────
1. 3 層 eval（outcome / trajectory / meta）を組む。LangChain agentevals が起点
2. OpenLLMetry で計装 → Langfuse or Datadog で storage → Braintrust で eval、と分離
3. 監査ログに 8 要素（agent_id / session_id / user_id / tool_call / hash / timestamp / approval_id / cost）を必ず残す
4. 週次で「tokens per feature」を見る運用に切り替え

業務投入の観点で重要な 3 点

観測スタックの「ingest / storage / eval」を分離：1 ベンダ全任せは lock-in リスクが大きい。OpenLLMetry → Langfuse or Datadog → Braintrust or Phoenix の 3 層分離が定石
3 層 eval を必ず組む：Outcome だけ見ると 83% に procedural violation を見落とす。Trajectory + Meta eval の併用が共通解。production traffic に常時かける
監査ログ 8 要素 + OWASP Agentic Top 10 への対応：「誰が・いつ・どの権限で・何を実行したか」を残せない設計は、エンプラに出してはいけない

次章への接続

Layer 1 から Layer 7 まで、6 レイヤ + 観測横串の地図を全部歩いた。最後の ch10 では、この地図を使って Devin / Manus / ChatGPT Agent / Claude Code Routines / Copilot Workspace / Replit / Sema4.ai を 6 レイヤで解剖する。「それぞれが何を作っていて、何が違うか」を一覧表に落とし込み、自分のスタック設計の参考材料とする。最後に、第2部（パターン編）・第3部（運用工学編）への伏線を回収して三部作の地図を渡す。

この章のまとめ

観測ツール 6 製品の住み分け：LangSmith（LangChain 系）/ Langfuse（OSS）/ Phoenix（eval 重視）/ Helicone（proxy）/ OpenLLMetry（計装）/ Datadog（エンプラ APM）
OTel GenAI semconv v1.37：spans/metrics/events は Stable、agent spans は Development。OTel 互換層を一段挟む
3 層 eval（outcome / trajectory / meta）：1 層だけだと 83% の procedural violation を見落とす
NeMo Guardrails（フロー制御）+ Guardrails AI（出力検証）：80/20 の組み合わせが定石
OWASP Agentic Top 10 と監査ログ 8 要素：エンプラ要件
「tokens per feature」+ 85/10/5 split：コスト管理の 2026 標準