AI Agentの正常と正しいを分けて観測する / Observe the normality and correctness of the AI Agent separately

Transcript

1. AI Agentの「正常」と「正しい」を 分けて観測する AIエージェント時代に求められるオブザーバビリティ / 2026/07/23 Joe / 大平 譲 @joe_yuzupi
2. About Me Joe (Yuzuru Ohira) 株式会社LayerX Ai Workforce事業部 Platform Enablement グループマネージャー 直近の登壇 2026.07 テクニカルプロジェクトマネージャーとSREが協働して構築する信頼性 ↗ 2025.10 可観測性は開発環境から ─ 開発環境にもオブザーバビリティ導入のススメ ↗ © LayerX Inc. 2
3. © LayerX Inc. 3
4. 事業紹介 © LayerX Inc. 4
5. まず、AI Agent像をそろえる AI Agentと聞いて、何を思い浮かべますか？ Coding Agent Issue・指示を理解する ↓ コードを編集し、テストする Research Agent 問いに必要な情報を探す ↓ 根拠を整理して回答する 業務Agent 依頼に応じて判断する ↓ 複数のツールで業務を完了する 共通点：ツールを使い、複数ステップで目的を達成する © LayerX Inc. 5
6. AI Agentの「正しい」を定義する AI Agentで「正しい」とは？ 目的を達成し、根拠と制約を満たした結果を返すこと 目的 利用者が依頼した業務を、期待し た形で完了している © LayerX Inc. 根拠 回答や判断が、参照情報によって 支えられている 制約 業務ルール・権限・安全条件を守 っている 6
7. 2つの健全性を分ける タスクは成功した。でも、権限外の操作だったら？ Execution health 期待どおり動いたか error、latency、dependency、retry Agent / LLM / tool の実行状態 Semantic quality 業務上、正しかったか 目的、根拠、制約 利用者の期待と結果の整合 「期待どおり動いたか」と「業務上、正しかったか」は、別の軸で評価する。 © LayerX Inc. 7
8. 観測の前に業務設計をする 観測の前に、Agentの「正しい挙動」を業務から定義する 1 目的 2 何を完了すれば、業務上の成功な のか 根拠 何を参照し、何を説明可能にする のか 3 制約 守るべき手順・権限・停止条件は 何か 目的・根拠・制約を定義し、証跡となるテレメトリーで「定義どおりだったか」を確かめる © LayerX Inc. 8
9. Traceで実行の流れをつなぐ Trace：親子関係と処理時間を、1件の実行で追う Span 0s invoke_agent {customer_support} 6.0s └ invoke_workflow {answer_request} ├ chat {実行計画} ├ execute_tool {資料検索} ├ retrieval {社内資料検索} 2s 4s 6s 5.8s 0.7s 0.6s 1.1s ├ chat {回答生成} └ execute_tool {回答登録} 1.9s 0.9s どのSpanで時間を使い、どの処理の子として実行されたかを追跡する © LayerX Inc. 9
10. Metricsで全体傾向を捉える Metrics：Agent全体の変化を時系列で捉える Reliability run success rate、error rate、retry rate Performance p50 / p95 latency、モデルが解決へ到達するまでの時間 Efficiency 完了タスクあたりのtoken・cost・tool call数 Quality signal Human reviewでFAILとなった割合、再実行率 model・workflow・toolのversionを軸に、変更前後の傾向を比較する © LayerX Inc. 10
11. Logsでイベントの事実を残す Logs：イベントを、発生時刻と内容で記録する 09:41:02 agent.started Agentの実行を開始 09:41:04 tool.called 資料検索toolを呼び出し 09:41:07 tool.completed toolの応答とstatusを記録 09:41:08 agent.completed 最終応答を返して実行を終了 trace_id・span_idで、Trace上の遅延・失敗箇所と該当時刻のイベントを結びつける © LayerX Inc. 11
12. 3つのテレメトリーは補完関係 Trace・Metrics・Logsは、同じケースを別の角度から見る Trace Metrics Logs どこで？ 実行経路と失敗箇所 頻度と影響範囲 該当イベント どの程度？ ケース単位の時間 全体傾向と変化 例外の件数 何が起きた？ 直前の依存関係 相関する変化 イベント時刻と内容 3つが正常でも、回答の業務上の正しさまでは確定しない © LayerX Inc. 12
13. Agent Observabilityで実行を観測する AI Agentの動きを、Agent Observabilityで観測する Datadog Agent Observability 1. Agent / LLM / toolをTraceで つなぐ 2. Metricsで全体傾向と解決時間 を見る 3. Agent TraceとAPM Traceを連 携する © LayerX Inc. Datadog Agent Observability ↗ 13
14. 問い：APM Traceだけで十分では？ この直線的な処理なら、APM Traceだけで十分では？ APM Trace Span web.request ├ auth.middleware └ agent.service ├ session.load └ postgres.query ├ retrieval ├ embedding.request └ vector_db.query ├ llm.request └ tool.call └ external_api.request © LayerX Inc. 0s 6.0s 2s 4s 6s 0.4s 5.6s 0.7s 0.4s 1.1s 0.3s 0.5s 2.1s 1.1s 0.7s 14
15. 関心を分けるためAgent Traceを追加 1つの遅い応答を、2つのTraceで分担して調べる Agent Trace Agentの判断と呼び出しを追う plan → LLM 2.1s → tool.call 5.4s どのLLM・tool callが遅いか どの選択・引数が結果へ影響したか APM Trace → 同じrequest で tool内部へ tool内部の信頼性を追う tool API 5.4s → service → DB query 4.8s DB・外部依存のlatency / error toolの内部で、どこが遅いか Agent Traceで「どのtoolか」を特定し、APM Traceで「tool内のDB遅延」まで掘る。両方を同じrequestでつなぐ。 © LayerX Inc. 15
16. 再現例：Traceだけでは正しさは分からない Traceが完了しても、回答が正しいとは限らない 実行観測では、正常に完了 しかし、業務上の結果は要確認 invoke_agent invoke_workflow completed completed retrieval chat {回答生成} execute_tool {回答登録} completed completed completed 「申請期限は翌月5日です。領収書を添付してください」 必要書類をすべて案内できているか 期限の根拠となる社内資料を参照できているか 許可された情報だけを使っているか Traceは「どう動いたか」を示す。「正しかったか」には期待結果が必要。 © LayerX Inc. 16
17. 再現例：同じ1件に期待結果を置く この1件の「正しい回答」を、先に定義する 利用者の依頼 経費申請の締切と、必要書類を社内資料から確認したい 01 目的 期限と必要書類を、漏れなく回答してい る PASS 3つをすべて満たす © LayerX Inc. 02 根拠 承認済みの社内資料が、期限と必要書類 を支えている 03 制約 許可された情報と操作の範囲を越えてい ない FAIL どれか1つでも欠ける 17
18. 再現例：Human reviewで照合する 実際の回答を、人が期待結果と照合する 実際の回答 Human review 申請期限は翌月5日です。 領収書を添付してください。 期限を資料で確認できる OK 必要書類をすべて案内した 不足 権限の範囲を守っている OK 同じ customer_support / answer_request の実行結果 判定：FAIL © LayerX Inc. 18
19. 再現例：FAILした実行をTraceで調べる FAILした1件から、調べるSpanを絞る 01 02 03 04 必要書類が1つ不足してい るためFAIL retrievalと chat {回答生成} へ絞る 必要な資料を取得したか 取得した根拠を回答へ使 ったか 検索条件・tool・prompt のどこを直すか決める Human review © LayerX Inc. Trace → Spanを確認 → 改善候補 → 19
20. 再現例から変更前後の判断へ広げる 1件の調査を、変更前後の判断へ広げる model・workflow・toolのversionを軸に、変更前後を比較する 業務品質 Outcome Human reviewのPASS率から、同じ失敗 が減ったかを見る PASSとなった完了タスク数 ÷ レビュ ー済み完了タスク数 © LayerX Inc. 解決時間 Time to resolution 依頼から、利用者が受け入れられる結果 へ到達するまでを見る request開始 → accepted result コーディングエージェントなら、着手 → tests pass / review accepted 実行効率 Efficiency 品質を保ったまま運用できるかを、コス トと安定性で見る p95 latency Cost / task Token / task Cache hit rate Error / retry rate 20
21. 現在の実行観測から、これからの品質評価へ 実行を調査できる状態から、品質を評価できる状態へ 現在 Agent Observabilityで実行を調査 1 Agent・LLM・toolの実行経路をTraceで追う 2 Agent TraceとAPM Traceを連携し、原因候補を絞る 3 latency・token・error・retryをversion別に比較する これから LLM-as-a-JudgeをHuman review基準で検証 1 少数ケースのHuman reviewでPass / Fail基準を揃える 2 LLM-as-a-Judgeの判定をHuman reviewと比較する 3 不一致から、見逃し・過検知・基準の曖昧さを確認する Judgeを正解判定者にせず、人との不一致を調べながら適用範囲を広げる © LayerX Inc. 21
22. まとめ AI Agentの正しさを、定義・観測・改善でつなぐ 01 成功と正しさを分ける 02 3つのシグナルを使い分ける Traceで1件の経路、Metricsで全体傾向、Logsでイベントの事実を捉える 03 2つのTraceを分けてつなぐ Agent TraceでLLM・tool、APM Traceでservice・DBを追い、同じrequestで相関する 04 FAILを改善判断へつなげる 期待結果とHuman reviewからTraceを調べ、品質・解決時間・実行効率を比較する © LayerX Inc. タスク完了を成功条件、目的・根拠・制約を正しさの条件として先に決める 22
23. 今日から始める順序 もし今日からオブザーバビリティを始めるなら？ 1 APMで、アプリ内部を見 えるようにする service・DB・外部依存 のlatency / errorをTrace で追う → 2 RUMで、利用者体験を捉 える 画面表示・操作・フロン トエンドerrorを利用者側 から見る → 3 RUMとAPMのTraceをつ なぐ 利用者の操作に紐づく requestから、バックエン ド処理まで辿る → 4 Agent Observabilityを 検討する Agentの判断・LLM・tool と、アプリ内部の処理を 分けて調べたいときに追 加する まずアプリと利用者体験をつなぐ。Agent固有の調査が必要になったら、観測の関心を分ける。 © LayerX Inc. 23
25. Thank you!