第10回 許可を設計する（承認疲れとauto modeの境界）

10回目の承認をする頃には、もう読んでいない。ただクリックしているだけだ。

第9回で、自己検証をhooksに組み込んだ。テスト・lint・型チェックは、Claudeの判断に関係なく自動で走るようになった。ここまでは「何を確認するか」の話だった。今回は別の負荷を扱う。体数が増えるほど、承認プロンプトの数そのものが増えるという問題だ。

最初のうちは、1つ1つのプロンプトを丁寧に読んでいたはずだ。このコマンドは何をするのか、このファイルを本当に書き換えていいのか。だが数が増えるにつれて、読む速度が追いつかなくなる。そしてある時点から、内容を読まずにYesを押すだけの作業に変わる。今回はこの変化に名前をつけ、起きる前に手を打つ。

承認疲れの正体

承認疲れには、もう名前がついている。

この現象は、他の現場にもよく似た問題がある。アラーム疲れだ。監視システムのモニターは、本来は異常を知らせるために鳴る。だが同じような警報が何十回も鳴り続けると、担当者は徐々に音を聞き流すようになる。まれに本当に危険な警報が鳴っても、他の音と区別がつかなくなってしまう。

承認プロンプトも同じ構造を持つ。プロンプトの目的は「本当に危険な操作だけ人間に立ち止まらせる」ことなのに、数が多すぎると立ち止まる感覚そのものが摩耗する。

99%承認は意味を失う

許可プロンプトをほぼ毎回無条件で承認するようになった時点で、そのプロンプトはリスクを知らせる合図としての役割を失う。Cat Wuの指摘だ（要旨）。

100回のうち99回Yesを押す運用を続けていると、残り1回の「これは本当に止めるべき操作だ」という信号が、他の99回に埋もれて見えなくなる。プロンプトの数を減らさない限り、この摩耗は止まらない。

auto modeという選択肢

権限モードには段階があり、auto modeは最速だが最も無防備でもある。

auto modeは、承認プロンプトを減らす手段のひとつに過ぎない。公式ドキュメントは、もう2つの手段を挙げている。ひとつはpermission allowlistsで、npm run lintのような安全だとわかっているコマンドだけを、個別にあらかじめ許可しておく仕組みだ。もうひとつはsandboxingで、OSレベルでファイルシステムとネットワークそのものを隔離し、操作が及ぶ範囲自体を狭める。auto modeが確認そのものを省略するのに対し、この2つは確認を残したまま、別の層で安全性を確保する手段になる。

事前許可の設計：何を自動承認し、何を毎回止めるか

許可設計の軸はひとつだけだ。「迷ったら止まって聞く」を既定にする。

Cat Wuのこの発想は、承認設計の軸をそのまま示している。すべてを事前承認するのではなく、「迷ったら止まって聞く」を既定の振る舞いにする。安全な読み取り系の操作は自動で進め、書き込み・削除・外部送信は毎回立ち止まる。境界は曖昧にしない。

よくある誤解と罠

• auto modeを「安全に自動でやってくれるモード」と誤解する。実際は確認を省略するモードであり、破壊的操作も等しく自動承認の対象になる
• sandboxingを「有効にすれば全部守られる仕組み」と誤解する。実際は書き込みが作業ディレクトリだけに制限される一方、読み取りは既定でかなり広い範囲まで許されている。守りたいものによっては、それだけでは足りない場合がある
• 個人設定と組織のポリシーを混同する。個人のsettings.jsonで許可した範囲が、組織全体の運用ルールと食い違っていないか、別に確認がいる
• 「今回だけ」の一時許可を繰り返し、実質的に恒久化してしまう。毎回同じ理由で一時許可を出しているなら、それは一時ではなく設計すべき範囲だというサインだ

今日のまとめ

• 承認疲れは、10回目あたりから内容を読まずにクリックするだけの作業に変わる現象
• auto modeは安全モードではなく、確認そのものを省略するモード
• 安全な範囲は自動化し、破壊的な操作は毎回止まる、という境界を先に決めておく

次は、承認の摩擦が減った先で何を見るかを変える。第11回、差分でレビューする。