--- title: "eBPFとは？Linuxカーネルを拡張する仕組みと可観測性・ネットワークでできること" url: "https://www.issoh.co.jp/tech/details/13232/" published: 2026-07-07 updated: 2026-09-02 categories: ["インフラ・クラウド"] publisher: "株式会社一創" --- # eBPFとは？Linuxカーネルを拡張する仕組みと可観測性・ネットワークでできること eBPFは、Linuxカーネルのソースを書き換えたりモジュールを読み込んだりせずに、小さなプログラムをカーネル空間で安全に動かす技術です。もとはパケットフィルタの仕組みでしたが、いまはネットワーク・可観測性・セキュリティを横断する基盤へ広がりました。名前は聞くものの「結局カーネルで何ができるのか」「自社で書く必要があるのか」で止まる技術者は多いはずです。本記事は、検証器とJITによる安全性の担保、kprobeやXDPといったフック地点、CO-RE/BTFでカーネル差を吸収する移植性、Cilium・Falco・bpftraceでの実用途、そしてeBPFを自社実装すべき企業と既製ツール経由で足りる企業の条件までを、実装の解像度で整理します。 ## まとめ：eBPFの要点と自社実装か製品経由かで分かれる判断軸 先に結論を置きます。eBPFは、カーネルを改造せずに機能を足せる「カーネルの拡張口」です。開発者が書いた小さなプログラムを、カーネルがまず検証器で安全性を確かめ、JITでネイティブ命令に変換してから、システムコールやネットワーク処理といった要所（フック地点）で実行します。アプリを止めず、カーネルモジュールの危うさも避けて、内部の挙動を観測し制御できる点が核心です。 できることは大きく三つ。ネットワーク（高速なパケット処理・CNI）、可観測性（アプリ無改修でのトレースやメトリクス収集）、セキュリティ（プロセス挙動のランタイム検知）です。CiliumやFalcoのように、この三領域を製品化した実装が広く動いています。 採用判断の軸は明確です。多くの企業にとって、eBPFプログラムを自分で書く必要はありません。CiliumやDatadogのような既製ツールが内部でeBPFを使っており、その恩恵だけを受け取れば足ります。自社実装が見合うのは、既製ツールで解けない固有の計測・制御要件があり、カーネルバージョン差やverifierの制約を運用できる体制がある場合に限られます。まず「既製で足りるか」を先に問うのが、過剰投資を避ける順序です。 ## eBPFの定義とLinuxカーネルを書き換えずに機能を足す仕組み eBPFを理解する近道は、それが避けている面倒——カーネルそのものの改造——から入ることです。従来、カーネルの挙動を変えるには本体の改修かカーネルモジュールが必要でした。そもそも[カーネルとは何か、その役割と仕組みはこちらで解説しています](https://www.issoh.co.jp/tech/details/13534/)。どちらも危険と手間を伴います。 ### eBPFがカーネル空間でサンドボックス実行するプログラムの正体 eBPFはextended Berkeley Packet Filterの略で、名前どおり出発点はパケットフィルタでした。いまの姿は、開発者の書いた小さなプログラムをカーネル空間のサンドボックス内で走らせる汎用の実行環境です。カーネル本体には一切手を入れず、ソース変更もモジュール読み込みも要りません。プログラムはバイトコードとしてカーネルに渡され、後述の検証を経てから所定の地点で動きます。この「本体を触らずに振る舞いを足す」性質が、eBPFがクラウドネイティブ基盤で使われる土台になりました。全体像は[クラウドネイティブの構成技術とCNCFの定義](https://www.issoh.co.jp/column/details/12999/)で確認できます。 ### 検証器とJITコンパイルが安全性と実行性能を両立させる二段構え カーネル空間でユーザーのコードを走らせるのは、本来なら危険な行為です。eBPFはこれを二段構えで安全にします。第一段が検証器（verifier）で、プログラムが必ず終了すること、未初期化の変数や境界外メモリに触れないこと、複雑度が上限を超えないことを、実行前に静的に検査する関門です。危ういプログラムはここで弾かれ、実行には`CAP_BPF`などの特権が要ります。第二段がJITコンパイルで、検証を通ったバイトコードをその場でネイティブ命令へ変換し、カーネルコードと同等の速度で動かす。安全性を静的検査で、性能をJITで確保する分業です。Spectre系の投機実行攻撃に対するメモリマスキングなどの緩和策も組み込まれています。 ### eBPFのフック地点とマップが状態を共有する仕組みとプログラム型 eBPFプログラムは、単体で動くのではなく特定の「引っかけ地点」に取り付けて実行します。代表的なフック地点は次の通りです。 - kprobe/kretprobe：カーネル関数の任意の入口・出口 - uprobe/uretprobe：ユーザー空間の関数呼び出し - tracepoint：カーネルが定義済みのトレースイベント - XDP・tc：ネットワークパケットの受信経路とトラフィック制御 取り付ける地点ごとにプログラム型が決まり、扱えるデータや権限が変わります。そして観測・計測した結果は「マップ」と呼ばれるデータ構造（ハッシュ・配列・リングバッファなど）に書き込み、ユーザー空間のプログラムがそれを読み出す。カーネル側で拾った生の情報を、マップ越しにユーザー空間へ運ぶ二層構造が、eBPFの計測とネットワーク制御を成り立たせています。 ## eBPFでできることとネットワーク・可観測性・セキュリティの用途 eBPFの用途は、カーネルのどの地点にフックするかで三つの領域に分かれます。それぞれ何を解くのかを具体で押さえます。 ### XDPとtcによる高速パケット処理とKubernetesのネットワーク制御 ネットワークはeBPFが最も早くから効いた領域です。XDPはNICに近い受信経路にフックし、パケットがカーネルの通常処理に入る前に転送・破棄・書き換えを判断します。DDoS防御やロードバランサで、iptablesより桁違いに軽い処理が組めるのが利点です。Kubernetes環境では、[Cilium](https://www.issoh.co.jp/tech/details/13265/)がこのeBPFネットワークをCNI（コンテナ間通信の基盤）として実装し、Podの通信制御やネットワークポリシーをカーネル側で捌きます。Kubernetesが土台になる前提は[コンテナオーケストレーションとKubernetesの役割](https://www.issoh.co.jp/column/details/13003/)で整理しました。ノード単位でプロキシを集約できるため、サイドカー方式より軽い構成を狙えます。 ### カーネルイベントを捉える可観測性とアプリ無改修の分散トレース 可観測性でeBPFが変えたのは「計測のためにアプリを書き換えなくてよい」点です。従来は各アプリにエージェントや計装コードを埋め込む必要がありました。eBPFはカーネル側でシステムコールや関数呼び出しを直接捉えるため、アプリのコードに触れずにレイテンシ・システムコール頻度・ネットワークフローを取れます。bpftraceで単発の調査を、PixieやParca、Datadogのような製品で継続的な収集を行うのが実務の型です。この考え方の全体像は[オブザーバビリティとは何か](https://www.issoh.co.jp/column/details/3077/)で扱っており、eBPFはそれをカーネル層から支える具体的な手段にあたります。アプリ改修なしで依存関係まで追える密度が、既存の監視との差になります。 ### ランタイムセキュリティでプロセスの挙動を検知する仕組みと製品 セキュリティ領域では、実行中のプロセスがカーネルに投げるシステムコールを監視し、不審な挙動をその場で検知します。想定外のファイルアクセス、権限昇格、外部への通信といった動きを、アプリのログではなくカーネルイベントとして捉える。CNCFの[Falcoが実行時の脅威を検知する仕組み](https://www.issoh.co.jp/tech/details/17238/)や、IsovalentのTetragonがこの用途の代表です。カーネルモジュール型のセキュリティツールと違い、eBPFはverifierで安全性を担保するため、監視ツール自体がカーネルをクラッシュさせる危険を抑えられます。侵入検知を、アプリの外側・カーネルの内側という一段深い層で回せるのが強みです。この検知をクラウドのワークロード全体へ広げる仕組みは[CWPPの定義と収集方式の整理](https://www.issoh.co.jp/tech/details/16212/)で解説しています。 ## eBPFの開発方式とCO-RE・BTFがカーネル差を吸収する仕組み eBPFを自分で書く段になると、最初の壁は「カーネルバージョンごとに構造体が違う」問題です。ここを解く仕組みまで押さえると、採用判断の解像度が上がります。 ### BCC・libbpf・bpftrace・GoやRustのライブラリの使い分け 開発の入口は複数あります。手早く調べたいならbpftraceで、awkに似た短い記述でカーネルイベントを追えます。本格的な開発ではlibbpf（C言語）が基盤で、コンパイル済みのeBPFオブジェクトを読み込んで動かす方式です。アプリケーションへ組み込むなら、Go言語のcilium/ebpfやRustのayaといったライブラリを使い、ホスト側のプログラムからeBPFを制御する構成が一般的です。かつて主流だったBCCはPythonから実行時にコンパイルする方式で手軽な反面、実行環境にコンパイラを要する重さがありました。いまはlibbpfとCO-REの組み合わせが主流に移っています。 ### CO-REとBTFでカーネルの差を越えて動かす移植性の仕組み eBPFプログラムはカーネル内部のデータ構造に触れるため、素朴に書くとカーネルバージョンが変わるたびに再コンパイルが要りました。これを解くのがCO-RE（Compile Once, Run Everywhere）です。BTF（BPF Type Format）というカーネルの型情報を使い、実行時に構造体のずれを吸収して、一度ビルドしたバイナリを複数バージョンのカーネルで動かします。BTFとCO-REはカーネル5.8以降で最も安定して使え、Linuxは6.x系が主流の時期に入りました（2026年時点）。ここが運用の分かれ目になります。CO-RE前提なら移植の手間は小さく済みますが、古いカーネルや独自ビルドのカーネルを抱える現場では、BTFの有無を先に確かめる必要があります。 ### Windows対応とeBPF Foundationが示すLinux外への広がり eBPFはLinux発祥ですが、活動範囲はそこに留まりません。2021年8月に発足したeBPF Foundation（Linux Foundation傘下）には、Meta・Google・Isovalent・Microsoft・Netflixなどが名を連ね、Linuxの外への展開を進めています。MicrosoftのeBPF for Windowsは、Windows 11やWindows Server 2022以降でeBPFを動かす試みで、PREVAILという健全性を証明できる検証器をユーザー空間で使う設計です。ただしWindows対応は開発途上で、Linuxほどの成熟度には届いていません。技術選定の現時点では、eBPFの本番運用はLinuxが前提と捉えるのが妥当です。 ## eBPFを自社実装すべき企業と既製ツール経由で使うべき企業の条件 ここは立場を明確にします。eBPFは強力ですが、大半の企業にとって「自分でeBPFプログラムを書く」場面はありません。恩恵の受け取り方を分けて考えます。 ### eBPFプログラムを自社で実装する投資が見合う要件と運用体制 次の条件が重なるほど、自社実装の価値が出ます。 - 既製ツールで解けない固有の計測・制御要件がある（独自プロトコルの観測、特殊なパケット処理など） - 大規模なトラフィックやノード数で、汎用エージェントのオーバーヘッドが無視できない - カーネルバージョン差・BTFの有無・verifierの制約を扱えるエンジニアと検証環境がある eBPFの自社実装は、C言語やGo/Rustでのカーネル寄りの開発と、カーネル差を吸収する運用の両方を要します。既製ツールが吸収してくれる複雑さを、自前で引き受ける判断です。固有要件と運用体制の二つが揃って初めて投資が回収できる、という順序を外さないことが肝心になります。カーネルレベルの可観測性やネットワーク基盤を含めた設計・実装の相談は、[Webシステム開発](https://www.issoh.co.jp/service/system/)で対応しています。 ### eBPFを直接書かず既製ツール経由で足りる小規模な構成の見極め 逆に、次の場合はeBPFを直接書くべきではありません。 第一に、標準的な監視やネットワーク要件しかない構成です。可観測性ならDatadogやPixieがすでにeBPFを内部で使っており、ネットワークならCiliumを入れれば、カーネルプログラムを一行も書かずに恩恵を受け取れます。第二に、カーネルを扱える人手がいない組織です。eBPFプログラムはverifierに弾かれると原因の特定が難しく、カーネルバージョン更新で動かなくなるリスクも抱えます。運用できる体制がないまま自作すると、ブラックボックスを増やすだけに終わりがちです。第三に、小規模でトラフィックも限られる段階です。この規模ではエージェントのオーバーヘッドが問題にならず、自作の労力が便益を上回ります。CiliumのeBPFデータプレーンを使うサービスメッシュのように、製品として磨かれた実装に乗るのが現実的な出発点になります。その住み分けは[サービスメッシュの仕組みと導入判断](https://www.issoh.co.jp/tech/details/13224/)で掘り下げました。まず既製で足りるかを問い、足りない一点が明確になってから自作を検討する。この順序が過剰投資を避けます。 ## eBPFの仕組み・できること・導入判断についてのよくある質問 検討段階でよく挙がる質問をまとめます。概念と採用判断に絞って答えます。 ### eBPFとBPF（旧来のBPF）の違いは何ですか？ BPFは元来、パケットをフィルタするための限定的な仕組みでした。eBPF（extended BPF）はそれを大幅に拡張し、パケット処理だけでなくカーネルの関数呼び出しやシステムコールにもフックできる汎用の実行環境になりました。扱えるマップの種類、フック地点、命令セットが広がり、ネットワーク・可観測性・セキュリティを横断する基盤へと役割が変わっています。現在「BPF」と言えば、多くはこのeBPFを指します。 ### eBPFで具体的に何ができるのですか？ 大きく三領域です。ネットワークでは、XDPによる高速なパケット処理やCiliumによるKubernetesの通信制御ができます。可観測性では、アプリを改修せずにレイテンシやシステムコールを計測でき、分散トレースまで取れる点が特徴です。セキュリティでは、プロセスの挙動をカーネルイベントとして監視し、不審な動きをランタイムで検知します。いずれもカーネルを改造せずに実現できる点が共通しています。 ### eBPFの利用にカーネルの改造やモジュール導入は必要ですか？ 不要です。eBPFの核心は、カーネル本体のソース変更もモジュール読み込みもせずに機能を足せる点にあります。開発者が書いたプログラムはバイトコードとしてカーネルに渡り、検証器の検査を通ってから実行される流れです。従来のカーネルモジュールと違い、検証器が安全性を担保するため、拡張コードがカーネルをクラッシュさせる危険を抑えられます。 ### eBPFはWindowsでも利用できますか？ MicrosoftのeBPF for Windowsにより、Windows 11やWindows Server 2022以降で動かす取り組みが進んでいます。PREVAILという検証器をユーザー空間で使う設計です。ただし開発途上で、Linuxほどの成熟度や実績には届いていません。2026年時点では、本番運用を前提にするならLinuxを基盤に据えるのが妥当な判断になります。 ### eBPFとカーネルモジュールはどう違うのですか？ どちらもカーネルの機能を拡張しますが、安全性の担保が異なります。カーネルモジュールはカーネル空間で無制限に動くため、バグがあればシステム全体を巻き込みかねません。eBPFは実行前に検証器が終了保証や境界チェックを行い、危ういプログラムを弾きます。そのぶんできることに制約はありますが、監視や計測を安全に足す用途では、モジュールよりeBPFが向きます。 ## 関連記事 - [クラウドネイティブとは？CNCFの定義・構成技術・導入判断](https://www.issoh.co.jp/column/details/12999/)：eBPFやCiliumが支えるクラウドネイティブ基盤の全体像。本記事の上位ハブ - [オブザーバビリティとは何か：その定義と全体像](https://www.issoh.co.jp/column/details/3077/)：eBPFがカーネル層から支える可観測性の概念。監視との違いはこちら - [コンテナオーケストレーションとは？Kubernetesの役割](https://www.issoh.co.jp/column/details/13003/)：CiliumのeBPFがCNIを担う土台。Kubernetesの必要性の判断はこちら - [サービスメッシュとは？仕組みと導入判断](https://www.issoh.co.jp/tech/details/13224/)：CiliumのeBPFデータプレーンでつながる領域。サイドカーレス方式の詳細 --- 出典: [eBPFとは？Linuxカーネルを拡張する仕組みと可観測性・ネットワークでできること]()（株式会社一創）