AIセキュリティ

Claude Codeのセキュリティを徹底解説!安全に使う設定と企業運用も紹介

中島大介(なかじ)読了時間 約17分
Claude Codeのセキュリティ解説のアイキャッチバナー

Claude Codeは、AIがファイルの書き換えやコマンドの実行まで進めるツールです。それだけに、社内のコードや顧客情報が入ったパソコンで動かす前には、何がどこまで守られるのかの確認が欠かせません。一方で、世の中の解説はエンジニア向けの設定羅列が中心で、何から手を付けるべきかの全体像がつかみにくい状態です。

この記事では、Claude Codeに標準で組み込まれている保護の仕組みと安全性を高める設定を、公式ドキュメントに基づいて解説します。企業・チームで運用するための管理機能も扱う内容です。読み終えるころには、自分の環境で何を決めて何を設定すべきかを判断できます。結論から言うと、Claude Codeは標準で読み取り専用で動く設計になっており、権限設定とサンドボックスを組み合わせれば会社利用に耐える構成が可能です。

Claude Codeのセキュリティの仕組み【標準で入っている保護】

Claude Codeに標準で入っている3つの保護を示す図解

Claude Codeに最初から組み込まれている保護は以下のとおりです。

  • 標準では読み取り専用で動作する
  • 作業フォルダの外には書き込めない
  • 危険な操作の前には確認が入る

標準では読み取り専用で動作する

Claude Codeのデフォルトは、厳格な読み取り専用として動きます。ファイルの編集・テストの実行・コマンドの実行といった変更を伴う操作には、その都度ユーザーの明示的な許可が求められます。AIが勝手にファイルを書き換えて作業が進んでしまう設計ではないのです。

許可の与え方は「1回だけ承認」と「以後は自動で許可」の2択です。慣れないうちはすべて1回ずつ承認し、信頼できる操作だけを自動化していきましょう。

作業フォルダの外には書き込めない

Claude Codeが書き込めるのは、起動したフォルダとその中のサブフォルダだけです。親フォルダや別の場所にあるファイルは、明示的に許可しない限り変更できません。プロジェクトの外にある家計簿や他案件のファイルまで触られる心配を、仕組みの面から抑えています。

フォルダの外の読み取りにも、承認プロンプトが挟まる仕組みです。複数のフォルダをまたいで作業したい場合だけ、追加ディレクトリとして明示的に範囲を広げます。

危険な操作の前には確認が入る

システムを変更しうるコマンドの実行前には承認が必須です。lsやcat、git statusのような、公式が読み取り専用と定義した一部のコマンドだけが確認なしで動きます。

インターネットへアクセスするcurlやwgetといったコマンドも、デフォルトでは自動承認されません。外部との通信が発生する操作は、人間の目を通す設計です。

Claude Codeのセキュリティ設定の基本【permissions】

権限ルールallow・ask・denyの違いと評価順を示す図解

標準の保護に加えて自分で決めるルールは以下のとおりです。

  • allow・ask・denyの3種類のルールで制御する
  • settings.jsonでチーム共通の設定を共有する
  • 権限モードは作業内容に合わせて選ぶ

allow・ask・denyの3種類のルールで制御する

Claude Codeの権限ルールは3種類です。確認なしで許可するallow、毎回確認するask、禁止するdenyがあります。現在のルールの確認と管理は、セッション内の/permissionsコマンドで可能です。

ルールはdeny→ask→allowの順に評価され、最初に一致したものが適用されます。「Bash(npm run *)は許可」「Bash(git push *)は禁止」のように、コマンド単位・ファイル単位で細かく指定できる仕組みです。触られたくない操作をdenyで先に塞ぐのが設計の基本になります。

settings.jsonでチーム共通の設定を共有する

権限ルールはsettings.jsonファイルに書いて保存できます。プロジェクトの設定ファイルはバージョン管理に含められるため、チーム全員へ同じルールを配布する用途に向いた仕組みです。

公式ドキュメントの例では、「npm run系とgit commit系は許可、git pushは禁止」のような形でプロジェクトの実情に合わせたルールを定義しています。個人が対話中に永続承認した内容は、プロジェクト内の.claude/settings.local.jsonに保存される仕組みです。

権限モードは作業内容に合わせて選ぶ

権限の確認頻度は、モードとしてまとめて切り替えられます。標準のdefaultは初回使用時に確認、acceptEditsは作業フォルダ内のファイル編集を自動承認、planは編集せず計画の提案だけを行うモードです。現行はこのほかに、指示との整合を自動チェックしながら承認を自動化するautoと、事前に許可した操作以外を自動で拒否するdontAskも用意されています。

原則すべての確認を省略するbypassPermissionsモードも存在しますが、公式ドキュメントは「損害を与えられない隔離環境でのみ使用すること」と警告しています。日常の作業で安易に使うモードではないのです。組織では、bypassPermissionsの禁止(disableBypassPermissionsMode)に加え、autoモードの禁止(disableAutoMode)も設定で強制できます。

サンドボックスで実行環境ごと隔離する

権限ルールとサンドボックスによる多層防御を示す図解

権限ルールの外側に、もう1段の防壁を作る機能があります。

  • サンドボックスはOSの仕組みでファイルとネットワークを制限する
  • /sandboxコマンドで有効化できる
  • 権限設定との併用で多層防御になる

サンドボックスはOSの仕組みでファイルとネットワークを制限する

サンドボックスは、コマンドが触れられるファイルと通信先をOSレベルで強制的に制限する機能です。有効にすると、コマンドの書き込み先は作業フォルダとセッション用の一時フォルダに限定されます。通信先のドメインも事前許可制で、新しい接続先が必要になった時点で承認プロンプトが出る仕組みです。

注意したいのは、読み取りが標準では広く許可される点です。公式ドキュメントは、サンドボックスを有効にしても既定では~/.sshや~/.awsといった認証情報ファイルが読める状態だと明示しています。読み取り遮断の設定に加え、認証情報を自動で守る専用の仕組み(sandbox.credentialsのdeny/mask)も用意されています。対応環境はmacOS・Linux・WSL2です。

/sandboxコマンドで有効化できる

サンドボックスはClaude Codeに組み込まれており、セッション内で/sandboxコマンドを実行して有効化できます。選んだモードは、チーム共有されない個人用のローカル設定ファイル(.claude/settings.local.json)に保存されます。全プロジェクトで常に有効にしたい場合の指定先は、ユーザー設定のsandbox.enabledです。

自動許可モードを選ぶと、サンドボックス内で完結するコマンドは確認なしで実行されます。安全の枠を先に固めることで、確認の手間を減らしながら使える運用です。

権限設定との併用で多層防御になる

権限ルールとサンドボックスは役割が異なります。権限ルールは実行前にClaude Codeが判断する仕組みで、サンドボックスは実行中のプロセスをOSが強制的に制限する仕組みです。

公式ドキュメントは両方を併用する多層防御を推奨しています。仮にAIの判断が攻撃的な指示にだまされても、サンドボックスの境界が越えられなければ実害へ届きにくくなるためです。同時に、サンドボックスも完全な隔離境界ではないと公式に明記されており、過信は禁物です。

もう1つ、サンドボックスが覆う範囲も押さえておきましょう。公式ドキュメントによると、組み込みのサンドボックスが隔離するのはBashコマンドの実行だけで、外部接続のMCPサーバーやhooksはその外側で動きます。信頼できないリポジトリを扱う場合は、仮想マシンやクラウド実行(Claude Code on the web)といった、環境ごと分ける選択肢が公式に推奨されています。

機密情報を守る設定と運用

機密情報を守るための設定と運用の確認項目を示す図解

情報漏洩への備えとして押さえる点は以下のとおりです。

  • 認証情報ファイルは読み取り自体を遮断する
  • 学習への利用とデータ保持の扱いを確認する
  • プロンプトインジェクションへの保護と自衛策を知る

認証情報ファイルは読み取り自体を遮断する

APIキーやSSH鍵などの認証情報は、AIに読ませない設定が基本です。Readのdenyルールで.envや鍵ファイルを指定すれば、Claude Codeの組み込みツールからの読み取りを禁止できます。

注意点として、denyルールが効くのは組み込みのファイルツールと主要なファイル系コマンドまでです。ファイルを間接的に開く自作スクリプトなどには適用されないため、全プロセスに対する強制にはサンドボックスの有効化が必要と公式ドキュメントに明記されています。2段構えで塞ぐのが確実です。

学習への利用とデータ保持の扱いを確認する

TeamやEnterpriseプラン、APIといった商用契約では、送信したコードやプロンプトはAIモデルの学習に使用されないと公式に定められています。個人向けのFree・Pro・Maxプランでは、学習への利用を許可するかを自分の設定で選ぶ方式です。

データの保持期間は、商用契約で標準30日間です。個人プランは学習利用を許可した場合5年間、許可しない場合30日間と案内されています。より厳しい要件がある組織向けには、送信データを応答後に保持しないZero Data Retention(ZDR)の仕組みも用意済みです。公式によると、ZDRは適格なアカウント向けにアカウントチーム経由で有効化されます。

もう1つ、見落としやすいのが手元のパソコン側です。公式ドキュメントによると、セッションの履歴は~/.claude/projects/に平文で保存され、既定の保持期間は30日です(cleanupPeriodDaysで調整可)。共有のパソコンで使う場合は、この点も含めて扱いを決めておきましょう。会社利用では商用プランを選び、設定と契約の両面でデータの扱いを確認しておくと説明責任を果たせます。

プロンプトインジェクションへの保護と自衛策を知る

プロンプトインジェクションは、Webページやファイルに仕込まれた指示でAIを操ろうとする攻撃です。Claude Codeには、権限システムによる承認・リクエスト全体の文脈分析・コマンドインジェクションを防ぐ入力の無害化・ネットワーク系コマンドの承認必須化といった保護が組み込まれています。初めて扱うコードベースや新しいMCPサーバーには信頼確認(trust verification)が入り、Webから取得した内容を隔離された文脈で処理する仕組みも実装済みです。

なお、外部ツールとつなぐMCPサーバーは便利な半面、接続先しだいでリスクにもなります。公式ドキュメントは、信頼できる提供元のサーバーだけを使うよう求めており、Anthropicが個々のMCPサーバーを監査しているわけではない点も明記しています。接続の追加は、機能と同じくらい慎重に判断してください。

公式が挙げる利用者側の自衛策は3つです。承認前にコマンドを確認すること・信頼できないコンテンツを直接渡さないこと・外部サービスとやり取りするスクリプトは仮想マシンで実行することです。保護は多層でもリスクはゼロにならない前提で設計されています。

企業・チームで安全に運用するための管理機能

組織で守りを強制する管理機能の流れを示す図解

組織導入で使う管理の仕組みは以下のとおりです。

  • managed settingsで組織のルールを強制する
  • サンドボックスの強制と抜け道の封鎖ができる
  • 利用の監視とコードレビュー体制を整える
  • 別機能のClaude Securityと混同しない

managed settingsで組織のルールを強制する

managed settingsは、管理者が配布する最上位の設定です。ユーザー個人やプロジェクトの設定では上書きできず、コマンドライン引数でも回避できません。

権限ルールを管理者配布のものだけに限定する設定や、接続を許可するMCPサーバー・通信先ドメインを組織の許可リストだけに絞る設定が用意されています。個人任せにせず、会社としての最低ラインを技術的に強制できる仕組みです。

サンドボックスの強制と抜け道の封鎖ができる

組織全体でサンドボックスを必須にする設定も公式に用意されています。依存パッケージが足りない環境では起動自体をブロックする指定や、サンドボックス外でのコマンド再実行の抜け道を無効化する指定を組み合わせる形です。

確認を全部飛ばすbypassPermissionsモードも、管理側の設定で禁止できます。守りの水準を人の注意力ではなく設定で担保する発想が、公式の推奨する運用です。

利用の監視とコードレビュー体制を整える

公式ドキュメントが挙げるチーム運用の施策は、組織標準の設定配布・承認済み権限設定のバージョン管理での共有・メンバーへの教育・OpenTelemetryによる利用状況の監視です。セッション中の設定変更を監査する仕組みも用意されています。

AIが書いたコードをそのまま本番に入れない運用ルールも必要です。公式は「Claude Codeはあなたが与えた権限のみを持ち、承認前のレビューはあなたの責任」と明記しています。AIが生成するコード自体の安全確認は、次の記事で扱っています。

Claude CodeのSecurity Guidanceとは|AI開発の事故を防ぐ実務対策

別機能のClaude Securityと混同しない

検索していると「Claude Security」という似た名前の情報も見つかりますが、これは本記事で扱ってきた安全設定とは別の機能です。公式ヘルプによると、Claude Securityはコードベースをスキャンして脆弱性を見つけ、修正案を提案する機能です。Enterpriseプラン向けのパブリックベータとして提供されています。

つまり、本記事の内容は「Claude Codeを安全に動かすための設定」、Claude Securityは「書かれたコードの弱点を探す検査機能」という関係です。名前が似ているため混同されがちですが、役割がまったく違う点を押さえておくと、情報収集で迷いません。

Claude Code導入前のセキュリティチェックリスト

導入前チェックリストを契約・設定・運用の順で示す図解

導入判断の前に確認する項目を7つにまとめました。

1. 契約プランとデータの扱いを確認する(商用契約は学習不使用・保持30日)

2. 触らせないファイルとコマンドを決めてdenyルールに落とす

3. 認証情報ファイル(~/.ssh、.envなど)の読み取り遮断を設定する

4. サンドボックスを有効化する(macOS・Linux・WSL2で利用可)

5. bypassPermissionsモードの扱いを決める(組織は禁止設定を推奨)

6. AIが書いたコードを人間がレビューする体制を決める

7. 利用状況の監視とメンバー教育の計画を立てる

上から順に、契約→設定→運用の順番で決めていくと漏れが出にくくなります。1〜5は導入前に一度整えれば済む項目で、6と7だけが継続的な運用項目です。

インストールや初期設定の手順そのものは、使い方の記事で解説しています。

Claude Codeの使い方入門!始め方から基本操作まで徹底解説

Claude Codeのセキュリティは標準の保護と設定の二段構えで固めましょう

標準の保護と自分で足す設定の二段構えをまとめた図解

Claude Codeには、読み取り専用のデフォルト・作業フォルダの境界・危険な操作前の確認の3つの保護が標準装備です。そのうえでallow・ask・denyの権限ルールとサンドボックスを設定すれば、判断の層とOSによる強制の層の多層防御になります。

会社で使う場合は、学習に使われない商用プランを選び、managed settingsで組織の最低ラインを強制する構成が公式の用意した道筋です。AIが書いたコードのレビュー体制まで含めて決めれば、導入判断に必要な材料は揃います。

まずは自分の環境でdenyルールとサンドボックスの2つを設定し、チェックリストの項目を上から順に埋めるところから始めましょう。

この記事の監修者

中島大介(なかじ)

中島大介(なかじ)

株式会社メリル 代表取締役 / 記事監修

株式会社メリル代表取締役。SEO歴20年以上。最新AIやセキュリティについて発信するYouTube「ウェブ職TV」は登録者15万人以上。著書「ChatGPT & Copilotの教科書」は10万部突破!

プロフィールを見る

関連する記事

生成AIの社内ルールの作り方を解説するアイキャッチバナー
AIセキュリティ

生成AIの社内ルールの作り方を徹底解説!盛り込む項目とひな形も紹介

生成AIの社内ルールを作りたい方は必見!この記事では、盛り込む項目と作り方の手順を公的資料に沿って解説します。実は、完璧な初版より小さく始める運用が近道です。記事を読めば、自社のルール策定に今日から着手できます。

中島大介(なかじ)監修 / Touch AI編集部15 分で読めます
AIに個人情報を入れてよいかを解説するアイキャッチバナー
AIセキュリティ

AIに個人情報を入れてよい?どこまで大丈夫かを個人情報保護法から解説

AIに個人情報を入れてよいか迷う方は必見!この記事では、入れてはいけない理由からどこまで大丈夫かの線引きまでを個人情報保護法に基づいて解説します。実は、判断の鍵は3つの確認です。読めば、根拠つきで自分で判断できます。

中島大介(なかじ)監修 / Touch AI編集部14 分で読めます
シャドーAIのリスクと対策を解説するアイキャッチバナー
AIセキュリティ

シャドーAIとは?リスクと対策を徹底解説!公認ルートの作り方も紹介

社員の無断AI利用が心配な方は必見!この記事では、シャドーAIのリスクと会社の対策、公認ルートの作り方を解説します。実は、一律禁止は利用を地下に潜らせるだけです。記事を読めば、防ぐ側も使う側も次の一手がわかります。

中島大介(なかじ)監修 / Touch AI編集部14 分で読めます

次のステップ

最新動向を学びに変える

話題のAIアップデートを、現役講師が背景と実務への影響まで解きほぐします。Touch AI の最新講座で、変化に追いつくための視点を得てください。

受講できる講座を見る