監視とオブザーバビリティ

約5分

本番AIサービスの監視設計を学びたいエンジニア、オブザーバビリティの三本柱を理解したい方

クラウドアーキテクチャ入門の全体構成を把握していると理解が深まります

オブザーバビリティ（Observability）とは、システムの外部出力（ログ、メトリクス、トレース）から内部状態を理解できる性質のことです。単なる監視（Monitoring）との違いは、「何かがおかしい」と知らせるのが監視であるのに対し、「なぜおかしいのか」を理解する手段を与えるのがオブザーバビリティです。本番AIサービスでは、LLM API呼び出しの遅延・コスト・品質という従来のWebサービスにない指標も追跡が必要です。

監視とオブザーバビリティの違い

観点	監視（Monitoring）	オブザーバビリティ（Observability）
問いに答える	「何かがおかしい？」	「なぜおかしいのか？」
アプローチ	既知の障害パターンをアラートで検知	未知の障害も外部出力から調査できる
前提	想定内の問題に対応	想定外の問題も調査できる
データ	事前に定義したメトリクス	ログ、メトリクス、トレース（三本柱）

オブザーバビリティの三本柱

1. メトリクス（Metrics）

メトリクスとは、時系列で収集される数値データです。「現在の状態がどのくらいか」を把握するのに使います。

例:
- レイテンシ: p99 = 2.4秒（99%のリクエストが2.4秒以内に完了）
- エラー率: 0.3%（全リクエストの0.3%がエラー）
- スループット: 150 req/s
- CPU使用率: 62%
- LLMコスト: $0.023/リクエスト

メトリクスは集計された数値であるため、ストレージ効率が良く長期保存に向きます。

2. ログ（Logs）

ログとは、タイムスタンプ付きのイベント記録です。「何が起きたか」の詳細な文脈を提供します。構造化ログ（JSONフォーマット）を使うと、後から集計・検索がしやすくなります。

{
  "timestamp": "2026-05-13T10:23:45.123Z",
  "level": "ERROR",
  "service": "chat-service",
  "request_id": "req_abc123",
  "user_id": "user_456",
  "message": "LLM API timeout after 30000ms",
  "model": "claude-opus-4-5",
  "input_tokens": 850,
  "error_code": "TIMEOUT"
}

非構造化ログ（プレーンテキスト）は人間には読みやすいですが、自動集計が難しいため、本番環境では構造化ログが推奨されます。

3. トレース（Traces）

分散トレーシングとは、単一のリクエストが複数のサービスを経由する際の処理経路全体を記録する仕組みです。マイクロサービスでは、あるリクエストが APIゲートウェイ → アプリサーバー → LLM API → DB の順に処理されます。どこで遅延が発生しているかをトレースで把握できます。

トレース例（リクエストID: req_xyz789）:
├── API Gateway (5ms)
├── App Server (4,250ms)
│   ├── JWT validation (3ms)
│   ├── DB query: fetch conversation (12ms)
│   ├── LLM API call (4,100ms)  ← ボトルネック
│   └── DB write: save message (35ms)
└── Total: 4,255ms

オブザーバビリティのアーキテクチャ

graph TD
    Client["クライアント"] --> APIGW["APIゲートウェイ\n▶ メトリクス送信\n▶ アクセスログ"]

    APIGW --> App["アプリサーバー\n▶ トレーススパン開始\n▶ 構造化ログ出力"]

    App --> LLM["LLM API呼び出し\n▶ トレーススパン\n▶ レイテンシ計測\n▶ トークン数・コスト記録"]

    App --> DB["DBクエリ\n▶ トレーススパン\n▶ クエリ実行時間"]

    App --> Cache["Redis\n▶ キャッシュヒット率"]

    APIGW --> OtelCollector["OpenTelemetry\nCollector"]
    App --> OtelCollector
    LLM --> OtelCollector
    DB --> OtelCollector
    Cache --> OtelCollector

    OtelCollector --> Metrics["メトリクスDB\nPrometheus / CloudWatch"]
    OtelCollector --> LogStore["ログストア\nElasticsearch / CloudWatch Logs"]
    OtelCollector --> TraceStore["トレースストア\nJaeger / X-Ray"]

    Metrics --> Dashboard["ダッシュボード\nGrafana / Datadog"]
    LogStore --> Dashboard
    TraceStore --> Dashboard

    Metrics --> Alert["アラート\nPagerDuty / OpsGenie"]

Webサービスの基本メトリクス（ゴールデンシグナル）

Googleの SREブック（Site Reliability Engineering）では、あらゆるサービスで監視すべき4つのシグナルを「ゴールデンシグナル」と定義しています。

シグナル	意味	計測方法
レイテンシ（Latency）	リクエスト処理にかかる時間	p50/p95/p99パーセンタイル
エラー率（Error Rate）	全リクエストに占めるエラーの割合	5xx レスポンス数 / 総リクエスト数
トラフィック（Traffic）	システムへの需要の大きさ	毎秒リクエスト数（req/s）
飽和度（Saturation）	リソースの利用率	CPU使用率、メモリ、DBコネクション数

AIシステム特有のメトリクス

一般的なWebサービスの指標に加えて、LLMを使うAIサービスでは以下の指標も追跡します。

LLM APIパフォーマンス

メトリクス	説明	目安
TTFT（Time to First Token）	リクエスト送信から最初のトークン受信まで	< 2秒
TPS（Tokens per Second）	生成速度	モデルによる
総レイテンシ	リクエスト完了までの全体時間	< 30秒（ストリーミング想定）

コスト追跡

{
  "date": "2026-05-13",
  "model": "claude-opus-4-5",
  "requests": 12450,
  "input_tokens_total": 8234000,
  "output_tokens_total": 15670000,
  "cost_usd_total": 421.30,
  "cost_per_request_avg": 0.0338
}

RAGメトリクス

メトリクス	説明
検索レイテンシ	ベクトル検索にかかる時間
取得チャンク数	1リクエストで取得するドキュメント断片の数
キャッシュヒット率	LLMレスポンスキャッシュのヒット率

品質メトリクス

メトリクス	計測方法
ユーザーのサムズダウン率	「役に立たなかった」フィードバックの割合
再生成リクエスト率	同一会話内で再生成が押される割合
セッション継続時間	ユーザーが会話を続ける長さ

SLO（サービスレベル目標）の設計

SLO（Service Level Objective）とは、サービスが提供すべき品質の目標値です。SLOを事前に定義することで、アラートの閾値設定と障害対応の優先度付けが明確になります。

# SLO例
slo:
  chat_api:
    latency_p99: "< 5秒"       # 99%のリクエストを5秒以内に処理
    error_rate: "< 0.5%"       # エラー率を0.5%未満に維持
    availability: "99.5%"      # 月間稼働率99.5%以上
  
  llm_api_cost:
    daily_budget_usd: 500      # 1日の上限コスト
    per_request_max_usd: 0.10  # 1リクエストあたり上限

アラートとアラート疲れ

アラートは多すぎると「アラート疲れ」（Alert Fatigue）が発生し、重要なアラートを見逃すリスクが高まります。

アラート設計の原則:

アクション可能なアラートだけを設定する: 受け取った人間が対処できないアラートは不要
症状ベースでアラートする: 「CPU使用率 > 80%」より「エラー率 > 1%」のほうが有用
段階的な重要度: 緊急対応が必要なもの（PagerDuty通知）と翌朝確認でよいもの（Slackのみ）を分ける

オブザーバビリティスタックの選択

スタック	種別	コスト	主な特徴	AIサービスへの適合
Prometheus + Grafana + Jaeger	OSS	低（運用コストあり）	高いカスタマイズ性	設定が必要だが可能
Datadog	マネージド	高	機能豊富、LLM observability機能あり	高
New Relic	マネージド	中〜高	AIモニタリング機能あり	高
Honeycomb	マネージド	中	高カーディナリティなトレース分析に強い	中
AWS CloudWatch	クラウドネイティブ	中	AWS環境との親和性が高い	中
Google Cloud Monitoring	クラウドネイティブ	中	GCP環境に統合	中

オンコールダッシュボードの設計

オンコール担当者が即座に状況を把握できるダッシュボードには、以下の情報を1画面に収めます。

┌─────────────────────────────────────────────────┐
│ ゴールデンシグナル（直近1時間）                  │
│  エラー率: 0.12%  ✓   レイテンシp99: 3.2s  ✓    │
│  スループット: 145 req/s   可用性: 99.98%  ✓    │
├─────────────────────────────────────────────────┤
│ AIサービス固有                                   │
│  LLM TTFT p95: 1.8s  ✓   コスト/時: $18.4       │
│  キャッシュヒット率: 23%   エラー: 0件           │
├─────────────────────────────────────────────────┤
│ インフラ                                         │
│  CPU: 45%  ✓   メモリ: 67%  ✓   DB接続: 45/100  │
└─────────────────────────────────────────────────┘

まとめ

監視は「何かがおかしい」を検知し、オブザーバビリティは「なぜか」を理解する手段
三本柱（メトリクス・ログ・トレース）を組み合わせることで本番障害の調査が可能になる
AIサービス特有のメトリクス（TTFT、トークンコスト、RAG品質）を追加で追跡する
SLOを定義してアラートの閾値を決め、アクション可能なアラートだけを設定する
小規模ならCloudWatch/Grafana、本格運用ならDatadog/New Relicが有力な選択肢

よくある質問

Q: 最初に何を監視すべきですか？

A: まずゴールデンシグナル（エラー率・レイテンシ・スループット・飽和度）から始めます。AIサービスではLLM APIのレイテンシとコストも初期から追跡することを推奨します。ログは構造化JSON形式で出力するだけで後から集計できるため、最初からJSON形式にしておくことが重要です。

Q: AIモデルの呼び出しはどうトレースしますか？

A: OpenTelemetryのSDKをアプリに組み込み、LLM APIへのHTTPリクエスト前後にトレーススパンを手動で作成します。Datadogの「LLM Observability」機能やArize Phoenix、LangSmithなどAI特化の観測ツールも2026年時点で成熟してきており、プロンプト・入出力・レイテンシを自動計装できます。

Q: ログとメトリクスが重複するように見えますが、両方必要ですか？

A: 役割が異なります。メトリクスは数値の時系列集計（長期保存・アラートに向く）で、ログは個々のイベントの詳細（障害時の原因調査に使う）です。どちらか一方では情報が不足します。トレースはさらに、複数サービスをまたぐ処理経路の把握に必要です。

Q: オープンソースとマネージドサービスのどちらを選ぶべきですか？

A: チームが小さく運用リソースが限られる場合はマネージドサービス（Datadog等）が推奨されます。オープンソース（Prometheus + Grafana）はカスタマイズ性が高いですが、インフラの維持・スケーリングをチームが担います。まずDatadogやNew Relicの無料トライアルで始め、コストが問題になったらOSSへの移行を検討するアプローチも有効です。

このページの外部仕様・背景情報は、参考文献を参照してください。[1][2][3][4][5]

参考文献

クイズ

デプロイとCI/CD

データベース設計パターン