Whim on Vim

/ log

Claude Code の安全な使い方

クロードは使い慣れるほど、確認を省いて何でも任せがちになります。そういった場面で起こりやすいインシデントを未然に防ぐために、しっかりとガードレールを設計しておくことが重要です。 最小セットの参考 [ ] Managed設定に disableBypassPermissionsMode: "disable" を入れる [ ] auto モードを使わせない場合は Managed設定に disableAutoMode: "disable" を入れる [ ] .env / ~/.ssh / ~/.aws の読み取りをdenyする(OSレベルで確実に止めるなら sandbox の denyRead と併用) [ ] sandbox.enabled: true にし、filesystem.denyRead / allowRead で読み取り範囲を絞る [ ] claude doctor と /status で読み込まれていることを確認する

Claude Code の安全な使い方

クロードは使い慣れるほど、確認を省いて何でも任せがちになります。そういった場面で起こりやすいインシデントを未然に防ぐために、しっかりとガードレールを設計しておくことが重要です。

さらに v2.1.283 以降、対話セッションの既定モードは auto(分類器モデルが承認を代行するモード)になりました。人間が確認を省かなくても、確認そのものが自動化される前提で設計する必要があります。

"With great power comes great responsibility" — Spider-Man (Amazing Fantasy #15, 1962)

安全の為の階層構造

クロードの挙動を制御するための設定ファイルは、複数のレイヤーに配置することができます。優先順位が強い順に並べると次のようになります。

  1. マネージドスコープ : managed-settings.json
  2. コマンドライン引数
  3. ローカルスコープ: your-project/.claude/settings.local.json
  4. プロジェクトスコープ: your-project/.claude/settings.json
  5. ユーザースコープ: ~/.claude/settings.json

Managed層にある設定ファイルは、OSのシステム設定領域に入っているため、管理者権限でないと編集することができません。一番強力なルールとなります。

※Managed層の配信手段は managed-settings.json のほか、managed-settings.d/ ディレクトリ、MDM プロファイル(macOS)、Windows レジストリ(HKLM)、claude.ai 管理コンソールからのサーバー配信があります。

その次に強いのが起動時のコマンドライン引数、続いてプロジェクト(特定のフォルダー)ごとに置く設定ファイルです。プロジェクト内では、Gitにコミットしない個人用の settings.local.json が、チームで共有する settings.json より優先されます。

そして意外かもしれませんが、ユーザースコープ(~/.claude/settings.json)は一番弱いレイヤーです。全プロジェクト共通のデフォルトとして機能し、プロジェクト側の設定で上書きされます。

managed-settings.json の参考

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "disableAutoMode": "disable",
    "deny": [
      "Read(./.env)",
      "Bash(su *)"
    ]
  },
  "claudeMd": "業務ポリシー: クライアントの個人情報・認証情報・未公開の見積内容をプロンプトに含めない。本番環境への適用は必ず人間の確認を経る。"
}

disableBypassPermissionsMode を disable にすると --dangerously-skip-permissions(bypassモード)を拒否できます。このキーはどの設定ファイルでも有効ですが、Managed に置くのは利用者本人が外せないようにするためです。

disableAutoMode を disable にすると auto モードを無効にできます。組織で無効にしたい場合は Managed に置きます。

deny は allow よりも強いです。また、bypassモードにも有効です。

ただし Read の deny が効くのは、Claude の組み込みファイルツールと、Claude Code が認識する Bash のファイル操作(cat, head, tail, sed, tee, リダイレクト > <)までです。grep -r のようにファイル名を指定しない読み方や、/usr/bin/curl、sh -c '...' のような別の書き方には効きません。

claudeMd は managed 層に置く settings.json 専用のキーで、ユーザースコープやプロジェクトスコープには使いません。

"ask": [
  "Bash(curl *)",
  "Bash(wget *)"
],
"allow": [
  "Bash(npm run build)"
]

その他にも permissions 内で ask や allow を使って細かく権限の設定をしていくことが可能です。

※ask に入れたコマンドはどのモードでも必ず確認が出る(例外:-p(非対話)で bypass 起動した場合は確認が出ず、「拒否」扱いになる)

Sandbox

sandbox をオンにすると、既定で制限されるのは「書き込み」です。作業ディレクトリと一時ディレクトリ以外には書き込めなくなります。一方で読み取りは制限されず、~/.ssh や ~/.aws を含め、マシンのほぼ全体を読めてしまいます。

親フォルダや秘密ファイルを読めなくするには、sandbox.filesystem.denyRead / allowRead を明示する必要があります。

{
  "sandbox": {
    "enabled": true,
    "filesystem": { "denyRead": ["~/"], "allowRead": ["."] }
  }
}

また、deny はコマンドを走らせる前の Claude Code 側のゲートキーパーですが、sandbox はOSレベル(macOSはSeatbelt、Linuxはbubblewrap)のゲートキーパーです。

任意の追記:その他のガードレール

permissions.blockReadsOutsideWorkingDirectories: true
# 作業ディレクトリ外の読み取りを全モードで拒否(v2.1.257 以降)

sandbox.allowUnsandboxedCommands: false
# Sandbox で失敗したコマンドを Sandbox 外で再実行する抜け道を禁止

検証コマンド

設定ファイルが読み込まれているか、有効になっているかをテストします。

/status
# セッション内でどのファイルから読み込まれているか確認

/permissions
# 有効になっているパーミッションルールの一覧

claude --dangerously-skip-permissions -p "echo test"
# bypassが止まるかテスト

最小セットの参考

  • [ ] Managed設定に disableBypassPermissionsMode: "disable" を入れる
  • [ ] auto モードを使わせない場合は Managed設定に disableAutoMode: "disable" を入れる
  • [ ] .env / ~/.ssh / ~/.aws の読み取りをdenyする(OSレベルで確実に止めるなら sandbox の denyRead と併用)
  • [ ] sandbox.enabled: true にし、filesystem.denyRead / allowRead で読み取り範囲を絞る
  • [ ] claude doctor と /status で読み込まれていることを確認する

参考リソース

Takaaki Yoneda

環境保全、グラフィックデザイン、マーケティングなどプログラミング以外にも幅広い興味を持ったソフトウェアエンジニアです。 最近の趣味は、ボードゲームと登山