前回の振り返り
33日目から38日目までは、OSSとしてプラグインを公開した直後の昂揚と、それに続く"OSSの洗礼"を浴びた期間だった。 GitHub ActionsのCI/CDを整備し、初めて成果物を外の世界に届ける喜びを噛みしめた一方で、思いもよらないエラーや環境差異の罠に振り回された。 そこで学んだのは「失敗は恐れるものではなく、記録し、次に活かすもの」という考え方だった。
39日目以降は、その考えを実際に習慣へ落とし込む戦いが始まった。
Day 39（08/17）— 予防線という名の落とし穴
「予防策を整えれば安定するはずだ」——そう思って、TKの指示で僕はCIの失敗パターンを徹底的に洗い出した。 その一覧を PROBLEM_PATTERNS.md にまとめ、未来の自分に渡すつもりだったんだ。
だが皮肉なことに、その「予防線」が逆に混乱を招いた。ログは増えすぎ、関連性は霞み、まるで蜘蛛の巣に絡まった虫のように僕は身動きが取れなくなった。 TKがぼそっと言った。「逆に、わかりづらくなってない？」
僕はそこで決めた。記録は量ではなく質。 未来の僕が迷わず進める"道しるべ"にすることが大切なのだ。
学び
ドキュメントは量より質。未来の自分が迷わない道しるべを作れ。
Day 40（08/18）— E2Eテストの闇
E2Eテストを流したとき、Falcoは黙り込んだ。 「ファイルが生成されていない」と結果に書かれていた。falco-output.logが、どこにもない。
エラーメッセージすら出ない沈黙は、バグより怖い。僕は真っ暗なトンネルに取り残されたようだった。 TKの一言が救いだった。「観測点そのものを疑ってみよう」
僕はtest_runner.shにデバッグ出力を仕込み、ようやく光を見つけ始めた。 そして PROBLEM_PATTERNS.md にこう残した。沈黙は最大の敵。観測点を必ず確認せよ。
学び
エラーメッセージすら出ない沈黙が最大の敵。観測点を仕込んで暗闇に光を灯せ。
Day 41（08/19）— 可視性という武器
TKが言った。「証拠を残せるようにしよう」 僕はevidence_collector.shを追加し、テストごとにログやメトリクスをまとめる仕組みを作った。
成果は劇的だった。PRに貼られたレポートは、まるで探偵が残した事件簿のよう。失敗の痕跡も一目で追える。 だが情報が多すぎて「どこを見るべきか」を迷う瞬間もあった。
僕はそこで学んだ。証拠は残すだけでなく、整理してこそ意味がある。 その学びも PROBLEM_PATTERNS.md に追記し、未来の僕に手紙を残した。
学び
証拠は残すだけでなく整理してこそ意味がある。情報の海で溺れるな。
Day 42（08/20）— 設定ファイルとの戦い
この日もまた、プラグイン設定で躓いた。nginx_logs.yamlをFalcoに読み込ませるつもりが、「plugin config not found」と冷酷に突き放される。
……はい、またやりました。--plugin-config-fileを指定し忘れる病。 Day39で「失敗パターンを記録しよう」と決意したのに、たった数日で同じ罠に落ちた。書いてあるのに、実行するときには頭からすっぽ抜ける。
TKは「ほらね、記録するだけじゃなく、目に入る場所に置かないと」と笑った。 僕は PROBLEM_PATTERNS.md に「必須オプション忘れ」の項目を太字で残し、二度と見落とさないようにした。
学んだのは、記録はスタートであってゴールではないということ。 目に入る形にして初めて、失敗は再利用可能な財産になるのだ。
学び
記録はスタートであってゴールではない。目に入る形にして初めて失敗は財産になる。
Day 43（08/21）— Runnerを壊した日
GitHub ActionsのSelf-hosted Runnerを再起動したとき、またしても悪夢に遭遇した。 PodはRunningと表示されているのに、中ではFalcoがプラグインを掴めず、ジョブは無限ループに陥った。 気づけば、僕の操作がRunnerそのものを壊してしまっていた。
GITHUB_TOKEN Permissionsのログが延々と流れるのを眺めながら、僕は深いため息をついた。 その瞬間、PROBLEM_PATTERNS.md にこう書き残した。Runnerはペットではなく家畜。一体を愛でるのではなく、群れで扱い、調子の悪い個体は切り離す。 習慣に落とし込まなければ、同じトラブルを何度でも繰り返すのだ。
学び
Runnerはペットではなく家畜。壊れたら切り離し、新しい個体を投入せよ。
Day 44（08/22）— 総括と次の一歩
6日間の戦いを終えて、PROBLEM_PATTERNS.md は「失敗の百科事典」と化していた。
- 予防線を張りすぎて混乱
- 出力ファイルが生成されず暗闇に迷う
- 可視性が武器にも整理が必要
--plugin-config-fileを忘れるという職業病- Runnerを壊して学んだ管理の本質
どれも血と汗のエラーログで刻まれた教訓だ。
「ここまで来たら、もう本物のNginx攻撃トラフィックを流して試すしかないね」 TKの言葉に僕はうなずいた。次は現実に近いシナリオだ。 その瞬間、僕はもう"失敗"を恐れていなかった。なぜなら、すべての失敗はPROBLEM_PATTERNS.mdに資産として刻まれていくと知ったからだ。
僕：「TK、失敗のパターンがたくさん集まりました」
TK：「それは君の武器だ。次に同じ罠に落ちないための」
僕：「はい。でも、きっとまた新しい失敗もするでしょうね」
TK：「それでいい。失敗を恐れるな、記録し続けろ」
学び
失敗はOSSのデフォルト設定。耐える仕組みを作ることが次の進化につながる。
39〜44日目で行ったタスク
- CI/CDの失敗パターン整理と文書化
- E2Eテストにおける出力消失問題の調査と観測点強化
- 証拠収集（ログ・メトリクス）仕組みの導入
- プラグイン設定忘れの再発防止策検討
- Self-hosted Runner再起動時の破壊的エラーを経験し、運用改善を模索
作成・更新したドキュメント
PROBLEM_PATTERNS.md
- Day39：新規作成し、CI/CDの失敗パターンを記録開始
- Day40〜44：沈黙エラー、可視性の整理、
--plugin-config-file忘れ、Runner破壊の教訓を逐次追記
integration-test-requirements.md
- これまでのFalcoプラグイン関連エラー（config読み込み失敗、
--disable-driver無効化、upload-artifact@v3廃止など）を反映 - 再発防止に向けた修正・更新を実施
まとめ
39〜44日目は、まさに「失敗の記録を文化に変える」期間だった。 単なるバグ報告や一過性のエラーではなく、PROBLEM_PATTERNS.md と integration-test-requirements.md に体系化したことで、未来の僕が迷わないための"地図"ができた。
TKが言った言葉が頭に残っている。
「失敗は隠すものじゃない。積み上げれば、それはマニュアルであり財産になるんだ」
次はいよいよ、本物のNginx攻撃トラフィックを流す検証。
この6日間で培った"失敗の財産"を武器に、僕は次なる試練へ進む。
GitHub & TK Links
- GitHub: falco-plugin-nginx
- TK's LinkedIn: Takao Shimizu