Claude Codeの『誰が何を許可したか』を残す権限レシート術

「あのとき、なんでこのコマンド実行を許可したんだっけ？」

先週、僕はチームのSlackでそう聞かれて、固まりました。3日前にClaude Codeに npm run deploy を一時的に許可した記憶はある。でも、どのファイルを触る前提で、何を確認して、なぜ安全だと判断したのか——何も残っていなかったんです。

設定ファイル（settings.json）を見れば「今どの許可が有効か」はわかります。でも「いつ、誰が、何のために、何を確認した上で許可したか」は、どこにも書いていない。これが地味に怖い。今日はその穴を1分で埋める、permission receipt（権限レシート） という小さな習慣の話です。

この記事の要点

• permission receiptは、Claude Codeの作業ごとに「許可した操作・承認待ちの操作・対象ファイル・検証コマンド・戻し方」を短く残すメモ。レシート（領収書）と同じで、後から「何を買ったか＝何を許可したか」を追える。
• settings.jsonは「今の状態」しか持たない。receiptは「その作業での判断」を残すので、事故の説明責任とロールバックの両方に効く。
• 書く場所はJSONでもMarkdownでもいい。allowed / requiresApproval / filesInScope / proof / rollback の5項目があれば十分。
• 認証・課金・秘密情報・メール送信・本番デプロイに触れる作業は、receiptを書く前に必ず止めて人間の承認を取る。
• チーム導入では CLAUDE.md にテンプレートを置き、毎回同じ粒度で残すのがコツ。属人化が消える。

permission receiptって、要するに何？

receipt は英語で「領収書・レシート」です。コンビニのレシートを思い浮かべてください。何を、いくらで、いつ買ったかが1枚に印字されていますよね。あれの「許可版」だと思ってください。

Claude Codeに作業を頼むとき、その場の判断で許可を広げることがあります。「今回だけ Edit を許す」「このディレクトリだけ書き込みOK」。便利なんですが、口頭やその場のノリで許可すると、記録が一切残りません。

permission receiptは、その作業を始める前に、こんな項目を1つの短いメモにまとめる習慣です。

• allowed: 今回許可する操作（読む、検索する、特定ファイルを編集する、ビルドする等）
• requiresApproval: 人間の承認が要る操作（本番デプロイ、価格変更、メール送信等）
• filesInScope: 触ってよいファイル・機能の範囲
• proof: 作業後に残す証拠（ビルド成功ログ、公開URL確認等）
• rollback: 失敗したときの戻し方

ポイントは「許可を広げる前に書く」こと。後から思い出して書くメモは、たいてい嘘が混じります。レジを通す前に値段を確認するのと同じ順番ですね。

なぜ設定ファイルだけでは足りないのか

ここがいちばん誤解されるところです。「settings.json に allow/deny を書いてるんだから、それで十分じゃないの？」と僕も最初は思っていました。

違うんです。設定ファイルが答えられるのは 「今、何が許可されているか」 だけ。次の質問には一切答えられません。

知りたいこと	settings.json	permission receipt
今どの許可が有効か	◯	△（その作業分だけ）
いつ・なぜ許可を広げたか	✗	◯
どのファイルを触る前提だったか	✗	◯
作業後に何を確認したか	✗	◯
失敗したときの戻し方	✗	◯
誰が責任を持つ作業か	✗	◯

Claude Codeに許可を広げるほど、作業は速くなります。でも同時に、事故ったときの説明責任も増えます。「なぜそのコマンドを実行したのか」「対象ファイルは何だったのか」「導入相談やGumroadの教材リンクをちゃんと確認したのか」——これを後から追えるのが receipt です。設定ファイルは状態、receipt は判断の記録。役割がまるで別なんですね。

コピペできる最小セット

説明より動かしたほうが早いです。まずは作業前に書く JSON のレシート。これをそのまま使ってください。

{
  "request": "記事のCTAリンクを更新する",
  "allowed": ["Read", "Grep", "コンテンツファイルのEdit", "npm run build"],
  "requiresApproval": ["本番deploy", "商品価格の変更", "メール送信"],
  "proof": ["ビルド成功", "公開URL確認", "CTAクリック確認"],
  "owner": "content-ops"
}

次に、Claude Codeへ最初に渡す指示文（システムプロンプト）。「動く前にレシートを書け」と先に約束させます。

作業を始める前に、permission receipt を書くこと。
含める項目: 許可する操作、承認が必要な操作、対象ファイル、検証コマンド、ロールバック方法。
作業が課金・認証・秘密情報・メール送信・本番デプロイに触れる場合は、止まって承認を求めること。

そして、機械的に「これは人間の承認が要る作業か？」を判定する小さな関数。レシートを受け取って、危険ワードが含まれていたら true を返します。

// permission receipt を受け取り、人間の承認が必要かを機械的に判定する
export function needsHumanApproval(receipt) {
  // 戻しにくい・事故ると痛い操作のキーワード
  const risky = ["billing", "auth", "secrets", "email", "production deploy"];
  return receipt.requiresApproval.some((item) =>
    risky.some((word) => item.toLowerCase().includes(word))
  );
}

この関数があるだけで、「人間が見落とした危険な承認待ち」をコードが拾ってくれます。僕は CI のチェックにこれを組み込んで、needsHumanApproval が true を返したら自動マージを止めるようにしています。目視に頼らないのが大事です。

どんな場面で効くか（3つの実例）

receiptは抽象論だと「ふーん」で終わります。具体的な3場面で見せます。

1. 記事のCTA修正 記事の中の教材リンクや相談リンク（CTA）を直すだけの作業。このときは allowed にコンテンツファイルの編集とビルドを入れ、requiresApproval に商品価格の変更を入れます。リンクを直すついでにAIが価格表記まで「親切に」直してしまう事故、これで防げます。

2. 無料PDFフォームの改善 登録フォームの文言や項目を整える作業。送信テスト（ダミーデータでの動作確認）は proof に入れていい。でも、実際のメール送信は承認待ちにします。テストのつもりが本番のメールリストに配信される、という事故をレシートの段階で止めます。

3. チーム導入時のテンプレート化 個人なら頭の中でもなんとかなりますが、複数人だと粒度がバラバラになります。そこで CLAUDE.md に receipt のテンプレートを置き、誰がやっても同じ5項目が埋まるようにします。レビュー時も「receiptが空＝差し戻し」とルール化すると、属人化が一気に消えます。

運用チェックリスト（毎回ここを見る）

この型は一度読んで終わりではなく、毎回のClaude Code作業で短く確認するためのものです。特に記事、商品ページ、問い合わせ導線を触る日は、次の項目を紙のチェックリストのように扱うと事故が減ります。

• 作業前に目的を1文で書き、対象外のファイルや機能を明記する。
• Claude Codeへ渡す前に、読むべきファイルと読まなくてよいファイルを分ける。
• 実装後に必ず1つ以上の証拠コマンドを残す。記事ならビルドだけでなく公開URLを見る。
• 無料PDF、Gumroad教材、導入相談のリンクが本文と記事下CTAの両方で矛盾しないか確認する。
• 多言語記事ではtitle、h1、本文冒頭、CTAが同じ言語になっているか見る。
• 無関係なdirty fileをstageしない。必要ならcommit前に差分をもう一度分ける。
• 次回の作業者が迷わないよう、残ったリスクと次に見る数字を短く書く。

権限まわりの基礎をまだ固めていないなら、先に Claude Codeの権限設定とallowlistの基本 で settings.json の全体像を押さえておくと、receiptに書く allowed の粒度が一気に決まります。毎朝の点検習慣とセットにしたい人は 権限と予算を毎朝回す permission budget loop も合わせてどうぞ。

僕がやらかした失敗3つ

正直に書きます。最初は receipt を「めんどくさい儀式」だと思って、何度も痛い目を見ました。

ひとつ目は、作業後に思い出して書いたこと。「終わってからまとめればいいや」とやったら、proof 欄に「たぶんビルド通ったはず」と書いている自分がいました。確認していないのに証拠欄が埋まっている。これでは何の意味もありません。今は許可を広げる前に、空のreceiptを先に作ってから手を動かします。

ふたつ目は、proof をビルド成功だけで済ませたこと。npm run build が通っても、公開ページのCTAが404を指していたことがありました。ビルド成功と公開URL成功はまったくの別物です。証拠欄には必ず「実際の公開URLを開いて確認」を1行足すようにしました。

みっつ目は、承認待ちを曖昧な言葉で書いたこと。「危なそうなのは止める」とだけ書いていたら、何が危ないかの基準が人によってバラバラで、結局メール送信が承認なしで通ってしまった。今は requiresApproval に「本番deploy」「価格変更」「メール送信」と固有名詞で書きます。needsHumanApproval 関数が拾えるように、です。

handoffに残すべきこと

Claude Codeの作業は、その場で終わったように見えても、翌日の確認や別担当者のレビューで価値が決まります。handoff（引き継ぎメモ）には、何を変えたかだけでなく、なぜその範囲に絞ったか、どの証拠を見たか、次に失敗しそうな場所はどこかを書きます。記事なら、本文の改善点、内部リンク、外部リンク、heroImage、公開URL、CTAの遷移先をまとめます。

たとえば記事公開のhandoffには、作成したslug、対象言語、使った画像、ビルド結果、deploy結果、公開URLで確認したh1、canonical、本文言語、CTAの行き先を書きます。既存記事のリライトなら、どの検索意図に寄せたか、どの段落を足したか、どの売上導線を強めたかも残します。これがあると、あとから「PVは増えたが登録が増えない」場合も、CTAの問題なのか、記事テーマの問題なのか、公開検証の漏れなのかを切り分けられます。receiptとhandoffは地続きで、receiptが「作業前の約束」、handoffが「作業後の記録」だと思ってください。

失敗例（これをやると追えなくなる）

• 権限を設定ファイルだけで管理すると、実際に何を許可したか作業単位で追えません。「今の状態」は見えても「過去の判断」が消えます。
• 承認待ちを曖昧にすると、価格、メール、deployのような戻しにくい変更へずるずる進みます。
• 証拠欄がないと、ビルド成功と公開URL成功を混同します。「動くはず」が事故の入口です。

危険コマンドそのものを毎朝洗い出す習慣は 権限監査チェックリスト に、allowを安全な順番で広げる考え方は 権限セーフティラダー にまとめています。receiptと一緒に回すと守りが厚くなります。許可の判定ロジックを自前で書く前に、Anthropic公式の Claude Code settings ドキュメント で permissions の allow / deny / ask の正確な挙動を確認しておくのもおすすめです。

よくある質問

Q. receiptはJSONとMarkdownどちらで書くべき？ A. どちらでも構いません。needsHumanApproval のように機械でチェックするならJSON、人間のレビューだけならMarkdownの箇条書きが楽です。大事なのは形式より、5項目（allowed / requiresApproval / filesInScope / proof / rollback）が毎回そろうことです。

Q. 毎回書くのは面倒。本当に必要？ A. 読むだけの軽い作業なら省いていいです。ただし課金・認証・秘密情報・メール送信・本番デプロイのどれかに触れる瞬間だけは、必ず書いてください。事故ったときのコストが桁違いなので、ここだけは横着しない方が結局速いです。

Q. settings.json の allow/deny と何が違う？ A. settings.jsonは「今の許可状態」、receiptは「その作業での判断と証拠」です。前者は状態、後者は履歴。両方そろって初めて「なぜこの操作が通ったか」を後から説明できます。

Q. receiptはどこに保存すればいい？ A. チームならPRの説明欄やhandoffメモに貼るのが一番追いやすいです。個人なら作業ログのファイルに追記するだけで十分。CLAUDE.md にテンプレートを置いておくと、毎回コピペで粒度がそろいます。

Q. CLAUDE.md にテンプレートを置く具体的なメリットは？ A. 誰がやっても同じ5項目が埋まるので、レビュー時に「receiptが空＝差し戻し」と機械的に判断できます。属人化が消え、新メンバーでも初日から同じ品質で記録を残せるようになります。

実際に試した結果

冒頭のSlackで固まった日以来、僕は「許可を広げる前にreceiptを書く」を徹底するようにしました。最初は面倒でしたが、requiresApproval を固有名詞で書くようにしてから、needsHumanApproval 関数が承認待ちの取りこぼしを自動で拾ってくれるようになり、目視のストレスが激減しました。

いちばん効いたのは proof 欄に「公開URLを実際に開く」を必須にしたこと。ビルドは通るのにCTAが古い商品ページを指していた、という事故がこれでゼロになりました。受け取れるレシートがあるだけで、「なんで許可したんだっけ」と固まる時間が消える。地味な1分の習慣ですが、チームで回すなら最初に入れる価値がある、というのが今の実感です。

権限設計、公開前レビュー、収益導線の設計までチームでまとめて固めたいなら、記事内リンクだけで完結させず 導入相談 で一度棚卸しするのが近道です。まずは手元のコマンドを固定したい段階なら、教材一覧 の無料チートシートやPrompt Templatesから始めてみてください。

• 無料 Claude Code チートシート
• 50個の Claude Code Prompt Templates
• Claude Code Setup Guide
• 教材一覧
• 導入相談