本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第10弾として、ログ設計について解説する記事です。
ログは書いたその時ではなく、半年後に真価が問われる将来の自分への手紙です。本記事では構造化ログ（JSON）・ログレベル・相関ID・PII マスキング・保存期間・ログ集約基盤（CloudWatch/Loki/Datadog）まで、必要十分な情報を機械が読める形で適切な保存期間で残す設計を扱います。
このカテゴリの他の記事
なぜログ設計が必要か
障害調査の一次情報
障害が起きた時、ログがなければ原因はわかりません。ログは過去のシステム状態を復元する唯一の資産です。
監査・コンプライアンス対応
「誰がいつ何をしたか」の記録は、監査で必ず求められます。SOX・PCI DSS・個人情報保護法──全て監査ログの保存を要求します。
ビジネス分析・改善
ユーザー行動・エラー傾向・パフォーマンス──ログを分析すればプロダクト改善のヒントが得られます。メトリクスより詳細な情報が取れます。
ログレベル
ログの重要度を段階分けするのが標準です。運用時にレベルで絞り込め、本番では INFO 以上、開発では DEBUG 以上、といった制御ができます。各言語のログライブラリは標準で対応しています。
| レベル | 用途 |
|---|---|
| TRACE | 最も詳細・通常は無効 |
| DEBUG | 開発時のデバッグ情報 |
| INFO | 正常な処理の節目 |
| WARN | 注意すべき状況（自動回復等） |
| ERROR | エラー発生・要調査 |
| FATAL | 致命的障害・即対応 |
DEBUGを本番で出すのは地獄の始まりです。量が爆発し、ストレージ費用が数倍に膨らみます。
構造化ログ（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
}フリーテキスト出力は現代ではアンチパターンです。全ての新規プロジェクトは構造化ログで始めるべきです。
「エラー発生」としか書かないログは、「誰かが死んだ」としか書かれていない遺書と同じ、というのはログ設計の定番の格言です。深夜帯の障害対応で [ERROR] Payment failed だけが並ぶログを前に、どのユーザーの何円の決済がなぜ失敗したのかを「時刻」と「Stripe 管理画面の突き合わせ」だけで逆引きする、という事態は現場でよく起こります。3時間格闘してようやく原因に辿り着き、その夜のうちに user_id と amount と error_code を追加した、という話も珍しくありません。
何をログに書くか
ログに含める情報は標準化して、全サービスで統一します。標準項目を決めておかないと、サービスごとにバラバラになり、横断検索が困難になります。
| 必須項目 | 内容 |
|---|---|
| timestamp | ISO 8601・UTC 推奨 |
| level | ERROR／INFO 等 |
| service | サービス名 |
| trace_id | 分散トレーシングと連携 |
| user_id／request_id | 主体・リクエスト識別 |
| message | 人間が読む内容 |
| context | 構造化された付加情報 |
個人情報・パスワード・トークンは絶対にログに書かないのが鉄則です。一度出力されたら回収不能です。
ログ収集アーキテクチャ
ログはアプリで出力するだけでなく、集約・保存・検索する基盤が必要です。現代はアプリは標準出力、収集は別プロセスの構成が主流（12-Factor App＝Heroku が提唱したクラウド時代のアプリケーションアーキテクチャ指針）で、これによりアプリ側はログ出力先を意識しなくて済みます。
flowchart LR
APP1[アプリ A] -->|stdout| COL[Collector<br/>Fluent Bit / Vector]
APP2[アプリ B] -->|stdout| COL
APP3[アプリ C] -->|stdout| COL
COL --> BUF[(バッファ<br/>Kafka等)]
BUF --> BACKEND[(保存先<br/>Loki / Elasticsearch / Datadog)]
BACKEND --> UI[検索/可視化UI<br/>Grafana / Kibana]
classDef app fill:#fef3c7,stroke:#d97706;
classDef col fill:#dbeafe,stroke:#2563eb;
classDef buf fill:#fae8ff,stroke:#a21caf;
classDef store fill:#dcfce7,stroke:#16a34a;
classDef ui fill:#f0f9ff,stroke:#0369a1;
class APP1,APP2,APP3 app;
class COL col;
class BUF buf;
class BACKEND store;
class UI ui;| 収集ツール | 特徴 |
|---|---|
| Fluent Bit | 軽量・CNCF 卒業 |
| Vector | Rust 製・高性能 |
| Fluentd | 古参・機能豊富 |
| Promtail | Loki 専用・軽量 |
保存先（ログバックエンド）
ログの保存先は、検索要求・コスト・データ量で選びます。大量ログを高速検索するのは意外とコストが高く、「とりあえず全ログをElasticsearch」は破綻しやすいアプローチです。
| バックエンド | 特徴 | コスト |
|---|---|---|
| Elasticsearch | 検索最強・運用重い | 高 |
| Loki | ラベルベース・安価 | 低 |
| Datadog Logs | SaaS 統合 | 高 |
| Splunk | 老舗・高機能 | 最高 |
| Cloud Logging（GCP） | マネージド | 中 |
| CloudWatch Logs | AWS 統合 | 中 |
| S3／GCS | アーカイブ | 最低 |
Loki は Grafana Labs 製でコスト効率が極めて良く、近年急速に普及しています。Elasticsearch の代替として注目されています。
保持期間とコスト管理
ログは保持期間に比例してコストが増えるため、永久保存は現実的ではありません。法的要件・調査要件を考慮して、段階的なコールド化が一般的です。
| 段階 | 期間 | 用途 |
|---|---|---|
| ホット（高速検索） | 7〜30日 | 障害調査 |
| ウォーム（やや遅い） | 3〜6か月 | 分析・監査 |
| コールド（アーカイブ） | 1〜7年 | 監査要件・法的保管 |
| 削除 | それ以降 | 不要情報は消す |
監査ログは7年保存が多くの規制で要求されますが、アプリログは30日で十分なことも多いです。分類して扱うのが現実的です。
ログのサンプリング
大規模システムでは全ログを保存するとコストが爆発するため、サンプリングで削減します。ただしエラーログは100%保存するのが原則で、成功リクエストだけサンプリングします。
| 戦略 | 内容 |
|---|---|
| 固定レート | 1／100 だけ保存 |
| テールサンプリング | エラー時は全保存 |
| 重要度ベース | 金額・ユーザー種別で変える |
| 適応サンプリング | トラフィック量で自動調整 |
OpenTelemetry のテールサンプリングが現代的な解で、トレース全体を見てから保存判断できます。
監査ログ（Audit Log）
「誰がいつ何をしたか」を記録する特別なログで、改ざん不可・長期保存が要求されます。一般ログとは別経路で管理し、WORM（Write Once Read Many）ストレージに保存するのが理想です。
| 必須記録項目 | 内容 |
|---|---|
| Who（誰が） | ユーザーID・IP |
| What（何を） | 操作内容 |
| When（いつ） | タイムスタンプ |
| Where（どこで） | システム・リソース |
| Result | 成功／失敗 |
AWS CloudTrail・GCP Audit Logs はクラウドレベルの監査ログを標準提供します。アプリレベルの監査ログは、別テーブルや別ログストリームに分離するのが安全です。
PII（個人情報）の取り扱い
個人情報をログに出力しないのが原則です。GDPR・個人情報保護法で厳しく規制されており、「ログから漏れた」では言い訳になりません。
| 対処 | 内容 |
|---|---|
| マスキング | user***@gmail.com のように伏せ字 |
| ハッシュ化 | 分析用に一方向変換 |
| 除外 | そもそも出力しない |
| PII 検出ツール | 自動検出してブロック |
クレカ番号・マイナンバー・パスワード・APIキー──これらは絶対にログに出ないよう、フレームワーク・ログライブラリで対策します。
判断基準①：データ量
ログ量でバックエンド選択が変わります。月に数GBなら CloudWatch Logs、数TBなら Loki・Elasticsearch、それ以上なら Splunk 等の本格派が必要です。
| 月間ログ量 | 推奨 |
|---|---|
| 〜10GB | CloudWatch Logs／Datadog 無料枠 |
| 10GB〜1TB | Loki／Grafana Cloud |
| 1TB〜10TB | Elasticsearch 自社運用／Datadog |
| 10TB〜 | Splunk／Elastic Cloud エンタープライズ |
判断基準②：組織の規制要件
監査・コンプライアンス要件が厳しい業種は、ログの改ざん不可・長期保存が必須です。
| 業種・規制 | 必須要件 |
|---|---|
| 金融・PCI DSS | 1年以上・改ざん防止 |
| 医療・HIPAA | 6年保存・暗号化 |
| J-SOX | 会計関連は7年 |
| 一般企業 | 30〜90日 + 監査ログは長期 |
ケース別の選び方
個人開発・小規模Webサービス
CloudWatch Logs or Cloud Logging + 構造化ログ出力。追加基盤なしで始められます。30日保持で十分で、監査ログだけ S3 に転送して長期保管します。
スタートアップ・SaaS（月間数十GB）
Grafana Cloud（Loki）+ OpenTelemetry Logs。コスト効率が良く、同じ基盤でメトリクス・トレースも扱えます。PII は pre-commit hook + Fluent Bit フィルタで多層防御します。
中堅企業・マイクロサービス
Loki 自社運用 + Vector or Fluent Bit + S3 アーカイブ。Loki でホット検索、S3 に長期アーカイブ、監査ログは CloudTrail と別経路で分離します。SRE 2〜3名で運用可能です。
金融・医療・規制業種
Splunk or Elastic Cloud + WORM ストレージ + 改ざん防止。監査ログは別系統・別権限・長期保存（7年）とし、全ログに署名・チェーン化（Hash Chain）して改ざん検知可能にします。
よくある勘違い
全部INFOレベルで出力しておけば安全
量が爆発してコストも検索も破綻します。レベル設計が先です。
開発中のprintを本番に残しても大丈夫
個人情報が混入する典型パターンです。pre-commit で print 検出するのが安全です。
ログは永遠に保存したい
現実的ではありません。コスト試算すると1年保存で数千万になることもあり、段階的コールド化が必須です。
stdoutに出すだけで十分
アプリとしては正しい判断です。ただし収集基盤が別途必要で、12-Factor App に従います。
ログ量・保存期間の数値Gate
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
ログは「全部取る」と請求書が爆発するので、用途別の保存戦略が必須です。
| 項目 | 推奨値 | 理由 |
|---|---|---|
| 本番ログレベル | INFO以上 | DEBUG は禁止（量が10倍） |
| ホット保存期間 | 7〜30日 | 障害調査の即応性 |
| ウォーム保存期間 | 3〜6か月 | 分析・監査 |
| コールド保存期間（監査） | 1〜7年 | 規制対応（金融: 7年、PCI DSS: 1年） |
| 1リクエストあたりのログ量 | 1KB以下 | 肥大化防止 |
| エラーログ保存 | 100%（サンプリング禁止） | 全て残す |
| 成功ログ保存 | 1〜10%サンプリング | コスト削減 |
| ログ形式 | 構造化JSON | AI・機械可読 |
| 必須フィールド | timestamp／level／service／trace_id | 横断検索 |
| PII（個人情報）出力 | 絶対禁止 | マスキング必須 |
月間ログ量の目安は、〜10GBはCloudWatch無料〜数千円、〜1TBはLokiで数万円、〜10TBはElasticsearch自社運用で月数十万円、それ以上はSplunkエンタープライズで数百万円〜。月1TB超になったらLoki／Grafana Cloudへの移行を検討すべきラインです。
ログは「取る」より戻せる形で残す。段階的コールド化とサンプリングで費用を制御します。
ログ運用の鬼門・禁じ手
ログで事故る典型パターン。どれも情報漏洩・コスト爆発・調査不能のいずれかにつながります。
| 禁じ手 | なぜダメか |
|---|---|
| PII（個人情報・パスワード・APIキー）をログ出力 | 2018年 GitHub 平文パスワード事件、470万件強制リセット発生 |
| フリーテキストログ | 検索・集計・AI 解析が困難。構造化JSON必須 |
| trace_idなしでマイクロサービス運用 | 横断検索不能、障害調査が数時間〜数日に |
| 全てをINFO以上で出す | 本番でDEBUG残しは月100万円請求の定番 |
| 単一サービスだけ独自形式のログ | 横断検索で詰まる。チーム内で標準を統一 |
| ログをアプリと同じストレージに保存 | 侵害時にログごと消される。別アカウント + WORM |
| 永久保存を目指す | 年間数千万円のストレージ課金。段階的コールド化 |
| エラーログのサンプリング | エラーは100%保存が鉄則。失敗は全て残す |
| HTTPボディを丸ごとログ出力 | 2021年 Twitter 内部ログAPIキー混入事件のパターン |
| pre-commit hookなしでprint文を残す | 個人情報が混入する典型。GitLeaks／detect-secretsで防ぐ |
| 監査ログと一般ログを混在 | 監査対応不能。別ログストリームで分離 |
2018年の GitHubパスワード平文ログ事件（パスワードリセット機能の実装ミスで一部ユーザーの平文パスワードが内部ログに記録、約470万件の強制リセット）、2021年の Twitter内部ログAPI Key混入事件（HTTPボディ丸ごとログ出力で認証トークンが6か月分の監査ログに残留）──ログに何を出すかの設計漏れが情報漏洩に直結する事例です。
PII・トークン・パスワードの出力禁止は実装レベルで強制。運用ルールだけでは守れません。
AI時代の視点
AI 駆動開発（バイブコーディング）と AI 活用が前提になると、ログはAIが読んで診断する教材として再定義されます。Datadog Bits AI・Grafana LLM 等の AI アシスタントは、ログを解析して障害の原因を自然言語で説明してくれます。
| AI時代に有利 | AI時代に不利 |
|---|---|
| 構造化ログ（JSON） | フリーテキスト |
| 標準スキーマ（OTel Logs） | 独自フォーマット |
| trace_id で相関 | 孤立したログ |
| 意味のあるメッセージ | 「エラー発生」だけ |
AI が「このエラーの原因は○○で、△△を直せばいい」と答えてくれる時代が始まっています。前提は AI が理解できる構造で出力することで、メッセージには何が・なぜ失敗したかを明示するのが新しい基準です。
ログはAIへのメッセージ。機械が読んで診断できる形で残します。
筆者メモ — 「ログに全部書いていた」が情報漏洩に変わった事例
「とりあえず全部ログに出しておく」が事故に繋がった事例は、業界の定番の教訓です。
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対策（マスキング・検出）
最終的な判断の仕方
ログ設計の核心は半年後の自分への手紙であり、書いた直後ではなく将来の障害調査で真価が問われます。構造化ログ（JSON）を標準にし、trace_id／service／user_id といった標準項目を統一して横断検索できる状態を作るのが合理的な判断です。フリーテキストログはもはやアンチパターンで、PII（個人情報）を絶対出さない規律と、段階的コールド化でコストを抑える運用が必須になります。エラーは100%保存し、成功はサンプリングするのが、大規模で破綻しない定石です。
もう一つの決定的な軸はログはAIへのメッセージです。Datadog Bits AI や Grafana LLM のような AI アシスタントがログを読んで障害原因を自然言語で説明する時代、構造化・標準スキーマ・trace_id 相関が揃っていれば数秒で原因仮説が立ちます。逆にフリーテキスト・独自フォーマットは、AI も人間も読めない負債になります。
選定の優先順位
- 構造化ログをデフォルト — JSON・標準項目・意味のあるメッセージ
- PII出力を絶対禁止 — マスキング・検出・pre-commit、一度出したら回収不能
- 段階的コールド化 — ホット30日／ウォーム3〜6か月／コールド1〜7年
- trace_idで相関 — メトリクス・トレースと紐付け、AI診断の基盤に
「ログはAIへのメッセージ」構造化・標準・相関で、半年後に真価が出る形で残します。
まとめ
本記事はログ設計について、ログレベル・構造化ログ・必須項目・収集と保存先・保持期間・サンプリング・PII保護・AIへのメッセージ視点まで含めて解説しました。如何だったでしょうか。
構造化ログをデフォルトに、PII出力を絶対禁止、段階的コールド化、trace_idで相関する。これが2026年のログ設計の現実解です。
次回はSLOとSLI（信頼性目標とエラーバジェット）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（63/89）