2026年04月13日 · OpenWorks · it-trends

ログ集約システムの導入で本当に必要な粒度と、ストレージコスト削減の折り合い

ログ集約ストレージコスト運用設計システム設計スケーラビリティ

ログ集約は「便利だから」では止まらない現実

ログ集約システム（ELK Stack、Datadog、Splunk など）の導入話が増えています。クラウドネイティブな開発環境が浸透し、マイクロサービスやコンテナ化されたアーキテクチャが広がったことで、単一サーバのログファイルを tail で見るだけでは追いつかなくなったからです。

ただし、実際に導入を進めると、誰もが同じ壁に直面します。ログの粒度を上げるほど、保存量が指数関数的に増え、ストレージコストが経営判断を揺さぶる という現実です。

現場では「とりあえず全部集約しておこう」という判断が起きやすいのですが、これが後々の運用負荷と予算の軋轢を生みます。本来必要な粒度と、実現可能なコストのバランスをどこに引くかが、ログ集約導入の成否を左右します。

ログ集約システムの導入検討では、通常こう考えます。

この判断は一見合理的ですが、実装段階で現実と衝突します。

例えば、API サーバが 1 秒間に 1000 リクエストを処理する環境を想像してください。リクエスト ID、タイムスタンプ、ユーザ ID、メソッド、パス、レスポンスコード、応答時間を記録する。これだけで 1 行あたり 200 バイト前後です。

1 日で：1000 req/s × 86400 秒 × 200 bytes ≈ 17 GB

これが 10 台のサーバで動いていたら 170 GB。さらに ERROR や WARN ログが追加されると 200 GB を超えます。30 日保持なら 6 TB。ストレージ代だけでなく、検索性能の低下、ネットワーク帯域の圧迫、バックアップ対象の肥大化も起きます。

現場では「3 ヶ月保持」という判断が起きやすいのですが、このスケールになると意思決定者の同意を取りにくくなります。

では、どのレベルのログ粒度が「現実的」なのか。ここは組織の成熟度とシステムの特性で変わります。

まず記録すべきは以下です。

これらは 保持期間を長めに（3～6 ヶ月） してもコスト効率が悪くありません。なぜなら、記録量が限定的で、かつ参照頻度が高いからです。

次のようなログは、粒度を意識的に下げるべき候補です。

これらは 環境で記録レベルを分ける ことが有効です。

本番環境：
  - ERROR, WARN, 重要イベント のみ
  - 保持期間：3～6 ヶ月

ステージング環境：
  - INFO, WARN, ERROR
  - 保持期間：1～2 ヶ月

開発環境：
  - DEBUG 含めて全て
  - 保持期間：1 週間

このように環境ごとに分けることで、本当に必要な情報は長期保持し、ノイズは早期削除できます。

完全な全記録を諦めることも、実は有効な戦略です。

アクセスログのように「成功ケースが大多数」という状況では、サンプリングが機能します。例えば：

こうすることで、ログ量を 1/10 以下に圧縮しながら、問題検出能力はほぼ損なわれません。

特定の IP アドレスやユーザエージェント（ヘルスチェック、ボットなど）からのアクセスをフィルタリングするだけでも、記録量の 20～30% が削減できる場合があります。

ログ集約の導入を検討する際、以下を確認することをお勧めします。

現在の課題は何か：「ログが分散していて原因追跡に時間がかかる」なのか、「何か起きたときに履歴を遡りたい」なのか。課題が明確でないと、粒度の決定ができません
月額のストレージ予算はいくらか：予算が決まっていなければ、「とりあえず全部」になりやすい。逆算して粒度を決めるべきです
検索対象は何か：全ログを検索することは稀です。「エラーログだけ検索する」「認証ログだけ検索する」など、用途を限定するほど、記録量を減らせます
保持期間は本当に必要か：監査要件がない限り、 30 日で十分な場合が多いです。「念のため」で 3 ヶ月は、コスト効率が悪い判断になりやすい

ログ集約システムは、間違いなく価値のあるツールです。ただ、その価値は「全情報を記録すること」ではなく、「本当に必要な情報に素早くアクセスできること」 にあります。

導入時は、粒度とコストのバランスを意識的に設計することが、長期的な運用の安定性につながります。現場では「とりあえず」という判断が起きやすいのですが、ここで一度立ち止まり、本当に何が必要かを問い直す価値があります。