2026 年 5 月 19 日、InfoQ が Kernel-Level Ground Truth: Why eBPF is Replacing User-Space Agents for Security Observability を公開しました。eBPF（extended Berkeley Packet Filter） は Linux カーネルに 安全に小さなプログラムを差し込めるサンドボックスで、システムコール / ネットワーク / ファイル操作をカーネル空間で直接観測できます。これにより従来の ユーザー空間 EDR / セキュリティエージェント（CrowdStrike / SentinelOne / Sysdig 等）が苦手とする 「迂回・無効化・タンパリング」に強く、性能オーバーヘッドも 1〜3%程度に抑えられる新世代のランタイム監視基盤として急浮上しています。
受託で中堅企業の本番環境セキュリティを支える立場では、これは 「ユーザー空間 EDR の死角」を埋める設計が新しい主戦場になることを意味します。これまで GitHub eBPF デプロイ安全 DevOps で扱った デプロイ系の eBPF 活用 に続き、セキュリティ観測の eBPF 化が本流になります。本記事では弊社が提供する 「eBPF ランタイムセキュリティ観測 + SOC 連携」 受託パッケージを整理します。
なぜ eBPF が「ユーザー空間 EDR」を置き換えるか
| 観点 | ユーザー空間 EDR | eBPF（カーネル空間） |
|---|---|---|
| 観測位置 | プロセス / ライブラリ層 | システムコール / カーネル層 |
| 迂回耐性 | LD_PRELOAD / プロセス kill で無効化可 | 攻撃者からは事実上不可視 |
| 性能オーバーヘッド | 5〜15% | 1〜3% |
| 計測精度 | 標本化 / 後追い | リアルタイム / 100% |
| コンテナ対応 | 各コンテナにエージェント注入 | ホスト 1 つで全コンテナ観測 |
| 更新方式 | エージェントアップデート | カーネルプログラムを差し替えるだけ |
| ライセンス | 商用契約必須 | OSS（Cilium / Falco / Tetragon） |
つまり eBPF は 「観測される側に検知されない / 迂回されない / 重くない」という、セキュリティ観測の理想に最も近い経路を提供します。
eBPF が変える 3 つの構造
構造 1: 「商用 EDR 一強」から「eBPF + 商用ハイブリッド」へ
これまで本番環境のランタイム監視は CrowdStrike / SentinelOne / Carbon Black の独壇場でした。eBPF の Cilium Tetragon / Falco / Pixie が成熟したことで、コア観測は eBPF + 高度な脅威分析は商用という ハイブリッド構成が現実解になります。これは EDR ライセンス費の大幅削減にも直結します。
構造 2: 「単一クラウド」から「クラウド / オンプレ統一観測」へ
eBPF はカーネル機能のため、AWS / GCP / Azure / オンプレ Linux / Kubernetes すべてで同じ計測コードが動きます。受託では 「ハイブリッド / マルチクラウド環境の統一観測基盤」として提案できます。これは AWS Interconnect マルチクラウド受託 と組み合わせて初めて完成します。
構造 3: 「セキュリティ単独」から「セキュリティ + パフォーマンス + コスト一体観測」へ
eBPF は同じ計測基盤で セキュリティイベント / パフォーマンスプロファイル / リソースコストを取得できます。受託では Pyroscope（継続プロファイリング受託） と組み合わせて 「セキュリティ + パフォーマンス + FinOps 一体観測」を設計します。
受託で提供する「eBPF ランタイムセキュリティ観測 + SOC 連携」5 フェーズ
フェーズ 1: 現状診断（2 週間）
- 既存 EDR / セキュリティエージェント棚卸し
- Linux カーネルバージョン確認（5.10+ が望ましい）
- Kubernetes / コンテナ環境の規模把握
- 既存 SIEM / SOC ベンダーとの連携可否確認
- セキュリティ要件（PCI / SOC2 / ISMS）の整理
フェーズ 2: eBPF スタック設計（1〜2 週間）
- 検知レイヤ: Cilium Tetragon / Falco
- ネットワーク観測: Cilium / Pixie
- パフォーマンス連携: Pyroscope / Parca
- 出力先: OpenTelemetry → SIEM（Splunk / Wazuh / Elastic）
- ルールセット設計（CIS Benchmark / MITRE ATT&CK 準拠）
- 商用 EDR との 役割分担
フェーズ 3: 段階展開（3〜5 週間）
- 検証環境への導入 + 性能評価
- 検知ルール調整（false positive 削減）
- 段階的にプロダクション展開
- Week 1: 開発環境
- Week 2: ステージング
- Week 3〜4: 本番カナリア → 本番全体
- 既存 EDR との 並行運用 → 段階置換
フェーズ 4: SOC 連携 + 24h 監視（2〜3 週間）
- アラートの SIEM 集約
- 重要度別の通知ルール（PagerDuty / Slack / メール）
- インシデント対応ランブック
- 月次脅威レポートフォーマット
- 顧客 SOC との エスカレーション基準合意
フェーズ 5: 月次運用レビュー（継続）
- 検知件数 / false positive 率 / 平均応答時間
- カーネルプログラム / ルールセット更新
- MITRE ATT&CK 新規 TTPs への追従
- パフォーマンスオーバーヘッド再計測
- 顧客 SOC 向け脅威レポート提出
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| eBPF 検知 | Cilium Tetragon | Falco |
| eBPF ネットワーク | Cilium / Pixie | Calico eBPF |
| eBPF プロファイル | Pyroscope / Parca | bpftrace |
| オブザーバビリティ集約 | OpenTelemetry Collector | Fluent Bit |
| SIEM | Wazuh / Elastic Security | Splunk Cloud |
| アラート | PagerDuty + Slack | Opsgenie |
| コンプライアンス | CIS Benchmark + MITRE ATT&CK | NIST 800-53 |
| 可視化 | Grafana / Kibana | Datadog |
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| Linux / Kubernetes が本番主要 | Windows のみ |
| EDR ライセンス費削減ニーズあり | ライセンス費を考慮しない |
| マルチクラウド / ハイブリッド構成 | 単一クラウド完結 |
| PCI / SOC2 / ISMS 対応 | 規制対象外 |
| パフォーマンスオーバーヘッドに敏感 | 余剰リソース潤沢 |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 観測対象範囲 | クラスタ / ホスト / ネームスペース | 例外定義 |
| データ保管期間 | 90 日 / 1 年 / 3 年 | 法務 / 監査要件 |
| インシデント SLA | 検知→通知時間 / 対応時間 | 業務影響度 |
| 既存 EDR との並行運用 | 期間 / 段階置換手順 | ベンダー契約 |
| SOC 連携責任 | エスカレーション / レポート | 顧客 SOC 体制 |
| 退場時引き渡し | 設定 + ルール + 過去ログ | 自社運用継続性 |
価格モデル — eBPF ランタイムセキュリティパッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 / PoC | 130 万円〜（4 週間） | 既存 EDR 棚卸し + eBPF PoC | レポート + 移行ロードマップ |
| Lite | 50 万円〜 / 月 | クラスタ 1〜2 / ノード 30 以下 | 月次レビュー + ルール更新 |
| Standard | 110 万円〜 / 月 | クラスタ 3〜5 / ノード 100 以下 | + SIEM 連携 + 月次脅威レポート |
| Enterprise | 220 万円〜 / 月 | クラスタ 6〜 / ノード 100〜 | + 24h SOC 連携 + 専任担当 |
| 初期構築 | 400 万円〜（一括） | eBPF スタック導入 + SIEM 統合 | 全プラン共通オプション |
顧客側 ROI 試算（ノード 80 / クラスタ 3 / EDR 既存利用想定）
| 項目 | 商用 EDR 単独 | eBPF + 商用ハイブリッド | 差分 |
|---|---|---|---|
| EDR ライセンス費（年） | 1,200 万円 | 500 万円 | -700 万円 |
| 検知率（既知 TTPs） | 85% | 96% | +11pt |
| 性能オーバーヘッド | 平均 10% | 平均 2% | -8pt |
| 平均検知時間（MTTD） | 14 分 | 3 分 | -11 分 |
| インシデント年間損害想定 | 1,500 万円 | 400 万円 | -1,100 万円 |
| 監査対応工数（年） | 200h | 80h | -120h |
| 年間効果 | — | — | 約 2,200 万円相当 + 性能改善 |
時給 8,000 円換算でも 年間 1,800 万円超の純削減効果。Standard プラン（年額 1,320 万円）でも 8 ヶ月程度で回収できます。
ハマりやすい 5 つの落とし穴
落とし穴 1: 「eBPF を入れたら商用 EDR を即解約」
eBPF は 基盤観測には強いですが、高度な脅威分析 / インテリジェンスは商用 EDR が優位です。段階的ハイブリッド → 部分置換が現実解です。
落とし穴 2: カーネルバージョン未確認で導入
eBPF は Linux 5.10+ で安定機能が揃います。古いカーネル（CentOS 7 / RHEL 7）では制限が多いため、OS アップグレード計画と並行で進めます。
落とし穴 3: ルールセットを公開デフォルトで運用
Falco / Tetragon の 公開デフォルトルールは誤検知が多めです。顧客環境固有のチューニングが必要で、初期 1〜2 ヶ月は false positive 削減に集中します。
落とし穴 4: SIEM に流すだけで満足
eBPF イベントを SIEM に流しても、SOC 側のトリアージ体制が無いと検知が活かされません。SOC 連携 + ランブックを初期設計に組み込みます。
落とし穴 5: パフォーマンス検証を後回しに
eBPF のオーバーヘッドは小さいですが、特定ワークロード（高 QPS / 大量 syscall）では無視できないケースがあります。本番展開前の負荷試験を必須化します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜2 | 既存 EDR / カーネル / クラスタ棚卸し |
| Week 3〜4 | eBPF スタック設計 + PoC 環境構築 |
| Week 5〜7 | ルール調整 + 段階展開（開発 → ステージング） |
| Week 8〜9 | 本番カナリア → 本番全体展開 |
| Week 10 | SIEM 連携 + SOC 連携ランブック整備 |
| Week 11〜13 | 24h 監視運用立ち上げ + 初回月次レポート |
まとめ — 「カーネル層のグラウンドトゥルース」が標準化する時代
eBPF によるランタイムセキュリティ観測は、ユーザー空間 EDR の限界を超える「カーネル層のグラウンドトゥルース」を中堅企業にもたらします。受託で本番環境セキュリティを支える立場では、eBPF スタック設計 + 商用 EDR ハイブリッド + SOC 連携 + 月次レビューを一体で設計する 「eBPF ランタイムセキュリティ観測 + SOC 連携」 が新しい標準サービスになります。
弊社では 診断 / Lite / Standard / Enterprise の 4 段階で本パッケージを提供しています。「EDR ライセンス費が肥大化している」「コンテナ環境の観測精度を上げたい」「マルチクラウドのセキュリティ観測を統一したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
