ホーム
BLOG
ものづくりAI研究所
Claude Codeを使う上で最低限知っておきたいセキュリティ対策

Claude Codeを使う上で最低限知っておきたいセキュリティ対策

1 そのClaude Code、セキュリティ設定は大丈夫ですか？
2 Claude Codeは「4層の多層防御」で設計されている
3 パーミッション — すべての操作は「許可」から始まる
4 機密ファイルの保護 — `permissions.deny` で「読ませない」設定をする
5 サンドボックスとネットワーク制限 — OSレベルの隔離で「最悪のケース」を防ぐ
6 Hooks — 標準設定では足りない場面に、カスタムガードレールを設ける
7 プロンプトインジェクション対策 — Claude Codeに組み込まれた4つの防御機構
8 MCP Serverとチーム運用 — 拡張と組織化のセキュリティ
9 まとめ：まずやるべき3つのこと
10 参照元（公式ドキュメント）

そのClaude Code、セキュリティ設定は大丈夫ですか？

Claude Codeを使い始めたものの、「自分のPCで動くAIって、セキュリティ的に大丈夫なのか？」と気になっている方は多いのではないでしょうか。

ChatGPTやClaude.aiはブラウザ上で動きますが、Claude Codeはあなたのマシンのターミナルで直接動きます。
ファイルの読み書き、シェルコマンドの実行まで自律的に行えます。
つまり、ブラウザAIとはリスクの性質が根本的に異なるのです。

「便利だからとりあえずデフォルト設定で使っている」
「.env にAPIキーを入れたまま作業しているけど、これClaude Codeに見えてるよな……」

——そんな状態で使い続けていないでしょうか。

この記事では、Claude Code公式ドキュメントに基づいて、最低限押さえておくべきセキュリティ対策を解説します。

読み終わる頃には、「何が危険で」「何を設定すれば安心か」が明確になっているはずです。

Claude Codeは「4層の多層防御」で設計されている

結論から言えば、Claude Codeのセキュリティは1つの機能に頼っていません。
以下の4層構造で多層的に守られています。

Layer	防御機能	役割
Layer 1	サンドボックス	OSレベルでファイルシステムとネットワークを物理的に隔離する土台
Layer 2	ネットワーク制限	接続先ドメインをホワイトリストで制御
Layer 3	パーミッション	操作ごとに deny / ask / allow で許可・拒否を判断
Layer 4	Hooks	チーム独自のカスタムルールを差し込めるガードレール

graph TB
    subgraph L1["Layer 1：サンドボックス"]
        subgraph L2["Layer 2：ネットワーク制限"]
            subgraph L3["Layer 3：パーミッション"]
                subgraph L4["Layer 4：Hooks"]
                    CC[Claude Code]
                end
            end
        end
    end

    style L1 fill:#e8f5e9,stroke:#4caf50
    style L2 fill:#e3f2fd,stroke:#2196f3
    style L3 fill:#fff3e0,stroke:#ff9800
    style L4 fill:#fce4ec,stroke:#e91e63

デフォルトの状態でも「読み取り以外は都度確認が入る」という安全設計になっています。
ただし、機密ファイルの除外やネットワーク制限は自分で設定しないと有効になりません。

この記事を読みながら、あなたの settings.json を開いて、一緒に設定していきましょう。

パーミッション — すべての操作は「許可」から始まる

5つのパーミッションモード — まずは default で始めるのが正解

Claude Codeには5つのパーミッションモードがあります。

モード	動作	用途
default	ツールの初回使用時に都度許可を求める	通常の開発作業
acceptEdits	ファイル編集は自動承認、コマンドは都度確認	コーディング主体の作業
plan	分析のみ。ファイル変更やコマンド実行は一切不可	設計・調査フェーズ
dontAsk	事前に許可したツール以外は自動拒否	CI/CD環境や厳格な運用
bypassPermissions	すべての確認をスキップ	コンテナ/VM等の隔離環境専用

初めて使う場合は default一択です。
ファイルの読み取り（Read、Grep等）は許可不要ですが、ファイルの変更やBashコマンドの実行には必ず確認が入ります。

まずはこの確認フローに慣れることが大事です。

deny → ask → allow — ルール評価は「拒否が最強」

パーミッションルールの評価順序は deny → ask → allow です。
最初にマッチしたルールが適用されます。

graph LR
    A[操作リクエスト] --> B{deny に
マッチ？}
    B -- Yes --> C[ブロック]
    B -- No --> D{ask に
マッチ？}
    D -- Yes --> E[ユーザーに確認]
    D -- No --> F{allow に
マッチ？}
    F -- Yes --> G[自動許可]
    F -- No --> H[デフォルト動作]

    style C fill:#ef5350,color:#fff
    style G fill:#66bb6a,color:#fff

つまり、denyルールに入れたものは、他の場所でどう設定しても絶対にブロックされます。
チームで使う場合、誰かが誤ってallowルールを追加しても、denyルールが最優先で効きます。

「最悪のケースを防ぐ安全弁」として機能するのです。

`–dangerously-skip-permissions` は名前通り本当に危険

起動時に --dangerously-skip-permissions フラグを付けると、前述の deny / ask / allow の仕組みがすべて無効化されます。

ネット上で「とりあえずこのフラグを付ければ確認が出なくて快適」という記事を見かけることがありますが、ローカルの開発環境では絶対に使ってはいけません。

このフラグはDockerコンテナやVMのような「壊れても問題ない隔離環境」で、自動化パイプラインを動かす場合にのみ使うものです。

/permissions コマンドで現在の設定を確認・変更できます。
月に一度でもチェックする習慣をつけておくと安心です。

機密ファイルの保護 — `permissions.deny` で「読ませない」設定をする

`.claude/settings.json` にdenyルールを追加する

APIキー、データベースパスワード、秘密鍵——開発プロジェクトには、AIに読ませたくないファイルが必ずあります。

Claude Codeでは permissions.deny 設定で、特定のファイルへのアクセスを明示的にブロックできます。

{
  "permissions": {
    "deny": [
      "Read path .env",
      "Read path .env.*",
      "Read path secrets/**",
      "Read path credentials.json",
      "Read path **/id_rsa",
      "Read path **/*.pem"
    ]
  }
}

この設定を追加すると、ファイル検索結果と読み取り操作の両方から除外されます。
Claude Codeがうっかり .env を読むことはなくなります。

これが「今日やるべきこと」の1つ目です。
今すぐ .claude/settings.json を開いて追加してください。

パスパターンの書き方 — 4種類の指定方法

パスの指定方法は4種類あります。プロジェクトの構成に合わせて使い分けてください。

パターン	意味	例
`//path`	ファイルシステムのルートから	`//etc/passwd`
`~/path`	ホームディレクトリから	`~/.ssh/id_rsa`
`/path`	プロジェクトルートから	`/config/secrets.yml`
`path` or `./path`	カレントディレクトリから	`.env`, `./secrets/**`

迷ったら ./path で書くのが安全です。

「.claudeignore」は存在しない — よくある誤解をファクトチェック

.gitignore のように .claudeignore ファイルを作れば除外できる、という情報がネット上で広まっています。

しかし、.claudeignore はClaude Codeの公式機能として実装されたことがありません。

この誤解が広まった背景を整理します。

過去のAnthropic公式ドキュメント（トラブルシューティングページ）に .claudeignore という文言が一時的に記載されていた。
しかしこれはドキュメント上の誤りであり、その後削除された
Anthropicが実際に実装したのは ignorePatterns というJSON設定。
ただし、これも現在は非推奨
現行の公式な方法は permissions.deny

GitHubのclaude-codeリポジトリにはissue #79、#579 等で .claudeignore の実装要望が投稿されていますが、Anthropicの公式回答は一貫して permissions.deny を推奨しています。

「.claudeignoreを作ったのに効かない」と悩んでいる方は、この記事の permissions.deny 設定に切り替えてください。

サンドボックスとネットワーク制限 — OSレベルの隔離で「最悪のケース」を防ぐ

macOS / Linux / WSL2 で動くサンドボックスの仕組み

Claude CodeはOSレベルのサンドボックスを備えています。

OS	サンドボックス技術	備考
macOS	Seatbelt	macOS標準のサンドボックス機構
Linux	bubblewrap	コンテナ技術ベースの隔離
WSL2	bubblewrap	Linuxと同じ
WSL1	非対応	カーネル機能不足のため

ファイルシステムの隔離ルールはこうなっています。

graph TB
    subgraph W["書き込み可能"]
        CWD["起動ディレクトリ（CWD）\nとそのサブディレクトリ"]
    end
    subgraph R["読み取りのみ"]
        HOME["ホームディレクトリ"]
        SYS["システムファイル"]
    end
    subgraph N["アクセス不可"]
        SSH["~/.ssh"]
        GNUPG["~/.gnupg"]
    end

    style W fill:#e8f5e9,stroke:#4caf50
    style R fill:#fff3e0,stroke:#ff9800
    style N fill:#ffebee,stroke:#e91e63

つまり、プロジェクトフォルダの外にある ~/.bashrc や /bin/ などのシステムファイルは、デフォルトでは書き換えられない仕組みです。

プロンプトインジェクションが成功しても、サンドボックスがダメージを限定する

プロンプトインジェクションとは、AIへの不正な指示の埋め込みです。外部から取得したファイルやWebページに悪意のある指示が含まれていた場合、AIがその指示に従ってしまうリスクがあります。

しかし、サンドボックスのおかげで、たとえインジェクションが成功しても以下の操作は防がれます。

~/.bashrc 等の重要な設定ファイルの変更
/bin/ 等のシステムレベルファイルの変更
未承認ドメインへのデータ送信
許可されていないドメインからのスクリプトのダウンロード

これがサンドボックスの本質的な価値です。「最悪のケースの被害範囲」を物理的に限定する最後の砦として機能します。

ネットワークアクセスをドメイン単位で制限する

サンドボックスはファイルシステムだけでなく、ネットワークアクセスも制御できます。settings.json に allowedDomains を設定し、接続先をホワイトリストで限定します。

{
  "allowedDomains": [
    "github.com",
    "registry.npmjs.org",
    "api.anthropic.com"
  ]
}

新しいドメインへのアクセスが発生した場合はパーミッションプロンプトが表示されます。さらに厳格な制御が必要な場合は、後述する「マネージド設定」で allowManagedDomainsOnly を有効にできます（この設定はマネージド設定専用です）。

注意点として、ドメインフィルタリングはトラフィック内容の検査は行いません。あくまで接続先の制御です。また、curl / wget はデフォルトでコマンドブロックリストに含まれていますが、ユーザーが明示的に許可した場合は任意のURLにアクセス可能になります。ネットワーク系コマンドを許可する場合は、ドメイン制限との併用を検討してください。

Hooks — 標準設定では足りない場面に、カスタムガードレールを設ける

PreToolUse / PostToolUse / ConfigChange — ツール実行前後にチェックを挟む

Hooksとは、Claude Codeのライフサイクルの特定のタイミングで、カスタムのチェック処理を差し込む仕組みです。

sequenceDiagram
    participant U as ユーザー
    participant C as Claude Code
    participant H as Hooks
    participant T as ツール

    U->>C: 指示を入力
    C->>H: PreToolUse（実行前チェック）
    alt ブロック
        H-->>C: 終了コード 2（操作中止）
    else 許可
        H-->>C: 終了コード 0（続行）
        C->>T: ツール実行
        T-->>C: 結果
        C->>H: PostToolUse（実行後チェック）
    end
    C-->>U: 結果を表示

セキュリティ観点で重要なフックイベントは3つです。

イベント	発火タイミング	主な用途
PreToolUse	ツール実行前	危険な操作のブロック
PostToolUse	ツール正常実行後	出力の検証やリント
ConfigChange	設定変更時	設定変更の監査やブロック

具体例 — `rm -rf` を自動ブロックするフックスクリプト

rm -rf のような破壊的コマンドを自動ブロックするPreToolUseフックの例です。

#!/bin/bash
# .claude/hooks/block-dangerous-commands.sh

COMMAND=$(jq -r '.tool_input.command // empty')

if echo "$COMMAND" | grep -qE 'rm\s+(-rf|-fr)\s+/'; then
  echo "BLOCKED: 危険なrmコマンドを検出しました"
  exit 2
fi

exit 0

フックスクリプトはstdinからJSON入力を受け取り、jq でパースします。終了コードの意味は以下の通りです。

終了コード	意味	動作
0	成功	処理続行
2	ブロッキングエラー	操作中止
その他	非ブロッキングエラー	警告のみ表示

フックスナップショット — セッション中の改ざんを防ぐ仕組み

セキュリティ上重要な設計として、フックはセッション起動時にスナップショットが取得されます。

セッション中にフックスクリプトが改ざんされても、スナップショット時点の内容が適用されます。つまり、実行中のセッションには影響しません。変更後のフックを反映するには /hooks メニューでの明示的なレビューが必要です。

これにより「フックを書き換えて防御を無効化する」という攻撃パターンが防止されています。

プロンプトインジェクション対策 — Claude Codeに組み込まれた4つの防御機構

Claude Code側の保護機構

プロンプトインジェクションに対して、Claude Codeには以下の4つの防御が組み込まれています。

入力サニタイゼーション：ユーザー入力を処理してコマンドインジェクションを防止
コマンドブロックリスト：curl / wget のようにWebから任意のコンテンツを取得できるコマンドをデフォルトでブロック。実行時に許可が求められる
分離されたコンテキストウィンドウ：WebFetch機能はメインのコンテキストとは別のウィンドウで処理される。取得したWebページに悪意のある指示が含まれていても、直接影響しにくい設計
不審なコマンドの検出：Bashコマンドが事前に許可リストに登録されていても、不審なパターンが検出された場合は手動承認を要求する

ユーザー側で心がけるべき4つのこと

Claude Code側の防御機構は強力ですが、ユーザー側の注意も必要です。以下の4つは習慣として身につけてください。

信頼できないコンテンツをパイプしない：外部から取得したデータをそのまま Claude Code に渡すのは避ける
コマンドの提案は承認前に確認する：Claude Codeが提案するBashコマンドは、実行前に必ず内容を確認する。特に curl、wget、rm などは要注意
外部Webサービスとやり取りする場合はVMを検討する：リスクの高い操作を行う場合は、仮想マシン内での実行がより安全
不審な動作は報告する：Claude Code内で /bug コマンドを使ってAnthropicに報告できる

MCP Serverとチーム運用 — 拡張と組織化のセキュリティ

MCP Serverは信頼できるものだけを使う

MCP Serverとは、Claude Codeに外部ツール（Slack連携、DB操作等）の機能を追加する仕組みです。

ここで押さえておくべき重要な事実があります。Anthropic社はMCPサーバーの管理・監査を行っていません。これは公式ドキュメントに明記されています。サードパーティが提供するものであり、品質やセキュリティはAnthropicが保証するものではないのです。

推奨される対応は、自前でMCPサーバーを構築するか、信頼できるプロバイダーのものを使用することです。パーミッションルールでMCPツール単位のアクセス制御も可能です。

{
  "permissions": {
    "deny": [
      "mcp__untrusted_server",
      "mcp__puppeteer__puppeteer_navigate"
    ]
  }
}

mcp__puppeteer（サーバー全体）や mcp__puppeteer__puppeteer_navigate（特定ツール）のように、粒度を変えてパターン指定できます。

チーム導入にはマネージド設定 — ユーザーが上書きできないポリシーを配信する

個人利用ならここまでの設定で十分です。しかし、チーム・組織で導入する場合は「メンバーが勝手に設定を変えてしまう」リスクがあります。

マネージド設定とは、組織管理者が配信する、ユーザーやプロジェクト設定で上書きできないセキュリティポリシーです。

配信方法：

方法	対象OS
MDM（モバイルデバイス管理）	macOS
レジストリ	Windows
ファイルベース	全OS

組織で特に有効な4つの設定：

設定名	効果
`disableBypassPermissionsMode`	`--dangerously-skip-permissions` を含むバイパスモード自体を無効化
`allowManagedPermissionRulesOnly`	ユーザーが独自のパーミッションルールを追加できないようにする
`allowManagedHooksOnly`	マネージドフックのみ有効にする
`allowManagedMcpServersOnly`	許可済みMCPサーバーのみ使用可能にする

これらを組み合わせれば、開発者の利便性を保ちつつ、組織のセキュリティポリシーを確実に適用できます。

まとめ：まずやるべき3つのこと

多層防御の全体像

ここまで解説してきた通り、Claude Codeはパーミッション × サンドボックス × ネットワーク制限 × Hooksの4層構造で多層的に守られています。1つの層が突破されても、次の層で止める。これが「多層防御」の考え方です。

今日からできる3つのアクション

1. permissions.deny に機密ファイルを追加する

.env や認証情報ファイルをdenyルールに入れてください。この記事の設定例をコピペすれば5分で完了します。

2. パーミッションモードを確認する

Claude Code内で /permissions を実行して現状を把握してください。defaultモードになっているか、意図しないallowルールが入っていないかをチェックします。

3. コマンド承認をレビューする習慣をつける

Claude Codeが提案するBashコマンドは、実行前に必ず内容を確認してください。特にネットワーク系コマンド（curl、wget）やファイル削除系コマンド（rm）は注意が必要です。

「信頼しつつ、検証する」がベストプラクティス

Claude Codeはデフォルトの状態でも安全に設計されています。しかし、仕組みを正しく理解し、プロジェクトに合った設定を施すことで、安心感は大きく変わります。

「Trust, but verify（信頼しつつ、検証する）」——これがAIコーディングエージェントと付き合う上でのベストプラクティスです。

セキュリティ脆弱性を発見した場合は、Anthropicの HackerOne プログラム経由で報告できます。

Claude Codeのチーム導入・セキュリティ設定のご相談は、お気軽にアディエムまでお問い合わせください。

参照元（公式ドキュメント）

株式会社アディエム
東京都中央区日本橋室町1丁目11番12号　日本橋水野ビル7階
tel : 050-3629-1986

PAGE TOP