FOUNDATION 05 / LOOPS

良い自動化ループは、速く回るより安全に止まれる

無限に仕事を作るエージェントは会社を自動化しません。重複、誤公開、コスト、確認作業を増やします。Revenue OSでは、収益導線に必要な6ループだけを残し、すべてを同じjob状態と停止規則で管理します。

jobは状態を飛ばさない

標準状態はqueued、researching、drafted、verified、staged、publishedまたはdelivered、measured、iteratingです。pausedとfailedは終端です。調査前に下書きへ進む、検証前に公開する、納品前に売上成功と判断するといった遷移を禁止します。

各状態には完了条件を持たせます。draftedなら入力と出力の参照がある、verifiedなら独立レビューの結果がある、stagedなら有効な承認範囲がある、measuredなら評価期間と結果がある、という具合です。単なるstatus文字列ではなく、必要な証拠と一緒に遷移させます。

二重実行を防ぐ5つの仕組み

dedupe keyは「記事を作る」では粗すぎます。loop ID、対象、期間、バージョンを含めます。leaseには期限を持たせ、workerが異常終了しても永遠にロックされないようにします。ただし期限切れjobを再取得する前に、外部操作が実行済みでないかを照合します。

3回失敗後は自動で別手段へ切り替えません。failedまたはpausedにし、失敗箇所、最後の安全な状態、再開に必要な判断を通知します。外部API障害で非公式APIへ逃げる、別アカウントを使う、承認を省くといった回避はしません。

残すループは6本だけ

1. Stripe決済・会員権限：署名済みwebhookを冪等処理し、注文、権限、更新、失敗、解約、返金を同期します。
2. 計測QA：イベント欠落、異常値、売上台帳との不一致、未納品を日次で確認します。
3. コンテンツ：実クエリ、匿名診断、社内実証から候補を作り、週3本を上限にします。
4. CV改善：承認済みページ枠で同時1件だけをstagedにし、十分な分母まで待ちます。
5. 商品更新：利用実績と問い合わせを月1回だけ集約し、更新案を作ります。
6. CEO週次レビュー：最大3判断と90分の上限を守り、例外と停止jobだけを渡します。

B2B、採用、POD、輸出、YouTube、最新レポート、広告PDCA、SNSトレンド、毎時会議などは定期実行から外します。成果物とコードは削除せずpaused_legacyとして保持し、将来の事業判断で必要なら一件ずつ再評価します。

スケジュールはjobを作るだけ

timerが直接公開、メール送信、価格変更を実行すると、承認と監査が抜けます。schedulerの責任は、上限とdedupeを確認してqueued jobを作るところまでです。その後、各役割が状態遷移と承認を検査します。Stripeだけは外部webhookが起点になります。

同じtimerが二重に登録されてもdedupe keyが重複jobを防ぎます。起動一覧は定期的に監査し、旧timerと新timerが同じ仕事を動かしていないかを確認します。実際の旧timer停止や本番登録は、サービス影響があるためCEO承認後に行います。

global kill switchは既定でOFFにする

新システムは環境変数が明示されない限り外部ループを起動しません。kill switchを切った時は新規jobの取得、公開、納品、販促メールを止めます。webhookの受信や会計整合性に影響する場合は、停止中イベントを失わない設計と再処理手順が必要です。

再開前にはDB backup、integrity check、失敗job、期限切れlease、承認残数、Stripe eventの重複を確認します。一括で全部を戻さず、計測、内部処理、承認内の外部処理の順に段階的に再開します。

改善は一度に一つ

measuredからiteratingへ進むjobは、何を変えたかを一つだけ持ちます。見出し、価格、CTA、商品内容を同時に変えると結果を説明できません。価格や規約は毎回承認が必要なため、自動CV実験の対象外です。

自動ループの価値は、作業量を最大化することではありません。正しい入力から、検証できる成果物を、一度だけ、安全な境界で外へ出し、結果に応じて止められることです。その条件を満たさないループは、常駐させず人の判断へ戻します。