「監視ツールを変えたいが、過去のダッシュボードとアラートを捨てられない」――この声は、受託で SRE 支援に入っていると毎回聞きます。
2026 年 4 月、InfoQ が Airbnb のメトリクスパイプライン OpenTelemetry 移行を報じました。1 日あたり数十兆点規模の高スループット基盤を、既存ベンダー製品から OpenTelemetry （以下 OTel）ネイティブに置き換えた事例で、段階移行の設計思想に学ぶべき点が多くあります。
本記事では、Airbnb 事例の勘所を整理しつつ、企業が OTel へ移行する際の設計パターンと、受託開発として提案する場合のプロジェクト化の切り口をまとめます。
なぜ今、OpenTelemetry への移行なのか
背景 1：監視ベンダーのコスト高騰
Datadog / New Relic / Splunk といった商用 APM はデータ量課金が基本です。AI エージェントや生成系ワークロードの普及でログ・メトリクス・トレース量が急増し、年間コストが数倍になる事例が増えています。
背景 2：ロックイン回避の潮流
CNCF 配下で急成長した OpenTelemetry が 2024 〜 2025 年に成熟し、トレース / メトリクス / ログの三本柱が揃いました。エクスポータを差し替えれば同じ計装コードで任意のバックエンドに送れるため、ベンダーロックインが構造的に解ける点が評価されています。
背景 3：AI エージェントの可観測性需要
LangFuse と AI 開発の可観測性 でも触れたように、LLM ワークフローの観測には従来の APM では不足する観点（プロンプト・トークン数・ツール呼び出し）が生まれています。OTel の GenAI Semantic Convention がデファクト化しつつあり、移行を後押ししています。
Airbnb 事例から読み取れる 3 つの設計判断
設計判断 1：「段階移行」を大前提にする
Airbnb は一度に切り替えず、既存基盤と OTel を並行稼働させ、メトリクスごとに徐々に切り替える方針をとりました。これにより、ダッシュボードやアラートを失わずに移行期間を長く取れました。
設計判断 2：「コレクターを中心に据える」
OpenTelemetry Collector をクラスター内のゲートウェイとして配置し、ルーティング・サンプリング・変換をすべて Collector 層で吸収する構成。アプリ側の計装は標準 SDK に統一し、バックエンド変更時に再計装しない設計になっています。
設計判断 3：「高カーディナリティ問題を最初に解く」
メトリクスのラベル爆発はコストの元凶です。Airbnb はラベルの棚卸しと正規化ルールを先に決めてから流量を増やしました。この順序を逆にすると、コストと検索性の両方で破綻します。
企業が OTel に移行する際の典型パターン
パターン A：APM 置き換え型
商用 APM （Datadog / NR 等）の全面代替を目指す構成。OTel Collector → Grafana Cloud / Honeycomb / Jaeger / Prometheus 等の OSS 寄せ構成。コスト削減効果は大きいが、ダッシュボードの移植負荷も大きい。
パターン B：ハイブリッド型
商用 APM を UI として残しつつ、データ送信側を OTel に統一する構成。APM ベンダーも OTel エンドポイントを受け付けるため、計装側を先に標準化し、UI 側の乗り換えは後回しにできます。現実的な中間解。
パターン C：LLM 可観測性特化型
LLM ワークフローだけ OTel に寄せる構成。既存システムは従来 APM のままで、新規の生成 AI システムだけ OTel GenAI Semantic Convention で計装する。導入障壁が最も低い。
| パターン | 移行期間目安 | 初期コスト | リスク |
|---|---|---|---|
| A（全面置換） | 6〜12 ヶ月 | 大 | 高（ダッシュボード移植） |
| B（ハイブリッド） | 3〜6 ヶ月 | 中 | 中 |
| C（LLM 特化） | 1〜3 ヶ月 | 小 | 低 |
受託プロジェクトとしての 5 ステップ
ステップ 1：可観測性現状評価（2〜3 週間）
- 既存監視ツールのライセンス構造と年間コストの棚卸し
- メトリクス / ログ / トレースの流量と保持期間の計測
- ダッシュボード・アラート資産の棚卸し（移植の優先順位付け）
- 最も痛みを感じているペインポイントの特定
ステップ 2：ターゲット構成の設計（2 週間）
- パターン A / B / C の選択
- Collector のトポロジー設計（エージェント型 / サイドカー型 / ゲートウェイ型）
- バックエンドの選定（OSS / SaaS / ハイブリッド）
- カーディナリティ設計ガイドラインの策定
ステップ 3：PoC と計装ガイドライン整備（4〜6 週間）
- 1 サービスだけ計装してエンドツーエンドで流す
- 言語別の SDK 統一とラッパー実装
- チーム向け計装ガイドラインのドキュメント化
ステップ 4：段階移行の実装（2〜4 ヶ月）
- ドメイン別に順次計装を拡張
- ダッシュボード・アラートの並行運用
- Collector での段階的なルーティング切り替え
ステップ 5：運用移管とチーム育成（継続）
- SRE チーム向けトレーニング
- ランブックの整備
- 月次のメトリクスコストレビュー会の定着
受託側が “避けるべき落とし穴”
落とし穴 1：既存ダッシュボードの完全再現を約束する
クエリ言語もデータモデルも違うため、完全再現は保証できないのが実情です。初期契約で「重要指標 Top 30 の移植」のようにスコープを絞っておくと、スムーズに進みます。
落とし穴 2：Collector を単一障害点にする
Collector がダウンするとすべての監視データが止まる構成は危険です。冗長化とバッファリングは最低限の要件として設計に含めます。
落とし穴 3：LLM 計装を後回しにする
新規に生成 AI 機能を導入している顧客では、LLM 可観測性が最も切実です。ここを先にクイックウィンとして出すと、プロジェクト全体の信頼を獲得できます。RAG 最適化パターン の観測点とも相性が良い領域です。
落とし穴 4：費用削減だけをゴールにする
OTel 移行は「コスト削減」だけでなく「開発速度向上」「ベンダーロックイン解消」という価値を併せて打ち出すことが、経営層の承認を取りやすくなります。
顧客説明テンプレート（経営層向け）
| 技術用語 | 経営層向け表現 |
|---|---|
| OpenTelemetry | 「監視データの業界標準仕様」 |
| Collector | 「監視データの交換機（ルーター）」 |
| カーディナリティ | 「監視データの粒度と費用のバランス」 |
| ベンダーロックイン | 「監視ツールから離れられないリスク」 |
説明資料には「計装コードを一度書けば、監視ツールを後から入れ替えられる」という一文を入れると、投資判断が加速します。
タイムラインの目安
2026-04 → 現状評価と設計（1 ヶ月）
2026-05 → PoC と計装ガイドライン策定
2026-06 → 1 ドメインへの本番反映
2026-07 〜 2026-09 → ドメイン順次展開
2026-10 → 旧ツール解約 or 縮小パターン B のハイブリッド型なら3〜6 ヶ月で目に見える成果を出しやすく、経営報告のネタに困りません。
まとめ ― 監視基盤は “捨てる前提” で設計する時代
Airbnb の OpenTelemetry 移行事例が示すのは、監視基盤もインフラと同じく抽象化すべきという方針転換です。受託の現場で押さえるべきは次の 3 点：
- パターン A / B / C の選択を初期合意の中心にする
- カーディナリティ設計を先に決めてからデータを流す
- LLM 可観測性をクイックウィンとして早期に示す
弊社 GleamHub では、OpenTelemetry 導入の現状評価・ターゲット構成設計・計装ガイドライン整備・段階移行の実装支援まで、可観測性基盤の乗り換えを一貫で支援しています。商用 APM のコスト高騰が経営課題になっている企業様、生成 AI ワークフローの可観測性を新規に組みたい開発チーム様は、1 ヶ月の現状評価フェーズからお気軽にご相談ください。既存ダッシュボード資産を残しつつ、将来のロックインを解く最短経路を一緒に設計します。
