Claude Codeのセキュリティ設定｜権限・秘密情報・本番事故を防ぐ6項目

SaaS開発で「ログを見て原因を探して」とClaude Codeに頼んだら、.env にあるAPIキーまで読ませていた。「不要ファイルを片づけて」と頼んだら、残すべきファイルまで消えた。AIに悪意がなくても、任せる範囲が曖昧なら事故は起きます。

僕自身、権限設定の記事を書いた後も、公開済みの設定例に現在のClaude Codeでは正しく一致しないルールが残っていることに気づきました。安全記事のコードが間違っていれば本末転倒です。そこで2026年7月21日に公式仕様と手元のコードを照合し、設定を作り直しました。

この記事では、初心者が最初の30分で入れられる対策を6項目に絞ります。個別ルールの書き方はClaude Code権限ガイドでも確認できます。権限ルールだけを過信せず、Git、サンドボックス、本番ガードを重ねるのが結論です。

この記事の要点

• 最初は default モードを使い、編集と通常のシェルコマンドを人が確認する
• .env と secrets/ は Read と Edit の両方で拒否する
• Glob(path) や Write(path) ではなく、現行仕様に合う Read(path) と Edit(path) を使う
• curl | bash のような複合操作は1本の文字列で止めず、curl と wget 自体を拒否する
• 権限設定とサンドボックスは役割が違う。機密案件では両方を使う
• 本番への書き込みは、AIの判断ではなくコード側の条件で止める

Claude Codeに任せる範囲と、人が判断する範囲

Claude Codeに任せてよいのは、差分を戻せる作業です。ファイル調査、テスト実行、変更案の作成、ローカル環境での編集は任せやすい。一方、認証情報の共有、依存パッケージの追加、本番デプロイ、データ削除、権限付与は人が判断します。

作業	Claude Code	人
ソースやログの調査	機密を除いて実行	渡してよい範囲を決める
コード編集とテスト	実装して結果を報告	差分とテスト結果を確認
パッケージ追加	候補と理由を提示	名前・保守状況・権限を確認
Git push・デプロイ	手順と対象を提示	実行先と差分を確認して承認
本番DBの更新・削除	実行しない	バックアップと手順を確認して実行

「AIなら安全に判断してくれる」ではなく、判断が必要な操作は止まる構造にするのが基本です。

1. 最初はdefaultモードで始める

default モードでは、作業ディレクトリ内の読み取りは原則そのまま動き、ファイル編集や通常のシェルコマンドは確認対象になります。初心者が最初から広い allow を書く必要はありません。

{
  "permissions": {
    "defaultMode": "default"
  }
}

allow、ask、deny が同じ操作に一致した場合は、deny、ask、allow の順に評価されます。禁止したい操作は deny に置けば、広い allow があっても拒否されます。正確なパターン構文は公式の権限ドキュメントで確認できます。

auto モードには操作を判定する仕組みがありますが、公式にも安全を保証する機能ではないと明記されています。本番や顧客データを扱う作業で、レビューの代わりにはしません。bypassPermissions は権限確認そのものを飛ばすため、使い捨てのコンテナやVM以外では使わないでください。

2. 秘密情報をGitとClaude Codeの両方から遠ざける

APIキーはコードに書かず、環境変数から読みます。まず .gitignore でGitへの混入を防ぎます。

.env
.env.*
!.env.example
*.pem
*.key
*-service-account.json
secrets/

次にClaude Codeの組み込みファイルツールからも隠します。現在のファイル権限チェックでパスに一致するのは Read(path) と Edit(path) です。Glob(path)、Write(path)、NotebookEdit(path) はパス付きルールとして使わないでください。

"deny": [
  "Read(.env)",
  "Read(.env.*)",
  "Read(secrets/**)",
  "Edit(.env)",
  "Edit(.env.*)",
  "Edit(secrets/**)"
]

ただし、この設定だけで「どんなプログラムからも読めない」とは言えません。Read と Edit の拒否は組み込みツールとClaude Codeが認識できる一部のコマンドには効きますが、Node.jsやPythonの任意スクリプトがファイルを開く処理までは防げません。そこは後述するOSレベルのサンドボックスで補います。

ログにも鍵を出しません。値ではなく、設定名と対処だけを表示します。

const token = process.env.QIITA_TOKEN;

if (!token) {
  throw new Error("QIITA_TOKEN が未設定です。.env を確認してください。");
}

// NG: console.error(`認証失敗: token=${token}`);
console.error("認証に失敗しました。QIITA_TOKEN を再確認してください。");

会話に貼るログも同じです。APIキー、Cookie、顧客情報、本番DBのURLは伏せ字にしてから渡します。

3. 危険コマンドは「文字列1本」ではなく操作単位で止める

以前のこの記事では Bash(curl * | bash) を拒否すれば、ダウンロードしたスクリプトの直接実行を止められると説明していました。これは堅い境界ではありません。Claude Codeは複合コマンドを分解して確認し、Bashの引数パターンには表記揺れや変数を使った抜け道があります。

初期設定では、取得コマンドそのものを止めます。必要なWebアクセスは、許可ドメインを指定した WebFetch に寄せます。

"deny": [
  "Bash(rm *)",
  "Bash(rmdir *)",
  "Bash(git push --force *)",
  "Bash(git reset --hard *)",
  "Bash(curl *)",
  "Bash(wget *)",
  "PowerShell(Remove-Item *)",
  "PowerShell(git push --force *)",
  "PowerShell(git reset --hard *)"
]

rm を全面禁止すると不便ですが、最初は止めておき、必要なプロジェクトだけ狭く緩めるほうが事故を見つけやすいです。ネットワーク先を厳密に制限したい場合は、WebFetch(domain:example.com)、PreToolUseフック、サンドボックスのドメイン許可リストを使います。

CLAUDE.md にも意図を書きます。ただし文章はAIの振る舞いを整えるもので、強制力のある境界ではありません。deny やフックと組み合わせます。

## 安全ルール

- .env と secrets/ は読まない。値が必要な場合は人に確認する。
- 削除、force push、本番更新は実行せず、対象と手順だけを提示する。
- ネットから取得したスクリプトは、内容と配布元を確認するまで実行しない。

4. Bashの子プロセスはサンドボックスで囲う

権限ルールは「Claude Codeがどのツールを呼べるか」を制御します。サンドボックスは「Bashから起動したプロセスが、どのファイルやネットワークへ届くか」をOS側で制限します。役割が違うので、片方だけで十分とは考えません。

macOS、Linux、WSL2ではClaude Code内で /sandbox を実行して有効化できます。ネイティブWindowsは2026年7月21日時点で未対応なので、Windows利用者はWSL2か隔離したコンテナを使います。

組織でサンドボックスを必須にする場合は、管理設定で次の3項目を使います。

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

failIfUnavailable はサンドボックスを開始できない環境でClaude Code自体を止めます。allowUnsandboxedCommands: false は、失敗したコマンドをサンドボックス外で再実行する抜け道を閉じます。個人のネイティブWindows設定へそのまま入れると起動できないため、対応OSまたは管理環境だけで使ってください。詳細は公式のサンドボックス解説が一次情報です。

5. 依存パッケージと外部入力は人とコードで検証する

Claude Codeが提案したパッケージ名が、本物と一文字だけ違うことがあります。npm install は確認対象にし、lockfileをコミットします。

"ask": [
  "Bash(npm install *)",
  "Bash(npm uninstall *)",
  "Bash(git commit *)",
  "Bash(git push *)"
]

依存関係は機械でも確認します。

npm ci
npm audit --audit-level=high

ユーザー入力やAPIレスポンスも、そのままDB処理へ渡しません。境界で型と値を検証します。

import { z } from "zod";

const Payload = z.object({
  email: z.string().email(),
  amount: z.number().int().positive().max(100000),
});

const safe = Payload.parse(await req.json());

safe だけを後続処理へ渡せば、想定外の文字列や巨大な金額を早い段階で止められます。

6. 本番書き込みはコード側で止める

本番事故は、確認メッセージだけでは防げません。「フラグが必要」と表示しているのに、実装ではフラグを確認していないコードも起こり得ます。次のガードは、--write があり、本番環境で、--force-production がない場合だけ終了します。

// scripts/db-query.mjs
const env = process.env.NODE_ENV ?? "development";
const args = new Set(process.argv.slice(2));
const wantsWrite = args.has("--write");
const forceProduction = args.has("--force-production");

if (env === "production" && wantsWrite && !forceProduction) {
  console.error("本番への書き込みには --force-production が必要です。");
  process.exit(1);
}

console.log("guard passed");

このフラグは最後の確認であって、単独の認可ではありません。本番用アカウントを分け、バックアップを取り、更新対象を表示してから実行します。

3つのUse case

Use case 1: SaaS連携で顧客データを調べる

• 入力: 伏せ字にしたAPIログ、再現手順、.env.example
• 出力: 原因候補、修正差分、ローカルでの確認コマンド
• 人の確認: 顧客情報が残っていないか、更新APIを呼ばないか

StripeやGoogle Workspaceの障害調査では、ログに顧客メールやトークンが混ざります。Claude Codeには伏せ字済みログと再現手順だけを渡し、認証情報は環境変数に残します。

Use case 2: AWS・GCP・Azureの設定を変更する

• 入力: 開発環境のTerraform、変更要件、対象リソース一覧
• 出力: コード差分、terraform plan、ロールバック案
• 人の確認: apply の対象、IAM権限、本番アカウント

Terraformの差分作成と plan までは任せても、apply とIAM権限付与は人が確認します。開発用と本番用の認証情報を分けます。

Use case 3: 記事や商品ページを自動公開する

• 入力: 下書き、公開日、内部リンク、CTA
• 出力: 完成原稿、ビルド結果、公開予定URL
• 人の確認: 誤情報、公開先、削除や大量リダイレクトの有無

下書き生成、リンク確認、ビルドは自動化できます。公開は、変更ファイル、公開URL、ビルド結果が揃ったときだけ実行します。

コピペで使える動く確認コードと最小設定

ネイティブWindowsを含む個人環境では、まず次を .claude/settings.json に置きます。サンドボックス設定は対応OSで別途追加してください。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "default",
    "ask": [
      "Bash(npm install *)",
      "Bash(npm uninstall *)",
      "Bash(git commit *)",
      "Bash(git push *)"
    ],
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)",
      "Edit(.env)",
      "Edit(.env.*)",
      "Edit(secrets/**)",
      "Bash(rm *)",
      "Bash(rmdir *)",
      "Bash(git push --force *)",
      "Bash(git reset --hard *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "PowerShell(Remove-Item *)",
      "PowerShell(git push --force *)",
      "PowerShell(git reset --hard *)"
    ]
  }
}

Claude Codeは頻繁に更新されます。2026年7月21日時点のファイル権限仕様はv2.1.208以降を前提にしているため、claude --version で確認し、古ければ先に更新してください。

Pitfall: よくある失敗と直し方

失敗	なぜ危ないか	直し方
Glob(**) をallowに入れる	パス付きGlobルールは現在のファイル権限チェックに一致しない	読み取り範囲は Read(path) で書く
Write(**) をaskに入れる	パス付きWriteルールは一致しない	Edit(path) を使うか、default の確認を使う
Bash(curl * | bash) だけ拒否する	表記や変数を変えた操作を堅く制限できない	Bash(curl *) と Bash(wget *) を拒否する
.env をdenyしたので安心する	任意のNode/Pythonプロセスまでは防げない	対応OSではサンドボックスも有効にする
--force-production と表示するだけ	フラグをコードで判定しなければ常に止まるか常に通る	3条件をテストする
bypassPermissions をPC上で使う	権限確認と安全チェックを飛ばす	隔離コンテナやVMだけに限定する

よくある質問

Q. deny を入れれば .env は絶対に読まれませんか?

組み込みのファイルツールには効きますが、任意のNode.jsやPythonプロセスまで止める境界ではありません。対応OSではサンドボックスを重ね、ネイティブWindowsではWSL2か隔離コンテナを使います。

Q. auto モードを使わなければ安全ですか?

モードだけでは決まりません。秘密ファイルの拒否、本番認証情報の分離、削除コマンドの拒否、コード側の本番ガードを重ねてください。

Q. まず1つだけ直すなら何ですか?

今日、.env がGit管理に入っていないか確認し、Read(.env) と Edit(.env) を deny に置いてください。その後に削除とforce pushを止めます。

公開前チェックリスト

• .env と鍵ファイルが .gitignore に入っている
• Read と Edit の両方で秘密ファイルを拒否した
• 削除、force push、ネット取得コマンドを拒否した
• パッケージ追加、commit、pushを人の確認対象にした
• 本番用と開発用の認証情報を分けた
• 対応OSではサンドボックスを有効にした
• 本番ガードを「拒否・許可・開発」の3条件で試した
• ログとプロンプトに鍵や顧客情報が含まれていない

ここまでの設定を自分の環境へ順番に入れるなら、設定ガイドを見る（500円）から進めてください。権限、MCP、CLAUDE.md、hooksを別々の記事から集めずに済みます。

実際に試した結果

2026年7月21日に、この記事のJSONを構文解析し、本番ガードを3条件で実行しました。本番で --write だけなら終了コード1、本番で --write --force-production なら0、開発環境で --write なら0になることを確認しています。また、公開原稿から Glob(**)、Write(**)、Bash(curl * | bash) の旧例が消えていることを自動チェックに追加しました。ネイティブWindowsではClaude CodeのOSサンドボックスが使えないため、実運用ではWSL2または隔離コンテナを選んでください。まず今日、自分の .claude/settings.json と .gitignore を開き、秘密ファイルの拒否設定を確認するところから始めてください。