Claude Codeに「どこまで任せる」を毎朝5分で決める権限とコストの回し方

「テスト通すついでに、依存関係も整えといて」

軽い気持ちでそう頼んだ夜、Claude Codeは npm install を3回叩いて、ついでに git push まで通していました。翌朝請求を見たら、いつもの一日の倍。pushされたブランチには、入れた覚えのないライブラリが4つ。

事故ではないんです。僕が Bash(npm *) を許可リストに入れていたから、Claude Codeは「許された範囲」で正しく動いただけ。怖いのはここで、賢いAIほど、渡した権限のフチまできっちり使い切る。財布を渡して「いい感じに買い物して」と言えば、いい感じに使い切る。当たり前の話でした。

それ以来、僕は朝の5分を「権限とコストの点検」に使っています。今日はそのループを、専門用語をなるべく崩しながら共有します。

この記事の要点

• Claude Codeの権限は allow（黙って実行）・ask（人間に確認）・deny（禁止）の3段で、評価は deny → ask → allow の順。最初に当たったルールが勝つ。
• Bash(npm *) のような雑な許可が事故の元。毎日使うコマンドだけ狭く allow し、install・push・deployは ask に置く。
• コストは /usage でセッションを、Claude ConsoleのUsageで実請求を見る。月の上限は /usage-credits、チームはworkspaceのspend limitで止める。
• 「権限を1日だけ開いて閉じ忘れる」が一番起きる。だから点検は一回きりではなく、毎朝の習慣にする。
• この記事の最後に、設定・予算・当日ログをチェックする監査スクリプト（依存ゼロ）を置いた。コピペで回せる。

なぜ「賢さ」より「柵」なのか

最初に勘違いしていたのは、CLAUDE.md に「秘密情報は読まないで」と書けば守ってくれる、という思い込みでした。

公式ドキュメントがはっきり書いています。権限ルールを強制するのはモデルではなく、Claude Code本体（CLI）です。つまり CLAUDE.md の指示は「Claudeがやろうとすること」を形づくるだけで、「Claude Codeが許すこと」は変えません。お願いは方針、設定は柵。境界にしたいなら、お願いではなくルールで書く必要があります。

例えば .env を守りたいなら、文章でお願いするのではなく、こう置きます。

{
  "permissions": {
    "deny": ["Read(.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}

Read(.env) はgitignoreと同じ書き方で、カレント以下のどの階層の .env にも効きます。ファイル単位で確実に止まる。「読まないでね」と祈るより、よっぽど夜が静かになりました。

権限の3段とモードを5分で頭に入れる

仕組みは難しくありません。覚えるのは2つだけです。

ひとつはルールの3種類。allow は確認なしで実行、ask は毎回確認、deny は禁止。評価順は deny → ask → allow で、最初に当たったルールが勝ちます。だから deny が常に最強。迷ったら deny に入れておけば、下の許可をすり抜けることはありません。

種類	意味	置くもの
allow	黙って実行	読む・lint・test・build など安全で毎日使うもの
ask	人間に確認	install・push・deploy・migration など外を変えるもの
deny	禁止	.env/secrets読み取り、curl/wget、rm -rf

もうひとつは権限モード。defaultMode を設定ファイルに書いて、全体の振る舞いを決めます。公式が用意しているのは次の通りです。

• default: 標準。各ツールの初回に確認を出す。
• plan: 読み取りと調査だけ。ソースは編集しない。最初の調査に向く。
• acceptEdits: ファイル編集と mkdir・mv などを自動で受ける。作業が乗ってきたとき。
• dontAsk: allow に入っていない操作は自動で拒否。許可リスト方式にしたいとき。
• auto: 背景の安全チェック付きで自動承認（リサーチプレビュー段階）。
• bypassPermissions: 全確認をスキップ。--dangerously-skip-permissions がこれ。

最後の bypassPermissions は、コンテナやVMなど「壊れても困らない隔離環境」専用です。rm -rf / のような致命的な操作には保険として確認が残りますが、それでも普段の作業フォルダで常用するものではありません。組織で完全に封じたいなら、管理者設定で permissions.disableBypassPermissionsMode を "disable" にできます。

毎朝5分のpermission budget loop

長い監査会議にすると続きません。目的は完璧な棚卸しではなく、危ない許可を開いたまま一日を始めないこと。見る場所を5つに固定して、機械的に流します。

順番	見るもの	合格条件
1	/permissions	Bash（全許可）や広すぎる Bash(npm *) がない
2	.claude/settings.json	secrets・deploy・DB・課金が ask か deny にある
3	/usage と Console	前日からコストが不自然に増えていない
4	git diff と実行ログ	許可した作業と差分が一致している
5	引き継ぎメモ	開いた許可・止めた作業・次の確認者が書いてある

朝イチのプロンプトも短く決め打ちしておくと、考えずに済みます。

今日のClaude Code作業を始める前に、次の3分類で提案して。
1. 承認なしで進めてよい作業
2. 人間の承認が必要な作業
3. このセッションでは実行しない作業
そのあと、/permissions と /usage と git diff で確認すべき点を5項目以内で。

このループの肝は、3番です。/usage はセッションのトークン使用量と概算ドルをローカルで計算して見せてくれますが、これはあくまで推定。最終的な請求はClaude ConsoleのUsageページが正です。僕は週に2回、/usage の数字とConsoleの実請求を突き合わせる日を決めています。見積もりと実請求のズレに早めに気づけると、月末に吹かずに済みます。

使いすぎを「先に」止める設定

権限は半分、もう半分はコストです。Claude Codeの作業は、長い調査・複数エージェント・何度も失敗するテスト修正で静かに膨らみます。公式が示す実測でも、平均はだいたい1人あたり1営業日13ドル前後。油断するとここを超えます。

止め方は段階で持ちます。

1. セッション単位: /usage で随時チェック。d / w で直近24時間と7日を切り替えられる。ステータスラインに常時表示しておくと、走らせながら見える。
2. 月単位（個人）: ProやMaxプランなら /usage-credits で月の上限を設定。上限に達するとClaude CodeがCLI内で「上げる？外す？」と聞いてくるので、作業を中断せず判断できる。
3. チーム単位: Claude APIを使うworkspaceに spend limit をかける。最初に認証すると「Claude Code」というworkspaceが自動で作られ、組織のClaude Code使用量がここに集まる。管理者はConsoleでコストとレートを見られる。

トークンそのものを減らす手も併用します。タスクが変わったら /clear で文脈を捨てる（古い文脈は毎メッセージ課金される）。モデルは /model で切り替え、調査やコーディングの大半はSonnet、込み入った設計だけOpus。深い推論が不要な作業は MAX_THINKING_TOKENS=8000 のように思考トークンを絞る。/context で今なにが文脈を食っているか覗けるので、MCPサーバーの入れすぎにも気づけます。

チームで配る settings.json の出発点

ここまでを1つの設定にまとめます。共有用の .claude/settings.json に置く叩き台です。defaultMode: "dontAsk" にすると、allow か ask に入っていない操作は通りません。チーム導入では強すぎる場合があるので、まず自分のローカルで試してから共有に移すのがおすすめです。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test)",
      "Bash(npm run test *)",
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff)",
      "Bash(git diff *)",
      "WebFetch(domain:code.claude.com)"
    ],
    "ask": [
      "Bash(npm install *)",
      "Bash(pnpm add *)",
      "Bash(git push *)",
      "Bash(wrangler deploy *)",
      "Bash(vercel deploy *)",
      "Bash(terraform apply *)",
      "Bash(kubectl apply *)"
    ],
    "deny": [
      "Read(.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(rm -rf *)"
    ]
  }
}

ここで一番伝えたいのは、Bashのワイルドカードを雑に広げないことです。Bash(npm *) は npm test だけでなく npm install や npm publish まで巻き込みます。公式も、引数を絞るBashパターンは脆い境界になり得ると警告しています。例えば Bash(curl http://github.com/ *) でcurlをGitHubに限定したつもりでも、curl -X GET ... やリダイレクト、URL=... && curl $URL で簡単にすり抜けます。だからネットワーク系は curl・wget ごと deny し、必要なドメインだけ WebFetch(domain:...) で開ける。これが現実的でした。

もう一点、Claude Codeはシェル演算子を理解します。Bash(npm test *) を許可しても npm test && rm -rf . は通りません。複合コマンドは各サブコマンドが個別に判定される。地味ですが、安心できる挙動です。

コピペで動く監査スクリプト

ここまでの点検を、人の目だけに頼ると忙しい日に必ず崩れます。だから機械にもやらせます。次を scripts/audit-claude-loop.mjs として保存し、node scripts/audit-claude-loop.mjs で実行してください。外部パッケージは不要です。設定・予算・当日ログの3ファイルを読み、広すぎるBash許可・deploy許可の置き忘れ・.env deny漏れ・予算超過・引き継ぎ漏れを検出します。

#!/usr/bin/env node
// 設定・予算・当日ログを読み、危ない許可と使いすぎを機械的に弾く門番
import fs from "node:fs";

const readJson = (file) => JSON.parse(fs.readFileSync(file, "utf8"));

const budget = readJson(".claude/permission-budget.json");
const log = readJson(".claude/daily-claude-log.json");
const settings = readJson(".claude/settings.json");

const problems = [];
const permissions = settings.permissions ?? {};
const allow = new Set(permissions.allow ?? []);
const ask = new Set(permissions.ask ?? []);
const deny = new Set(permissions.deny ?? []);
const hasPattern = (items, pattern) => [...items].some((item) => pattern.test(item));

// 予算の数字そのものが壊れていないか
if (typeof budget.dailyLimitUsd !== "number" || budget.dailyLimitUsd <= 0) {
  problems.push("dailyLimitUsd は正の数にする");
}
if (typeof budget.warnAtUsd !== "number" || budget.warnAtUsd >= budget.dailyLimitUsd) {
  problems.push("warnAtUsd は dailyLimitUsd より小さくする");
}

// 当日の使いすぎチェック
if (log.spentUsd > budget.dailyLimitUsd) {
  problems.push(`spentUsd ${log.spentUsd} が日次上限 ${budget.dailyLimitUsd} を超過`);
}
if (log.spentUsd >= budget.warnAtUsd) {
  console.warn(`WARN: spentUsd ${log.spentUsd} が警告ライン ${budget.warnAtUsd} に到達`);
}

// 点検したフラグが立っているか
if (!log.usageChecked) problems.push("/usage を見て usageChecked を true に");
if (!log.settingsChecked) problems.push("/permissions を見て settingsChecked を true に");

// 全Bash許可は事故の元
if (allow.has("Bash") || allow.has("Bash(*)") || hasPattern(allow, /^Bash\(\*.*\)$/)) {
  problems.push("Bash 全許可は禁止");
}

// deploy 系が allow に紛れていないか
if (hasPattern(allow, /(deploy|terraform apply|kubectl apply|git push)/)) {
  problems.push("deploy・インフラ・push は allow ではなく ask に");
}

// 予算が要求する ask / deny がそろっているか
for (const rule of budget.askFirst ?? []) {
  if (!ask.has(rule)) problems.push(`ask ルール不足: ${rule}`);
}
for (const rule of budget.mustDeny ?? []) {
  if (!deny.has(rule)) problems.push(`deny ルール不足: ${rule}`);
}

// .env の読み取りを塞いでいるか
if (!hasPattern(deny, /Read\(.*\.env/)) {
  problems.push("deny に .env 読み取りブロックを入れる");
}

// 引き継ぎメモがあるか
if (!Array.isArray(log.handoff) || log.handoff.length === 0) {
  problems.push("引き継ぎメモを最低1件書く");
}

if (problems.length) {
  console.error(problems.map((problem) => `- ${problem}`).join("\n"));
  process.exit(1);
}

console.log("Claude Code 権限・予算チェック 合格");

読み込む2ファイルはこんな形にします。.claude/permission-budget.json が「今日の予算とルールの宣言」、.claude/daily-claude-log.json が「今日やった点検の記録」です。

{
  "date": "2026-06-07",
  "dailyLimitUsd": 6,
  "warnAtUsd": 4,
  "usageSource": "/usage plus Claude Console",
  "askFirst": ["Bash(npm install *)", "Bash(git push *)", "Bash(wrangler deploy *)"],
  "mustDeny": ["Read(.env)", "Read(./.env.*)", "Read(./secrets/**)"],
  "handoffRequired": true
}

CIに入れるなら、いきなり全PRを落とすより、最初は手動実行か continue-on-error でチームの実態を見たほうが続きます。予算の数字も、最初から厳しくしすぎないこと。続かない仕組みは、無いのと同じでした。

効いた場面、4つ

1. 記事やドキュメントの更新。Markdown・MDX・内部リンク・誤字・画像パスは、秘密情報にも本番にも触れません。Read・git diff・npm run lint・npm run build を狭く allow しておくと、Claude Codeは小さな差分を止まらずに作れます。公開前は人間が中身とSEOを見ますが、ファイルを読むたびに承認を押す必要はない。承認疲れが一番減ったのがここでした。

2. 依存パッケージの追加。npm install は便利ですが、lockfile・postinstall・ライセンス・脆弱性・バンドルサイズに影響します。だから ask。承認時には「なぜ要るのか」「既存で代替できないか」「消す手順は何か」をClaude Codeに書かせます。型エラー解消のために安易にライブラリを足す流れは、あとで運用コストに化けます。

3. deployとmigration。wrangler deploy・vercel deploy・terraform apply・kubectl apply・DB migrationは、成功しても失敗しても外の状態を変えます。コマンド案・影響範囲・rollback・確認URL・監視項目を書かせ、実行は人間が承認。特に「一度だけ許可」のつもりが allow に残る事故が起きやすいので、朝のループでdeploy許可を必ず閉じます。

4. チーム引き継ぎ。夜に別メンバーが続けるなら、開いた許可・やった検証・止めた操作・残り予算を書く。引き継ぎが無いと、次の人は同じ調査を再実行してコストを使い、危ない許可をもう一度開きます。permission budgetは個人のメモではなく、チームの作業台帳です。

僕がやらかした落とし穴3つ

正直に書きます。最初の運用は穴だらけでした。

ひとつ目は、冒頭の Bash(npm *) 事故。便利だからと前方一致で広げたら、test・install・publishが同じ重さで通りました。今は毎日叩くコマンドだけを列挙しています。prefixで広げない、ただそれだけで夜が静かになりました。

ふたつ目は、deploy許可の閉じ忘れ。障害対応中に wrangler deploy * を ask から allow に移し、そのまま翌日の通常作業に入る。これが危ない。deployは「作業中だけ開く」より「毎回 ask に戻す」方が、結局ラクでした。

みっつ目は、コスト増を『今日はよく働いた』で流したこと。長い調査、同じテストの連打、放置した背景セッション、巨大ログの丸投げ。静かに積み上がります。/usage だけでなくConsoleを見る日を決めてからは、月末の請求で驚かなくなりました。

よくある質問

Q. allow と ask と deny、評価の順番は？ A. deny → ask → allow の順で、最初に当たったルールが勝ちます。deny が常に最優先なので、絶対に触らせたくないものは deny に入れておけば下の許可をすり抜けません。

Q. Bash(npm *) の何がそんなに危ないんですか？ A. ワイルドカードが npm install や npm publish まで巻き込むからです。毎日使うのは npm run test や npm run build くらいのはず。そこだけ狭く allow し、installは ask に分けると事故が激減します。

Q. コストはどこで確認・制限すればいい？ A. セッションは /usage、実請求はClaude ConsoleのUsageページが正です。/usage のドル表記はローカル推定なのでズレます。月の上限はProやMaxなら /usage-credits、チームはworkspaceのspend limitで止めます。

Q. --dangerously-skip-permissions（bypassPermissions）は使ってもいい？ A. コンテナやVMなど壊れても困らない隔離環境だけにしてください。rm -rf / には保険の確認が残りますが、普段の作業フォルダで常用するものではありません。組織で封じるなら管理者設定の disableBypassPermissionsMode を使います。

Q. CLAUDE.md に「pushしないで」と書けば防げますか？ A. 防げません。CLAUDE.md は方針であって柵ではない。境界にしたいなら Bash(git push *) を ask か deny に置きます。権限を強制するのはモデルではなくClaude Code本体です。

実際に試した結果

一日の倍の請求にヒヤッとして以来、僕は「Claudeを信じるか」で悩むのをやめました。代わりに見るのは、どの柵で止まったかです。

効いたのは「危ないコマンドを全部禁止する」ことではなく、毎朝5分で /permissions・/usage・git diff・引き継ぎメモを見る習慣でした。小さな allow を残しつつ、deployと課金とsecretsを ask か deny に戻すだけ。それだけで承認疲れが減り、レビューで「なぜこの差分か」を説明できるようになりました。監査スクリプトを足してからは、深夜に自分が見落としても、門番が予算超過とdeploy置き忘れを朝に教えてくれます。

権限の細かい構文はClaude Code 権限設定リファレンスに、トークン課金の仕組みと予算で止める実装はLLM APIの料金と予算で止める実装にまとめました。設定の棚卸しを定期化したい人は権限監査チェックリストもどうぞ。一次情報は公式のConfigure permissionsとManage costs effectivelyが確実です。

再利用できるチェックリストや CLAUDE.md テンプレート、レビュー用プロンプトは教材一覧にまとめています。チームで権限・コスト・CI・教育まで整えるなら研修・相談が現実的です。permission budgetは一度作って終わりではなく、チームの作業量と請求に合わせて育てる運用です。