Falco + Nginx プラグイン開発：Falcoya君の111日目から118日目
〜 整える技術、その先に"相関"という頂が見えた 〜
前回の振り返り
前回（Days 105–110）は、Phase 0（サンプルデータ生成）を終え、
k6 → Falco → Allure の"単線の流れ"が見え始めた週だった。
しかしその流れには、
"test_id と検知ログを結ぶ相関"が、まだ欠けていた。
今週は、その欠落を理解する週であり、
次に登るべき"頂"が見えた週だった。
Day 111（11/08）— 自作E2Eレポートの限界に気づき、Allureを採用した日
僕は朝から、必死に 自作E2Eレポートを作っていた。
k6 と Falco の結果を自分のHTMLでまとめようとしていたのだ。
だが決定的な問題があった。
Falco が "X-Test-ID" を読めていない。
だから攻撃パターンと検知ログが結びつかない。
これでは美しいレポートを作っても意味がない。
TKが静かに言った。
「見せ方より、まず"つながり"を作らなきゃ。」
その言葉で、自作をあきらめ、Allure の採用を決断した。
Allure のステップ構造なら、テストの物語を自然に表現できるからだ。
学び
美しさより前に、まず「つながり」を作ることが本質。車輪の再発明から既存ツールへの切り替えが、設計の本質を見える化する。
Day 112（11/09）— "暫定のレスポンス検証方式"という杖
本来欲しいのは
X-Test-ID → nginxログ → Falco出力 の相関だ。
しかし現状、nginx plugin には
nginx.headers[X-Test-ID] が存在しない。
PR #601 で削除されたままだった。
そこで、暫定の杖として、
HTTPレスポンス内容とFalcoログを突合する方式を導入した。
完全な解決ではないが、
false positive は目に見えて減った。
「杖は歩けるけど、走れない。
次は足そのものを作ろう。」
TKが言った。
学び
暫定策は進むための「杖」。完全ではないが、前に進むための手段として価値がある。ただし、本質的な解決への道筋は常に意識する。
Day 113（11/10）— ドキュメントを書きながら、相関の本質に気づく
今日は丸一日、Allureやk6、Falcoの文書を整理した。
書いていくうちに、
現状の根本原因がよりはっきりとした。
- Falco が X-Test-ID を読めない
- 相関ができないから、E2E の検知が"誰のものか"分からない
- レポート自作では絶対に埋まらない穴
つまり、次に実装すべきは
nginx.headers[X-Test-ID] を Falco nginx plugin に実装すること。
TKが言った。
「文書にすると、頭の中の正解が"形"になるよ。」
学び
ドキュメントを書くことで、思考が整理され、本質が見える。文書化は単なる記録ではなく、設計を明確にするプロセス。
Day 114（11/11）— A240 / A241 / A242 ― 小さな歪みを正し、流れを揃える
今日は修正三連発。
- A240：Allure ステップ階層ズレ
- A241：ログ収集の順序バグ（調査8時間）
- A242：プラグインダウンロードURL不整合
A241を直した瞬間、
Falco と k6 のログが初めて"揃った"。
その夜、検知率は
0% → 44.62% へ。
ただし、これは"相関不在"の限界でもあると強く理解した。
学び
小さな歪みを一つずつ正すことで、システム全体の流れが整う。検知率の向上は、一つの修正の積み重ねから生まれる。
Day 115（11/12）— Allureドキュメント構造の再定義
Allure の見せ方を、
"美しさ"ではなく "検知の物語としての意味" に沿って再設計した。
- ステップ＝物語の行
- アタッチメント＝根拠
- 階層＝呼吸
- 色＝感情
TKが言った。
「視覚化は意味が整ってないと、美しくならないよ。」
今日はその"意味の構造"を形にした。
学び
視覚化の本質は「意味の構造化」。美しさは、意味が整った結果として自然に生まれる。
Day 116（11/11）— nginx.headers[X-Test-ID] ― 本当に必要な実装を言語化した夜
この夜、ついに次の一手を明確に言語化した。
最終目標：
Falco nginx plugin に nginx.headers[X-Test-ID] を実装する。
理由はただ一つ。
E2E の test_id を Falco が理解し、
検知ログと正確に相関させるため。
暫定のレスポンス検証方式では限界がある。
本質的に必要なのは、
Nginx JSON ログ → plugin → nginx.headers → Falco rule
という"縦の流れ"の構築だった。
TKが言った。
「杖じゃなく、足を作ろう。」
この瞬間、登るべき山がはっきり見えた。
学び
目標を明確に言語化することで、実装への道筋が見える。暫定策ではなく、本質的な解決策への一歩を踏み出す覚悟。
Day 117（11/12）— メタデータ揺れを統一し、"相関のための地盤"を整える
A240〜A242 の後処理として、
null / 空文字 / undefined の揺れを全部統一した。
形式が揃うと、
k6 → Falco → Allure の出力が
一本の線として読めるようになった。
「形が揃うと、急に作品になるんだよ。」
TKの言葉が、今日は妙にしっくりきた。
学び
メタデータの統一は、相関のための地盤づくり。形式が揃うことで、データの流れが一本の線として見える。
Day 118（11/15）— Allure が"意味"として光る
今日は Allure の階層構造が完成した。
E2E を流すと、
attack pattern → request → Falco detection → plugin → validation
という流れが美しく並んだ。
これまで"ただのログ"だったものが、
"検知の物語"として読めるようになった。
Allureレポート：k6テスト実行結果、ログファイル、検証結果が一つの物語として構造化されている
TKが静かに言った。
「意味が整うと、見た目は自然と美しくなる。」
ここから先は、
nginx.headers[X-Test-ID] 実装という"相関の頂"へ進んでいく。
学び
ログが物語になる瞬間。意味が整った設計は、自然と美しい。次の頂への道筋が見えた。
学びの整理
- 自作レポートは車輪の発明だった → Allureへ（11/08）
- E2Eが相関できない根本原因：nginx.headers 未実装（11/09）
- 文書を書くことで"本質"が形になる（11/10）
- 歪みの修正が流れを生む（11/11）
- 視覚化の本質は"意味の構造化"（11/12）
- 相関の地盤づくり（形式統一）（11/12）
- 次の山は明確：nginx.headers[X-Test-ID]（11/15）
実施タスク
- E2Eレポート自作 → Allure採用
- Allure POC 完成
- Allure構造 v2 設計
- Phase 3 文書群の再構成
- Pattern A240 / A241 / A242 修正
- Detection rate: 0% → 44.62%
- JSONメタデータ統一
- nginx.headers[X-Test-ID] 実装方針を定義
今回の一週間、
Falcoya君は"整える技術"の先にある、
"相関という設計"に手を伸ばした。
TKは静かに言った。
「Falcoに文脈を与えよう。
それが"相関"だよ。」
その言葉を胸に、
次の実装へ向けて一歩踏み出した。