本番運用とオブザーバビリティ

本番運用

Observability の 3 軸

• Logs: リクエスト/レスポンスの記録。PII マスキング必須。
• Metrics: レイテンシ p50/p95/p99, コスト, エラー率, キャッシュヒット率。
• Traces: 1 リクエストの中での tool 呼び出しチェーンを可視化。

SLO 例

• p95 レイテンシ < 4s
• エラー率 < 0.5%
• 月間コスト < $X
• 拒否率 < 2%

Failover

• Anthropic API 障害時のフォールバック:
• モデルダウングレード (Sonnet → Haiku)
• キャッシュからの返答
• 静的な定型文

def safe_answer(prompt: str) -> str:
    try:
        return ask_sonnet(prompt)
    except Exception:
        try:
            return ask_haiku(prompt)
        except Exception:
            return "ただいま混雑しています。しばらくお待ちください。"

Canary Deploy

新プロンプト/新モデルは 5% トラフィックのみ に流して安全確認。 A/B 比較ができる仕組みも望ましい。

Cost Guardrails

• 1 ユーザー / 1 セッションの トークン上限。
• 異常検知で自動停止。
• ハードリミット (組織全体での月間予算)。
• 早期警告 (80% 到達でアラート)。

ユーザーへの透明性

• 「AI が回答しています」を明示。
• 機密性が高い回答には警告を。
• フィードバック機構を必ず置く (👍 / 👎)。
• 出力は変更可能なドラフトとして提示するのが望ましい。

Trace の例

OpenTelemetry や Langfuse・Helicone を使うと、エンドツーエンドのトレースが可視化できます。

Request 12ab
├─ retrieve_context (8ms)  [chunks=5]
├─ messages.create [stream] (3.2s)
│   ├─ tool_use: search_db (220ms)
│   └─ tool_use: notify_slack (180ms)
└─ post_process (15ms)

Monitoring 仕組み

Incident response

• LLM 出力に重大な問題が出たら、即座に モデルやプロンプトをロールバック
• 影響を受けたユーザーへの通知方針を準備
• root cause analysis (RCA) を 24 時間以内に文書化

試す

監視設計を Claude に。