Linux カーネルの中でコードを安全に動かす技術として登場したeBPF（extended Berkeley Packet Filter）が、クラウドネイティブ観測基盤の主流に躍り出た。CNCF（Cloud Native Computing Foundation）のQ1 2026調査では、eBPFソリューションの本番採用率が前年比300%増を記録した[1][2]。楽天・Cloudflare・Netflix・ByteDanceが大規模事例として取り上げられ、チェコのSeznam.czはeBPFロードバランサー導入でスループット2倍・CPU使用率72分の1を達成している[2]。
この数字が示すのは単なる「eBPFが流行った」という話ではない。観測・セキュリティ・ネットワーキングの3領域で、ユーザー空間エージェントや伝統的なサイドカーパターンを置き換える動きが本格化したことを意味する。
予備知識：本記事を読む前に
- カーネル（Linuxカーネル）：OSの中核で、ハードウェア制御・プロセス管理・ネットワーク処理を担う部分。通常のアプリケーションコードはカーネルの外側（ユーザー空間）で動く。
- サイドカー：Kubernetes環境で、メインのアプリケーションコンテナに並走させる補助コンテナ。ログ収集や通信の可視化などを担当するが、Pod数だけリソースを消費する。
- BTF / CO-RE：BTF（BPF Type Format）はカーネルの型情報を保持する仕組み、CO-RE（Compile Once – Run Everywhere）はそれを使って同じeBPFプログラムを異なるカーネルバージョンで再コンパイルなしに動かす仕組み。eBPFの可搬性を支える基盤技術。
eBPFの本質は、「カーネルの外からリクエストするのではなく、カーネルの中で安全にコードを実行して観測・制御する」という発想の転換にある。従来はカーネルの挙動を変えるには専用モジュールの開発とカーネル自体の変更が必要だったが、eBPFは検証済みの安全なプログラムをカーネル内に動的にロードできる。
eBPFが解決する3つの問題
1. サイドカーレス観測
従来のKubernetesのオブザービリティはサイドカー注入モデル（全Podにagentコンテナを追加）が主流だった。この方式はリソース消費（Pod当たり10〜50MB程度のメモリ追加）と展開管理の複雑さを抱える。
eBPFはLinuxカーネル層で動作するため、アプリケーションに手を加えずにシステムコール・ネットワーク通信・CPU使用量をすべて収集できる。Ciliumのケースでは、サイドカーエージェントなしでPod間のL7通信メトリクスを収集する「Hubble」が、Kubernetes環境の観測の標準ツールとして定着しつつある。
Kubernetesのネットワーク・セキュリティ運用をeBPFの視点まで含めて体系的に押さえておきたい場合、拡張リソース管理やCilium・Tetragonのような周辺技術も扱う書籍が土台として役立つ。
2. カーネル層のセキュリティ観測
eBPFはkprobe・tracepoint・LSM（Linux Security Module）フックを通じて、OS内部の動作をユーザー空間からプローブできる。Falco・Tetragonがこの仕組みを使ってシステムコールレベルの脅威検知を実現している。
具体的には「特定プロセスが予期しないネットワーク接続を開いた」「通常のアプリがファイル削除操作を実行した」といった異常をリアルタイムで検知できる。コンテナランタイム上のワークロードでも、カーネルから見ればOSのプロセスに過ぎないため、コンテナのアイソレーション境界をまたいで横断的に観測できる。
3. カーネルオフロードによる高性能ネットワーキング
eBPFはXDP（eXpress Data Path）を使ってNIC（ネットワークインターフェイスカード）のドライバ層でパケット処理を行うことができ、ユーザー空間でのスタック処理を完全にバイパスする。Cloudflareはこの仕組みでDDoSパケットのフィルタリングをカーネル以前の段階で処理している。Seznam.czが達成したスループット2倍・CPU使用率72分の1という数字はXDPベースのロードバランサーの典型的な成果だ[2]。
OTel第4のシグナル：プロファイリング統合
OpenTelemetry（OTel）はトレース・メトリクス・ログの3シグナルで知られていたが、2026年にProfilesシグナルが公開アルファになった[2]。eBPFプロファイラーがOpenTelemetry Collectorのレシーバーとして統合され、DaemonSet（各Kubernetesノードに1つ起動するPod）として展開されるアーキテクチャが標準形として定着しつつある。
プロファイリングシグナルが可能にするのは「CPU時間の消費がコードのどの行に起因するか」をリアルタイムで観測することだ。従来のメトリクス・ログだけでは「CPU 80%」という事実はわかるが、「どの関数呼び出しが原因か」が分からなかった問題を、継続的プロファイリングが解決する。
楽天の導入事例から学ぶ設計判断
楽天はeBPFを使ったネットワーク観測を大規模に本番展開した事例として2026年のレポートで取り上げられた[1]。日本企業の事例として参考になる設計判断の骨子は次の2点だ。
サイドカーからCiliumへの段階移行：全Pod同時移行は変更リスクが高いため、特定Namespaceやサービスメッシュをまず無効化してCiliumのHubbleで置き換え、観測継続性を確認しながら段階移行する。
カーネルバージョンの制約管理：eBPFの高度な機能（BTF、CO-RE等）はLinux 5.8以降を要件とするケースが多い。マネージドKubernetes（EKS・AKS・GKE）は順次対応ノードイメージを提供しているが、自前ノードプールは棚卸しが必要だ。
段階移行の計画づくりや、本番運用に落とし込む際の実務的な勘所は、Kubernetes本番運用を扱う書籍でも補強できる。
日本企業への示唆
CNCF調査でeBPF本番採用が300%増という数字は、グローバルの動向だ。日本のIT環境では「新技術の採用は様子見」というサイクルが1〜2年遅れる傾向があり、eBPFの本番導入は国内では今がアーリーアダプター段階にある。今年からパイロットを始めることで、2〜3年後に標準になるアーキテクチャへの先行者優位を作れる。
まずは開発・ステージング環境でCiliumやFalcoをDaemonSetとして試し、サイドカーエージェントとの比較ベンチマークを取ることが最初のステップだ。
まとめ
eBPFはカーネル層からの全通信・全プロセス観測というユーザー空間エージェントでは不可能な粒度の観測を、サイドカーなしで実現する。CNCF調査の300%増という数字はその有効性が本番環境で証明された結果だ。OTelのプロファイリングシグナルとの統合により、トレース・メトリクス・ログ・プロファイルの4シグナルを統一基盤で管理する「Full-Stack Observability」が実用段階に入っている。
よくある質問（FAQ）
Q1. eBPFを使うためにカーネルはどのバージョンが必要ですか？
基本的なeBPF機能はLinux 4.xから使えますが、実用的な本番用途（BTF/CO-RE対応・LSMフック等）はLinux 5.8以降を推奨します。EKS（Amazon Linux 2023）・GKE（cos_containerd）・AKS（Ubuntu 22.04系）はいずれも5.15以降で動作します。
Q2. Ciliumの導入はCalico等の既存CNIからの移行が必要ですか？
はい、CNI（Container Network Interface）の置き換えになります。KubernetesのCNIはクラスター単位で一つしか動かせないため、Calicoを使っているクラスターにCiliumを追加インストールする形にはなりません。新規クラスターからの採用か、既存クラスターの移行計画が必要です。
Q3. eBPFのオーバーヘッドはどの程度ですか？
軽量に設計されており、典型的なeBPFプローブのCPUオーバーヘッドは数%未満です。Lista.czのように「CPU使用率が72分の1になった」ケースはXDPのカーネルオフロードが効いたケースで、通常の監視用途での導入ではそこまでの劇的な変化はありません。アプリのサイドカーを廃止できる分のメモリ削減効果の方が大きいケースが多いです。
Q4. eBPFプログラムがカーネルをクラッシュさせる心配はありませんか？
eBPFプログラムはロード時にカーネル内の「ベリファイア（verifier）」による静的検査を通過しないと実行できません。無限ループや不正なメモリアクセスになりうるコードは検証段階で拒否されるため、通常のカーネルモジュールと比べて安全性が高い設計になっています。この安全性の担保が、eBPFがカーネルの本番運用に受け入れられた大きな理由です。
