本稿はJCB Advent Calendar 2025の12月24日の記事です。
こんにちは。JCBデジタルソリューション開発部の西村です。JDEPで加盟店部門のシステム開発を担当しています。皆さんのチームでは、SaaS のコスト管理はどうされていますか？
この記事では、Datadog APM のコストをおおよそ 60% 削減しつつ、可観測性（Observability）の質を落とさずに改善できた取り組みを紹介します。「コスト削減のためにログを捨てる」のではなく、「本当に必要なデータだけを残す」ために何をしたか。その過程で 生成 AI をどう使ったかもあわせて書いていきます。
課題
JDEP では Google Cloud 上でマイクロサービスアーキテクチャを採用し、アジリティの高い開発を進めています。ただ、サービスが増えるほど、可観測性を維持するためのデータ量は指数関数的に膨らみます。
特に Datadog APM においてコストの大部分を占めているのが「Indexed Spans（インデックス化されたスパン）」です。これは Datadog のバックエンドに保存され、検索や分析に利用できるトレースデータを指します。担当プロジェクトでは、このデータ量が肥大化し、コスト最適化が喫緊の課題になっていました。
単純にサンプリングレートを下げればコストは削減できますが、「障害調査に必要なデータまで失う」リスクがあります。「コストは下げたいが、信頼性は犠牲にしない」 という、よくあるけれど簡単ではないテーマに正面から向き合うことになりました。
前日譚：「Intelligent Retention Filter」への移行検討
最初の選択肢として、Datadog が標準提供している 「Intelligent Retention Filter」 への全面移行を検討しました。AI が自動的にエラーや高レイテンシのトレースを選別して保持してくれる機能で、その対象は Indexed Spans の課金対象外（無料）になる、という非常に魅力的な仕組みです。
「これで一気に解決するのでは？」と期待したのですが、検証を進めた結果、担当プロジェクトでは 採用を見送る という判断になりました。
原因
担当システムでは外部システムとの連携が多く、その一部では ビジネスロジック上はエラーでも HTTP ステータスコードが 200 OK で返ってくるケースがあります。
一方、Intelligent Retention Filter は主に 5xx などのエラーステータスや、極端な遅延（レイテンシ）をトリガーにデータを保持します。そのため、200 OK として返ってくるビジネスエラーは「正常」と判断されてサンプリングで捨てられてしまう可能性が高いことが分かりました。
障害調査で必要になるログが消えてしまうリスクは、どうしても受け入れられませんでした。結果として、「Custom Retention Filter（有料）を使い続ける」ことを前提に、その設定を最適化する方針に切り替えました。
失敗事例
最初からうまくいったわけではなく、直感的に思いついた 2 つのアプローチは期待した結果を出せませんでした。
失敗1：テスト用モックサービスの除外
「テスト用の mock サービスは本番監視には不要だから、Retention Filter から除外すればいいのでは？」と考え、service: *mock をフィルタで除外しました。
結果：コスト削減効果なし。
調べてみると、そもそも *mock のトレースは Ingestion（取り込み）段階ですでにフィルタリングされており、課金対象の Indexed Spans には含まれていませんでした。「あるはずだ」という思い込みで、きちんと確認していなかったことが原因です。
失敗2：一律のサンプリングレート低減
もうひとつ試したのが、「現在 40% 保存している設定を、一律で 10% に下げる」という案です。
結果：採用見送り（危険と判断）。
一律にレートを下げると、発生頻度は低いもののビジネス上重要な処理（例：1 日に数回だけ発生する処理、トランザクション量が少ない時間帯の処理など）のトレースも消えてしまうリスクがあることが分かりました。
この 2 つの失敗から、「サービス単位の大ざっぱな制御ではなく、リソース（API エンドポイントや SQL クエリ）単位での制御が必要」 という結論に至りました。
解決策
とはいえ、数千種類あるリソースを人間が一つずつ見て分類するのは現実的ではありません。そこで、パートナーとして 生成 AI (Gemini) を使ってみることにしました。
AIによる分類
過去 2 週間分のリソース一覧を CSV で抽出し、Gemini に次のようなプロンプトで分類を依頼しました。
「あなたは熟練したSREです。以下のリソースリストを、障害調査の重要度とコスト削減の観点から分類してください。ただし、エラー分析に繋がるSpanは絶対に捨てないでください。」
Gemini との対話を通じて、各リソースの性質に応じた分類を行い、フィルタリングの方針を固めました。
- Critical（重要）:
POST APIやCommitなど、ビジネス価値が高い処理 - Noise（ノイズ）:
GetTopic（監視用）,healthz（ヘルスチェック）,RowIterator（内部処理）など、大量に発生するが調査価値が低い処理
特に効果が大きかったのは、Pub/Sub の GetTopic（トピック存在確認）などのノイズ除去です。
正常であれば延々と発生し続けるため、Retention Filter の対象から外すだけで大きな効果が見込めました。
実装と成果
最終的には、従来の「サービス名だけを条件にしていたクエリ」を見直し、
重要なリソース（POST, PUT, DELETE, SQL 実行など）だけを明示的に許可（Allowlist）し、それ以外を除外する
という形にクエリを組み替えました。
変更後クエリのイメージ（抜粋）:
service:(...) AND (
"POST *"
OR "PUT *"
OR "DELETE *"
OR "ExecuteSql..."
OR ("GET *" AND NOT "GET _healthz_")
)
この変更により、GetTopic や healthz といったノイズが保存対象から外れ、次のような結果が得られました。
定量的成果：コスト60%減
- 対策前： 約40,000 Spans（2週間あたり）
- 対策後： 約15,000〜20,000 Spans
- 削減率： 50%〜62.5%
定性的成果：開発者体験（DX）の向上
単にデータが減っただけではありません。
ノイズが消えた
検索結果を埋めていたヘルスチェックや内部処理が姿を消し、意味のあるトレースを見つけやすくなりました。シグナルの純度が上がった
Span の保持率（Span Rate）自体は 40% のまま変えていませんが、保存容量を圧迫していた「不要なデータ」を徹底的に減らしました。その結果、同じコスト（もしくはそれ以下）で、ビジネスロジックのログ密度を高めて運用 できるようになりました。
まとめ
今回の取り組みを通じて、コスト削減は単なる「節約」ではなく、システム構造の理解と「価値のあるデータとは何か」の定義を伴うエンジニアリングだと改めて感じました。
JCB デジタルソリューション開発部では、今後も AI を含むさまざまな技術を取り入れながら、信頼性と効率性を両立するモダンなシステム運用を目指していきます。
もしサービス運用監視ツールのコストでお困りなら、「リソース単位での仕分け」を一度試してみてください。思わぬところに「コスト泥棒」が潜んでいるかもしれません。
最後に、JCBでは我々と一緒に働きたいという人材を募集しています。
詳しい募集要項等については採用ページをご覧下さい。
本文および図表中では、「™」、「®」を明記しておりません。 記載されているロゴ、製品名は各社及び商標権者の登録商標あるいは商標です。
