本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第10弾として、ログ設計について解説する記事です。
ログは書いたその時ではなく、半年後に真価が問われる将来の自分への手紙です。本記事では構造化ログ（JSON）・ログレベル・相関ID・PIIマスキング・保存期間・ログ集約基盤（CloudWatch / Loki / Datadog）まで、必要十分な情報を機械が読める形で適切な保存期間で残す設計を扱います。
本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』も参考にしてみてください。
この記事の結論
- 構造化ログ（JSON）をデフォルトにする
- 個人情報（PII）のログ出力を絶対禁止にする
- trace_idで相関させ、保存は段階的にコールド化する
この記事を読む前に
本記事は開発・テスト・リリース・監視といった、サービスを作って動かし続ける工程の話が中心です。IT用語にあまり馴染みがない方は、基礎編の「開発から運用までの流れ」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもログ設計とは何か
飛行機のフライトレコーダー（ブラックボックス）を思い浮かべてください。事故が起きた時、何が起きたかを解明できるのは、飛行中の全データが自動で記録されていたからです。「墜落してからカメラを回す」では遅いのです。
ログ設計とは、システムの動作記録を何を・どの形式で・どこに・どれくらいの期間残すかを事前に決めることです。障害調査・セキュリティ監査・ビジネス分析──全てはログがなければ始まりません。
もしログ設計がなければ、障害が起きても原因を特定する手がかりがゼロです。「昨日の夜中に何が起きたか」を誰も答えられず、同じ障害を繰り返すことになります。
なぜログ設計が必要か
第一に、障害調査の一次情報だからです。ログは過去のシステム状態を復元する唯一の資産です。第二に、監査・コンプライアンス対応です。「誰がいつ何をしたか」の記録はSOX・PCI DSS・個人情報保護法のいずれでも要求されます。第三に、ビジネス分析・改善です。ユーザー行動・エラー傾向を分析すれば、メトリクスより詳細なプロダクト改善のヒントが得られます。
ログレベル — 本番はINFO以上
ログの重要度を段階分けするのが標準です。運用時にレベルで絞り込め、本番ではINFO以上、開発ではDEBUG以上、といった制御ができます。
| レベル | 用途 |
|---|---|
| TRACE | 最も詳細・通常は無効 |
| DEBUG | 開発時のデバッグ情報 |
| INFO | 正常な処理の節目 |
| WARN | 注意すべき状況（自動回復等） |
| ERROR | エラー発生・要調査 |
| FATAL | 致命的障害・即対応 |
DEBUGを本番で出すのは地獄の始まりです。量が10倍に爆発し、ストレージ費用が数倍に膨らみます。
構造化ログ（Structured Logging）
JSON形式など、機械が読める構造でログを出力する方式です。従来のフリーテキストログは人間には読みやすいですが、検索・集計・相関分析が困難でした。構造化ログなら全てが容易になります。
{
"timestamp": "2026-04-18T10:23:45Z",
"level": "ERROR",
"service": "order-api",
"trace_id": "abc123",
"user_id": "u42",
"message": "Payment failed",
"error_code": "CARD_DECLINED",
"latency_ms": 1234
}必須項目はtimestamp（ISO 8601・UTC推奨）・level・service・trace_id（分散トレーシングと連携）・user_id / request_id・message・contextで、全サービスで統一します。標準項目を決めておかないとサービスごとにバラバラになり、横断検索が困難になります。
「エラー発生」としか書かないログは、「誰かが死んだ」としか書かれていない遺書と同じ、というのはログ設計の定番の格言です。深夜帯の障害対応で [ERROR] Payment failed だけが並ぶログを前に、どのユーザーの何円の決済がなぜ失敗したのかを時刻とStripe管理画面の突き合わせだけで逆引きし、3時間格闘してからその夜のうちに user_id と amount と error_code を追加した、という話は珍しくありません。
ログ収集と保存先
現代はアプリは標準出力、収集は別プロセスの構成が主流（12-Factor App方式）で、アプリ側はログ出力先を意識しなくて済みます。収集ツールの主役は軽量でCNCF卒業のFluent Bitと、Rust製で高性能なVector。その他、古参のFluentd、Loki専用のPromtailがあります。
保存先は検索要求・コスト・データ量で選びます。主役はLoki（Grafana Labs製、ラベルベースでコスト効率が極めて良い）と、AWS統合のCloudWatch Logs。検索最強のElasticsearchは運用が重く、「とりあえず全ログをElasticsearch」は破綻しやすいアプローチです。その他、SaaS統合のDatadog Logs、老舗のSplunk（高機能・最高コスト）、アーカイブ用のS3 / GCSがあります。
保持期間・サンプリング・監査ログ
ログは保持期間に比例してコストが増えるため、永久保存は現実的ではありません。ホット（高速検索、7〜30日、障害調査用）→ウォーム（3〜6か月、分析・監査用）→コールド（1〜7年、法的保管）→削除、という段階的コールド化が一般的です。監査ログは7年保存が多くの規制で要求されますが、アプリログは30日で十分なことも多く、分類して扱うのが現実的です。
大規模システムでは全ログ保存でコストが爆発するため、サンプリングで削減します。ただしエラーログは100%保存が原則で、成功リクエストだけを1〜10%サンプリングします。OpenTelemetryのテールサンプリング（トレース全体を見てから保存判断、エラー時は全保存）が現代的な解です。
監査ログ（誰が・何を・いつ・どこで・結果）は改ざん不可・長期保存が要求される特別なログで、一般ログとは別経路で管理し、WORM（Write Once Read Many）ストレージに保存するのが理想です。AWS CloudTrail・GCP Audit Logsはクラウドレベルの監査ログを標準提供します。
PII（個人情報）はログに出力しないのが大原則です。クレカ番号・マイナンバー・パスワード・APIキーは絶対にログに出ないよう、マスキング（user***@gmail.com）・ハッシュ化・除外・自動検出ツールをフレームワーク・ログライブラリのレベルで対策します。一度出力されたら回収不能です。
3つのシナリオで考える
個人開発・小規模Webサービスの場合
CloudWatch Logs（またはCloud Logging）に構造化ログを出力するだけで、追加の基盤なしに始められます。保持は30日で十分ですので、監査ログだけS3に転送して長期保管しておきましょう。月10GB程度までなら無料〜数千円で収まってしまいます。
中小SaaS企業の場合
Grafana Cloud（Loki）とOpenTelemetry Logsの組み合わせがコスト効率も良く、同じ基盤でメトリクスやトレースまで扱えるのでお勧めです。PIIについてはpre-commit hookとFluent Bitフィルタの多層防御にしておきます。月間1TB規模になってきたら、Lokiの自社運用とS3アーカイブへの移行を検討する時期です（SRE 2〜3名で運用できます）。
大企業・規制業種の場合
Splunk（またはElastic Cloud）にWORMストレージと改ざん防止を組み合わせた構成になります。監査ログは別系統・別権限で長期保存（金融は7年、PCI DSSは1年以上）として、全ログに署名とチェーン化（Hash Chain）を施して改ざんを検知できるようにしておくべきです。
ログ量・保存期間の数値Gate
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
ログは「全部取る」と請求書が爆発するので、用途別の保存戦略が必須です。
| 項目 | 推奨値 | 理由 |
|---|---|---|
| 本番ログレベル | INFO以上 | DEBUG は禁止（量が10倍） |
| ホット保存期間 | 7〜30日 | 障害調査の即応性 |
| コールド保存期間（監査） | 1〜7年 | 規制対応（金融: 7年、PCI DSS: 1年） |
| 1リクエストあたりのログ量 | 1KB以下 | 肥大化防止 |
| エラーログ保存 | 100%（サンプリング禁止） | 全て残す |
| 成功ログ保存 | 1〜10%サンプリング | コスト削減 |
| ログ形式 | 構造化JSON | AI・機械可読 |
| PII出力 | 絶対禁止 | マスキング必須 |
月間ログ量の目安は、〜10GBはCloudWatchで無料〜数千円、〜1TBはLokiで数万円、〜10TBはElasticsearch自社運用で月数十万円。月1TB超になったらLoki / Grafana Cloudへの移行を検討すべきラインです。
AI判断軸 ― ログはAIへのメッセージになった
構造化ログがAI障害診断を可能にする仕組み
JSON形式のログに trace_id・service・level・timestamp が含まれていると、AIは「この時刻帯にエラーが集中しているサービスはどれか」「このtrace_idの処理がどこで失敗したか」を即座に解析できます。非構造化テキストログでは、まず正規表現でパースする必要があり、解析精度が落ちます。
2026年現在、Datadog・New Relic・Honeycombの主要Observabilityツールはすべて「AIにログを質問する」機能を搭載しており、構造化ログが前提条件です。
ログレベル設計とAIの関係
AI生成コードでは、ログレベルの設計が曖昧になりがちです。AIは console.log や logger.info を多用し、本来ERRORやWARNにすべき箇所もINFOで出力するケースがあります。ログレベルの基準をプロジェクトで明文化し（ERROR=即対応・WARN=調査必要・INFO=正常フロー確認・DEBUG=開発時のみ）、CIのLintで適切なレベルが使われているか検証する仕組みが有効です。
やってはいけないこと
ログで事故る典型を、特に危険な6つに絞ります。どれも情報漏洩・コスト爆発・調査不能のいずれかにつながります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| PIIをログ出力 | 2018年GitHub平文パスワード事件（470万件強制リセット） → 実装レベルでマスキングを強制する |
| HTTPボディを丸ごとログ出力 | 認証トークンが監査ログに残留（2021年Twitter事件） → 出力フィールドを許可リスト化する |
| 本番でDEBUGレベルを出し続ける | 月100万円請求の定番 → INFO以上に絞る |
| trace_idなしでマイクロサービス運用 | 横断検索不能で障害調査が数日に → 必須フィールドとして標準化する |
| エラーログをサンプリング | 障害の証拠が消える → エラーは100%保存、成功だけ間引く |
| ログをアプリと同じストレージ・権限で保存 | 侵害時にログごと消される → 別アカウント + WORMで分離する |
なお「ログは永遠に保存したい」という無期限保存も、年間数千万円のストレージ課金につながります。段階的コールド化が必須です。
筆者メモ — 「ログに全部書いていた」が情報漏洩に変わった事例
2018年のGitHubパスワード平文ログ事件では、パスワードリセット機能の実装ミスにより、一部ユーザーの平文パスワードが内部ログに記録されていたことが判明しました。幸い外部流出は起きませんでしたが、約470万件のパスワード強制リセットが行われ、「ログは安全な場所」という前提が崩れた事例として語り草になっています。
もう一つ、2021年にはTwitter内部ログへのAPIキー混入が報告されています。開発者がHTTPボディを丸ごとログに出していた結果、認証トークンが6か月分の監査ログに記録された、というケースで、ログの閲覧権限を持つ社員全員が事実上そのトークンを知れる状態になっていました。ログを読める＝本番データを読めるという構造的な問題を浮き彫りにした事例です。
どちらも「何を出すか・何を出さないか」の設計が甘かった事例で、PII・トークン・パスワードをログに出さない規律は、運用ルールではなく実装レベルで強制する必要があります。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- ログフォーマット（JSON構造化推奨）
- ログレベル戦略（本番INFO / 開発DEBUG）
- 必須項目の標準化（timestamp・trace_id・service）
- 収集基盤（Fluent Bit / Vector / 各クラウド）
- 保存先（Loki / Elasticsearch / Datadog）
- 保持期間（ホット / ウォーム / コールド）
- PII対策（マスキング・検出）
この記事に関連する記事
まとめ
本記事はログ設計について、ログレベル・構造化ログ・必須項目・収集と保存先・保持期間・サンプリング・PII保護・AIへのメッセージ視点まで含めて解説しました。如何だったでしょうか。
構造化ログをデフォルトに、PII出力を絶対禁止、段階的コールド化、trace_idで相関する。これが2026年のログ設計の現実解です。
次回はSLOとSLI（信頼性目標とエラーバジェット）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Amazon CloudWatch Logs も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（69/95）