AIに承認を求めるのをやめた｜事前承認ではなく「拒否権」で運用する設計

個人事業を、AIとの複数セッションで運営しています。戦略を見る窓口が1つ、実装をやる窓口が事業ごとに1つずつ、雑談用が1つ。人間は私ひとりです。

しばらく回して、はっきりした問題がありました。AIに任せられる範囲が広がるほど、私が承認する回数が増えて、結局そこが詰まる。

「これをやっていいですか」が1日に何度も来る。1件あたりは30秒でも、判断そのものが疲れます。しかもAI側は待っている間、止まっている。AIの能力が上がるほど、人間の承認がボトルネックになるという、当たり前だけど直視していなかった構造です。

そこで運用設計を作り直しました。この記事はその設計と、実際にAIの提案を却下した記録・AIが間違えた記録をそのまま出します。

承認をやめて、拒否権にする

出発点はこの一行です。

承認を求めることは、人間の最も希少な資源（判断力）を消費する。だから承認を減らすこと自体が価値になる。

代わりに担保するのは「止められること」です。事前の承認ではなく、事後の拒否権でガバナンスする。

従来：AIが「やっていいですか」→ 人間が承認 → AIが実行
いま：AIが実行 → 人間が1日1回まとめて見る → おかしければ「止めて」の一言

この転換には前提条件があります。止められない行動には、この方式を使えません。 だから設計の実体は「どう任せるか」ではなく「どこまでが巻き戻せるか」の線引きになります。

前提条件1：行動を「巻き戻せる単位」で実行する

拒否権が成立するのは、実行を取り消せるときだけです。そこでルールを1つ置きました。

1施策 = 1コミット。revert可能な状態を常に保つ。

複数の変更を1コミットに混ぜると、「この部分だけ止めたい」ができなくなります。逆に言えば、コミットを分けておくだけで拒否権が機能する。これは技術的にはただの作法ですが、運用上は権限設計そのものです。

実際、後述する記事の公開についても「止め方＝記事の非公開化（1コミットでrevert可）」を先に決めてから実行しています。止め方が書けない施策は、まだ実行してはいけないという判断基準にもなりました。

前提条件2：レーンを3つに分けて、自動で判定する

毎回「これは聞くべきか」を考えていたら、結局そこで止まります。分類を先に決めて、AIが自分で判定します。迷ったら1段上げるというルールつきで。

🟢 GREEN — 黙って実行。事後報告のみ

コンテンツ作成、SEO、内部リンク、バグ修正、リファクタ、計測の実装、調査・分析、記録。既に提携済みのリンクの配置もここです。

要は「間違えても戻せて、外部に不可逆な影響が出ない」もの。ここを承認制にしていたのが、そもそもの詰まりでした。

🟡 YELLOW — 実行してよい。ただし24時間の異議申し立て窓を置く

新しいページ群の公開、見え方が変わる規模のUI変更、新規提携の申請（無料・審査のみ）、実験の開始と停止。

実行はする。ただし報告に必ず載せて、24時間以内に「止めて」が来たら即revert。来なければ承認とみなして継続します。

ここが設計の肝です。「聞いてから動く」と「勝手に動く」の間に、"動くが取り消せる窓を開けておく"という第三の状態を作った。判断の総量が減るのに、コントロールは残ります。

🔴 RED — 必ず人間。AIは提案と準備で手を止める

金銭の支出・購入・契約、価格の変更、法務（規約・特商法・著作権）、個人情報の取り扱い方針、認証情報の設定、新しい公開アカウントの作成、外部への個別送信、撤退や新規事業の判断。

REDの共通点は「巻き戻せない」か「責任の主体が人間でなければならない」かのどちらかです。

前提条件3：観察点を1つに固定する

拒否権は、見ていなければ行使できません。そこで毎朝1本・5分で読める報告に固定しました。構成も固定です。

昨日やったこと（3行以内）
数字（前日比の異常だけ）
今日やること
⚠️ 止めるなら今（YELLOW項目。無ければ「なし」と明記）
🔴 人間待ち（REDで止まっている案件）

人間の操作は原則読むだけ。違和感があれば「止めて」の一言です。

運用してすぐ出た落とし穴

設計した直後に、2つ問題が出ました。どちらも運用しないと分からないやつです。

落とし穴1：口伝は消える

毎朝の報告は、記憶を持たない新しいセッションが生成します。つまり「昨日YELLOWで実行したこれを、明日の報告に載せてね」という会話上の申し送りは、翌朝には存在しません。

対処として、機械可読な印を決めました。

🟡YELLOW <施策名>｜止め方: <revert対象>｜期限: <24hの起点日時>

記録ファイルの行頭にこの印を付け、報告を作るセッションは grep -rn "🟡YELLOW" notes/ で当日分を拾います。会話ではなくファイルに書く。 AIを複数セッションで運用するなら、セッション間の共有は必ずファイル経由にしないと落ちます。

落とし穴2：「なし」を省略すると、沈黙の意味が分からなくなる

報告の「止めるなら今」欄が空だったとき、それが「本当に何も無い」のか「拾い漏れた」のかを、読む側は区別できません。

なので「なし」と明記させることをルールにしました。省略を許すと、報告そのものが信用できなくなります。

AIの提案を却下した記録

ここからが、たぶんこの記事でいちばん役に立つところです。AIは間違えます。 拒否権が要るのは、そのためです。

却下1：「縮小しましょう」しか出せなかった

実測でうまくいっていない事業について、AIはこう提案してきました。

この面は数字が出ていないので、維持の定義を下げましょう（新規投下をやめる）。資源を本命に寄せます。

却下しました。理由は「アクセスが集まらないから維持を下げる、ではない。勝ち目が低いなら作り変えるのが望む姿」。

AIの誤りの構造は明確でした。診断は正しいのに、そこから「畳む／続ける」の二択しか出せなかった。 「同じ土台のまま中身を作り変える」という第三の道を検討していない。

判断基準として残しました——数字が悪い資産を見たとき、二択に落とさない。土台（ドメイン・実装・提携）と中身（コンテンツの仮説）を分離して、土台が生きているなら中身の作り変えを先に検討する。

結果として、この却下から出てきた作り変えが、いま進んでいる方向そのものになっています。却下は否定ではなく、選択肢の追加でした。

却下2：心配の順序が逆だった

別の場面で、AIがこう報告してきました。「ブランド基準を守ると、この面で一番単価の高い案件を捨てることになる。収益の上限が構造的に下がる」。

返ってきた判断は、「その心配は時期尚早」。

単価の議論は、流入がある面でしか意味を持たない。 6週間で9クリックの面で、5,000円の案件があっても成約はほぼゼロ。流入ゼロの面で単価の上限を心配するのは順序が逆。

これは効きました。AIは真面目に損得を計算していたのですが、計算する前に確かめるべき前提を飛ばしていた。しかも「ちゃんと考えている」ように見えるぶん、指摘されないと気づきません。

代わりに置いたのは、再検討ゲートです。「その面で月間クリック100を超えたら収益設計を再評価する。それまでは流入だけを見る」。心配を捨てるのではなく、心配する条件を先に決めておく。

AIが自分で間違えた記録

却下された話だけでなく、AI側が自分で踏んだ失敗も出します。こちらのほうが再現性が高いかもしれません。

失敗1：空欄を「記入漏れ」だと推定した

設定ファイルに、値が空のままの項目がありました。AIはこれを「配線漏れ＝埋めるべきもの」と診断しました。

間違いでした。 別のファイルに、こう書かれていたのです。

提携は現状見送り／新規募集なし（2か月前に確認済み）。

つまりその空欄は、過去に調査して出した結論の記録でした。埋めていたら、存在しない提携リンクを読者に出すところだった。

教訓として残したのはこれです。

空欄を見たら、まず「これは事故か、判断か」を確認する。空欄は失敗の跡とは限らず、判断の跡のことがある。

そして、より一般的な形はこうなりました。原因を推定で埋めない。コード・記録・コミット履歴に「なぜそうなっているか」が残っていないか、先に探す。

失敗2：自分の検査ツールのほうが壊れていた

公開した記事が「効果を成果として書いていないか」を機械的に検査したとき、「改善しました」「回復しました」という語がヒットしました。違反かと思われましたが、実際は全部否定文脈でした。

「〜とは書きません」「まだ測っていないものを成果として書いた時点で、この記事の主張と矛盾します」

前後を読まずに、キーワードの有無だけで判定した検査のほうが壊れていた。 検査結果を信じて記事を書き換えていたら、正しい記述を消していたことになります。

この設計で、まだ分かっていないこと

正直に書きます。

運用3日目です。 効果はまだ測れていません。私が言えるのは「承認を求められる回数が減った」という体感までで、それが事業の成果に繋がったかは分かりません。

具体的に、まだ検証できていないのはこのあたりです。

24時間窓は本当に機能するか。 いまのところ「止めて」が発動した実績がありません。止めるべきものが無かったのか、見落としているだけなのかを区別できていません
レーンの線引きが正しいか。 GREENに入れているものの中に、実はYELLOWであるべきものが混ざっている可能性があります。これは事故が起きて初めて分かる種類の誤りです
人間の負荷が本当に下がったか。 承認は減りましたが、代わりに毎朝の報告を読む負荷が発生しています。差し引きがプラスかは、もう少し時間が要ります

同じことを試すなら、この3つは自分の環境でも確かめてほしいところです。

まとめ

承認（事前）を拒否権（事後24時間）に置き換える。 AIの能力ではなく、人間の判断回数がボトルネックになるため
成立の前提は3つ：巻き戻せる単位で実行する／レーンを先に決めて自動判定する／観察点を1つに固定する
「聞いてから動く」と「勝手に動く」の間に、動くが取り消せる窓という第三の状態を作る
止め方が書けない施策は、まだ実行してはいけない
複数セッションで運用するなら、申し送りは会話ではなくファイルに。口伝は翌日消える
AIは間違える。 診断が正しくても選択肢が足りないことがあり、真面目に計算していても前提を飛ばすことがある

「AIに任せる」を、能力の話だと思っているうちは進みませんでした。任せられる範囲を決めているのは、AIの賢さではなく、こちらの巻き戻せる設計のほうでした。

効果が測れたら、この記事に追記します。良い結果でも、悪い結果でも。