Claude Codeへの承認、1週間で何回発生し何をやめたか
1週間で何回「Yes」を押したか
社内のプロダクト開発でClaude Codeを使い始めてから、承認ダイアログの回数を記録してみました。1週間の内訳はおおよそ次のようになりました。
| 操作の種類 | 回数の目安 |
|---|---|
| ファイル編集の確認 | 60〜70回 |
| bashコマンド実行（npm install, test実行など） | 40〜50回 |
| git操作（commit, branch作成） | 20回前後 |
| 外部API・Web取得 | 10回前後 |
| 破壊的操作（rm, force push相当） | 5回未満 |
合計すると1日20〜25回、1週間で150回前後の「Yes」を押している計算でした。この数字自体は環境やタスクの粒度で大きく変わりますが、重要なのは中身の9割以上が「本来止める必要のない操作」だったという点です。
承認が多いと何が起きるか
承認ダイアログは安全装置ですが、頻度が上がると機能が壊れます。理由は単純で、人間は同じ確認を何十回も繰り返すと「内容を読まずにYesを押す」状態に移行するからです。これは注意力の限界の問題であって、意識の問題ではありません。結果として、承認という仕組みが「実質的にノーガードで実行している」状態と変わらなくなります。
もう一つの問題は作業の分断です。Claude Codeにまとまったタスクを渡しても、数十秒おきに手が止まると、結局は人間が横に張り付いて監視するのと工数が変わらなくなります。エージェントに任せる意味が薄れます。
危険度で操作を3段階に分ける
承認をゼロにするのではなく、「止める価値のある操作だけ止める」設計に切り替えます。目安は次の3段階です。
- 常に自動許可（allow）: ファイルの読み取り、lsやgrep、テストの実行、ローカルブランチでのcommit
- 都度確認（ask）: 依存パッケージの新規追加、既存ファイルの大幅な削除、mainブランチへの直接操作
- 常に拒否（deny）: 本番環境への接続、force push、秘密鍵や環境変数ファイルへのアクセス
Claude Codeでは.claude/settings.jsonにこの分類をそのまま書けます。
{
"permissions": {
"allow": ["Bash(npm test:*)", "Read(*)", "Bash(git commit:*)"],
"ask": ["Bash(npm install:*)", "Bash(git push:*)"],
"deny": ["Bash(rm -rf:*)", "Read(.env)"]
}
}この設定を書いた時点で、150回中100回以上の承認が消えました。残った承認は「本当に人間の判断が要る操作」だけになります。
CLAUDE.mdでルールを言語化する
settings.jsonはコマンド単位の許可、CLAUDE.mdは判断基準の共有です。「テストが通らないコードはcommitしない」「新規ライブラリ導入時は理由を1行コメントで残す」といったルールを書いておくと、都度確認すべき場面でもAI自身が事前にセルフチェックしてから提案してくるようになり、askの発生頻度自体も下がっていきます。
信頼できる箱を作って隔離する
より攻めた運用をしたい場合は、Dockerコンテナやgit worktreeで作業領域を本番から物理的に切り離し、その隔離環境の中だけ--dangerously-skip-permissionsで全自動実行する方法があります。前提は「その箱の中で何が起きても本番に影響しない」ことです。壊れたら箱ごと作り直せる状態を先に作ってから、権限を緩めるという順序が逆になると事故につながります。
承認を減らした分、どこで守るか
事前の承認を減らした分は、事後の検証で埋めます。CI上でのテスト実行、型チェック、Lintを必須化し、pull requestの差分は人間が最終レビューする。承認は「実行前に止める」ためのものですが、実行後に検証する仕組みがあれば、実行前の確認を減らしても事故の検知は可能です。承認回数を減らすことと、品質担保を諦めることはイコールではありません。
広告運用にも同じ設計が使える
この考え方は広告の自動運用でも同じ構造です。入札額の微調整や配信時間の最適化は自動化し、月間予算の上限変更や配信停止といった影響の大きい操作だけ人間の承認を残す。私たちがバーチャルCMO事業やAdsyncで自動化の範囲を設計するときも、判断基準は「危険度で線を引く」という一点に尽きます。承認回数を数えることは、どこまで機械に任せてよいかを可視化する最初の一歩です。