ボットトラフィック急増時代のNew Relic転送量管理 — 日次Slackレポートで観測・予測・テストまで

Last updated at 2026-07-15Posted at 2026-07-15

はじめに:
転送量は『自分たちの意思だけでは決まらない』変数になった

私は現在、SaaS型ECサイト構築プラットフォームのフロントエンド開発に従事しており、New Relicを活用したオブザーバビリティの推進にも携わっています。

New Relicの料金は、ユーザー数とともに インジェストしたデータ量（GB Ingested。本記事では「転送量」と表記） に応じて決まります。つまり転送量は観測コストを大きく左右する変数です。
そしてこの変数が今、自分たちのリリースやトラフィック計画とは無関係な外部要因で動く局面に入りつつあります。

ボットトラフィックの急増という実情

弊社のECプラットフォームでも、クローリングをはじめとするボット由来のアクセスが、近年増加していると感じています。Browser監視（PageView等）では、JavaScriptを実行するボット由来のアクセスも計測対象になり得るため、ボットトラフィックの増加がインジェスト量へ影響する可能性があります。

これは弊社環境だけの話ではないようです。業界データを見ると、

Cloudflareの分析では、2024年5月から2025年5月にかけて、検索クローラーとAIクローラーを合わせたトラフィックが18%増加しました。個別のクローラーでは、GPTBotのリクエスト数が同期間に305%増加しています。¹
また、HUMAN Securityの調査では、AIシステムによって、またはAIシステムのために生成された「AI由来トラフィック」の月間量が、2025年1月から12月にかけて187%増加し、約2.9倍になったと報告されています。さらに、同社の顧客環境で観測されたAI由来トラフィックの95%以上が、小売・EC、ストリーミング・メディア、旅行・宿泊の3分野に集中していました。²

ここでいうAI由来トラフィックには、AI学習用クローラーだけでなく、リアルタイムの情報を取得するスクレイパーや、Web上で操作・取引を行うAIエージェントも含まれます。そのため、これらの数値をそのまま弊社環境のBrowser計測やインジェスト量の増加原因と結びつけることはできません。ただし、更新頻度が高く、商品や価格などの構造化された情報を持つECサイトが、AIによる情報取得の主要な対象になっていることは読み取れます。

Cloudflareが2025年7月、同社へ新たに追加されるドメインについて、AIクローラーをデフォルトでブロックする方針へ変更したことも、Webサイト運営者にとってAIクローラーへの制御が現実的な課題になったことを示す動きです。³

弊社環境で増加したトラフィックの内訳を現時点で断定することはできません。それでも、事業成長やリリース計画だけでは説明できない外部トラフィックが、計測量と観測コストを動かし得る以上、「転送量は自分たちの意思だけでは決まらない」ことを前提に管理する必要性は高まっています。

削減手段は多様。だからこそ「観測」が先

転送量の削減手段は、環境ごとにさまざまです。

収集パイプライン側で制御する
例：OpenTelemetry Collector
Browser計測の一部を制御する
例：Ajax Deny ListによるAjaxRequestの除外
New Relic側で取り込み対象を制御する
例：Pipeline Control系の機能

弊社ではこのうち、NRQL Drop RuleのEOLを機に、OpenTelemetry CollectorとAjax Deny Listを主に利用する形へ移行しました。

従来のNRQL Drop RuleはEOL（2026年8月31日）が確定しており、以降はPipeline Control cloud rulesへの移行が必要です ⁴。また、後継のcloud rulesはAdvanced Computeの課金対象で、dropしたデータ量やルールがスキャンしたイベント数に応じてaCCUが発生します ⁵。「データを削る」行為自体のコスト構造が変わる移行期にあります。

ただし、どの削減手段を選ぶにせよ、先に必要なのは観測と予測です。どこで・なぜ増えているかが分からなければ削る対象を決められず、削った効果も観測なしには検証できません。

本記事では、この「観測・予測」を担う仕組みとして構築した、転送量の日次Slackレポートの作り込みを紹介します。転送量レポートの実装自体に加え、運用の中で通知を直し続けるために、どのようにテスト可能な設計へ変えたかを中心に扱います。

主な論点は次の2点です。

なぜアラートではなくレポートなのか
運用の中で見えてきた、通知を直し続けるための仕組み
- 具体的には、workflowInputsによるテスト設計

なお、本記事は次の2本の続編にあたります。

第1弾: SaaS型ECプラットフォームで予期せぬリソース参照を観測する — Workflow Automationによる日次通知の最初の構築
第2弾: New Relic Workflow AutomationをIaC化して、"作って終わり"の運用から抜け出す（Terraform公式対応済み）

対象読者

New Relicの転送量（インジェストコスト）を管理する立場にある方
使用量の可視化を「ダッシュボードを見に行く」運用から先に進めたい方
Workflow Automationの実践的なユースケースを探している方

検証環境（2026年7月時点）

項目	内容
New Relic	Workflow Automation（2026年2月GA ⁶）、リージョン: US
通知先	Slack
しきい値	本文中の月間上限6TB・日次目安197.3GBは例示値です。実際の値はご自身の契約・環境に合わせてください

位置づけ:
アラートでもダッシュボードでもなく、なぜ日次レポートか

作り込みの前に、一番大事な設計判断から書きます。転送量の把握には公式に推奨される手段が既にあります。本レポートはそれらの代替ではありません。

役割	適した手段
スパイクの即時検知	NRQLアラート（時間単位の使用量にしきい値）⁷
月間上限超過の最終防衛線	`NrMTDConsumption` へのしきい値アラート（公式推奨）⁷
増加要因の深掘り分析	ベースラインダッシュボード ⁸
日々のペース共有・着地予測・「正常であること」の確認	日次レポート（本記事）

上3つは公式の推奨パターンで完結します。問題は4行目です。

アラートには構造的な性質があります。異常がないとき、沈黙することです。そして沈黙は「問題ない」と「仕組みが壊れている」を区別できません。一方、予算管理という営みは「超えたら教えて」ではなく「今月どのくらいのペースか」を日々把握し続けることです。

ダッシュボードはこれに応えられますが、見に行く習慣に依存します。ダッシュボードを毎朝Slackへ自動配信するネイティブなスケジュール機能は、2026年7月時点では確認できませんでした。

NerdGraphのスナップショットAPIを利用した自作や、OSSのnr-reportsという選択肢はあります ⁹。

つまり「異常がなくても毎朝、予算の消化ペースがチームの目の前に届く」という定常プッシュ型の運用には空白地帯があり、ここを埋めるのが本レポートです。アラートが沈黙している日常の側を担う、と言い換えてもよいです。

もう1つの判断軸が、しきい値の扱いです。転送量の目安値は契約や環境によって変わる可変パラメータです。一方、NRQLアラートのしきい値はアラート条件側の設定値として管理されるため、日次レポートのように実行時の入力でしきい値を差し替えながら検証する、という使い方には向きません。

本レポートではしきい値を定義内の名前付き変数として持ち、実行時に上書きしてテストできます。この設計は後半（workflowInputsの章）で詳しく扱います。

作ったもの:
転送量の日次Slackレポート

毎朝09:30（JST）、Slackに次の判断材料が1通で届きます。

直近24時間の実績と日次目安との差 — 超過していれば⚠️付きで注意喚起
前週比 — 増減のトレンド
月間累計と上限までのバッファ — 今月の消化状況
月末の着地予測 — このままのペースだとどこに着地するか

通知はあくまで「毎朝の判断材料」で、深掘りが必要な場合は、通知内のリンクからダッシュボードへ遷移する二段構えにしています。実装はNew RelicのWorkflow Automationで、NRQLを実行するステップとSlack通知ステップをつないだシンプルな構成です。

実装の勘所: NRQL設計

月末の着地予測

核になるのは着地予測のクエリです。

SELECT
  sum(GigabytesIngested) AS 'MTD_Actual_GB',
  ${{ .workflowInputs.monthlyLimitGb }} - sum(GigabytesIngested) AS 'MTD_Remaining_GB',
  rate(sum(GigabytesIngested), 730 hours) AS 'Predicted_EOM_GB'
FROM NrConsumption
WHERE productLine = 'DataPlatform'
SINCE THIS MONTH
WITH TIMEZONE 'Asia/Tokyo'

rate(sum(...), 730 hours) は、月初からの合計を「730時間（≒1ヶ月）あたりのペース」に換算します。月間平均ペースを730時間へ換算した、単純な着地見込みです。

ここでは、1か月を730 hoursとして近似しています。暦月の日数や月内の残日数を厳密に反映した予測ではありませんが、月間平均ペースがこのまま続いた場合の着地感を把握するには十分と判断しています。

予測手段としては、公式のHolt-Winters法ベースの PREDICT 句や predictLinear() もあります ¹⁰。PREDICT はTIMESERIESチャートに予測線を引く用途に強力ですが、今回は「Slack通知に載せる月末着地の単一値」が欲しかったため、rate() を採用しました。季節性を織り込んだ高度な予測が必要になったら PREDICT への乗り換えを検討する、という整理です。

タイムゾーンの明示

見落としがちですが重要なのが WITH TIMEZONE 'Asia/Tokyo' です。

NRQLの SINCE THIS MONTH のような集計窓・月境界は、アカウントのタイムゾーン設定に暗黙に依存します。「09:30 JST更新の日次レポート」を謳うなら、クエリ側でタイムゾーンを明示して集計窓を固定しておかないと、アカウント設定次第で「今月」の境界がずれます。

比較の窓設計

前日比・前週比は SINCE ... UNTIL ... で窓をずらして取得します。

-- 前週同日: 8日前から7日前までの24時間
SELECT sum(GigabytesIngested) AS 'LastWeek_GB'
FROM NrConsumption
WHERE productLine = 'DataPlatform'
SINCE 8 days ago UNTIL 7 days ago
WITH TIMEZONE 'Asia/Tokyo'

実は初期実装では「前週比」のつもりで SINCE 2 days ago UNTIL 1 day ago（=前日比）と書いており、運用の中で気づいて直しました。この手の「動いているが意図と違う」変更が続くことが、後半の話に繋がります。

運用して分かったこと:
通知は「直し続けるもの」だった

この通知は数週間の運用の中で、既に何度も修正が発生しています。
そしてその修正要因は、コードのバグだけではありませんでした。

実例①: 通知文言の陳腐化

超過時の通知文言に、対処ガイドとしてこう書いていました。

⚠️ 日次目安を超過しました → 内訳を確認し、スパイクの原因調査やDropルールの強化を検討してください。

この一文は、書いた時点では正しい案内でした。
しかしその後、NRQL Drop RuleのEOL（2026年8月31日）が確定し ⁴、弊社ではこれを機に、削減手段の主力をOpenTelemetry CollectorとAjax Deny Listへ移行しました。

その結果、この文言は「まもなく存在しなくなる機能」への案内であると同時に、「もう主力ではない手段」への案内にもなりました。プロダクト側の変化（EOL）が組織側の運用変更を連鎖的に引き起こし、通知文言だけが取り残された形です。

そして、EOLのように変化の時期が確定しているケースでは、「古くなってから直す」のではなく「確定した時点で直す」が正解です。それができるかどうかは、変更のコストにかかっています。

補足: 文言設計で変更の発生源を減らす

通知文言に「具体的な対処手段」を書き込むと、今回のようにプロダクトと組織の変化のたびに文言が取り残されます。文言には「何が起きたか」だけを書き、「どうするか」は別途メンテナンスされるランブックへのリンクに寄せる設計にすると、この種の陳腐化は構造的に起きにくくなります。

※ただし、設計で減らせるのはこの種の変更だけです。しきい値の見直し・クエリの修正・表現の改善といった、変更需要そのものはなくなりません。

実例②: 動いていても、意図どおりとは限らない

初期実装では「前週比」のつもりで前日分を比較していました。クエリ自体は正常に実行され、通知も毎日届くため、機能の失敗としては表面化しません。運用して数字を見続けたことで、初めて意図とのずれに気づきました。

このようなクエリ解釈の修正に加え、しきい値の見直しや通知文言の調整など、運用を始めてから見えてくる変更需要は継続的に発生します。

そして、変更コストの壁

ここで問題になるのが、通知機能は変更のたびのテストが難しいことです。文言を1行直しただけでも「実際にSlackでどう見えるか」を確認したい。

しかし、

そのために本番チャンネルへ向けてテスト実行するのか
超過時の⚠️分岐の表示を確認したいが、実際に超過するまで待つのか

といった問題があります。

こうした変更コストの高さは、確実に改善を先送りさせます。

「文言が古いのは分かっているが、直すのが億劫」

という状態こそが、通知を腐らせる真因でした。

解決策:
workflowInputsで「変更コスト」を下げる

そこで、Workflow Automationの workflowInputs（実行時に上書きできる入力変数 ¹¹）を使って、この通知を「テストできる通知」に作り替えました。先に言っておくと、テストの易化は目的ではなく、変更コストを下げて改善サイクルを回すための手段です。

3つの困りごとと解決

困りごと	従来のワークアラウンド	workflowInputsでの解決
本番チャンネルを汚したくない	定義のチャンネルを書き換え、後で戻す（戻し忘れ事故のリスク）	`slackChannel` を実行時に渡す
テストしたものと本番の同一性がない	ない（書き換えた時点で別の定義）	デプロイ済みの定義をそのまま実行
異常系（⚠️分岐）を任意に発火できない	超過するまで待つ／データを偽造する	`dailyBudgetGb=1` を渡して分岐を強制発火

3つ目が個人的なハイライトです。異常系のテストのためにデータを偽造するのではなく、判定基準の方を動かす。本番の実データ・本番と同一の定義のまま、しきい値だけを実行時に差し替えれば、⚠️分岐は今すぐ発火させられます。

定義の変更内容

name: report_daily_ingest
workflowInputs:
  slackChannel:
    type: String
    defaultValue: your_notification_channel   # 本番チャンネル
  dailyBudgetGb:
    type: Float
    defaultValue: 197.3    # 例示値。月間上限から算出した日次目安
  monthlyLimitGb:
    type: Int
    defaultValue: 6000     # 例示値。月間上限（6TB）
steps:
  # ...NRQLステップでは ${{ .workflowInputs.dailyBudgetGb }} を参照...
  - name: send_slack_notification
    type: action
    action: newrelic.notification.sendSlack
    version: 1
    inputs:
      destinationId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
      channel: ${{ .workflowInputs.slackChannel }}
      text: >-
        ...（${{ .workflowInputs.dailyBudgetGb }} を文言内でも参照）...

安全設計: defaultValueは常に本番値

設計のキモは、defaultValueに本番の値を置くことです。確認済みのversionを参照するスケジュール実行ではinputを渡さないため、defaultValueで動きます。つまり「何も渡さなければ本番動作」です。

手動テストで渡した値はdefaultValueを書き換えないため、テスト実行の入力がそのまま通常のスケジュール実行へ残ることを防げます。テストチャンネル名やテスト用しきい値を、YAMLやTerraformの定義へ書き込む必要もありません。

落とし穴: しきい値はクエリ外にも記載があった

しきい値の変数化には落とし穴がありました。197.3 という値は、クエリ（2箇所）・超過判定の条件分岐・通知文言の中（「日次目安(197.3GB)との差」のような表記が3箇所）に散在していたのです。

クエリと分岐だけ変数化して文言を直し忘れると、「dailyBudgetGb=1 で⚠️が発火したのに、文言は197.3GBと表示される」という不整合が起きます。変数化とは値の置換ではなく、値が現れる全箇所の棚卸しです。地味ですが、テストして初めて気づくタイプの罠でした（そしてこの不整合に気づけたこと自体が、テストできるようになった効能でもあります）。

UIの隠れた効能

workflowInputs を宣言すると、UIの手動実行ダイアログに入力欄が自動生成されます（defaultValueがプレフィルされる）。宣言前はパラメータを渡す口自体が存在しなかったので、これは大きな変化です。

validations を併せて宣言すれば、対応する型について入力値を制限できます ¹¹。

monthlyLimitGb:
  type: Int
  defaultValue: 6000
  validations:
    - type: minIntValue
      errorMessage: "0以上の値を指定してください"
      minValue: 0

つまりworkflowInputs化は、APIからの制御だけでなく「エンジニアでなくてもUIから安全に動作確認できる導線」を作る対応でもあります。NerdGraphから実行する場合は workflowAutomationStartWorkflowRun に workflowInputs: [{key, value}] を渡し、返ってくるrunIdで実行ログを追跡できます ¹²。

アラートとの対比

前半で、NRQLアラートは実行時の入力でしきい値を差し替えながら異常系を確認する用途には向かないと書きました。workflowInputs化した通知は、本番のdefaultValueを一切触らずに異常系を発火できます。

これが「しきい値という可変パラメータを名前付き変数として持つ」設計の実利です。

副産物として、本記事の仕組みを自環境に適用する場合も、defaultValueを契約値に差し替えるだけで済みます。

改善サイクルの完成:
テスト容易性 × コード管理

テスト容易性とあわせてもう1つ必要なのが、変更管理です。
定義はTerraformでコード管理しており（手順は第2弾の記事）、変更はYAMLのdiffとしてPull Requestでレビューし、terraform planで影響を確認してから反映します。

ただし、2026年7月時点のnewrelic_workflow_automationリソースが管理するのはWorkflow定義であり、スケジュールは管理対象に含まれていません。スケジュールは特定のWorkflow versionに固定されるため、Terraformで定義を更新して新しいversionが作成されても、既存スケジュールは旧versionを参照し続けます。テスト完了後に、UIまたはNerdGraphのSchedule APIで参照versionを更新する必要があります ¹³¹⁴¹⁵。

これで、運用改善の1サイクルはこうなりました。

変更をYAMLで書く（文言修正・しきい値変更・除外条件追加）→ PRでdiffレビュー
Terraformでapplyし、新しいWorkflow versionを作成する
UIまたはAPIからテストチャンネル＋テスト用しきい値で実行し、正常系・異常系の実際の表示を確認する
テスト完了後、UIまたはSchedule APIでスケジュールの参照先を確認済みのversionへ更新する
翌朝のスケジュール実行で、確認済みの定義が動作することを確認する

このサイクルを支えるのが、次の2つです。

変更をためらわない仕組み（workflowInputs）
変更を安全に反映する仕組み（Terraform）

この2つが揃って初めて、通知は「直し続けるもの」から「直し続けられるもの」になります。
確定した文言の陳腐化を確定した時点で直すことも、
理解の修正を気づいたその日に入れることも、
特別な対応ではなく通常の運用サイクルの一部になりました。

一方で、スケジュールのversion更新は現時点ではTerraformだけで完結しません。この境界を隠さず、明示的な運用手順として組み込むことも、仕組みを信頼できる状態に保つために必要です。

本記事の限界・注意点

本レポートはアラートの代替ではありません。着地予測は月間平均ベースであり、急激なスパイクには鈍感です。スパイクの即時検知と上限超過の最終防衛線は、公式推奨のNRQL/NrMTDしきい値アラート ⁷ を併設してください
NrConsumption の値は目安であり、請求額と厳密には一致しません ⁷。また月次集計（NrMTDConsumption）は計算が毎時・生成に約3時間かかるとされており ⁷、朝の実行タイミングでは直近数時間分が未反映の可能性があります
Workflow Automationのスケジュールは、2026年7月時点のnewrelic_workflow_automationリソースでは管理できません。また、スケジュールは特定のWorkflow versionに固定されるため、定義を更新しても自動では最新versionへ切り替わりません。applyとテストの完了後に、UIまたはNerdGraphのSchedule APIで参照versionを更新する必要があります ¹³¹⁴¹⁵
しきい値（月6TB・日次197.3GB）は例示値で、契約・環境に依存します
転送量の削減手段そのもの（OTel Collector・Ajax Deny List・Pipeline Controlの設計や比較）は本記事のスコープ外です。機会があれば別記事で扱います

まとめ

ボットトラフィックの増加により、転送量は「自分たちの意思だけでは決まらない」変数になりつつある。削減の前に、まず観測と予測
アラート（異常時）とダッシュボード（見に行く）の間には、「異常がなくても毎朝ペースを共有する」定常プッシュの空白地帯がある。日次レポートはアラートの代替ではなく、その沈黙を補完する
通知は作って終わりではなく直し続けるもの。だからこそ、しきい値・通知先をworkflowInputsで変数化し、本番定義のまま数分でテストできる状態にしておくことが、改善サイクルを維持する土台になる
Terraformで定義を管理しても、スケジュールの参照version更新は別途必要になる。自動化できない境界を運用手順として明示することも、通知を信頼できる状態に保つための一部である

観測の仕組みは、それ自体が観測され、直され続けることで初めて信頼されます。この記事が、転送量管理を「たまにダッシュボードを見る」から一歩進めたい方の参考になれば幸いです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up