はじめに
「本番でエラーが起きても原因調査に時間がかかりすぎる」
「ログがバラバラに出力されていて、追跡しにくい」
「OpenTelemetryを導入したいが、設定が複雑で手が出ない」
Observability（可観測性）はモダンなアプリケーションの運用に不可欠ですが、設定が複雑で後回しにされがちです。Claude Codeを使えば、ログ・メトリクス・トレースの3本柱を体系的に実装できます。
目次
- Observabilityの3本柱
- 構造化ログの実装
- OpenTelemetryの導入
- メトリクス収集の設定
- 分散トレーシングの実装
- アラートの設定
- ダッシュボードの構築
- まとめ
1. Observabilityの3本柱
現状診断と改善計画
> このアプリケーションのObservabilityの現状を診断して、
改善計画を立ててください。
現在の状況：
- console.logでのランダムなログ出力
- エラー監視なし
- パフォーマンス計測なし
予算・規模に応じた段階的な改善計画と、
推奨するツールスタックを提案してください。
スタック候補：
A. OSS（自己ホスト）：OpenTelemetry + Grafana + Prometheus + Loki
B. SaaS：Datadog または New Relic
C. 低コスト：Axiom + Sentry3本柱の概要
| 柱 | 内容 | 代表ツール |
|---|---|---|
| Logs（ログ） | イベントの記録 | Loki・Elasticsearch |
| Metrics（メトリクス） | 数値の時系列データ | Prometheus・Datadog |
| Traces（トレース） | リクエストの追跡 | Jaeger・Zipkin |
2. 構造化ログの実装
構造化ログへの移行
> このアプリケーションのconsole.logをすべて構造化ログに置き換えてください。
使用ライブラリ：pino（Node.js）またはstructlog（Python）
ログのフォーマット：
{
"timestamp": "2026-05-28T10:00:00.000Z",
"level": "info",
"service": "api-server",
"request_id": "uuid",
"user_id": "user-123",
"message": "ユーザーがログインしました",
"duration_ms": 45,
"metadata": {}
}
以下を実装してください：
- ログレベルの使い分けガイドライン（error・warn・info・debug）
- リクエストIDの自動付与（ミドルウェア）
- センシティブ情報のマスキング（パスワード・トークン）
- 環境ごとのログレベル設定ログの集約・保存
> Fluentd（またはVector）を使ってログを集約する設定を行ってください。
収集元：
- アプリケーションログ（Docker コンテナ）
- Nginxアクセスログ
- PostgreSQLスロークエリログ
送信先：
- Grafana Loki（直近7日分）
- S3（長期保存：90日）
Docker Composeでの設定も含めてください。3. OpenTelemetryの導入
自動計装の設定
> OpenTelemetryをこのNode.jsアプリに導入してください。
自動計装対象：
- HTTPリクエスト（Express/Fastify）
- データベースクエリ（Prisma/pg）
- Redisアクセス
- 外部APIへのリクエスト（axios/fetch）
設定内容：
- @opentelemetry/sdk-node の設定
- OTLP Exporterの設定（送信先：Jaeger）
- サンプリングレートの設定（本番：10%・開発：100%）
- トレースIDをログに自動付与カスタムスパンの追加
> 重要なビジネスロジックにカスタムスパンを追加してください。
追加対象：
- 決済処理（payment.process）
- メール送信（email.send）
- バッチ処理（batch.execute）
各スパンに追加する属性：
- ユーザーID
- 処理対象のリソースID
- 処理結果（成功/失敗）
- カスタムエラーコード4. メトリクス収集の設定
Prometheusメトリクスの実装
> このAPIにPrometheusメトリクスを追加してください。
収集するメトリクス：
- HTTPリクエスト数（エンドポイント・メソッド・ステータスコード別）
- レスポンスタイム（P50・P95・P99）
- アクティブなWebSocket接続数
- データベース接続プールの使用状況
- キューのジョブ数（待機中・処理中・失敗）
/metricsエンドポイントをPrometheus形式で公開してください。カスタムビジネスメトリクス
> ビジネスKPIをメトリクスとして収集してください。
メトリクス一覧：
- 新規ユーザー登録数（hourly）
- 決済成功/失敗率
- アクティブセッション数
- 機能ごとの使用率
Prometheusのカウンター・ゲージ・ヒストグラムを
適切に使い分けてください。5. 分散トレーシングの実装
マイクロサービス間のトレース伝播
> 複数のサービスにまたがるリクエストのトレースを実装してください。
サービス構成：
- APIゲートウェイ（Node.js）
- ユーザーサービス（Python/FastAPI）
- 通知サービス（Node.js）
実装内容：
- W3C Trace Contextヘッダーによるトレース伝播
- サービス間の親子関係の可視化
- エラー発生時のトレース保持（テールサンプリング）6. アラートの設定
Grafanaアラートの設定
> 以下のアラートをGrafanaで設定してください。
重大（即時通知）：
- エラーレート > 5%（5分間）
- P99レスポンスタイム > 2秒
- サービスがダウン
警告（業務時間内に通知）：
- エラーレート > 1%
- P95レスポンスタイム > 500ms
- ディスク使用率 > 80%
- データベース接続プール残量 < 20%
通知先：Slack（重大→#alerts・警告→#warnings）7. ダッシュボードの構築
Grafanaダッシュボードの設計
> 以下のダッシュボードをGrafana（JSON形式）で作成してください。
ダッシュボード1：サービス概要
- サービスごとのリクエスト数・エラー率・レイテンシ
- 直近のデプロイマーカー
ダッシュボード2：インフラ概要
- CPU・メモリ・ディスク・ネットワーク
- コンテナの健全性
ダッシュボード3：ビジネスKPI
- DAU・MAU・売上・コンバージョン率8. まとめ
Claude CodeでのObservability構築の効率化ポイント：
- console.logから構造化ログへの一括移行を自動化
- OpenTelemetryの自動計装を設定なしで導入
- Prometheusメトリクスの追加を自動実装
- Grafanaダッシュボード・アラートのJSON設定を自動生成
Observability導入の優先順位：
- 構造化ログ + Sentry（エラー監視）← 最小構成
- メトリクス + アラート
- 分散トレーシング
次回の第39回：AWSとGCPのクラウド環境を構築する方法では、インフラ設定をClaude Codeが自動化する手順を解説します。
よくある質問（FAQ）
Q. 小規模なアプリにObservabilityは必要ですか？
A. 最低限Sentryによるエラー監視は導入することをお勧めします。Claude Codeに「このアプリに最小限のObservabilityを設定してください。Sentryだけで始めたいです」と依頼すれば、最小構成から始められます。
この記事はClaude Code入門シリーズ（第4部）の第38回です。← 第37回：React Native ｜ 第39回：AWS・GCPクラウド環境 →
ご質問はお問い合わせページからお気軽にどうぞ。
