【2026年版】Claude Codeの使い方と安全対策｜セキュリティ設定ガイド7選

Claude Codeは強力な開発ツールだが、自動化には相応のリスクが伴う。特に外部データやWebアクセスを伴う運用では、予期せぬ挙動やプロンプトインジェクションへの備えが不可欠だ。Claude Codeで1人SaaS開発を行う中で痛感した、安全に運用するための実践的ガイドをここにまとめる。

1. settings.jsonによるdenyルール設定

Claude Codeの挙動を制限する最も基本的な手段が、プロジェクト直下の.claude/settings.jsonだ。特定のツールや操作を禁止することで、意図しないファイル読み込みや外部通信を物理的に遮断できる。

メリットはGit管理によりチーム全体で権限設定を統一できる点にある。一方で、Pythonスクリプトを介したファイル操作など、一部の実行経路を完全に塞ぐことは困難だ。これだけで万全とは考えず、あくまで防壁の一部と捉えるのが賢明だ。

2. claude-securityプラグインによるスキャン

Anthropic公式のセキュリティスキャンプラグインを活用すれば、設定ファイルやエージェントの挙動を網羅的に検証できる。セッション内で完結する仕組みのため、外部プロセスを立てる手間がない。

公式の検証ロジックを用いることで、人間が見落としがちな設定の不備を可視化できる。ただし、スキャンには一定のトークンコストと時間がかかるため、定期的なメンテナンスの一環として実施するのが効率的だ。

3. 送信前のattempt記録とLedger運用

外部への書き込みを伴う操作には、送信前に試行（attempt）を記録する台帳（Ledger）を作成する。これにより、クラッシュやネットワークエラーが発生しても、どこまで処理が進んだかを確認できる。

この仕組みがあれば、自動リトライによる重複送信を確実に防げる。タイムアウトが発生した際には、人間が状況を把握するまで処理を自動停止させる運用を徹底する。

4. 外部データに対するUntrusted扱い

Webサイトや外部APIから取得したデータは、常にプロンプトインジェクションの脅威があると見なす必要がある。モデルの判断に依存せず、コード側のツール実行層で許可リストを厳格に管理する設計が重要だ。

外部文字列をそのまま指示として流し込まない工夫が、強固な防御を実現する。ただし、過剰なブロックが発生して作業が中断されることもあるため、バランスを見極める必要がある。

5. 本番環境と同一条件でのテスト

ローカル環境でのテストだけで満足してはいけない。本番と同じスケジューラ、ユーザー権限、ロケール、文字コードでテストを実施するのが鉄則だ。

特に文字コード起因の失敗はローカルで再現しにくい。実環境での動作確認を終えるまでは、テスト済みとは呼べないはずだ。

6. ドライランの徹底

チェックリストの項目が一つでも満たされない場合は、必ずドライランで実行する。自動化のミスによる後始末は非常にコストが高い。安全が確認できるまでは、書き込みを伴う操作を禁止するルールを設けるのが一番の近道だ。

7. API呼び出しの監視と上限設定

コード側での制御だけでなく、プロバイダーの管理画面でハードリミットを設定する。予算超過の1週間前には警告が届くよう運用を組む。コードのバグによる予期せぬ高額請求を避けるための最終防衛線だ。

しんたろー：
Claude Codeでコードを書く身からすると、やはりsettings.jsonでの制限が一番の基本だ。
理由はシンプルで、設定ファイルとしてGit管理できるからチーム開発でも抜け漏れがなくなる。

しんたろー：
外部データへの慎重な扱いは、実際に自動化を組んでいると重要だと実感する。
モデルの判断に全てを委ねず、人間が介入できる粒度でタスクを分割するのが安全策だ。

8. 作業の人間による引き取り単位の分割

エージェントの処理を、途中で止まっても人間が復旧できる小さな単位に分割する。シーケンスを長くしすぎないことで、ブロック発生時のリカバリーコストを最小化できる。

FAQ

Q1: settings.jsonのdenyルールで.envファイルを完全に守れるか

A1: 完全には守れない。denyルールはClaudeが標準的に使用するツールを制限するものであり、Pythonスクリプト内でファイルを開くような操作までは防げない可能性がある。機密情報は環境変数や専用のシークレット管理サービスに分離し、プロジェクトフォルダに直接置かない運用が必要だ。

Q2: プロンプトインジェクションを防ぐにはどうすればいいか

A2: 外部から取得した文字列を「指示」として解釈させないことが重要だ。システムプロンプトでの指示だけでなく、コード側でツール実行の許可リストを厳格に管理し、モデルが判断した内容であっても、許可されていない操作は実行されない仕組みを構築する。

Q3: claude-securityプラグインは毎回実行すべきか

A3: 設定変更時や、新しいエージェント・ツールを導入したタイミングで実行するのが効果的だ。スキャンにはトークンコストと時間がかかるため、CI/CDパイプラインに組み込むか、週次などの定期的なメンテナンスの一部として実施する。

Q4: エージェントが勝手に動いて失敗した時の対処法は

A4: まずは送信前にattemptを記録する仕組みを導入する。これにより、どこまで処理が完了し、どこで停止したかがログで明確になる。また、自動リトライを安易に行わず、失敗した場合は必ず人間がログを確認してから再開する運用フローを徹底する。

Q5: 初心者がまずやるべきセキュリティ対策は

A5: まずはプロジェクトの.claude/settings.jsonを作成し、必要最小限のツールのみを許可することから始める。また、外部への書き込みを伴うエージェントには、必ずドライランの工程を挟み、いきなり本番環境へ書き込ませないルールを設けるのが重要だ。

まとめ

Claude Codeは賢いが、自動化の責任は常に開発者にある。今回紹介した7つの対策を組み合わせ、安全な開発環境を構築する。まずはsettings.jsonの設定から見直すのが賢明だ。