公開2026.09.02更新2026.10.20 セキュリティ

Falcoとは？ランタイム脅威検知の仕組みとルール運用・誤検知の抑え方を解説

Q: Falcoの誤検知が多いときはどう対処しますか？

ルール単位の exceptions に除外条件を書くのが基本です。 condition を直接書き換えると既定ルールの更新と衝突し、除外の理由も読めなくなります。手順としては、数週間アラートを溜めて件数上位のルールを洗い、運用担当と正規の動作か確認したものだけを除外し、理由と確認日を残す流れです。件数だけを見て消すと本物の侵害を静かに落とす運用になります。

Falco（ファルコ）は、Linuxカーネルが流すイベントを読み取り、コンテナやホストで「いま起きている」不審な挙動を検知するオープンソースのランタイムセキュリティエンジンです。イメージスキャンや設定監査が事前に穴を潰す道具である一方、Falcoは実行中のプロセスがどのファイルを開き、どこへ通信し、どんなシェルを起こしたのかを見張ります。この記事では、カーネルイベントの取得方法、検知ルールの書き方と配り方、現場でいちばん詰まる誤検知の抑え方、そして採用と見送りの判断軸を、公式ドキュメントとリリースの一次情報にもとづいて整理します。

まとめ：Falcoはカーネルイベントから実行中の脅威を検知する

FalcoはCNCFのGraduatedプロジェクト（2024年2月29日に卒業）で、システムコールとKubernetesの監査イベントを入力に、ルールと一致した挙動をアラートとして吐き出すエンジンです。中身は3層に分かれます。カーネルからイベントを取るドライバ、条件と出力を書いた検知ルール、アラートを通知先やSIEMへ流す出力経路です。この3層のどこを自社で握るかを決めれば、導入設計はほぼ固まります。

既定のドライバは modern eBPF probe で、CO-REによりカーネルごとのビルドや配布が要りません。ルールはruleとconditionとoutputとpriorityで書き、macroとlistで共通化し、exceptionsで自社の正規運用を除外します。運用の山場は導入ではなく、この除外設計です。既定ルールをそのまま流すとアラートが溢れ、当番が読まなくなって検知そのものが死にます。

採用の線引きははっきりしています。実行時の証跡を自前で持つ必要があり、ノードにDaemonSetを常駐させて運用できる体制があるなら候補に入ります。マネージド側の保護で不足が出ていない段階なら、継続運用のコストが効き目を上回りがちです。以下では仕組み、ルール、出力、誤検知対策、役割分担、採用と見送りの条件を順に見ます。

Falcoがカーネルイベントからランタイム脅威を検知する位置づけ

まずFalcoがスタックのどこに入るのかを押さえます。コンテナはホストのカーネルを共有して動くため、コンテナ内のプロセスがシステムコールを呼べば痕跡はホスト側に現れるという前提です。Falcoはこの一点に賭けた設計で、アプリにエージェントを埋め込まず、コンテナの外側から全ワークロードの挙動を横断的に見ます。上位の判断軸はKubernetesが自社に必要かの判断で扱っています。

システムコールを取得するドライバとしてのmodern eBPF probe

Falcoがイベントを取る口は2種類です。既定は modern eBPF probe で、設定ファイルのengine.kindにmodern_ebpfを指定します。もう一方が kernel module で、カーネル3.10以上という広い互換性を持つ代わりに、フル権限での動作が前提になります。modern eBPF probeはユーザー空間バイナリに同梱され、eBPFのCO-RE（Compile Once Run Everywhere）によってカーネル版数ごとのビルドが不要です。ドライバ配布やDKMSの面倒が消える点が運用側の最大の差分です。eBPF自体の成り立ちはeBPFがLinuxカーネルで動く仕組みで詳しく解説しています。

権限も両者で違います。modern eBPF probeは最小権限モードで動かせ、必要なLinux capabilityは限られた組み合わせに収まる一方、kernel moduleはcapabilityでの絞り込みができません。監査でコンテナの特権を問われる環境なら、この差はそのまま設計判断になります。

CNCF Graduatedプロジェクトとしての開発体制と提供範囲

FalcoはSysdigが立ち上げ、2018年10月にCNCFへ採択、2020年1月にIncubating、2024年2月にGraduatedへ昇格しました。段位は成熟度の最上位で、脱ベンダー性とリリース運用の安定性が一定の水準に達したことを示します。提供範囲は検知までで、プロセスを止めるのかPodを隔離するのかは別のコンポーネントや運用フローに委ねる分担です。「入れれば止まる」と期待すると設計をやり直します。

Falcoの検知ルールを条件と出力と優先度で組み立てる仕組み

Falcoの本体価値はルール言語にあります。カーネルイベントの生の羅列を、人が読める「脅威の記述」に変換する層です。ここを自社の運用語彙で書けるかどうかが、導入後に検知が育つかどうかを決めます。

ruleとconditionとoutputで検知内容を記述する書式

ルールの必須要素は5つです。一意な名前のrule、イベントを絞る条件式のcondition、何を検知するのかを説明するdesc、一致したときに出す文のoutput、重大度を示すpriorityです。priorityにはEMERGENCY・ALERT・CRITICAL・ERROR・WARNING・NOTICE・INFORMATIONAL・DEBUGの8段階が用意されています。公式は割り当ての目安も示しており、状態を書き換える検知はERROR、許可のない読み取りはWARNING、想定外の動作はNOTICEです。

実際のルールは次のような形になります。条件の書き味を掴むには、既定ルールを1本読み解くのが最短です。

- list: sensitive_files
  items: ["/etc/shadow", "/etc/sudoers"]

- macro: open_read
  condition: evt.type in (open, openat) and evt.is_open_read=true

- rule: Read sensitive file
  desc: 機微なファイルの読み取りを検知する
  condition: open_read and fd.name in (sensitive_files)
  output: "機微ファイル読取 (user=%user.name file=%fd.name container=%container.name)"
  priority: WARNING
  tags: [filesystem, mitre_credential_access]

outputのなかの%で始まる部分はフィールド参照で、実際のイベントの値に置き換わります。ここに含めるフィールドの選び方が事故対応の速さを左右する点は見落としがちです。ユーザー名とコンテナ名とコマンドラインが入っていれば当番はすぐ動けますが、プロセスIDだけでは調査に戻る手間が増えます。

macroとlistで条件を共通化して規則を保守しやすくする書き方

macroは条件式の共通部分を名前付きで切り出す仕組みで、先に定義したマクロを別のマクロから参照できます。listはルールやマクロに差し込む項目の集合で、あとに定義したものも参照できる仕様です。この2つを使い分けると、ルール本体は「マクロの組み合わせ」だけになり、条件の意味が読み取れる状態を保てます。

自社で書くときの原則は1つです。イベント種別やフィールドの生条件はマクロへ、環境固有の値（許容イメージ名、除外パス、管理ユーザー）はリストへ寄せます。環境が増えても書き換えるのはリストだけになり、ルール本体をコピーして分岐させる事態を避けられます。既定ルールは直接編集せず、自社ルールを別ファイルに置いて上書きする形が安全です。

アラート出力先とSIEM連携でFalcoの検知を運用に乗せる経路

検知が書けても、届かなければ意味がありません。Falcoは出力経路を設定ファイルで選べる作りになっており、どこに流すかで運用の形が変わります。

標準出力とファイルとsyslogとHTTPの出力チャネルの使い分け

本体が持つ出力先は、標準出力、ファイル、syslog、外部プログラムの実行、HTTPエンドポイントの5つです。Kubernetes上でDaemonSetとして動かす構成なら、標準出力に出してログ収集基盤へ載せるのがいちばん素直な選択になります。ホストへ直接入れる構成ならsyslogに寄せ、既存のログ転送へ統合する手も有効です。HTTPエンドポイントは後述の転送プロキシへ渡す前提で使います。

Falcosidekickを挟んで通知先とSIEMへ振り分ける構成の作り方

アラートを複数の宛先へ振り分けたいときは、Falcosidekickを挟みます。FalcoのHTTP出力をFalcosidekickへ向け、そこからチャットやメール、オブジェクトストレージ、SIEMやFaaSへ配る構成です。連携先は50を超える数が用意されており、宛先ごとに最低の重大度を指定して流量を絞れます。

設計の型としては、CRITICAL以上は当番のチャットへ即時、WARNING以下はログ基盤に貯めて後追い、という二段構えが扱いやすい形です。全部をチャットに流すと通知が埋もれ、全部をログに貯めると気づくのが遅れます。集約先の選び方そのものはSIEMの仕組みと製品選定の考え方で整理しています。

falcoctlでルールセットを配布して版を管理する運用の流れ

ルールを手で配ると、ノードごとに中身が食い違って原因究明ができなくなります。これを避けるのがfalcoctlで、ルールファイルをアーティファクトとして取得・更新する経路を提供します。自社ルールをリポジトリで管理し、レビューを通して配れば、変更の履歴が追える状態です。

あわせて決めたいのが、ルール更新と本体更新を分けることです。同じ作業にまとめると、アラートが変わった原因がルールなのか版なのか切り分けられません。CI工程で不審な挙動を止める話はCI/CDにランタイム脅威検知を組み込む手順で扱っており、実行時のFalcoとは工程を分けて併用します。

誤検知を抑えるためにFalcoのルールを現場へ合わせる調整手順

ここが導入の成否を分けます。Falcoの既定ルールは広く網を張る設計なので、自社の正規運用が引っかかるのは異常ではなく前提です。放置するとアラート疲れが起き、本物の検知が埋もれます。

exceptionsで正規の運用を除外して騒がしさを下げる手順

Falcoにはルール単位のexceptionsがあり、「このルールはアラートを出さない」条件を宣言できます。除外はここに書くのが基本で、conditionを直接書き換えて否定条件を足すやり方は避けてください。理由は2つあります。既定ルール更新時に手元の改変が衝突すること、そして除外の理由がルール本体に埋もれて読めなくなることです。

手順としては、まず1〜2週間ほどアラートを溜めて、件数の多いルールと発生源を数えます。次に上位から順に、業務上正規のものかを運用担当と突き合わせる工程です。正規と確認できたものだけをexceptionsへ落とし、理由と確認日をコメントに残します。この確認を飛ばして件数だけで消すと、本物の侵害を静かに落とす運用になるため省けません。

priorityとタグで通知量を段階化して当番の負荷を抑える設計

除外だけで静かにするのは限界があります。もう一方の手が、重大度とタグによる段階化です。自社ルールのpriorityを実際の対応方針に合わせて振り直し、即時対応するものと日次で見るものを分けます。タグは検知の種類で付け、出力先の絞り込み条件に使います。

数字で線を引くと運用が安定します。「即時通知は1日あたり数件までに収まる状態を維持する」と決めておけば、それを超えたときがルール見直しの合図です。逆に即時通知が数十件出る状態を数か月続けると、当番はチャットを開かなくなり、検知基盤としては機能を失います。

FalcoとCSPM・SIEM・脆弱性診断の役割分担を整理した見取り図

Falcoを単体で評価すると、範囲を誤ります。クラウドネイティブのセキュリティは複数の道具が層をなしており、Falcoはそのうち実行時の1層です。ここを整理しておくと、どこまでをFalcoに任せるかが決まります。

設定監査を担うCSPMと実行時検知のFalcoが見る対象の違い

CSPMはクラウドの設定を読み、公開バケットや広すぎる権限といった「状態の誤り」を見つけます。対象は構成情報で、実行中のプロセスは見ません。Falcoはその反対で、設定が正しくても起きうる侵害後の挙動を捉えます。両者は時間軸の前後で補い合う関係です。設定側の詳細はCSPMによる設定ミス検出の仕組みにまとめています。

この層の道具をまとめて調達する考え方はクラウドネイティブ保護を1つに束ねる仕組みで扱っています。以下に主な道具の担当範囲を並べます。

道具	見る対象	効く時点
Falco	システムコールと挙動	実行中
CSPM	クラウドの設定情報	実行前と定期
イメージスキャン	依存パッケージの欠陥	ビルド時
SIEM	各種ログの集約と相関	検知後の分析
脆弱性診断	外部からの攻撃可能性	公開前と定期

SIEMへ集約する前提でFalcoに任せる範囲を線引きする考え方

Falcoは単体でも通知できますが、他のログとの相関はSIEM側の仕事です。Falcoに任せるのはノード上の挙動を粒度高く拾ってイベント化するところまでと割り切ると、設計が素直になります。アプリのログやクラウドの監査ログとつなぎ合わせた判断をルールで表現しようとすると、条件が複雑になって保守が破綻します。

実装の順序としては、まずアラートをSIEMやログ基盤へ確実に届ける経路を作り、そのうえでルールを育てます。届く先が決まらないままルールを増やすと、出したアラートが誰にも読まれないまま溜まります。実行時の証跡が手薄だと感じる段階なら、外部からの攻撃可能性の確認と合わせて脆弱性診断・セキュリティ診断で現状の穴を洗い出してから検知の設計に入る順序が無理がありません。

Falcoの採用が見合う条件と過剰投資になる見送り場面の線引き

ここは判断を言い切ります。Falcoは中身の見える良い道具ですが、すべてのKubernetes環境に要るわけではありません。要件から見て採る場面と、見送るべき場面を条件付きで分けます。

Falcoの導入が見合うクラスタ規模と監査要件の具体的な条件

採用が見合うのは、次のいずれかに当てはまるときです。第一に、監査や契約で実行時の挙動の証跡を求められる場合。第二に、外部のコードやサードパーティのイメージを本番で動かしており、ビルド時の検査だけでは侵害後の動きを追えない場合。第三に、複数チームが同じクラスタに載っており、権限昇格やシェル起動を横断的に検知したい場合です。いずれもイメージスキャンや設定監査では手当てできず、カーネル側から見る設計が効きます。

あわせて体制の条件があります。ノードにDaemonSetを常駐させ、カーネル版数とドライバの前提を継続して面倒みられること。アラートを毎日読み、除外の妥当性を確認できる人が置けること。この2つが欠けるなら、入れても検知は育ちません。

マネージドの保護で足りる段階でFalcoが過剰投資になる条件

逆に、数ノードの単一クラスタで、動かしているのが自社製のアプリだけ、外部監査の要求もなく、クラウド側のマネージド保護で不足が出ていないなら、導入は過剰投資になりやすいと考えます。理由はコストの形です。導入自体はHelmで短時間に終わりますが、その後にルールの除外設計、アラートの当番、本体とドライバのアップグレード検証が継続して乗ります。この継続分を払える体制がない段階で入れると、既定ルールのまま鳴り続けて誰も見ないアラートだけが残ります。

この場合の順序は、まずビルド時のイメージスキャンと設定監査で事前に潰せる穴を確実に閉じることです。実行時に見えていないものが具体的な課題として出てきた段階で進むほうが、投資の効き方がはっきりします。先回りして入れる価値が出るのは、上に挙げた条件に当てはまるときだけです。

Falco導入前に確認するカーネル前提とマネージドK8sの制約

最後に、導入前に潰しておく前提条件を整理します。ここを飛ばすと、入れてから起動しないという事態になります。

modern eBPF probeが求めるBTFとリングバッファの前提

modern eBPF probeが要求するのは、カーネルのBPFリングバッファ対応と、BTF（BPF Type Format）の公開の2点です。目安は5.8以上とされますが、必要な機能が古いカーネルへバックポートされている場合もあり、版数だけで断定はできません。導入前に対象ノードでBTFの公開状況を確認するのが確実です。要件を満たさないノードが残るなら、そこだけkernel moduleに切り替える構成も取れます。

マネージドKubernetesでは、カーネルを自由に選べない点が制約になります。ノードイメージの版はサービス側の更新に従うため、Falcoの前提と更新計画を突き合わせておく必要があります。特権コンテナやhostPIDの許可がポリシーで塞がれている環境では、DaemonSetの配置そのものが通らないこともあるため、先に確認してください。

Falco 0.44系で廃止されたドライバと出力機能の版差の注意点

版差の注意点も押さえておきます。0.44系（0.44.0が2026年5月、0.44.1が同年6月のリリース）では、レガシーeBPFプローブ、gVisorエンジン、gRPC出力のサポートが外れました。手元の構築手順や社内Wikiがそれ以前の版を前提に書かれている場合、レガシーeBPFプローブの指定やgRPC経由の連携がそのままでは通りません。移行先はドライバなら modern eBPF probe か kernel module、出力ならHTTPエンドポイントとFalcosidekickの組み合わせになります。

既存環境を上げる前に「どのドライバで動いているか」と「どの出力チャネルを使っているか」を実機で確認してから版を選んでください。ここに挙げた内容も2026年9月時点の公式リリースを基準にした整理なので、導入時は各版のリリースノートで確認してください。

よくある質問

Falcoの検討で挙がる質問を、実装の観点からまとめます。

Falcoとは何のためのソフトウェアですか？

コンテナやホストの実行中の挙動を、Linuxカーネルのイベントから検知するランタイムセキュリティエンジンです。システムコールやKubernetesの監査イベントを入力に、ルールと一致した動きをアラートとして出します。CNCFのGraduatedプロジェクトとして開発が続いており、検知までを担って遮断は本体の外に置く分担になっています。

FalcoとCrowdStrike Falconは同じものですか？

別の製品です。ここで扱うFalcoはCNCFのオープンソースで、名前が似ているCrowdStrike Falconは商用のエンドポイント保護製品です。検索や社内の資料で混同すると前提が食い違うため、文脈でどちらを指しているか確かめてください。Falcoの一次情報はfalco.orgとfalcosecurityのリポジトリにあります。

Falcoは不審な挙動を自動で止めてくれますか？

本体の役割は検知とアラートまでで、プロセスの停止やPodの隔離は含みません。自動対処が要る場合は、アラートを受けて動く別のコンポーネントや運用フローを組み合わせます。まず検知だけを回して、通知の量と精度が運用に耐える状態を作ってから自動対処へ進む順序が安全です。

Falcoの誤検知が多いときはどう対処しますか？

ルール単位のexceptionsに除外条件を書くのが基本です。conditionを直接書き換えると既定ルールの更新と衝突し、除外の理由も読めなくなります。手順としては、数週間アラートを溜めて件数上位のルールを洗い、運用担当と正規の動作か確認したものだけを除外し、理由と確認日を残す流れです。件数だけを見て消すと本物の侵害を静かに落とす運用になります。

FalcoとeBPFはどういう関係にありますか？

eBPFはカーネルを再ビルドせずに検証済みのプログラムをカーネル内で動かす仕組みで、Falcoはそれを使ってシステムコールを取得します。既定の modern eBPF probe はCO-REに対応しており、カーネル版数ごとのビルドや配布が要りません。eBPFが使えない古いカーネルでは、代わりにkernel moduleで動かす選択肢が残されています。

eBPFとは？Linuxカーネルを拡張する仕組みと可観測性・ネットワーク：Falcoがイベント取得に使うeBPFの動作原理を、カーネルの観点から詳しく解説しています。
GitHub Actionsにtracee-actionを統合する方法｜CI/CDに脅威検知：CI工程側でランタイム脅威検知を回す手順を扱い、実行時のFalcoとの併用形を示しています。
CSPMとは？設定ミス検出の仕組みとCNAPPとの違い・導入判断：Falcoが見ない「設定の誤り」を担う層の仕組みと導入判断を整理しています。
CNAPとは？クラウドネイティブ保護を1つに束ねる仕組みと採用判断：実行時検知や設定監査をまとめて調達する考え方と、その採用判断を解説しています。
SIEMとは？仕組み・機能とEDR/XDR/SOARの違い・製品選定：Falcoのアラートを集約して相関分析する側の仕組みと、製品選定の軸をまとめています。
コンテナオーケストレーションとは？Kubernetesの役割と判断：Falcoが守る対象のKubernetes基盤を、自社に必要かの判断軸から解説しています。
tracee-actionとは？GitHub ActionsにTraceeを組み込む手順と開発停止後の代替