Claude Codeの権限と予算を毎朝回す: 5分で点検するpermission budget loop

毎朝5分の点検が効く理由

Claude Codeを業務で使い始めると、最初に詰まるのは「何を許可してよいか」です。毎回すべてのBashコマンドを承認すると、最初の数回は安全に見えます。しかし数十回のプロンプトが出ると、人間は内容を読まずに承認し始めます。反対に、何でも許可すると、.envの読み取り、依存パッケージの追加、git push、本番deploy、DB migration、課金設定の変更が同じ重さで通ってしまいます。

そこで使うのがpermission budget loopです。permission budgetとは、Claude Codeに「止めずに任せる操作」「人間に聞いてから進める操作」「絶対に禁止する操作」を先に書いた運用表です。loopは、その表を毎朝短時間で見直し、前日の実行ログとコストを照合し、不要な許可を閉じる習慣を指します。難しいセキュリティ用語にするとアクセス制御ですが、実務では「エージェントに渡す財布と鍵を毎朝数える」くらいに考えるとわかりやすいです。

2026年6月3日時点の公式ドキュメントでは、Claude Codeの権限はallow、ask、denyで管理できます。denyが最優先で、ask、allowの順に評価されます。/permissionsで現在のルールと設定元を確認でき、設定ファイルはユーザー、プロジェクト、ローカル、管理者配布のスコープを持ちます。詳しくは公式のConfigure permissions、Claude Code settings、Manage costs effectively、CLI referenceを確認してください。

この考え方は、Claude Code permissions guide、permission audit checklist、permission receipt patternと相性がよいです。この記事では、それらを毎朝回せる形に落とします。

まず覚える権限の基本

初心者向けに言い換えると、Claude Codeのpermissionは「モデルの気持ち」ではなく「CLIが実際に止める柵」です。CLAUDE.mdに「秘密情報を読まないで」と書くことは重要ですが、それだけでは境界になりません。境界にしたいならRead(./.env)やRead(./secrets/**)をdenyに置きます。公式ドキュメントも、権限ルールはモデルではなくClaude Codeにより強制されると説明しています。

権限モードも分けて考えます。defaultは標準の承認フロー、planは読み取りと調査に寄せたモード、acceptEditsは編集を進めやすくするモード、dontAskは事前承認されていないツールを自動で拒否するモードです。bypassPermissions、つまり--dangerously-skip-permissionsは全承認を飛ばす強いモードで、公式にも隔離されたコンテナやVMのような環境に限定する考え方が示されています。通常の作業ディレクトリで常用するものではありません。

コストも同じです。/usageはセッションのトークン使用量や概算コストを確認するのに便利ですが、API課金の最終確認はClaude Console側のUsageやworkspace spend limitを見ます。claude -pのような非対話実行では--max-budget-usdや--max-turnsを使えますが、これはスクリプト実行の上限であり、毎日のチーム予算そのものではありません。

毎朝のpermission budget loop

5分で見る場所を固定します。長い会議にすると続きません。目的は完璧な監査ではなく、危険な許可を開いたまま1日を始めないことです。

順番	見るもの	合格条件
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項目以内にしてください。

チームで共有するsettings.json例

次の例は、共有用の.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(git *)はgit diffだけでなくgit pushにも近づきます。公式ドキュメントは、Bashパターンは便利だが脆い境界になり得ると説明しています。迷ったら「読む、lint、test、build」は狭くallowし、「install、push、deploy、apply」はaskに置きます。

予算と実行ログをJSONで残す

権限だけでは半分です。もう半分は予算です。Claude Codeの作業は、長い調査、複数エージェント、何度も失敗するテスト修正で膨らみます。チームの本番運用では、/usageを見たか、ConsoleのUsageを見たか、今日の上限を超えたかを記録します。

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

{
  "date": "2026-06-03",
  "spentUsd": 1.85,
  "usageChecked": true,
  "settingsChecked": true,
  "permissionsReviewed": [
    "/permissions",
    ".claude/settings.json"
  ],
  "openAllowances": [
    "Bash(npm run lint)",
    "Bash(npm run test *)"
  ],
  "handoff": [
    "No deploy allowance left open",
    "Claude stopped before production data work"
  ]
}

ファイル名はそれぞれ.claude/permission-budget.jsonと.claude/daily-claude-log.jsonにします。ExcelやNotionでもよいですが、JSONにしておくとPRで差分を見られ、Claude Code自身にも監査させやすくなります。

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

次のファイルを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 must be a positive number");
}

if (typeof budget.warnAtUsd !== "number" || budget.warnAtUsd >= budget.dailyLimitUsd) {
  problems.push("warnAtUsd must be lower than dailyLimitUsd");
}

if (log.spentUsd > budget.dailyLimitUsd) {
  problems.push(`spentUsd ${log.spentUsd} exceeds daily limit ${budget.dailyLimitUsd}`);
}

if (log.spentUsd >= budget.warnAtUsd) {
  console.warn(`WARN: spentUsd ${log.spentUsd} has reached warnAtUsd ${budget.warnAtUsd}`);
}

if (!log.usageChecked) problems.push("Run /usage and mark usageChecked true");
if (!log.settingsChecked) problems.push("Review /permissions and mark settingsChecked true");

if (allow.has("Bash") || allow.has("Bash(*)") || hasPattern(allow, /^Bash\(\*.*\)$/)) {
  problems.push("Do not allow every Bash command");
}

if (hasPattern(allow, /(deploy|terraform apply|kubectl apply|git push)/)) {
  problems.push("Deploy, infrastructure, and push commands must be ask-first, not allow");
}

for (const rule of budget.askFirst ?? []) {
  if (!ask.has(rule)) problems.push(`Missing ask rule: ${rule}`);
}

for (const rule of budget.mustDeny ?? []) {
  if (!deny.has(rule)) problems.push(`Missing deny rule: ${rule}`);
}

if (!hasPattern(deny, /Read\(.*\.env/)) {
  problems.push("Deny rules should block .env reads");
}

if (!Array.isArray(log.handoff) || log.handoff.length === 0) {
  problems.push("Add at least one handoff note");
}

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

console.log("Claude Code daily permission budget check passed.");

CIに入れるなら、いきなり全PRを落とすより、最初はcontinue-on-errorや手動実行にしてチームの実態を見ます。budgetの数字も最初から厳しくしすぎない方が続きます。

具体的なユースケース

1つ目は記事やドキュメント更新です。Markdown、MDX、内部リンク、CTA、誤字修正、画像パスの確認は、秘密情報や本番環境に触れません。Read、git diff、npm run lint、npm run buildを狭くallowしておくと、Claude Codeは小さな差分を止まらずに作れます。公開前には人間が内容とSEOを見ますが、ファイル読み取りごとに承認する必要はありません。

2つ目は依存パッケージの追加です。npm installやpnpm addは便利ですが、lockfile、postinstall、ライセンス、脆弱性、バンドルサイズに影響します。ここはaskに置きます。承認時には「なぜ追加が必要か」「既存依存で代替できないか」「削除手順は何か」をClaude Codeに書かせます。単なる型エラー解消で新しいライブラリを入れる流れは、後で運用コストになります。

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

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

失敗例と落とし穴

一番多い失敗は、便利だからとBash(npm *)やBash(git *)をallowすることです。最初はテストやdiffのつもりでも、install、publish、pushに近い操作まで同じカテゴリに入ります。prefixで広く許可するより、実際に毎日使うコマンドだけを列挙してください。

次に、deploy許可の閉じ忘れです。障害対応中にwrangler deploy *をaskからallowに移し、そのまま翌日の通常作業に入ると危険です。deployは「作業中だけ開く」より「毎回askに戻す」方が運用しやすいです。

3つ目は、tokenやcostの増加を「今日はよく働いた」で済ませることです。調査が長い、同じテストを何度も走らせる、複数の背景セッションを放置する、巨大ログを丸ごと渡すと、コストは静かに増えます。/usageだけでなくConsoleも見る日を決め、見積もりと実請求の差を確認します。

4つ目は、プロンプトと設定を混同することです。「secretsを読まないで」は方針であり、Read(./.env) denyが境界です。「deployしないで」は方針であり、Bash(wrangler deploy *) askまたはdenyが境界です。Claude Codeのharness、つまりエージェントの足場は、プロンプト、設定、ログ、レビューが揃って初めて機能します。

収益導線とチーム導入

個人で始めるなら、この記事のJSONとNodeスクリプトを小さなリポジトリで試してください。再利用できるチェックリスト、CLAUDE.mdテンプレート、レビュー用プロンプトが必要なら/products/にまとめています。チームで権限、コスト、CI、レビュー、教育資料まで揃えるなら/training/が現実的です。permission budgetは一度作って終わりではなく、チームの作業量、権限、請求、事故対応に合わせて育てる運用です。

実際に試した結果、もっとも効いたのは「危険なコマンドを全部禁止する」ことではなく、毎朝5分で/permissions、/usage、git diff、引き継ぎメモを見る習慣でした。小さなallowを残し、deployと課金とsecretsをaskまたはdenyに戻すだけで、承認疲れが減り、レビュー時に説明できる差分が増えました。