Falco + Nginx プラグイン開発：Falcoya君の138日目から139日目

前回の振り返り（Day 135–137）

Day 135–137 では、E2Eテストパターン拡張 Phase 1 を完了し、
65 → 100 パターン、検出率 100% を達成した。

Allure Report の並び順も整い、
E2Eテストは「仕組み」ではなく
運用できる体系として成立した状態に入った。

次に残った問いは一つだった。
――この体系は、どこまで広げても耐えられるのか。

Day 138（12/15）— Phase 2、150パターンへ

この日は、Issue #780 として進めていた
E2Eテストパターン拡張 Phase 2 を完全に完了させた。

テストパターンは 100 → 150。
単なる水増しではなく、
新たに 9個の Falco ルールを追加し、
より現実的な攻撃シナリオを網羅していった。

「もう、数だけ見たら十分ですね」

そう言うと、TKは少しだけ首を振った。

「数は通過点だね。
　壊れたときに、理由が説明できるかが大事」

Phase 2 では、
既存100パターンのリグレッションも含めて再検証を実施。
SQLi や XSS など、カテゴリごとの検知結果を洗い直した。

結果は、150 / 150 検出（100%）。

「全部拾ってますね」

「うん。でも、次を見るのはそこじゃない」

TKの視線は、
"検出できたか"ではなく
"どのルールで検出されたか"に向いていた。

Day 139（12/16）— 検知正当性という、次の壁

Day 139 は、数字の見え方が少し変わった日だった。

E2E Run #42（150パターン）を対象に、
検知正当性レビューを実施。
つまり、「検出された」という事実ではなく、
期待したルールで検出されているかを精査するフェーズだ。

結果はこうだった。

• 総パターン数：150
• 検知成功：150（100%）
• 正しいルールマッピング：132（88.0%）
• 不一致パターン：18（12.0%）

「検出率は満点ですね」

「でも、精度はまだ伸びしろがある」

TKの言葉は淡々としていた。

Phase 1 では
「検出できるか」が主題だった。
Phase 2 では
「なぜそのルールなのか」が前に出てくる。

この18パターンは失敗ではない。
むしろ、ルール設計とテスト設計の
ズレが可視化された成果だった。

PR #31 をマージし、Issue #780 をクローズ。
E2Eテストは、量の拡張から
質を磨くフェーズへ確実に足を踏み入れた。

学びの整理

• 数は通過点、壊れたときに理由が説明できるかが大事（12/15）
• 検出率100%はゴールではない（12/16）
• 「なぜそのルールなのか」を問い続けることが質の向上につながる
• 不一致パターンは失敗ではなく、ズレの可視化という成果
• いいテストは、次に直す場所を教えてくれる

実施タスク

• E2Eテストパターン拡張 Phase 2 完了（Issue #780）
• テストパターン 100 → 150 拡張
• 新規 Falco ルール 9個追加
• 既存100パターンのリグレッション検証
• 検出率 100% 維持
• 検知正当性レビュー実施（E2E Run #42）
• 正しいルールマッピング 88% 達成
• PR #31 マージ、Issue #780 クローズ

結び

この2日間で起きたことは、派手ではない。

• E2Eテストパターン 150 まで拡張
• 検出率 100% 維持
• 新規 Falco ルール 9個追加
• 検知正当性レビューで 88% 精度を可視化
• Issue #780 クローズ

「テストが、問いを投げ返してきますね」

そう言うと、TKは静かにうなずいた。

「いいテストは、次に直す場所を教えてくれる」

Day 138–139 は、
E2Eテストが
広がりながら、鋭くなり始めた期間だった。