Claude Codeを実務で安全に使うための設定と運用の整理
はじめに
Flutterエンジニアとして3年弱になります。
実務でも個人でもClaude Codeをメイン使いしています!
Claude Codeは非常に強力な開発支援ツールですが、その便利さゆえに意図せず機密情報を外部に送信してしまうリスクがあります。
この記事では、Claude Codeを実務で使う中で学んだセキュリティ対策について、具体的な設定例とともに解説します。
1. Claude Codeの動作と権限
ローカル完結ではない
Claude Codeはローカルで動作しているように見えますが、実際にはLLMとやり取りするためにネットワーク経由でデータを送信しています。
[あなたのPC] ──→ [Anthropicサーバー]
│ │
会話内容 推論処理
ファイル内容 ログ保持
会話に入った情報は、Anthropicのサーバーに送信され得ます。
アクセス手段は2系統
Claude Codeが情報にアクセスする手段は大きく2つあります。
| 手段 | 内容 | 例 |
|---|---|---|
| Claude Code専用ツール | ファイル読み取り・検索 | Read / Glob / Grep |
| Bash(シェル実行) | コマンド実行と結果取得 | git / cat / test実行 |
重要なのは、Bashの実行結果(ログ)も会話コンテキストに入るという点です。
権限制御(スコープ優先順位)
Claude Codeの権限は allow / ask / deny で制御できます。
| 設定 | 動作 | 使いどころ |
|---|---|---|
| allow | 確認なしで実行 | 安全な操作(git statusなど) |
| ask | 毎回確認ダイアログ | 影響が大きい操作(git pushなど) |
| deny | 絶対に実行しない | 危険な操作(機密ファイル読み取りなど) |
permissionsはスコープ(Managed / CLI / Local / Project / User)の優先順位で決まり、より高優先の設定が低優先の設定を上書きします。
例:ユーザー設定で allow でも、プロジェクト設定で deny ならブロックされます。
スコープ優先順位(高い順)
1. Managed(組織管理者が配布)
2. CLI(コマンドライン引数)
3. Local(.claude/settings.local.json)
4. Project(.claude/settings.json)
5. User(~/.claude/settings.json)
2. 学習(モデル改善)設定を確認する
セクション1で説明した通り、Claude Codeはデータを外部に送信します。では、送信されたデータはどう扱われるのか? これは契約タイプと設定によって異なります。
契約タイプによってデフォルト設定が異なる
| 契約タイプ | 対象 | 学習利用 | 設定変更 |
|---|---|---|---|
| Consumer | Claude Free / Pro / Max | デフォルトON(変更可) | 可能 |
| Commercial | Team / Enterprise / API | 原則OFF | 契約による |
Consumer(Free / Pro / Max)の場合
Claude.aiの個人アカウントでClaude Codeを使う場合、Model Improvement(モデル改善)設定がONになっていると、チャットやコーディングセッションがモデル改善に使われ得ます。
設定の確認・変更手順:
- claude.ai/settings/privacy にアクセス
- 「Improve Claude」または「Model Improvement」の項目を確認
- 必要に応じてOFFに変更
Commercial(Team / Enterprise / API)の場合
会社契約やAPI経由でClaude Codeを使う場合、原則として学習には使われません。ただし、詳細は契約内容によって異なるため、組織の管理者または契約内容を確認してください。
学習設定をOFFにしても残るリスク
学習設定をOFFにしても、以下のリスクは残ります:
- データはAnthropicのサーバーに送信される(推論のため)
- 一定期間ログとして保持される
- 信頼・安全(trust & safety)分類でフラグされた場合、長期保持の対象になり得る
つまり、学習OFFにしても「送信しない」わけではないので、機密情報の取り扱いには引き続き注意が必要です。
以降のセクションでは、「そもそも機密情報を送信しない」ための対策を解説します。
3. なぜAIに秘密情報を渡したらダメなのか
「どうせAIなんて確率的なプログラムでしょ?」と思いがちですが、エンジニアとして恐れるべきは 「AIが意思を持って悪用すること」ではなく、「データが管理外に流出する仕組みそのもの」です。
理由1:プロバイダーのサーバーにログとして残る
これが最も物理的な理由です。
- 送信した時点で、自社のセキュリティ管理下から離れる
- プロバイダーがハッキングされた場合、ログデータの一部として漏れるリスクがある
理由2:学習データとして取り込まれるリスク
契約プランによりますが、最も恐れられている事態です。
- 無料版や一部のサービスでは、会話内容が次世代モデルの学習データとして利用される
- AIがあなたの秘密鍵を「正解パターン」として学習してしまう可能性
- 他人への回答にあなたの秘密鍵がサンプルとして出力されるリスク
理由3:チャット履歴やキャッシュに残る
- 多くのAIツールは過去の会話履歴をクラウドに保存
- アカウント乗っ取りや「このチャットを共有」機能で秘密情報が丸見えになるリスク
APIキーやクラウドの認証情報が漏洩するとどうなるのか
APIキーやクラウドの認証情報が漏洩すると、以下のシナリオが起こり得ます。
1. .envやAWS認証情報をAIに渡す
↓
2. その情報がどこかで漏洩
↓
3. 攻撃者が認証情報を入手
↓
4. あなたのAWS/GCPアカウントで大量のリソースを起動
(仮想通貨マイニング用のGPUインスタンスを数百台など)
↓
5. 請求が数百万〜数千万円に
4. 実務で"やってしまいそうになる"具体例
以下は、どれも悪意なく、自然な流れでやってしまいそうな例です。
例1:Firebase環境構築をAIに任せる
「Firebaseの設定がうまくいかない。
google-services.jsonを見て原因を教えて」
→ APIキー・プロジェクトIDが会話に入る
google-services.json には Firebase の API キーやプロジェクト ID が含まれています。settings.json で Read を deny していても、自分で内容を貼り付けたら意味がありません。
例2:環境差分のデバッグ
「本番と開発で動作が違う。
.envの内容を比較して原因を教えて」
→ DB認証情報・APIシークレットが会話に入る
.env にはデータベースの接続情報や外部サービスのAPIキーが入っていることが多いです。「一回だけ」のつもりでも、会話に入った時点でAnthropicのサーバーに送信されます。
例3:ログをそのまま貼る
「ビルドが失敗した。このログを見て原因を教えて」
→ ログにAPIキーが含まれていることがある
特に --verbose オプション付きのビルドログや、環境変数を展開するコマンドの出力には、意図せずAPIキーが含まれていることがあります。
共通する問題
deny 設定は「Claude Code が自動で読む」ことは防げますが、自分で内容を貼り付けた場合は別の問題になります
settings.json での設定は「Claude Code が勝手に読む」のを防ぐものです。自分でコピペして会話に入れてしまったら、設定は無意味になります。
5. 今回実務で行った設定
settings.json の設定
.claude/settings.json に以下の設定を入れました。
{
"permissions": {
"allow": [
"Bash(fvm flutter *)",
"Bash(fvm dart *)",
"Bash(dart run build_runner *)",
"Bash(git status)",
"Bash(git diff)",
"Bash(git add *)",
"Bash(git commit *)",
"Bash(git log *)",
"Bash(git show *)",
"Bash(git branch *)",
"Bash(git checkout *)",
"Bash(git stash *)"
],
"ask": [
"Read(lib/firebase_options.dart)",
"Bash(git push *)",
"Bash(git clean *)"
],
"deny": [
"Read(.env*)",
"Read(**/.env*)",
"Read(android/key.properties)",
"Read(android/app/src/*/google-services.json)",
"Read(ios/Runner/GoogleService-Info.plist)",
"Read(**/*.keystore)",
"Read(**/*.jks)",
"Read(**/*.p12)",
"Read(~/.ssh/**)",
"Read(~/.aws/**)",
"Bash(curl *)",
"Bash(wget *)",
"Bash(sudo *)",
"Bash(rm -rf *)",
"Bash(git push --force *)",
"Bash(git push -f *)",
"Bash(cat .env*)",
"Bash(cat **/google-services.json)",
"Bash(cat **/key.properties)",
"Bash(printenv)",
"Bash(env)"
]
}
}
遮断対象の整理
| カテゴリ | ファイル/コマンド | 理由 |
|---|---|---|
| 環境変数 | .env* |
APIキー、DB接続情報 |
| Firebase |
google-services.json, GoogleService-Info.plist
|
Firebase APIキー |
| 署名鍵 |
key.properties, *.keystore, *.jks
|
ストア署名鍵 |
| システム認証 |
~/.ssh/**, ~/.aws/**
|
SSH鍵、AWS認証情報 |
| コマンド出力 |
printenv, env, cat .env*
|
環境変数の出力 |
| 危険操作 |
curl, wget, sudo, rm -rf
|
外部通信、破壊的操作 |
| Git | git push --force |
履歴破壊(不可逆) |
判断基準
| 設定 | 判断基準 |
|---|---|
| allow | 日常的に使うコマンドで、機密情報に触れないもの |
| ask | 必要だが影響が大きい操作(push、機密ファイル参照) |
| deny | 機密情報の漏洩リスクがあるもの、破壊的操作 |
6. 最終的に落ち着いた実務対策
多層防御の設計
最終的に、技術的対策・運用ルール・環境隔離の多層防御で対策することにしました。
┌─────────────────────┐
│ 🔧 技術的対策 │
│ (settings.json) │
│ 「読ませない」 │
└─────────────────────┘
+
┌─────────────────────┐
│ 📝 運用ルール │
│ (CLAUDE.md) │
│ 「渡さない」 │
└─────────────────────┘
+
┌─────────────────────┐
│ 📦 環境隔離 │
│ (sandbox/container)│
│ 「出させない」 │
└─────────────────────┘
↓
どれか一つでは守れない
技術的対策(settings.json)
- 機密ファイル → deny
- 危険なコマンド出力 → deny
- git push → ask
環境隔離(sandbox)
公式のBest Practicesでは、強い権限で実行する場合に隔離環境(サンドボックス、devcontainer)の利用が推奨されています。
サンドボックスとは
サンドボックスとは、Claude Codeが動ける範囲を「箱」の中に閉じ込める仕組みです。
通常モード:
┌────────────────────────────────────────────┐
│ あなたのPC全体 │
│ │
│ Claude Code → どこでもアクセス可能 │
│ │
│ - プロジェクトフォルダ ✅ │
│ - ~/.ssh/ ⚠️(設定次第) │
│ - ~/.aws/ ⚠️(設定次第) │
│ - インターネット ⚠️ │
└────────────────────────────────────────────┘
サンドボックスモード:
┌────────────────────────────────────────────┐
│ あなたのPC │
│ │
│ ┌──────────────────────────────┐ │
│ │ サンドボックス(箱) │ │
│ │ │ │
│ │ Claude Code(主にBash実行) │ │
│ │ ↓ │ │
│ │ プロジェクトフォルダのみ ✅ │ │
│ └──────────────────────────────┘ │
│ │
│ ~/.ssh/(Bashからのアクセスが制限。 │
│ Read権限設定も併用) │
│ ~/.aws/(同上) │
│ ネットワーク(Bashの接続先ドメインが │
│ 制限される) │
└────────────────────────────────────────────┘
なぜサンドボックスが必要なのか
settings.json で deny していても、以下のリスクが残ります。
| リスク | 例 |
|---|---|
| プロンプトインジェクション | 悪意あるコードがClaude Codeを操作して、設定を回避する |
| 予期しないコマンド実行 | 外部のREADMEをコピペしたら、その中に危険なコマンドが含まれていた |
| 情報の外部送信 | 機密情報を curl で外部に送る |
サンドボックスは、万が一上記が起きても、被害を箱の中に閉じ込めるための仕組みです。
具体的に何が制限されるのか
| 制限 | 内容 |
|---|---|
| ファイルシステム隔離 | Bash 実行時のファイルアクセス範囲に境界を設ける(許可範囲外はブロック/通知) |
| ネットワーク隔離 | Bash 実行時の通信先を許可ドメインに制限(未許可ドメインはブロック/確認) |
使い方
Claude Code内で /sandbox と入力するだけです。
# Claude Code内で
/sandbox
いつ使うべきか
| 使うべきタイミング | 理由 |
|---|---|
| 依存関係更新(pub upgrade / pod install) | 外部からパッケージをダウンロードするため |
| 外部の手順コピペ実行 | READMEやブログの手順に危険なコマンドが含まれている可能性 |
| ビルドやスクリプトが大量に走る作業 | 何が実行されるか把握しきれない |
| 通常は不要なタイミング | 理由 |
|---|---|
| コードを書く・読む | ファイル読み書きだけなら deny 設定で十分 |
| git status / git diff | 読み取り専用の安全な操作 |
より強い隔離が必要な場合
/sandbox は Bash 実行を中心に隔離しますが、OS 全体・IDE・ブラウザなども含めてより強く隔離したい場合は、Docker / devcontainer / VM など「開発環境そのもの」を分離することを検討してください。
運用ルール(CLAUDE.md)
CLAUDE.md に以下のルールを明記しました。
## 🔒 セキュリティルール
### 読み取り・出力を禁止するファイル
- `.env*`(環境変数、サブディレクトリ含む)
- `android/key.properties`(署名鍵設定)
- `**/google-services.json`(Firebase設定)
- `**/GoogleService-Info.plist`(Firebase設定)
- `**/*.keystore`, `**/*.jks`, `**/*.p12`(署名鍵)
### 確認後に読み取り可能なファイル
- `lib/firebase_options.dart`
- 読む場合は要点のみ抽出し、会話に全文を貼らない
### 禁止コマンド
- `printenv`, `env`(環境変数の出力)
- `cat` で上記機密ファイルを表示すること
- `curl`, `wget`(外部通信)
- `rm -rf`(再帰的削除)
- `git push --force`(履歴破壊)
### 運用ルール
- 機密ファイルの内容を **会話に貼らない**
- 聞くなら **構造だけ**(「.envにはどんなキーが必要?」)
- ログを貼る前に **機密情報をマスク**
なぜ多層防御が必要なのか
- settings.json は「Claude Code が勝手に読む」のを防ぐ
- CLAUDE.md は「自分で貼ってしまう」のを防ぐ(意識づけ)
- sandbox は「万が一の場合に被害を限定する」
- チームで共有できる(新メンバーも同じルールで運用)
7. セキュリティ設定チェックリスト
Claude Codeを安全に使うための設定フローです。
┌─────────────────────────────────────────────────────────────┐
│ 🚀 START: Claude Codeを使い始める前に │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 📋 STEP 1: 契約タイプを確認 │
├─────────────────────────────────────────────────────────────┤
│ │
│ あなたのアカウントは? │
│ ※最新の分類は公式ドキュメントを確認 │
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ 👤 Consumer │ │ 🏢 Commercial │ │
│ │ │ │ │ │
│ │ Free / Pro / Max │ │ Team / Enterprise │ │
│ │ │ │ / API │ │
│ └──────────┬──────────┘ └──────────┬──────────┘ │
│ │ │ │
└───────────────┼──────────────────────────┼──────────────────┘
│ │
▼ ▼
┌───────────────────────────┐ ┌───────────────────────────┐
│ ⚙️ STEP 2a: │ │ ⏭️ STEP 2b: │
│ 学習設定をOFFにする │ │ スキップ(原則OFF) │
│ │ │ │
│ claude.ai/settings │ │ ※契約内容を確認 │
│ /privacy │ │ │
└─────────────┬─────────────┘ └─────────────┬─────────────┘
│ │
└───────────────┬────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 🔧 STEP 3: 技術的対策(settings.json) │
├─────────────────────────────────────────────────────────────┤
│ │
│ ※以下はFlutterプロジェクトの例 │
│ │
│ ☐ .env* を deny に追加した │
│ ☐ google-services.json を deny に追加した │
│ ☐ key.properties を deny に追加した │
│ ☐ printenv / env を deny に追加した │
│ ☐ curl / wget を deny に追加した │
│ ☐ git push を ask に追加した │
│ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 📝 STEP 4: 運用ルール(CLAUDE.md / チーム共有) │
├─────────────────────────────────────────────────────────────┤
│ │
│ ☐ 機密ファイルの内容を会話に貼らない │
│ ☐ ログを貼る前に機密情報をマスクする │
│ ☐ 聞くなら「構造」だけ(内容は渡さない) │
│ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ ✅ DONE: 安全にClaude Codeを使える状態 │
└─────────────────────────────────────────────────────────────┘
8. まとめ
設定だけでは守れない
- deny していても、自分で貼ったら終わり
- 「一回だけなら大丈夫」が一番危ない
AIは「全部任せる相手」ではなく「どこまで見せるかを設計する相手」
Claude Code は非常に強力なツールですが、その強力さは「ローカル環境に広くアクセスできる」ことに由来します。
どこまで見せるかを設計する。その意識がないと、設定をいくらやっても漏れます。
明日からできること
-
settings.json に最低限の deny を入れる
-
.env*,google-services.json,key.propertiesは必須(Flutterの場合)
-
-
「これ、貼っていいんだっけ?」と一瞬考える
- この意識があるだけで、事故の確率はかなり下がります
参考リンク
公式ドキュメント
- Claude Code Security Documentation
- Claude Code Settings Reference
- Claude Code Best Practices
- Claude Code Sandboxing Guide
Privacy Center
- Is my data used for model training?
- How long do you store my data?
- How long do you store my organization's data?
Discussion