こんにちは、インフラエンジニアのryuです。
「サービスが遅いらしい。でも、どこが原因かさっぱり分からない」。そんな夜を過ごしたことは、ありませんか。
サーバーは動いている。CPUもメモリもグラフ上は問題なさそう。なのに、ユーザーからは「つながらない」の声。ログをあちこち掘り返しても、原因の尻尾がなかなかつかめない。
そんなときに効いてくるのが、今日のテーマオブザーバビリティ、日本語で言う「可観測性」です。
2026年、この分野はちょうど大きな節目を迎えました。標準化を担うOpenTelemetryという仕組みが正式に一人前と認められ、eBPFというLinuxカーネルの技術が「見える化」のやり方そのものを塗り替えつつあります。
専門用語が続くテーマですが、身近なたとえを交えながら進めます。気楽に読み進めてください。
オブザーバビリティ（可観測性）って、そもそも何？¶
まずは言葉の整理から始めましょう。オブザーバビリティとは、システムの外から観測できる情報だけを頼りに、その内部で何が起きているかを推し量れる状態のことです。
もともとは制御工学の言葉で、「出力を見れば内部の状態が分かるか」を表す概念でした。それをソフトウェアの世界に持ち込んだのが、いまの使われ方です。
たとえるなら、お医者さんの診察に似ています。体の中を直接のぞかなくても、体温・脈拍・血液検査といった外に出てくる数値から、体の中で何が起きているかを推し量りますよね。
システムも同じです。中で何が起きているかを直接は見られません。だから、システムが外に出してくれる手がかりを集めて、状態を読み解くわけです。
監視（モニタリング）とどう違うの？¶
「それって、昔からある監視と何が違うの？」と思った方もいるでしょう。ここは混同しやすいので、丁寧に分けておきます。
従来の監視は、あらかじめ「これを見張る」と決めた項目を追いかける発想です。CPU使用率が90%を超えたら警告、といった具合ですね。
つまり監視は、「起きると分かっている問題」に強い。一方で、想定していなかった未知の不具合には弱いのです。
オブザーバビリティは、その逆を狙います。事前に予想していなかった問いにも、集めておいたデータから後追いで答えられるようにしておく。そんな考え方です。
両者の違いを、表にまとめてみましょう。
| 観点 | 従来の監視（モニタリング） | オブザーバビリティ（可観測性） |
|---|---|---|
| 得意なこと | 予測できる既知の問題を見張る | 予測できない未知の問題を後から探る |
| 問いの立て方 | 「CPUは大丈夫か？」と事前に決める | 「なぜ遅い？」と後から自由に掘る |
| 主なデータ | あらかじめ決めた指標 | 指標・ログ・トレースを幅広く収集 |
| 向いている対象 | 構成が固定的なシステム | 複雑で変化の速い分散システム |
誤解のないように言えば、監視が古くて可観測性が新しい、という単純な話ではありません。可観測性は、監視を含んだうえで、その先まで見通せるように土台を広げたもの、と捉えるのが正確です。
手がかりになる「三つの柱」¶
では、システムはどんな手がかりを出してくれるのでしょうか。オブザーバビリティの世界では、代表的なものを「三つの柱」と呼びます。
一つ目がメトリクス。CPU使用率やリクエスト数のような、時間とともに変わる数値です。健康診断でいう、体温や血圧のような定点の数字ですね。
二つ目がログ。「何時何分に、何が起きたか」を記録した文章です。ログの扱いにまだ不安がある方は、Linuxのログ監視の基本から手を動かしてみると土台が固まります。
三つ目がトレース。一つのリクエストが、どのサービスをどの順番で通っていったかを追いかけた「経路の記録」です。宅配便の追跡番号を思い浮かべてください。荷物がどの営業所を、いつ通過したかが分かるあの仕組みに近いものです。
この三つを組み合わせて、はじめて「なぜ遅いのか」に答えられるようになります。数字で異変に気づき、経路で怪しい区間を絞り、ログで最後の一手を確かめる。そんな流れです。
どれか一つだけでは、どうしても足りません。数字だけを見ていても「なぜ」までは分からず、ログだけを追いかけても全体の流れは見えてこないからです。三つがそろってはじめて、点と点が線でつながり、一枚の地図として原因までたどり着けるようになるのですね。
2026年、OpenTelemetryが「標準」になった¶
さて、ここからが今年ならではの話です。この三つの柱を集めるやり方は、長らくツールごとにバラバラでした。
計測ツールを乗り換えるたびに、アプリのあちこちに埋め込んだ「計測用のコード」を書き直す。これはエンジニアにとって、地味だけれど大きな負担でした。
そこで登場したのが、集め方を統一しようという取り組みOpenTelemetryです。特定の製品に縛られず、メトリクス・ログ・トレースを共通の作法で集めて送り出すための、いわば「業界共通の配線規格」だと考えてください。
そして2026年5月、このOpenTelemetryはクラウドネイティブ技術の総本山であるCNCF（Cloud Native Computing Foundation）で、最高位である「Graduated（卒業）」に到達しました。技術面だけでなく、運営体制やセキュリティ、幅広い採用実績まで認められた、という節目です。
数字を見ると、その広がりがよく分かります。
| 項目 | 規模（2026年時点） |
|---|---|
| コントリビューター（開発協力者） | 12,000人超 |
| 参加企業 | 2,800社超 |
| JavaScript用APIの年間ダウンロード | 約13.6億回 |
| Python用APIの年間ダウンロード | 約13億回 |
これだけの人と企業が同じ規格に乗った、ということです。もはや一部の先進企業だけの流行ではなく、様子見をしている側が少数派になりつつある、という段階に入りました。
なぜ「ベンダー中立」がそんなに大事なの？¶
「規格が一つにまとまると、そんなにうれしいの？」という声が聞こえてきそうです。ここは可観測性を語るうえで、外せない勘所です。
計測の仕組みが特定の製品専用だと、その製品から離れづらくなります。乗り換えようとするたび、計測コードの書き直しが待っているからです。これを、囲い込み（ロックイン）と呼びます。
たとえるなら、部屋の照明が特定メーカー専用の特殊なソケットしか使えない状態です。電球を替えたくても、まずソケットごと交換しなければならない。これでは選ぶ自由がありません。
OpenTelemetryは、この配線を共通規格にそろえます。集め方さえ標準化しておけば、送り先のツールは後から自由に選び直せる。この「乗り換えの自由」こそが、多くの企業がこぞって採用した最大の理由なのですね。
ちなみに2026年には、四つ目の柱として「継続的プロファイリング」も新たな信号として加わり始めました。プログラムのどの処理が時間を食っているかを、常時こまかく追う仕組みです。可観測性の守備範囲は、いまも静かに広がり続けています。
eBPFが変える「コードを触らない観測」¶
ここまでで、集め方の規格が一つにまとまってきた話をしました。でも、もう一つ大きな流れがあります。それが、そもそも「計測用のコードを書かなくてよくする」動きです。
その主役がeBPFという技術です。これはLinuxカーネル、つまりOSの一番奥まった中心部で、安全に小さなプログラムを動かせる仕組みです。
Linuxカーネルがそもそも何をしているのかは、Linuxのしくみの記事で触れています。ざっくり言えば、アプリとハードウェアの間に立つ「案内係」のような存在です。
コードに手を入れずに、なぜ中が見えるの？¶
eBPFのすごさは、この案内係の受付カウンターに、そっと観測係を座らせられる点にあります。
アプリが通信をするときも、ファイルを読むときも、必ずカーネルという受付を通ります。その受付の様子を、カーネルの外から横で記録する。だから、アプリのコードには一切手を触れずに、通信量やエラー、処理にかかった時間までが見えてしまうのです。
従来のやり方だと、観測したいアプリ一つひとつに計測コードを埋め込む必要がありました。eBPFなら、その手間が要りません。
アプリを書き換えず、再起動もせず、動いているシステムの内側を観測できる。この「コードに触れない観測」こそ、eBPFが可観測性にもたらした最大の変化だ。
この二つの流れは、実はきれいに合流しました。2026年、Grafana社は自社のeBPFツール「Beyla」をOpenTelemetryに寄贈し、OpenTelemetry eBPF Instrumentation（略してOBI）という公式プロジェクトとして生まれ変わったのです。
つまり、「eBPFでコードに触れず集めて、OpenTelemetryの共通規格で送り出す」という、理想的な組み合わせが標準の道筋になりつつある、ということですね。
イメージだけ、ごく簡単なコマンドで示しておきましょう。実際の運用はもっと複雑ですが、雰囲気はつかめるはずです。
# eBPFベースの計測ツール(OBI)を、対象プロセスを指定して起動するイメージ
# アプリ側のコードは一切変更しない
export OTEL_EBPF_EXECUTABLE_PATH=/usr/bin/my-web-server
export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4317
otel-ebpf-instrument
# → 通信・処理時間などが自動で集まり、OpenTelemetry形式で送信される
こうした仕組みは、コンテナが無数に立ち上がるKubernetesのような環境で特に力を発揮します。Kubernetesとは何かの記事でも触れているように、動的に増えたり消えたりするコンテナを、一つずつ手作業で計測するのは現実的ではありません。だからこそ、カーネルの側からまとめて見張るeBPFの発想が効いてくるわけです。
もっとも、eBPFは万能の魔法ではありません。カーネルの中で動く技術ですから、ある程度新しいバージョンのLinuxが前提になりますし、細かい仕組みまで踏み込もうとすれば、結局カーネルへの理解が求められます。
そしてもう一つ、忘れてはいけない現実があります。観測データは、集めれば集めるほど保管や転送にお金がかかる、ということです。すべてを無制限に集めれば安心、というわけにはいきません。何を集め、何を捨てるか。その見極めもまた、可観測性の設計に欠かせない視点なのですね。
エンジニアにとって、可観測性は何を意味するの？¶
「便利そうだけど、これって大規模なシステムの話でしょう？」と思うかもしれません。でも、可観測性の土台は、日々の基礎とまっすぐつながっています。
なぜなら、集まってくるデータを読み解くには、結局インフラの基礎知識が欠かせないからです。トレースを見て「この区間が遅い」と気づけても、そこがネットワークの問題なのか、ディスクの問題なのかを見極めるのは、人間の側の力量にかかっています。
eBPFがカーネルの話である以上、Linuxの理解は避けて通れません。通信の経路を読むには、ネットワークの基礎も要ります。派手な新技術ほど、足元の基本がものを言うのですね。
この流れは、開発と運用を橋渡しするPlatform Engineeringの記事や、AIが運用を変えつつあるAgentic AIOpsの記事とも地続きです。そして、集めたデータをどう費用対効果で見るかという点では、FinOpsの記事ともつながっています。効率も、自動化も、お金も、可観測性という一枚の地図の上でつながっているのです。
私が運営に関わっているInfraAcademyでも、こうした基礎を手を動かしながら学べる教材をそろえています。可観測性を「読める」エンジニアを目指すなら、まずはLinuxのロードマップでOSの土台を固め、続けてネットワークのロードマップで通信の流れをつかんでいくと、遠回りせずに進めます。
なお、こうした最新のインフラ知識を新人研修に組み込みたい企業の方は、法人プランもあわせてのぞいてみてください。
まとめ¶
最後に、今日の話を振り返りましょう。
オブザーバビリティ（可観測性）とは、システムが外に出す手がかりから、内部で何が起きているかを読み解ける状態のことです。決めた項目だけを見張る従来の監視に対し、想定外の問いにも後から答えられるよう、土台を広げた考え方でした。
その手がかりが、メトリクス・ログ・トレースという三つの柱。そして2026年、集め方を統一するOpenTelemetryがCNCFを卒業し、業界の共通規格として一人前と認められました。
さらにeBPFの広がりで、アプリのコードに触れずに内部を観測できるようになり、両者はOBIという形で一つに合流しつつあります。
派手な新技術に見えますが、それを使いこなす鍵は、やはりLinuxやネットワークといった足元の基礎にあります。焦らず、まずは自分が触れている環境のログや通信を、いつもより少しだけ深くのぞいてみるところから始めてみましょう。
今日も読んでくれて、ありがとうございました。
