背景

この連載では、Claude Codeの公式ドキュメントを1ページずつ読み解いていきます。公式ドキュメントは情報が網羅されている分、「結局どの機能を、どんな場面で使えばいいのか」は自分で考える必要があり、読むのに意外と時間がかかります。そこで、私が実務で使うために読み込んだ内容を「使う場面→実例コード」の順に整理して残していくことにしました。専門家の解説というより、一次情報を読んだ記録です。推測や動作を確認していない部分には、その都度そう書きます。

1. これは一言でいうと何か

このページは、Claude Code が備えるセキュリティ対策と、安全に使うためのベストプラクティスをまとめたものです。個別機能の設定手順ではなく、保護の全体像と、その限界を示す回だと考えてください。

基本設計は「パーミッションベースのアーキテクチャ」です。Claude Code は既定で厳密な読み取り専用パーミッションで動き、ファイル編集・テスト実行・コマンド実行が必要になった時点で明示的に許可を求めます。ユーザーは1回だけ承認するか、自動的に許可するかを選べます。

そして、ページが明記している前提が1つあります。Claude Code はユーザーが付与したパーミッションしか持ちません。承認前に、提案されたコードとコマンドのセキュリティを確認する責任はユーザーにあります。

2. どういう場面で役立つか

• 機密リポジトリで作業を始めるとき：プロジェクト固有のパーミッション設定を使い、dev container での分離を検討し、/permissions で定期的に設定を監査する、という3点が挙げられています。
• 信頼できないコンテンツを扱うとき：外部 Web サービスと対話するようなケースでは、承認前にコマンドを確認し、信頼できないコンテンツを Claude に直接パイプすることを避け、重要ファイルへの変更を確認し、VM 上で実行することが推奨されています。
• チームに展開するとき：管理設定で組織標準を実施し、承認済みのパーミッション設定をバージョン管理で共有し、OpenTelemetry で使用を監視し、ConfigChange フックでセッション中の設定変更を監査またはブロックします。

注意が必要なケース。

1. Windows で WebDAV を有効にするのは推奨されていません。 \\* のような WebDAV サブディレクトリを含み得るパスへのアクセスを許可すると、Claude Code がリモートホストへのネットワークリクエストをトリガーし、パーミッションシステムをバイパスする可能性があるとされています（WebDAV は Microsoft によって非推奨）。
2. MCP サーバーは Anthropic の監査対象ではありません。 ディレクトリへの掲載前にリスティング基準に照らした確認は行われますが、セキュリティ監査や管理は行われないと明記されています。自作するか、信頼できるプロバイダーのものを使うことが推奨されています。
3. これらの保護をもって「完全」とは考えないでください。 ページ自身が「どのシステムもすべての攻撃に完全に免疫があるわけではない」と警告しています。

3. プロンプトインジェクション対策の実像（元ページにコード例はありません）

プロンプトインジェクションは、悪意あるテキストを挿入して AI アシスタントの指示を上書き・操作しようとする手法です。Claude Code の対策は多層で、性格の異なるものが並んでいます。

コアの保護

パーミッションシステム（機密操作には明示的承認が必要）、コンテキスト認識分析（完全なリクエストを分析して有害な指示を検出）、入力サニタイゼーション、そしてネットワークコマンド承認の4つです。

最後の1つは具体的で覚えておく価値があります。curl や wget のようにウェブからコンテンツを取得するコマンドは、既定では自動承認されません。 他の非読み取り専用 Bash コマンドと同じくプロンプトが出るので、1度承認するか Bash(curl *) のような許可ルールを足すことになります。完全に塞ぐなら permissions.deny です。

追加のセーフガード

注目に値するものを挙げます。

• 分離されたコンテキストウィンドウ：Web fetch は、悪意あるプロンプトの注入を避けるため別のコンテキストウィンドウを使います。取得した内容がそのまま本体の指示に混ざらない設計です。
• コマンドインジェクション検出：疑わしい Bash コマンドは、以前にホワイトリスト登録されていても手動承認を要求されます。
• フェイルクローズドマッチング：マッチしないコマンドは既定で手動承認になります。
• セキュアな認証情報ストレージ：API キーとトークンは、可能なら macOS Keychain に保存され、Windows と Linux ではファイルパーミッションで保護されます。
• 自然言語説明：複雑な Bash コマンドには理解のための説明が付きます。

信頼検証には2つの例外がある

初回のコードベース実行と新しい MCP サーバーには信頼検証が要求されます。ただし、ここに実務上重要な注記が2つあります。

ひとつ、-p フラグで非対話的に実行する場合、信頼検証は無効になります。 CI やスクリプトで回すときは、この保護が外れている前提で設計する必要があります。

ふたつ、ホームディレクトリで直接 Claude Code を起動すると、信頼受け入れは現在のセッションのみ保持され、ディスクに書き込まれません。 起動のたびにプロンプトが再表示され、これを永続化する設定は存在しません。回避策はプロジェクトのサブディレクトリから起動することです（そこではディレクトリごとに保存されます）。

作業ディレクトリの境界

Claude Code は起動されたフォルダとそのサブフォルダにのみ書き込め、明示的な権限なしに親ディレクトリのファイルは変更できません。一方読み取りは、承認プロンプトを経れば境界外も可能です。プロンプトを省きたいなら追加ディレクトリで境界を広げ、逆に読み取り専用 Bash コマンドから見える範囲を狭めたいなら、サンドボックスの denyRead ルールを使います（第17回で扱ったとおり、これはサンドボックス有効時のみ適用されます）。

4. まとめと次回予告

• 設計の中心はパーミッション。既定は読み取り専用で、それ以外は明示的な承認を経ます。
• プロンプトインジェクション対策は多層ですが、完全ではありません。承認前の確認責任はユーザー側にあります。
• MCP サーバーは Anthropic に監査されていません。信頼できる出所のものを選ぶのは利用者の仕事です。

実行場所によって保証が変わる点も押さえておいてください。 Claude Code on the web のクラウドセッションでは、各セッションが分離された Anthropic 管理 VM で動き、ネットワークアクセスは既定で制限され、git push は現在の作業ブランチに制限され、すべての操作が監査ログに記録され、セッション完了後に環境が自動終了します。

一方 Remote Control はまったく別物です。 Web インターフェースがローカルマシンで動く Claude Code プロセスに接続する形で、コード実行とファイルアクセスはすべてローカルに留まり、クラウド VM もサンドボックスも関与しません。 接続中はデバイス間同期のためセッショントランスクリプトが Anthropic サーバーに保存されます。接続には短命で狭くスコープされた複数の認証情報が使われ、1つが侵害された場合の影響範囲を限定する設計です。

脆弱性を見つけた場合は、公開で開示せず HackerOne プログラム経由で報告し、詳細な再現手順を添え、公開前に対処の時間を与えることが求められています。

次回予告：連載の締めくくりとして「ベストプラクティス」を取り上げる予定です。

関連ページ（本記事で触れた概念の詳細）：パーミッション設定 →「権限を設定する」、ファイルシステムとネットワーク分離 →「サンドボックス」、分離手段の比較 →「サンドボックス環境」、ConfigChange →「Hooks」、使用の追跡と監査 →「使用状況の監視」、分離環境 →「開発コンテナ」、Claude 自身に脆弱性をレビューさせる →「セキュリティガイダンスプラグイン」、認定とコンプライアンス →「Anthropic Trust Center」。

---

本記事は執筆時点の公式ドキュメント（セキュリティ）に基づきます。最新は公式ドキュメントをご確認ください。