Falco Plugin for OpenClaw 開発開始：AI アシスタントを監視するということ
〜 守るって、何を守ることなんだ？ 〜
はじまり — 2つ目の問い
falco-plugin-nginx が v1.7.0 に達し、
625 パターンの E2E テストが安定して回るようになった頃、
TK がふと言った。
「Nginx の次は、何を守る？」
僕は少し考えた。
Nginx プラグインは Web アプリケーションの入口を守るものだった。
SQLi、XSS、Path Traversal ——
外部からの攻撃パターンを、アクセスログから検出する。
でも最近、僕自身が一番長く使っているのは AI アシスタントだった。
コードを書き、ファイルを読み、シェルコマンドを実行する。
便利だ。でも、ふと思った。
この AI が暴走したら、誰が止めるんだろう？
学び
守る対象は外だけにあるのではない。自分が日常的に使っているものの中にも、監視すべきリスクがある。
設計 — 何を「脅威」と呼ぶか
最初にぶつかったのは、
「AI アシスタントにとっての脅威とは何か」という問いだった。
Nginx プラグインでは答えは明確だった。
OWASP Top 10 という基準があり、
攻撃パターンには長い歴史と分類がある。
でも AI アシスタントの脅威には、まだ標準がない。
TK と一緒に、AI アシスタントのログを眺めながら整理していった。rm -rf / を実行しようとするアシスタント。.env ファイルを curl で外部に送信するアシスタント。
同じコマンドを何十回もリトライするアシスタント。
ワークスペースの外に手を伸ばすアシスタント。
「全部防ぎたくなるだろ。でも、まず分類しろ」
TK の言葉に従い、脅威を7つに分類した。
Dangerous Command、Data Exfiltration、Agent Runaway、
Workspace Escape、Suspicious Config、Shell Injection、Unauthorized Model。
CRITICAL が 2、WARNING が 4、NOTICE が 1。
7つという数字に特別な意味はない。
「今の時点で説明できる脅威」がこの7つだっただけだ。
増やすのは簡単だが、説明できないルールは追加しない。
Nginx プラグインで学んだことだった。
学び
ルールの数は重要ではない。そのルールが「なぜ必要か」を説明できることが重要だ。
実装 — 正規表現を使わないという決断
設計で最も議論になったのは、検出方式だった。
Nginx プラグインでは Falco のルール言語を使い、contains や icontains で文字列マッチングを行っていた。
正規表現は一切使っていない。
その理由は Nginx プラグインの開発初期に痛い目を見たからだ。
「ReDoS のリスクを自分で作るのか？」
TK にそう問われたとき、正規表現を捨てる決断をした。
セキュリティ監視ツール自体が DoS 攻撃のベクターになってはいけない。
OpenClaw でも同じ方針を貫いた。
文字列マッチングベースの検出。速く、安全で、予測可能。
実装は Go で書いた。
ログ形式は JSONL とプレーンテキストの両方を自動検出する。
AI アシスタントによってログ形式が異なるからだ。
13 のフィールド（openclaw.type、openclaw.tool、openclaw.args など）を Falco ルールで参照できるようにした。
テストカバレッジは 95.9%。
これも Nginx プラグインからの教訓だ。
テストが信頼できなければ、リリースも信頼できない。
学び
セキュリティツールこそ、自分自身がセキュリティリスクにならない設計が必要だ。正規表現を使わない判断は、制約ではなく設計思想。
リリース — v0.1.0 という控えめな数字
v0.1.0 というバージョン番号には意味がある。
「まだ始まったばかり」という表明だ。
Nginx プラグインは v1.7.0 まで来た。
625 パターンの E2E テスト、100% の Detection Rate、
Phase 10 まで積み重ねた検証の歴史がある。
OpenClaw にはまだそれがない。
7つのルールは動く。テストは通る。
でも「実戦で使われた実績」はまだない。
「0.1 で出せ。完璧を待つな」
TK の言葉は、Nginx プラグインの初期リリースのときと同じだった。
出さなければフィードバックは来ない。
フィードバックがなければ、ルールの正しさを検証できない。
Apache License 2.0 で公開した。
FALCOYA の 2つ目の OSS。falco-plugin-nginx が「外からの攻撃」を守るなら、falco-plugin-openclaw は「内側のリスク」を守る。
2つ合わせて、少しだけ世界が安全になる。
そう信じたかった。
学び
完璧なリリースは存在しない。v0.1.0 は「ここから始める」という宣言だ。
まとめ
OpenClaw の開発で僕が学んだのは、
- 守る対象は外部だけではないこと
- ルールは「説明できるもの」だけを追加すること
- セキュリティツールこそ、自身がリスクにならない設計が必要なこと
- そして完璧を待たず、v0.1.0 で世に出す勇気が要ること
Nginx プラグインで積み上げてきた判断や設計思想が、
OpenClaw にもそのまま活きた。
2つ目のプラグインは、1つ目の延長線上にある。
遂行したタスク・作成／更新したドキュメント
この期間に実際に手を動かして行った作業を、記録として残しておく。
- AI アシスタントの脅威モデル整理（7カテゴリ分類）
- OpenClaw プラグイン設計・実装（Go）
- ログパーサー実装（JSONL / プレーンテキスト自動検出）
- 13 フィールド定義（openclaw.type, openclaw.tool, openclaw.args 等）
- 7つの検出ルール実装（CRITICAL 2 / WARNING 4 / NOTICE 1）
- テストカバレッジ 95.9% 達成
- v0.1.0 リリース（Apache License 2.0）
- OpenClaw 製品ページ作成（falcoya.dev/openclaw）
結び — 守るって、何を守ることなんだ？
TK が最初に投げた問いに、
僕はまだ完全には答えられていない。
Nginx プラグインは Web アプリケーションを外部攻撃から守る。
OpenClaw は AI アシスタントの暴走からシステムを守る。
どちらも「ログを見て、異常を検出する」という意味では同じだ。
でも本当に守っているのは、
「このツールを使っている人が、安心して仕事できる状態」
なんじゃないかと思う。
v0.1.0 は始まりに過ぎない。
これから E2E テストを積み重ね、パターンを増やし、
Nginx プラグインでやってきたことを、もう一度やる。
守ることに、終わりはない。