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領域で、ユーザー空間エージェントや伝統的なサイドカーパターンを置き換える動きが本格化したことを意味する。
eBPFが解決する3つの問題
1. サイドカーレス観測
従来のKubernetesのオブザービリティはサイドカー注入モデル（全Podにagentコンテナを追加）が主流だった。この方式はリソース消費（Pod当たり10〜50MB程度のメモリ追加）と展開管理の複雑さを抱える。
eBPFはLinuxカーネル層で動作するため、アプリケーションに手を加えずにシステムコール・ネットワーク通信・CPU使用量をすべて収集できる。Ciliumのケースでは、サイドカーエージェントなしでPod間のL7通信メトリクスを収集する「Hubble」が、Kubernetes環境の観測の標準ツールとして定着しつつある。
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]。
CiliumやTetragonが使うeBPFベースのKubernetesネットワーク・セキュリティ運用を体系的に学べる一冊。
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）は順次対応ノードイメージを提供しているが、自前ノードプールは棚卸しが必要だ。
数百人規模で自社LLM基盤や生成AIサービスをAWS上に構築し、年次予算策定サイクルを持つ企業のインフラ担当・調達担当が対象になる。GPUインスタンスを一定期間確保できるCapacity Block（GPUインスタンスを予約購入できるAW[…]
日本企業への示唆
CNCF調査でeBPF本番採用が300%増という数字は、グローバルの動向だ。日本のIT環境では「新技術の採用は様子見」というサイクルが1〜2年遅れる傾向があり、eBPFの本番導入は国内では今がアーリーアダプター段階にある。今年からパイロットを始めることで、2〜3年後に標準になるアーキテクチャへの先行者優位を作れる。
まずは開発・ステージング環境でCiliumやFalcoをDaemonSetとして試し、サイドカーエージェントとの比較ベンチマークを取ることが最初のステップだ。
数千人規模でAzure MonitorとDatadogを併用し、年次のコスト監査で監視ツール契約の妥当性を問われる企業のITインフラ担当者は、今回の発表を無視できない。対象はマイクロソフトのAzure Monitor、具体的にはSLI（サ[…]
まとめ
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のカーネルオフロードが効いたケースで、通常の監視用途での導入ではそこまでの劇的な変化はありません。アプリのサイドカーを廃止できる分のメモリ削減効果の方が大きいケースが多いです。
ビジネススクールで受講した「テクノベート・シンキング」の学びを全12回でまとめるシリーズ、その10。 前回はノーコード×AI APIで実際にアプリを作った話を書いた。今回は第5回後半の課題──「自分のビジネス領域でAIがどう使われ、今後[…]
