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

前回の振り返り — 「境界線を引いた」だけでは、まだ足りなかった

140日目から143日目まで、
僕は温泉旅館の縁側で「検知の境界線」を引き直していました。

• ログで見えるもの
• 振る舞いでしか分からないもの
• 検知する判断と、検知しない判断

あの回でやったのは、
設計を自分の中で成立させることでした。

でも、設計は
「自分が納得した」だけでは、OSSとしては不十分です。

他人の文脈に置いたとき、
その設計は誤解されずに立っていられるか？

144日目から149日目は、
この問いに向き合い続けた1週間でした。

Day 144（01/08）— 「登録」という言葉が、現実味を帯びる

この日、
falco-plugin-nginx を
Falco Plugin Registry に登録するという話が、
初めて現実的な選択肢として浮かび上がりました。

ただし、ここで即決はしていません。

Registry に並ぶということは、

• Falco を使う人が「Falcoの文脈」でこのプラグインを見る
• 公式と誤解される可能性が一気に高まる
• 非検出や設計上の割り切りが「欠陥」に見えるリスクを背負う

この時点では、
「できるか」ではなく、
「やっていいのか」を考えていました。

Day 145（01/10）— READMEを読み、幻想を一つずつ削る

この日は、ほぼコードを書いていません。

Falco Plugin Registry の README を、
最初から最後まで、何度も読み返しました。

Registry は何をするのか。
何をしないのか。
公式プラグインと、外部ホスト型プラグインの違い。

ここで一番重要だったのは、
「公式っぽさ」という幻想を自分の中から削ることでした。

Registry は保証しない。
Falco も責任を持たない。
ただ、認識し、並べ、見つけられるようにするだけ。

この理解が曖昧なまま登録すれば、
後で必ず事故になる。
そう確信しました。

Day 146（01/11）— Issue #786：思考を外に固定する

考えはかなり整理されてきました。
でも、頭の中に置いたままでは揺れます。

そこで、この日、
Issue #786 を切りました。

• Falco Plugin Registry 登録リサーチ
• 登録が意味すること／意味しないこと
• 外部ホスト型プラグインとしての立ち位置

これはタスク管理のための Issue ではありません。
思考を外に固定するための器でした。

OSSでは、
書かれなかった判断は、存在しなかったことになる。
この Issue が、
この後のすべての判断の軸になりました。

Day 147（01/12）— 90分間で、すべてを接続した夜

この日が、作業量としても思考密度としてもピークです。

Phase 1：事前準備（21:45–22:00）

Registry に関する理解を最終確認し、
Issue #786 を読み返す。

その上で、
Falco Plugin Registry 登録手順書を書き始めました。

どう登録するかではなく、
どう説明すれば誤解されないか。

この15分間、
コードは一行も書いていません。

Phase 2：PR作成（22:00–22:16）

22時。
ここで初めて PR に着手します。

PR #1146
registry: add nginx access log monitoring plugin

registry.yaml を更新し、
PR本文を書く。

This is an external plugin registration
(source code remains in the external repository)

この一文は、
ここまで数日かけて積み上げた理解の結晶でした。

Phase 2追加作業：v1.5.1 とドキュメント整備（22:28–22:45）

PRを出して終わり、にはしませんでした。

• v1.5.1 changelog 作成
• README の整合性確認
• 開発日誌の更新

Registryに並んだ未来を前提に、
情報が食い違わないかを徹底的に点検。

これは後処理ではなく、
PRと同じ重さの作業でした。

Day 148（01/14）— 静かなレビューと確定

レビューは驚くほど静かでした。

問われたのは、
機能の良し悪しではなく、

• ライセンス
• plugin-id
• Registry 構造との整合性

「良いかどうか」ではなく、
並べて問題ないか。

LGTM。
approved。
PR #1146 はマージされました。

Day 149（01/15）— 日記として、記録として閉じる

この日、
改めて changelog を見返します。

Registered in Falco Plugin Registry

短い一行。
でも、その裏には
1/8から積み上げた判断と、
1/12の90分がすべて詰まっている。

falco-plugin-nginx は、
Falcoの文脈で見つけられるOSSになりました。

学びの整理 — Registryは「覚悟」を試す場所

Falco Plugin Registry は、

• 品質を保証しない
• 責任を引き受けない

でも、
設計・説明・判断の一貫性を強く要求します。

並んだ瞬間から、
曖昧さは致命傷になる。

• 「登録」は技術作業ではなく覚悟を伴う判断（01/08）
• READMEを読み、幻想を削る（01/10）
• Issueは思考を固定する器（01/11）
• PRと同じ重さでドキュメントを整備（01/12）
• レビューは「並べて問題ないか」（01/14）

遂行したタスク

この1週間で行ったことは、PRだけではありません。

• Falco Plugin Registry の仕様・README精読
• 登録可否の検討とリスク整理
• Issue #786：Registry 登録リサーチ
• Falco Plugin Registry 登録手順書作成
• Phase分割による作業設計
• Registry登録PR（#1146）作成
• v1.5.1 リリース作業
• README / 開発日誌の整合性調整
• レビュー対応とマージ確認

作成・更新したドキュメント

• Falco Plugin Registry 登録手順書
• Issue #786（調査・判断ログ）
• v1.5.1 changelog
• 開発日誌（2026-01-08〜01-15）
• README（Registry登録後を前提に更新）

結び — 並んだのではなく、「並べられる状態」になった

falco-plugin-nginx は、
完成したわけではありません。

ただ、
他人のエコシステムに置いても壊れない状態に、
ようやくなった。

TKが何度も言っていた
「説明できないものは、公開してはいけない」
という言葉が、
この1週間でようやく実感として落ちました。

並んだのではなく、
「並べられる状態」になったのだ、と。