Claude Code権限監査チェックリスト: 仕事で使う前に安全設定を固める

なぜ権限監査を最初にやるのか

Claude Codeは便利ですが、仕事で使う前に「どこまで任せてよいか」を決めないと、レビューより確認作業が重くなります。権限監査は難しいセキュリティ儀式ではありません。編集してよい場所、承認が必要な作業、絶対に触らない情報を先に書き出すだけです。

この記事は 最初の30分チェックリスト と CLAUDE.mdスターターテンプレート の間に置く運用メモです。無料PDFで基本操作を覚えたあと、仕事のrepoで使う前にこの監査を通してください。

まず許可プロファイルを1枚で作る

最初に作るのは細かい規程ではなく、Claude Codeに渡せる短いプロファイルです。次のように「許可」「確認」「禁止」を分けると、依頼のたびに迷う時間が減ります。

claude_code_permission_profile:
  workspace: "repo only"
  allowed_without_approval:
    - "read files"
    - "run tests"
    - "edit content files"
  ask_first:
    - "install packages"
    - "change auth or billing code"
    - "deploy production"
  never_allow:
    - "print secrets"
    - "delete git history"
    - "rotate keys without owner approval"
definition_of_done:
  - "git diff reviewed"
  - "proof command captured"
  - "rollback note written"

ポイントは、ツールに何をしてよいかだけでなく、完了条件まで含めることです。権限が広くても検証が弱ければ危険ですし、権限が狭くてもロールバックメモがあれば安心して小さく進められます。

実例: コンテンツサイトでの安全な依頼

たとえば多言語のAstroサイトなら、記事MDX、CTA文言、商品ページの説明は比較的安全です。一方で、フォームAPI、課金リンク、分析タグ、Cloudflare設定は売上や個人情報に近いため、実装前に確認を挟みます。

実装前にこのリポジトリを監査してください。
返してほしい内容:
1. 安全に実行できるコマンド
2. 安全に編集できるファイル
3. 承認が必要な作業
4. 今日終えられる最小の有用タスク
5. 検証コマンドとロールバックメモ

この依頼を最初に投げると、Claude Codeは実装前に「今日進める最小タスク」を提案できます。記事下CTAの改善、無料PDFフォーム文言の修正、商品ページの導線整理のように、収益導線に効きつつ戻しやすい作業を選びやすくなります。

失敗例: 便利だから全部許可する

よくある失敗は、初日にパッケージ追加、認証コード変更、本番deployまで一気に許可することです。うまくいけば速いですが、失敗したときに「何が変わったか」「どこまで戻すか」が曖昧になります。

もう一つの失敗は、禁止事項だけを書いて検証を書かないことです。「秘密情報を出さない」だけでは不十分です。build、テスト、公開URL、フォーム送信、Gumroadリンクの確認まで、作業種類ごとに証拠を決めておきます。

15分レビューの手順

1. “git status —short” で開始時点の変更を確認する。
2. 編集可能なディレクトリと触らないディレクトリをClaude Codeに読ませる。
3. 作業ごとに、実行してよいコマンドと承認が必要なコマンドを分ける。
4. 最後に証拠コマンドとロールバックメモを残す。

実務では、この15分が後半の手戻りを減らします。特にチーム利用では、誰が見ても「なぜこの変更だけ許可したのか」が残るため、レビューが感想ではなくリスク確認になります。

現場で使う3つの権限パターン

権限監査は、最初から完璧な社内規程にしようとすると止まります。最初は作業の種類ごとに、次の3パターンだけ決めれば十分です。

1つ目は「読んでよいが変更しない」パターンです。新しいリポジトリ、請求、認証、個人情報、顧客データに近い作業では、まず読解とリスク整理だけを許可します。Claude Codeには「編集せず、変更候補をファイル名と理由だけで返す」と伝えます。

2つ目は「小さい編集なら許可する」パターンです。記事、ドキュメント、テストの期待値、明らかなtypo、CTA文言のように戻しやすい場所では、編集とローカル検証まで任せます。ただし、完了条件には必ず git diff、build、公開URL確認のどれかを入れます。

3つ目は「人間の承認後に進める」パターンです。package追加、環境変数、デプロイ、課金リンク、フォーム送信先、分析タグは、収益や個人情報に近いため確認を挟みます。ここで大事なのは、禁止ではなくゲートにすることです。承認条件が明確なら、Claude Codeも次の作業に戻りやすくなります。

このタスクを次の3区分に分けてください。
- 読むだけでよい
- 小さく編集して検証まで進めてよい
- 人間の承認が必要

各区分について、対象ファイル、理由、完了条件を1行ずつ書いてください。

私が実際にコンテンツ運用で使うときは、記事本文と内部リンクは2つ目、Gumroadの商品URLやフォーム送信は3つ目に置きます。これだけで「速く進めたい作業」と「間違えると高くつく作業」が分かれ、レビューの焦点がかなり絞れます。

作業別の監査表

権限監査を毎回ゼロから考えると続きません。よくある作業を表にして、最初の判断を固定しておきます。

作業	初期権限	追加で見る証拠
記事本文の修正	編集可	build、公開URL、h1、CTA
内部リンク追加	編集可	リンク先200、canonical、言語パス
Gumroadリンク変更	承認後	商品名、価格、公開状態、リンク先
フォーム文言変更	編集可	mobile表示、送信後ページ、エラー文言
フォーム送信先変更	承認後	API、個人情報、ログ、ロールバック
package追加	承認後	lockfile差分、build、脆弱性理由
画像差し替え	編集可	alt、重複、読み込み、OGP
Cloudflare設定	承認後	対象project、branch、deploy結果

この表の目的は、作業を止めることではありません。Claude Codeが「ここは触ってよい」「ここは先に確認」と判断できるようにすることです。特に商品導線では、リンク1つの間違いが売上に直結します。記事本文よりも、購入リンク、無料PDF、導入相談フォームを強めに扱うのが現実的です。

もう一つ大事なのは、権限の広さと検証の強さをセットで見ることです。たとえば記事本文の編集は許可してよい一方、公開URLで本文が本当に反映されたかを見なければ完了ではありません。逆に、Gumroadリンク変更は承認が必要ですが、承認後の修正自体は1行で終わることが多いです。危険なのは行数ではなく、失敗したときの影響範囲です。

迷ったら、「この変更が間違っていたとき、読者は困るだけか、購入や問い合わせまで失うか」で分けます。前者は小さく直して検証、後者は先に承認と証拠をそろえる。この一文をチームの共通ルールにしておくだけでも、Claude Codeに任せる範囲をかなり判断しやすくなります。

この記事で紹介した内容を実際に試した結果

多言語コンテンツサイトの更新でこの監査を使うと、作業前の確認時間は少し増えます。その代わり、最後の手戻りは明らかに減りました。特に効果があったのは、デプロイ前に「公開URLで正しいh1とcanonicalを見る」と完了条件に書いたことです。ローカルbuildだけで終える失敗を防げます。

逆に、権限プロファイルを書いても効かなかった場面があります。禁止事項だけを書き、検証コマンドを書かなかったときです。その場合、Claude Codeは安全に編集しても、最後の証拠が弱くなります。権限監査は「何を触るか」ではなく「どう終わったと判断するか」まで含めて初めて役に立ちます。

次の導線

基本コマンドをまだ覚えていない場合は 無料チートシート から始めてください。権限、CLAUDE.md、hooks、MCPまでまとめて固めたい場合は Setup Guide が近道です。チーム導入や本番運用の線引きまで一緒に設計するなら 導入相談 に進んでください。