Claude Codeのサンドボックスと権限設計 ― 便利さと安全性を両立する実践

「AIエージェントが暴走して環境を壊したらどうしよう」「便利だが、本番DBにアクセスできる状態は怖い」 ― CTO・情シスから受ける典型的な懸念だ。Claude Codeのような自律型エージェントは「やる気」と「権限」を持つため、一度間違うと取り返しがつかない事態を起こす。想定外のファイル削除、本番環境への直接アクセス、機密データへの過剰アクセス、課金APIの暴走呼び出し ― これらリスクは決してゼロではない。「便利さ」と「安全性」のバランスを取るには、サンドボックスと権限設計が必須だ。本稿では、サンドボックスの必要性、3層構造（ディレクトリ・コマンド・ネットワーク）、信頼できるディレクトリ設定、危険コマンド制御、環境分離、権限設計の4原則、MCP連携時の権限管理、インシデント時の対応、ガバナンス文書、経営観点の重要性を整理する。

要点：「便利さ」と「安全性」のバランスは、サンドボックスと権限設計で取る。最小権限の原則を徹底し、3層防御（ディレクトリ・コマンド・ネットワーク）で組織を守る。

1. なぜサンドボックスが必要か ― 自律エージェントの3つのリスク

サンドボックスが必要な理由は明確だ。想定外のファイル削除、本番環境への直接アクセス、機密データへの過剰アクセス、課金APIの暴走呼び出し ― これらリスクは自律型エージェントが原因で起きうる。Claude Codeは「やる気」と「権限」を持つため、指示を誤解して破壊的操作を実行する可能性がある。一度起きると取り返しがつかない事態（本番DBの全削除・SSH鍵の漏洩等）もありうる。「便利だから自由に使わせる」は組織のリスク管理として不適切で、最低限のサンドボックス設計は導入時の必須要件だ。「事故が起きてから対策」では遅い領域。

💡 ポイント：4リスクを経営層に提示することで、「サンドボックス整備」が便利機能ではなく必須投資として位置づけられる。

2. サンドボックスの3層構造

サンドボックスは3層で設計する。層1：ディレクトリ制限でアクセス許可ディレクトリの限定、信頼できるディレクトリ設定。層2：コマンド制限で危険コマンドのホワイトリスト、実行前確認。層3：ネットワーク制限で外部API呼び出しの制限、認証情報の管理。これら3層が組み合わさることで「壊せない・触れない・出ていけない」環境ができる。1層だけでは突破される可能性があり、3層を組み合わせる多重防御が現実解だ。「ディレクトリ制限だけ」「コマンド制限だけ」では不十分で、すべての層を整備する必要がある。

📊 経営判断のコツ：3層構造を1枚図にして経営会議に提示する。「便利さと安全性のバランス」を構造的に説明する材料になる。

3. 信頼できるディレクトリ設定

ディレクトリ制限は最も基本的な防御層だ。設定例として、~/.claude/settings.jsonにtrustedDirectoriesとして~/projects/work・~/projects/personalを許可、blockedDirectoriesとして~/secrets・~/.ssh・/etcを禁止する。これにより機密ディレクトリへのアクセスが防止され、誤操作による被害が最小化される。「全ディレクトリ自由アクセス」は最悪の設定で、最初に設定すべき防御だ。プロジェクトごとに信頼ディレクトリを限定することで、意図しない他プロジェクトへの影響も防げる。設定ファイル自体をGit管理し、変更時はレビューを通す運用が望ましい。

⚠️ 注意：「ホームディレクトリ全体を信頼」は危険な設定。プロジェクト単位で絞ることが安全運用の基本。

4. 危険コマンドの制御

危険コマンドの制御方法は3つ。ホワイトリストで許可コマンドのみ実行。ブラックリストで危険コマンドは禁止。確認モードで実行前に人間承認。代表的な危険コマンドはrm -rf・sudo・git push --force・DB系の本番アクセス・課金APIの呼び出し。これらコマンドはAIエージェントが実行する前に必ず人間が承認するか、そもそも禁止するかを設定する。「便利だから許可」は事故の温床で、「安全側に倒す」判断が長期的に正しい。組織全体で「禁止コマンドリスト」を整備し、Claude Code設定として共通配布する運用が現実的だ。

💡 ポイント：「禁止コマンドリスト」を組織標準として整備する。CTO直轄でリスト管理し、半年に1回見直す運用にする。

5. 環境分離 ― 開発・ステージング・本番

環境分離の3階層を明確にする。開発環境はフル機能・自由度高い、ただし機密データは入れない。ステージング環境は本番に近い、制御強め。本番環境はAIエージェント直接アクセス禁止、必ず人間が承認。これら3階層を明確に分けることで、リスクを段階的に管理できる。「開発と本番が同じ環境」は最悪の状態で、必ず分離する。AIエージェントは開発環境では自由に動かし、本番環境では絶対に直接触らせない原則を徹底する。本番リリースは必ずPR→人間レビュー→マージというフローを通す設計が、長期運用の前提条件だ。

📊 経営判断のコツ：「本番AIアクセス禁止」を経営方針として明示する。CTO・情シス・現場で共通認識を作ることが、事故防止の前提。

6. 権限設計の4原則

権限設計の原則は4つ。最小権限で必要最小限の権限のみ、「とりあえず全権限」を避ける。最小範囲で必要なファイルだけアクセス、全リポジトリへのアクセスは避ける。人間承認の組み込みで不可逆操作は必ず人間、高リスク操作も同様。監査ログで何をしたか追跡可能に。これら4原則を守ることで、権限による事故を大幅に減らせる。「便利だから」「面倒だから」で原則を曲げると、半年〜1年後に重大事故が起きる確率が高くなる。組織として4原則を徹底することが、CTOの責任だ。

⚠️ 注意：4原則のうち「最小権限」は最も忘れられやすい。「便利だから全権限」が最大の事故原因。

7. MCP連携時の権限管理

MCP連携時は各MCPごとの権限を細かく管理する。GitHub MCPは読み取りのみvs書き込み可、Slack MCPは閲覧のみvs投稿可、DB MCPは参照のみvs更新可。推奨設定は「まず読み取りのみから始める、信頼ができてから書き込み拡大」。MCPの権限を最小化することで、AIエージェント経由での外部システムへの影響を限定できる。「便利だから書き込み権限も付与」は事故の温床で、必要最小限から始めて段階的に拡大する設計が安全だ。MCP接続情報の管理（APIトークン・OAuth）も、認証情報管理の延長で厳格に行う必要がある。

💡 ポイント：MCP権限は「最初は厳しく、徐々に緩める」が原則。逆方向（最初は緩く、事故が起きたら厳しく）は失敗パターン。

8. インシデント時の対応4ステップ

インシデント発生時は4ステップで対応する。即時停止で異常検知時の自動停止、アクセス権剥奪。原因調査で監査ログから追跡、根本原因の特定。復旧でバックアップからの復旧、環境再構築。再発防止で規約・権限見直し、監視強化。これら4ステップをプレイブック化しておくことで、インシデント時に迅速に対応できる。「事故が起きてから対応を考える」では時間がかかりすぎ、被害が拡大する。インシデント対応プレイブックを最初から整備し、四半期に1回は訓練を行う運用が望ましい。CTO・情シス・経営層の連携体制も事前に決めておく。

📊 経営判断のコツ：インシデント対応プレイブックを四半期に1回訓練する。実際の事故時に動ける組織にするには訓練しかない。

9. ガバナンス文書5種

整備すべきガバナンス文書は5種類。AI利用ポリシー、サンドボックス設計書、権限管理ガイドライン、インシデント対応手順、監査ログ仕様。これら5文書が揃うことで、組織のガバナンス体制が文書化される。監査・取締役会対応・規制業界での取引条件など、外部からの説明責任を果たすために必要だ。「整備するのが面倒」と思う組織が多いが、整備しないことで失う信頼・取引機会のほうが圧倒的に大きい。CTOと情シス・法務責任者が連携して、半年〜1年で5文書を整備する計画を立てる。

⚠️ 注意：5文書を「形だけ整備」しても意味がない。実際の運用に組み込まれていることが重要で、文書と運用の整合を半年に1回確認する。

10. 経営観点での重要性

なぜサンドボックス・権限設計が経営マターか3つの理由がある。一度のインシデントで信頼失墜 ― 顧客・取引先・株主からの信頼回復は何年もかかる。監査・取締役会対応に必須 ― ガバナンス整備の証拠として求められる。規制業界では取引条件 ― 整備されていないと取引停止リスク。投資対象は3領域、自動化ツール（DLP・監査）、教育プログラム、インシデント対応体制。これら3領域への継続的投資が、AIDD組織の生命線になる。「便利」を追求するだけでは持続可能な組織にならず、「安全」とのバランスを経営層が主導することが必要だ。

💡 ポイント：「便利さ」と「安全性」を両立させるには、経営層が継続的に投資する判断が必要。CTO単独では完結しない領域。

まとめ

Claude Codeのサンドボックスと権限設計は、便利さと安全性のバランスを取る根幹だ。3層構造（ディレクトリ・コマンド・ネットワーク）で多重防御を構築し、信頼できるディレクトリ設定・危険コマンド制御・環境分離（開発・ステージング・本番）で組織を守る。権限設計は4原則（最小権限・最小範囲・人間承認・監査ログ）で運用し、MCP連携時も「まず読み取りのみから始める」という慎重なアプローチを取る。インシデント対応4ステップ（即時停止・原因調査・復旧・再発防止）をプレイブック化し、ガバナンス文書5種（ポリシー・サンドボックス・権限・インシデント・ログ）で文書化する。経営観点では信頼失墜リスク・監査対応・取引条件の3点で重要マターだ。CTOと情シス・法務・経営層の連携で、長期的な安全運用を実現する。

サンドボックス・権限設計チェックリスト

• [ ] 4リスク（誤削除・本番アクセス・機密アクセス・暴走API）を組織で認識している
• [ ] 3層構造（ディレクトリ・コマンド・ネットワーク）でサンドボックスを設計している
• [ ] 信頼できるディレクトリ・禁止ディレクトリが設定されている
• [ ] 危険コマンドのホワイトリスト・確認モードが運用されている
• [ ] 開発・ステージング・本番の環境分離が明確
• [ ] 権限設計4原則（最小権限・最小範囲・人間承認・監査ログ）を守っている
• [ ] MCP権限が最小化され段階的に拡大している
• [ ] インシデント対応4ステップのプレイブックがある
• [ ] ガバナンス文書5種が整備されている
• [ ] 経営層がサンドボックス・権限設計の重要性を認識している

IT COMPASSのAI駆動開発支援

IT COMPASS では、CTO経験者が外部CTO・技術顧問として、Claude Codeのサンドボックス・権限設計を伴走支援しています。

支援できること

• 🛡 サンドボックス・権限設計：3層防御の整備、4原則による権限設計
• 🚨 インシデント対応プロセス整備：監査ログ・通報・調査フロー、4ステッププレイブック
• 🤖 Claude Code導入支援：CLAUDE.md・SKILL.md・Hooksの統合運用
• 🛡 ガバナンス・セキュリティ整備：AI利用ポリシー、権限設計、知財・契約ルール
• 📈 経営会議への定例参加：取締役会・経営会向けのKPI設計と進捗レポート

こんな方におすすめ

• AIエージェントの暴走リスクを管理したいCTO・情シスの方
• サンドボックス設計をゼロベースで作りたいセキュリティ責任者の方
• 監査・取締役会向けに権限設計を説明したい経営層の方

お問い合わせ

スポット相談（1回／契約不要・最短当日）から、月額契約での継続伴走まで、フェーズに応じて柔軟に対応します。

👉 IT COMPASS お問い合わせフォーム

経営と技術の両面から、御社のAI駆動開発を一緒に設計しましょう。

監修者

西脇　靖紘（lanitech合同会社 代表取締役CEO 兼 CTO）

「テクノロジーで人と社会をつなぐ」をミッションに、企業のDX推進・AI導入支援から、デジタル教育・地域共創まで幅広く活動。エンジニアとしての現場経験と経営視点を活かし、外部CTO・AIコンサルティングなどを通じて企業のデジタル変革を支援している。著書はオライリー・ジャパンから複数刊行。

 
lanitech合同会社 webサイト