
Claude Code を安全に使おう【社内勉強会スライド】
社内のチームメンバー(クラウド事業本部コンサルティング部)向けに 「 Claude Code を安全に使おう勉強会 」を開催しました。 Claude Code をセキュアに使う上での、 基本的な考え方や権限/サンドボックス機能の紹介、簡単なデモを実施しました。
DevelopersIO向けに調整したスライドを掲載します。
以下勉強会で連携した設定サンプルです。
スライドの内容:テキスト情報を以降に記載します。参考になれば幸いです。
イントロ
勉強会の目的やアジェンダ、スコープについて話します。
勉強会の目的
Claude Code (に限らず、AIエージェント) はとても便利です。 しかしリスクもあり、暴走もします。
この勉強会では、 Claude Codeが適切な範囲で適切に動けるような、 ガードレールの敷き方 を学びます。
アジェンダ
- Claude Code の仕組みを知る
- Claude Code を安全に使うには?
- 抑止する工夫
- 制限する工夫
- 隔離する工夫
- その他いろいろ
話すこと / 話さないこと
話すこと
- Claude Code の仕組みとセキュリティの考え方
settings.jsonの permissions / Hooks / サンドボックス- 推奨設定のサンプル共有
話さないこと
- MCP / Skill など拡張機能のセキュリティ
- 周辺知識(GitHub / Terraform / コーディング等)のセキュリティ
- 詳細な
settings.jsonの書き方 - ガバナンス・コンプライアンス領域の話
- 推論の地理的制約、データ保持期間、監査要件など
Claude Code の仕組みを知る
Claude Code の仕組み、特に agenticループとツールの話をします。
agenticループ
agenticループは コンテキストの収集、アクションの実行、結果の検証 の3つのフェーズで構成されます。 あなた自身もループの一部です。

agenticループの構成図: Gather context → Take action → Verify results。ユーザーの介入も含まれる
agenticループのコンポーネント
agenticループは 推論するモデル と アクションを実行するツール によって駆動されます。
- モデル : コードを理解し、次に何をすべきか推論・判断する
- 具体例:
sonnet,opus
- 具体例:
- ツール : モデルの判断に基づきファイル操作やコマンド実行などを実際に行う
- 具体例:
Read,Edit,Bash
- 具体例:
参考: 組み込みツールができること
| カテゴリ | Claude ができること |
|---|---|
| ファイル操作 | ファイルの読み取り、コード編集、新規ファイル作成、名前変更と再編成 |
| 検索 | パターンでファイルを検索、正規表現でコンテンツを検索、コードベースを探索 |
| 実行 | シェルコマンド実行、サーバー起動、テスト実行、git 使用 |
| ウェブ | ウェブ検索、ドキュメント取得、エラーメッセージ検索 |
– 引用: Claude Code の仕組み - Claude Code Docs (抜粋)
ツールが agentic の肝
ツールが無かったらClaudeはテキスト応答しかできません。 ツールがあることでアクションを実行できます。
<ツール制御がセキュリティの肝!>
Claude Code を安全に使うには?
セキュアな環境を作るには ツールの制御 が大事になってきます。
どのような制御アプローチがあるか、学びましょう。
以下3軸で考えてみました
- 抑止する : 危険なツールを実行させないように誘導する
- 制限する : 危険なツールを実行できないようにする
- 隔離する : 危険なツールを実行しても問題ない環境を作る
Claude Code で実現するには?
- 抑止する → CLAUDE.md
- 制限する → Permissions, Hooks
- 隔離する → サンドボックス, Dev Container
(それぞれの話は後ろで説明します!)
クラウド事業本部なのでむりやりAWSに絡めます
※ 鵜呑みにしないでください
抑止する

CLAUDE.md ≒ AWS利用ガイドライン。望む方向に向かわせる効力はあるけどあくまでお守り
制限する

settings.json [permissions] ≒ ユーザーポリシーやSCP。できる操作/できない操作を仕組みで制限する
隔離する

Dev Container や Sandboxing ≒ AWSアカウント分割。環境を分離して、そもそも境界の外に手が届かないようにする
抑止する工夫
Claudeが危険なツール実行をしないように お願い する工夫を考えます。
CLAUDE.md
CLAUDE.md を使って Claude に永続的な指示を与える方法を見ていきます。
CLAUDE.md とは
CLAUDE.md ファイルは、プロジェクト、個人的なワークフロー、 または組織全体に対して Claude に 永続的な指示を与えるマークダウンファイル です。 Claude は 各セッションの開始時にそれらを読みます 。
CLAUDE.md を置く場所(スコープ)
CLAUDE.md は配置する場所によってスコープが変わります。
| スコープ | 場所 | 共有対象 |
|---|---|---|
| 管理ポリシー | OS のシステムディレクトリ | 組織内のすべてのユーザー |
| プロジェクト指示 | ./CLAUDE.md or ./.claude/CLAUDE.md |
ソース管理を通じたチームメンバー |
| ユーザー指示 | ~/.claude/CLAUDE.md |
あなただけ(全プロジェクト共通) |
– CLAUDE.md ファイルをどこに配置するかを選択する - Claude Code Docs
危険なツール実行をしないように "お願い" するサンプル
CLAUDE.md に「やってほしくないこと」を書いておく例です。
# セキュリティ
- .env, credentials 等の機密ファイルを読み取り・編集・コミットしないこと
- シークレットやAPIキーをコードにハードコードしないこと
- rm -rf / や force push 等の破壊的コマンドを実行しないこと
その他の抑止手段
CLAUDE.md 以外にもいくつか工夫できるポイントがあります。
- .claude/rules/ にもコンテキストファイルを置ける
pathsフィールドで特定ファイルにスコープしたルールを書ける
- 曖昧な指示を避ける
- 「認証失敗する、直して」→ 試行錯誤で操作範囲が広がりがち
- そもそも破壊的な操作は Claude に依頼しない
terraform apply/destroy、ディレクトリ削除 等
制限する工夫
ツール実行そのものを 機械的に制御 する仕組みを学びます。
そのために、まずはツールのことを知りましょう。
ツールの種類
Claude Code は組み込みツールを通じてアクションを実行します。 主要なツールは以下のとおりです。
| ツール | 説明 |
|---|---|
Bash |
シェルコマンドを実行する |
Read |
ファイルの内容を読み取る |
Edit |
特定のファイルに対して対象を絞った編集を行う |
Write |
ファイルを作成または上書きする |
WebFetch |
指定された URL からコンテンツを取得する |
| ... | ... |
– ツール リファレンス - Claude Code Docs
特に制御したいツール
セキュリティの観点で特に制御したいのはこのあたりです。
- Bash : シェルコマンドを何でも実行できてしまう
- Read : 機密ファイル(
.env等)を読まれてしまう - Edit / Write : 更新されたくないファイルを変更できてしまう
settings.json で権限を制御する
ツールの制御は settings.json の permission セクションに記載します。
settings.json とは
Claude Code の動作を構成する設定ファイルです。
権限ルール、フック、サンドボックス、その他諸々の設定を定義します。
- 参考: settings#利用可能な設定
settings.json の置き場所(スコープ)
settings.json は配置する場所でスコープが変わります。
| スコープ | 場所 | 共有対象 |
|---|---|---|
| Managed | OS のシステムレベル | 組織内のすべてのユーザー |
| User | ~/.claude/settings.json |
あなただけ(全プロジェクト) |
| Project | .claude/settings.json |
チームメンバー |
| Local | .claude/settings.local.json |
あなただけ |
permissions セクションに権限ルールを記載する
{
"permissions": {
"allow": [ ... ],
"ask": [ ... ],
"deny": [ ... ]
}
}
- allow : 手動承認なしでツール使用を許可
- ask : ツール使用のたびに確認を促す
- deny : ツール使用を拒否
Tips: 評価の順序
権限ルールは deny → ask → allow の順番で評価されます。
最初にマッチしたルールが優先されるため、 deny は常に最優先 です。
権限ルールの書き方
ルールは Tool または Tool(specifier) の形式で書きます。
| ルール | 効果 |
|---|---|
Bash |
すべての Bash コマンドをマッチ |
Bash(npm run *) |
npm run で始まるコマンドをマッチ |
Read(~/.zshrc) |
~/.zshrc ファイル読み取りをマッチ |
Edit(/src/**/*.ts) |
<project root>/src/ 配下の TS ファイル編集をマッチ |
Read(//**/.env*) |
システム全体の .env* ファイル読み取りをマッチ |
– 権限ルール構文 - Claude Code Docs (読み込み推奨!)
推奨設定のサンプル
~/.claude/settings.json に置く例です。
{
"permissions": {
"deny": [
"Read(//**/.env*)",
"Read(//**/credentials*)",
"Edit(//**/.env*)",
"Edit(//**/credentials*)",
"Bash(rm *)",
"Bash(git *)"
]}}
- 完全なサンプルは こちら → Gist
その他の制限手段: Hooks
settings.json の deny ではカバーしきれない範囲もあります。
そういった範囲は Hooks (や その次のSandbox) で補いましょう。
Hooks とは
Claude Code ライフサイクル内の特定ポイントで 自動実行される、 ユーザー定義のシェルコマンド(など) です。 同じく settings.json に記載します。
| 観点 | permissions (deny/allow) | Hooks |
|---|---|---|
| 方式 | 静的なパターンマッチ | スクリプトによるチェック |
| 柔軟性 | ツールとパターンの組み合わせ | 任意のロジックを実装可能 |
| 用途 | 基本的なアクセス制御 | 複雑な条件での判定 |
– Claude Code フック - Claude Code Docs
ライフサイクルイベントの例
| イベント | いつトリガーするか |
|---|---|
SessionStart |
セッション開始時 |
PreToolUse |
ツール呼び出しの直前 |
PostToolUse |
ツール呼び出しの成功後 |
Notification |
Claude がユーザーに通知を送信する時 |
ツール制御の文脈では PreToolUse をよく使います。
Hooks の活用例
PreToolUse フックを使用する。 Bash コマンドの URL を検証し、許可されていないドメインをブロックするフックを実装します。
具体的な書き方は Hooksリファレンス を参照ください。
隔離する工夫
影響範囲を限定する 仕組みを学びます。
サンドボックス
Bash ツールのファイルシステムとネットワークを OS レベルで制限する仕組みです。
サンドボックスとは
Claude Code は ネイティブサンドボックス機能 を備えており、エージェント実行のためのより安全な環境を提供しながら、継続的な許可プロンプトの必要性を軽減します。 各 bash コマンドの実行許可を求める代わりに、サンドボックス化により 事前に定義された境界 が作成され、Claude Code はリスクを軽減しながらより自由に動作できます。
サンドボックスのスコープは Bash ツールとその子プロセスのみ です。 Read, Edit, Write, WebFetch 等のほか組み込みツールは対象外です。
何が嬉しい?
permissions の deny パターンは コマンド文字列 のマッチです。
"deny": ["Bash(cat .env)", "Bash(curl example.com)"]
しかし、コマンドはいくらでも書き換えられます。 python -c "print(open('.env').read())" や less .env 、 my-custom-script .env など、いくらでも迂回できます。
サンドボックスは OSレベル でファイルアクセスとネットワーク接続を制限するため、 コマンド名に関係なく、すべての子プロセスに同じ制約が適用されます。
有効化の方法
settings.json に以下を記載します。 (もしくは /sandbox で有効化)
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": false
}}
境界の設定方法

sandbox 設定の構成例 (filesystem / network / excludedCommands 等)
sandbox > filesystem, network に定義します。 詳しい書き方は公式リファレンスを参照ください。いちサンプル → Gist
その他の隔離手段: Dev Container
より強力な隔離が必要な場合は Dev Container も選択肢です。
- コンテナ内で Claude Code を実行し、ホストシステムから完全に分離
- ファイアウォールでネットワーク接続先をホワイトリスト制限
- Anthropic が リファレンス実装 を提供しています
その他いろいろ
雑多なTipsや所感、メモを書いていきます。
あまり整理できていないところもあります。
Claude Code を起動する場所に注意する
デフォルトの挙動として、Claude Code は 起動されたディレクトリ内のファイルにアクセス できます。 したがって、起動する場所を絞ることが、そのままアクセス範囲を絞ることに繋がります。
ホームディレクトリや複数プロジェクト/コンテキストが混じったような デカいディレクトリでの起動は避けましょう 。 無関係なファイルまでアクセスされるリスクがあるためです。
Permissions / Hooks / サンドボックス はどう使い分ける?
Permissions とサンドボックスは補完関係であり両方使うべき です。
- 各ツールの基本的な制御 → Permissions
- Bash 実行のOSレベルでの封じ込め → サンドボックス
Hooks は Permissions やサンドボックスでは制御が難しい、 高度な allow/deny 判断処理が必要な場合に使うと良いです。
サンドボックスを触り始めた雑感(メモレベル)
-
permissions.deny の Bash(xx) では防ぎきれない、 ファイル読み書き・NW経由の迂回を封じ込められるのは、かなり便利
-
デフォルトだと Bash 実行が承認無しになる。 怖いので、
autoAllowBashIfSandboxed:falseを入れた -
デフォルトだとサンドボックス内での Bash 実行が失敗した時に、 承認を求めたうえでサンドボックス外で再実行しようとする
allowUnsandboxedCommands:falseを入れて、バイパスを止めた- サンドボックス外で実行したいコマンドは
excludedCommandsに明示的に書く運用が良さそう
-
最初は Bashの実行失敗 or NWアクセス承認/拒否確認が多発しがち。 地道にチューニングしながら運用するのが現実的
-
たとえば
awsコマンドを実行させると169.254.169.254(インスタンスメタデータ) や*.amazonaws.comへの アクセス承認を都度求められる。これらはnetwork.allowedDomainsで許可すると良い -
gh/terraform等の Go製ツールはサンドボックス内から macOS の TLS 信頼サービスにアクセスできず失敗するenableWeakerNetworkIsolation:trueで回避できるが、 ネットワーク隔離が弱まる点はトレードオフ
パーミッションモードを使い分けよう

パーミッションモード一覧: default / acceptEdits / plan / auto / bypassPermissions / dontAsk とそれぞれの用途
– 引用: 利用可能なモード - Claude Code Docs
dangerously-skip-permissions は原則使わない
--dangerously-skip-permissions フラグは --permission-mode bypassPermissions と同等です。 保護されたディレクトリへの書き込みを除く、すべての権限プロンプトをスキップします。 強力な隔離環境で動かす場合を除き、 原則使わない ようにしましょう。
autoMode の雑感(メモレベル)
- autoMode は 分類器モデルがアクションの安全性を判断 し、許可なしで実行可否を決めるモード (現在は研究プレビュー)
- 少し触った感想: わりと承認無しに色々実行するので、ちょっと怖い。 Permissions や Sandboxing の設定はちゃんと固めた上で使いたいと思った
- 未検証:
autoMode.environmentで信頼インフラを分類器に連携できる - 未検証: 分類器組み込みのblock/allowルールをオーバーライドできる
autoMode.allow/autoMode.soft_denyに追加ルールを定義するclaude auto-mode defaultsでデフォルトの完全なリストを取得し、 それをベースに編集する (空リストから書き始めない)

autoMode の allow / soft_deny でブロック・許可ルールをオーバーライドする設定例
小ネタ: "🤖 Co-Authored-By" を消す
attribution キーを更新して、 git コミットとプルリクエストメッセージをカスタマイズできます。 以下、空にする設定です。
{
"attribution": {
"commit": "",
"pr": ""
}}
※ includeCoAuthoredBy 設定は非推奨になっています。
Claude Code の周辺環境も整えましょう
- シークレット管理ツール (1Password CLI, aws-vault 等)
- 認証情報を
.envなどに平文で置くのを避けます - Claude Code に読み取られるリスク自体を無くしましょう
- 認証情報を
.gitignore- 機密情報は確実に ignore します。 誤ってコミット対象に含めてしまうリスクを下げましょう
settings.local.jsonなど個人設定も ignore 対象にします。 個人設定の設定が他メンバーに混ざるのを防ぎます
- pre-commit
- gitleaks で機密情報のコミットを検出・ブロックします
- など…
有益なリソース
- 読み込みたい公式ドキュメント
- Claude Codeの設定 : 基本仕様や設定可能なキー一覧が分かる
- 設定 > 権限 : 権限ルールの構文が分かる
- 設定 > サンドボックス : サンドボックス機能を理解できる
- はじめに > パーミッションモード : 各モードの権限が分かる
- リファレンス > ツール : 利用可能なツール一覧が分かる
おわりに
以下、今回話したことです。
- 安全に Claude Code を使うには ツールの制御が肝
- 抑止 : CLAUDE.md でお願いする。ただしお守り程度と割り切る
- 制限 : permissions で deny/ask/allow を定義する。複雑な判定は Hooks で補う
- 隔離 : サンドボックスで Bash ツールを OS レベルで封じ込める。より強力な隔離は Dev Container も選択肢
- 周辺環境 (シークレット管理、
.gitignore、pre-commit 等) も合わせて整えよう
安全な Claude Code 環境を作りましょう!
参考
本資料作成にあたり、参考にしたリンクを記載します。
Claude Code 公式ドキュメント
- 基本情報
- settings.json (権限/ツール/Hooks)
- サンドボックス, Dev Container








