Claude Code をチームに展開しようとすると、最初に出てくる質問はだいたい同じです。「これ、ソースコードや顧客情報が漏れたりしないですよね」。便利なのは分かっているけれど、責任を背負う側からすれば不安が先に立ちますよね。

私自身、社内ガイドラインを作る側として何度もこの相談を受けてきました。結論から言うと、Claude Code は「素のまま」配るとリスクが高い一方、最低限のガードレールを敷くだけで実用レベルの安全性は確保できます。

この記事で分かること

Claude Code を社内導入するときに最初に整えるべき5つのガードレールの全体像
.claudeignore や settings.json を使った具体的な設定例と書き方の勘所
「設定したつもり」で実は漏れているという、運用後に気付きがちな落とし穴と対策
個人開発と社内利用で考え方をどう切り替えるべきか、判断軸のチェックリスト

なぜ「個人で使えている」だけでは危ないのか

個人開発で Claude Code を快適に使っている人ほど、社内導入時に油断しがちです。個人なら漏れて困るのは自分の OSS リポジトリだけかもしれませんが、社内では顧客データ、契約情報、未公開の仕様書がリポジトリ近辺に同居していますよね。

特に注意したいのは、Claude Code がエージェントとして「賢く文脈を集めてくれる」点です。便利さの裏返しで、.env の中身や secrets/ 配下のファイルを「親切に」読み込み、要約やコメントとしてプロンプトの一部に載せてしまう経路ができてしまいます。ガードレールは、この「親切すぎる文脈収集」を意図的に制限するための仕組みだと考えると腑に落ちやすいでしょう。

ガードレール1：`.claudeignore` で読み取り対象を明示的に絞る

最初の一手は読み取り範囲の制御です。.gitignore と似た書式で、Claude Code に「ここは見ないでね」と伝えるファイルを置きます。

下の例は、私が新規プロジェクトに必ずコピーしているテンプレートです。秘密情報の典型的な置き場と、ローカル生成物をまとめて除外しています。

# .claudeignore
.env
.env.*
secrets/
credentials/
**/*.pem
**/*.key
**/id_rsa*

# 個人情報を含みやすい場所
data/raw/
data/customer/
logs/

# 巨大かつ機密になりがちなダンプ
dumps/
backups/

ポイントは、「漏れたら困るもの」ではなく「業務上 Claude に読ませる必要がないもの」 という基準で書くことです。前者で書こうとすると永遠に網羅できませんが、後者なら判断が早く、結果として漏洩経路もまとめて閉じられます。

ガードレール2：シークレットはリポジトリの外に追い出す

.claudeignore で除外しても、開発者がうっかり .env をリポジトリ直下に置き続ければリスクは残ります。そもそも秘密情報をリポジトリの中に置かない構造にしておきましょう。

具体的には、シークレット参照をリポジトリ外パスや 1Password CLI、direnv 経由に寄せる方法が安全です。下のコードは、開発者ローカルで direnv を使ってシークレットを差し込む例です。

# .envrc(リポジトリにコミットしてよい)
# 実体はホームディレクトリ配下に置く
dotenv_if_exists ~/.secrets/myapp.env

# 1Password CLI を使う場合
export DATABASE_URL="$(op read 'op://Dev/myapp/database_url')"

.envrc 自体はリポジトリに含めても安全で、シークレットの実体は ~/.secrets/ や 1Password の中にしか存在しません。Claude Code が .envrc を読んでも、漏れるのは「参照経路」だけで値そのものは漏れない、という構造になります。

ガードレール3：ツール権限を段階的に許可する

Claude Code は便利な反面、Bash ツールを通じて任意コマンドを実行できます。ここを無制限にしておくと、curl で外部へデータを送る経路がフリーパスになってしまいます。

社内配布時は、~/.claude/settings.json に 最小許可セット をテンプレートとして配るのがおすすめです。

{
  "permissions": {
    "allow": [
      "Read",
      "Edit",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(npm test:*)"
    ],
    "deny": [
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Bash(scp:*)"
    ]
  }
}

allow を狭く、deny で外向き通信系を塞ぐのが基本姿勢です。「不便だったら開発者がチケットで申請する」というフローにしておくと、現場の声に合わせて緩める判断が記録として残るのもメリットですね。

ガードレール4：CLAUDE.md にチーム共通の禁止事項を書く

CLAUDE.md は Claude Code が常時参照する「チームの掟」を書く場所です。技術スタックだけでなく、してほしくない行動 を明示しておくと、エージェント側の暴走をかなり抑えられます。

# CLAUDE.md（抜粋）

## 取り扱い禁止
- `data/customer/` 配下のファイルは内容を絶対に読み込まない
- 顧客名や社内案件コードを生成物に含めない
- 外部APIへのリクエストは事前に人間の許可を得る

## レビュー前提
- AIが生成したコードは必ず `ai/` プレフィックスのブランチに置く
- マージ前に最低1名のレビューを必須とする

ここで重要なのは、「やってよいこと」と「やってはいけないこと」を両方書くことです。禁止だけだと萎縮し、許可だけだと暴走します。読みやすさを優先して、箇条書き＋短文で書くのがコツです。

ガードレール5：AI 生成差分のレビュー導線を作る

最後は技術ではなく運用の話です。Claude Code の出力が混じったコミットは、レビューで普段と同じ集中力では読みきれません。私のチームでは次のルールを敷いています。

AI が手を入れた変更は ai/ プレフィックスのブランチに分離する
PR テンプレートに「使用した AI ツール」「機密情報を含めていないことの確認」のチェックを入れる
月1回、git log --grep で ai/ ブランチを棚卸しし、定期的に振り返る

地味ですが、運用初月の事故はだいたいレビュー導線の不整備が原因です。技術的なガードレールと同じくらい、「人の目が必ず通る経路」 を整える価値があります。

まとめ

最後に、本記事の要点を振り返ります。

Claude Code の社内導入は「便利さ」より先に「親切すぎる文脈収集」を制御する発想で設計しましょう
.claudeignore は「漏れたら困るもの」ではなく「読ませる必要がないもの」基準で書くと過不足が出にくいです
シークレットはそもそもリポジトリの外へ追い出し、direnv や 1Password などの参照経路に置き換えましょう
settings.json で Bash 系の権限を絞り、外向き通信を deny に入れておくと事故率が大きく下がります
CLAUDE.md と PR テンプレートで「人の目を通す導線」を整え、技術と運用の両輪でガードレールを成立させましょう

次のステップとしては、自社のリポジトリで .claudeignore を1本書いてみることをおすすめします。そこから足りない設定が自然と見えてきますし、レビュー時に議論する叩き台にもなります。

ここまで読んでいただきありがとうございます。
こちらの記事が何かのお力添えになればいいなと思います。
今後もよろしくお願いします。