この記事の概要
2026年5月21日、OpenTelemetryがCNCF（Cloud Native Computing Foundation）のGraduatedプロジェクトに昇格しました。
Kubernetes に次ぐ2番目の成長速度を誇るこのプロジェクトの卒業は、メトリクス・ログ・トレースの収集標準が事実上確定したことを意味します。
まだ導入を検討段階で止めているチームは、今こそ本番採用に踏み切るタイミングです。
OpenTelemetryがオブザーバビリティの「共通言語」になった
※ 画像挿入予定（otel_graduation_announcement）
2026年5月21日、CNCFはObservability Summitの場で OpenTelemetryのGraduation（卒業） を正式に発表しました。
CNCFにおけるプロジェクトの成熟度には「Sandbox → Incubating → Graduated」の3段階があります。
GraduatedはKubernetesやPrometheusなどと同じ最高ランクで、セキュリティ監査・ガバナンスレビュー・本番実績の基準をすべてクリアした証明です。
今回の卒業が業界に与えるメッセージは明確です。
「OpenTelemetryはもはや実験的な技術ではない。
本番環境で使うべき標準である」ということです。
主なマイルストーン：
| 日付 | 出来事 |
|---|---|
| 2019年5月 | OpenTracing + OpenCensus が統合しCNCF Sandboxへ |
| 2021年8月 | CNCF Incubatingに昇格 |
| 2026年5月21日 | CNCF Graduatedに昇格 |
プロジェクトの規模感を数字で示すと、コントリビューター数は 12,000人以上・2,800社以上 に上り、直近12か月でJavaScript APIが 13.6億回、Python APIが 13億回 ダウンロードされています。
CNCFの240以上のプロジェクトの中でも、Kubernetesに次ぐ 2番目の成長速度 を記録しています。
なぜ今まで「Sandbox/Incubating」だったのか — ベンダー中立の標準を作ることの難しさ
「そんなに使われているのに、なぜ今まで卒業していなかったの？」と感じた方もいるかもしれません。
理由は、Graduationの審査基準がきわめて厳しいからです。
特に以下の2点に時間がかかりました。
1. セキュリティ監査（サードパーティ独立審査）
OpenTelemetry CollectorはGo製の高スループットなパイプラインコンポーネントで、外部からデータを受け取りルーティング・変換・エクスポートを担います。
インターネットに公開されることも多いため、独立したセキュリティファームによる審査が必須でした。
2. ガバナンスの成熟
単一ベンダーへの依存を排除し、Alibaba・Anthropic・Bloomberg・Capital One・eBayなど数千社が対等に関与できる運営体制を確立する必要がありました。
この長い準備期間こそが、OTelが「特定ベンダーのベストプラクティス集」ではなく「業界全体の共通基盤」として機能できる理由です。
Graduated後もその姿勢は変わらず、DatadogやDynatrace・New Relicといった競合するベンダーが同じ仕様に沿ってSDKを提供し続けています。
また、Graduation直前には以下の新機能も追加されました：
- Kotlin Multiplatform SDK の新規追加（モバイル〜サーバーサイド統一計装）
- Profiles シグナルがパブリックアルファへ昇格（CPU/メモリプロファイリングをトレースと相関可能に）
- GenAI / LLM向けセマンティック規約の整備（AIワークロードの可観測性に対応）
実際にOpenTelemetry Collectorを構成してみる
Graduated後のOTelを実務で活用する基本ステップを示します。最も重要なコンポーネントは OpenTelemetry Collector です。
アプリケーションから直接エクスポーターに送るのではなく、Collectorを中継させることで、バックエンドを変更しても計装コードを変更せずに済みます。
graph LR App[アプリケーション SDK計装済み] -->|OTLP gRPC/HTTP| Collector[OTel Collector] Collector -->|metrics| Prometheus[Prometheus] Collector -->|traces| Jaeger[Jaeger / Tempo] Collector -->|logs| Loki[Loki] Collector -->|all signals| CloudWatch[Amazon CloudWatch]
実装例・コード例
Kubernetes上にOTel Collectorをデプロイする最小構成のHelmセットアップです。
# OpenTelemetry Collectorをk8s上にインストール
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update
helm install otel-collector open-telemetry/opentelemetry-collector \
--namespace observability \
--create-namespace \
-f otel-collector-values.yaml
# otel-collector-values.yaml
mode: daemonset # または deployment
config:
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
# Kubernetesのメトリクスも自動収集
kubeletstats:
collection_interval: 20s
auth_type: serviceAccount
endpoint: "${env:K8S_NODE_NAME}:10250"
processors:
# バッチ送信でネットワーク効率化
batch:
timeout: 10s
send_batch_size: 1024
# メモリ保護
memory_limiter:
limit_mib: 512
spike_limit_mib: 128
# リソース属性の付与
resourcedetection:
detectors: [env, k8snode]
timeout: 5s
exporters:
# PrometheusフォーマットでメトリクスをRemote Write
prometheusremotewrite:
endpoint: "http://prometheus:9090/api/v1/write"
# Tempoへトレース送信
otlp/tempo:
endpoint: "http://tempo:4317"
tls:
insecure: true
# CloudWatchへOTLPで直接送信（2026年4月〜プレビュー）
awscloudwatch:
region: ap-northeast-1
log_group_name: /otel/collector
service:
pipelines:
metrics:
receivers: [otlp, kubeletstats]
processors: [memory_limiter, batch, resourcedetection]
exporters: [prometheusremotewrite]
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlp/tempo]
logs:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [awscloudwatch]
アプリケーション側（Python例）の計装コードはシンプルです：
# requirements: opentelemetry-api opentelemetry-sdk opentelemetry-exporter-otlp
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
# CollectorのエンドポイントへOTLP送信
provider = TracerProvider()
exporter = OTLPSpanExporter(endpoint="http://otel-collector:4317", insecure=True)
provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(provider)
tracer = trace.get_tracer(__name__)
def process_order(order_id: str):
with tracer.start_as_current_span("process_order") as span:
span.set_attribute("order.id", order_id)
span.set_attribute("service.version", "2.1.0")
# ビジネスロジック
...
実務での活用シナリオ
シナリオ1：監視ツールのマルチベンダー移行
DatadogからGrafana Stackへの移行など、バックエンドを変更する際にOTelが威力を発揮します。
アプリのコードを一切変えずに、Collector設定のエクスポーター定義を変更するだけで切り替えが完了します。
シナリオ2：AIワークロードの可観測性
2026年はLLMを組み込んだサービスが急増しています。
OTelのGenAIセマンティック規約を使うと、LLMへの入出力トークン数・レイテンシ・エラー率をトレースと紐付けて記録できます。
「どのユーザーリクエストがモデルを何回呼び出し、コストはいくらか」を可視化する基盤になります。
シナリオ3：Amazon CloudWatchへのOTLP直送（プレビュー）
2026年4月から、CloudWatchがOTLPメトリクスをネイティブサポートしています。
これまでEMFフォーマットへの変換や中間ツールが必要でしたが、CollectorからそのままOTLPで送信できるようになりました。
AWSネイティブ環境で運用するチームには特に注目の変更です。
OTel Graduated後の今日から始める3つのアクション
Graduationを受けて、各主要クラウドプロバイダーの対応も加速しています。
AWS・Azure・GCPいずれもOTLPをネイティブサポートする方向で動いており、今後「OpenTelemetryを使わない理由」はどんどん少なくなっていきます。
Graduated発表を機に、以下の3ステップでOTelの本番採用を進めることをおすすめします：
Step 1: まずCollectorをサイドカーまたはDaemonSetで置く
アプリの計装より先に、Collectorをインフラに配置して既存のPrometheus/Fluentdからのデータを通過させるだけでも価値があります。
バックエンドの切り替えがいつでも可能な状態になります。
Step 2: 新規サービスはOTel SDKで計装する
既存サービスの計装は段階的に行い、新規開発分からOTel SDKを標準として採用します。
Go・Python・Java・Node.jsのSDKはすべてStableです。
Step 3: Profilesシグナルのアルファを試す
CPU・メモリプロファイリングをトレースと同じコンテキストで記録できるProfilesシグナルがアルファになっています。
特にGo/Python製のバックエンドで、パフォーマンス問題の根本原因特定に役立ちます。
まとめ
OpenTelemetryがCNCF Graduatedになったことは、単なる称号以上の意味を持ちます。
2,800社以上が参加し、第三者セキュリティ監査をパスした標準が確立されたということは、「どのクラウド・どの監視ツールを選んでも計装コードを書き直さなくて済む」時代が正式に始まったことを意味します。
インフラエンジニアにとって重要なのは、ベンダーロックインのリスクを計装レベルで回避できることです。
Collectorを中継させる設計を今から取り入れておくだけで、5年後に監視ツールを刷新する際のコストが大幅に下がります。
コメント