最低限記録したいデータ
最初から複雑な評価基盤を作る必要はありません。まずは1リクエストを追跡できるIDと、モデル・トークン・料金・処理時間・成否を同じレコードに残します。
- モデル名とプロバイダー
- 入力・出力トークンと推定料金
- レイテンシ、エラー、再試行回数
- 機能名、環境、顧客またはプラン
- 品質評価とユーザーフィードバック
ダッシュボードより先にタグ設計
総額だけを可視化しても削減施策につながりません。feature、customer、plan、environmentなどのタグを決めておくと、『特定機能だけ原価率が高い』『無料プランの利用が想定を超えている』といった判断ができます。
方式別の向き・不向き
LLM特化型は導入が速く、既存監視基盤との統合型はインフラ障害との相関を追いやすく、自前構成は保存先と加工を制御しやすいという違いがあります。
| 方式 | 代表例 | 強み | 確認点 |
|---|---|---|---|
| LLM特化型 | Langfuse | Trace、評価、トークン・料金を同じ文脈で確認 | 価格定義、保存先、イベント量 |
| 統合監視型 | Datadog LLM Observability | 既存APMやログと一緒に原因を追跡 | 既存契約と取り込み量 |
| 標準／自前 | OpenTelemetry | ベンダーをまたいだ計装と保存先の自由度 | 収集基盤と運用責任 |
ツール選びの基準
LangfuseのようなLLM特化型、Datadogのような既存監視基盤との統合型、OpenTelemetryを使った自前構成があります。評価機能の豊富さだけでなく、ログ保存先、SDKの対応言語、既存トレースとの接続、月間イベント数で比較します。
費用を下げる改善ループ
可視化の目的はレポート作成ではなく改善です。高コストな機能を特定し、プロンプト短縮・キャッシュ・モデル振り分けを小さく試し、品質と完了単価の変化を追います。
コスト表示を過信しない
推定料金は、モデル名と価格表の突合方法によってずれます。Langfuseは使用量と料金を取り込み、未指定時はモデル定義から推定できますが、独自契約単価や新しい料金階層では定義の更新が必要です。請求照合では、プロバイダーの実請求額を正として月次差分を確認します。
Trace・Span・Generationの関係
LLM機能を1回のAPI呼び出しだけで捉えると、エージェント型処理の全体像が見えません。ユーザーの1操作をTrace、その中の検索、モデル呼び出し、ツール実行、再試行をSpanまたはGenerationとして記録すると、どこで時間と費用が増えたか追跡できます。
たとえば問い合わせ回答が3回のモデル呼び出しと2回の検索で構成される場合、各呼び出しの単価だけでなく、最終回答までの合計時間、合計費用、途中失敗を同じTrace IDで結びます。OpenTelemetryの生成AI向けセマンティック規約を使うと、モデル名やトークン使用量などの属性を既存の分散トレーシングへ載せやすくなります。
品質を数値化する4つの方法
コストだけを最適化すると、回答品質の低下を見逃します。すべての処理を人が採点する必要はなく、用途に応じて自動評価とサンプリングを組み合わせます。評価結果はモデルやプロンプトのバージョンと紐付け、変更前後で比較できる状態にします。
| 評価方法 | 向く場面 | 注意点 |
|---|---|---|
| ルール評価 | JSON形式、禁止語、必須項目 | 意味の正しさまでは測れない |
| 正解データとの比較 | 分類、抽出、定型回答 | 継続的な正解データ更新が必要 |
| LLMによる評価 | 要約、文章品質、複数観点 | 評価モデルの偏りと費用を管理 |
| 人手レビュー | 重要判断、苦情、高額取引 | 全件ではなく高リスク・低確信度を抽出 |
個人情報と機密データをログへ残しすぎない
Observabilityのためにプロンプトとレスポンスを全文保存すると、顧客情報、認証情報、社内文書が監視基盤へ複製される可能性があります。デバッグの便利さだけで保存範囲を決めず、目的、閲覧者、保存期間、削除方法を定義します。
全文が不要な集計では、トークン数、モデル名、処理時間、結果コード、ハッシュ化した顧客IDだけを残します。品質確認用の本文ログはサンプリングし、機密項目を送信前にマスキングする設計が現実的です。開発環境と本番環境で保存ポリシーを分けることも重要です。
導入を4段階に分ける
最初から全機能へSDKを埋め込むと、タグの不統一やイベント量の急増が起きます。まず費用影響の大きい1機能を選び、必要最小限の項目から始めます。
- 第1段階：request ID、モデル、入出力トークン、料金、時間、成否を記録
- 第2段階：feature、customer、plan、environmentのタグを統一
- 第3段階：評価スコア、ユーザーフィードバック、再生成を接続
- 第4段階：予算超過、品質低下、異常な再試行へのアラートを設定
月次レビューで確認する指標
ダッシュボードは眺めるだけでは改善につながりません。毎月、費用増加の原因を利用者増、入力増、出力増、再試行増、モデル変更に分解し、翌月の実験を一つ決めます。
経営向けには総額と売上・顧客当たり原価、開発向けには機能別トークン、p95レイテンシ、エラー率、品質スコアを提示します。同じ数字を並べるより、意思決定者ごとに必要な粒度を変える方が有効です。
- 顧客・プラン・機能別の完了タスク原価
- モデル別の入力・出力・キャッシュトークン
- p50・p95レイテンシとタイムアウト率
- 再試行率、フォールバック率、人手修正率
- 予算と実績の差、その差が生じた要因
参考資料
料金・仕様は変更される可能性があります。導入時は各社の最新情報をご確認ください。