Claude Codeのセキュリティと使用上の注意！流出・破壊・ライセンスを守る設定チェックリスト

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

Claude Codeの不安は設定で線引きできる

Claude Code を使うときの不安は、突き詰めると「勝手に何でも実行されるのではないか」という一点に集約されます。ファイルを消されるのが怖い、APIキーや顧客のコードが外に漏れるのが怖い、受託案件のコードが学習に使われるのか分からない——この漠然とした怖さは、すべて「どこまでを自動で許可し、どこから先は人が確認するか」という権限の線引きの問題に置き換えられます。

そして線引きは、感覚ではなく設定で再現できます。Claude Code は権限ベースのアーキテクチャを採用していて、デフォルトでは読み取り専用、編集やコマンド実行には明示的な承認が要ります(公式ドキュメント code.claude.com/docs/en/security)。つまり「危ないことが勝手に起きる」前提ではなく、「許可した範囲しか動かない」前提から出発できるのです。

この記事では、読者の不安を破壊・流出・ライセンスの3軸に分け、それぞれを止めるための設定を順に並べます。全部を完璧にやる必要はありません。個人で受託をしている方なら、まずは顧客コードの分離・学習設定のオプトアウト・本体の最新版更新の3つだけでも実害はかなり防げます。総花的に身構えるより、効く設定から手をつけるのが近道です。

破壊的操作を止める権限と承認の設定

いちばん visceral な不安は、AI が rm のような破壊的コマンドを無確認で走らせてしまうことでしょう。ここを最初に潰しておくと、残りの不安にも落ち着いて向き合えます。

Claude Code の権限の実像はシンプルです。デフォルトは読み取り専用で、ファイルの編集やコマンドの実行には承認が必要です。書き込みできる範囲も、起動したフォルダとその配下に限定されています。つまり「何が起きるかは、自分が承認した範囲がすべて」という状態が出発点になっています。

このセクションでは、その権限の実像を3つの切り口で具体化します。まずデフォルトでどこまで自動で動くのかを確かめ、次に settings.json の許可・拒否リストで安全境界を自分の手で引き、最後に実行前の計画確認・隔離実行・機械的なブロックという3段のガードを重ねます。順に設定していけば、破壊的操作は「うっかり起きる」ものではなく「自分が明示的に許可しない限り起きない」ものに変わります。

①デフォルトの権限と承認の実像

Claude Code は起動直後、読み取り専用で動きます。ls や cat、git status のような副作用のない読み取り系コマンドは確認なしで実行されますが、ファイルの編集や副作用のあるコマンドはそのつど承認を求めてきます。承認は「今回だけ許可」か「以後は自動で許可」を選べます。

書き込みできる範囲にも境界があります。Claude Code が書き換えられるのは、起動したフォルダとその配下だけです。親ディレクトリは明示的に許可しない限り変更できません(読むだけなら作業フォルダの外も可能です)。プロジェクトのルートで起動しておけば、それより外を勝手に壊される心配はまずありません。

注意したいのは Accept Edits モードです。これを有効にすると、ファイルの編集と、作業ディレクトリ内のパスに対する一部の決まったコマンド——mkdir / touch / rm / mv / cp / sed ——が自動承認されます。rm がこの中に含まれる点は知っておくべきで、便利さと引き換えに削除が無確認で通るようになります。それ以外の Bash コマンドや作業範囲外のパスは、このモードでも引き続き承認を求められます。重要な案件では Accept Edits を常用せず、効かせる場面を選ぶのが安全です。

②settings.jsonの許可と拒否リスト

承認を毎回手で押すのは現実的でないので、安全なコマンドはあらかじめ許可し、危険なコマンドは明確に拒否しておきます。これを担うのが settings.json の permissions です。allow に書いたパターンは自動承認され、deny に書いたパターンはブロックされます。

たとえば、よく使う読み取り系やビルド系を許可しつつ、破壊的な削除を拒否する書き方は次のようになります。

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force *)"
    ]
  }
}

この設定の効きどころは、マッチングが fail-closed であることです。allow にも deny にもマッチしなかったコマンドは、自動で通るのではなく手動承認に落ちます。つまりリストの作り込みが甘くても、想定外のコマンドが黙って実行されることはありません。さらに、許可済みのコマンドであっても、注入の疑いがある不審な Bash は手動承認が要求されます。「許可リストは攻め、拒否リストは守り、マッチしなければ必ず人に聞く」と覚えておくと設計しやすいです。設定はユーザー単位・コードベース単位・組織単位で持てるので、案件ごとに分けて管理できます。

③Plan Mode・サンドボックス・hooks

許可・拒否リストの上に、さらに3段のガードを重ねられます。

1つめは Plan Mode です。実際に手を動かす前に「何をどう変更するか」の計画を提示させ、内容を確認してから実行に移れます。破壊的な変更を含む作業ほど、まず計画を読んでから承認する流れが効きます。Plan Mode の具体的な操作や slash コマンドの使い分けは別記事で詳しく扱っているので、ここでは「実行前に立ち止まる仕組み」という位置づけにとどめます。

2つめはサンドボックスです。/sandbox でファイルシステムとネットワークを隔離した状態でコマンドを実行できます。試したいが手元の環境を汚したくないとき、隔離した箱の中で動かして影響範囲を閉じ込められます。

3つめは hooks です。PreToolUse の deny フックを使うと、特定のツール実行を機械的にブロックできます。許可リストの「人が承認するかどうか」とは別に、「そもそも実行させない」という固い壁を作れるのが利点です。hooks の実装パターンは別記事のレシピが参考になります。Plan Mode で立ち止まり、サンドボックスで閉じ込め、hooks で固く止める——この3段で破壊的操作はかなり制御できます。

秘密情報の流出を防ぐ設定

次の不安は流出です。.env や APIキー、顧客から預かったコードが、知らないうちに外へ送られないか——ここは「これだけやれば漏れにくい」と言える最低限の手順に落とせます。

流出を防ぐ発想は3つです。まず、秘密をそもそもリポジトリやコンテキストに混ぜないこと。.gitignore で鍵ファイルを除外し、秘密は環境変数で渡し、資格情報はOSの安全な保管先に置きます。次に、外へ出ていく経路を絞ること。外部送信に使われがちなコマンドはデフォルトで自動承認されないので、その性質を活かして経路を塞ぎます。最後に、設定の書き換えや信頼できない拡張という運用面の穴を埋めること。

このあと、基本三点セット・外部送信の制御・hooks と MCP の信頼確認の順に具体化します。すべて設定として再現でき、一度整えれば案件ごとに使い回せます。

①.gitignore・環境変数・資格情報保管

流出対策の土台は、秘密をコードと同じ場所に置かないことです。基本の三点セットを押さえます。

1つめは .gitignore です。.env や各種の鍵ファイル、認証情報を含むファイルは必ず除外し、コミット対象から外します。除外し忘れると、AI うんぬん以前に Git の履歴へ秘密が残り続けてしまいます。

.env
.env.local
*.pem
*.key
credentials.json

2つめは環境変数です。APIキーやトークンはコードに直書きせず、環境変数として渡します。こうしておけば、ソースを共有しても鍵そのものは出ていきません。

3つめは資格情報の保管です。Claude Code は自身のログイン資格情報を安全に保管します。macOS では Keychain を使い、Windows と Linux ではファイル権限で保護します。ここはツール側が面倒を見てくれる部分なので、利用者としては「平文のメモやコードに鍵を貼らない」を徹底するのが役割分担になります。この三点を守るだけで、うっかり漏れの大半は塞げます。

②外部送信とネットワークの制御

秘密を置かない次は、外へ出ていく経路を絞ります。

幸い、外部送信に使われやすい curl や wget はデフォルトで自動承認されません。実行のたびに承認を求められるので、意図しない送信に気づけます。この性質を固くするには、permissions.deny で明示的にブロックしてしまうのが確実です。

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

逆に特定の社内エンドポイントだけ許したい場合は、allow に限定したパターンを足して、それ以外は承認・拒否に落とします。Web の取得についても、Claude Code は隔離されたコンテキストで処理し、取得した内容がそのまま実行系へ流れ込まないよう配慮されています。

運用面で効くのは「信頼できない内容をそのままパイプで流さない」という習慣です。出所の怪しいファイルやWebページをAIに丸ごと食わせると、その中に紛れた指示につられて余計な送信をしてしまう余地が生まれます。外部から取り込んだものは中身を確認してから渡す、と決めておくと経路はかなり堅くなります。

③hooksとMCPの信頼確認

最後は運用面の穴を埋めます。せっかく許可・拒否リストを整えても、設定そのものをセッション中に書き換えられたら台無しです。ここで効くのが ConfigChange フックで、設定変更を監査したり、望ましくない変更をブロックしたりできます。チームなら設定をバージョン管理で共有しておくと、誰かが勝手にゆるめた変更も差分で追えます。

もうひとつ省略してはいけないのが信頼確認です。Claude Code は、初めて開くコードベースや新しく追加する MCP サーバに対して信頼確認を求めます。これは面倒に感じても飛ばさないのが安全で、非対話実行のフラグ(-p)を使うとこの確認が無効になる点も知っておくべきです。自動化スクリプトでうっかり確認を飛ばさないよう注意します。

MCP サーバについては特に慎重に。Anthropic はディレクトリ掲載の基準でコネクタを審査しますが、MCP サーバそのもののセキュリティ監査はしません。つまり「公式に並んでいる=安全」ではないということです。自分で書いたものか、出所と中身を信頼できるものだけを使うのが原則です。hooks や MCP の組み立て方は別記事のレシピが参考になります。

受託・商用コードを守る学習対策

3つめの不安はライセンスとデータの扱いです。受託で預かったコードが学習に使われたり、別の案件に流用されたりしないか。そもそも商用で使ってよいのか。ここはプラン別の事実を押さえれば、判断の枠組みがはっきりします。

先に結論の方向性だけ言うと、「どのプランで使っているか」で扱いが大きく変わります。商用向けのプランと、個人向けの消費者プランでは、データが学習に使われるかどうかの前提が違います。この違いを知らないまま消費者プランで顧客コードを扱うと、意図せず学習対象になっている、という事態が起こり得ます。

このあと、プラン別の学習の違いと、学習設定をオフにするオプトアウトや商用での備えを順に見ます。なお、契約や機密保持の具体的な線引きは案件ごと・顧客ごとに異なります。この記事はツール側のデータ方針と運用指針までを扱い、契約文言の是非までは踏み込みません。最終的には顧客の規約や NDA を確認するのが前提だと考えてください。

①プラン別のデータ学習の違い

学習に使われるかどうかは、プランの種類で線が引かれています。

商用向けのプラン——API、Team、Enterprise、そしてクラウド経由の Bedrock や Vertex——では、あなたのデータがモデルの学習に使われることはありません。受託や業務で顧客コードを扱うなら、まずこちら側にいるかどうかが分かれ目になります。

一方、個人向けの消費者プラン(Free / Pro / Max)は事情が異なります。これらのアカウント経由で使う Claude Code を含め、「You can help improve Claude(Claude の改善に協力する)」という学習設定がオンのときに限って、データが学習に使われる可能性があります。逆に言えば、設定がオフなら学習には使われません。サインアップ時にどちらかを選び、あとから Privacy Settings でいつでも変更できます。

判断の枠組みはこうです。商用プランなら学習の心配は基本的に不要。消費者プランなら、学習設定がオンかオフかを必ず確認する。保持期間など具体的な数値はこのあとの整理セクションにまとめているので、まずは「自分がどちら側にいて、設定はどうなっているか」を押さえてください。

②学習オプトアウトと商用での備え

では、消費者プランで使う場合にどう備えるか。具体的な動きは3つです。

1つめは学習設定のオプトアウトです。Privacy Settings を開き、「You can help improve Claude」をオフにします。これで以後のデータは学習に使われなくなります。受託や機密性の高い案件を消費者プランで触る前に、ここを必ず確認してください。設定はあとから変えられますが、「気づいたときにはオンのまま使っていた」が一番避けたい状態です。

2つめは、そもそも商用プランへ逃がす選択です。学習に使われない前提が要件になる案件では、API や Team などの商用プランで作業するほうが説明もしやすく、設定の取り違えリスクも減ります。顧客に「学習には使われません」と言い切れる根拠を持てるのは大きな安心材料です。

3つめは顧客との事前合意です。どのプランでどう扱うかを、案件開始前にすり合わせておきます。契約や機密保持の細かな線引きは案件ごとに違うので、この記事で一律の正解は示せません。最終的には顧客の規約や NDA を確認し、必要なら明文化しておく——これが受託でコードを扱う側の現実的な守り方です。

公式の自動セキュリティレビュー機能

「Claude Code Security」という名前を、独立した製品やオプションだと思っている方が少なくありません。これは正確には、自動セキュリティレビューの機能を指します。別途契約する製品ではなく、いまの Claude Code に組み込まれた機能です。

中身は2つの入り口があります。1つはターミナルから使う /security-review で、まだコミットしていない変更に対してその場でセキュリティ解析をかけます。もう1つは Claude Code Security Review GitHub Action で、新しいプルリクエストをトリガーに走り、見つかった問題をPRへインラインコメントで投稿します。手元の確認と、チームのレビュー工程の自動化を分担できる構成です。

検査するのは主に5つのクラスです。SQLインジェクション、XSS(クロスサイトスクリプティング)、認証・認可の欠陥、安全でないデータ処理(入力の検証やサニタイズの不備)、そして依存関係の脆弱性です。利用できるのは Claude Code の有料プラン(Pro / Max)と、従量課金の API Console アカウントで、無料枠での明示的な提供はありません。

ここまで紹介してきた設定(権限・gitignore・hooks)が「危ないことをさせない」セルフ対策だとすれば、この機能は「書いたコード自体の脆弱性を見つける」攻めのチェックです。両者は役割が違うので、片方では代替できません。両輪で使うのが前提です。詳細は公式サポート記事 support.claude.com で確認できます。

プラン別データとインシデントの整理

ここからは、変わりやすい数字や事実をまとめて置いておきます。プラン構成や保持期間、修正バージョンは更新されることがあるため、最新は必ず公式で確認してください。以下は2026年6月時点で確認できた内容です。

プラン別のデータの扱いは次の通りです。

自動セキュリティレビュー機能の利用可否は次の通りです。

最後に、2026年に話題になったインシデントの要点です。Claude Code の GitHub Action が、プロンプトインジェクション経由で CI/CD のシークレット(APIキー)を漏らしうると指摘されました。Bash ツールは隔離されていたものの、Read ツールが隔離されておらず、/proc/self/environ から環境変数を読めてしまったのが原因です。これは Claude Code 2.1.128(2026年5月5日)で修正され、Read ツールが該当する /proc 配下のファイルを無条件で拒否するようになりました。

この事例から実務的に引き出せる教訓は2つです。ひとつは本体を最新版に保つこと。もうひとつは、信頼できない入力・秘密情報へのアクセス・外部通信の3つを同じワークフローに同居させないこと(Microsoft はこれを「Agents Rule of Two」と呼んでいます)。煽る話ではなく、なぜ最新版更新と入力の隔離が要るのかの具体的な根拠として押さえておけば十分です。

個人と法人で見る優先設定

ここまでの設定を、立場別に「まずこれだけ」へ並べ直します。全部を一度にやる必要はありません。

個人で受託をしている方の最低限は3つです。

法人で導入する場合は、上記に加えて組織として効かせる設定が要ります。

個人は「自分の手元で漏らさない・壊さない」を最優先、法人は「組織として統制し、監査できる」を足す——この優先順位で進めれば、総花的に身構えずに済みます。

Claude Codeセキュリティのよくある質問

Claude Code安全設定のまとめ

Claude Code の不安は、破壊・流出・ライセンスの3軸に分けて設定で線引きすれば、漠然とした怖さではなくなります。要点を振り返ります。

最初の一歩として、個人で受託をしている方は、案件フォルダを分けて顧客コードを隔離する・学習設定を確認する・本体を最新版に更新する、の3つから始めてください。これだけでも実害の多くは防げます。そして「最新版に保つ」を習慣にすること。修正は新しいバージョンで入るので、更新の後回しが最大の穴になりがちです。完璧を目指すより、効く設定を今日いくつか有効にするところから動いていきましょう。