Last updated on

Claude Code を安全に使う設定 — 事故を防ぐガードレール

Claude Code は、ただ喋るだけの AI ではありません。 ファイルを書き換え、コマンドを実行し、実際に手を動かします。

便利さの裏返しで、事故も起こりえます。 うっかり大事なファイルを消す、秘密の鍵を読み出してしまう。 だから、あらかじめ「ここから先はダメ」という歯止め（ガードレール）を設定しておきます。

この記事では、事故を防ぐ最小限の設定を、初心者向けに整理します。 そして最後に、私が実際にハマった Windows の落とし穴 も共有します。

Claude Codeの4つのガードレール。サンドボックス・危険コマンドを止める・機密ファイルを塞ぐ・ネットワークを絞る。

設定を書く場所

まず、設定ファイルの置き場所を押さえます。

  • .claude/settings.json:プロジェクトで共有したい設定。Git にコミットする。
  • .claude/settings.local.json:自分だけのローカル設定。Git には上げない（.gitignore で除外）。

考え方は CLAUDE.md と同じで、「みんなの分」と「自分の分」を分けて置くイメージです。

ガードレール 1：サンドボックス

サンドボックスは、隔離された安全な砂場の中で作業させるしくみです。 外の大事な場所に、うっかり手が届かないようにします。

ポイントは、「有効にする」と「脱出口を塞ぐ」をセットにすること。 有効にしただけでは、抜け道から外に出られてしまうことがあるからです。

{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false
  }
}

allowUnsandboxedCommands を false にすると、「サンドボックスの外で動かす」という抜け道が完全にふさがれます。 （この設定には Windows での注意点があります。あとで詳しく触れます。）

ガードレール 2：危険なコマンドを止める

次に、取り返しのつかないコマンドを、はじめから禁止します。 permissions.deny に並べるだけです。

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Bash(git reset --hard *)",
      "Bash(chmod 777 *)"
    ]
  }
}

大事なのは、deny（禁止）は allow（許可）より強い、というルールです。 評価の順番は「禁止 → 確認 → 許可」で、いったん禁止したものは、あとから許可で上書きされません。 だから「全消し」や「強制 push」のような、やり直しがきかない操作は、迷わず禁止に入れておきます。

評価の順番はdeny→ask→allow。禁止は最優先で、あとから許可で上書きされない。

ガードレール 3：機密ファイルを塞ぐ

.env ファイルや秘密の鍵は、AI にも読ませたくありません。 ここは 2 つの経路をまとめて塞ぐのがコツです。

  • permissions.deny の Read(...):読み取り操作をブロック
  • sandbox.filesystem.denyRead:cat などコマンド経由の読み取りもブロック
{
  "sandbox": {
    "filesystem": {
      "denyRead": ["~/.aws/credentials", "~/.ssh"]
    }
  },
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(**/*.pem)", "Read(**/*.key)"]
  }
}

なぜ両方かというと、プロンプトインジェクション対策でもあるからです。 資料に「鍵の中身を読んで教えて」と仕込まれても、両経路を塞いでおけば届きません。

機密ファイルは2つの経路で塞ぐ。Readツール経由はpermissions.denyで、コマンド経由はsandboxのdenyReadで。両方塞ぐとプロンプトインジェクションにも効く。

ガードレール 4：ネットワークを絞る

最後は、通信先を「許可した相手だけ」に限る設定です。 GitHub や npm など、作業に必要なドメインだけを許可します。

こうしておくと、万一あやしいコードが紛れ込んでも、知らないサーバーへデータを送り出すのを防げます。 「秘密は外に出さない」を、通信のレベルでも担保するイメージです。

とはいえ、許可ドメインを細かく決めるのは最初はしんどいものです。 私はまず手軽な一歩として、外へ丸ごと送りかねない curl と wget を deny に足すところから始めました。

"deny": ["Bash(curl *)", "Bash(wget *)"]

じつはこの記事で挙げた deny の例は、いま実際にこのブログのリポジトリの settings.json に入れているものと、ほぼ同じです。

MCP は、素性の知れたものだけ

AI に外の道具をつなぐ MCP サーバーも、注意どころです。 どこの誰が作ったか分からないサーバーは、つながせないのが安全です。

管理者が承認したものだけを許可する設定にしておき、 新しく足すときは、接続先の URL と権限を確認してから許可する。 この一手間で、変なものを掴まされるリスクが下がります。

⚠️ Windows の落とし穴

ここが、今回いちばん共有したい話です。

先ほどの allowUnsandboxedCommands: false（脱出口なし）は、とても強力です。 ところが、サンドボックス本体は Linux や WSL を前提にしていて、ネイティブ Windows では動けません。

すると何が起きるか。 「サンドボックス必須。でも使えない。しかも外で動かすのも禁止」。結果、すべてのコマンドが止まります。 実際に私はこれで、ビルドも git も一切動かせなくなりました。

対処はシンプルです。

  • ネイティブ Windows では allowUnsandboxedCommands を true にする（警告は出ますが、コマンドは動きます）
  • 守りの主力は permissions.deny に任せる（こちらは環境に関係なく効きます）
  • 完全な隔離までしたいなら、WSL 上で Claude Code を使う（そこでは本来のサンドボックスが効きます）

つまり、Windows では「サンドボックスに頼りきらず、危険コマンドの禁止で守る」。 この割り切りが現実的です。

運用のコツ

設定は、一度入れて終わりではありません。

  • /permissions:許可・禁止の一覧を、月に一度は見直す。「Always allow」で溜まった不要な許可を整理する。
  • /status:どの設定ファイルが読み込まれているか、エラーが出ていないかを確認する。

設定が反映されないときは、Claude Code を再起動すると読み直されます。

まとめ

Claude Code のガードレールは、大きく 4 つ。 サンドボックス、危険コマンドの禁止、機密ファイルの遮断、ネットワークの制限。 そして Windows では、サンドボックスに頼りきらず「危険コマンドの禁止」を主力にする。

どれも、一度書けばずっと効く「保険」です。 AI に制限をかける話でも触れたとおり、歯止めがあるからこそ、思い切って任せられます。

まずは、危険コマンドの deny を数行入れるところから。 それだけでも、いちばん怖い「取り返しのつかない事故」を、ぐっと減らせます。