eBPFが2026年のクラウドセキュリティを変える——Cilium・Tetragonでカーネルレベル可視化

Netflix、Google、Metaが本番環境で数百万ノード規模で採用しているカーネル技術がある。**eBPF（extended Berkeley Packet Filter）**だ。2026年のKubeCon Europe でも最大級のトピックとなったこの技術は、従来のIPtablesやサイドカープロキシに代わり、Kubernetesのネットワーキング・セキュリティ・オブザーバビリティの標準基盤になりつつある。

CNCFグラデュエーテッドプロジェクトであるCiliumと、そのランタイムセキュリティコンポーネントであるTetragonを中心に、eBPFが2026年のクラウドインフラにどんなインパクトをもたらしているのかを深掘りする。

eBPFとは何か——カーネルを書き換えずに拡張する技術

eBPFを一言で説明すると、Linuxカーネル内で安全にカスタムプログラムを実行できる仮想マシンだ。従来、カーネルの動作を変更するにはカーネルモジュールを書くかカーネル自体を再ビルドする必要があった。これはリスクが高く、開発サイクルも長い。

eBPFはこの制約を根本から覆す。ユーザー空間からコンパイルした小さなプログラムをカーネル内の「フックポイント」にアタッチするだけで、ネットワークパケットの処理、システムコールの監視、ファイルアクセスの追跡などをリアルタイムに行える。しかもカーネルの安定性を損なわないよう、eBPFプログラムはロード時にベリファイア（検証器）によって安全性がチェックされる。

以下の図は、従来のエージェント方式とeBPF方式のアーキテクチャの違い、およびカーネル内のフックポイントを示しています。

eBPFによるカーネルレベル可視化アーキテクチャ。従来のエージェント方式とeBPF方式の構造比較、Linuxカーネル内のフックポイント一覧

eBPFの主要なフックポイントは以下のとおりだ。

フックポイント	用途	代表的なユースケース
XDP（eXpress Data Path）	ネットワーク最早段階での処理	DDoS軽減、ロードバランシング
TC（Traffic Control）	パケットの分類・転送制御	Ciliumのネットワークポリシー
Kprobe / Kretprobe	カーネル関数の呼び出し追跡	パフォーマンス分析
Tracepoint	カーネルの静的トレースポイント	プロセス生成・終了の監視
LSM（Linux Security Module）	セキュリティポリシー強制	Tetragonのランタイム保護
cgroup / Socket	ソケット・cgroup単位の制御	Pod単位の帯域制限

この「カーネル内で動く」という特性が決定的に重要だ。従来の監視エージェントはユーザー空間で動作するため、カーネルとの間でコンテキストスイッチが発生し、パフォーマンスに影響を与えていた。eBPFはカーネル内で直接データを収集・処理するため、オーバーヘッドが桁違いに小さい。

Cilium——IPtablesを完全に置き換えるCNI

Ciliumは、eBPFをベースとしたKubernetes向けCNI（Container Network Interface）プラグインだ。Isovalent社（2024年にCiscoが買収）が開発を主導し、2023年にCNCFグラデュエーテッドプロジェクトに昇格した。

なぜIPtablesが限界なのか

従来のKubernetesネットワーキングは、IPtablesに大きく依存していた。ServiceやNetworkPolicyを作成するたびにIPtablesルールが追加される。問題は、IPtablesがルールを線形に評価することだ。つまり、ルール数が増えるほど処理時間がO(n)で増加する。数千のServiceと数万のPodが存在する大規模クラスタでは、IPtablesルールが数万行に膨れ上がり、ネットワークのレイテンシが深刻になる。

Ciliumはこの問題をeBPFのハッシュマップで解決する。ルールの評価はO(1)の定数時間で完了するため、クラスタの規模に関係なく一定のパフォーマンスを維持できる。Ciliumの公式ベンチマークでは、10,000ルール環境でIPtablesと比較して最大40%のスループット改善が報告されている。

Ciliumの主要機能

L3/L4ネットワークポリシー: Pod間のトラフィックをIPアドレス・ポート・プロトコルレベルで制御
L7フィルタリング: HTTP、gRPC、Kafkaなどアプリケーション層のプロトコルを解析し、APIエンドポイント単位でアクセス制御
サービスメッシュ（サイドカーレス）: Istioのようなサイドカープロキシ不要で、サービス間通信の暗号化（mTLS）とトラフィック管理を実現
マルチクラスタ接続（ClusterMesh）: 複数のKubernetesクラスタ間でPod同士を透過的に接続
Hubble: eBPFベースのネットワークオブザーバビリティツール。サービス間の通信フローをリアルタイムで可視化

特にサイドカーレスのサービスメッシュは大きなインパクトだ。従来のIstioやLinkerdでは、各Podにサイドカーコンテナ（Envoyプロキシなど）を注入する必要があった。これによりPod数が実質2倍になり、メモリ消費とレイテンシが増加する。Ciliumのサービスメッシュはカーネル内で処理するため、サイドカーのオーバーヘッドを完全に排除できる。

Tetragon——カーネルレベルのランタイムセキュリティ

Tetragonは、Ciliumと同じIsovalent（現Cisco）が開発するeBPFベースのランタイムセキュリティツールだ。2023年にCNCFサンドボックスプロジェクトとして採択され、2025年にインキュベーティングに昇格。2026年現在、エンタープライズ環境での採用が急拡大している。

Tetragonが解決する課題

従来のコンテナランタイムセキュリティツール（Falco、Sysdigなど）は、主にユーザー空間でシステムコールをフックしてイベントを収集していた。この方式には2つの大きな課題がある。

検知のみで防御できない: 不正な操作を「検知」することはできるが、その操作を「ブロック」するにはカーネルレベルでの介入が必要
パフォーマンスオーバーヘッド: ユーザー空間での処理はコンテキストスイッチのコストが大きい

Tetragonはこの両方を解決する。LSM（Linux Security Module）フックを使い、カーネル内でリアルタイムにポリシーを強制できる。例えば「特定のコンテナが /etc/shadow を読もうとしたら即座にブロック」といったルールを、カーネルレベルで実行する。検知からブロックまでのレイテンシは数マイクロ秒だ。

Tetragonの主要機能

機能	説明	ユースケース
プロセスイベント監視	プロセスの生成・終了・権限変更をリアルタイム追跡	不正プロセスの早期検知
ファイルアクセス監査	機密ファイルへの読み書きを監視・ブロック	データ漏洩防止
ネットワーク接続追跡	Pod発のネットワーク接続を送信先・プロトコル付きで記録	C2通信の検出
権限昇格検知	`setuid`、`setgid`、capability変更をカーネルレベルで検出	特権エスカレーション防止
ランタイムポリシー強制	検知だけでなく、カーネル内で即座にブロック	ゼロデイ攻撃の緩和

Tetragonポリシーの実例

Tetragonのポリシーは TracingPolicy というCRD（Custom Resource Definition）で定義する。以下は、コンテナ内から /etc/shadow へのアクセスを検知・ブロックするポリシーの例だ。

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-sensitive-file-access
spec:
  kprobes:
    - call: "fd_install"
      syscall: false
      args:
        - index: 1
          type: "file"
      selectors:
        - matchArgs:
            - index: 1
              operator: "Equal"
              values:
                - "/etc/shadow"
                - "/etc/passwd"
          matchActions:
            - action: Sigkill

このポリシーにより、対象ファイルを開こうとしたプロセスは即座にSIGKILLで終了させられる。従来のセキュリティツールでは「検知→アラート→人間が対応」というフローだったが、Tetragonはカーネル内で自動的にブロックするため、攻撃者の横展開を未然に防げる。

従来型セキュリティツールとの比較

eBPFベースのアプローチと従来型を比較すると、その優位性は明確だ。

項目	従来型（エージェント/サイドカー）	eBPF方式（Cilium / Tetragon）
動作レイヤー	ユーザー空間	カーネル空間
オーバーヘッド	高（コンテキストスイッチ発生）	極めて低（カーネル内完結）
IPtablesとの関係	IPtablesに依存	IPtablesを完全置換
サイドカー	必要（Envoy等）	不要
防御能力	検知のみ（ブロックには別途対策）	検知 + リアルタイムブロック
スケーラビリティ	ルール数に比例して劣化 O(n)	ルール数に依存しない O(1)
可視性	アプリ層のみ	カーネルからアプリ層まで全レイヤー
設定の複雑さ	高（サイドカー注入・iptablesルール管理）	中（CRDベースの宣言的定義）

以下の図は、Cilium + Tetragonのエコシステム全体像と、従来型との性能差を示しています。

Cilium + Tetragonエコシステム全体像。CNCFプロジェクトとしてのポジショニング、大規模採用企業、パフォーマンス比較

大規模採用の実績——Netflix、Google、Meta

eBPFの信頼性を裏付けるのは、世界最大規模のインフラを持つテック企業群が本番環境で採用しているという事実だ。

NetflixはCiliumを全面的に採用し、数十万のマイクロサービス間通信をeBPFで処理している。従来のIPtablesベースからの移行により、ネットワークレイテンシが平均15%改善されたと報告している。

GoogleはeBPFの主要な開発貢献者でもあり、GKE（Google Kubernetes Engine）でCiliumをファーストクラスのCNIとしてサポートしている。2025年後半には、GKE DataplaneV2としてCiliumベースのデータプレーンがデフォルトになった。

**Meta（旧Facebook）**は、eBPFをロードバランサー「Katran」や、パケット処理基盤で大規模に活用している。毎秒数十億パケットの処理をXDP（eXpress Data Path）で行い、従来のIPVS比で10倍以上のスループットを達成している。

Ciscoは2024年にIsovalent（Cilium/Tetragonの開発元）を買収し、自社のネットワーキング・セキュリティ製品群にeBPF技術を統合中だ。エンタープライズ向けサポートとSLAを提供することで、金融・医療などの規制産業での採用障壁を下げている。

KubeCon 2026での動向

2026年3月のKubeCon Europeでは、eBPF関連のセッションが過去最多を記録した。注目のトピックをまとめる。

Cilium 1.16のリリース: BGPコントロールプレーンの完全統合、WireGuardベースのPod間暗号化がGA（一般提供）に
Tetragonのインキュベーティング昇格後初のメジャーアップデート: Windowsノードの初期サポート、ポリシーのドライランモード追加
eBPF Foundation: Linux Foundationのサブプロジェクトとして、eBPFの標準化とクロスプラットフォーム対応（Windows eBPF）を推進
サイドカーレスメッシュの普及: Istioもサイドカーレスモード（ambient mesh）を強化しており、eBPFとの統合が進む

導入時の注意点と課題

eBPFは万能ではない。導入にあたって考慮すべき点もある。

カーネルバージョンの制約: eBPFの高度な機能はLinuxカーネル5.10以上が推奨される。Tetragonの一部機能（LSMフック）は5.13以上が必要だ。古いカーネルを使っている環境ではアップグレードが前提となる。

デバッグの難易度: カーネル内で動作するプログラムのデバッグは、ユーザー空間のアプリケーションほど簡単ではない。bpftoolやbpftraceといった専用ツールの習熟が必要だ。

学習コスト: eBPFプログラムの直接開発にはC言語とカーネルの知識が求められる。ただし、CiliumやTetragonを使う限りは、YAMLベースのポリシー定義で十分であり、eBPFの内部実装を理解する必要はない。

Windowsサポートの発展途上: Windows向けeBPF（eBPF for Windows）はMicrosoftが開発中だが、Linux版と比べると機能カバレッジに差がある。ハイブリッド環境ではLinuxノード優先の設計が現実的だ。

日本での導入状況と展望

日本のエンタープライズ環境でも、eBPFへの関心は急速に高まっている。特にメガバンクや大手SIerが検証フェーズに入っており、2026年後半から本番導入が本格化する見込みだ。

背景には、金融庁の「クラウドリスクガイドライン」改訂（2025年12月）がある。コンテナ環境におけるランタイムセキュリティの実装が推奨事項に加わり、Tetragonのようなカーネルレベルの防御機構が注目されている。

また、日本の主要パブリッククラウドの状況も追い風だ。

GKE: CiliumベースのDataplaneV2がデフォルト。日本リージョン（asia-northeast1）でも利用可能
EKS: Ciliumをアドオンとしてサポート。Amazon VPC CNIとの併用も可能
AKS: Azure CNI Powered by CiliumがGA。東日本リージョンで利用可能

Dockerコンテナ環境を本番運用しているチームにとって、eBPFベースのセキュリティ・オブザーバビリティは次のステップとして検討すべき技術だ。

料金体系

Cilium・Tetragon自体はオープンソースであり、無料で利用できる。エンタープライズサポートが必要な場合の料金体系は以下のとおりだ。

プラン	料金	内容
Cilium OSS	無料	コミュニティサポート
Isovalent Enterprise（Cisco）	要問い合わせ（年額$50,000〜が目安、約750万円〜）	24/7サポート・SLA・追加機能
GKE DataplaneV2	GKE料金に含まれる	Ciliumベース、Googleサポート
Azure CNI Powered by Cilium	AKS料金に含まれる	Ciliumベース、Microsoftサポート

まとめ——eBPFは「知っておくべき」から「使うべき」へ

eBPFは2026年、もはや先進的な実験技術ではない。Netflix、Google、Metaが本番で稼働させ、CNCFグラデュエーテッドプロジェクトとして成熟し、主要パブリッククラウドがネイティブサポートを提供している。IPtablesとサイドカープロキシの時代は終わりに向かっている。

具体的なアクションステップを以下に示す。

現状評価: 自社のKubernetes環境でIPtablesルール数と、サイドカーによるリソース消費を計測する。Cilium移行によるコスト削減効果を試算する
PoC実施: ステージング環境でCiliumをCNIとして導入し、Hubbleでネットワークフローの可視化を体験する。既存のNetworkPolicyとの互換性を検証する
Tetragonの段階的導入: まず監視モード（ブロックなし）でTetragonを本番に投入し、TracingPolicyでファイルアクセスやプロセス実行のベースラインを把握する
段階的なポリシー強制: 十分なデータが蓄積されたら、ブロックモードを有効化し、ランタイムセキュリティを強化する
チーム教育: eBPFの基礎知識を全インフラエンジニアに共有する。Isovalent（Cisco）のeBPFトレーニング（無料オンライン版あり）が最も体系的だ

カーネルレベルの可視性とセキュリティ強制は、クラウドネイティブセキュリティの次のスタンダードだ。早期に取り組むことで、セキュリティとパフォーマンスの両方で競争優位を築ける。