「eBPF（イービーピーエフ）」という言葉を、最近 Linux の記事やカンファレンスでよく見かけるようになりました。
名前は知っているけれど、結局それが何で、自分のような初学者に関係あるのか分からない——そう感じている人は多いはずです。
結論から言うと、eBPF は カーネルのソースを書き換えず、再コンパイルもせず、アプリも止めずに、Linux カーネルの中で小さなプログラムを安全に動かす仕組みです。
本記事では概念の説明だけで終わらせず、Ubuntu 24.04 の Docker 公式イメージで bpftrace を実際にインストールし、
動いているプロセスのシステムコールをリアルタイムで覗くところまで、実行結果つきで見せていきます。
（カーネル 5.10.76 上で 2026-06-15 に実測）
この記事のポイント
- eBPF はカーネルを再コンパイルせずに「観測・制御」の小さなプログラムを安全に差し込む技術です
- 安全性の鍵は
検証器(Verifier)。無限ループや不正メモリアクセスがあるプログラムは一切ロードされません - Ubuntu では
apt install bpftraceだけで、すぐに eBPF を体験できます（24.04 で bpftrace v0.20.2） - 実測では、アプリを1行も変えずに
cadvisorが5秒で534回ファイルを開いていることまで丸見えになりました - 一般ユーザーからの eBPF はデフォルトで無効（
unprivileged_bpf_disabled=1）。root かCAP_BPFが必要です
eBPF とは何か（ざっくり全体像）
eBPF は extended Berkeley Packet Filter の略です。
もともとはネットワークパケットをフィルタするための小さな仮想マシンでしたが、現在は「カーネルの好きな場所に、安全な小さなプログラムを取り付けられる汎用の仕組み」へと拡張されました。
カーネル（OS の中核となる、ハードウェアとアプリの間を取り持つ部分）に手を入れたいとき、従来はカーネルモジュールを書くかカーネル本体を改造して再コンパイルするしかありませんでした。
どちらもハードルが高く、バグがあればシステム全体が固まる（カーネルパニック）リスクがあります。
eBPF はこのリスクを取り除き、「観測したい」「ちょっと制御したい」といった用途を、アプリを止めずに、カーネルを再起動せずに実現します。
ユーザーが書いたコードが、実際にカーネルの中で動くまでの流れは次のようになっています。
ポイントは③の検証器(Verifier)です。
ユーザーが書いたプログラムはそのままカーネルに入るわけではなく、「危険なことをしないか」を静的に検査され、合格したものだけが JIT で機械語に変換されて実行されます。
この仕組みがあるおかげで、初心者が雑にワンライナーを書いても、システム全体を巻き込んで落とすことは基本的に起こりません。
なぜ「安全に」カーネルを拡張できるのか
「カーネルの中でコードを動かす」と聞くと危なそうですが、eBPF が安全とされるのには明確な理由があります。
eBPF が安全な3つの理由
- 検証器(Verifier)が、無限ループ・未初期化メモリの読み出し・範囲外アクセスをロード前に拒否する
- eBPF プログラムは決められたヘルパー関数しか呼べず、任意のカーネル関数を勝手に実行できない
- 実行は有限ステップで終わることが保証される（昔は完全にループ禁止、今は有界ループのみ許可）
さらに Ubuntu では、一般ユーザーが勝手に eBPF プログラムをロードできないように設定されています。
実際に実行カーネルの設定を確認してみると、次のようになっていました。
1
# 1 = 一般ユーザーからの eBPF ロードは無効。root か CAP_BPF 権限が必要です
値が 1 なので、特権のないユーザーは eBPF を使えません。
これはセキュリティ上の妥当なデフォルトで、後述の bpftrace も sudo（または root のコンテナ）で動かす必要があります。
「権限が要る」という事実そのものが、eBPF が無制限のバックドアではないことを示しています。
Ubuntu で実際に eBPF を動かしてみる
概念だけ並べても腹落ちしないので、ここからは実際に手を動かします。
入門に最適なのが bpftrace です。これは数行のワンライナーで eBPF プログラムを書ける高水準のトレース言語で、C のコードを書かなくても eBPF を体験できます。
前提環境
本記事は ubuntu:24.04 Docker 公式イメージ（カーネル 5.10.76）で実行しています。eBPF はカーネルの機能を直接使うため、コンテナで試す場合は --privileged が必要です。バージョンが違うとツールのバージョンやオプションが変わる場合があります。
手順1：bpftrace をインストールする
インストールは apt 一発です。実際に実行したログがこちらです。
bpftrace 本体に加えて、eBPF ローダの中核ライブラリである libbpf1（バージョン 1.3.0）などが依存として入り、合計47パッケージがインストールされました。
bpftrace --version は bpftrace v0.20.2 を返しました。
手順2：最初の eBPF プログラムを動かす
まずは「カーネルにプログラムを1個ロードして、すぐ終了する」だけの最小例です。
BEGIN はトレース開始時に1回だけ動くブロックで、いわば eBPF 版の「Hello World」です。
Attaching 1 probe... に続いて hello from eBPF が表示されました。
地味に見えますが、この瞬間、本物の eBPF バイトコードが検証器を通過し、カーネル内で実行されているのです。
同じ図の下段では、カーネルが「どこを観測できるか」を数えています。
bpftrace -l でアタッチ可能なプローブ（観測点）を一覧すると、なんと 合計 49,550 個もありました。
内訳はシステムコールのトレースポイントが 568 個、カーネル関数を動的に観測できる kprobe が 46,288 個です。
つまりカーネル内のほぼあらゆる関数の出入りに、自分のプログラムを取り付けられるということです。これが eBPF の表現力の源泉です。
ライブでシステムコールを覗いてみる
ここからが eBPF の本領です。いま動いているプロセスが、どのシステムコールを何回呼んでいるかを、対象のアプリを一切改造せずにリアルタイムで集計してみます。
システムコール（syscall）とは、アプリがカーネルに「ファイルを開いて」「メモリをくれ」などとお願いするための入口です。
①ファイルを開いた回数をプロセス別に数える
openat（ファイルを開くシステムコール）の呼び出しを、comm（プロセス名）ごとに5秒間集計します。
たった5秒の観測で、システム上で動く各プロセスのファイルアクセス量が一目で分かりました。
この環境で最も活発だったのは cadvisor（コンテナ監視ツール）で 534回、次いで runc が180回、elasticsearch が120回です。
strace のように1プロセスに張り付くのではなく、システム全体を横断して集計できるのが eBPF の強みです。しかもオーバーヘッドはごくわずかです。
②呼ばれているシステムコールの種類で並べる
今度は視点を変えて、「どの種類のシステムコールが一番多いか」を全プロセス横断で5秒間集計してみます。
圧倒的1位は epoll_pwait（9,966回）でした。これはイベント待ちのシステムコールで、サーバー系プロセスが「次のリクエストを待っている」状態を表します。
2位の futex（8,949回）はスレッド間のロック処理です。
そして注目してほしいのが、リストの中に bpf システムコール自身が 626回登場している点です。
これは cadvisor など監視系のプロセスが、裏で eBPF プログラムを次々とロードしている証拠で、「現代の Linux 監視は eBPF だらけ」という現実がデータに表れています。
正直、この bpf が上位に出てきたのは私も驚きました。eBPF を「これから学ぶ新技術」だと思っていたら、自分のマシンの監視ツールがすでにガンガン使っていた、というわけです。
Ubuntu 22.04 と 24.04 のツール差
eBPF はカーネルとツールの進化が速い分野なので、Ubuntu のバージョンによってツールの新しさがかなり違います。
実際に ubuntu:22.04 と ubuntu:24.04 の両イメージで apt-cache policy を叩いて、主要パッケージのバージョンを比較しました。
特に大きいのが libbpf の差です。22.04 の 0.5.0 に対し、24.04 は 1.3.0 とメジャーバージョンが上がっています。
libbpf は CO-RE（Compile Once – Run Everywhere）という、1度コンパイルした eBPF プログラムを別のカーネルでも動かす仕組みの中核です。
これから本格的に eBPF を学ぶなら、ツールが新しくつまずきの少ない Ubuntu 24.04 LTS を選ぶのがおすすめです。
eBPF は実際に何に使われているのか
「面白い技術だけど実用性は？」と思うかもしれません。実は eBPF は、すでに私たちが日常的に使うインフラの土台になっています。
eBPF が支えている主な領域
- 可観測性（Observability）：Prometheus 系の
cadvisor、Datadog、bcc/bpftraceによるパフォーマンス解析 - ネットワーク：Kubernetes の CNI である
Ciliumは eBPF でパケット処理とロードバランスを行う - セキュリティ：
Falcoや Tetragon が、不審なシステムコールを eBPF でリアルタイム検知する
eBPF の全体像や事例は、公式コミュニティサイト ebpf.io によくまとまっています。
トップページには、ユーザー空間からカーネルの Verifier & JIT を通って実行されるという、まさに本記事で説明した流れが図示されています。
本記事で使った bpftrace も、活発に開発が続く OSS です。GitHub リポジトリはスター 1万超、最新版は v0.26.1 がリリースされており、入門ツールとして安心して使えます。
よくある誤解とつまずきポイント
誤解1：eBPF は危険でシステムを壊しやすい
逆です。検証器(Verifier)が無限ループや不正アクセスをロード前に弾くため、カーネルモジュールを書くよりはるかに安全です。検証に通らないプログラムはそもそも動きません。
誤解2：root さえあればどこでも動く
権限だけでなく、カーネル側の機能も必要です。本記事の環境のように /sys/kernel/btf/vmlinux が無い（BTF 非搭載の）カーネルでは、kprobe を多用する bcc 系ツールが動かないことがあります。最近の Ubuntu の標準カーネルは BTF 付きなので問題ありませんが、軽量カーネルや古い環境では注意してください。
つまずきやすいエラー
コンテナで bpftrace を動かすと Could not read symbols from /sys/kernel/tracing/available_events と出ることがあります。これはトレース用の tracefs が未マウントなのが原因で、--privileged で起動し mount -t tracefs none /sys/kernel/tracing を実行すると解決します。
まとめ
この記事のまとめ
- eBPF はカーネルを再コンパイルせず、アプリも止めずに、観測・制御の小さなプログラムを安全に差し込む技術です
- 安全性の鍵は検証器(Verifier)。危険なプログラムはロード前に拒否されます
- Ubuntu なら apt install bpftrace だけで体験でき、24.04 では bpftrace v0.20.2 が入ります
- 実測では cadvisor が5秒で534回ファイルを開き、監視ツール自身が bpf システムコールを626回使っていました
- 本格的に学ぶなら libbpf が新しい Ubuntu 24.04 LTS が有利です
eBPF は最初こそ概念が難しく感じますが、bpftrace のワンライナーを1本動かすだけで「自分のマシンの中で本当に何が起きているか」が一気に見えるようになります。
まずは本記事の openat の集計あたりから、手元の環境で試してみてください。
なお、eBPF や bpftrace を本格的に試すなら、壊しても気にならない検証用のサーバーを1台持っておくと安心です。
自宅PCのカーネルをいじるのは怖い、という人ほど、月数百円から借りられる VPS が向いています。
どの VPS が学習用に向いているかは、実測ベンチをまとめた VPS比較の記事も参考にしてください。
特に Vultr は東京リージョンがあり、最小プランなら月 $5 ほどから eBPF やカーネルの実験環境を立てられます。
root 権限のある自分専用のサーバーなので、--privileged コンテナや sudo bpftrace も気兼ねなく試せます。
日本語のサポートや管理画面で安心して始めたい場合は、ConoHa VPS も選択肢になります。
コメント