Supabase課金ゲートを13日遅延でFAIL判定 — 人間記録から番人routineへの設計転換実録

課金ゲートを設定していた。達成できなければ方針を見直す、という設計だった。ゲートが通過したかどうかの判定をしたのは、期限から13日後だった。

結論

第1課金ゲートはFAIL。実支払い0件（合格条件: 5件以上）。かつ、合格の前提となる施策（有料note+X広告）が実走されたかどうかもSupabaseのDBでは確認できない状態だった。

問題は「施策が足りなかった」ではなく、**「ゲートの判定と記録を人間が行う設計にしていたこと」**だった。判定が13日遅延したのはそれが原因だ。次回からは、番人routineがSupabaseのSQL閾値を参照して自動記録する方式に切り替える。

第1課金ゲートの合格条件は「有料note + X広告¥2万相当の施策を実走した結果、実支払い5件以上（本人除く）」だった。

判定期限は2026-08-22。

Supabaseで確認した結果：

施策がSupabase外のツール（noteのダッシュボード、X広告管理画面）で動いていたため、実走されたかどうかをDBで確認する手段がなかった。課金が発生したかどうかもDBでは追えない。

この記録がdev_journalに書き込まれたのは2026-09-04。判定期限から13日後。

遅延の直接原因は**「ゲートの判定・記録をmasatoman本人が行う設計になっていた」**こと。

AIがコンテンツを生成し、自動でpushし、外部媒体に配信する——という動作は自動化されていた。しかし「その結果を評価して記録する」という行為は人間に残っていた。

この設計の問題点は2つ：

「AIに任せた」と言いながら、判定という核心部分を人間が持っていた。それが今回の設計の穴だった。

AIに業務を任せる設計を組む上で、「判定」をどこに置くかは重要な設計選択だ。

今回の課金ゲートは「実支払い≥5件」という数値閾値で完全に定義されていた。Supabaseに記録があれば、SQLで即座に判定できる。人間が記録する必要はなかった。

次の設計方針：

自分のゲート条件をSQL化できるか確認する: 設定している目標や判断ポイントを書き出し、「Supabaseのクエリで判定できるか」を確かめる。できないなら何が足りないか（テーブル・記録経路）を特定する
施策の実走経路を見直す: 外部ツール（noteダッシュボード・広告管理画面）でのみ確認できる施策がある場合、Supabaseに実走ログを残す経路（webhook・手動insert・日次バッチ）を設計する
番人routineの実装範囲を決める: 自動判定させるゲート条件を1つだけ選び、最小のSQLとroutineスクリプトで動かしてみる。全部を一度にやらない

「設計した」と「動いている」は別物だ。今回の教訓は、判定という行為が自動化されていなければ、自動化設計は絵に描いた餅になるということだった。AIに任せる設計を「完成」させるのは、人間が最後まで手を放せるかどうかにかかっている。

masatoman.net の今週の記事 1 本を、読者目線で深掘りした手紙が毎週月曜 9:00 に届きます。「これ自分のことだ」が見つかる予告編。登録特典に「個人開発の収益化チェックリスト 15 項目」。

masatoman のメルマガ — 毎週月曜の朝に 1 通

masatoman.net で今週公開した記事の中から 1 本を、読者目線で深掘りした手紙が届きます。「自分も同じことやってる」「ここで詰まってた」が見つかる予告編。