Claude Codeを安全に使うための設計思想
── 信頼境界の引き方と守り方

はじめに ── Claude Codeはもう「コーディングだけのツール」ではない

Claude Codeは、Anthropic が開発するAIを活用したコーディングアシスタントです。「code」と名前についていますが、実体は「目的を伝えると、自分で計画してツールを使い、自律的に作業を進める汎用エージェント」です。コーディングだけではなく広くいろいろな業務を任せることができるため、利用者はエンジニアだけでなく、普段、コードを書かない非IT部門の方にまで広がっています。文書ファイルを直接編集して文章の執筆や整形もできますし、フォルダやファイルの整理や、インターネット上の情報をリサーチしたり、MCP(Model Context Protocol)を通してクラウドサービスを操作することも可能です。

なぜセキュリティが課題になるのか

例えばClaude Codeは、業務を遂行するために以下のような操作が可能です。

• ファイル読み取り: ローカルのコード、設定、認証情報、シェル履歴
• コマンド実行: cat、curl、git、npm、docker、ほぼ何でも
• ネットワーク通信: WebFetch、curl/wget、MCP経由の外部API呼び出し
• 永続化機構へのアクセス: cron、systemd、シェル起動ファイル
• スケジュール実行: Claude自身が定期タスクを登録できる

これらは業務を自動化する強力な手段である一方、裏を返せば、攻撃者にとっても魅力的な操作経路です。本来の業務に使われる能力と、悪用されうる能力は表裏一体であり、Claude Codeが意図しない動作をすればセキュリティインシデントへ直結します。

2種類のリスク

1. 外部からの敵対的脅威 ── 攻撃者が意図を持ってClaude Codeを誤動作させるケース。間接プロンプトインジェクション、悪意あるパッケージ・MCPサーバーの混入、公開されたレポジトリのCLAUDE.mdに仕込まれた指示などが代表例。
2. Claude自身の判断ミス ── 攻撃ではなく、LLMの確率的挙動として現れるリスク。幻覚、誤解などにより、重要なファイルの削除など意図しない操作が発生するケース。

本記事で紹介する安全設計は、確率的に動くLLMに依存しすぎないことがポイントです。「悪意ある指示に乗って破壊する」のも「うっかり間違って破壊する」のも、「予測不能な挙動の発現」として安全に対処します。自律的に動くエージェントに何を許し、何を許さないかを整理し、決定論的な制御によってそれを実装します。

1. 信頼境界フレームワーク

信頼の根拠は「決定論性」

CLAUDE.mdに「本番DBには絶対に書き込まないで」と書いたり、会話の冒頭で「破壊的なコマンドは実行しないで」などと書くとたいていClaudeはその指示に従います。ところが、ある日Web上で読み込んだ文書に悪意ある指示が紛れていた場合や長い対話の中で文脈を見失った瞬間など、当初の指示が9回守られても、10回目に守られないかもしれません。そこで、「信頼の根拠にできるのは決定論的に動くものだけ」という原則を設定します。

Claudeおよび Claudeによって変更できる設定を「信頼できないもの」として扱う

Claudeが変更できるもの ＝ 信頼できない側
Claudeが変更できないもの ＝ 信頼できる側

制御の方向は一方通行です。信頼できる側のルールが、信頼できない側の挙動を制約するのは問題ありません。しかし逆向きを許すと、信頼そのものが崩れます。信頼できる側のルールに「認証情報の読み取り禁止」「外部送信禁止」が設定されていれば、Claudeがどう判断しようと実行されません。最終的な決定権はClaudeでなく人間が事前に定義したルールとなります。

2. 信頼できる側で何を実現するか

信頼できる側に置く仕組みは、主に3つの機能で構成します。止める／記録する／守る、です。

（1）止める ── 危険な操作のブロック

• データ漏洩の遮断 ── 機密情報の読取（.env、SSH鍵、APIキー等）と外部への送信をブロック。
• 破壊的操作の禁止 ── 特定フォルダやDBのデータ削除（rm -rf、DROP TABLE）をブロック。
• パッケージ取り込みの制限 ── npm install/pip install の直接実行を禁止し、悪意あるパッケージの導入をブロック。

settings.jsonのdenyルールで機械的にブロックし、askルールで操作可否をユーザに確認します。CLAUDE.mdはLLMが参照する情報であり、信頼できない側に分類します。厳格に止めるべき要件はsettings.jsonに、AIのよりどころとなる作法はCLAUDE.mdに、という使い分けです。

（2）記録する ── 全操作の監査ログ

PostToolUse hookを使い、どんなBashコマンドを実行したか、どのファイルをReadしたか、どこへWebFetchしたか等をログに残します。

（3）守る ── 仕組み自身の保護

「止める」「記録する」を記述するsettings.jsonなどのファイルを保護します。Claudeがこれらを書き換えられると、信頼境界が崩れます。

3. 信頼境界を守り抜く ── 防御の仕組みを改ざんから守る

denyルールは有効ですがバグや迂回の可能性が残ります。OSのファイル権限はClaude Codeの実装と独立して機能するためこれを活用します。「多層防御」の考え方の一例です。第1層ではsettings.jsonに、防御本体である設定ファイルへの書き込みや権限変更の操作をdenyルールとして記述。第2層では、ファイルの所有者をClaudeと別にし、上位ディレクトリも含めて書き込み禁止にします。

4. 最後の信頼境界 ── サンドボックスで全体を囲う

これまでの対策に加えて、Claude Codeのもう一段外側に、サンドボックスという最後の信頼境界を置きます。環境が隔離されていれば、被害はその中だけに閉じ込められます。内側の対策がすべて破られても、外側にある重要なファイル、認証情報、ネットワーク設定にClaudeは到達できません。決定論的な仕組みの最後の砦です。

まとめ

1. 信頼境界をどう引くか ── Claudeは確率的なので信頼できない側に置き、信頼できる側のルールが挙動を制約する
2. 信頼できる側で何をするか ── 止める／記録する／守る の3機能を実装する
3. 信頼できる側をどう守り抜くか ── 書き換え禁止の設定 ＋ OS権限でファイルと親ディレクトリを守る
4. 最後の信頼境界としてサンドボックスで全体を囲う

完璧な防御は存在しませんが、「どこで止められるか」「どこは止められないか」を確認しながら設計・実装しておくことが、Claude Codeを安心して使うための土台になります。この考え方はAIエージェントを利用する上での1つの設計思想として活用できると考えています。

では、また次の記事でお会いしましょう。