エンジニアじゃない私がClaude Codeのセキュリティ設定でやったこと
自分は鍼灸師です。Claude Code で自社で使うアプリ開発をしています。自分で開発してみたら、こんな大変だったのかの連続。今までいろんなシステムとかの不具体に対して、エンジニアの方に生意気いってすいませんって感じです。
特にセキュリティーは難しいし、怖い。でも自社で開発する必要があると感じる。
色々情報はあるが、そのまま理解しないで設定するのが怖いので、一応AIに聞きながら、必要な設定にチャレンジした記録を残します。
まだまだ、知らないことはあるので、勉強しながら成長したいです。
内容は、AIに聞いた内容がほとんどなので、真偽はわかりません。
1. はじめに — Yesを押すのが怖い
Claude Code を使い始めて、最初に思ったこと。
「この英語の確認画面、なに聞かれてるかわからない」
Claude Code はターミナル（黒い画面）で動く AI ツール。コードを書いてくれるし、ファイルも操作してくれる。とても便利。でも、何か操作をするたびに英語で「これ実行していい？」と聞いてくる。
Allow? Yes / No
何をするのか意味がわからないことが多い。でも No を押したら作業が止まる。だから Yes を押す。また聞かれる。また Yes。また Yes……。
Yes の連打。
これ、ものすごく怖い
自分はエンジニアではありません。プログラミングの知識はほとんどゼロ。そんな自分が「意味もわからずYesを押し続ける」のは、目隠しで横断歩道を渡っているようなもの。
だから、Claude Code を本格的に使い始める前に、まずセキュリティ設定をしました。
正直、完璧な設定ではないと思う。エンジニアから見たら「まだ足りないよ」と言われるかもしれない。でも、何も知らずに Yes を連打していた頃とは全然違う。
最低限の入口には立てた。自分がやった設定の記録として残しておきます。
この記事は、そんな「最初の一歩」の記録です。
自分がやった12の対策（まとめ）
詳しい説明は各セクションにあるけど、「結局なにをやったの？」がすぐわかるように、先に一覧で並べておく。
| # | やったこと | ひとことで言うと |
|---|---|---|
| ① | ホームディレクトリで開かない | アクセス範囲を必要最小限に絞る |
| ② | rm -rf 等の削除コマンドを完全禁止 | ファイルが一瞬で消えるのを防ぐ |
| ③ | sudo（管理者権限）を完全禁止 | パソコン全体を乗っ取られるのを防ぐ |
| ④ | curl / wget を完全禁止 | 勝手にネットからダウンロードさせない |
| ⑤ | .env / ~/.ssh/ / ~/.aws/ の読み書き作成を禁止 | API キーや秘密鍵の漏洩を防ぐ |
| ⑥ | bash -c / python -c 等の間接実行を禁止 | 裏口から禁止コマンドを実行されるのを防ぐ |
| ⑦ | chmod（権限変更）を全パターン禁止 | ファイルのアクセス権を勝手に変えさせない |
| ⑧ | git push / mv 等を毎回確認 | 重要な操作は理解してから判断する |
| ⑨ | サンドボックスを有効化 | OS レベルでファイル書き込みと通信先を制限 |
| ⑩ | CLAUDE.md で日本語説明を義務化 | 「Yes の前に、何を許可するか理解する」 |
| ⑪ | .gitignore に .env を追加 | 万が一 .env が作られても外に漏れない安全網 |
| ⑫ | 1Password と連携し .env に直接記入しない | 秘密情報をファイルに残さない |
① が「ホームディレクトリで開かない」、②〜⑦ が「完全禁止」、⑧ が「毎回確認」、⑨⑩⑪⑫ が「仕組みで守る」。
2. Yes連打で何が起きるか
「Yes を押すだけで何が起きるの？」
具体的に、想定される怖い例を挙げる。これらはすべて、Yes を1回押すだけで起きうること。
ファイル全削除
rm -rf というコマンドがある。「フォルダごと、確認なしで、強制的に削除する」という意味。
Yesを押すと、プロジェクトのファイルが一瞬で消える。ゴミ箱にも残らない。「元に戻す」もできない。
秘密鍵・APIキーの漏洩
.env というファイルには、API キー（外部サービスに接続するためのパスワードのようなもの）が入っている。~/.ssh/ には、サーバーに接続するための秘密鍵が入っている。
AI がこれらを読み取って画面に表示してしまうと、コピペで外部に流出するリスクがある。
※自分は 1Password と連携しており、.env に直接記入しない運用にしている。
管理者権限の奪取
sudo は「管理者権限で実行する」という意味。これを許可すると、パソコン全体の設定を変えられてしまう可能性がある。
普段は制限されている操作が、すべて可能になってしまう。
意図しないコードの公開
git push は、自分のパソコンにあるコードをインターネット上（GitHub）に送信するコマンド。
未完成のコードや、秘密情報が入ったままのコードが公開されてしまうかもしれない。
外部からの不正ダウンロード
curl や wget は、インターネットからファイルをダウンロードするコマンド。
悪意あるスクリプト（プログラム）をダウンロードして、そのまま実行されてしまう可能性がある。
ホームディレクトリで開く
Claude Code をホームディレクトリ（~/）で起動すると、パソコン内の個人フォルダ全体にアクセスできる状態になる。
.ssh/ や .aws/、書類フォルダなど、本来プロジェクトとは関係ないファイルまで触れるようになってしまう。アクセス範囲が広いほど、誤操作や漏洩のリスクが増える。
これらはすべて、Yes を1回押すだけで起きうること。
「まさかそんなことにはならないでしょ」と思うかもしれない。でも、可能性がゼロではない限り、対策しておきたい。それが、自分がやった対策の理由。
3. 自分が使った仕組み — Claude Codeのセキュリティ設定
Claude Code には、「やっていいこと」と「やっちゃダメなこと」を事前に設定できる仕組みがある。
設定に使うファイルは、大きく分けて2種類。
settings.json — 「禁止」と「確認」のルール
JSON（ジェイソン）という形式のファイルで、コマンドごとに以下を設定できる。
- deny（禁止）: そのコマンドは絶対に実行できない。Yes すら表示されない完全ブロック
- ask（毎回確認）: 実行前に毎回 Yes / No を聞かれる。意識的に判断できる
CLAUDE.md — 「ふるまい」のルール
マークダウン（Markdown）という形式のファイルで、Claude の行動ルールを自然な言葉で書く。
たとえば「日本語で説明してから実行してね」「確認なしにファイルを変更しないでね」といったルール。
settings.json が「法律」だとしたら、CLAUDE.md は「社内マニュアル」のようなイメージ。
4. Claudeが勝手に動くのが怖かった
セクション2で挙げたリスクを知った上で、自分がまずやったのは2つの対策。
対策A: settings.json で危険なコマンドを完全禁止
先ほどの rm -rf、sudo、curl などを deny（完全禁止）に設定した。
これで、Claude がこれらのコマンドを実行しようとしても、Yes / No の画面すら表示されない。完全にブロックされる。
「Yes を押す機会すら与えない」— これが一番確実な防御。
対策B: CLAUDE.md に行動ルールを書いた
settings.json だけでは足りない。settings.json は特定のコマンドしかブロックできないから。
そこで、CLAUDE.md に「すべての操作について日本語で説明してから実行する」というルールを書いた。
特に重要なのは、この一文。
ユーザーが「よくわからないまま Yes を押す」ことを絶対に防ぐ。これが最優先の目標である。
さらに、確認を求めるときは以下の形式で説明するよう指示した。
【これから行うこと】ビルド番号を3に更新します
【なぜ必要か】TestFlightに新しいバージョンをアップロードするため
【実行するとどうなるか】Info.plist のビルド番号が 2 → 3 に変わります
【リスク】なし
英語で Allow? と聞かれるよりも、ずっとわかりやすい。自分が何を許可しようとしているのか、理解した上で判断できるようになった。
5. 設定ファイルの場所がわからない
もう一つ戸惑ったのが、設定ファイルの置き場所。
Claude Code の設定ファイルは 2箇所 に置ける。
グローバル設定（パソコン全体に効く）
~/.claude/settings.json ← 全プロジェクト共通の禁止・確認ルール
~/.claude/CLAUDE.md ← 全プロジェクト共通の行動ルール
~/ は「ホームフォルダ」のこと。パソコンにログインしたユーザーの個人フォルダ。ここに置いた設定は、どのプロジェクトを開いても適用される。
プロジェクト設定（そのプロジェクトだけに効く）
プロジェクト/.claude/settings.json ← このプロジェクトだけの追加ルール
プロジェクト/CLAUDE.md ← このプロジェクトだけの行動ルール
特定のプロジェクトだけに必要な設定はここに置く。
最初の失敗
自分は最初、全部プロジェクト側に入れてしまった。後から「あ、これだと新しいプロジェクトを作るたびに同じ設定をコピーしないといけない」と気づいた。「rm -rf を禁止する」なんて、どのプロジェクトでも同じはず。 そこはAIは考えてはくれないのか？自分が選択肢を見逃したのか？
そこで、後からグローバル設定に整理し直した。
考え方はシンプル。
- 全プロジェクト共通のルール → グローバル（~/.claude/）
- 特定プロジェクトだけのルール → プロジェクト（.claude/）
6. 自分が実際に設定した内容
最後に、自分が実際に設定した内容の全体像を載せておきます。
グローバル設定（~/.claude/settings.json）
すべてのプロジェクトに共通する設定。セクション2で挙げたリスクに対応している。
完全禁止（deny）— Yesすら表示されない
| 設定 | 何を防いでいるか | 対応するリスク |
|---|---|---|
| rm -rf | フォルダごと強制削除 | ファイル全削除 |
| rm -r | フォルダごと削除 | ファイル全削除 |
| sudo | 管理者権限での実行 | 管理者権限の奪取 |
| curl | ネットからのダウンロード | 不正ダウンロード |
| wget | ネットからのダウンロード | 不正ダウンロード |
| chmod | アクセス権の変更（すべて） | セキュリティ全般 |
| > (リダイレクト) | ファイル内容を空にする | ファイル全削除 |
| bash -c / sh -c | シェル経由の間接実行 | 禁止コマンドの迂回 |
| python -c / python3 -c | Python 経由の間接実行 | 禁止コマンドの迂回 |
| node -e / eval | Node.js / eval 経由の間接実行 | 禁止コマンドの迂回 |
| .env の読み取り・編集・作成 | API キーなどの秘密情報 | 秘密鍵の漏洩 |
| ~/.ssh/ の読み取り | SSH 秘密鍵 | 秘密鍵の漏洩 |
| ~/.aws/ の読み取り | AWS 認証情報 | 秘密鍵の漏洩 |
毎回確認（ask）— 実行前に必ず確認
| 設定 | 何を確認しているか |
|---|---|
| rm | ファイルの削除 |
| rmdir | フォルダの削除 |
| mv | ファイルの移動・名前変更 |
| npm install | Node.js パッケージの追加 |
| pip install | Python パッケージの追加 |
| brew install | macOS パッケージの追加 |
| git push | コードのインターネット公開 |
| git reset | git 履歴の巻き戻し |
| git checkout — | ファイル変更の取り消し |
| git clean | 未追跡ファイルの削除 |
| git branch -D | ブランチの強制削除 |
サンドボックス — OSレベルの制限
settings.json には deny/ask だけでなく、サンドボックスという設定もある。
“sandbox”: { “enabled”: true, “mode”: “auto-allow” }
これを有効にすると、macOS の機能を使って以下が制限される。
- ファイル書き込み: プロジェクトフォルダ内のみ（他の場所に書き込めない）
- ネットワーク: 許可されたドメインのみ（勝手に外部通信できない）
deny/ask が「コマンドの禁止・確認」だとすると、サンドボックスは「そもそも手が届かないようにする」イメージ。家のドアに鍵をかける（deny）だけでなく、家の周りに塀を作る（サンドボックス）ような防御。
プロジェクト設定（.claude/settings.json）
このプロジェクト固有の設定。とてもシンプル。
| 設定 | 何を確認しているか |
|---|---|
| xcodebuild | Xcode のビルド実行 |
ビルド（アプリのコンパイル）は時間がかかるので、意図しないタイミングで実行されないよう確認を入れている。
行動ルール（CLAUDE.md）の要約
settings.json に加えて、CLAUDE.md で以下の行動ルールを定めている。
| ルール | 内容 |
|---|---|
| 基本姿勢 | すべての操作を日本語で説明してから実行。ホームディレクトリで開かない（プロジェクトフォルダで起動する） |
| ファイル編集 | 編集前に「〇〇を編集しますが、よろしいですか？」と確認 |
| 削除コマンド | 原則として実行しない（settings.json の deny と二重防御） |
| パッケージ追加 | 名前・目的・影響範囲を説明してから |
| コマンド実行 | 「よくわからないまま Yes を押す」ことを絶対に防ぐ（最重要ルール） |
7. 自分がやった設定をClaudeに採点させたら穴が6つ出てきた
Claude自身に「この設定、ちゃんとできてる？」と聞いてみた。そしたら、6つも穴が見つかった。 正直ちょっとショックだった。
見つかった穴と対策
穴① サンドボックスが未有効（影響度：大）
settings.json の deny/ask だけでなく、OS レベルでファイル書き込みや通信を制限できる機能がある。それを有効にしていなかった。
たとえるなら: 玄関には鍵をかけていたが、窓が開けっぱなしだった状態。
→ 対策: sandbox を有効化（セクション6に追記済み）
穴② .env ファイルの「新規作成」が止められなかった（影響度：中）
.env の「読み取り」と「編集」は禁止していたけど、「新規作成」は禁止していなかった。Claude が新しい .env ファイルを作ることは止められなかった。
たとえるなら: 「金庫を開けるな」「金庫の中身を書き換えるな」とは言ったが、「新しい金庫を作るな」とは言っていなかった。
→ 対策: Write(./.env) を deny に追加
穴③ 間接的なコマンド実行ができた（影響度：中）
rm -rf を禁止しても、bash -c “rm -rf /” のように別のコマンド経由で実行できる可能性があった。（禁止したコマンドを、別のコマンドの「裏口」から実行されること）
→ 対策: bash -c、sh -c、python -c、node -e、eval をすべて deny に追加
穴④ ファイル移動（mv）が無制限だった（影響度：小〜中）
mv（ファイルの移動・名前変更）は、重要なファイルを別の場所に移動できてしまう。
→ 対策: mv を ask（確認）に追加
穴⑤ chmod の範囲が狭かった（影響度：小）
chmod 777（アクセス権の全開放）だけ禁止していたけど、他にも危険なパターンがあった。
→ 対策: chmod *（すべての chmod）を禁止に変更
穴⑥ .gitignore に .env が未登録（影響度：中）
万が一 .env ファイルが作成された場合、git に追跡されて push 時に公開されるリスクがあった。
→ 対策: .gitignore に .env / .env.* を追加
改善後の全体像
| レイヤー | 設定ファイル | 役割 |
|---|---|---|
| コマンド制御（deny） | settings.json | rm -rf, curl, bash -c, .env の全操作を完全禁止 |
| コマンド制御（ask） | settings.json | git push, npm install, mv を毎回確認 |
| OS レベルの制限 | settings.json（sandbox） | ファイル書き込み範囲・通信先を制限 |
| 行動ルール | CLAUDE.md | 操作前に日本語で説明・確認を取れ |
| 安全網 | .gitignore | .env を git 追跡対象から除外 |
ポイント: settings.json がシステムレベルの守り、CLAUDE.md が AI への指示レベルの守り、.gitignore が万が一のための安全網。複数の層が重なることで、1つが破られても他で止められる「多層防御」になっている。
8. まとめ — 自分がやったことの記録
最初にやったのは「最低限の防御」。そこから自分がやった設定をClaudeに採点させたら、6つの穴が見つかって、全部塞いだ。
何も知らずに Yes を連打していた頃とは全然違う。
- 危険なコマンドは、Yes を押す画面すら出ない
- 裏口（間接実行）も塞いだ
- OS レベルのサンドボックスで、そもそも手が届かない範囲を制限した
- その他のコマンドも、日本語で意味を教えてもらってから判断できる
- 万が一のために .gitignore で安全網も張った
ただ、これで完璧ではない。AIが教えてくれる範囲には限界がある。本当に安全かどうかは、詳しい人に見てもらわないとわからない。セキュリティに「完成」はないんだろう。
最低限の入口には立てた。でも、ここから先は専門家の力を借りるタイミングだと感じている。 引き続き、使いながら設定を育てていきます。