Article by: Rahul Chhabria
最新の AI エージェントをプロダクトに組み込み、リリースして、あとは寝るだけ。ところが起きてみると、空文字を返していたり、昨日より 5 秒も遅くなっていたり、あるいは「完璧な JSON」の体裁で堂々と嘘を出していたりしています。
当然、ログを確認します。
プロンプトはある。レスポンスもある。……でも、肝心の手がかりが何もない。
驚きますよね。プロンプト入力とレスポンス出力だけでは、オブザーバビリティとは言えません。あれは雰囲気です。
「LLM のオブザーバビリティ」は今かなり話題です。ただ、実態は「要らないチャート」と「そのうち見なくなるダッシュボード」が増えるだけ、というケースも少なくありません。もしあなたが実際に、チャットボットや社内エージェント、検索・取得アプリなど、LLM を組み込んだプロダクトを作って運用しているなら必要なのは観測です。しかも、肝心なところに差し掛かった瞬間に途切れるような観測ではなく、原因まで辿れる観測です。
何を追うべきか。いつ追うべきか。なぜそれが重要なのか。中身のない補完にうっかり 5,000 ドル払う前に、順番に整理していきましょう。
ステージ 1：本番前
（別名：「プロンプト墓場」）
今、プロトタイプを作っている段階だとします。ノートブック、ベクターストア、OpenAI API キー、そして夢もある。必要なのはダッシュボードではなく、壊れたプロンプトを必死に救い出すためのログです。
何をログに残すべきか
この段階でデバッグしているのは、ユーザーというより自分自身です。なので、以下をログに残しましょう。
- プロンプト全文とレスポンス全文
- モデル名、temperature、function schema のバージョン
- トークン使用量とレイテンシ
- プロンプトのバージョンを特定できる情報（何でもいいので）
プロンプトのバージョン管理に気の利いた仕組みは要りません。コミットハッシュで十分です。付箋でもいい。とにかく、何が変わったのか忘れる前に書き留めておきましょう。
当面はこれで済むツール類
- JSON ファイル
- Postgres のテーブル
- 構造化ログを使った Sentry
- Traceloop（そういうのが好きなら）
ここでの唯一の目的は「変な挙動」を再現できるようにすることです。何かが爆発しても、5 分以内に説明できるなら勝ちです。
ステージ 2：本番（Production）
（いまや「誰か別の人」の問題）
アプリは公開されました。どこかの誰かが、入力欄にとんでもないものを打ち込んでいます。ここから先は楽観的だったプロトタイプが、リトライ嵐、古い埋め込み、そして頼んでもいない LLM の挙動変化に満ちた「お化け屋敷」に変わっていきます。
何を監視すべきか
この段階でデバッグしているのはモデルそのものではありません。モデルの周辺にあるあらゆるものです。
レイヤー | 壊れやすいポイント |
|---|---|
フロントエンド | 入力欄がもたつく、ユーザーが PDF を貼り付けてくる |
バックエンド | プロンプト組み立てのバグ、リトライループ |
LLM | レイテンシ、トークンの無駄消費、原因不明のハルシネーション |
検索・取得 | ドキュメントが見つからない、関連度スコアが低い |
外部API | スキーマ変更、レート制限、突発的な障害 |
インフラ | コールドスタート、メモリ使用量のスパイク、コンテナがログを残さず落ちる |
必要なのはちゃんとしたトレーシング
これは「モデルに何を送ったか」の話ではありません。「ユーザーのクリックから、炎上するアウトプットが出るまでに何が起きたか」の話です。
無料でもしっかり役立つもの
- フロントエンドとバックエンドを横断してトレース ID を付ける
- OpenTelemetry か Sentry でリクエストの流れを追えるようにする
- リトライ回数とトークン使用量を追跡する
- レイテンシのスパイクとエラー率にアラートを設定する
ユーザーが何を見たのか、モデルが何を見たのか、そして途中で何が変わったのか。それが追えないなら、オブザーバビリティはできていません。やっているのは考古学です。
トレーシングがないと起こること
- ベクターストア障害中、リトライループが静かにトークンを燃やし続ける
- モデルが想定外のプレフィックスを付けて、UI が壊れる
- モデル変更の影響で Retrieval が動かなくなり、Twitter で初めて気づく
- レイテンシが 600ms 跳ねても、原因が誰にも分からない
見つけられないものは直せません。特にそれが JSON の塊の中で base64 に包まれているなら、なおさらです。
イベント：ワークショップ：Seer・MCP・Agent Monitoring で学ぶ Sentry AI デバッグ
WATCH VIDEO
ステージ 3：プロダクトマーケットフィット（PMF）
（別名：「オンコール開始」）
プロダクトは実際に使われ、人がそれに依存するようになります。ここから先は、新しい問題が増えます。たとえばコスト、スケール、そして「要約機能が急に要約しなくなった理由」をマネージャーに説明することとか。
この段階では、オブザーバビリティの主眼が「バグを見つける」から、「回帰を捉えて、トレードオフを判断する」へと移ります。
実際に必要なもの
- モデルのアップグレードごとの出力ドリフト検知
- 意味的類似度やフォーマットチェックなどの評価指標
- ユーザー別・エンドポイント別・モデル別のコスト／レイテンシ内訳
- RAG（Retrieval-Augmented Generation）の品質トラッキング：インデックスは最新で、関連性があり、壊れていないか
- フルスタックトレーシング：静かに失敗した謎のツール呼び出しに至るまで
例：手早く雑に Eval
まだ自分たちでできることもある
- cron と SQL を使った夜間の評価（eval）
- エンドポイント別に集計したトークン使用量レポート
- モデル変更の前後で出力を手作業で差分比較
- しきい値を使った埋め込みの鮮度チェック
自作をやめて課金を始めるタイミング
次の状態になったら、ツールにお金を払うべきです。
- 機能を出すより、ログを読む時間のほうが長い
- 「何が変わった？」に答えるのに 5 分以上かかる
- システムが黙って壊れて、顧客の苦情で初めて気づく
役立つツール
- LangSmith：トレーシングと評価（eval）
- Sentry：フルスタックの可視化
- WhyLabs / Arize：ドリフト検知と出力モニタリング
理想形とは
LLM システムの監視は厄介です。これらは確率的なツールです。ログに残すのはエラーではなく、挙動です。
ステージ | 見るべきもの |
|---|---|
本番前 | プロンプトログ、トークン使用量、バージョン追跡 |
本番 | トレーシング、リトライ、フィードバック、構造化ログ |
PMF後 | ドリフト検知、評価（eval）、コストの洞察、RAG の健全性 |
良いオブザーバビリティ基盤は、次の 4 つの質問に素早く答えられるべきです。
- モデルに何を送ったのか
- なぜその応答になったのか
- 最近何が変わったのか
- これにいくらかかっているのか
これらに答えられるなら、たぶん問題ありません。答えられないなら、小さく始めましょう。痛いところから直す。変なことが起きたら、そのときに足す。遅かれ早かれ、必ず出てきます。
最後にもうひとつ
監視がモデル呼び出しで止まっているなら、それは監視ではなく、ただ願っているだけです。
Sentry はアプリ全体を横断したリクエストトレースを提供します。ユーザーのクリックから、ツールチェーン、ベクターストア、モデル呼び出しを経て、アウトプットに戻るまでを追うことができます。さらに、エージェントのプラン内でツール呼び出しが失敗した理由まで、ログから文脈を再構築して、午後を全て費やすことなく確認することができます。
だから、推測はやめて、把握しましょう。そして、何が原因で壊れたのか忘れる前にプロンプトを必ずログに残してください。
詳しくはドキュメントをご覧ください。Discord で議論に参加することもできます。もしSentry が初めてなら、無料で始めることができます。
Original Page: What You Actually Need to Monitor AI Systems in Production
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
