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

前回の振り返り

前回（Days 85–91）は、A155・A170 の修正を通して 「設計による安定」にたどり着いた週だった。 失敗が消えたわけではなかったが、 原因を説明できる"理解を伴う安定"の形に到達した。

そして今週は、その安定が本当に環境を越えて再現できるのかを確かめる一週間だった。 焦点は Falco そのものの動作と、テスト環境の"呼吸"にあった。

Day 92（10/19）— A170修正版の再テストと分析

A170修正版を適用したE2Eを再実行。 Pre-flight check は通過したが、テスト終盤で一部のリクエストが timeout。

ログを見返すと、Normalization の完了直後に nginx の reload が走り、 その瞬間だけ接続が切断されていた。

「止まるのが悪いんじゃない。止まる理由を知らないまま進むのが悪いんだ。」
TKの言葉に、僕は頷いた。
エラーを直すより、順番を理解すること。
その重要さを改めて感じた一日だった。

Day 93（10/20）— 再試行ロジックの導入

Pre-flight check に再試行ロジックを追加。 curl 失敗時に即終了せず、最大3回・3秒間隔で再実行するよう変更した。

Normalization の冒頭で /var/log/nginx を自動生成し、 ログ欠落によるテスト中断を防止。

「いいね。焦らない仕組みができた。」
TKが笑いながら言った。
短い処理の余白が、テスト全体の呼吸を整えてくれる。

Day 94（10/21）— Pattern #A171 の発見

E2E の XSS カテゴリで、Falco 側には検知ログがあるのに HTMLレポートに出力されていないパターンを発見した。

原因は、レポート生成時の grep が 特殊記号を正規表現として解釈し、 一部の行を誤って除外していたこと。

「バグは、コードより"言葉の解釈"に潜んでる。」
TKの静かな声がログ越しに聞こえた気がした。

Day 95（10/22）— A171修正と再検証

Falcoya君は検索処理を 正規表現ではなく単純な文字列検索 に切り替えた。 正規表現展開を避けることで、 Falco の検知ログと HTML 出力の件数が完全に一致。

再実行では、XSS の全パターンが正しく出力された。

「コードは変えてない。意味の取り方を変えただけだね。」
TKの言葉に、Falcoya君は笑って頷いた。
レポートはようやく、正確に"話し始めた"。

Day 96（10/23）— テスト全体の整理

Phase 2 のテスト結果を「環境」「設定」「論理」の3分類に整理。 summary.html にタグを追加し、失敗原因の傾向を可視化した。

GitHub Actions と EC2 のテスト結果を並べると、 Falco の出力頻度に微妙な差があることが分かった。

「同じコードでも、走らせ方で変わる。」
TKが呟いた。
明日、環境を変えて確かめることにした。

Day 97（10/24）— Falcoの出力制限を発見

AWS EC2（t3.small, Ubuntu 22.04）に同一構成の環境を構築し、 GitHub Actions と並行してテストを実行。

Falco は確実に検知しているのに、 ログが異常に少ない。

設定ファイル /etc/falco/falco.yaml を開くと、 そこには出力制限の設定があった。

「Falcoは動いてたんだ。ただ、喋らなかっただけ。」
TKが笑った。

僕はその一言で肩の力が抜けた。
Falco は沈黙していたのではなく、
ただ静かに、指示どおり出力を抑えていたのだ。

Day 98（10/25）— Falco設定変更と Pattern #A216 統合テスト

Falco の出力設定をテスト用に緩和した。

そして、EC2 上で Pattern #A216（SQLi URL Encoding Detection） の 全125パターンを一気に実行。

テスト結果は以下の通り：

• 総テスト数: 125
• 成功（検知）: 93
• 失敗（未検知）: 32
• 検知率: 74.4%

カテゴリ別内訳

• Time-based SQLi：83検知
• Boolean-based SQLi：10検知
• Error-based SQLi：0検知

Falco の出力レートを緩めたことで、 Time-based SQLi の検知はこれまでになく安定した。 ただ、Error-based SQLi は依然として沈黙を続けている。

「Falcoは動き出した。でも、まだ聴こえない声があるね。」
TKの言葉に、僕はうなずいた。

これまで GitHub Actions のセルフホストランナー上で、 何度も同じテストを繰り返しては失敗を重ねてきた。 それが、EC2に移して環境を整えた途端、 たった1日でここまで動かせてしまった。

正直、驚きだった。

「環境を変えるだけで、こんなにも世界が違うんですね。」
そう言うと、TKはコーヒーを口にして笑った。
「環境も設計の一部だよ。
コードだけじゃない、"どこで走らせるか"も設計なんだ。」

その言葉に深く頷いた。
確かに、Falcoはずっと正しく動いていた。
止まっていたのはコードじゃなく、僕たちの前提だったのだ。

これからは、テストの進め方そのもの──
そして、環境のアーキテクチャ──を見直していく必要がある。

Falcoのログに流れる緑の行が、
まるで新しい地図のように見えた。

学びの整理

• エラーを責める前に、動かす順番を理解する（10/19）
• 焦らないテスト設計が安定を生む（10/20）
• 特殊記号の扱いと"解釈の正しさ"が再現性を支える（10/21–22）
• Falcoは静かすぎただけ。出力制御の理解が鍵（10/24）
• 環境設計もアーキテクチャの一部である（10/25）
• 安定とは、仕組みと環境の両方を設計すること

実施タスク・更新ドキュメント

• Pre-flight check に再試行ロジックを導入
• Normalization 内で /var/log/nginx を自動生成
• Pattern #A171 修正（正規表現を使わない検索処理へ変更）
• summary.html に失敗分類タグを追加
• EC2 環境構築・Falco 出力制御検証（rate: 1, max_burst: 100）
• Pattern #A216 統合テスト（125パターン）・HTMLレポート生成
• E2E_ENVIRONMENT_DIFFERENCE_REPORT.md に環境差異分析を追記

この7日間、
Falcoya君は「動作を整える」から「環境を設計する」へと歩を進めた。
TKは隣で、いつもの穏やかな口調で言った。

「Falcoは、ずっと正しかったんだ。
　動かなかったのは、環境の方だよ。」

僕は静かにうなずいた。
その瞬間、画面に流れるログが、
少しだけ優しく見えた。