オブザーバビリティ層のうち、eBPF（カーネル内で安全に小さなプログラムを動かす仕組み）を使った計装が実用域に入ってきた。対象はKubernetes基盤でアプリの通信を可視化したいプラットフォームチームやSREで、これまでは各サービスにOpenTelemetry SDKを組み込む計装作業が避けられなかった。OpenTelemetry公式プロジェクトのOBI（OpenTelemetry eBPF Instrumentation、コード変更なしでアプリの通信を観測するプロジェクト）は、この前提を変える。カーネルでHTTP/gRPC/SQLなどの通信を直接観測し、RED指標（Rate・Error・Duration、サービスの健全性を示す3つの基本指標）と分散トレースをアプリのコードに一切触れずに取得する[1][2]。2026年4月のKubeCon+CloudNativeCon Europeでベータ発表があり、バージョンはv0.10.0まで進み、年内の1.0 GA（一般提供開始）に向けたロードマップが公式ブログで示された[1][3][6]。既存の計装導入コストに悩むIT運用部門と、投資判断を下す経営層の双方にとって、OBIがどこまで実用になっているかを見極める材料を整理する。
予備知識
- eBPF: カーネル内で安全に小さなプログラムを動かし、アプリの動作をコード変更なしに観測できる仕組み
- OBI: OpenTelemetry eBPF Instrumentationの略。Grafana Beylaを起源に持ち、2025年にOpenTelemetryへ寄贈されたゼロコード計装プロジェクト
- RED指標: Rate（リクエスト率）・Error（エラー率）・Duration（応答時間）というサービス健全性の3指標
- ゼロコード計装: アプリのソースコードやビルド設定を変更せずにテレメトリを取得する計装方式
OBIの基盤技術であるeBPFの仕組みをカーネルレベルから体系的に学べる
OBIとは何か：eBPFでゼロコード計装を実現する仕組み
OBIは、Linuxカーネル内でアプリの通信を直接観測し、コード変更もSDK組み込みも不要でテレメトリを生成するOpenTelemetry公式プロジェクトである。
起源はGrafana Labsが2023年に開発したBeylaで、当初はOpenTelemetryのGo向けeBPF計装エージェントのフォークとして始まった[4]。Grafanaは2025年にBeylaのコードをOpenTelemetryへ寄贈し、週次SIG（Special Interest Group）体制での開発に移行、同年内にアルファ版を公開した[4][5]。
技術面では、アプリの実行ファイルとOSのネットワーク層をeBPFプローブで検査し、Linux上のHTTP/HTTPSおよびgRPC通信からWebトランザクションのスパンとRED指標を取得する[2]。カーネル側のプローブは生イベントのみ捕捉し、パースやフィルタリングなど重い処理はユーザー空間のエージェントに任せる設計のため、CPUオーバーヘッドは低く抑えられている[6]。
2026年4月にv0.8.0がリリースされ、同月のKubeCon+CloudNativeCon Europe（アムステルダム）でSplunkがベータローンチを発表した[4][7]。取得データはOpenTelemetry Protocol（OTLP）で出力されるため、既存のOTel Collectorやバックエンドにそのまま接続できる。
OBIが出力するOTLPやシグナル設計などOTel全体の基礎概念を学べる
対応シグナルとプロトコル：RED指標・分散トレース・サービスグラフ
OBIが対応する範囲は当初のHTTP/gRPCから、SQL・Redis・MongoDB・Kafkaなど主要ミドルウェアの通信プロトコルへと広がっている。
公開時点でOBIが計装できるプロトコルは、HTTP/HTTPS・HTTP/2・gRPCに加え、SQL・Redis・MongoDB・Kafka・GraphQL・Elasticsearch/OpenSearch・AWS S3まで及ぶ[8]。直近のv0.10.0では分散トレーシングとgRPCのコンテキスト伝播（サービス間でトレースIDを引き継ぐ仕組み）が強化され、ランタイムテレメトリと運用面の制御項目も追加された[9]。
これらの通信から生成されるRED指標と分散トレースは、サービス間の呼び出し関係を示すサービスグラフの生成にもそのまま使える。スパンから事後集計する従来方式に比べ、OBIはサービスグラフ用のメトリクスを直接生成できるため、監視対象サービス側・処理パイプライン側の双方でオーバーヘッドを抑えやすい[6]。
OBIはOpenTelemetry SDKの導入有無も自動検知し、SDKがすでに動いているサービスでは重複計測を避ける設計になっている[6]。この自動検知は、eBPFとSDKを段階的に併用する移行パスを設計しやすくする一因になる。
Amazon CloudWatch（AWSのマネージド監視サービス）が、OpenTelemetry（OTel、ログ・メトリクス・トレースを統一形式で扱う業界標準規格）由来のメトリクスをネイティブに取り込み、PromQL（Promet[…]
従来のSDK計装との比較：導入コストと情報量のトレードオフ
SDK計装はアプリごとのコード変更と保守が必要な一方、業務コンテキストを含む深いテレメトリを取得できる。両者の違いを整理する。
| 観点 | SDK計装（従来） | OBI（eBPF・ゼロコード） |
|---|---|---|
| 導入作業 | サービスごとにコード変更・依存追加 | カーネルで自動検知、コード変更なし |
| 対応範囲 | 計装済みサービスのみ | 対応プロトコル内の全通信 |
| 情報の深さ | 業務ロジックに紐づくカスタム属性を付与可能 | 通信情報が中心、業務コンテキストは限定的 |
| 向いている対象 | 新規開発・自社コード | レガシー・サードパーティ・多言語混在環境 |
| 運用の手間 | 言語ランタイムごとに保守が必要 | 言語非依存、Linuxカーネルに依存 |
OBIとSDK計装は代替関係ではなく補完関係にある。ゼロコード方式はコード改修なしに全サービスへ横断的なベースライン計装を提供する一方、SDK計装はビジネスロジックに直結したカスタム属性など、より深い文脈情報を付与できる[6]。
判断の起点は「コード変更が可能か」と「必要な情報の深さ」の2軸になる。改修コストが高いレガシーサービスや多言語混在環境では、まずOBIで全体のRED指標とトレースを確保し、重要度の高いサービスから段階的にSDK計装を足すハイブリッド構成が現実的だ[6]。
2026年5月21日、CNCF（Cloud Native Computing Foundation）はOpenTelemetry（以下OTel）のGraduated（卒業）ステータスへの昇格を正式発表した[1]。Graduatedは[…]
1.0 GAへのロードマップ：2026年に何が変わるか
OpenTelemetry eBPF Instrumentation SIGは2026年の最重要目標を安定版1.0のリリースに置き、本番採用の障壁を順に解消する計画を示している。
公式ブログが示す2026年ロードマップの旗艦目標は、本番環境での採用に耐える安定版1.0のリリースである[1]。1.0到達に向けた作業は、ドキュメントの整備、設定項目の標準化、本番運用に耐えるかの検証の3点に整理されている[1]。
並行する取り組みとして、OpenTelemetryのAPI・SDKとの統合強化によるハイブリッド計装の前提整備、ネットワーク属性のセマンティック規約への統一、OBIをレシーバーとして組み込んだOTel Collectorディストリビューションの提供、eBPFプロファイラーとの統合、OBI自体からのランタイムメトリクス提供が挙げられている[1]。
現時点でOBIはベータ段階であり、1.0到達前のマイナーバージョンではAPIや設定項目が変わる可能性が残る。本番の重要サービスに投入する前に、非クリティカルな環境でv0.10.0系を検証し、ロードマップの進捗を見ながら投入時期を判断するのが妥当だ[1][9]。
※本記事は2026年7月時点の情報です。料金・提供条件は変動が速いため、最新は各公式でご確認ください。一部アフィリエイトリンクを含みます。 ✅ 先に結論（Seedance 2.0の要点） 何がすごい[…]
まとめ
OBIは、Kubernetes基盤の通信をコード変更なしに可視化できる段階まで実用度を高めている。既存のSDK計装をゼロコードに置き換える話ではなく、改修コストの高いサービスや多言語混在環境にまずOBIでベースラインの可観測性を敷き、重要度の高いサービスにSDK計装を重ねるハイブリッド構成が現実的な出発点になる。次の一歩として、非クリティカルなワークロードでOBIのPoC（概念実証）を回し、既存のSDK計装とコスト・オーバーヘッド・情報の深さを比較検討することを勧める。1.0 GAの進捗を継続的に追い、本番投入のタイミングを見極めたい。
よくある質問（FAQ）
Q1. OBIとGrafana Beylaはどう違うのですか。
OBIはBeylaを起源とするプロジェクトで、Grafana Labsが2025年にコードをOpenTelemetryへ寄贈したことで生まれた。開発体制がOpenTelemetryの週次SIGに移り、ベンダー中立のプロジェクトとして継続している[4][5]。
Q2. OBIを導入すれば既存のSDK計装は不要になりますか。
不要にはならない。OBIはSDKの有無を自動検知して重複計測を避ける設計で、業務コンテキストを含む深い情報が必要なサービスにはSDK計装を残すハイブリッド構成が推奨される[6]。
Q3. 本番環境にはいつ投入すべきですか。
現時点ではベータ段階でAPIや設定が変わる可能性がある。2026年内の1.0 GAを待つか、非クリティカルな環境で先行検証しながらロードマップの進捗を確認するのが妥当[1][9]。
