判断の仕組みi-Willink
承認は「元に戻せるか」で決める
「迷ったら慎重に承認をもらう」は、戻せる軽い作業まで止めて会社を遅くします。私たちは判断の軸を、元に戻せるか・外に届くか・お金や法律が絡むかの3つに替えました。決め方と、戻せるかを実測で確かめる規律をまとめます。
承認が要るかは「重要そうか」ではなく、元に戻せるか・外に届くか・お金や法律が絡むか、の3つで決めます。戻せるかは思い込みでなく、実際に確かめてから判断します。
「迷ったら承認をもらう」「迷ったら慎重に」。誠実に聞こえるルールですが、私たちの会社ではこれが、いちばん仕事を止めていました。
私たちは、実務の多くをAI（Claude Code）に任せ、社長は最終判断と外向きの決裁に絞っています。この形で最初にぶつかったのが、「どこまでAIに即断させ、どこから人に上げるか」の線引きでした。この記事は、その線引きを引き直した社内ルールの記録です。
この記事の要点
- 1「迷ったら上に上げる」は、戻せる社内作業まで承認待ちに積み、いちばん時間の少ない人を全作業の詰まりにする
- 2軸は3つ。元に戻せるか、外に届くか、お金や法律が絡むか。戻せて社内で完結し、お金も法律も絡まないものは即実行する
- 3「戻せるはず」は認めず、実際に確かめる。権限や鍵、監視の停止のように自分を締め出しかねない操作は、軸に関わらず人に上げる
「迷ったら承認」が会社を遅くしていた
重要そうだから、迷うから、と承認に回すと、本当は戻せる社内作業まで承認待ちに積み上がります。
最初に作った承認のルールは、作業を3段階に分けるものでした。1段目は即実行、2段目は事後報告、3段目は事前承認。そして安全のために「迷ったら3段目」と決めていました。
運用してみると、承認待ちに積み上がるのは危ない判断ではありませんでした。「技術的に重そう」「なんとなく大事そう」というだけの、本当は元に戻せる社内作業ばかりです。社長ひとりの時間は限られているので、承認の列は伸びる一方でした。
安全のつもりのルールが、いちばん時間の少ない人を、全部の作業の詰まりにしていたのです。AIで作業を速くしても、承認の決め方が古いままだと全体は遅くなる。私たちはこれを「負の自動化」と呼んでいます。
判断の軸を3つの問いに替えた
「重要そうか」をやめ、元に戻せるか・外に届くか・お金や法律が絡むか、の3つで承認の要否を決めます。
判断の軸そのものを入れ替えました。問いは3つです。
- 元に戻せるか。社内の文書の直しや、同じものを入れ直すだけの再公開のように、間違えてもすぐ戻せるものは軽く扱う
- 外に届くか。社内で完結する作業と、お客さんや一般に届くものを分ける。送ったメールや公開した投稿は、見られた事実が取り消せないので、届いた時点で戻せないと考える
- お金や法律が絡むか。一定額を超える支出、契約、価格、利用規約のような文書の公開は、無条件で人に上げる
この3つで振り分けます。戻せて、社内で完結して、お金も法律も絡まないものは、AIが即実行してよい。社内だが戻せないもの、外に届くが戻せるものは、実行して事後に報告する。外に届いて戻せないものや、お金や法律が絡むものは、事前に承認をもらう。迷いではなく、問いの答えで決まります。
考え方の土台は、Amazon の株主への手紙にある「片道のドアと両開きのドア」です。戻れない決定は慎重にじっくり、戻せる決定は小さな単位で素早く決めてよい、という整理で、私たちはこれを承認の仕組みにそのまま当てはめました。
「戻せます」を思い込みで通さない
戻せるかどうかは、見立てではなく、実際に確かめてから判断します。確かめられないものは一段上げます。
この決め方には落とし穴があります。「戻せるので実行しました」という申告をそのまま信じると、軸が形だけになります。人もAIも、「たぶん重複だから消しても平気」「もう取り込み済みのはず」と、確かめずに戻せると判断してしまう瞬間があります。
なので私たちのルールでは、戻せるかを実際に確かめてから即実行の段に入れます。変更の取り込み状態なら、その場で今の状態を取得する。消して平気かは、対象を一覧と照合する。インフラの変更なら、差分を出して壊すものが無いことを確かめてから動く。確かめられないなら、一段上げて人に回します。
「戻せると思う」と「戻せると確かめた」は別物です。この線をルールに書いたことが、いちばん効きました。
自分を締め出す操作は、いつも人に上げる
権限の変更、鍵の再発行や無効化、監視の停止、本番の設定やドメインの変更は、軸に関わらず事前承認にします。
軸で振り分ける一方で、軸に関わらず必ず人に上げると決めた操作もあります。代表が、自分自身の実行権限や、壊れたときの戻し方そのものに触る操作です。
権限設定の変更、鍵やトークンの再発行や無効化、監視の停止、本番の環境の設定やドメインの変更。これらは失敗すると、壊した手段でしか戻せない、という行き止まりに入ります。AIが自分で自分を締め出すと、人が手で救い出すしかありません。だからここは戻せるかの議論を持ち込まず、いつも事前承認にしています。
安全のための例外は、「迷ったら全部」ではなく「自分を締め出す操作だけ」に絞る。これが古いルールとの決定的な違いです。
迷ったら「これは戻せるか」に置き換える
迷いは対象の危なさより、自分の慣れを映していることが多いので、「これは戻せるか」という問いに置き換えて決めます。
運用してみて分かったのは、「迷う」という感覚は判断の材料として頼りないことです。初めて触る作業は、戻せるものでも重く感じます。迷いは、対象の危なさより自分の慣れ具合を映していることが多いのです。
だから迷ったら、その気分を一度「これは戻せるか」に置き換えます。戻せるなら進む。戻せないなら立ち止まり、外に届くか、お金や法律が絡むかを確かめる。手順はこれだけです。
やってみて変わったこと
社長の承認リストが本当に人が見るべきものだけになり、判断すべき場所に判断が集まるようになりました。
切り替えて変わったのは、社長の承認リストが「本当に人が見るべきものだけ」になったことです。社内の文書の整理や入れ直すだけの再公開で止まらなくなり、外向きの公開やお金が絡む判断は確実に人の目を通ります。判断の量が減ったのではなく、判断すべき場所に判断が集まりました。
慎重さは減らしていません。全部に薄く慎重だった状態から、危ないものに濃く慎重な状態へ、配り方を変えただけです。人が自分で決める場面でも同じように効きます。手元の作業を1つ、3つの問いに当ててみてください。戻せて社内で完結するとはっきり言えるものは、もう自分の裁量で進めてよいはずです。
この承認の決め方を含む運営の雛形は、ai-coo-starter として公開しています。止まらずに判断を回す仕組みは判断を止めない仕組みの記事に書いています。
よくある質問
「元に戻せる」作業とは、具体的にどんなものですか？
社内の文書の直し、同じものを入れ直すだけの再公開、取り消しのきく設定値の調整などです。ただし戻せるかは見立てでなく、前の状態に本当に戻せるかを確かめてから判断します。
外に届くけれど元に戻せる作業は、承認なしで進めていいですか？
私たちは、実行して事後に報告する扱いにしています。たとえば決まった型どおりの告知の修正などです。ただしメールの送信のように、届いた時点で取り消せないものは戻せない扱いにして、事前に承認をもらいます。
少人数の会社でも承認のルールは必要ですか？
少人数ほど必要です。承認する人の時間がいちばん少ないので、何でも上に上げる形だと、その人が全作業の詰まりになります。上げるものを3つの問いで絞ると、判断が必要な場所に時間を使えます。
AIに即実行を任せて、事故は起きませんか？
即実行は、戻せて社内で完結し、お金も法律も絡まない作業に限っています。戻せるかは実際に確かめることを求め、自分の権限や監視に触る操作はいつも人に上げるので、取り返しのつかない事故を防ぐ形にしています。
参考・出典
- Amazon.com: 2015 Letter to Shareholders（米国証券取引委員会への提出資料）（戻れない決定と戻せる決定を分け、戻せる決定は素早く決めてよいという「片道のドア・両開きのドア」の考え方）
- ai-coo-starter（GitHub）（この記事の承認の決め方を含む、私たちが公開している運営の雛形）