LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

監視SaaS（Datadog等）のコストが高騰する仕組み

監視SaaS（Software as a Service）のコスト最適化を外注するとは、Datadog・New Relic・Grafana Cloudなどのオブザーバビリティ（可観測性）ツールにおける課金構造を分析し、監視品質を維持しながらコストを削減する作業を専門パートナーに委ねる取り組みです。クラウドネイティブ化が進むにつれてこれらのSaaSは広く普及していますが、サービス規模が拡大すると費用が急増し、管理しきれないケースが見られます。

監視SaaSのコスト高騰を理解するうえで、課金構造の全体像を把握することが不可欠です。主要な監視SaaSはおおむね以下の単位で課金が発生します。

ホスト・エージェント課金

Datadogをはじめとする多くの監視SaaSは、監視対象のサーバー・コンテナホスト・クラウドインスタンスの台数に応じた月額課金を基本としています。インフラが拡張されるたびに監視対象ホスト数が増え、それに比例してコストが上がります。

ログの取り込み（Ingestion）とインデックス（Indexing）の二段課金

Datadogのログ管理は特徴的な二段構造になっています。まず全ログを取り込む「Ingestion（インジェスト）」の段階で取り込みデータ量に応じた課金が発生し、さらに検索・分析対象として保持する「Indexing（インデックス）」の段階で別途課金が加わります。

インデックスに入れないログはアーカイブ（安価な長期ストレージ）に流すことができますが、アーカイブからの検索には再水和（Rehydration）と呼ばれる操作が必要です。この二段構造を理解しないままログを全量インデックスすると、コストが急増します。

カスタムメトリクス課金

標準メトリクスは多くの場合ホスト課金に含まれていますが、アプリケーション独自のカスタムメトリクス（Custom Metrics）は別途課金されます。カスタムメトリクスはラベル（タグ）の組み合わせ数（カーディナリティ）が増えると急速に数が膨らむため、タグ設計が課金に直結します。

APM・分散トレーシング課金

APM（Application Performance Monitoring：アプリケーションパフォーマンス監視）や分散トレーシングも多くの場合独立した課金体系を持ちます。トレースの取り込み量・保持量・インデックス量に応じた課金が発生し、マイクロサービスが増えるほど対象が広がります。

保持期間

ログやメトリクスの保持期間が長いほど、ストレージコストも増えます。コンプライアンス要件で長期保存が必要なデータと、運用上は数日から数週間あれば十分なデータを分けて管理することが、保持コスト削減の出発点になります。各SaaSの最新単価・保持オプションは公式の料金ページでご確認ください。

主な削減手段：フィルタリング・サンプリング・保持期間・カーディナリティ・コミット

監視SaaSのコストを削減するアプローチは複数あります。どの手段が効果的かは現在の課金構造と使い方によって変わります。主要な手段を整理します。

ログのフィルタリングと除外設定

定期的なヘルスチェックのリクエストログ、大量発生するデバッグログ、同一エラーの繰り返しログなど、実際の障害検知や分析に使われないログをパイプラインの段階で除外します。取り込み量自体を減らすことで、Ingestion課金を直接削減できます。Datadogではログパイプラインのフィルタリングルールで設定できます。

ログのサンプリング

一定割合のリクエストログだけを取り込む「サンプリング」も有効です。ユーザーの全アクセスを記録する必要のないアクセスログや、エラーでない情報ログは一定の割合でサンプリングすることでデータ量を削減できます。重要なエラーログや認証ログはサンプリング対象から外すことが前提です。

ログのインデックス設計と安価なストレージへのアーカイブ

すべてのログをインデックスに入れる必要はありません。リアルタイム検索が必要な重要ログのみインデックスに入れ、それ以外はアーカイブ（Amazon S3やGoogle Cloud Storageなどの安価な長期ストレージ）に流す設計が、Indexing課金の削減に直結します。

アーカイブに流したログはDatadogの再水和（Rehydration）機能で後から検索可能にできます。ただし再水和には別途費用が発生するため、アーカイブ頻度と再水和の利用頻度を想定したうえで設計することが大切です。

メトリクスのカーディナリティ削減

カーディナリティ（Cardinality）とは、メトリクスに付与するラベル・タグの組み合わせ数のことです。たとえば「ユーザーID」「リクエストUUID」など一意に近い値をタグに含めると、タグの組み合わせが爆発的に増えてカスタムメトリクス数が急増します。

高カーディナリティのタグを整理し、必要な集計粒度に絞ることでカスタムメトリクス課金を大幅に抑えられます。内部でメトリクスを集計してからSaaSに送る「事前集計（Pre-aggregation）」も有効です。

保持期間の最適化

データ種別ごとに適切な保持期間を設定します。たとえばアクセスログは7日、エラーログは30日、セキュリティ関連ログは90日といった形で、コンプライアンス要件と運用上の必要性を照らし合わせて最短の保持期間を設計します。保持期間を半分にするだけでストレージコストも同程度下がります。

未使用ダッシュボード・インテグレーションの整理

使われなくなったダッシュボードやインテグレーション（外部サービス連携）を整理することも重要です。不要なインテグレーションが裏でデータを送り続けているケースや、誰も見ていないダッシュボードのために不要なメトリクスが収集されているケースが見られます。

年間コミット割引の活用

多くの監視SaaSは月次払いに対して年間コミット（Annual Commitment）の割引を提供しています。利用量が安定していると見込める場合、年間コミットへの切り替えで費用を抑えられます。ただし大きくコストを削減してから年間コミット量を決めると、余剰コミットのリスクを避けられます。

OSSスタックへの一部移行

Prometheus（プロメテウス）・Grafana（グラファナ）・Loki（ロキ）などのOSS（オープンソースソフトウェア）スタックへの一部移行も選択肢です。コストの高い特定のデータ層（たとえば大量のアクセスログ）だけをOSSに切り出し、重要な監視はSaaSに残すハイブリッド構成が現実的なアプローチになります。完全移行は構築・維持の工数が増えるため、費用対効果の試算が必要です。

外注で進める4ステップ：課金分析→棚卸し→施策実装→品質確認

監視SaaSのコスト最適化を外注で進める場合、以下の4ステップが基本的な流れになります。スコープと成果基準を事前に合意してから進めることが、効果的な外注のポイントです。

ステップ1：課金構造の分析と高騰要因の特定

まず現状の課金内訳を詳細に把握します。ログ・メトリクス・APM・インフラそれぞれの費用がどのくらいかを分解し、特にコストが大きい項目を特定します。Datadogであればコスト管理ダッシュボードや使用量ページでデータを確認できます。

この段階で「インデックスログが全体コストの何割を占めるか」「カスタムメトリクスが急増した時期はいつか」「どのサービスやインテグレーションが費用を押し上げているか」を把握します。高騰要因が特定できると、次の棚卸しで優先すべき領域が絞れます。

ステップ2：ログ・メトリクスの棚卸しと削減対象の合意

収集しているログとメトリクスを一覧化し、「実際に参照されているか」「アラートやダッシュボードで使われているか」「削減または除外が可能か」を評価します。この棚卸し作業はサービスの業務内容を理解した上で行う必要があり、アプリケーションチームとの連携が欠かせません。

棚卸し結果をもとに、削減施策の優先順位と対象スコープを発注者と合意します。「このログは除外してよい」「このメトリクスはアーカイブに流してよい」という判断は、業務への影響を確認してから決定します。

ステップ3：削減施策の実装と設定変更

合意した方針に基づき、ログパイプラインのフィルタリングルール設定・インデックスフィルター変更・アーカイブへの振り向け・保持期間の変更・カスタムメトリクスのタグ整理などを実施します。各SaaSの管理画面やIaC（Infrastructure as Code：インフラのコード化）ツールで設定変更を行います。

設定変更はステージング環境や非重要サービスから段階的に適用し、コストと監視品質への影響を確認しながら本番環境に展開することがリスク管理の基本です。変更前後のコスト推移をモニタリングし、期待どおりの削減効果が出ているかを確認します。

ステップ4：監視品質の確認とアラートテスト

削減施策の実装後、監視の網羅性が維持されているかを確認します。重要なアラートが正しく発火するか、障害検知に必要なログが引き続き取得できているかをテストします。この確認を省略すると、コストは削減できても障害を見落とすリスクが生じます。

アラートテストとしては、実際にエラーを発生させてアラート発火を確認する方法や、過去の障害シナリオを再現してログが取得されているかを確認する方法が一般的です。テスト結果を記録し、発注者に品質確認レポートとして共有することが望ましいです。

監視品質を落とさないための注意点

コスト削減を優先するあまり監視品質が低下すると、障害検知の遅延や原因調査の困難化につながります。以下の点を意識して進めることが大切です。

削減対象ログの業務影響確認を欠かさない

「このログは使っていない」と思っていても、月に1回の障害調査時だけ参照されているケースや、セキュリティインシデント調査で必要になるケースがあります。削減対象を決める前に、過去の障害対応記録やアラート設定を確認し、使われていないかどうかを実績ベースで判断することが必要です。

特にセキュリティ関連ログ（認証ログ・操作ログ・不正アクセスの痕跡が残るログ）は、コンプライアンスや監査要件から保持義務がある場合があります。削減前にセキュリティ要件を確認することは省略できません。

段階的な削減とロールバック手順の準備

一度に大きく削減するとリスクが集中します。フィルタリング対象を少しずつ増やし、コストと監視品質の両方をモニタリングしながら段階的に進めることでリスクを抑えられます。設定変更のロールバック手順を事前に準備し、問題が発生した際に迅速に元の状態に戻せるようにしておきます。

アラート設定の依存関係を把握する

フィルタリング設定を変更したことでアラートの発火条件が変わることがあります。たとえば「エラーログの件数が一定以上でアラート」という設定があるとき、エラーログをサンプリングするとアラートの感度が下がります。アラート設定がどのログ・メトリクスに依存しているかをマッピングしてから削減施策を設計することが、品質維持の鍵になります。

内製で対応するには専門知識と時間が必要

監視SaaSの課金構造は複雑であり、Datadogだけでも課金モデルは製品ラインごとに異なります。最適化の設計には対象SaaSの仕様理解に加え、自社のシステム構成・障害対応フロー・コンプライアンス要件を横断的に把握した上での判断が求められます。担当エンジニアが他業務と兼任しながらこれを進めると、調査・設計・実装・テストで数週間以上の工数を要することも珍しくありません。

費用構造とレンジ感 — スポット診断・初期プロジェクト・継続運用

監視SaaSのコスト最適化を外注する際の費用は、対象SaaSの種類・利用規模・最適化のスコープによって大きく異なります。以下は市場で語られる参考レンジであり、一次資料に基づく数値ではありません。実際の費用は提供会社・スコープ次第です。

削減効果については「コストが一定割合改善された」という事例が語られることがありますが、効果は利用中のSaaS・現状の設定状況・ログ・メトリクスの使い方によって大きく異なります。断定的な削減率を約束する提案には注意が必要であり、複数社に見積もりを依頼して比較することをおすすめします。

また、コスト削減のプロジェクト費用が削減効果を上回っては本末転倒です。初期診断のみを依頼して自社実装の可否を判断する進め方も選択肢の一つです。

委託先の選び方：SaaS課金知識・実績・アラートテスト体制で判断する

監視SaaSのコスト最適化を外注する委託先を選ぶ際は、技術的な専門性だけでなく、監視品質を維持できる体制かどうかを合わせて確認することが大切です。以下の軸で評価するとよいでしょう。

対象SaaSの課金構造への理解

Datadogであれば取り込み・インデックス・APM・カスタムメトリクスの各課金モデルを、New Relicであればデータプラットフォームの取り込みベース課金を正確に理解しているかを確認します。課金構造を理解していないと、削減施策の設計に誤りが生じやすくなります。提案書や初回ヒアリングで課金の仕組みについて具体的な説明ができるかを判断材料にするとよいです。

同様の最適化プロジェクトの実績

同種の監視SaaSで同程度の規模・業種の最適化を行った実績があるかを確認します。実績がある場合は、どのような施策を行いどのような結果が出たかを具体的に確認します。ただし他社での削減率をそのまま自社に当てはめることはできないため、参考として聞きつつも自社環境での分析を重視してください。

監視品質確認・アラートテストの体制

削減後のアラートテストを実施する体制があるかを確認します。「設定変更はするが品質確認はお客様で」という委託先では、削減後に障害を見落とすリスクを自社が負うことになります。品質確認のプロセスと成果物（アラートテスト結果レポートなど）が提案スコープに含まれているかを確認してください。

IaCや設定のコード管理対応

Terraform（テラフォーム）・Pulumi（プルミ）などのIaCツールを使って監視設定をコード管理している場合、外注先がその管理方法に対応できるかを確認します。手作業での設定変更だけに対応する委託先では、変更履歴の管理やロールバックが難しくなります。

継続的な対応が可能か

監視SaaSのコストは、新機能リリース・インフラ拡張・設定変更の積み重ねで再び増加します。初期最適化後も定期的なレビューと再チューニングを依頼できる体制があるかを確認してください。スポット型で終わりではなく、継続的なパートナーシップを結べる委託先を選ぶことが長期的なコスト管理につながります。

まとめ：監視SaaSコスト削減外注の3つの判断軸

本稿では、Datadogをはじめとする監視SaaSのコスト高騰の仕組みから、主な削減手段、外注で進める4ステップ、委託先の選び方までを整理しました。要点を3つに集約すると次のとおりです。

第一に、監視SaaSのコスト高騰はログのIngestion・Indexing二段課金、カスタムメトリクスのカーディナリティ、APM課金など多層の課金構造に起因します。どの層がコストを押し上げているかを正確に把握することが最適化の出発点です。第二に、削減手段はフィルタリング・サンプリング・保持期間の最適化・カーディナリティ削減・アーカイブ活用など複数あり、現状の課金内訳に合わせて組み合わせることが効果につながります。削減効果は環境次第であり、断定的な数値を事前に約束することはできません。第三に、外注で進める際は「課金分析→棚卸し→施策実装→品質確認」の4ステップを踏むことで、コスト削減と監視品質の維持を両立できます。委託先を選ぶ際はSaaS課金構造への理解、実績、削減後のアラートテスト体制を確認することが重要な判断軸になります。

よくある質問

Datadogのログ課金はどのような仕組みになっていますか？

Datadogのログ課金は、ログの「取り込み（Ingestion）」と「インデックス（Indexing）」の二段構造になっています。まずすべてのログを取り込む際に取り込み量に応じた課金が発生し、さらに検索・分析対象として保持するインデックスログに対して別途課金が加わります。インデックスに入れず長期アーカイブに流すと保持コストを抑えられます。詳細な単価は最新の公式料金ページでご確認ください。

ログのフィルタリングとサンプリングはどう違いますか？

フィルタリングは条件に合わないログを完全に除外する方法で、デバッグログや定期ヘルスチェックのログなど運用上不要なものを送らないようにします。サンプリングは一定割合のログだけを取り込む方法で、大量発生する同種のアクセスログや情報ログに対して適用します。フィルタリングは除外条件が明確な場合に、サンプリングは均一なログが大量発生する場合に向いています。

監視SaaSのコスト最適化を外注するとどのくらいの費用がかかりますか？

費用は監視SaaSの種類・利用規模・最適化のスコープによって大きく変わります。課金分析と棚卸しだけを依頼するスポット型では数十万円台から、設計・実装・品質確認まで含む初期プロジェクト型では数百万円台が市場参考レンジとして語られますが、これらは一次資料に基づく数値ではなく実勢はスコープ・提供会社次第です。複数社に見積もりを依頼し、スコープと成果基準を明確にしてから比較することをおすすめします。

監視コストを削減すると監視の網羅性が下がりますか？

コスト削減と監視品質はトレードオフになるとは限りません。重要ログ・エラーログ・セキュリティ関連ログはインデックス保持しつつ、大量発生する情報ログやデバッグログを安価なアーカイブに流すことで、必要な可視性を維持しながらコストを下げられます。ただし削減前後で重要アラートの発火条件が変わらないかを確認することが欠かせません。削減後のアラートテストも実施することが大切です。

監視SaaSを全面OSSに切り替えることは現実的ですか？

Prometheus・Grafana・Lokiなどのオープンソーススタックへの移行は技術的には可能ですが、構築・維持に専門人材の工数が必要です。SaaSは運用負荷が低い反面コストが高く、OSSは初期費用と人件費がかかる反面、大規模になるほどランニングコストを抑えやすい傾向があります。現実的には全面移行ではなく、コストの高いデータ層だけをOSSに切り出すハイブリッド構成が選ばれることもあります。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. ※　監視SaaSの課金単価・料金体系は各SaaSの公式料金ページで最新情報を確認してください（Datadog：Datadog Pricing）。本文中に記載した費用レンジは市場参考値であり、一次資料に基づく数値ではありません。