「Datadog の年額が 2 年で 1.8 倍になった。来年も 1.5 倍と言われた。SRE 5 名いるのに、ツール代が SRE 人件費を超える」――2026 年、中堅企業（従業員 1,000-3,000 名 / ホスト数 100-300 規模）の SRE 責任者から増えている相談である。 SaaS オブザーバビリティの年額が 1,500-3,000 万円帯に入ると、内製基盤（OpenTelemetry + Grafana スタック）が TCO で 50-70% 削減 できる現実解として浮上する。本記事は中堅 SRE チーム規模で内製化を成立させる構成・TCO・移行ロードマップ・撤退基準を実装視点で整理する。執筆時点（2026 年 4 月）の OpenTelemetry / Grafana 各社公式情報に基づく目安であり、採用時は最新公式ドキュメントの確認が必須である。

目次

  1. SaaS から内製化に踏み切る判断ライン（年額・チーム規模・主権要件）
  2. OpenTelemetry を中核に置く理由
  3. Grafana Tempo / Loki / Mimir / Pyroscope の役割分担
  4. 中堅企業の典型構成（ホスト 100-300 台）
  5. SaaS vs 内製の TCO 比較（5 年累計）
  6. 移行 12 ヶ月ロードマップ
  7. 必要な SRE 人員とスキルセット
  8. 内製化の撤退基準（やめどき）
  9. よくある質問（FAQ）
  10. 関連記事

SaaS から内製化に踏み切る判断ライン（年額・チーム規模・主権要件）

中堅企業で内製化が成立する条件は経験則として 3 つの軸で判断される。

判断軸内製化が成立する閾値補足
現行 SaaS 年額1,500 万円以上これ以下では内製人件費の方が高い
SRE / プラットフォームチーム人員専任 3 名以上Kubernetes + Postgres + ClickHouse / S3 運用ができる構成
データ主権 / 国内保管要件法務 / 業界規制で必須金融 / 医療 / 公共系は SaaS 越境保管が NG な場合
3 軸のうち最低 2 軸を満たさないと内製化はほぼ失敗する。年額 500 万円台の中堅企業が「コスト削減」だけで内製化に踏み切ると、SRE 人件費（1 人 1,200-1,800 万円 / 年）を含めた TCO で SaaS 維持より高くなる事例が多い。

内製化が向くケース

  • ホスト 200-500 台規模で SaaS 年額が 2,000 万円超
  • データ主権法務要件で SaaS 越境保管禁止
  • SRE / プラットフォームチームが 5 名以上
  • 既に Kubernetes 全社標準で運用ノウハウあり
  • 観測データを社内 ML / 分析基盤に二次利用したい

内製化が向かないケース

  • ホスト 50 台未満 / SaaS 年額 500 万円未満
  • SRE 専任なし、開発チーム兼務
  • Kubernetes 未導入 / オンプレ ESXi 中心
  • ログ保管要件が標準（30-90 日）
  • 「コスト削減」が唯一の動機

OpenTelemetry を中核に置く理由

OpenTelemetry（OTel）は CNCF（Cloud Native Computing Foundation）のインキュベーションプロジェクトで、トレース / メトリクス / ログを統合した ベンダー中立な観測データ標準 である。2026 年時点で Trace / Metrics は GA（一般提供）、Logs は安定化フェーズ。

OTel を採用する 3 つの戦略的理由

  1. ベンダーロックイン回避：エクスポーター差替えで Datadog / New Relic / Grafana / 自前 ClickHouse へ送り先変更可能
  2. 計装の共通化：アプリ側のコード変更ゼロで観測先を変更できる
  3. 業界標準化の波に乗る：W3C Trace Context / Semantic Conventions が業界標準化、各種 SaaS / OSS の対応が進む

OTel Collector が中核アーキテクチャ

OTel Collector は受信（Receiver）→ 加工（Processor）→ 送信（Exporter）の 3 層パイプラインを持ち、複数バックエンドへの fan-out / フィルタリング / サンプリング / 属性追加を実装できる。

OTel Collector の Tail-based Sampling はオブザーバビリティのコスト削減で最重要機能の一つ。エラー / 遅延セッションのみ全送信し、正常セッションは 1-10% のサンプリングで送ることで保管量を 70-90% 削減できる。

Grafana Tempo / Loki / Mimir / Pyroscope の役割分担

Grafana Labs が提供する OSS スタックは、トレース / ログ / メトリクス / プロファイリングをそれぞれ別 OSS で提供し、Grafana UI で統合表示する。

OSS役割ストレージ特徴
Tempo分散トレースS3 / GCS / Azure Blobインデックスレス設計で安価
LokiログS3 / GCS / Azure Blobラベルのみインデックス、ログ本文はオブジェクトストレージ直置
MimirメトリクスS3 / GCS / Azure BlobPrometheus 互換、長期保管・水平スケール特化
Pyroscope継続的プロファイリングS3 / GCS / Azure BlobCPU / Memory / Goroutine プロファイル
Grafana可視化 UI–全データソース統合
Alloy（旧 Grafana Agent）観測データ収集–OTel Collector 互換

「インデックスレス」設計が安いワケ

従来の Elasticsearch / OpenSearch ベースのログ基盤は 全文インデックス で高速検索を実現するが、ストレージが原本の 3-10 倍に膨張する。Grafana Loki / Tempo は ラベル / トレース ID のみインデックス、本文は S3 直置 で ストレージ単価を 5-20 分の 1 に下げる設計。検索速度はインデックス型より遅いが、観測データの 99% は「特定セッションを掘る」用途であり、ラベル / トレース ID 経由のアクセスで実用十分。

Grafana Mimir の Prometheus 互換性

Mimir は Prometheus PromQL / Remote Write API 完全互換で、既存 Prometheus 環境を 設定変更だけで Mimir に統合 可能。Prometheus 単独での弱点（長期保管・水平スケール・マルチテナント）を解消する。

中堅企業の典型構成（ホスト 100-300 台）

中堅企業（ホスト 100-300 台 / 1 日ログ取込 100-500GB）の典型構成を提示する。

コンポーネント構成

層コンポーネント規模目安
計装OpenTelemetry SDK（各言語）全アプリ計装
収集 AgentGrafana Alloy / OTel Collector各ノード 1 台
集約 GatewayOTel Collector Gateway（Kubernetes Deployment）3-5 レプリカ
トレース保管Grafana TempoS3 互換ストレージ
ログ保管Grafana LokiS3 互換ストレージ
メトリクス保管Grafana MimirS3 互換ストレージ
可視化Grafana3 レプリカ HA
アラートGrafana Alerting + Alertmanager3 レプリカ

インフラ要件（参考値）

  • Kubernetes クラスタ：観測基盤専用 6-12 ノード（CPU 32 vCore / Memory 128GB / SSD 500GB）
  • オブジェクトストレージ：S3 互換 5-20TB（ログ 90 日保管想定）
  • データベース：Postgres（Grafana メタデータ用）+ Memcached / Redis（キャッシュ）
  • ロードバランサ：内部 L7 LB（Ingress NGINX 等）

月次運用負荷の現実値

  • 定常運用：SRE 1 名で月 20-40 時間
  • アップグレード（年 4 回）：1 回あたり 8-16 時間
  • インシデント対応：年 5-10 件、1 件 4-16 時間
  • キャパシティプランニング：四半期 1 回、4-8 時間

合計で SRE 0.3-0.5 名相当の常時稼働 が必要。

SaaS vs 内製の TCO 比較（5 年累計）

ホスト 200 台規模の中堅企業を仮定した 5 年累計 TCO 比較。数字は目安。

項目SaaS（Datadog 想定）内製（OTel + Grafana スタック）
ライセンス / クラウド費用（年）2,000-3,000 万円200-400 万円（S3 + Kubernetes インフラ）
5 年累計ライセンス1.0-1.5 億円1,000-2,000 万円
初期構築（一時）100-300 万円1,500-3,000 万円
運用人件費（SRE 0.5 名 × 5 年）0（SaaS が運用）3,000-4,500 万円
アップグレード / マイグレーション500-1,000 万円
5 年累計 TCO1.0-1.5 億円6,000-9,500 万円
5 年累計で 30-50% 削減 が現実的なライン。ただし以下の前提が崩れると削減効果が消える。

削減効果が消える前提崩れ

  • SRE 人員が 0.5 名以下しか割けない → 障害対応が遅延し業務影響増
  • Kubernetes 運用未経験 → 学習コスト + 事故対応で工数倍増
  • 要件が SaaS 機能（CI Visibility / RUM Session Replay 等）に依存 → 内製で同等機能を作る工数が膨大
  • データ量がさらに 5 倍（ホスト 1,000 台規模） → 内製インフラのスケール工数が跳ねる

移行 12 ヶ月ロードマップ

中堅企業で SaaS から内製基盤への並行運用 → 切替の標準ロードマップ。

月 1-2：基盤設計と PoC

  • OTel Collector + Grafana Tempo / Loki / Mimir の単体 PoC
  • ストレージ S3 / オブジェクトストア決定
  • 観測データの分類設計（保管期間 / アクセス頻度別）
  • SRE チーム 2-3 名で OSS スタック学習

月 3-4：本番並行投入（10% トラフィック）

  • 1 サービスを選定し OTel Collector を導入
  • Datadog と Grafana 両方に並行送信（fan-out）
  • ダッシュボード / アラートを Grafana 側で再構築
  • 機能差分の Gap 分析

月 5-7：本番並行（50% トラフィック）

  • 主要 10-20 サービスを OTel 化
  • ログ階層設計（Hot / Warm / Cold）実装
  • Tail-based Sampling 適用
  • インシデント対応訓練（Grafana 単独で対応できるか検証）

月 8-10：本番並行（100% トラフィック）

  • 全サービス OTel 化完了
  • Grafana 側で全アラート稼働
  • SRE on-call ローテーションを Grafana ベースに切替
  • Datadog はバックアップとして並行維持

月 11-12：SaaS 撤退

  • Datadog 契約縮小 / 解約
  • 撤退判断基準クリア確認（後述）
  • ポストモーテム / ナレッジ共有

移行プロジェクトの典型工数

  • SRE 3 名フルタイム × 12 ヶ月 + アプリ開発チーム協力 1-2 名 × 6 ヶ月
  • 初期構築コスト 1,500-3,000 万円（インフラ + 人件費 + 学習）

必要な SRE 人員とスキルセット

内製基盤を支える SRE / プラットフォームエンジニアに必要な技術スタック。

コア スキル（必須）

  • Kubernetes 運用（StatefulSet / PVC / オブジェクトストレージ連携）
  • Prometheus / PromQL / Grafana 設計
  • OpenTelemetry SDK / Collector 設定
  • ログ / メトリクス / トレースの設計原則（USE / RED / Four Golden Signals）
  • インシデント対応 / ポストモーテム文化

推奨スキル

  • Helm / ArgoCD / GitOps
  • S3 / オブジェクトストレージ ライフサイクル設計
  • Terraform / IaC
  • Go / Python（OTel Collector 拡張プラグイン）
  • カオスエンジニアリング（Chaos Mesh / Litmus）

チーム構成の現実解

  • テックリード SRE 1 名：アーキテクト責務、観測基盤全体設計
  • SRE 2-3 名：日次運用、インシデント対応、改善開発
  • プラットフォーム連携 1 名：開発チームへの計装支援、コンサルテーション

合計 専任 4-5 名 + アプリチーム協力 が中堅企業の現実規模。

内製化の撤退基準（やめどき）

内製化は やめどきを最初に決めておく ことが重要。撤退判断基準を明文化しないと「サンクコスト」で抜けられなくなる。

撤退基準 6 項目

  1. SRE 専任が 2 名以下に減少した
  2. インシデント MTTR が SaaS 時代より 50% 以上悪化した
  3. 観測基盤自体の障害が四半期 3 件以上発生
  4. アップグレードに 1 ヶ月以上かかる事態が 2 回連続
  5. 5 年 TCO 試算で SaaS との差が 20% 未満に縮小
  6. データ主権要件が緩和され、SaaS の国内 DC で要件を満たせる

撤退時のデータ移行

撤退時は 「内製基盤のデータを SaaS に持ち込めない」 制約に注意。観測データはほぼリアルタイム性が価値であり、過去 30-90 日のデータ移行は通常不要だが、コンプライアンス保管要件があるログは S3 アーカイブで別途保管する設計にしておく。

よくある質問（FAQ）

Q1. Grafana Cloud（マネージド）と完全自社運用、どちらが安いか

A. ホスト 100-200 台規模では Grafana Cloud の方が安い ケースも多い。Grafana Labs が運用責任を持つため SRE 人件費を省略できる。完全自社運用の優位は データ主権要件 + ホスト 300 台超 + SRE 5 名以上の組合せ。

Q2. Prometheus 単独 vs Mimir、どちらを選ぶか

A. Prometheus 単独は 単一インスタンスで保管 1-2 週間 が上限。長期保管・水平スケール・マルチテナント要件があれば Mimir 必須。中堅企業では Prometheus → Mimir 移行が標準パス。

Q3. ログを Loki ではなく Elasticsearch / OpenSearch にすべきか

A. 全文検索が業務必須（セキュリティ捜査・監査対応）なら Elasticsearch / OpenSearch、ラベル + トレース ID 経由のアクセスで十分なら Loki。後者の方がストレージコスト 1/5-1/20 で済む。中堅企業では用途別に併用が現実解。

Q4. OpenTelemetry の Logs Signal は本番運用できる段階か

A. 2026 年時点で安定化フェーズだが、Trace / Metrics に比べて成熟度が低い。当面は OTel Trace + Loki Promtail（または Fluent Bit）の組合せが現実解。OTel Logs は早期採用は推奨せず、2026 年中の GA 移行を待つことを推奨。

Q5. CNCF プロジェクト終了リスクはあるか

A. OpenTelemetry / Prometheus はインキュベーション → Graduated に到達済みで終了リスクは極小。Grafana 各 OSS は Grafana Labs 主導で AGPL ライセンス、商用サポートも継続見込み。ただし AGPL ライセンスを商用配布する場合は法務確認必須。

Q6. 観測基盤自体の監視はどうするか

A. 観測基盤の監視を観測基盤自身でやらない。最低限の Watchdog（外形監視 + Heartbeat）を別 SaaS（UptimeRobot / Pingdom 等）で冗長化する。観測基盤がダウンした時に検知できないと致命的。

Q7. Datadog から Grafana への移行で UI 慣れの抵抗が強い

A. SRE / 開発者の Grafana 学習に 3-6 ヶ月の慣熟期間 を見込む。Datadog の UI 完成度は業界トップクラスで、Grafana で同等 UX を実現するにはダッシュボード設計の作り込みが必要。チェンジマネジメントとして「並行 6 ヶ月 + 段階的切替」が現実的。

Q8. CI / CD パイプラインに観測基盤を組み込むべきか

A. 推奨。ダッシュボード / アラート設定を Git 管理（grafana-as-code）+ CI で diff レビュー することで、本番設定の属人化と消失を防げる。Grafana Provisioning + Terraform / Helm 統合が標準アプローチ。

関連記事

参考資料

  • OpenTelemetry 公式（https://opentelemetry.io/）
  • CNCF OpenTelemetry プロジェクトページ（https://www.cncf.io/projects/opentelemetry/）
  • Grafana Labs 公式（https://grafana.com/）
  • Grafana Tempo / Loki / Mimir 公式ドキュメント
  • Prometheus 公式（https://prometheus.io/）
  • Google SRE Book "Site Reliability Engineering"（https://sre.google/sre-book/table-of-contents/）

OpenTelemetry 内製基盤 構築のご相談

GXO は中堅企業（従業員 1,000-3,000 名 / ホスト数 100-500 規模）向けに、OpenTelemetry + Grafana スタックの内製化を支援します。SaaS / 内製 TCO 比較、12 ヶ月移行ロードマップ策定、SRE チーム編成支援、ログ / メトリクス / トレース統合設計、Tail-based Sampling 実装、撤退基準設計まで一貫対応可能です。年額 2,000 万円超のオブザーバビリティ予算の見直しからご相談を承ります。

OpenTelemetry 内製基盤のご相談はこちら