Claude Code のセキュリティ設計｜シークレット・本番DBに触れないガードレール

Anthropic がリリースした Claude Code は、ターミナル上で動作し、リポジトリ全体を理解してコードの作成・テスト・デバッグを自律的に行う強力なコーディングエージェントです。しかし、その強力な権限ゆえに、開発者が最も懸念するのが「セキュリティ」です。

「不用意に .env ファイルを読み取られて、API キーが外部に送信されないか？」「本番環境のデータベースを操作するスクリプトを勝手に実行されないか？」といった不安は、実務担当者として当然の反応です。本記事では、Claude Code を実務で安全に運用するための、シークレット保護と本番環境へのガードレール（概念と設定）について、IT 実務者の視点から徹底解説します。

Claude Code の動作原理とデータ露出のリスク

Claude Code は単なるチャット AI ではなく、あなたのローカルマシン上で CLI（Command Line Interface） として動作します。これが意味するのは、Claude Code は「実行ユーザーと同じ権限」でファイルシステムやネットワーク、各種コマンドにアクセスできるということです。なお、2025年5月のGA以降、Claude Code は CLI のほかデスクトップアプリ（Mac/Windows）、Web（claude.ai/code）、VS Code 拡張、JetBrains 拡張からも利用できます。

CLI ツールとしての権限とリスク

Claude Code を起動すると、カレントディレクトリ以下のファイル構成をスキャンし、必要に応じて cat や ls、さらには npm test や git commit といったコマンドを自ら生成して実行します。ここで発生しうる主なリスクは以下の 3 点です。

• 機密ファイルの読み取り: .env や config/secrets.yml など、認証情報が含まれるファイルがコンテキストとして Anthropic のモデルに送信されるリスク。
• 破壊的なコマンドの実行: AI がバグ修正の過程で、意図せず rm -rf や docker-compose down -v（ボリューム削除）などの破壊的コマンドを提案・実行するリスク。
• 本番データへのアクセス: ローカル環境から本番 DB へのトンネルが張られている場合、AI が本番データをクエリしたり、削除したりするリスク。

主要 AI エージェントツールのセキュリティ設計比較

Claude Code が他の AI ツールとどう違うのか、セキュリティと権限の観点から比較表にまとめました。

Claude Code の特徴は、「ターミナルを自ら操作する」 という点にあります。この自律性が高いからこそ、後述する「ガードレール」の設計が不可欠になります。特に、複数の SaaS を組み合わせてデータ基盤を構築している場合、認証情報の扱いは極めて慎重に行う必要があります。

例えば、広告データの自動最適化のために BigQuery と連携しているような環境では、サービスアカウントキーの露出は致命的です。こうした基盤構築の全体像については、以下の記事も参考になります。

広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャ

実践：シークレットと本番DBを守る「3層のガードレール」

Claude Code に「やっていいこと」と「やってはいけないこと」を教え込み、物理的・論理的に制限をかける手法を紹介します。

第1層：物理的隔離（.gitignore と permissions.deny）

最も基本的かつ強力な対策は、Claude Code の「視界」から機密ファイルを消すことです。Claude Code はデフォルトで .gitignore に指定されたファイルを尊重しますが、機密ファイルを確実に読み取らせないためには、.claude/settings.json の permissions.deny に Read(...) ルールを追加します（deny は allow より優先されます）。なお、かつて流布した .claudeignore は公式機能ではなく、読み取りを確実に止められない点に注意してください。

設定手順：

プロジェクトの .claude/settings.json に、以下のような permissions.deny ルールを記述します。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./**/*.pem)",
      "Read(./**/*.key)",
      "Read(./logs/**)",
      "Read(./dumps/**)",
      "Read(./sql_exports/**)"
    ]
  }
}

これにより、API キーやダンプを含むファイルを Claude Code が読み取ろうとしても、deny ルールで拒否されます。node_modules/ や dist/ のように、機密ではなくコスト・コンテキスト節約のために外したいだけのものは、.gitignore に入れておけば既定で読み取り対象から外れます。

第2層：論理的制約（CLAUDE.md / AGENTS.md）

Claude Code は、リポジトリ内に CLAUDE.md というファイルが存在する場合、それを「プロジェクトの憲法」として読み取ります。ここで AI の振る舞い（ルール）を明文化できます。

CLAUDE.md への記述例：

セキュリティ・ガイドレール

ローカル環境の .env ファイルを絶対に読み取らないこと。

データベース操作（psql, mysql コマンド等）を行う際は、必ず SELECT クエリのみに留め、UPDATE/DELETE/DROP は禁止する。

本番環境（production）へのデプロイコマンドや、本番 DB への接続が予想されるポートフォワードコマンドを実行してはならない。

新しいパッケージをインストールする際は、必ず脆弱性がないか確認すること。

コーディング規約

テストコード（Jest）が存在しない機能追加は認めない。

型安全性を重視し、TypeScript の 'any' 使用は原則禁止。

このように、指示（System Prompt）の一部としてガードレールを組み込むことで、AI が自律的に動く際の「倫理規定」を設けることができます。

第3層：実行の承認フロー（ReadOnly モードと承認制）

Claude Code には、コマンド実行の前に必ずユーザーの承認を求める仕組みが備わっています。さらに安全に運用するために、以下のフラグや設定を活用しましょう。

• –read-only フラグ:
  claude --read-only で起動すると、Claude Code はファイルの編集やコマンドの実行ができなくなり、コードの分析と提案のみを行うようになります。初めて触るリポジトリや、大規模なリファクタリングの方向性を相談する際に有効です。
• 権限の最小化:
  Claude Code を実行するターミナルのユーザー権限自体を制限します。例えば、本番環境への ssh 権限を持たない専用のローカルユーザーで作業する、あるいは Docker コンテナ内で Claude Code を動かすといった手法です。

特に、SaaS のアカウント管理や退職者のアクセス権削除を自動化しているような組織では、AI エージェントに対しても「最小権限の原則」を適用することが重要です。この考え方は、以下のアイデンティティ管理（IDAM）の文脈と共通しています。

SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

シーン別：Claude Code を安全に運用するワークフロー

では、具体的な実務シーンで Claude Code をどう使うべきか、具体的なファイル構成と手順を見ていきましょう。

1. 新規機能開発における「テスト駆動型」ガードレール

エンジニアが Claude Code を開き、「新しい API エンドポイントを追加して」と依頼するシーンを想定します。この際、リポジトリに AGENTS.md を配置し、Claude Code のサブエージェント（特定の役割に特化した AI）に以下のタスクを割り振ります。

• 役職：QA Agent
• タスク：メインエージェントが書いたコードに対して、カバレッジ 100% のテストコードを作成し、npm test を実行してパスすることを確認するまで PR（プルリクエスト）の作成を許可しない。

これにより、AI が「動けばいい」という粗悪なコードを本番リポジトリに混入させるのを防ぐ論理的なガードレールが機能します。

2. 経理・バックオフィス自動化スクリプトの作成

非エンジニアの情シス担当者が、CSV データの変換スクリプトを Claude Code で作成する場合を想定します。例えば、「楽楽精算のデータを freee 会計用に変換する Python スクリプト」を作成させるシーンです。

ワークフロー：

1. リポジトリに data/sample.csv（マスキング済みのダミーデータ）を置く。
2. .claude/settings.json の permissions.deny に "Read(./data/real_*.csv)" を追加し、本番データが読み取られないようにする。
3. Claude Code を起動し、「sample.csv の形式を分析して、freee 用のインポート形式に変換するスクリプトを scripts/convert.py として生成して」と指示。
4. 生成されたスクリプトをローカルで実行し、期待通りの CSV が出るか目視で確認。

このように、「本物のデータは見せず、構造（ダミー）だけ見せる」 という運用が、セキュリティと効率を両立させるコツです。この手の自動化については、以下の記事で解説しているアーキテクチャも、AI 活用の土台として非常に相性が良いものです。

楽楽精算×freee会計の「CSV手作業」を滅ぼす。経理の完全自動化とアーキテクチャ

組織規模・業種別 × Claude Codeセキュリティ設計の必要レベル × 優先設定項目 早見表

前のセクションでシーン別のClaude Code安全運用ワークフローを説明しましたが、セキュリティ設計の厳格さは「組織規模」「業種・取り扱うデータの機密性」によって必要なレベルが異なります。5名のスタートアップと500名の金融機関が同じセキュリティ設計でClaude Codeを運用する必要はなく、過剰なセキュリティ設計は開発効率を下げます。一方、規制業種（金融・医療・法律）では最低限の設定を怠ると法令違反になるリスクがあります。以下の表は組織規模・業種別の設計指針をまとめたものです。

この表でClaude Codeのセキュリティ設計において組織規模を問わず共通する最重要原則が「本番データ・シークレットとClaude Codeのコンテキストを物理的に分離する設計」です。Claude Codeが読み込めるファイルの範囲を意図的に制限すること（.envファイルの除外・本番接続情報の別管理）だけで、セキュリティインシデントの8割以上のリスクを低減できます。高度な監査ログ・アクセス制御の整備は中長期で取り組むとして、「渡してはいけないデータの明示」という最も簡単な対策を最初に実施することが、Claude Codeの安全な組織展開の出発点です。

よくあるエラーと対処法

Claude Code を運用中に直面しやすいセキュリティ関連のトラブルと解決策をまとめました。

• エラー: “Permission denied” でファイルが読み取れない
  • 原因: OS レベルのファイル権限不足、または .claude

    本記事で解説した3層のガードレール（permissions.deny・CLAUDE.md・ReadOnlyモード）を自社のリポジトリ構成に合わせて実装したい場合や、開発チームへの展開方針を固めたい場合は、Claude Code 導入支援でPoCの進め方を一緒に設計できます。

    生成AIの法人導入・セキュリティ設計のご相談

    ChatGPTやClaudeなど生成AIのプラン選定・セキュアな全社導入・権限／ログ設計を、貴社の体制に合わせて整理します。すでに導入済みの環境について『この設計で問題ないか』を確認したい、という導入前後のセカンドオピニオンにも対応しています。

    生成AI導入・セキュリティ支援を見る → セキュリティ設計の支援を見る →