eBPFとは｜Linuxカーネル拡張の仕組みとCilium・可観測性での活用

eBPFとは何か｜カーネルを書き換えずに拡張する仕組み

結論として、eBPFはカーネル内にサンドボックス化されたプログラムを差し込む仕組みです。ソースコードの改変やカーネルモジュールのロードを必要とせず、システムを止めずに挙動を変えられます。条件は「検証器の審査を通ること」。例外として、検証器が安全性を証明できないプログラムは一切ロードされません。

eBPF公式サイトは、eBPFを「オペレーティングシステムにおけるカーネルのような特権を要する環境の中で、サンドボックス化されたプログラムを実行できる」技術と定義しています。

BPFからeBPFへ｜パケットフィルタが汎用実行基盤になった経緯

もともとのBPF（Berkeley Packet Filter）は、1990年代にパケットキャプチャのフィルタ条件を効率よく評価するための仮想マシンでした。tcpdumpの内部で使われていたあれです。

これが拡張され、汎用的なイベント処理基盤になったのが2014年のLinux 3.18です。レジスタ幅が64ビットになり、永続的なデータ構造（マップ）を持てるようになり、パケット以外のイベントにも接続できるようになりました。以降、機能追加はカーネルのリリースごとに積み上がっています。

2021年8月には、Meta・Google・Isovalent・Microsoft・Netflixが発起人となってeBPF Foundationがthe Linux Foundation傘下に設立されました。特定ベンダーの技術ではなく、業界横断の基盤として扱われているということです。

カーネルモジュール・ユーザー空間エージェントとの違い

3つのアプローチを比べると、eBPFが選ばれる理由がはっきりします。

ユーザー空間のエージェントで同じことをやろうとすると、/procを定期的に読む、システムコールをフックする、アプリにSDKを埋め込む、といった手段になります。どれも情報が薄いか、アプリ側の改修が要るか、オーバーヘッドが大きいかのどれかでした。eBPFは「カーネルの中で、取りたいデータだけを集約してから返す」ため、これらのトレードオフを比較的緩和しやすいのが特徴です。

ミニFAQ：eBPFを使うとカーネルが不安定になりませんか？

検証器が、無限ループしないこと・未初期化変数を読まないこと・メモリ境界外にアクセスしないことをロード前に検査します。検査に通らないプログラムはそもそもロードされないため、一般にカーネルモジュールより安全性を確保しやすい設計とされています。ただしこの安全性は、検証器だけでなくヘルパー関数の制約・ロード権限の制御・カーネル実装の健全性の組み合わせで成り立っています。検証器自体の脆弱性が報告された例もあるため、カーネルは更新し続けてください。

eBPFプログラムが動くまで｜フックポイント・検証器・マップ

結論から言うと、流れは「C言語などで書く → BPFバイトコードにコンパイル → カーネルにロード → 検証器が検査 → JITでネイティブコードに変換 → フックポイントに接続 → イベント発生時に実行」です。

どこに差し込めるか｜主なフックポイント

eBPFはイベント駆動です。あらかじめ定義されたフックポイントをカーネルやアプリケーションが通過したときに実行されます。

kprobeは任意のカーネル関数に差せて自由度が高い反面、関数名や引数がカーネルのバージョンで変わります。tracepointはカーネル側が安定性を約束している観測点なので、長く動かすツールではこちらが好まれます。

検証器（Verifier）が保証していること

検証器はプログラムの全パスを静的に解析します。チェックしているのは主に次の点です。

• 必ず終了すること（初期は後方ジャンプ禁止。Linux 5.3以降は上限が確定する有界ループを許容）

• 初期化されていない変数を読まないこと

• メモリ境界外にアクセスしないこと

• プログラムサイズが上限を超えないこと

この上限が実務でよく効いてきます。Linux 5.2より前は1プログラム4,096命令が上限で、5.2で特権ユーザー向けに100万命令まで引き上げられました。複雑なロジックを書くと「検証器に落とされる」経験をしますが、多くは分岐を減らす・ループ境界を明示する・関数を分割するといった書き換えで通ります。

eBPFマップ・ヘルパー関数・CO-RE

eBPFプログラムは単体では状態を持てません。状態の保存とユーザー空間とのやり取りを担うのがeBPFマップで、ハッシュテーブル・配列・LRU・リングバッファなどの型が用意されています。メトリクスを集計してからユーザー空間に渡す、という典型パターンはこのマップで実現します。

カーネルの機能を呼ぶにはヘルパー関数を使います。現在時刻の取得、乱数生成、マップ操作、プロセスやcgroupのコンテキスト取得などが安定APIとして提供されています。

そして移植性の鍵がCO-RE（Compile Once, Run Everywhere）です。カーネルの構造体レイアウトはバージョンで変わるため、以前はターゲットのカーネルヘッダを用意してビルドし直す必要がありました。カーネル5.2以降で使えるBTF（BPF Type Format）という型情報を使い、libbpfがロード時にオフセットを補正することで、1つのバイナリを複数のカーネルで動かせるようになっています。配布されるeBPFツールを複数のカーネルで動かしやすくなったのは、この仕組みのおかげです。逆に言えば、BTFが有効でないカーネルや、必要な機能が入っていないディストリビューションでは動かないこともあります。

eBPFで何ができるか｜3領域と主要ツール

用途は3つに大別できます。どれもカーネル内でイベントを掴むという共通点を持ちながら、出てくるプロダクトの見た目はかなり違います。

ネットワーキング

パケットが来た最も早い地点で処理できるため、ロードバランシングやパケットフィルタリングと相性が良い領域です。Metaは自社データセンターのソフトウェアロードバランサ（Katran）をeBPFで実装しています。Kubernetes領域ではCiliumが代表格です。

iptablesベースのkube-proxyは、Serviceが増えるとルールが線形に増え、評価コストとルール更新コストが効いてきます。eBPFはハッシュマップでの引き当てに置き換えるため、Serviceが数千規模になるクラスタほど、Service解決時の処理効率やルール更新時の運用負荷で差が出やすい構造です。逆に言えば、小規模クラスタではこの差は体感しにくい部分でもあります。

可観測性・プロファイリング

アプリケーションにSDKを埋め込まずに、通信・システムコール・CPU使用箇所を観測できるのがeBPFの強みです。アプリにSDKを埋め込まずに観測する、いわゆるゼロインストルメンテーションと呼ばれる方向性で、Pixie（Kubernetes向け自動計測）、Parca（常時プロファイリング）、bpftrace／BCC（アドホックなトレーシング）などがあります。

注意したいのは、eBPFがOpenTelemetryのような計装規格を置き換えるわけではない点です。eBPFで取れるのは「外から観測できる事実」で、業務的な文脈（どのユーザーのどの注文か）はアプリ側の計装でしか付けられません。実務では両者を併用します。Prometheus & Grafanaのようなメトリクス基盤や、DatadogやNew RelicといったSaaS側の監視製品も、eBPFベースのエージェントを提供しています。

セキュリティ・ランタイム防御

コンテナ内で想定外のプロセスが起動した、機密ファイルが読まれた、外部に予期せぬ通信が出た。こうした挙動をカーネル層で検知するのがFalcoやTetragonです。LSMフックを使えば検知だけでなく、その場で処理をブロックする強制まで踏み込めます。

主要ツールを整理すると次のようになります。公式の一覧はeBPF Applications Landscapeにまとまっています。

ミニFAQ：eBPFを使えばアプリへの計装は不要になりますか？

いいえ。通信・レイテンシ・システムコールのような「外形的な事実」はeBPFで取れますが、ビジネスコンテキストを伴うトレースやカスタムメトリクスはアプリ側の計装が必要です。eBPFは計装の代替ではなく、計装されていない領域を埋める手段と捉えるのが実務的です。

Ciliumとは｜eBPFベースのKubernetesネットワーク基盤

Ciliumは、eBPFベースのKubernetes向けCNIを中核に、ネットワークポリシーや通信の可視化機能までを提供するオープンソースプロジェクトです。2021年10月にCNCFのIncubatingとなり、2023年10月11日にCNCFの卒業（Graduated）プロジェクトになりました。卒業時点で7社のメンテナと800人超のコントリビュータが関わっています。

CNIとして解いていること

Ciliumが担当する範囲は、単なるPod間疎通にとどまりません。

• CNIプラグイン：オーバーレイ（VXLAN／Geneve）とネイティブルーティングの両方に対応

• kube-proxyの置き換え：Service解決をiptablesではなくeBPFで処理

• ネットワークポリシー：IPではなくアイデンティティ（ラベル）ベースでL3/L4を制御し、さらにHTTPメソッドやパス、DNS名などL7の条件も書ける

• 暗号化：IPsecまたはWireGuardによるノード間の透過的な暗号化

• Cluster Mesh：複数クラスタをまたいだService解決とポリシー適用

• Gateway API／サービスメッシュ：サイドカーを置かない構成でのL7処理

IPベースではなくラベルベースでポリシーを書ける点は、Podが頻繁に入れ替わる環境では効いてきます。IPアドレスが状態を持たなくなるためです。

HubbleとTetragon

HubbleはCilium上に構築された可視化基盤で、L3からL7までのフロー、サービス間の依存関係マップ、ドロップされたパケットとその理由を見られます。「なぜこの通信が落ちているのか」をポリシーの評価結果まで含めて追えるのが、汎用の監視ツールとの違いです。

Tetragonはセキュリティ可観測性とランタイム強制を担当します。プロセス実行やファイルアクセスをカーネル層で捉え、条件に応じて遮断まで行えます。

マネージドKubernetesでの採用状況

自前でCiliumを入れなくても、マネージドサービスのデータプレーンとして既に使っているケースがあります。GKEのDataplane V2はCiliumをベースにしており、2021年5月にGAになりました。AzureにもAKS向けのAzure CNI Powered by Ciliumがあります。ただしこれらはCiliumベースのデータプレーンを採用しているという意味で、利用者が直接触れる機能範囲はサービスごとに異なります。OSS版Ciliumのすべての機能がそのまま使えるわけではない点に注意してください。

つまり「Ciliumを入れる／入れない」の判断以前に、すでにeBPFデータプレーンの上でワークロードを動かしている現場が増えているということです。Kubernetesの運用に関わるなら、知識として素通りしにくくなってきました。

Cilium導入の判断基準｜効果が出やすいクラスタ・急がなくてよいクラスタ

結論として、規模とポリシー要件で判断します。「新しいから入れる」は運用負荷に見合いません。

判断フローと移行前チェック

次のどれかに当てはまるなら検討の価値があります。

• Serviceが数千規模に達し、kube-proxyのルール更新やレイテンシが問題になっている

• HTTPメソッド・パス単位、あるいはFQDN単位のポリシーを書きたい（標準のNetworkPolicyでは表現できない）

• 複数クラスタ間でServiceを解決したい

• ポリシーで落ちた通信の理由を、ログから追えるようにしたい

• サイドカーを増やさずにノード間暗号化やL7処理を入れたい

逆に、数十サービス規模の単一クラスタで、L3/L4のポリシーしか使っていないなら、既存CNIのままで困らないことが多いはずです。CNIの入れ替えはクラスタの土台を差し替える作業で、切り戻しも簡単ではありません。

移行前に確認する項目を挙げておきます。

1. ノードのカーネルバージョン（後述の要件表）

2. 必要なカーネルコンフィグが有効か（CONFIG_BPF_SYSCALL、CONFIG_BPF_JIT など）

3. kube-proxyを置き換えるのか併存させるのか

4. 既存のNetworkPolicyがそのまま移行できるか

5. 監視・ログ基盤との接続（Hubbleのメトリクスをどこに流すか）

6. 切り戻し手順とメンテナンスウィンドウ

他CNIとの選び分け

Calicoも広く使われており、eBPFデータプレーンのモードを持っています。選定は「どちらが優れているか」ではなく、必要な機能と運用体制の相性で決まります。L7ポリシーやCluster Mesh、Hubbleの可視化まで一体で欲しいならCilium、既存のCalico運用資産があり要件がL3/L4に収まるなら無理に動かさない、という判断が現実的です。マイクロサービス構成でサービス間の通信制御が主題なら、Istioのようなサービスメッシュとの役割分担も併せて検討することになります。

ミニFAQ：kube-proxyは必ず置き換えないといけませんか？

いいえ。Ciliumはkube-proxyを残したまま導入でき、置き換えは段階的に行えます。まずCNIとして入れてポリシーとHubbleを使い、安定してからkube-proxy replacementを有効にする進め方が、切り戻しの余地を残せます。

運用で詰まりやすいポイント

導入事例の記事では触れられにくい、実際にハマる箇所を挙げます。

カーネルバージョンとディストリビューションの差

最初にして最大の関門がこれです。Cilium公式のシステム要件では、全体の最低要件がLinuxカーネル5.10とされています（RHEL 8.10のように、ディストリ側でバックポートされた4.18系が該当する場合もあります）。機能ごとの要件はさらに上です。

オンプレのRHEL系や、更新が止まっているマネージドノードイメージでは、ここで計画が変わります。検証の一番最初にやるべきはuname -rの確認で、これを後回しにすると設計をやり直すことになりがちです。Linuxまわりの基礎知識が効いてくる場面でもあります。

「カーネルの中」をデバッグする難しさ

期待どおりに動かないとき、原因がポリシーの記述にあるのか、eBPFプログラムのロード失敗なのか、カーネル側の非対応なのかを切り分ける必要があります。ここは経験がものを言う領域です。

Cilium運用では、まずCLIでcilium statusとcilium monitorを実行して現状を確認し、Hubbleでドロップ理由を追い、それでも分からなければbpftoolでロード済みプログラムとマップを確認する、という順序になります。検証器のエラーメッセージは慣れるまで読みにくく、最初は面食らいます。

既存監視スタックとの重複

Hubbleを入れると通信の可視化ができますが、既にDatadogやPrometheusで似た指標を取っていることがあります。メトリクスが二重になり、コストとアラート運用が複雑になるパターンです。導入時にどの指標をどちらで持つかを決めておかないと、後から整理するのは骨が折れます。

フリーランスエンジニアの案件でeBPFはどう効くか

結論として、eBPFは単体でアサインされるスキルではなく、Kubernetes運用・SRE・可観測性基盤の案件で差がつく要素として現れます。

eBPF単独の募集はほとんどない

以下は、2026年9月時点で首都圏中心の主要フリーランスエージェント3〜5社の公開案件ページを確認した範囲での観測です。非公開案件や海外案件は含みません。この範囲では、「eBPFエンジニア」という職種名の募集は見当たりませんでした。実際に見かけるのは次のような形です。

• Kubernetes基盤の運用案件で、必須スキルに「CNI（Calico/Cilium等）の運用経験」が含まれる

• 可観測性基盤の構築案件で、「OpenTelemetryまたはeBPFベースの計装経験」が歓迎条件に入る

• セキュリティ寄りの案件で、「ランタイムセキュリティ（Falco等）の導入経験」が要件になる

公開案件数がまだ多くない領域なので、上記は観測ベースの目安として読んでください。案件の絶対数で言えば、SREやプラットフォームエンジニアの募集要件の一部として登場するケースが中心です。単価レンジそのものは職種側の相場に従うため、SREフリーランスの単価相場を参照するのが実態に近いはずです。

自分の経験でどのくらいの単価を狙えるか確認したい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を把握できます。単価を体系的に上げる考え方は「フリーランスエンジニアの単価相場と単価の上げ方」で整理しています。クラウド・インフラ系の募集そのものを見たい場合は案件一覧から探せます。

スキルシートでの書き方

「eBPFの知識あり」と書いても評価されません。商談で刺さるのは、規模・課題・打ち手・結果が入った1行です。

• 悪い例：Ciliumを使用

• 良い例：Serviceが約1,200あるEKSクラスタでkube-proxyをCilium eBPFに置き換え、Service更新時の反映遅延を解消。Hubbleでポリシー違反の可視化を導入

• 良い例：カーネル4.18のオンプレ環境でCilium導入を検証し、要件未達を理由にCalicoの継続を提案（判断の経緯もアピール材料になります）

導入して終わりではなく、入れなかった判断も実務経験として書けます。インフラエンジニアのスキルシートの書き方も参考にしてください。

学習ロードマップ｜どこまで知れば現場で通用するか

全員がeBPFプログラムを書けるようになる必要はありません。関わり方によって到達点が違います。

レベル別の到達目標

以下はKubernetesの基本操作（Pod・Service・Deploymentの理解とkubectlの日常利用）に慣れている人を前提とした目安です。前提知識や経験年数によって必要な時間は大きく変わります。

案件要件として現れるのはレベル2までがほとんどです。レベル3以上は差別化要素で、必須にされることは稀でした。

手を動かす順序

1. kindやminikubeでCiliumを入れたクラスタを1つ作る（半日程度）

2. NetworkPolicyを書いて、意図的に通信を落としHubbleで理由を確認する

3. kube-proxy replacementを有効にして、Serviceの挙動が変わらないことを確かめる

4. bpftraceの既成スクリプトを本番相当の環境で動かし、出力の読み方に慣れる

5. 余力があればCO-REのサンプルをビルドし、別カーネルのノードで動かしてみる

1から3までを通すと、案件の面談で聞かれる範囲はだいたい答えられるようになります。Kubernetes自体の体系的な理解が不足している場合は、先にCKA資格の出題範囲を埋めるほうが近道です。コンテナの基礎から確認したいならDockerの記事から入ってください。

まとめ

eBPFは、カーネルを書き換えずにその挙動を拡張する仕組みであり、Kubernetes環境ではCiliumというかたちで既に土台として動いています。フリーランスエンジニアにとっては、独立したスキルというよりKubernetes運用・SRE案件の中で差がつく要素です。

• eBPFの本質は「検証器で安全性を担保したうえでカーネル内にプログラムを差し込む」こと

• 用途はネットワーク・可観測性・セキュリティの3領域。代表格がCilium、Pixie、Falco

• CiliumはCNCF卒業プロジェクトで、GKEやAKSのデータプレーンとしても採用されている

• 導入判断の軸はService規模とポリシー要件。小規模クラスタなら急がなくてよい

• 最初に確認するのはカーネルバージョン。Ciliumの目安となる最低要件は5.10（ディストリのバックポート例外あり）

• 案件要件として現れるのは「Ciliumを構築・運用できる」レベルまでが中心

• スキルシートには規模と課題と結果を書く。導入を見送った判断も材料になる

次の一歩としては、kindでCiliumクラスタを1つ立て、NetworkPolicyで通信を落としてHubbleで理由を追うところまでをやってみてください。半日で、案件面談で聞かれる範囲の実感がつかめます。

なお、カーネル要件・対応機能・案件動向はいずれも更新されます。実際に構築する前に、最新の公式情報も必ず確認してください。

参照した一次情報は以下のとおりです。

• eBPFとは？eBPFへの入門と探求（ebpf.io）

• eBPF Applications Landscape（ebpf.io）

• Cilium公式サイト

• Cilium System Requirements（公式ドキュメント）

• CNCF Announces Cilium Graduation（CNCF）

• eBPF Foundation設立プレスリリース（the Linux Foundation）

• Azure CNI Powered by Cilium（Microsoft Learn）

• eBPF（CNCFクラウドネイティブ用語集）