最適なアプリケーションログを考えてみる
なぜログ出力が課題になるのか？
課題は大きく下記に分類できると考えます。
- ログが肥大化して読むのが大変
- ログの粒度が適切でない（多すぎる／少なすぎる）
- 開発者ごとにルールがバラバラ
- セキュリティや個人情報流出のリスク
特に四つめのセキュリティ面に関して、
- 個人情報をログ出力はできない。
- 障害検知のため個人を特定できる何かしらの情報はログ上に必要。
この点で何がログ出力に最適なのかは頭を悩ませました...
最終的に私のプロジェクトでは下記で対応しています。
- リフレッシュトークンの後ろから15桁を取得。
- 下5桁のみを表示、それ以外はマスキングしたトークンをログ出力。
- 個人特定の際はDBの曖昧検索で対応。
個人を特定できる一意の情報は設計段階でしっかりと考える必要があると感じています。
最適なログ出力の要件
最適なログ要件は大きく下記になると考えます。
1. 誰が見ても理解できるメッセージ
2. 適切なレベル分け（INFO, DEBUG, WARN, ERROR, FATAL）
これは事前にチーム内で明確に定義しておかないと個人でばらつきが出ると感じています。
3. 必要なコンテキスト情報（ユーザーID、リクエストID、タイムスタンプなど）
ユーザーID等個人情報が絡むものは慎重に検討する必要があります。
4. 検索性・解析性の高さ
これは障害時特に仇となって出てきます。
エラー箇所を的確に検索できるのは非常に大事だと感じています。
5. パフォーマンスへの影響を最小限に
ログの出し過ぎも良くないです。
必要な情報を最低限出すのが一番見やすいログになると考えています。
（特にINFOレベルは個人的に過剰に出力しすぎてしまいがちでした...）
最適なログ出力を実現する具体的な方法（AI作）
上記踏まえ、具体的な実現方法をAIにまとめてもらいました。
1. 構造化ログを使う
ログを単なるテキスト出力ではなく、JSONなどの構造化形式で記録することにより、解析性・検索性・ダッシュボードでの可視化が非常に楽になります。
具体的にはタイムスタンプ・ログレベル・サービス名・リクエストIDなどを明確にフィールド化し、ログの意味を見える形にすることが推奨されています。
🔗 Elastic – Best Practices for Log Management: Leveraging Logs
2. ログレベルの統一
DEBUG, INFO, WARN, ERROR などのレベルをチームで統一し、開発時／本番時でログ出力ポリシーを切り替えることが重要です。
🔗 AWS – Logging – Performance Engineering Prescriptive Guidance
3. トレースID・相関IDの付与
分散システムや複数サービスをまたぐリクエストに対応するため、リクエストごとの一意のID（相関ID／trace ID）をログに含めることで、障害調査や処理時間分析が容易になります。
🔗 AWS – Logging – Performance Engineering Prescriptive Guidance
4. 個人情報・機密情報の扱い
ログには個人を特定できる情報（PII）や機密情報を不用意に含めないことが基本です。必要な情報をマスク／トークン化する、アクセス制御を厳格にするなどの対策を設けましょう。
🔗 Google Cloud – Best practices for Cloud Audit Logs
5. 集中管理とログ基盤の活用
ログを複数箇所に散らしておくと探すのも合成するのも手間がかかります。
必要なログデータを集め・整理・分析しやすくする設計が大事です。
🔗 Azure – Architecture Best Practices for Log Analytics
6. ログ量とコストの最適化
ログデータ量の増加は保存コスト・検索／集計の遅さ・保守コストを増やす原因になります。
不要なログは収集し過ぎないようにし、ログ収集ルールを適切に設定してコスト最適化を図るべきです。
🔗 Azure – Azure Monitor data sources and data collection methods
7. 保存期間とアーカイブ戦略
監査ログなど長期間保存が法律や規制で求められるものは別として、分析用／運用用ログは保存期間を定め、古いものはアーカイブまたは削除していく戦略が必要です。
🔗 AWS – Logging – Performance Engineering Prescriptive Guidance
8. アラート設計と SLO 連携
ログが障害や異常を早く知らせる仕組みとして機能するよう、アラート設計が重要です。
エラー率・応答時間の異常・リクエスト遅延などをしきい値で監視するほか、SLO（Service Level Objective）と紐づけて対応できるようにすることが大事です。
🔗 Azure – Best practices for Azure Monitor Logs
9. セキュリティ監査ログ
認証・権限変更や設定変更などのシステム操作を記録する監査ログは、セキュリティの観点で別管理・別保存・可監査性を確保すべきです。
🔗 Google Cloud – Best practices for Cloud Audit Logs
10. ガイドラインと自動チェック
チームでログ出力ルール（レベル定義・必須フィールド・マスキングポリシーなど）を明文化し、CI/CD やコードレビューでのチェックを制度化することが望ましいです。
🔗 AWS – Logging – Performance Engineering Prescriptive Guidance
まとめ
私のプロジェクトでは、ログ出力定義を事前にしないまま開発が走り出したためリリース後の初めての障害時原因究明にかなり苦労しました...
事前に最適なログについて設計段階からチームで話し合うこと、定義を明確にしておくことはかなり大事だと感じました。
Discussion