トップ > New Relic > 【New Relic】無駄なログでO11yコスト圧迫してませんか？ ～ログパターンを活用したO11yコスト削減事例

【New Relic】無駄なログでO11yコスト圧迫してませんか？ ～ログパターンを活用したO11yコスト削減事例

New Relic ログ管理 AWS Summit Japan 2026
記事タイトルとURLをコピーする

はじめに

こんにちは、サーバーワークスの福田です。

本記事は、AWS Summit Japan 2026のNew Relic社のミニシアターにて発表させていただいた内容をブログ記事としてまとめたものです。 参考：AWS Summitミニシアターtimetable_New Relic

「とりあえず全部送っておこう」という判断でログをNew Relicに流し込んでいませんか？ 実はその"念のため"が、コストを圧迫しているかもしれません。

本記事では、New RelicのLog Patterns機能とPipeline Controlを使って、不要なログを特定・除外し、数TB/月規模のデータ削減を実現した事例をご紹介します。

なぜ「全部送る」がまずいのか

「念のため全部送っておこう」が招く3つの問題

オブザーバビリティツールを導入したとき、ついやりがちなのが「データを全部送ること」です。しかしこれにはいくつか問題があります。

① コストが際限なく増え続ける

不要データの転送にも従量課金が発生します。ストレージコストやインジェスト費用が積み上がり、予算を圧迫します。New RelicはTrue-Up方式のため月単位での超過請求はすぐには発生しませんが、収集データを最初から設計するほどコスト超過リスクを下げることができます。

② 運用チームが疲弊する

アラートが大量に飛んでくることで「アラート疲れ」が起きます。本当に重要な通知を見落とすリスクが高まり、障害対応コストの増大にもつながります。

③ 分析効率の低下

不要なデータが増えノイズが多すぎると、異常の発見や分析効率（AI活用を含む）が大幅に低下します。整理されていないデータ環境では、AIに分析を任せても精度が上がりません。

何が不要なログか？

不要なログ（コストを押し上げるだけ） 必要なログ（障害検知に役立つ）
正常系のINFO / DEBUGログ ERROR / WARNレベルのログ
DBヘルスチェック・定型クエリ パフォーマンス劣化・スロークエリ
スケジューラの起動・完了記録 ユーザー影響のあるリクエスト
正常なHTTPアクセスログ（200 OK） サービス間の依存関係のトレース
ネットワークの正常フロー 異常系のネットワークイベント

オブザーバビリティとは：まず「見える化」から始める

オブザーバビリティとは、複雑化したシステムを理解し、問題を素早く発見・解決できる状態を作ることです。

New Relic導入前後でどう変わるかを一言でまとめると

Before（導入前） After（New Relic導入後）
障害が起きても原因がわからない 問題の原因を数分で特定できる
ログを探すのに時間がかかる ログ・メトリクス・トレースを一画面で確認
担当者によって見えている情報がバラバラ チーム全員が同じ情報で意思決定
システムがブラックボックス システムの内側が見え、改善が加速

ただし、オブザーバビリティ導入はゴールではなく、スタートです。「なにを見える化するか」「見える化した情報をどのように活用するか」を設計することが重要です。

実践：不要なログを特定する3ステップ

STEP 1：Log Patternsでログのパターンを自動分類

New RelicのLog Patterns機能を使うと、類似したログを自動でグループ化し、件数の多い順に一覧表示してくれます。

操作手順

  1. ログ画面左メニューの「Logs」→「Patterns」をクリック
  2. 件数（count列）が多いパターンを上から確認する
  3. 右端に表示された件数が削減候補の目安

ポイント：件数グラフでパターン化されたログ数の推移も確認できます。急増しているパターンがあればすぐ気づけます。

docs.newrelic.com

STEP 2：内容を確認して「本当に必要か」を判断

特定したパターンのログ内容を展開し、以下の観点で判断します。

  • 障害検知に必要なログか？
  • 正常系の定型ログ（毎回同じ内容）ではないか？

200 OKの正常アクセスログや、スケジューラの「処理開始/完了」ログなどは、障害検知にほぼ寄与しないことが多いです。

STEP 3：Pipeline Controlで転送を停止する

不要と判断したログは、Pipeline Controlを使って除外します。アプリ側の改修・再デプロイは一切不要です。

Pipeline Control：収集するデータをNRQLで制御する

Pipeline Controlは、データがNew Relicに届く前の段階でフィルタリングし、必要なデータだけを保存する機能です。

docs.newrelic.com

2種類のドロップ方式

① Drop data：ログ種別をNRQLで指定してログ全体をドロップ

-- 例：cache_statusが'SYNTH'のログを除外
WHERE cache_status = 'SYNTH'

② Drop attributes：ログ自体をドロップするのではなくログ内の特定フィールドだけを削除（秘匿情報のマスクにも使える）

なぜPipeline Controlが便利なのか

  • アプリ側の変更・再デプロイが不要→ 影響範囲ゼロで即日コスト削減可能
  • 除外したデータはコスト計算に含まれない→ 実質的なコスト削減効果に直結
  • NRQLのWHERE句と同じ書き方で柔軟に条件指定できる
  • 設定はNew Relic UI上でGUI操作が可能で、リアルタイムで即時反映（再起動不要）

削減効果の確認方法

Pipeline Control設定後は、NRDBに格納されるデータ量と除外されたデータ量をUIで確認できます。

  • 右側の枠（課金対象）：ドロップ後のデータ量。Pipeline Controlを設定するとこの量が減少します
  • 左側の枠（除外分）：NRDBに届く前に除外されたデータ量

ポイント：設定直後からリアルタイムで効果が可視化されるので、本当に削減できているかをすぐ確認できます。

実際の削減効果

今回の取り組みで実現した効果は以下の通りです。

項目 結果
削減データ量 数TB/月規模
不要なログの特定時間 数時間〜数日（Log Patternsで効率化）
Pipeline Control設定時間 約1時間
コスト超過 ゼロ（契約内に収まっている）

Log Patternsで削減対象を特定し、Pipeline Controlで設定するというシンプルな2ステップで、大幅なデータ削減を実現できました。

まとめ

今回の内容をまとめます。

  1. 「全量転送」はコスト・運用・分析効率の三重苦を招く 　不要データの削減がコスト最適化とAI活用の前提になります

  2. Log Patternsで削減対象を可視化できる 　類似ログを自動分類し、件数が多いパターンを上位から確認するだけで削減候補を特定できます

  3. Pipeline Controlで再デプロイなしに対応できる 　NRQLで柔軟に除外条件を設定でき、設定後すぐに効果が出ます

  4. New Relicなら段階的に始められる 　Log Patterns + Pipeline Controlというシンプルな組み合わせで最適化をスタートできます

オブザーバビリティ導入はゴールではなく、スタートです。整理されたデータ環境がAIの分析精度と効率を大きく高めます。ぜひ「全部送っている」状態を見直すきっかけにしていただければと思います。

宣伝

弊社では、お客様環境のオブザーバビリティを加速するためのNew Relicアカウント開設を含めた伴走型のNew Relic導入支援サービスをご提供しております。もしご興味をお持ちの方は、こちらのNew Relic導入支援サービスのページよりお問合せ頂けましたら幸いでございます。

・福田 圭(記事一覧)

New Relic Trailblazer。New Relic Trailblazer of the Year 2025受賞。New Relic User Group運営。