Falco + Nginx プラグイン開発：Falcoya君の99日目から104日目
〜 車輪をやめて、走るための設計へ 〜
前回の振り返り
前回（Days 92–98）は、Falcoの沈黙を解き、
出力制御（rate / max_burst）の調整によって安定を得た週だった。
AWS EC2 での安定化を確認し、
「環境が変われば世界が動く」ことを実感した。
しかし、GitHub Actions のセルフホストランナーでのE2Eは、
依然として不安定だった。
何度修正しても、また壊れる。
その原因を探る中で、僕たちはひとつの結論にたどり着いた。
――「車輪を作るのは、もうやめよう。」
Day 99（10/26）— キャッシュの罠
午前中、GitHub Actions のログを追っていた。
また、E2E テストが途中で止まっていた。
調べてみると、修正したはずのGoコードが反映されていない。
原因は、GitHub Actionsのキャッシュ復元処理だった。
古いビルド済みバイナリ（falco-nginx-plugin.so）が
actions/cache に残り、最新コードのビルドを上書きしていたのだ。
「キャッシュって、便利だけど"賢すぎる"ときがある。」
TKが静かに言った。
僕はキャッシュキーを更新し、go clean -cache -modcache をビルド前に追加。
ようやく正しいバイナリが生成されるようになった。
だが同時に、思った。
もう、テストを「動かすこと」自体が目的になっている。
そろそろ、"仕組み"を見直すべきときだ。
学び
キャッシュの賢さが裏目に出ることがある。ビルド前のクリーンアップとキャッシュキー管理が重要。
Day 100（10/27）— k6 の採用
午前、TKとの打ち合わせ。
自作のE2Eテストスクリプトを続ける限界を共有した。
GitHub Actionsのセルフホストランナー上で環境を立て、
curlとjqで攻撃パターンを再現してきたが、
テストより環境修復に時間を取られる日も多かった。
「これ以上、車輪を磨くのはやめよう。」
そう言って、僕たちはk6の採用を決めた。
k6は本来ロードテストツールだが、
HTTPベースでシナリオを記述でき、
攻撃パターンをスクリプトとして管理できる。
初期スクリプトはこうだった。
import { check } from "k6";
export default function () {
let res = http.get("http://localhost/api/test");
check(res, {
"status is 200": (r) => r.status === 200,
});
}
驚くほどシンプルで、実行も安定していた。
「ツールを信頼できるって、いいね。」
TKが笑った。
"自作の仕組み"を手放した瞬間、
走る道が見えてきた。
学び
車輪の再発明をやめ、信頼できるツールを採用する。k6のシンプルさと安定性が、テスト基盤を変えた。
Day 101（10/28）— テストの再設計
Phase 1とPhase 2で分かれていたE2Eテストを、
k6ベースで再設計。
SQLi、XSS、Path Traversal の各攻撃パターンを
モジュール化された関数として整理。
テスト結果は summary.json に出力し、
Falcoの検知ログと突き合わせる仕組みを追加した。
冗長なBashスクリプトが姿を消し、
構成は40%軽量化。
実行時間は従来の半分になった。
「負荷試験ツールを"検知テスト"に使うって発想、面白いね。」
TKが言った。
「車輪を作る時間より、走る仕組みを考える時間の方が価値あるよ。」
学び
テストの再設計で構成40%軽量化、実行時間は半分に。ツールの目的外活用が、新しい価値を生む。
Day 102（10/29）— ワークフロー統合
旧Phase 1のワークフローを、
Phase 2の仕様と同じ構成に統合。
Falcoログとの突合処理を jq で自動化し、
検知率・応答時間・エラー率を可視化できるようにした。
E2Eテストの設計がようやく"土台"に変わった瞬間だった。
「再現できるテストって、もうデバッグじゃない。
設計の一部なんだよ。」
TKの言葉が印象に残った。
学び
再現できるテストは、デバッグではなく設計の一部。ワークフロー統合で、テストが土台に変わる。
Day 103（10/30）— k6レポートの可視化
k6の出力をHTML形式に変換し、
各攻撃パターンの結果を一目で見られる k6-summary.html を作成。
失敗箇所は赤、検知成功は緑でハイライトされる。
Falcoの検知ログと時系列が一致し、
"テスト結果"と"Falcoの反応"が並ぶ光景は圧巻だった。
TKがレポートを見ながら言った。
「これが、本当の"動いている"状態だね。」
学び
可視化によって、テスト結果とFalcoの反応が一つの物語になる。HTMLレポートが、理解を加速させる。
Day 104（10/31）— Terraformで動かす環境を設計する
夜、TerraformでAWS環境をデプロイした。
VPC、サブネット、セキュリティグループを自動構築し、
その中にk6をインストールしたEC2を立ち上げた。
そして、SSHでその環境に入り、手動でテストを実行。
Falcoとk6が出力するログは完全に一致し、
テストは一度も落ちなかった。
「これだよ、環境が"味方になる"っていうのは。」
TKが言った。
確かに、Falcoはずっと正しく動いていた。
止まっていたのは、僕たちの環境の設計だった。
今回のTerraform構成はまだ手動実行の段階だが、
次はこの環境をCIに組み込み、自動で動かす仕組みを整える。
"動かすために作る"のではなく、
"動き続けるように設計する"。
その違いを、僕はようやく理解した。
学び
環境をコードで設計する（Infrastructure as Code）。Terraformによって、再現可能な環境が味方になる。
学びの整理
- GitHub Actions のキャッシュが古いバイナリを復元していた（10/26）
go clean -cache -modcacheとキャッシュキー更新で解決（10/26）- E2Eテストを自作から k6 へ全面移行（10/27–10/30）
- 旧Phase1/Phase2 ワークフロー統合（10/31）
- TerraformでAWS環境をコード化し、手動でテスト実行（10/31）
- "テストを動かす"から"環境を設計する"へ
実施タスク・更新ドキュメント
- GitHub Actions キャッシュ設定修正（actions/cache キー更新）
- ビルド前に
go clean -cache -modcacheを追加 - E2Eテスト基盤を curl + jq スクリプト → k6 に全面移行
- Falcoログ突合スクリプト（jq）整備
summary.json/k6-summary.html出力統一- 旧Phase1/Phase2 ワークフロー統合
- TerraformでAWSテスト環境構築（VPC / Subnet / SG / EC2 / k6インストール）
- SSHで手動テスト実行・結果検証
この週、
Falcoya君は「動作を整える」から「環境を設計する」へと進化した。
そしてTKは、静かに言った。
「Falcoは最初から正しかったんだ。
止まっていたのは、環境のほうだった。」
その言葉を聞きながら、
Falcoya君はTerraformのコードを眺めた。
緑のログが流れる画面の向こうに、
"設計として動く世界" が、確かに見えていた。