LLMアプリのオブザーバビリティ：本当に重要なものをログに残す

従来のアプリケーションは動くかエラーを投げるかのどちらかで、壊れたときはスタックトレースを読みます。LLMアプリケーションには、はるかに頻繁で、はるかにデバッグしにくい第三の状態があります。問題なく動き、エラーも返さず、微妙に、あるいはひどく間違った答えを生み出すのです。捕らえるべき例外はありません。LLMアプリのオブザーバビリティとは、各インタラクションについて十分な情報を捕捉し、「悪い答えを返した」を実際に調査できる問いに変える実践です。本稿では、何を、なぜ、そしてデータに溺れずにどうログするかを扱います。

なぜ通常のモニタリングでは足りないのか

従来のオブザーバビリティは、エラー、レイテンシ、リソース使用を監視します。それらは今も重要ですが、言語モデル特有の故障モードを見逃します。完全に成功した呼び出しが、間違ったコンテンツを返すというモードです。HTTPステータスは正常、レイテンシも通常どおり、何も燃えていない――それでも出力はハルシネーションで、指示から外れているか、安全でないのです。

それをデバッグするには、インタラクションの内側を見る必要があります。実行時に組み立てられた部分も含め、正確にどんなプロンプトがモデルに渡ったのか。モデルは何を返したのか。どんな文脈が取得され注入されたのか。どのバージョンのプロンプトが稼働していたのか。これらはインフラ指標からは見えません。LLMオブザーバビリティは、各インタラクションの中身を事後に検査可能にするために存在します。何かがうまくいかなかったその瞬間、唯一残る証拠はあなたがログに残したものだからです。

中核となる記録：インタラクション全体を捕捉する

基盤となるのは、何が起きたかを再構成できるほど完全な、各モデルインタラクションの記録です。最低限、次を意味します。

• 解決済みの完全なプロンプト。 テンプレートではなく、すべての変数、取得した文脈、会話履歴が埋め込まれた、実際に送られたテキスト。バグは多くの場合、書いたテンプレートではなく、組み立てられたものの中にあります。
• 完全な応答。 後処理が整形したり切り詰めたりする前の、モデルが返したものそのもの。
• モデルとパラメータ。 どのモデルか、そして温度のように振る舞いを形作る設定。同じプロンプトでもこれらで挙動が変わります。
• プロンプトのバージョン。 どのバージョンのプロンプトが稼働していたか。リグレッションを特定の変更に紐づけられるようにします。

この四つがあれば、「なぜそうしたのか」という調査の大半は扱いやすくなります。これらがなければ、推測するしかありません。規律は解決済みの状態をログに残すことです。意図したテンプレートと実際に送ったプロンプトとのあいだのギャップに、驚くほど多くのバグが潜んでいるからです。

モデル呼び出しだけでなく、連鎖全体をトレースする

現代のLLMアプリが単一の呼び出しであることはまれです。一つのリクエストが、文書を取得し、モデルを呼び、ツールを起動し、また別のモデルを呼ぶかもしれません。最終的な答えが間違っているとき、原因はどのステップにもあり得ます――不適切な検索、不正な形式のツール結果、あるいはモデル自身。

だからこそ、トレースはログと同じくらい重要です。トレースは一つのリクエストを処理する全ステップを一本のつながったタイムラインに結びつけ、入力から出力までリクエストをたどり、どこで道を外れたかを見られるようにします。間違った文書が取得されたのか。ならばモデルは不適切な文脈の上で正しく推論したわけで、修正すべきは検索であってプロンプトではありません。検索は成功したのにモデルが文脈を無視したのか。ならばまったく別の修正です。エンドツーエンドのトレースがなければ、複数ステップのシステムはほぼデバッグ不可能です。連鎖のどの環が壊れたのか判別できないからです。

時系列で見る価値のある指標

インタラクションごとの記録の先に、システムが本番で健全かを教えてくれる集計シグナルがいくつかあります。

• レイテンシ（最初のトークンまでの時間を含む）。 ストリーミング体験では、出力が始まるまでの時間こそユーザーが実際に感じるものであり、総完了時間とは区別されます。
• トークン使用量。 リクエストあたりの消費トークンはコストに直結し、プロンプトと文脈が膨らむにつれ徐々に増えていきます。これを見張れば、高コストへのじわじわとした変化を早く捕らえられます。
• エラー率と拒否率。 明白な失敗と、モデルが断ったり言葉を濁したりする、より柔らかいパターンの両方。拒否率の上昇は、調査に値するプロンプトやポリシーの問題をしばしば示します。
• スループットと処理量。 異常が際立つ基準となるベースライントラフィック。

これらは答えが良いかどうかは教えてくれません。システムが正常に振る舞っているかどうかだけです。これらは早期警戒の層です。指標が動いたら、インタラクションごとのログに行って理由を突き止めます。単一の値ではなくトレンドとして追いましょう。数値は自らの履歴と照らしてはじめて意味を持つからです。

活動ではなく品質を判断する

最も観測しにくいのは、出力が実際に良いかどうかです。比較対象となる唯一の正解が通常は存在しないからです。いくつかの実践的なアプローチで、品質を少なくとも部分的に見える化できます。

ユーザーシグナルがあれば捕捉しましょう――明示的なグッド・バッド評価や、ユーザーが再試行したり、放棄したり、出力を編集したりといった暗黙のシグナル。これらはノイズが多いものの本物で、調べる価値のあるインタラクションへ導いてくれます。代表的な入力の厳選セットを保持し、新しいプロンプトやモデルのバージョンを本番展開前にそれに対して走らせれば、本番でリグレッションを発見するのではなく、意図的に品質を比較できます。そして実際のインタラクションを定期的にサンプリングして人間がレビューします。実際の出力を少量、ルーティンとして読むだけで、どの指標も表面化させないドリフトを捕らえられます。要点は判断を完全に自動化することではなく、手探りで飛ぶのをやめることです。

責任あるログ取り

完全なプロンプトと応答を捕捉するということは、ユーザーが入力したものをすべて捕捉するということです――そこには個人情報や機密情報が含まれ得ます。オブザーバビリティが、ひっそりとしたデータ保持の問題になってはいけません。

最初からプライバシーを組み込みましょう。何が保存されているかを把握し、可能な場所では機密フィールドをマスクするか保存を避け、ログが永遠に蓄積されないよう保持期限を設定し、誰が読めるかを制御します。ここには本物の緊張関係があります。ログが豊かであるほどデバッグは良くなり、それらが漏れたときの露出も大きくなります。偶然ではなく意図的に解決しましょう。OpenAIとAnthropicのプロバイダードキュメントは彼ら自身のデータ取り扱いを記述しており、それも全体像の一部ですが、あなたが保存するものを統治するのはあなたの責任です。

小さく始めて育てる

初日から完全なオブザーバビリティプラットフォームは不要で、必要だと思い込むのは結局始めないための良い口実になります。まずは、すべてのインタラクションについて中核となる記録――解決済みプロンプト、応答、モデル、プロンプトのバージョン――をログに残すことから始めましょう。その一歩だけで、初期のデバッグの大半が可能になります。システムが単一呼び出しを超えて成長したらトレースを追加します。トレンドが意味を持つだけのトラフィックが集まったら集計指標を追加します。プロンプトとモデルを本格的にチューニングし始めたら品質評価を追加します。各層はその場所を勝ち取ります。一度にすべてではなく、アプリケーションが実際に成長する順番で組み込みましょう。

まとめ

LLMアプリは、従来のモニタリングでは見えない仕方で失敗します――成功した呼び出しが間違った答えを返すのです――だからオブザーバビリティは、周囲のインフラだけでなく、各インタラクションの内側を見なければなりません。解決済みの完全なプロンプトと応答を、モデルとプロンプトのバージョンとともにログに残し、複数ステップのリクエストをエンドツーエンドでトレースし、レイテンシとトークン使用量をトレンドとして見張り、品質を仮定するのではなくサンプリングする方法を見つけましょう。最初からプライバシーを設計に組み込み、システムの成長に合わせて層を育てます。報酬は、「悪い答えを返した」が肩をすくめるだけのものではなくなり、答えられる問いになることです。