判断の仕組みi-Willink
AIが社長の承認を待ち続けた理由
社内で完結する変更まで、AIが社長のマージ待ちにしていました。正しいルールはあったのに、毎回読まれる要約と古いメモが判断を決めていたのが原因です。何が起きたか、5つの原因、機械で止める仕組みに変えた手順をまとめます。
承認のルールそのものは正しかったのに、AIは社内の変更まで社長の承認を待っていました。判断を決めていたのは、ルールの本文ではなく、毎回読まれる短い要約と、引き継がれた古いメモでした。
私たちは、実務の多くをAI（Claude Code）に任せ、社長は外に出るものの決裁だけを持つ形で会社を回しています。承認が要るかどうかは「元に戻せるか・外に届くか・お金や法律が絡むか」で決める、というルールも以前から書いてありました。
それでも先日、社長からこう言われました。「毎回ドラフトでPR出すのなぜでしょうか？ 毎回私の承認が必要になっていて、手間で待ちが発生します。内部の決定は基本的にもう全て委ねます」。この記事は、その原因を調べて直した記録です。
この記事の要点
- 1ルールの本文は正しかった。止めていたのは、毎回読まれる要約の一文「マージは事前承認」と、新しい作業に引き継がれた古いメモだった
- 2要約で除外条件を書くとき「どのリポジトリの話か」が抜けると、全部のマージを止める一文になる
- 3直し方は「気をつける」ではなく機械の検査。社長に回す承認には「外に出る理由」を6種類から選ばせ、無ければ検査で落とす
何が起きていたか
社内だけで完結する変更まで、AIが「下書き」の状態で出し、社長がマージするのを待っていました。
私たちの会社では、変更はGitHubのプルリクエスト（PR）で出し、自動の検査が通ったら本流に取り込みます（マージ）。社内向けの管理画面の裏側や、動画を作る仕組みの改良など、社外の人には一切届かない変更も同じ流れです。
ある1週間に作ったPRを数えると、63本のうち17本が「下書き（ドラフト）」のまま、18本がマージされずに残っていました。どれも検査は通っていて、残っていた理由は「社長のマージ待ち」でした。社長が画面を見られる時間は限られているので、待ちはそのまま半日、1日の遅れになります。
ルールの本文は、そう書いていなかった
承認のルールの正本には「社内のマージは事前承認」とはどこにも書いておらず、むしろ即実行の側でした。
まず正本を読み直しました。承認のルールは3段階で、社内で完結し、元に戻せて、お金も法律も絡まないものは即実行です。開発作業はその例に入っていて、ブランチの規約には「自分で出したPRでも自動マージを使う」と書いてありました。
つまり、ルールどおりに動けば待ちは起きないはずでした。それでも待ちが起きたのは、AIが判断のたびに読んでいたのが正本ではなかったからです。
原因は5つあった
実行環境の既定、要約の一文、公開サイトの慣習、表の空白、古いメモの5つが重なっていました。
1. 実行環境の既定が「PRは下書きで出す」だった。AIを動かしているクラウドの環境は、何も指定しなければPRを下書きで出すように指示しています。社内のルールに「社内のPRは下書きにしない」という上書きが無かったので、AIは既定に従いました。
2. 要約の一文が、対象を落としていた。以前、顧客と共同で運用しているリポジトリについて「マージ・リリース・顧客への連絡は社長の承認」と決めました。ところが、AIが毎回最初に読む短い要約には「マージ・リリース・顧客連絡・5万円超・新しいチャネルは事前承認」とだけ書かれ、「顧客のリポジトリでは」という対象が抜けていました。この一文が、全部のマージを止めていました。
3. 公開サイトの慣習が、社内の変更にまで広がった。会社のWebサイトは、マージするとそのまま公開されます。だからサイトの見た目や文章の変更は、社長のマージを「公開の承認」にしてきました。同じリポジトリに社内向けの管理画面も入っていたため、管理画面の変更も同じ扱いになっていました。
4. 表に行が無かった。即実行の一覧に「社内PRのマージと配置」という行がありませんでした。書いていないものは、安全側に一段上げて扱われます。さらに社長に回す宿題の一覧では、「事前承認です」と名乗れば理由なしに社長へ回せました。即実行や事後報告の項目を社長に回すときは理由を求める検査があったのに、事前承認には無かったのです。
5. 古いメモが引き継がれていた。作業をまたいで残すメモに「マージは事前承認」「自動の安全判定がマージを止めるので社長が押す」と書かれ、新しい作業を始めるたびに読み込まれていました。
要約は正本より強く効く
毎回読まれる短い要約とメモは、たまにしか開かれない正本よりも、実際の判断を強く決めます。
今回いちばんの学びはここでした。正本は長く、必要なときにしか開かれません。一方で要約とメモは、毎回の作業の最初に読まれます。読まれる回数が多いほど、そこに書いた一文が判断を決めます。
そして要約は、書くたびに少しずつ意味が変わります。「顧客のリポジトリでは、マージは承認」が、「マージは承認」になる。言葉を削ったつもりで、対象を削っていました。除外条件を要約するときは、どのリポジトリ・どの面の話かを必ず一緒に書く。これを社内のルールに加えました。
直したこと：社長に回すのは「外に出るもの」だけ
社長の承認が要るものを6つの種類に限り、社長に回すときは必ずそのどれかを書かせ、書いていなければ検査で落とすようにしました。
社長の承認が要るのは、次の6つのどれかに当たるものだけにしました。一般の人に届くもの（公開・配信・投稿）、社外の相手への連絡や合意、お金、契約や規約、自分たちを締め出しかねない権限や鍵の操作、本番データの破壊。当たらないものは、AIが決めて実行し、必要なら事後に報告します。
社内のPRは下書きにせずに出し、検査が通ったらAIがマージして、本番に反映されたかまで確かめます。同じリポジトリに社内向けと公開用が同居している場合は、リポジトリ名ではなく「その変更が公開される面を変えるか」で決めます。
そして「気をつけます」で終わらせないために、社長に回す宿題の一覧に検査を足しました。事前承認として社長に回すなら、上の6種類のどれに当たるかを書かないと検査が赤になります。その日に残っていた27件にも種類を付けたところ、1件は「社長しか知らない情報が要るだけ」で、事前承認ではありませんでした。
コマンドの許可も同じ線で引き直した
AIが打つコマンドも、基本は全面許可にし、取り消せないものとお金がかかるものだけ確認を挟むようにしました。
同じ日に社長から「コマンドの承認もCOOに任せます。不可逆なものや費用が発生するものだけ許可を」と言われました。そこで、削除、課金、ドメインの設定、鍵の失効、公開のリリース、社外へのメール送信といった操作だけを「必ず確認」に置き、それ以外は許可しました。強制的な上書きや全消去のような操作は、これまでどおり禁止のままです。
あわせて、もともとAIの判断に任せていた公開物（ゲートを通った記事や定型の告知など）は、機械の検査が通れば公開してよいことになりました。動画の中身の確認だけは、引き続き社長が行います。
よくある質問
AIに社内のマージまで任せて、壊れたときはどうしますか？
マージの前に自動の検査が通ることを条件にし、マージの後は本番に反映されたかを実際に確かめます。壊れたらAIが直します。元に戻せる社内の変更なので、事前の承認より、速く直せることを優先しています。
要約やメモを使わなければ、こうした事故は起きませんか？
要約を使わないと、毎回長い正本を読むことになり、作業が遅くなります。私たちは要約を残したうえで、除外条件には対象を必ず書くこと、承認に回すときは理由を機械で確かめることで防いでいます。
6種類に当たるかどうか迷ったら？
「外部の人に届くか」で判断します。届かず、元に戻せて、お金も法律も絡まないなら、AIが実行します。届くか分からないときは、何が分からないのかを書いたうえで社長に回します。
参考・出典
- Claude Code: Configure permissions（公式ドキュメント）（許可・確認・禁止の3段のルールと、その評価の順番）
- Claude Code: Configure auto mode（公式ドキュメント）（自動の安全判定が、リポジトリ側の設定ではなく端末側の設定を読む理由）