Claude Codeの権限設計を実例で｜settings.jsonとhooksの書き方の勘所

「部署でもClaude Codeを活用したいが、AIの判断でファイルを削除されたり、メールを社外へ送られたりするのは避けたい」。企業から導入について伺うと、最初に挙がるのはこの懸念です。

必要なのは、利用者へ注意を呼びかけることだけではありません。危険な操作を設定によって最初から実行不能にすることが、より確実な答えになります。

Claude Codeには、AIへ渡す道具を細かな単位で管理できる機能があります。その中心が設定ファイルの settings.json と、ツール実行の前後へ任意の処理を組み込めるhooks（フック）です。両方を併用すれば、文章による注意から一歩進み、システム側で強制的に制止できます。

既存の解説は、開発者が作業速度を上げるための許可設定に重点を置くものが中心です。しかし営業や人事、経理、総務などで守るべき対象は、ソースコードだけではありません。誤送信された連絡、復元できない業務台帳、持ち出せない個人情報といった、バックオフィス特有のリスクを基準に設計する必要があります。

この記事では、当社がバックオフィスで現に使用している構成をもとに、deny→ask→allow の評価順、禁止を起点にした組み立て方、フックで処理を止める方法、パス指定で間違いやすい5点、組織へ強制配布する管理設定を順番に解説します。

管理部門や情シスが、自社用へ置き換えられる粒度でまとめました。

掲載する設定とフックは、当社（AIスキル）のバックオフィスで稼働している内容から、社名やアカウントなどを匿名化したものです。他社媒体の設定例を転載したものではありません。ルールの評価順、記述方式、管理ファイルの配置は、2026年8月14日現在のClaude Code公式資料（権限を設定する／Settings／Hooks）と照合しています。仕様やキー、初期値は変更される可能性があるため、導入時にはその時点の公式情報も必ず参照してください。

非エンジニア部署では、防ぎたい事故の形が違う

設定を書く前に、まず保護する対象を明確にします。この前提が定まらないままでは、何も通さない設定か、何でも通す設定へ極端に寄りがちです。

開発現場なら、本番環境やデータベース、リポジトリの履歴、認証情報などが代表的な保護対象です。損傷時の影響が大きい一方、通常は技術担当者の管理下にあります。

営業、人事、経理、総務で問題になる対象は異なります。導入支援の現場で聞いた不安は、主に次の4種類へ整理できます。

1. 社外へ届く情報。顧客宛てのメール、取引先へのSlack、外部共有の資料などです。下書きは有用でも、無確認の送信は取り消せません
2. 失うと元へ戻せないデータ。長期間更新してきた台帳、作業中の表計算、契約書原本など、履歴管理されていないファイルは上書きで旧状態を失います
3. AIへ開示できない内容。ログイン情報、マイナンバーを含む人事資料、給与関連データは、読み込ませること自体が問題になります
4. 防御用設定の変更。AIが自分の権限ファイルを書き換えられる状態では、厳格なルールを作っても保護になりません

いずれも攻撃者の悪意より、曖昧な依頼や文脈の読み違いといった偶発的なミスから発生しやすい事故です。

そのため、利用時の注意だけに依存する対策では足りません。

さらに非エンジニアには、確認画面の内容を評価できない問題があります。たとえば rm -rf ./tmp を許可してよいか問われても、安全性を判断できなければ承認画面は機能しません。1日に何十回も同様の表示が続けば、内容を確認せず承認する習慣も生まれます。不要な確認を減らすことも、安全性を高める設計の一部です。

権限の仕組み——allow・ask・denyと、判定される順番

Claude Codeのルールは3区分です。2026年8月14日に公式資料で確認できる役割を、実務向けに言い換えると次のようになります。

• allow（許可）……そのツールを都度承認せず使わせる指定
• ask（確認）……呼び出すたびに利用者の判断を求める指定
• deny（禁止）……該当する利用を実行させない指定

設計で特に重要なのは、照合が deny → ask → allow の順で進み、最初に一致した時点で結論が確定することです。

条件を細かく書けば優先される、という仕組みではありません。たとえば Bash(aws *) をdenyへ入れた場合、allowへ Bash(aws s3 ls) を追加しても前者が先に一致します。したがって、広い禁止の内側に個別の許可例外を設けることはできません。askとallowにも同じ関係があり、askに一致すれば、より限定的なallowが存在しても確認は表示されます。

括弧の有無で、禁止の効き方が変わる

denyは括弧を付けるかどうかで作用範囲が変わります。

• "Bash" のようにツール名だけ指定する場合。AIからその道具全体が見えなくなり、利用の候補にも上がりません
• "Bash(rm *)" のように対象を括弧内へ書く場合。ツールは残しつつ、一致した呼び出しのみ拒否します

当社ではSlackの送信機能に前者を使っています。AIへ「送らないように」と指示するだけでなく、送信手段自体を手元から取り除くため、誤操作の入口がありません。

権限モード——既定をどう置くか

個別ルールとは別に、全体の標準動作を defaultMode で選択できます。2026年8月14日時点で案内されているモードは以下です。

非エンジニア部門で bypassPermissions を選ぶべきではありません。公式資料も、損害を与えられないコンテナや仮想マシンなどの隔離環境に用途を限定しています。

組織で無効化するなら permissions.disableBypassPermissionsMode を "disable" にします。auto の停止には permissions.disableAutoMode を使います。

調査と原稿作成から始める導入初期には plan が役立ちます。ファイルを変更せず、現状把握と改善案の提示だけを任せられるためです。最初の2週間はこの設定で出力傾向を把握し、その後に編集を開放する進め方もできます。

設定ファイルは4か所ある。どれが勝つのか

ルールの保存場所は1つではありません。2026年8月14日現在、公式資料が示す主な配置は次の4か所です。

強さは、管理設定、コマンドライン引数、ローカル、プロジェクト、ユーザーの並びです。最上位の管理設定は、下位のファイルから変更できません。

ただし禁止については、通常の優先順位とは別に考える必要があります。どこか1つの階層でdenyに入った道具は、別階層のallowで復活できません。ユーザー側の禁止もプロジェクト側の許可より強く作用します。つまり、denyは配置場所を問わず残り、allowはdenyを覆せないという非対称な構造です。

見落としがちな落とし穴：許可は「信頼したフォルダ」でしか効かない

.claude/settings.json にあるallowと additionalDirectories は、ワークスペースを信頼するダイアログへ同意してから有効になります。同意前はファイルを認識しても、権限拡大に当たる指定は適用しません。

外部から入手したフォルダが自由に権限を増やせないようにする、合理的な保護です。一方でdenyとaskは能力を狭める指定なので、フォルダを信頼する前から作用します。

allowを書いても承認が続くなら、まず信頼済みか確認しましょう。

また定期処理のように対話画面を出せない運用では、信頼ダイアログに頼らず、禁止ルールとフックを安全の土台にします。

事故を止める三段構え——文章・設定・フック

当社では、単一の対策ですべてを守ろうとせず、1つを越えられても次が止める三層の防御を採用しています。

CLAUDE.mdはAIが取ろうとする行動へ影響しますが、権限を実装しているのはAIモデルではなくClaude Codeです。

したがって、文章は行動方針、settings.jsonとフックは越えられない境界として役割を分けます。取り消せない処理は、依頼文による自制ではなく後者で防ぎます。

この構造は、外部文書にAI向けの命令を紛れ込ませるプロンプトインジェクションにも有効です。たとえば受信メールに転送を促す指示が書かれていても、その文章はデータとして扱うよう1層目で定め、2層目で送信機能をなくし、3層目で外部持ち出しコマンドを拒否します。

文章の判別だけで攻撃を100%見抜くことはできません。目標はAIが絶対に騙されない状態ではなく、誤認が起きても実害へつながらない状態を作ることです。

実例：当社で動いているsettings.jsonの中身

以下は、当社のバックオフィス用リポジトリで利用している .claude/settings.json の権限箇所です。組織名とアカウントに関する情報だけを伏せています。

{
  "permissions": {
    "deny": [
      "Bash(rm -rf:*)", "Bash(git push --force:*)",
      "Read(**/.env)", "Read(**/.env.*)", "Read(**/*_key)",
      "Read(**/*.pem)", "Read(**/*.p12)", "Read(**/id_rsa*)",
      "Read(**/id_ed25519*)", "Read(**/credentials*)", "Read(**/token.json)",
      "Read(**/.netrc)", "Read(**/service-account*.json)",
      "mcp__slack__slack_send_message", "mcp__slack__slack_schedule_message",
      "mcp__slack__slack_add_reaction", "mcp__slack__slack_create_conversation",
      "mcp__slack__slack_create_canvas", "mcp__slack__slack_update_canvas"
    ],
    "ask": [
      "Bash(git push:*)", "Bash(git reset --hard:*)", "Bash(git clean -f:*)",
      "Write(context/owner/**)", "Edit(context/owner/**)",
      "Write(context/finance/**)", "Edit(context/finance/**)"
    ],
    "allow": [
      "Bash(ls:*)", "Bash(cat:*)", "Bash(grep:*)", "Bash(find:*)",
      "Bash(head:*)", "Bash(tail:*)", "Bash(wc:*)", "Bash(git add:*)",
      "Bash(git commit:*)", "Bash(git status:*)", "Bash(git diff:*)",
      "Bash(git log:*)", "WebSearch", "WebFetch"
    ]
  }
}

この例を、各ルールを置いた理由とともに見ていきます。

denyに入れたもの：取り返しがつかない4種類

① データを失う操作。Bash(rm -rf:*) はディレクトリ単位の削除、Bash(git push --force:*) は共有履歴を強制的に変更する処理です。実行後に判明しやすく、復旧へ多くの作業が必要です。末尾の :* は、半角空白とアスタリスクを使う Bash(rm -rf *) と同じ末尾ワイルドカードです。

② 閲覧させないファイル。.env、秘密鍵、credentials、token.json、サービスアカウント用JSONなど、資格情報に使われやすい名前を対象にしています。会話や要約、ログへ内容が入り得るため、読み取り段階から遮断します。

仕様上、Readのdenyは同一パスに対するEditも阻止しますが、WriteとNotebookEditまでは対象になりません。変更も禁じる場所には Edit(...) を追加するほうが安全です。この説明はClaude Code v2.1.208以降について記載された挙動に基づきます。

③ 他者へ見える操作。Slackの送信、予約投稿、リアクション、会話作成、キャンバスの作成と更新を止めています。文章以外でも相手には人間の反応と見えるため、他者の目に触れる操作をまとめて外部出力として扱う方針です。接続先ワークスペースを変更してもツール名による禁止は継続することを実機で確かめています。

④ 防御設定の編集。上の掲載例には含めていませんが、運用が定着したら Edit(.claude/**) のdenyも候補になります。AI自身に権限ルールを変更させず、設定変更は人が担当する境界を作るためです。

askに入れたもの：判断が要るが、禁止までは行かない

git push、git reset --hard、git clean -f は必要な場面もある一方、自動実行は避けたい処理です。全面禁止と自動許可の中間として、実行時に人へ確認します。

context/owner/** と context/finance/** への書き込みや編集も確認対象です。経営者情報と財務情報をフォルダで分離することで、重要領域だけに承認を要求できます。情報の機密度に合わせたフォルダ構成があって初めて、この粒度の権限制御が可能になります。

allowに入れたもの：毎日押していた確認だけ

allowは導入前の想像で埋めず、運用中に繰り返し承認していた処理だけを後から移しました。ファイル内容を調べる ls、cat、grep、find、head、tail、wc と、日常的なgit操作である add、commit、status、diff、log に限定しています。

Claude Codeは ls、cat、echo、pwd、head、tail、grep、find、wc、which、diff、stat、du、cd と、gitの読み取り専用形式の一部を標準で安全なコマンドと認識し、モードにかかわらず承認なしで動かします。この組み込み一覧は変更できないため、これらにも確認を挟む場合はaskまたはdenyを明示します。

何をdenyに入れるか——業務から逆算する4分類

自社版を作る際は、次の4つの観点で業務を棚卸しすると見落としを減らせます。

① 一度実行したら取り消せないものは何か

送信、公開、支払い、削除、権限付与という5種類を手掛かりに業務を確認します。営業ならメール送信や見積提出、人事なら応募者への結果通知、経理なら振込データ確定、総務なら公開告知などです。基準は後から撤回できるかどうかであり、保存した下書きはここへ含めません。

可能なら、設定で禁止する前に送信手段そのものを与えない構成にします。当社のGmail連携はOAuthスコープで送信権限を取得していないため、読むことと下書き作成はできても送れません。

ドライブとドキュメントにも読み取り専用スコープを使っています。権限ルールより前の接続段階で、不要な能力を削るほうが強固です。

② 読まれると困る情報は、どのファイルにあるか

資格情報以外にも、次の場所を確認しましょう。

• ダウンロード先。一時保存した契約書や給与明細が残存している場合があります
• 古い会議記録や営業メモ。取引情報が加工されず記載されていることがあります
• 個人用の備忘録。認証情報がそのまま記録されている例もあります
• 複製データの保存先。原本だけ保護しても、バックアップを読めれば防御になりません

人によって変わるファイル名だけでなく、統一しやすいフォルダ単位で範囲を定めると確実性が上がります。

③ AIが触ると、他の人の作業が壊れるものは何か

共同利用の表計算、同時編集する文書、複数部署が参照する台帳も対象です。本人の端末だけで影響を考えず、変更時に別部署の仕事を止めるデータがないか、組織を横断して確認します。

④ 外部の内容を読んだ直後に、何が起きうるか

メール、Webサイト、PDF、議事録などの外部情報は、直後の行動へ影響する可能性があります。当社では、それらを閲覧した後の送信、削除、設定変更、インストールについて、内容にかかわらず人の承認を必須としています。

取得先を WebFetch(domain:...) で限定する方法は有効ですが、WebFetchだけで通信全体は遮断できません。Bashが使えれば curl や wget から別URLへ接続できるからです。

Bashの引数パターンによるURL制限も堅牢ではありません。Bash(curl http://github.com/ *) としても、オプション位置、プロトコル、転送先、変数、空白の違いで一致しない場合があります。

公式が挙げる対応は、① curl や wget を止め、許可ドメインだけWebFetchへ通す、②PreToolUseフックでURLを検査する、③CLAUDE.mdへ方針を書くの3つです。

③だけでは強制境界にならないため①または②と組み合わせます。当社では①と②を重ねて運用しています。

hooksの書き方の勘所——exit 2で止める

フックは、ツールを使う前後など所定のタイミングで独自プログラムを動かす機構です。静的な形だけを照合する権限ルールと違い、入力の内容を調べて結論を変えられます。

法人利用で最初に理解したいイベントは次の3つです。

• PreToolUse……実行より前に起動し、条件に合えば処理を阻止できる
• PostToolUse……正常実行後に起動し、検査や後処理を担当する
• Stop……AIが返答を完了する際に起動し、未完了なら終了を差し戻す

フックは標準入力でJSONを受け取り、終了コードで結果を返します。共通データには session_id、transcript_path、cwd、permission_mode、hook_event_name が含まれ、イベントに応じて tool_name と tool_input なども渡されます。

登録の書き方

settings.json の hooks へ、当社では次のように登録しています。

{
  "hooks": {
    "PreToolUse": [{"matcher": "Bash", "hooks": [
      {"type": "command", "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/guard.py\""}
    ]}],
    "PostToolUse": [{"matcher": "Edit|Write|MultiEdit|NotebookEdit", "hooks": [
      {"type": "command", "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/quality.py\""}
    ]}],
    "Stop": [{"hooks": [
      {"type": "command", "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/stop_test.py\""}
    ]}]
  }
}

matcher で対象ツールを選び、縦棒を使えば複数名を列挙できます。$CLAUDE_PROJECT_DIR にはプロジェクトのパスが入るため、各利用者で保存場所が異なってもリポジトリの配布だけで動かせます。

実例1：危ない持ち込みと持ち出しを止める（PreToolUse）

guard.py は5種類を検査します。

1. リポジトリ取得元を限定。未承認の場所からコードを持ち込ませません
2. git経由のパッケージ導入元を限定。同様に不審なコードの混入を防ぎます
3. 取得直後の実行を拒否。ダウンロード結果をそのままシェルへ渡す処理を遮断します
4. コードの送付先を限定。社内データが想定外の接続先へ出ることを防ぎます
5. 機密ファイルの読み出しを拒否。Read以外のコマンドを使った迂回も塞ぎます

最後の対策では、内容を表示できるコマンドをまとめて対象にします。

READERS = (r"cat|bat|tac|more|less|head|tail|strings|xxd|od|hexdump|nl|rev|"
           r"grep|egrep|fgrep|rg|ag|awk|gawk|sed|sort|uniq|cut|paste|column|tr|fold|"
           r"base64|base32|uuencode|openssl|Get-Content|gc|type")

cat のみを止めても less で表示できるため、同じ目的を果たす手段を一群として扱う必要があります。拒否処理は簡潔です。

def deny(reason):
    print(reason, file=sys.stderr)
    sys.exit(2)  # 終了コード2で呼び出しを拒否

拒否理由を標準エラーへ書き、コード2で終えます。その説明がAIへ戻るので、AIは制止された原因を踏まえて代替手段を選べます。フックは停止するだけでなく、次の判断に必要な理由も返す設計にします。

実例2：壊れたまま先へ進ませない（PostToolUse）

quality.py はファイル変更後に構文を検査し、問題があればコード2で差し戻します。問題がなければフォーマッタで形式を整えます。JSONやCSVの破損を発生直後に検知できるため、後工程がまとめて停止してから原因を探す事態を減らせます。

ただし検査ツール自体が使えない環境では、確認を省略して通す設計です。

def run(cmd, cwd=None):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=30, cwd=cwd)
        return p.returncode, (p.stdout or "") + (p.stderr or "")
    except Exception as e:
        return 0, "skip: %s" % e  # 検査不能な環境では処理を継続

安全目的のフックは判断不能なら止め、品質目的のフックは判断不能なら通す、という違いを設けています。

安全検査を通せば事故につながりますが、補助的な品質検査で業務を止め続けると、利用者がフック自体を外す原因になるためです。

実例3：「終わったことにさせない」（Stop）

stop_test.py は応答終了前に動き、テストが存在する案件ではテストを実行します。失敗していれば完了を認めず、修正へ戻します。

    # 差し戻し後に再度停止して循環することを防ぐ
    if data.get("stop_hook_active"):
        sys.exit(0)

Stopで差し戻されたAIは作業を続け、再び終了しようとします。そこで毎回拒否すると循環するため、stop_hook_active が有効な再停止時は通過させる処理が必須です。非開発業務なら、指定フォルダに下書きが保存されたか、チェックリストが完了したかを終了条件にする応用もできます。

パス指定と記法でつまずく5か所

危険なのは設定エラーが明示される場合より、設定できたと思いながら実際には一致していない場合です。代表的な5点を事前に確認しましょう。

① 先頭の / は「ファイルシステムの根」ではない

ReadとEditでは、次の4種類のパス指定を使い分けます。

Read(/Users/alice/file) はOS上の絶対パスではなく、スラッシュ1つは設定ファイル位置を起点にします。絶対指定にはスラッシュを2つ使います。

特に ~/.claude/settings.json へ Read(/secrets/**) と書くと、案件内ではなく ~/.claude/secrets/** が対象になり、意図した場所を保護できません。

全案件共通の禁止をユーザー設定へ置く場合は、// または ~/ で起点を明示します。Read(**/.env) のような名前指定は任意の深さで一致し、Read(.env) と同等ですが、現在位置より下だけが対象です。全体から探すなら Read(//**/.env) とします。

② ワイルドカードの前の空白で意味が変わる

• Bash(ls *)……単語境界が必要なため ls -la には一致し、lsof には一致しない
• Bash(ls*)……接頭辞だけを見るため、上記の両方へ一致する

allowでは空白を含む前者が安全です。Bash(git*) ではgitから始まる別コマンドまで許可する可能性があります。末尾の :* は空白付きワイルドカードと同じで、Bash(ls:*) は Bash(ls *) と等価です。ただし末尾以外の Bash(git:* push) ではコロンが文字として扱われます。

③ つなげたコマンドは、1つずつ別に許可が要る

safe-cmd && other-cmd は Bash(safe-cmd *) だけでは許可されません。

&&、||、;、|、|&、&、改行で区切られた各部分が、それぞれallowに一致する必要があります。

timeout、time、nice、nohup、stdbuf は照合前に取り除かれる組み込みラッパーなので、Bash(npm test *) は timeout 30 npm test にも一致します。この一覧は変更できません。

一方、docker exec など一覧外の実行ランナーは内部コマンドまで分解されません。ランナーのrun以降を広く許可すれば、その後ろの任意処理が通る可能性があります。内部の処理まで含めた限定的なルールを個別に用意します。

④ ツールの名前は、画面の表示と違うことがある

照合に必要なのは表示ラベルではなく正式名称です。公式例では、画面上の「Stop Task」に対する正式名は TaskStop です。既知の名称へ一致しないdenyやaskがある場合、Claude Codeは起動時に警告するため、変更後は一度起動して警告の有無を確認します。

⑤ MCPで繋いだ道具の名前の付き方

MCP（AIと業務サービスを接続する共通インターフェース。詳細はMCPの解説記事を参照）では、名称が mcp__サーバー名__ツール名 になります。

• mcp__slack……対象サーバーが提供するツール群へ一致する
• mcp__slack__*……ワイルドカードを使った同範囲の表現
• mcp__slack__slack_send_message……指定した単一ツールだけへ一致する
• mcp__*……denyで全MCPサーバーの全ツールを一括拒否する

当社が個別名を列挙する理由は、同じSlackサーバー内でも閲覧は残し、送信だけを外すためです。全面停止なら mcp__* のみで対応できます。allow側の "*" や "mcp__*" のように広すぎる指定は警告され、無視されるため、許可時は具体的なサーバー名が必要です。

全社に配る——管理設定で手元から外せなくする

リポジトリ内の設定はチームへ共有できますが、各利用者がローカルで調整できます。全社共通で変更を認めない境界には、下位から上書きできない管理設定を使用します。

2026年8月14日時点で、公式資料に記載された配置先は以下です。

通常利用者には変更できない場所なので、配置には管理者権限が必要です。

情シスがMDMやレジストリポリシーを介して配布すれば、既存の端末管理へ組み込めます。

管理設定でしか使えないキー

• allowManagedPermissionRulesOnly……true にすると、ユーザー設定とプロジェクト設定からallow、ask、denyを追加できず、管理側のルールだけを採用する
• allowManagedHooksOnly……管理者が配ったフック以外を利用できなくする
• allowManagedMcpServersOnly……接続可能な外部サービスを管理側で限定する
• strictPluginOnlyCustomization……スキル、エージェント、フック、MCPサーバーの追加経路を制限する

permissions.disableBypassPermissionsMode を "disable" にし、承認を飛ばすモードも組織として無効化することを推奨します。どのスコープでも機能しますが、利用者が変更できない管理設定に置くのが適切です。

権限とサンドボックスは役割が違う

• 権限……利用可能なツールとアクセス先のファイルやドメインをClaude Code側で統制し、全ツールへ適用する
• サンドボックス……Bashと子プロセスのファイル・通信アクセスをOS側で制限する

ReadやEditのdenyはClaude Codeが認識するファイル操作へ効きますが、PythonやNodeのプログラムが自力でファイルを開く間接アクセスまでは防げません。その迂回も止める場合、OSレベルのサンドボックスが必要です。

一般的な非エンジニア部署では、権限ルールとフックで足りることが多いでしょう。

ただし高機密情報を扱う組織や認証取得企業では、サンドボックスを含む構成も検討します。詳しい考え方はセキュリティ対策の記事でも紹介しています。

進め方——禁止から作り、確認を減らしていく

ここまでを導入手順へ落とすと、次の順番になります。

第1段：禁止を決める（着手から1週間）

4分類で挙げた対象をdenyへ入れます。初期は範囲を広めに取って構いません。必要なら後から緩和できますが、発生済みの事故は元に戻せないためです。

同時に連携サービスのスコープを調べ、閲覧だけで足りる接続には読み取り専用を選びます。接続元で能力を削れば、settings.jsonで守る対象も減ります。

第2段：確認を挟む（1〜2週間目）

業務上は必要でも自動実行を避けたいものをaskへ入れます。承認回数が多い時期ですが、その記録が次のallow選定に使えます。

plan モードで閲覧と提案に限定する方法も有効です。利用者がAIの出力傾向を理解し、委任できる範囲を体感する期間として使えます。

第3段：許可を足す（3〜4週間目）

日々繰り返し承認している処理だけをallowへ移します。便利そうかではなく、実運用で反復しているかを判断基準にします。

確認画面の「はい、今後は聞かない」を選ぶとルールは自動追加されます。

複合コマンドでは承認が必要な部分ごとに別ルールが保存され、1コマンドにつき最大5つになります。意図以上の範囲が許可されていないか、/permissions で定期点検してください。

第4段：管理設定で固定する（2か月目以降）

利用方法が固まり、複数部署へ広げる時点で共通のdenyだけを管理設定へ移します。現場経験を根拠に禁止理由を説明できるため、利用者の納得も得やすくなります。

権限設計で多い失敗は、制約が厳しすぎて定着しないことです。

事故後に締めることはできますが、一度使えないと判断されたツールを再び利用してもらうのは困難です。安全境界を守りながら、反復する確認を段階的に減らします。

よくある質問

設定ファイルは誰が書くべきですか?

denyの対象を決めるのは、取り消せない業務や機密の保存場所を把握している現場担当者が適任です。JSONの記述と管理設定の配布は、情シスまたは外部支援へ任せられます。業務側が境界を決め、技術側が設定へ変換する分担が進めやすいでしょう。

禁止を増やしすぎると、使い物にならなくなりませんか?

denyを撤回不能な操作へ絞れば、調査、閲覧、下書き、集計など通常の利用はほぼ妨げません。操作性を下げやすいのはdenyの数より、判断できない確認の多さです。反復する安全な確認をallowへ移せば負担を減らせます。

フックを書くのに、プログラミングの知識は必要ですか?

独自プログラムを動かすため、初期作成には技術知識が必要です。ただし構築後に現場が日常的に書き換えるものではありません。当社の支援でも最初にフックを整え、その後の運用を担当部署へ引き継ぎます。settings.json の権限ルールは、非エンジニアでも十分管理できます。

設定を書いたのに、思ったとおりに効きません

①起動時に名称エラーの警告がないか、②/permissions で意図したファイルを読み込んでいるか、③allowの場合はフォルダを信頼済みか、④パス先頭のスラッシュ数が正しいかの順で確認します。経験上、多くの不一致はこの4項目で見つかります。

AIが権限をすり抜けることはありますか?

権限はAIの判断から独立してClaude Codeが実施するため、一致した呼び出しはAIの意向に関係なく拒否されます。ただし指定パターンに穴があれば、別形式の呼び出しは一致しません。公式資料もBash引数による制約の弱さを説明しています。AIの意思ではなくルールの不足を防ぐため、denyを先に洗い出します。

どこから相談すればいいですか?

最初に、AIへ絶対に任せたくない操作を1つ挙げてください。settings.jsonだけで防げるか、接続スコープを削るべきか、フックが要るかを整理できます。現在の連携状況から、すでに利用可能になっている外部経路も確認します。ご相談とお見積りは無料です。

まとめ

Claude Codeの権限について、評価方法、設定例、フック、組織への展開まで見てきました。実務上の要点は次のとおりです。

• 管理部門で守る対象を業務から特定する。外部へ出る情報、復元不能なデータ、非公開情報、防御設定の4方向で確認する
• 照合順は deny → ask → allow。最初に一致した条件が採用され、限定的なallowでも広いdenyの例外にはできない
• denyとallowには強さの差がある。全社の境界は管理設定、部署固有の線はプロジェクト、個人の効率化はローカルへ分担する
• 方針・権限・フックを重ねる。文章で行動を導き、取り消せない処理は機械的な境界で阻止する
• フックで拒否するなら exit 2。標準エラーへ理由を出し、安全検査は判断不能時に止め、品質検査は継続させる
• パスの起点を取り違えない。先頭のスラッシュ1つは設定ファイル基準で、ファイルシステム基準の絶対指定には2つ使う
• denyから始めて承認を減らす。allowを予想で作らず、実際に繰り返した安全な承認だけを移す

担当者の注意力に依存する運用は、人が交代すれば引き継がれないことがあります。

設定ファイルとフックにした規則なら、担当者やAIモデルが替わっても境界は残ります。最初に土台を整えれば、業務変更に合わせて対象を更新していけます。

当社はClaude Codeの研修と法人向け導入支援を行っています。禁止、確認、許可の切り分けから、settings.json の設計、フック開発、管理設定による全社配布までまとめてご相談いただけます。この記事の構成も当社の実運用を基にしています。ご相談とお見積りは無料です。

AIへ任せない操作を、実行できない権限として設計します
相談とお見積りには費用がかかりません

導入について相談する →