// シス担のミカタ
開発ツール・手法

ログ設計 ろぐせっけい

ログロギング構造化ログログレベルオブザーバビリティ監査ログ
ログってどう設計すればいいの？

簡単に言うとこんな感じ！

ログは「後から問題を調査するための記録」だから、「問題が起きたときに何が知りたいか」を想像して設計するといいよ！「いつ・どこで・何が・なぜ・どうなった」が書いてあれば、深夜の障害対応でも冷静に原因を追えるんだ。

ログ設計とは

ログ設計 とは、アプリケーションやシステムが実行中にどんな情報を・どのタイミングで・どの形式で記録するかを計画・実装することです。

適切なログ設計は、障害対応・デバッグ・セキュリティ監査・パフォーマンス分析に不可欠です。「ログが多すぎて何も見えない」「重要な情報が記録されていない」という問題を防ぐのがログ設計の目的です。

ログレベル

レベル用途例
TRACE / DEBUG開発時の詳細な診断情報関数の入出力値
INFO正常な動作の記録リクエスト受信・処理完了
WARN異常ではないが注意が必要レスポンスタイムが閾値超え
ERRORエラーが発生したが継続可能外部APIの一時的なエラー
CRITICAL / FATALシステム継続不可能なエラーDBへの接続失敗

構造化ログ（Structured Logging）

テキスト形式のログよりJSON形式で記録することで、ログ検索・分析が容易になります。

{
  "timestamp": "2026-04-13T10:30:00Z",
  "level": "ERROR",
  "service": "order-service",
  "trace_id": "abc123",
  "message": "Payment processing failed",
  "user_id": "user-456",
  "order_id": "order-789",
  "error": "Connection timeout"
}

ログ設計のベストプラクティス

  • 機密情報を記録しない：パスワード・クレジットカード番号は絶対にログしない
  • トレースIDを付与：リクエストIDを全ログに含め、関連ログを追跡可能に
  • ログレベルを適切に設定：本番ではINFO以上、開発ではDEBUGも有効化
  • 構造化ログを使う：検索・分析・アラートのためにJSON形式が推奨

歴史と背景

  • Unix syslog（1980年代）：標準的なログ形式の先駆け
  • ELKスタック（2010年代）：Elasticsearch+Logstash+Kibanaでログ集中管理が普及
  • 現在：OpenTelemetryがログ・メトリクス・トレースの統合標準として台頭

関連用語