AI Agent Agentic Workflow の可観測性 / Observability of AI Agent Agentic Workflow

Transcript

1. AI Agent / Agentic Workflow の可観測性 AI Agents in Production #1 2026/01/15 Joe/@joe_yuzupi
2. 自己紹介
3. Joe (Yuzuru Ohira) © LayerX Inc. About Me 株式会社 LayerX Ai Workforce 事業部 テクニカルプロジェクトマネージャー 2025/7~ 趣味: ゴルフ(昨年40ラウンド前後) シングルになりたい。 。 。 3
4. 事業紹介 © LayerX Inc. 4
5. 一緒にイシューを解決してくれる仲間を募集しています © LayerX Inc. We're hiring! LayerX Ai Workforce 事業部 採用情報ページ 5
6. 本日の流れ
7. アジェンダ © LayerX Inc. 本日の流れ Ai Workforce と Agentic Workflow なぜ可観測性が難しいのか 取り組み まとめ 7
8. 話すこと 話さないこと © LayerX Inc. 本日の流れ Ai Workforce と Agentic Workflow なぜ可観測性が難しいのか 取り組み まとめ ツールや技術の比較 8
9. Ai Workforce と Agentic Workflow
10. AI Workflow から Agentic Workflow へ 従来の AI Workflow（ルールベース） © LayerX Inc. Ai Workforce と Agentic Workflow 当初はルールベースの AI Workflow を構築 より広い業務領域をカ バーするために柔軟な 判断が必要に Agentic Workflow へ の移行を決断 10
11. Agentic Workflow とは 従来の決定論的なワークフローと、 自律的だが非決定論的な AI Agent の中間に位置づ けられるシステム 固定的なワークフローに、状況に応じて計画を柔軟 に組み替えるエージェント的なメカニズムを組み合 わせた 「半決定論的」 なアプローチ © LayerX Inc. Ai Workforce と Agentic Workflow 11
12. AI Agent と Agentic Workflow 比較軸 AI Agents Agentic Workflows 定義 与えられた目標に基づき、必要な手順を自ら立案・実行する自 律的システム 大枠のフローは人間が設計し、内部の判断・修正・最適化を AI が 担う仕組み 自律性のレベル 高い：次に何をするか自律的に決める 中程度〜高い：手順の構造は固定だが、ステップ内判断は AI が行 う 手順・計画決定の 主体 AI 自身（環境を観察し計画を立てる） 人間が大枠を設計し、AI はその中で判断を最適化 柔軟性 高い（予期せぬ状況にも対応しやすい） 一定の柔軟性（フロー内で判断・修正できる） 予測可能性 低め（動的に振る舞う可能性があり予測困難） 高め〜中（フローが固定なので比較的予測可能） 制御・信頼性 低め〜注意が必要（無限ループなどのリスクあり） 高い（大枠が固定されていて制御しやすい） AI の役割 ゴール達成のための計画立案／実行主体 あらかじめ決められたステップ内で判断・調整を担当 典型的な特徴例 行動順序を自ら決める、計画の立案・実行・修正まで担う 設計された一連の流れの中で、AI が「どの分岐を選ぶべきか」な どを判断 引用: https://www.youtube.com/watch?v=Qd6anWv0mv0 © LayerX Inc. Ai Workforce と Agentic Workflow 12
13. なぜ可観測性が難しいのか
14. なぜ可観測性が難しいのか → 従来のステップ実行モデルとは根本的に異なる © LayerX Inc. なぜ可観測性が難しいのか 非決定性: 同じ入力でも異なる出力になり得る 非同期処理: 複数の処理が並行して進む 動的分岐: LLM の判断で処理経路が変わる 14
15. 従来の Observability 3つの柱 柱 役割 Metrics 数値指標（レイテンシ、エラー率） Logs イベントの記録 Traces リクエストの流れを追跡 → 「何が起きたか」は分かりやすい → なぜそうなったかは別の話 © LayerX Inc. なぜ可観測性が難しいのか 15
16. しかし AI Agent / Agentic Workflow では足りない 従来の可観測性では見えないもの： © LayerX Inc. なぜ可観測性が難しいのか なぜその判断をしたか（意思決定の根拠） どの選択肢を検討したか（判断経路） 失敗がエージェント起因か、それともツール起因か（帰属） 16
17. 非同期境界の多さ 例: Ai Workforce の Agentic Workflow アーキテクチャ © LayerX Inc. なぜ可観測性が難しいのか 各境界でコンテキストが途切れるリスク → workflow_run_id / span_id の伝播が鍵 17
18. 分岐理由の説明が困難 請求書 → LLM 判定 → 要確認 ❓ なぜ？ 判断プロセスがブラックボックス © LayerX Inc. なぜ可観測性が難しいのか AI の判断理由がログでは見えない 「なぜこの請求書を要確認と判定した か」 「なぜこの項目を自動抽出できなかった か」 「なぜこの勘定科目を消耗品費と判断し たか」 18
19. 原因特定が困難 → 観測可能な状態ではなく説明可能な状態を目指したい © LayerX Inc. なぜ可観測性が難しいのか 失敗・遅延がどのレイヤー起因か追いにくい LLM？DB？外部API？ネットワーク？キュー滞留？ 複数のコンポーネントが絡み合い、エラーが伝播 ノイジーネイバー問題: 特定テナントの過剰な LLM コールが全体に影響 19
20. 取り組み
21. 分散トレース（遅延の特定） Workflow Run └ Task A (OCR抽出) └ DB Read (ドキュメント取得) └ LLM Call (項目抽出) └ DB Write (結果保存) └ Task B (仕訳判定) └ LLM Call (勘定科目判定) └ External API (会計システム) └ DB Write (仕訳保存) © LayerX Inc. 取り組み + 3.2s 1.3s 120ms 850ms 80ms 1.8s 720ms 580ms 150ms 可観測性は開発環境から、開発環境にもオブザーバビリティ導入のススメ 21
22. 非同期境界の伝播 © LayerX Inc. 取り組み 非同期処理間でコンテキストを伝える trace_id / parent_id / workflow_run_id を必ず引き継ぐ キューイング時もヘッダーに含める 22
23. Span Links で非同期処理を繋ぐ 親子関係を作らず、トレース間の関係性を表現 © LayerX Inc. 取り組み API がジョブ投入 → 別プロセスのワーカーが実処理 親子関係ではなくリンクで関連性を追跡 Ai Workforce では Assistant Orchestrator 間で活用 23
24. Span Links 実装例 キューに載せる情報 → 詳細: tech.layerx.co.jp/entry/ai-agent-span-links © LayerX Inc. 取り組み traceparent / tracestate （W3C標準） Producer の SpanContext（trace_id / span_id） 24
25. 実例: Span Links の双方向リンク API側トレース → Forward Backward ← Worker側トレース © LayerX Inc. 取り組み 25
26. 属性設計 後追い分析・フィルタリングのための属性： 属性 用途 workflow_run_id 1回の実行を一意に識別 task_type タスクの種類でフィルタ tenant_id テナント（顧客）単位の分析 workspace_id Workspace 単位の分析 model_name 使用した LLM モデル decision_path 判断経路の記録 © LayerX Inc. 取り組み 26
27. イベントログ設計 状態変化をイベントとして記録 → 長時間実行や停滞を検出可能に © LayerX Inc. 取り組み task_started / task_completed / task_failed llm_request_sent / llm_response_received decision_made (判断内容と根拠) 27
28. 計画中: APM と AI Agent 間の相互連携トレーシング Application (APM) ↓ trace_id / parent_id ↓ AI Agent (LLM Observability) ┌───┼───┐ Task A Task B Task C © LayerX Inc. 取り組み 既に APM 等が導入済みのため、 シームレスな連携を期待 Datadog LLM Observability の導 入を検討中 datadoghq.com/blog/monitor-ai-agents 28
29. Tips: 開発環境から導入する 可観測性は開発環境から、開発環境にもオブザーバビリティ導入のススメ © LayerX Inc. 取り組み 可観測性は本番環境だけでなく開発 環境から導入する 開発時から計装を意識することで、 本番投入後のデバッグが容易に ローカル環境でも可視化できる環境 を整備 29
30. まとめ
31. これからやっていくこと テーマ 内容 スケール/SLO SLO に基づいた可用性・スケール設計 ツール/モデル増加 標準化された観測設計が必要に 監査/ガバナンス 「何がどこで起きたか」を証明する必要性 © LayerX Inc. まとめ 31
32. まとめ © LayerX Inc. まとめ 半決定論的な設計で観測ポイントを設計可能に 従来の Observability + 意思決定の観測が必要 階層的 Trace / イベントログ / Timeline で実現 観測可能な状態ではなく説明可能な状態を目指す 32
33. ご清聴ありがとうございました