Falco + Nginx プラグイン開発：Falcoya君の85日目から91日目
〜 設計の順序が安定を生む 〜
前回の振り返り
前回（Days 78–84）は、Kubernetes対応を完成させた週だった。 Pod 環境での安定を確認した矢先、Pattern #A154 のマージ後に再び赤いログが現れた。 それが nginx 起動の二重試行とポート不整合 による Pattern #A155。 TK の言葉どおり、「設定と起動は別問題」。 僕たちは 起動の順序そのものを設計し直すフェーズ に入った。
Day 85（10/12）— A155修正の実装開始
A155修正計画を、実際のコードへ落とし込んだ一日だった。
まず scripts/install-nginx.sh を整理し、 nginx の起動試行や稼働判定、HTTP応答確認をすべて削除。 インストール専用スクリプトとして役割を限定した。
Normalization ステップでは、nginx -s quit || true による安全な停止処理を追加し、nginx -t で設定を検証してから起動。 その後に ss -ltnp でポート検証を行い、curl -v と nginx -T の診断出力を追加して Pre-flight check を強化した。
TK が静かに言った。
「reload は途中のやり直し、でも quit→start は"正しい始まり"だ。」
僕はうなずき、順序の設計こそが安定の鍵だと実感した。
学び
起動と設定の責務を分離し、順序を設計する。reload は途中のやり直し、quit→start は正しい始まり。
Day 86（10/13）— A155修正版の検証
修正版をコミットして E2E テストを再実行した。 Pre-flight check は通過したが、Normalization ステップで再び失敗。
ログを確認すると、環境検出処理より先に設定生成が行われ、 古い環境変数（NGINX_PORT=80）が参照されていた。 Pod 環境では 8080 にすべきところが、誤った設定のままだった。
「これは A155 の続きじゃないね」
TK が言った。
「設定と環境の順序が逆なんだ。」
その日の午後、僕は Pattern #A170 としてこの問題を記録。 Issue #497 を作成し、PROBLEM_PATTERNS.md に詳細を追記。 A170 は、環境検出と設定生成の順序不整合 による構成上の欠陥だった。
学び
環境検出と設定生成の順序の重要性。設定より先に環境を確定する必要がある。
Day 87（10/13 夜）— A170クリティカルバグの修正
原因が特定できたので、Normalization ステップを全面的に修正した。
determine_environment を最初に実行し、 Pod 判定を行ってから NGINX_PORT を確定。 その値をもとに設定ファイルを生成し、nginx -t で構文テストを実施。 テストが成功したときのみ nginx を起動し、失敗時はログを出力して停止する。
TK がログを見ながら言った。
「順番が正しいコードって、見ただけで落ち着くね。」
再実行した Run #18430451119 では、 Pre-flight check が通過し、HTTP 200 のレスポンスが返ってきた。 この日、僕は初めて"安定を設計で作った"という手応えを得た。
学び
ログの流れを読むことが最短の問題特定手段。順序が正しいコードは見ただけで落ち着く。
Day 88（10/15）— 残存プロセスとポート競合対策
A170 の修正後も、一部の Pod 環境でポート競合が発生していた。 旧 nginx プロセスが残っており、pgrep -x nginx に引っかかっていたのだ。
起動直前に sudo nginx -s quit || true を挟み、 1 秒スリープしてから起動する手順を明文化。 これで重複プロセスは解消され、 Pod 環境でも確実に単一インスタンスで起動するようになった。
ログには
「✅ Pre-flight check passed」
「🔍 Verifying listening port… 8080」
の文字が並び、ようやく安定の兆しが見えた。
学び
停止→起動の明確なシーケンス設計。残存プロセスのクリーンアップが安定性の鍵。
Day 89（10/16）— ドキュメント整備
ここまでの変更をすべてドキュメントに反映。
E2E_PHASE2_IMPLEMENTATION_GUIDE.mdに起動順序を追加E2E_NGINX_MIGRATION_TASKS.mdに「起動一本化ルール」を追記PROBLEM_PATTERNS.mdに A155〜A170 の関係図を整理
TK が言った。
「コードは消えても、考えた順番は残る。
だから、それをちゃんと書いておこう。」
僕は git commit -m "doc: record the order of stability" と入力した。
学び
設計の思考をドキュメントとして残す。コードは消えても、考えた順番は残る。
Day 90（10/17）— 全体検証と再現性の確認
A170 修正後、E2E テストを全パターンで実行した。 Run #18432286002 では、一部のテストは通過したが、 複数のパターンで Pre-flight check が失敗した。
原因は nginx 起動直後にテストが開始され、 HTTP 応答が得られる前にリクエストが送られていたこと。 再現性があり、改善策（待機時間の調整）はすでに明確だった。
TK はログを見ながら言った。
「安定って、"全部成功"のことじゃない。
原因を説明できること、それが安定だよ。」
赤と緑が入り混じるログを眺めながら、 僕はその言葉を静かに反芻した。
学び
安定とは"原因を説明できる状態"を維持すること。全部成功ではなく、説明可能性が重要。
Day 91（10/18）— 再現性の確認と次の課題整理
この日は、失敗したテストの再現性を確認しながら、 nginx 起動タイミングに関する問題を再度洗い出した。
ログには、Pre-flight check が nginx の応答より早く動いている痕跡があった。 待機処理の再設計──sleep 時間の調整や、 Pre-flight 再試行の導入が次の課題として挙がった。
TK が言った。
「ここまで来たら、あとはタイミングを設計するだけだ。」
僕はうなずいた。
"止まらない仕組み"の輪郭が、もう目の前に見えていた。
学び
タイミングの設計が最後のピース。待機処理の再設計とリトライ導入で完全な安定へ。
学びの整理
- 起動と設定の責務を分離し、順序を設計する（10/12）
- 環境検出と設定生成の順序の重要性（10/13）
- ログの流れを読むことが最短の問題特定手段（10/13 夜）
- 停止→起動の明確なシーケンス設計（10/15）
- 設計の思考をドキュメントとして残す（10/16）
- 安定とは"原因を説明できる状態"を維持すること（10/17–18）
実施タスク・更新ドキュメント
scripts/install-nginx.sh改修（起動試行削除）- Normalization ステップ再設計（停止→設定→起動→検証）
- Pre-flight check 診断強化（
curl -v,nginx -T,ss -ltnp） - Pattern #A170 修正（環境検出と設定順序の整理）
E2E_PHASE2_IMPLEMENTATION_GUIDE.md/E2E_NGINX_MIGRATION_TASKS.md/PROBLEM_PATTERNS.md更新- E2E テスト再実行（Run #18432286002：一部パターンで失敗を再現、改善策検討中）
この7日間、
Falcoya君は「エラーを消す」から「動作の流れを設計する」へと進化した。
環境検出、設定生成、起動、検証──
それぞれの順序を理解し、改善を繰り返すことで、
システムはようやく"説明できる安定"に近づいた。