OpenTracingとOpenTelemetryの違い｜shim移行の手順と載せ替え判断

OpenTracingのプロジェクトは2022年1月31日にCNCFがアーカイブし、後継のOpenTelemetryは2026年5月21日にGraduatedへ到達しました。さらに2026年3月19日、OpenTelemetry仕様からOpenTracing互換の要件が非推奨になり、撤去は2027年3月以降と告知されています。「まだshimが動くから」という理由で先送りできる期間には、はっきりと終わりが見えました。この記事では両者の守備範囲とAPIの対応関係、tagとlogがattributeとeventへどう写るか、shimを挟んだ三段階の移行手順、トレースが分断される条件、着手時期の決め方を、公式仕様とブログの記述に沿って整理します。

まとめ｜OpenTracingからの載せ替えで先に決める三点

結論を三点で示します。第一に、shimは移行の橋であって終着点ではありません。2026年3月19日の仕様PR #4938で互換要件が非推奨になり、撤去時期は「2027年3月より前ではない」と示されました。第二に、載せ替えるとテレメトリの中身が変わります。公式移行ガイドは「better も different を意味する」と明言しており、semconv v1.23.0では http.method が http.request.method へ改称されました。ダッシュボードとアラートは作り直しになります。第三に、移行の単位はサービスではなくコードパスです。同一トレース内で両方のAPIを混在させると、親子関係が誤ったスパンが生まれます。

2026年8月時点で採るべき進め方はこうです。新規の計装はすべてOpenTelemetry APIで書く。既存のOpenTracing計装は、まずTracer実装をOpenTelemetry SDKへ差し替えてshimを載せ、エクスポート先と形式を従来と同一に保ったまま出口だけ揃える。そのうえでコードパス単位で計装を置換し、置換のたびにダッシュボードを更新していく。shimを据え置いてよいのは、機能追加が凍結済みで、かつ2027年内に廃止が確定しているサービスだけです。

OpenTracing終了までの経緯とOpenTelemetry統合で変わった前提

両者は競合規格ではありません。片方がもう片方の前身にあたります。この関係を押さえると、移行が「乗り換え」ではなく「メジャーバージョンアップ」に近い作業だと分かります。

2022年1月のアーカイブから2026年5月のGraduated到達まで

時系列はこうです。2019年5月、OpenCensusとOpenTracingの統合がOpenTelemetryとして発表されました。Microsoftのオープンソースブログはこのとき、OpenTelemetryを両プロジェクトの「次のメジャーバージョン」と位置づけています。CNCFは2022年1月31日にOpenTracingを、2023年7月にOpenCensusをアーカイブしました。リポジトリはGitHub上に残りコードの取得自体は今も可能ですが、機能追加もバグ修正も止まっています。そして2026年5月21日、CNCFはOpenTelemetryのGraduated到達を発表しました。

CNCFが2026年7月24日に公開したブログによれば、コントリビューションは12,000件超、参加企業は2,800社超、開発速度はCNCFプロジェクト中Kubernetesに次ぐ第2位です。移行先が動き続ける材料としては十分でしょう。

トレース専用だったOpenTracingと三シグナルを束ねるOTelの差

守備範囲がまるで違います。OpenTracingが定義したのはトレース用のAPI仕様だけでした。Tracer、Span、SpanContext、ScopeManager、そしてBaggage。SDK実装も送信プロトコルも仕様には含まれず、JaegerやZipkinなど各ベンダーの実装を別途選ぶ必要がありました。対してOpenTelemetryは、API・SDK・送信プロトコルのOTLP・中継役のCollector・属性の命名規則であるセマンティック規約までを一体で定義します。

この差が移行作業の性格を決めます。載せ替えは単にライブラリを入れ替える話ではなく、各ベンダー実装が埋めていた領域を標準側が引き取る再編です。3つのシグナルの位置づけやOTLPとCollectorの役割はOpenTelemetry（OTel）とは｜3つのシグナル・OTLP・Collector・Prometheusとの違いを解説で扱っているため、本記事では移行判断と手順に絞ります。

2026年3月19日の互換要件非推奨と2027年3月以降の撤去予定

移行の締切感を決めたのが2026年3月19日の仕様変更です。Specificationのプルリクエスト #4938 がマージされ、OpenTracing互換の要件が非推奨になりました。公式ブログが示した撤去時期は「Earliest specification removal: no earlier than March 2027」、つまり最短でも2027年3月以降です。

誤読しやすい点を2つ補足します。非推奨になったのは仕様上の要件であって、既存のshim成果物が即座に消えるわけではありません。公式ブログも、非推奨期間中は後方互換のためにサポートを継続できると述べています。もう1つ、これは「shimを今すぐ剥がせ」という要求でもない。公式が求めているのは、ネイティブなOpenTelemetry APIとSDKへの移行計画を立てることです。

セマンティック規約とAPI対応の差がダッシュボード再構築を招く理由

shimを入れれば動きます。ただし出てくるデータは同じではありません。ここを見落とすと、移行当日にダッシュボードが空になります。

tagとlogがattributeとeventへ写る対応関係と例外の扱い

shim仕様には、OpenTracingの各操作がOpenTelemetryのどの概念へ写るかが明記されています。

特に注意したいのが最下段です。Start Spanは最初のChild Of参照を親として扱い、参照が1つもなければ最初の参照を親にします。そのうえで参照はすべて opentracing.ref_type 属性の付いたLinkへ変換される。Follows Fromで関連スパンを結んでいた計装は、親子ツリーではなくLinkとして表現が変わります。もう1点、初期tagはサンプリング判定より前に適用される仕様です。tagの値でサンプリング率を変えているなら、この順序に依存した挙動が保たれるかを移行前に確認してください。

semconv v1.23.0でhttp.methodが改称された影響範囲

公式移行ガイドの「better も different を意味する」という一文は、抽象的な注意書きではなく具体的な破壊的変更を指しています。OpenTelemetryは2023年11月、semantic-conventions v1.23.0でHTTPの規約を初めて安定版とし、このとき http.method は http.request.method へ改称されました。移行を緩やかにする環境変数 OTEL_SEMCONV_STABILITY_OPT_IN も用意されましたが、多くの言語SDKは安定版へ移行済みでサポートを外しています。

影響を受けるのはコードではなく、その先です。属性名でフィルタしているダッシュボードのクエリ、しきい値アラートの条件式、属性でグルーピングしているメトリクスの系列。属性名が変われば、これらは静かに一致しなくなる。エラーにはならず、単に結果が0件になります。だからこそ計装を1つ置換するたびにダッシュボードを更新する運用にしてください。属性の取り方が系列数に跳ね返る設計論はOpenTelemetryのメトリクス実装｜計器選定とカーディナリティ設計で扱っています。

OpenTracing APIのBaggageが伝播されない非互換の回避

移行ガイドが名指しで警告している非互換が1つあります。「Baggage which is set using the OpenTracing API is not available to OpenTelemetry Propagators.」。OpenTracing APIで設定したBaggageは、OpenTelemetryのPropagatorからは見えません。

shim仕様側でもこの点は一貫しています。Span Shimは読み取り専用のOpenTelemetry SpanとSpanContext Shimを保持し、後者がSpanContextとBaggageを読み取り専用で抱える構造です。Baggageの更新は既存オブジェクトを書き換えず、新しいSpanContextShimを生成する不変方式で行われる。仕様の非推奨シナリオにも「OpenTracingコードがbaggageを消費する場合」が挙げられています。

結論は単純です。テナントIDやリクエスト種別をBaggageで引き回している計装があるなら、Baggageの読み書きは分割せず一度に移してください。計装だけ先にOpenTelemetryへ寄せ、設定側をOpenTracingに残す構成は、値が届かない障害を必ず生みます。

shimを挟んだ段階移行の手順とトレース分断を防ぐ切り替え単位

公式が示す移行の型は3段階です。順序に意味があり、入れ替えると観測が止まる期間が生まれます。

SDK差し替えとshim導入から始める公式の三段階の移行手順

手順は次のとおりです。

1. OpenTracingのTracer実装をOpenTelemetry SDKへ差し替え、shimを導入する。エクスポート先と形式は従来と同一に揃え、連続性を保ったまま基盤だけを入れ替える。
2. SDKの動作を確認したうえで、計装を1つずつOpenTelemetryの計装ライブラリへ置き換え、そのたびに対応するダッシュボードを更新する。
3. これ以降の新規計装は、OpenTracingではなくOpenTelemetry APIで書く。

第1段階でエクスポート形式を変えないことが肝心です。SDK差し替えと送信先変更を同時にやると、データが出ない原因が計装側なのか送信経路側なのか切り分けられなくなります。Tracer Shimは TracerProvider を受け取り、opentracing-shim という名前のtracerを取得する仕様です。TextMapとHTTPHeaders用のPropagatorは任意で指定でき、未指定ならグローバルのpropagatorへフォールバックする。既存システムが独自のヘッダ形式でコンテキストを運んでいるなら、ここで明示指定してください。

Go・Java・Python・JavaScript・.NET・C++の提供状況

公式の移行ガイドは主要言語すべてにshimの実装リンクを掲載しています。ただし言語ごとに難所が違います。

言語選択より先に確認したいのが、その言語にOpenTracingのScopeManagerに相当する仕組みがあるかどうかです。shim仕様は非推奨シナリオとして「暗黙のOpenTelemetry伝播はあるがScopeManagerがない言語」を挙げています。該当するとアクティブスパンの意味論が噛み合わず、shim経由でも期待どおりに親子関係が作られません。その場合は延命をあきらめ、一括でネイティブ移行する判断が要ります。

同一トレース内でのAPI混在が壊れたスパンを生む具体的な条件

移行中の事故は、ほぼこの1点に集約されます。公式ガイドはJavaScriptについて、同一トレース内でのAPI混在は「壊れたスパンや不整合なスパンを生む可能性があり、推奨されない」と述べ、コードパス全体を1つの単位として移行するよう求めました。shim仕様側でも、同一コードベースでShimとOpenTelemetry APIを混在させると親スパンが誤る恐れがあると非推奨シナリオに明記されています。

実務に落とすと、切り替えの単位は「サービス」でも「チーム」でもありません。1本のリクエストが通るコードパスです。入口のHTTPハンドラだけOpenTelemetryへ移し、その先の内部ライブラリがOpenTracing APIのまま残る状態が、最も危険な中間形になります。スパンは出るのに親子がつながらず、1リクエストが複数の断片に割れる。進捗を「置換したファイル数」で測ると、この分断に気づけません。測るべきは「端から端まで移行済みのコードパス本数」です。複数サービスにまたがる場合の配置設計はOpenTelemetryのKubernetes構成｜Operator導入とCollector二層設計を参照してください。

載せ替え時期の判断基準と、shimを据え置きで済ませてよい条件

ここからは判断です。公式は撤去時期の下限しか示していないため、着手時期は自分で決めることになります。玉虫色にせず、条件を切って言い切ります。

2027年3月の撤去予定から逆算して移行着手時期を決める考え方

結論から述べます。2026年8月時点でshimに依存している計装があるなら、置換計画は今期中に立ててください。理由は撤去の順序です。「2027年3月より前ではない」が指すのは仕様からの削除時期であり、各言語SDKが成果物の維持をやめるのはその後になります。仕様に要件が残る間は実装側にも維持の根拠がありますが、要件が消えた瞬間からshimは「互換のために誰かが好意で残しているもの」に変わる。それを本番の可観測性基盤の土台に置き続ける判断は、取りにくいはずです。

逆算します。置換作業には計装の棚卸し、コードパス単位の書き換え、ダッシュボードとアラートの再構築、本番での並行確認が要ります。サービス数が二桁ある組織なら数か月単位の作業です。2026年内に棚卸しと優先順位付けを終え、2027年前半を置換の実作業に充てる。この配分なら仕様撤去に追われる形にはなりません。

shimを据え置いてよい条件と、先送りが招く三つの失敗パターン

据え置きが正当化できる条件は1つだけです。そのサービスの機能追加が凍結済みで、かつ2027年内に廃止または全面刷新が確定していること。この2条件がそろうなら、移行工数を投じる意味はありません。片方でも欠けるなら据え置きは先送りにすぎません。動いていることと、来年も保守できることは別です。

先送りが招く失敗は、次の3つの形で現れます。

• shimを入れた時点で「移行完了」と扱い、第2段階の計装置換に着手しないまま年単位で放置する。第1段階はテレメトリの出口を揃えただけで、OpenTracing APIへの依存は1行も減っていません。
• 撤去が迫ってから全サービスを一斉に切り替え、属性名の変更でダッシュボードとアラートが同時に無反応になる。障害検知が落ちている最中に移行を進める状況が、最も避けたい形です。
• Baggageの設定側をOpenTracingに残したまま計装だけ移し、テナントIDなどの引き回しが静かに切れる。エラーが出ないため、下流の集計がおかしいと気づくまで時間がかかります。

3つに共通するのは、移行そのものの難しさではなく進め方の設計不足が原因だという点です。技術的な障壁は公式ガイドとshim仕様でほぼ解消されています。残っているのは順序と単位の決定だけです。

移行を止めないための実務体制と保守運用へ引き継ぐ範囲の線引き

移行を完走させる体制は、開発チーム内で閉じないほうが現実的です。計装の書き換えはアプリ側ですが、ダッシュボードとアラートの再構築、Collectorの設定変更、二重送信の管理は基盤側の作業になる。この2つを同じスプリントで動かす調整が実務では最大の難所です。ログ側の送出経路も見直すなら、OpenTelemetryのログ実装｜直接送信とfilelog receiverの選び分けの構成と突き合わせて計画してください。

開発リソースを新機能側に残したまま移行を進めたい場合は、計装の棚卸しと置換、ダッシュボード再構築までを外部に切り出す進め方もあります。一創では可観測性基盤の設計と移行、その後の運用引き継ぎまでを保守運用 ／ 内製化支援として請けています。置換の判断基準とダッシュボードの設計意図を運用チームへ引き渡すところまで範囲に含めれば、次の規約更新にも自走で追随できるでしょう。

よくある質問

OpenTracingからの移行でよく挙がる質問を、2026年8月時点の一次情報で整理します。

OpenTracingは今も使えますか？

動作はします。ただしCNCFが2022年1月31日にプロジェクトをアーカイブしており、機能追加もバグ修正も行われていません。新しいフレームワークやランタイムへの対応も期待できないため、新規の計装をOpenTracingで書く理由はない。既存の計装についても、OpenTelemetry仕様が2026年3月19日に互換要件を非推奨とし、撤去を2027年3月以降と告知した以上、移行計画を立てる段階に入っています。

shimを入れればコードを書き換えずに済みますか？

一時的には済みます。shimはOpenTracing APIの呼び出しを内部でOpenTelemetryの構造へ写す層なので、既存コードをそのままにSDKだけを差し替えられる。ただし公式移行ガイドはshimを第1段階と位置づけ、第2段階として計装をOpenTelemetry版へ順次置換することを前提にしています。導入時点ではOpenTracing APIへの依存が残ったままです。書き換えを回避する手段ではなく、書き換えの時間を稼ぐ手段と捉えてください。

OpenTracingとOpenTelemetryを同じサービスで併用できますか？

推奨されません。shim仕様は、同一コードベースでOpenTracing ShimとOpenTelemetry APIを混在させると親スパンが誤る恐れがあると明記しています。JavaScriptについては公式移行ガイドが、同一トレース内でのAPI混在は壊れたスパンや不整合なスパンを生む可能性があるとして、コードパス全体を1つの単位で移行するよう求めました。併用するとしても、リクエストが通る経路の途中で切り替わらないよう境界を引いてください。

Jaegerを使っている場合、移行で何が変わりますか？

受け側の変更は小さく、送り側の変更が主になります。JaegerはOpenTracingの代表的な実装として使われてきましたが、v2でOpenTelemetryを取り込む構成へ変わりました。移行の第1段階でエクスポート先を従来のJaegerのまま保てば、テレメトリの連続性を維持したままSDKだけを差し替えられる。バックエンド側の仕組みと選び分けはJaegerとは？v2でOpenTelemetryを取り込んだ分散トレーシングの仕組みとX-Rayとの選び分けで扱っています。

移行後にダッシュボードが壊れるのを防ぐ方法はありますか？

属性名の変更を移行前に洗い出しておくのが確実です。semantic-conventions v1.23.0でHTTPの規約が安定化した際、http.method は http.request.method へ改称されました。ダッシュボードのクエリ、アラートの条件式、メトリクスのグルーピング条件を棚卸しし、新旧の属性名の対応表を作ってから置換に入ってください。置換は一度に行わず、計装を1つ移すたびにダッシュボードを更新すれば、どの変更が何を壊したか追跡できます。

関連記事

• OpenTelemetry（OTel）とは｜3つのシグナル・OTLP・Collector・Prometheusとの違いを解説：移行先の定義と全体像を押さえる前提記事。
• Jaegerとは？v2でOpenTelemetryを取り込んだ分散トレーシングの仕組みとX-Rayとの選び分け：移行後のバックエンド選定。
• OpenTelemetryのメトリクス実装｜計器選定とカーディナリティ設計：属性設計が系列数に跳ね返る話。
• OpenTelemetryのログ実装｜直接送信とfilelog receiverの選び分け：トレース以外のシグナルの移行。
• OpenTelemetryのKubernetes構成｜Operator導入とCollector二層設計：複数サービス横断時の配置設計。