2026年5月21日、CNCF（Cloud Native Computing Foundation）はOpenTelemetry（以下OTel）のGraduated（卒業）ステータスへの昇格を正式発表した[1]。GraduatedはCNCFの最高成熟度区分で、ガバナンス・セキュリティ監査・長期持続性の厳格な審査を経た証明に相当する。クラウドネイティブ可観測性レイヤーにおいて、OTelは事実上の業界標準として確定した。同時期に公開アルファとなったProfilesシグナルは、eBPF（カーネル内で安全に小プログラムを実行する仕組み）を用いた継続的プロファイリングをOTelの4本目の標準シグナルとして確立する[2]。メトリクス・ログ・トレースに続くProfilesの登場で、ベンダーAPM（アプリケーション性能管理ツール）に分散していたテレメトリを単一コレクターで集約できる設計が現実的になった。IT基盤を担う運用エンジニアと、そのコスト構造を意思決定する管理職の双方に、今すぐ検討すべき判断軸がある。
CNCF卒業の意味：ベンダー中立な可観測性標準の確定
OTelはCNCFに2019年5月に参加し、2021年8月にIncubatingへ昇格、2026年5月11日に卒業票決を通過した[1]。プロジェクト速度はKubernetesに次ぐCNCF第2位で、12,000人を超えるコントリビューターが2,800社以上に分散する。JavaScriptのAPIパッケージは過去12か月で13.6億ダウンロード、PythonのAPIパッケージは13億ダウンロードを超え、いずれも月次最高記録を更新した[1]。採用企業にはAlibaba・Anthropic・Bloomberg・Capital One・eBay・Herokuが名を連ねる。
GraduatedはIncubatingより上位の最高成熟度区分で、セキュリティ監査の実施・正式なガバナンス文書・長期持続性の評価が追加で求められる。調達担当が「OSS採用のベンダーリスク」を評価するとき、Graduatedは明確な根拠になる。DatadogやNew RelicもOTLPインジェスト対応を強化しており、OTelを軸に置く設計が事実上の共通解になりつつある。
第4シグナル「Profiles」：eBPF連続プロファイリングの仕組み
メトリクス・ログ・トレースに続く第4シグナルProfilesは、2026年3月25日に公開アルファとなった[2]。OTLPプロトコル上でCPUサンプル・メモリ割り当て・スタックトレースを送受信できるようにし、仕様はpprof形式（Goの標準プロファイリングフォーマット）と情報ロスなく相互変換できる[2]。
eBPFプロファイラーの実装（opentelemetry-ebpf-profiler）はElasticが寄贈したコードを基にしており、OTel Collectorのレシーバーとして動作する[3]。Linux上でホスト全体を低オーバーヘッドで計測し、追加インストゥルメンテーションなしにGo・JVM・Pythonを含む主要言語ランタイムをサポートする。GoはCollector側での自動シンボル解決（auto symbolization）に対応した。
| シグナル | 安定度 | 主なユースケース |
|---|---|---|
| Metrics | Stable | リソース使用量・SLO（サービス品質の目標値）監視 |
| Logs | Stable | 障害調査・監査ログ |
| Traces | Stable | レイテンシ分析・依存関係の可視化 |
| Profiles | Alpha | CPU/メモリのボトルネック特定・コスト効率の可視化 |
Profilesはアルファ段階であり、APIの破壊的変更が起きる可能性がある。バックエンド（Grafana Pyroscope・Elastic等）の対応は進行中で、本番採用は非クリティカルなワークロードから試験を始めるのが現実的だ。
本番基盤への組み込み：3つの設計判断軸
OTel Profilesの実装アプローチは、3軸で判断を整理すると明確になる。
アーキテクチャ軸：OTel CollectorをすでにKubernetesのSidecarまたはDaemonSetとして稼働させている環境では、eBPFプロファイラーをレシーバーとして追加するだけでデプロイが完結する。新規構築の場合はCollectorのメモリ・CPU割り当てを事前に見積もる。
バックエンド互換性軸：GrafanaスタックとElastic Stackは2026年時点でProfiles取り込みに対応している。商用APM（Datadog・New Relic等）はOTLPインジェストを段階的に拡充しているが、Profilesシグナルの受け入れ状況は各社で異なるため事前確認が必要だ。
稼働環境軸：現行のeBPFプロファイラーはLinux専用で、Windowsノードプールでは動作しない。EKS・AKS・GKE上のLinux DaemonSetとして展開する場合は、ノードへのhostPIDアクセスとprivilegedコンテナ権限が必要になる。
ベンダーAPMからの移行コスト構造
OTelのGraduated昇格は、移行における最大の不確実性（仕様の後退・コミュニティ縮小リスク）を実質的に除去する。移行コストの主要項目を3区分で整理する。
| コスト区分 | 内容 |
|---|---|
| ライセンス | OTel本体はApache 2.0で無料。バックエンドをOSSに替える場合は自己ホスティング（インフラ・運用工数）を含むTCOで比較する |
| 移行エンジニアリング | Java・Python・Node.jsは自動計装（auto-instrumentation）の整備が進んでおり工数が少ない。カスタムメトリクスの移植とSLO定義の再設計が主な作業になる |
| ロックイン解消後のリスク管理 | アルファ段階のProfilesにはAPIの変更リスクがある。安定済みのメトリクス・ログ・トレースからTraces→Metrics→Logsの順で段階移行すると運用リスクを分散できる |
現在のベンダーAPMライセンス費をベースに、インフラコストと移行工数を加えたTCO比較が意思決定の起点になる。段階移行（Traces→Metrics→Logs）が工数と障害リスクを抑えやすい。
まとめ：今すぐ取るべきアクション
OTelのCNCF卒業とProfilesアルファ公開は、可観測性戦略を固める好機を告げる。既存のOTel Collectorを最新版に更新し、テスト環境でProfiles receiverを有効化してeBPFプロファイリングを試す。並行して現在のベンダーAPM契約のTCOを試算し、切り替えロードマップに期限を設ける。Graduated標準への集中が加速するなか、移行を後回しにするコストは年々上昇する。
よくある質問（FAQ）
Q1. CNCF GraduatedはIncubatingと何が違うのですか？
セキュリティ監査・正式ガバナンス・長期持続性の評価を追加で通過した最高成熟度区分です。プロジェクト廃止リスクが著しく低く、調達・契約のリスク評価根拠として使えます。
Q2. Profilesシグナルはいつ安定版になりますか？
2026年6月時点でPublic Alpha段階で、RC→Stableと進みますが具体的な時期は未発表です。商用バックエンドの対応が整い次第、本番採用が現実的になります。
Q3. すでにDatadogを使っています。移行は必要ですか？
必須ではありません。DatadogはOTLPインジェストに対応しており、OTelエージェントをDatadogに送ることも可能です。OTelへの依存度を高めておくことで、将来のバックエンド変更時のロックイン解消コストを下げられます。
