FOUNDATION 03 / APPROVAL

承認境界は「ツール」ではなく「操作」で決める

同じブラウザ操作でも、内部ページを見ることと、価格を公開することでは影響が違います。AIに使わせるツールの一覧だけでは安全になりません。何を、どこへ、何回、いつまで、どの上限で実行できるかを操作単位で定義します。

第1階層：自動でよい内部操作

内部分析、草案生成、形式検証、集計、重複確認、テスト、バックアップ検証など、外部の約束や不可逆な変更を生まない操作です。ただし、内部なら無制限でよいわけではありません。個人情報の取得目的、アクセス権、保存期間、ログへの出力を制限し、入力不足や秘密情報の混入を検知したら停止します。

例として、匿名化された診断結果の集計、既存記事と新規構成案の重複チェック、Stripe webhook台帳と納品状態の照合、ローカルbackupのintegrity checkは自動化できます。一方、生の顧客メール一覧を別用途の販促案へ渡すことは内部処理でも許可しません。

影響は外部へ出るものの、対象と上限を事前に限定でき、取り消し可能な操作です。Revenue OSでは週3本までの記事公開、明示同意済み宛先へのメール、承認済みページ枠における同時1件の可逆的CV実験をこの階層に置きます。

承認レコードには、対象、許可する操作、開始・失効日時、回数上限、金額上限、実験範囲、承認者を含めます。「マーケティングを自動化してよい」のような包括承認は使いません。期限切れ、上限到達、対象外URL、成果物の検証未通過では自動停止します。

会社の約束、資金、法的表示、権限、不可逆なデータに触れる操作です。価格、規約、checkoutの有効化、DNS、OAuth同意、本番migration、返金、削除、承認範囲外の公開は毎回止めます。AIは変更案、差分、影響範囲、復帰方法を準備できますが、実行直前の明示承認なしに進みません。

「以前に似た操作を承認した」「開発環境で成功した」「金額が小さい」は承認の代わりになりません。対象環境と操作が一致する承認だけを有効にします。認証情報や個人データの入力が必要になった場合も同じです。

承認は成果物ではなく操作を許可するものです。公開候補が三本あっても、レビュー未通過の記事は承認枠を消費して公開しません。逆に、承認期間内でも異なる商品価格を含む変更は対象外として止めます。

承認はチャットの記憶に置かず、jobと紐づくレコードにします。jobがstagedからpublishedへ進む時に、承認の対象、期限、残回数、リスク階層を検査します。条件を満たさなければpausedへ移し、CEOへ「何を判断すれば再開できるか」だけを通知します。

一度使った承認を別jobへ流用しないため、使用回数と対象IDを記録します。二重実行を防ぐdedupe key、処理中のlease、失敗後のcooldownも同時に使います。承認の有無だけでなく、同じ操作が安全に一度だけ行われることが必要です。

外部操作を持つシステムにはglobal kill switchを設けます。異常時は新しいjobの起動と公開・納品を止め、内部の読み取りと診断に限定します。停止後は直前backupの検証、影響を受けたjobと承認の特定、重複決済や未納品の照合を行い、原因を直してから段階的に再開します。

kill switchを切るだけでデータは戻りません。DBを復元する場合はscheduler停止、復元対象の明示、backupの完全性確認、現在DBの退避、restore後の照合という順序を守ります。本番復元は第3階層です。

CEOへ渡すのは全ログではなく、売上と流入、CV、会員、障害、CEO時間、期限が近い承認、停止中jobです。判断は最大三つに制限します。現状を継続する、一つの仮説だけ変える、成果のないループを止める。判断が増えた週は、追加の新施策を始めません。

良い承認境界はAIを止める壁ではなく、人間が重要な責任だけを短時間で引き受けるためのインターフェースです。何も起きていない週に承認会議を開く必要はありません。例外が生まれた時だけ、必要な判断が明確に届く構造を目指します。