Claude Codeの権限設計とは、誰が・どこで・何をしてよいかを設定ファイルとGitレビューに書いて決めておくことです。スタッフに使わせたいが、触ってほしくないファイルを開いたり危ない操作を勝手に実行したりしないか、という心配はよく聞きます。
Summary ／ この記事の要点
権限は「誰が・どこで・何を」の3つで決める。最初から全員に広く渡さない。
迷ったら「拒否」を厚く。許可は狭く始め、現場の声で1つずつ広げる。
変更はPR経由とログで「誰が何をしたか」を残す。小さく試して一週間ごとに見直す。
導入前に決める、権限の範囲
設定を触り始める前に、誰が使うか、どこで動かすか、何をしてよいかの三つを、紙かドキュメントに書き出しておきます。誰が使うか（担当者と役割）、どこで動かすか（どのリポジトリ・フォルダ・端末）、何をしてよいか（読むだけ／コードを直す／コマンドを実行する／社外と通信する）。これがないまま全員へ同じ広い権限を渡すと、いざ事故が起きたとき、誰のどの操作が原因かを追えなくなります。
役割で段階をつけると判断しやすくなります。試用中や新人は「読み取りと提案まで」、慣れた担当は「ブランチを切ってコミットまで」、本番のサーバーやデータベースに直接つなぐ操作は誰にも常時許可しない、といった具合です。最初から広げず、必要が出たら一段ずつ開けていくほうが安全です。
触られたくないものは先に挙げておきます。認証情報の入った設定ファイル、SSHの鍵、顧客データのフォルダ、本番の接続情報。これらは「読み取りそのものを止める」対象として、地図に印をつけておきます。後の設定作業が、この印をなぞるだけで済むようになります。
権限を決める3つの軸
誰が使うか
試用中・新人／慣れた担当／管理者。役割ごとに段階をつける。
どこで動かすか
どのリポジトリ・フォルダ・端末で使うかを限定する。
何をしてよいか
読むだけ／コードを直す／コマンド実行／社外と通信。
先に印をつける
注意
先に印をつける
認証情報の入った設定ファイル、SSHの鍵、顧客データのフォルダ、本番の接続情報。これらは「読み取りそのものを止める」対象として最初に印をつけておくと、後の設定作業がこの印をなぞるだけで済みます。
許可・拒否・確認をどこに書くか？
Claude Codeは設定ファイルで、やってよい操作・だめな操作・毎回確認する操作を指定できます。設定は三つの層に分かれます。個人用（その人の端末だけに効き、共有しない）、プロジェクト共有（リポジトリに入れてチーム全員に効き、Gitで履歴とレビューを残せる）、会社の管理用（端末に配り、個人が勝手に緩められない）。チームの共通ルールは共有層に、絶対に外せない禁止は管理層に置きます。
線引きの原則はひとつ、拒否は許可より強い、です。迷ったらまず拒否を厚くします。印を付けた認証情報や鍵ファイルは読み取りを拒否、まとめて消すコマンドや本番への接続、履歴を書き換えるような強制プッシュは「毎回確認」か「拒否」にしておきます。これだけで、取り返しのつかない操作はほぼ塞げます。
許可は狭く始めます。最初に何でも許可してしまうと、後から締めるのは現場の反発もあって難しくなります。日常の安全な操作（差分の確認、テスト実行、ブランチ作成など）だけ許可しておき、現場から「これも許可してほしい」と声が出たら、その都度ひとつずつ共有設定に足していきます。設定変更そのものもGitのレビューに乗せれば、誰がいつ何を開けたかが残ります。
3つの設定層と置きどころ
| 設定の層 | 効く範囲 | 用途 |
|---|---|---|
| 個人用 | その人の端末だけ | 各自の使い勝手。共有しない。 |
| プロジェクト共有 | リポジトリ＝チーム全員 | 共通ルール。Gitで履歴が残る。 |
| 会社の管理用 | 配布した端末全体 | 絶対に外せない禁止。個人が緩められない。 |
拒否は、許可より強い。
線引きの原則。迷ったら拒否を厚くする
「誰が何をしたか」を残す仕組み
Claude Codeに任せた変更は、必ずGitのブランチとプルリクエスト経由にして、本番に直結するブランチへ直接書かせないようにします。生成された差分を担当者が一度読み、納得してから取り込む。少人数の会社でも、この一段のレビューを飛ばす自動マージは事故のもとになりやすいので避けます。
記録は二種類そろえておきたいところです。コードの変更履歴はGitが残してくれます。加えて、コマンド実行や操作のログを残す設定（特定の操作の前後に自分の決めたチェックを差し込める仕組み）を入れておくと、後から「いつ・どの端末で・何をしたか」を追えます。トラブルのときに経緯を再現できるかどうかは、この記録の有無で大きく変わります。
コミットメッセージに、AIの補助で作った変更だと分かる印を残す運用も、後で見返すときに役立ちます。誰の判断で取り込んだのかがはっきりすれば、責任の所在も曖昧になりません。
変更を安全に取り込む流れ
ブランチを切る
本番と切り離した作業用ブランチで動かす。
AIが差分を生成
変更はコードの「差分」として提示される。
担当者が読んで納得
一度目を通し、内容を理解してから進める。
PR経由で取り込む
プルリクエストで記録を残しつつマージ。
操作ログを残す
いつ・どの端末で・何をしたかを後から追える。
よくあるつまずきと、最初の一歩
つまずきの代表は「確認疲れ」です。毎回の確認が多すぎると、人は中身を読まずにとりあえず承認してしまいます。そこで安全な操作はあらかじめ許可しておき、確認は危険な操作だけに絞ります。確認の回数を闇雲に減らすより、意味のある場面に集中させるのがコツです。
もうひとつは、すべての確認を飛ばす「全部許可」での運用です。手早く進みますが、慣れていない段階や共有端末では使わないほうが無難です。まずは読み取りと提案だけで内容を確かめてから実行に移る進め方に慣れ、社外へコードや顧客情報が出る操作（外部サービスへの送信やWeb取得）は線引きをはっきりさせておきます。
最初の一歩は小さくて構いません。ひとつのリポジトリで、認証情報の読み取り拒否と危険コマンドの確認だけを設定し、変更はプルリクエスト経由に固定する。ここから一週間使ってみて、現場の要望に合わせて許可をひとつずつ広げていきます。この回し方なら、業務を止めずに、かつ大きな事故も起きにくくなります。
最初の一歩・チェックリスト
ひとつのリポジトリだけで始める
認証情報の読み取り拒否と危険コマンドの確認を設定
変更はプルリクエスト経由に固定
一週間使い、現場の要望で1つずつ許可を広げる
ヒント
ヒント
ヒント
安全な操作はあらかじめ許可し、確認は危険な操作だけに絞ります。回数を闇雲に減らすより、意味のある場面に集中させるのがコツです。
Related ／ あわせて読む