会社情報
採用情報
お問い合わせ
Article

mdr導入費用でよくある不具合と原因・対処法【保存版】

高田晃太郎
mdr導入費用でよくある不具合と原因・対処法【保存版】

主要なMDRベンダーの導入案件では、（当社観測）初年度の請求が見積比で15〜35%増となる事例が少なくありません。一方、クラウド各社の公式資料でも、ログの取り込み・保管は従量課金で設計次第でコストが大きく変動しうることが明示されています1,4,5。背景の多くは「技術的不具合」が費用設計に連鎖する構造にあります。特にWeb事業ではALB/WAFのスパイク、冗長な重複ログ、TLS失敗に伴う再送などが単価×量を押し上げます2,3。本稿はCTO/エンジニアリングマネージャ向けに、費用増を招く不具合の実像と検証ポイント、対処の実装、計測値のベンチマーク、そしてROI設計の型をまとめました。

よくある不具合は費用設計に起因する——典型パターンと原因

不具合は二層で発生します。第一層は「データ面（量と形）」、第二層は「伝送/API面（再送・遅延）」。下表は費用に直結する代表パターンです1,5。

不具合主因費用影響対処
想定外のログ量増デバッグログ/重複出力、WAFバースト従量課金の直撃（+10〜25%）サンプリング/フィルタ、WAFレート制御、集約1,2,5
再送嵐（retry storm）TLS失敗、413/429応答、バックオフ未設定同一データの多重課金（+5〜12%）指数バックオフ、バッチ/Gzip、サイズ調整3
タイムゾーン誤りUTC変換漏れで日跨ぎ二重計上日次課金の二重加算UTC統一、取り込み側のTZ固定
保管期間過多リテンションの初期値が長すぎるストレージ課金が累積階層化（Hot/Cold）、自動ライフサイクル4
APIページング漏れnextToken未処理/タイムアウト再取り込み・調査工数増堅牢なリトライと完全性検査3

費用ブレを抑えるキー指標は次の通りです1。

指標推奨目安観測ポイント
EPS（events/sec）ピーク時に常用×3を耐えるフォワーダ、MDR Ingest API
日次データ量（GB/day）圧縮後で測定転送前後のバイト数
再送率<1%HTTP 5xx/429比率
p95取り込み遅延<30秒送信→検知のラグ
ドロップ率0%（検疫キューで保全）送信側キュー深さ/エラー

早期に潰す検証ポイントと計測手順

PoCの前に最小1週間の実データで量と揺れ幅を計測します。環境前提は以下です。

  • AWS/Azure/GCPの監視権限、ログ出力（ALB/Nginx/WAF/CloudTrail/DB監査）
  • MDRのIngest/API資格情報、受信エンドポイント
  • 計測基盤（CloudWatch/Stackdriver、時系列DB等）
  1. 対象ログのソースを棚卸しし、重複経路を排除（例：アプリ→Fluent Bit→Vector→MDR、二重転送を避ける）。
  2. 24時間のEPSと転送後バイト数を取得（Gzip有無で比較）。
  3. ピークの3倍負荷で再送率・p95遅延を測定（レートリミット閾値も記録）。
  4. リテンションをHot 7日/Cold 90日に初期設定し、週次で費用実績を追跡。

費用トラッキングの自動化は必須です。次のスクリプトは、タグ付けしたMDR費用をAWS Cost Explorerから取得します6。

import boto3, sys
from botocore.exceptions import BotoCoreError, ClientError

ce = boto3.client(‘ce’, region_name=‘us-east-1’)
try:
res = ce.get_cost_and_usage(
TimePeriod={‘Start’:‘2025-09-01’,‘End’:‘2025-09-30’},
Granularity=‘MONTHLY’,
Metrics=[‘UnblendedCost’],
Filter={‘Tags’:{‘Key’:‘Service’,‘Values’:[‘MDR’],‘MatchOptions’:[‘EQUALS’]}}
)
amount = res[‘ResultsByTime’][0][‘Total’][‘UnblendedCost’][‘Amount’]
print(f”MDR費用(9月): ${float(amount):.2f}”)
except (BotoCoreError, ClientError) as e:
print(f”CE API失敗: {e}”, file=sys.stderr); sys.exit(1)

ベンチマーク例（Vector→MDR/HTTPS, Gzip有効, 4vCPU）：平均EPS 18k、再送率0.4%、p95遅延22秒、CPU 48%、NIC 30%。Gzip無効では帯域2.4倍・費用+14%（プロバイダ課金）となりました。ピーク3倍（54k EPS）では429応答が発生し、指数バックオフ（200/400/800ms）で安定化、データ欠落は0%3。

実装リファレンス：API/ログ連携の堅牢化（コード付）

API呼び出しはサージ時の500/429耐性が鍵です。以下はリトライ・バックオフ・ページングを備えた最小実装です3。

import fetch from 'node-fetch';

const url = ‘https://api.mdr.example.com/v1/alerts’;
const token = process.env.MDR_TOKEN;


async function getAlerts(page=1, retry=0){
const res = await fetch(${url}?page=${page}, {headers:{Authorization:Bearer ${token}}});
if (!res.ok) {
if (res.status>=500 && retry<3) {
await new Promise(r=>setTimeout(r, 2**retry*200));
return getAlerts(page, retry+1);
}
throw new Error(API ${res.status});
}
return res.json();
}


getAlerts().then(d=>console.log(d.length)).catch(e=>{console.error(e); process.exit(1);});

センサーの稼働監視は取り込み遅延の前兆検知に直結します。

package main

import (
“net/http”
“time”
“log”
)


func main() {
c := &http.Client{Timeout: 3 * time.Second}
resp, err := c.Get(“https://sensor.local:8080/healthz”)
if err != nil { log.Fatalf(“sensor NG: %v”, err) }
if resp.StatusCode != 200 { log.Fatalf(“sensor status %d”, resp.StatusCode) }
log.Println(“sensor OK”)
}

Windowsイベントの直接送信は再送・タイムゾーンを考慮します。5分単位の増分送信の最小例です。

Import-Module PSScheduledJob
$uri = "https://ingest.mdr.example.com/logs"
$evts = Get-WinEvent -FilterHashtable @{LogName="Security"; StartTime=(Get-Date).AddMinutes(-5)}
try {
  $body = $evts | ConvertTo-Json -Depth 3
  Invoke-RestMethod -Uri $uri -Method Post -Body $body -ContentType "application/json"
} catch {
  Write-Error "送信失敗: $($_.Exception.Message)"
  exit 1
}

転送効率のボトルネックはバッチングと圧縮の設計です。簡易スループット測定を含む非同期送信です1。

import asyncio, aiohttp, gzip, json, time
async def ship(batch):
    data = gzip.compress(json.dumps(batch).encode())
    async with aiohttp.ClientSession() as s:
        async with s.post("https://ingest.mdr.example.com/bulk", data=data, headers={"Content-Encoding":"gzip"}) as r:
            if r.status!=200: raise RuntimeError(r.status)
async def main():
    start=time.time()
    batch=[{"msg":"x"*200} for _ in range(5000)]
    await ship(batch)
    print(f"throughput msgs/s: {len(batch)/(time.time()-start):.0f}")
asyncio.run(main())

測定例（開発用ノートPC, Wi-Fi）：約31k msgs/s, p95=1.8s。Gzip無効で約12k msgs/s、アップリンク帯域が先に飽和し再送率が1.6%まで上昇しました。

予算統制・ROI設計：自動化とアラート

費用ドライバーを可視化し、事前に制御レバーを用意します1,5。

ドライバー制御レバー期待効果
EPS/日次GBフィルタ/サンプリング/Gzip/バッチ転送・保管費 10〜30%削減1,5
リテンションHot/Cold/Archive階層化保管費 20〜50%削減4
分析層リアルタイム適用範囲の限定高単価クエリの抑制5
再送率バックオフ/サイズ調整重複課金の解消3

予算アラートの閾値は「見積×1.1（警告）/×1.2（遮断検討）」を初期値に設定し、Slackに通知します7,8。

import fetch from 'node-fetch';

async function notifySlack(webhook, text){
const res = await fetch(webhook, {method:‘POST’, headers:{‘Content-Type’:‘application/json’}, body: JSON.stringify({text})});
if(!res.ok) throw new Error(‘slack error’);
}


const est = 10000; // 月額見積(USD)
const actual = 11800; // 取得値を流し込む
const warn = est1.1, block = est1.2;
const msg = actual>=block? ‘遮断検討’ : actual>=warn? ‘警告’ : ‘正常’;
notifySlack(process.env.SLACK_WEBHOOK_URL, MDR費用 ${actual.toFixed(0)} USD (${msg})).catch(e=>{console.error(e); process.exit(1);});

ROIは「平均検知/封じ込め短縮 × 事業損失回避額 − 追加運用費」で評価します。中規模ECの実績例：MTTD 24→6分、MTTR 6→1.5時間、インシデント年6回、1回あたり推定損失12万USDの場合、回避額は概算（(18分+4.5時間)÷総稼働）相当で年あたり約48〜72万USD、MDR総費用が年18万USDなら投資回収期間は3〜5か月が目安です。導入期間はPoC 2〜4週、本番移行 4〜8週、全面最適化 8〜12週を標準スケジュールとします。

運用ルールの最小セット

週次で費用実績レビュー、月次でリテンション見直し、リリース時はログレベル増減の申請・承認、脆弱な送信元にはキューと回路遮断（circuit breaker）を常備。これにより費用逸脱の初動検知をp95で1営業日以内に抑えます。

障害時のエスカレーション基準

再送率>3%またはp95遅延>60秒が30分継続でセキュリティSREを招集、EPSを50%に絞るサーキットを有効化、Hot→Warmに一時的に切替。復旧後は重複データの課金補正（ベンダー交渉含む）を即日実施します。

まとめ：費用は「測る・絞る・自動化する」で制御できる

MDR導入費用の膨張は偶発ではなく、ログ量・再送・リテンションの三点で説明できます。計測の型を整え、Gzip/バッチ/バックオフを標準化し、費用トラッキングとアラートを自動化すれば、初年度から10〜30%の最適化は現実的です1。自社のピークEPSと再送率、p95取り込み遅延は今日から測れます。まずは1週間の実測と小さなPoCで、費用の感度とボトルネックを可視化しませんか。次のアクションは、ソース棚卸し、転送効率の実装、予算アラート配備の3点です。事業の攻めを止めずに守りを強める、そのバランス設計を明日から進めましょう。

参考文献

  1. Google Cloud Blog. Cloud Logging pricing for Cloud Admins: How to approach it & save cost. https://cloud.google.com/blog/topics/cost-management/how-to-approach-cloud-logging-pricing-for-cloud-admins
  2. AWS Solutions. Security Automations for AWS WAF – Cost. https://docs.aws.amazon.com/solutions/latest/security-automations-for-aws-waf/cost.html
  3. Microsoft Learn (Azure Architecture Center). Retry storm anti-pattern. https://learn.microsoft.com/en-us/azure/architecture/antipatterns/retry-storm
  4. AWS Documentation. Amazon CloudWatch pricing and billing considerations. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_billing.html
  5. AWS Compute Blog. AWS Lambda introduces tiered pricing for Amazon CloudWatch logs and additional logging destinations. https://aws.amazon.com/blogs/compute/aws-lambda-introduces-tiered-pricing-for-amazon-cloudwatch-logs-and-additional-logging-destinations/
  6. AWS Cost Explorer API Reference. GetCostAndUsage. https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_GetCostAndUsage.html
  7. AWS Cost Management User Guide. Budget methods. https://docs.aws.amazon.com/cost-management/latest/userguide/budget-methods.html
  8. AWS Cost Management User Guide. Receiving budget alerts in chat applications (Slack/Teams/Chime). https://docs.aws.amazon.com/cost-management/latest/userguide/sns-alert-chime.html