LLMワークフローのオブザーバビリティ設計｜ログだけでは足りない本番運用の観測戦略

LLMオブザーバビリティとは、プロンプトや応答だけでなくワークフロー全体の挙動を計測・追跡する仕組みである。

結論から言えば、本番で動くLLMシステムに「プロンプトとレスポンスをログに残す」だけでは足りない。リトリーバル、ツール呼び出し、ガードレール、フォールバック、評価ループが絡み始めた瞬間、会話ログは「何が起きたかの断片」でしかなくなる。必要なのは会話の記録ではなく、ワークフローの計測。この違いを理解しないまま本番に出すと、遅い・高い・たまに壊れるという三重苦を前に原因究明の手がかりが消える。

本記事は、LLMを組み込んだプロダクトを開発・運用しているソフトウェアエンジニア向けに、観測設計を「監視ツール導入」の話ではなく「デバッグとシステム設計の問題」として再定義する実装指針です。Mediumで公開された観測設計に関する記事の骨子に、Anthropicのハーネス設計に関する考察や、自律エージェント開発における実践的な知見を織り込みながら進めていきます。

LLMオブザーバビリティとは何か

LLMオブザーバビリティは、単にAPIの入出力を保存することではありません。リクエストがシステムに入ってから応答が返るまでの、すべての中間状態を再現可能な形で計測する設計思想。これが本節の核。

会話ログとワークフロー計測の違い

多くのチームが最初にやるのは、プロンプトとレスポンスをデータベースに突っ込む方式です。これで「何を聞かれて何を返したか」は追える。ただし、なぜその応答になったのかは追えません。

RAGシステムを例にとりましょう。ユーザーが質問を投げた瞬間、システム内部ではクエリ書き換え、ベクトル検索、コンテキスト構築、プロンプト組み立て、モデル呼び出し、後処理、ガードレール判定、場合によってはフォールバックが連続で走っています。このうちどの段階で遅延が発生したのか、どの検索結果が採用されたのか、どのテンプレートでプロンプトが組まれたのか。会話ログだけでは一切見えません。

ワークフロー計測とは、この中間段階を「スパン」として構造化し、時系列と因果で結びつける設計のこと。この文脈でしばしば強調されるのが、「多くのチームは会話を記録しているが、ワークフローを計測しているチームは非常に少ない」という指摘であり、これが本質を突いています。

なぜ既存の監視ツールだけでは足りないのか

DatadogやNew RelicのようなAPMツールは優秀ですが、LLM特有の観測対象をネイティブに扱えるわけではない、という現実があります。従来のWebサービスなら、リクエスト数・レスポンスタイム・エラー率で大半の異常が検出できました。しかしLLMでは、同じリクエストに対して結果が毎回違う、エラーにならずに「それっぽく間違っている」、コストが予測不能に跳ね上がる、といった新種の障害モードが発生します。

また、開発者コミュニティで議論されているハーネス設計（Harness Design）の文脈では、「モデル自体ではなく、モデルを取り巻くハーネス（オーケストレーション層）こそが差別化要因になる」という主張が展開されています。ハーネスが差別化要因ということは、観測対象もハーネスに移るという話。モデルのAPIを叩く一行だけ見ていても、何も分かりません。

既存監視ツールが扱うのは「リクエスト/レスポンス/ステータスコード」のHTTP層。LLMワークフローの観測は、その一段内側にある「検索・プロンプト・ツール呼び出し・評価」の層に手を入れる必要がある。この内側の層を可視化する作業が、LLMオブザーバビリティの実体です。

トレース・ログ・メトリクスの三層設計

観測性の世界には古くから「トレース・ログ・メトリクス」という三種の神器があります。LLMワークフローでも例外ではなく、この三つを組み合わせて初めて使い物になる観測基盤が完成します。どれか一つでは不十分。

それぞれが答える問いの違い

三層がそれぞれ何の問いに答えるのかを整理しておきましょう。ログは「何が起きたか」の点情報。メトリクスは「全体としてどういう傾向か」の集計値。トレースは「一つのリクエストがシステムをどう駆け抜けたか」の因果関係。

種別	答える問い	LLMでの具体例
ログ	何が起きたか（点情報）	プロンプト本文、応答テキスト、エラーメッセージ
メトリクス	全体傾向はどうか（集計値）	秒間リクエスト数、平均レイテンシ、トークン消費量
トレース	1リクエストがどう流れたか（因果）	検索→プロンプト組立→モデル→ツール呼び出しのスパン連鎖

LLM固有の事情として、トレースの重要度が他のシステム以上に高い、という点を強調しておきたいところ。なぜなら「なぜ遅いのか」「なぜ高いのか」「なぜこの応答が返ったのか」という質問は、単一ログでもメトリクスでも答えられず、必ず「リクエスト全体の経路を追う」という作業になるから。

スパン設計の粒度

トレースを入れるなら、スパンの粒度設計が実質的な勝敗を決めます。粗すぎると「モデル呼び出しに3秒かかった」としか分からず、細かすぎるとストレージと可読性がともに崩壊する。経験則として、以下の粒度で区切ると扱いやすい。

• リクエスト受信から応答送信までの全体スパン（ルート）
• リトリーバル（クエリ書き換え・ベクトル検索・リランキング）
• プロンプト構築（テンプレート選択・コンテキスト結合・トークン数計算）
• モデル呼び出し（プロバイダ別に分ける）
• ツール呼び出し（各ツール1スパン）
• バリデーション・ガードレール
• フォールバック発動時の代替経路

各スパンには入出力・所要時間・使用リソースを属性として持たせます。OpenTelemetry形式に寄せておくと、既存の可視化ツールに流し込めるので後が楽。

トレースとログを別々のシステムで管理しているチームも多いですが、両者はトレースIDで紐付けるのが鉄則です。「このリクエストのプロンプト本文を見たい」と思ったときにトレースからログへジャンプできないと、結局grepで探す作業に戻ってしまう。メトリクスもトレースのサンプリングから生成すると一貫性が保ちやすくなります。

ワークフロー各段階で計測すべき項目

ここからは実装寄りの話。リクエスト受信から応答送信までを段階ごとに分解し、各段階で何を記録すべきかを具体的に示していきます。この設計をスプレッドシートに起こしてチーム内で合意しておくと、後からの分析が格段に楽になります。

リクエストとリトリーバル

最初に押さえるのはリクエスト側の情報。ユーザーID、セッションID、スレッドID、タイムスタンプ、そして入力テキスト。ただし入力テキストはプライバシー観点で要検討（詳細は後述します）。

リトリーバル段階で記録すべきは以下。

• クエリ書き換え後のテキスト（元クエリと別に保存）
• ベクトル検索のトップK件のドキュメントID・スコア
• 検索にかかったミリ秒
• リランキングの入出力（使っている場合）
• 最終的にプロンプトに投入されたチャンクID一覧

「検索がおかしい」というバグ報告が来たとき、上記があれば再現可能。なければ、本番環境で同じクエリを再実行して検索結果を見る、という再現困難な作業になります。

プロンプト構築とモデル呼び出し

プロンプト構築段階で計測すべきは、どのテンプレートのどのバージョンを使ったか、コンテキストに入れたチャンクの合計トークン数、最終プロンプトのトークン数、そしてテンプレート変数に何を埋めたか。テンプレートのバージョン管理を観測データと紐付けると、「バージョンX.Yに上げた瞬間に応答品質が落ちた」という切り分けが一瞬でできるようになります。

モデル呼び出し段階では、プロバイダ名、モデル名、モデルバージョン、温度などのパラメータ、入力トークン数、出力トークン数、レイテンシ、エラーの有無、リトライ回数を記録します。マルチプロバイダ構成の場合、どのプロバイダがどの頻度で呼ばれているかが見えないとコスト管理が破綻します。

ツール実行・バリデーション・フォールバック

エージェント的なワークフローではツール呼び出しが発生します。ここで記録すべき項目は、呼び出されたツール名、引数、結果、成功/失敗、所要時間、そしてツール側のログIDへの参照。ツールの中身（DB検索、外部API、コード実行など）はそれぞれ独立した観測対象を持っているので、ツールIDから向こう側のトレースに飛べる設計にしておくと便利。

バリデーション段階では、スキーマ検証の結果、JSONパース成功率、構造化出力の整合性チェック結果を記録。フォールバック発動時は、なぜ発動したか（タイムアウト、バリデーション失敗、ガードレール違反など）と、代替経路が何を返したかを必ず残します。フォールバックは最後の砦なので、発動頻度と発動理由がモニタリングされていないシステムは危険。

まとめると、一回のリクエストで残すべき情報は「誰が・いつ・何を聞き・どう検索され・どう組み立てられ・どのモデルが・何秒で・何トークン使って・どのツールを叩き・何を返し・どの検証を通り・フォールバックが起きたか否か」という流れ全体。この全体が一つのトレースとして閲覧できて初めて、本番デバッグが現実的なものになります。

レイテンシとコストを分解して追う

「遅い」と「高い」はLLMシステムが最も頻繁に問われる二つの問い。どちらも、合計値だけ見ていても原因は分からず、必ず段階分解が必要になります。

ステージ別レイテンシ分解

ユーザーから見た応答時間が5秒かかっているとき、その内訳は毎回違います。リトリーバルが2秒なのか、モデル呼び出しが4秒なのか、ツール実行が3秒なのか。トレースの各スパンに所要時間が記録されていれば、ダッシュボードでステージ別の内訳を集計できます。

推奨する可視化のかたち:

• 総レイテンシのp50/p95/p99
• 各ステージのレイテンシをp95で積み上げ表示
• ステージ別の分散（同じステージでもリクエスト間のばらつきが大きいと問題）
• タイムアウトが発生した場合の発生ステージ

実務でよく起きるのが、平均値ではリトリーバルが遅く見えるけれど、p99で見ると外部API呼び出しが支配的になっている、というパターン。平均だけ見ていると真犯人を見逃します。

ストリーミング応答を使っている場合、TTFT（Time To First Token）とTBT（Time Between Tokens）を分けて計測する必要があります。ユーザーの体感速度は合計秒数ではなくTTFTに強く依存するため、TTFTがメトリクスに入っていないダッシュボードはユーザー体験の代理指標になりません。

トークンとコストの可視化

コスト観測の基本は、トークン使用量をすべてのモデル呼び出しスパンに記録すること。入力トークン・出力トークン・キャッシュヒット分を分けて保存します。モデルごとに単価が違うので、記録時ではなく集計時にコスト換算する方式が管理しやすい。単価を一元管理しておけば、プロバイダの値下げ・値上げに合わせてダッシュボードを再集計できます。

コスト可視化で押さえたい軸は以下。

• モデル別の月間コスト
• エンドポイント別（機能別）の月間コスト
• ユーザー別・テナント別のコスト（BtoB SaaSの場合は特に重要）
• キャッシュ削減量の可視化（キャッシュを入れたROIを示すため）
• 1リクエストあたりの平均コストと、その時系列推移

1リクエストあたりコストが時系列で急増していたら、プロンプトが肥大化しているか、リトリーバル件数が増えているか、フォールバックが高頻度で発動しているか、のいずれかが疑われます。この三つはどれも観測データで切り分け可能。

一般的に、運用が長期化すると複数の階層（個人・チーム・組織レベル）で記憶コンテキストが肥大化し、階層化と自動剪定が必要になります。記憶の肥大化は、そのままプロンプト長の肥大化とコストの肥大化に直結します。トークン使用量の時系列をモニタリングしていれば早期に検知できる類の問題であり、観測設計の具体的なユースケースとして覚えておく価値があります。

コスト観測を先送りにすると、月初に請求額を見て青ざめる、という恒例行事が発生します。観測データがあれば「どの機能がコストを食っているか」が即座に分かり、削減優先順位も自明。実装コストは初期に入れておくのが圧倒的に安上がりです。

エージェント・ツール呼び出しの可視化

観測性の議論でモデルそのものに目が行きがちですが、実は本番で問題を起こすのはモデル周辺のオーケストレーション層。LLMが呼び出すツール、エージェントが選んだ分岐、ハーネスがリトライした履歴——この層の挙動が見えないと、「なぜエージェントがこの答えにたどり着いたのか」を後追いできません。

モデルの知能そのものではなく、その周りを固めるハーネス設計が AI エージェントの実用性を左右する要素として注目されつつあります。観測対象もこの構造に合わせるべき。ログに残すのはモデル呼び出し1回ではなく、ハーネスがその1回を呼ぶに至った過程ごと記録する必要があります。

ツール呼び出しトレースの設計

エージェントがツールを呼ぶたびに、次の情報をスパンとして残すのが基本形です。

• 呼ばれたツール名と引数
• ツールが返した生レスポンス（ペイロードサイズが大きい場合はハッシュ＋一部抜粋）
• 呼び出し結果をエージェントがどう解釈したか（次のプロンプトに何を入れたか）
• ツールの実行時間と失敗有無
• 同一セッション内で何回目の呼び出しか

特に重要なのが「エージェントがツール結果をどう使ったか」の記録。ツールが正しい値を返しているのにエージェントが無視している、というケースは珍しくありません。この切り分けはツール側ログとエージェント側ログを突き合わせないと判別不能。スパンをツリー構造で紐づけておけば、トレースビューで一目で追えるようになります。

もう一つの勘所が、ツール呼び出しループの検知。同じツールを短時間に何度も呼び続けているエージェントは、たいてい何かに詰まっています。スパンの親子関係とタイムスタンプから自動的にループを検出し、アラートを飛ばす仕組みが欲しいところ。

長期実行エージェントで壊れる箇所

長時間走るエージェントは、短時間タスクとは違う壊れ方をします。Dev.toで紹介された28エージェント単一サーバー運用の報告では、Slackメッセージ50000件以上を処理する中で、記憶の肥大化と矛盾したフィードバックが具体的な障害として顕在化したとされています。投稿者は個人・チーム・チャネル・会社レベルの階層的メモリと自動剪定を導入し、さらに「修正」を昇格プロセス化してチーム全体に共有する仕組みで対応したと報告しています。

この事例から読み取れる観測設計上の示唆は明快。長期運用エージェントでは、次の軸を常時モニタリングしておく価値があります。

• コンテキスト長の時系列推移（メモリ肥大化の早期検知）
• エージェントが受け取ったフィードバックの内容と矛盾検出
• 同じタスクの自己修正回数（過剰修正ループの検知）
• エージェントが参照しているメモリのソースと鮮度

観測していれば検知できた、というのは事後に言えば何とでもなりますが、この種の障害は「静かに悪化して、ある閾値を越えた瞬間に全体が詰まる」タイプ。時系列メトリクスを取っていれば傾きの変化で気づけた可能性が高いパターンです。

なお、エージェント運用における観測不足と設計不良の関係については、別記事「AIエージェント失敗の88%はモデルのせいではない｜真因は「コンテキスト設計」にある」でも扱っています。コンテキスト設計と観測設計は表裏一体の関係にあり、どちらか片方だけを詰めても本番で詰まります。

プロンプト・モデル・セッションの系譜管理

観測データは「取ること」より「後で辿れること」が本質。プロンプトのバージョン、モデルのバージョン、セッションの連続性——これらが紐づいていないと、「2週間前の月曜日の深夜に起きた例のバグ」を再現できません。

バージョン追跡の必要性

プロンプトは生き物。A/Bテストで差し替えたり、ユーザーごとに動的に組み立てたり、時間帯で変えたりすることが当たり前にあります。モデルも同様で、プロバイダ側が予告なくマイナーアップデートする場合もある。どちらのバージョンで実行された推論か分からないと、デバッグは手詰まりになります。

最低限記録すべきは以下の情報。

プロンプトテンプレートID	テンプレート名＋ハッシュまたはセマンティックバージョン
モデル識別子	プロバイダ名＋モデル名＋バージョン文字列（プロバイダが返すメタデータをそのまま保存）
生成パラメータ	temperature、top_p、max_tokens等の設定値
コンテキスト構成	どのメモリ・RAG結果・システムプロンプトが組み込まれたか

プロンプトテンプレート本体はハッシュで紐づけ、本文はバージョン管理リポジトリに保存する設計が現実的。全ログにプロンプト全文を埋め込むとストレージが跳ね上がるうえ、個人情報混入リスクも増えます。

ユーザー・セッション単位の相関

一回の問い合わせで問題が起きることは少なくて、実際は「セッションの3ターン目あたりから挙動が変」というパターンが多い。トレースをユーザーID・セッションID・スレッドIDで相関できるようにしておくと、会話の流れごと再現できます。

相関IDの設計で踏みやすい地雷が二つ。一つ目は、匿名ユーザーと認証済みユーザーのIDが非対称になり、途中で切り替わったセッションを追えなくなるケース。二つ目は、フロントエンドで生成したトランザクションIDがバックエンドに伝播せず、途中のスパンが親子関係を失うケース。前者は匿名ID→認証済みIDのマッピングテーブルで解決、後者はリクエストヘッダーとキュー経由の伝播ルールを最初に決めておくこと。

ガードレール・評価・フィードバックループ

観測の最終目的は、監視ダッシュボードを眺めることではなく、システムを継続的に改善するサイクルを回すこと。ガードレール発動、フォールバック発動、ユーザー評価——これらを計測対象に組み込んで初めて、観測データが改善に接続されます。

ガードレールとフォールバックの発動追跡

ガードレールが発動した回数は、単なるエラーカウントではありません。「モデルが危険な出力を生成しようとしたが止めた」という貴重なシグナルで、プロンプト脆弱性やモデル挙動の変化を知る手がかりになります。

記録すべきは以下。

• どのガードレールが発動したか（PII検知・トキシシティ・プロンプトインジェクション等）
• 発動したときの入力と、ブロックされた出力
• 代替として返したレスポンス（フォールバック結果）
• 同一ユーザー・同一セッションでの発動頻度

フォールバックの発動についても同じ考え方。「主モデルがタイムアウトしたから安いモデルに切り替えた」「JSON構造検証に失敗したから再生成した」等の経路は、品質低下の前兆としてダッシュボードに載せるべきです。フォールバック発動率が急上昇していたら、主モデル側で何かが起きているサイン。

ユーザー体験シグナルの回収

Did the answer actually help the user? ——元記事が投げかけたこの問いは、観測設計の根幹を刺します。技術的に成功したリクエストでも、ユーザーにとって無価値だったら意味がない。次のようなシグナルを拾って、品質メトリクスとして可視化しましょう。

• 明示的な評価（サムズアップ/ダウン、5段階評価）
• 暗黙の評価（回答コピー、フォローアップ質問の有無、セッション継続時間）
• リトライ行動（同じ質問を言い換えて再投入しているか）
• 手動介入（ユーザーが手で編集したレスポンス内容）

暗黙シグナルは解釈に注意が要ります。「セッションが短い」のが満足によるものか離脱によるものかは一意に判別できません。それでも、時系列で相対変化を追えば、プロンプトやモデル差し替えがユーザー体験に与えた影響を統計的に読み取れます。

フィードバックループを閉じるなら、これらのシグナルを評価データセット構築に還流する仕組みまで入れ込むのが理想。低評価だった会話ログを自動的にラベリング候補キューに送り、定期的に評価用データセットとして整備する。観測データが改善の燃料になる設計です。

プライバシーと現場導入の現実

ここまで書いた全てを一気に実装できるチームは、現実にはほぼ存在しません。Reddit r/automationで共有された議論では、AI実装現場はデータの断片化、触りたくないレガシー、ドメイン知識と技術理解を併せ持つ人材の慢性的不足、ツールの進化速度と安定化のジレンマを抱えていると指摘されています。投稿者の主張では、経営層の40%以上が投資正当化に苦しんでいるとも報告されています（Redditの議論ベース、一次ソース未確認）。

記録と匿名化のバランス

観測ログはデバッグの宝箱である一方、個人情報・企業秘密・医療情報を吸い込む危険な器でもあります。記録と匿名化のバランスは、次の三層で整理すると設計しやすい。

1. 層1: 生ログ（短期保管・強アクセス制御）——インシデント調査のみに使用、保管期間7〜30日
2. 層2: 匿名化ログ（中期保管）——PIIを検出・置換した状態、統計分析と評価データ作成に使用
3. 層3: 集計メトリクス（長期保管）——個人識別情報を一切含まない、ダッシュボードとトレンド分析に使用

PII検知は既存ライブラリで下地を作り、自社固有のパターン（顧客ID形式、内部プロジェクトコード等）をカスタムルールで追加していく構え。完璧な匿名化は目指さず、アクセス制御とのセット運用でリスクを下げる設計が現実解です。

段階導入のすすめ

観測設計を全部一気にやろうとすると、導入前に疲弊します。現場の実態を踏まえるなら、次の順序で段階導入するのが最短ルート。

最初にやるべきは、モデル呼び出しの入出力とトークン数・レイテンシ・コストの記録。これだけで「なぜ遅い・なぜ高い」の6割は説明できるようになります。

次に、リトリーバルのトレースとツール呼び出しのスパン化。RAG・エージェント系の障害の多くはこの層で起きます。

三番目に、プロンプト/モデルのバージョン管理とセッション相関。再現性のあるデバッグが可能になるフェーズ。

最後に、ガードレール・ユーザー評価・フィードバックループ。改善サイクルを回す体制が整った段階で取り組むのが現実的です。

段階導入の各ステップで「これだけでも入れたらどの問いに答えられるか」を明確にしておくと、経営層への説明もしやすくなります。観測はコストではなく、デバッグ時間短縮と障害対応時間短縮の投資。そう位置づけられるかが、社内合意形成の分水嶺。

よくある質問

Q. 既存のAPMツール（Datadog、New Relic等）だけで足りますか？

一般的なリクエスト・レイテンシ・エラー率の可視化には十分ですが、LLM特有の観測軸（トークン使用量、プロンプトバージョン、リトリーバル品質、ツール呼び出しトレース）は標準機能でカバーされません。既存APMにLLM専用の計装を足すか、Langfuse・Helicone・Phoenix等のLLM特化ツールを併用する構成が現実的です。

Q. 最小構成で始めるなら、まず何を記録すべきですか？

モデル呼び出しごとの入力・出力・トークン数・レイテンシ・コスト・モデルバージョンの6つを、セッションIDと紐づけて保存するところから。これだけで「なぜ遅い・なぜ高い・なぜ変な答えが出た」の大半を事後調査できます。ストレージも1日あたり数百MB〜数GB規模で済みます。

Q. 観測データでインフラコストはどれくらい増えますか？

プロジェクトや記録粒度によって変動しますが、目安としてLLM運用コストの10〜20%増を見込む構えが無難。トークン単価が高いモデルを使っている場合は相対的に観測コスト比率が下がります。層別保管（生ログは短期、集計は長期）を徹底すればさらに圧縮可能。

Q. プロンプトそのものをログに全文保存すべきですか？

個人情報が混じる可能性があるならハッシュ＋バージョンIDで参照する方式が安全。本文はバージョン管理リポジトリに一元保存し、ログからは参照だけ行う設計が扱いやすいです。デバッグ時には必要に応じて本文を復元する運用。

Q. オープンソースの観測ツールと商用SaaSはどちらを選ぶべき？

LangfuseやPhoenixなどOSSは自社ホスティング可能で機密データを外に出さずに済む利点があります。商用SaaSは初期構築コストが低くダッシュボードが充実。センシティブデータを大量に扱う場合はOSS自前運用、スピード優先のスタートアップならSaaS、という使い分けが標準的です。

まとめ

本番運用のLLMワークフローで観測性を語るとき、会話を記録するだけでは足りません。ワークフロー全体を計測するという発想の転換が必要。リクエスト受付からリトリーバル、プロンプト構築、モデル呼び出し、ツール実行、バリデーション、フォールバック、レスポンス返却まで、各段階をスパンに分解して記録する設計が出発点です。

観測の目的はダッシュボードを飾ることではなく、「なぜ遅いか」「なぜ高いか」「なぜ間違ったか」「ユーザーに役立ったか」に答えられる基盤を作ること。段階導入でもいい、完璧でなくてもいい、まずはモデル呼び出し単位のトークン・レイテンシ・コストをセッションIDで紐づける、そこから始めるのが最短ルート。会話を記録するフェーズから、ワークフローを計測するフェーズへ——この移行ができたチームだけが、本番LLMシステムを継続的に改善できる場所に立てます。

AI自動化の全体像

• オブザーバビリティを量産型 4 層に組み込む → 量産型AI自動化の4層構造 ─ ストックフォト動画系で動かしている中身
• AI自動化が稼げるかのハブ記事 → 2026年版｜AI自動化は本当に稼げるのか？

本記事は AIツール図鑑編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。