GitHub Searchで path:CLAUDE.md と打ってみてください。
5万件以上のリポジトリで、CLAUDE.mdがそのまま公開されています。中には社内の命名規則、本番DBのスキーマ、検証用APIキーの断片、未公開製品の内部コードネームまで、本来コミットしてはいけない情報がごっそり露出している例が散見されます。
私もClaude Codeを毎日使っているので分かるのですが、CLAUDE.mdは「AIに渡す自分の取扱説明書」です。プロンプトに毎回書きたくない指示を全部詰め込む。だからこそ、書く内容はどんどん社内ナレッジに寄っていきます。
そして、ほとんどの人がそれを .gitignore に追加していません。
この記事では、なぜCLAUDE.mdをコミットしてはいけないのか、すでに公開してしまったらどう取り消すのか、AI関連で .gitignore に追加すべきファイルは何か、を実例ベースで整理します。
CLAUDE.mdは「あなたのプロンプトそのもの」
CLAUDE.mdが何かを念のため整理します。
これはClaude Codeがプロジェクトルートで自動的に読み込むコンテキストファイルです。グローバル(~/.claude/CLAUDE.md)とプロジェクト単位の2階層で動き、セッション開始時にClaudeが必ず参照します。
つまりCLAUDE.mdに書いた内容は、毎回のClaudeへのシステムプロンプトと等価です。
エンジニアがここに書きがちな情報を並べてみます。
- 社内ライブラリの命名規則
- 本番DBのテーブル構造とリレーション
- 内部API endpoint一覧
- セキュリティポリシー(IPホワイトリスト、認証方式)
- リファクタリング中の領域と現在の作業状態
- 未公開プロダクトのコードネーム
- 検証用のtest credentialやAPIキーの断片
書いている瞬間は「Claudeに渡すだけだから」と思っています。けれど、リポジトリにそのままコミットすれば、それは GitHub経由で全世界に配信されている社内ドキュメント になります。
GitHub Searchで実際に何件出るのか
検証してみました。2026年5月時点のGitHub Searchで以下のクエリを叩いた結果です。
| クエリ | おおよそのヒット件数 |
|---|---|
path:CLAUDE.md |
5万件超 |
path:CLAUDE.md "API" |
1.2万件超 |
path:CLAUDE.md "production" |
7,000件超 |
path:CLAUDE.md "internal" |
4,000件超 |
path:.cursorrules |
3.5万件超 |
path:AGENTS.md |
8,000件超 |
これらの数字には、もちろん「OSSのドキュメント用CLAUDE.md」「サンプルテンプレート」「個人ブログ用」など、漏洩リスクのないものも含まれます。
けれど、path:CLAUDE.md "production" で出てくるリポジトリの中身を眺めると、明らかに業務利用のものが相当数混じっています。本番環境のURL、社内Slackチャンネル名、未公開のAPIスキーマが平然と書かれているものがありました。
私が確認できた範囲だけでも、これは検索結果の 氷山の一角 です。
本記事に具体的なリポジトリ名やURLは載せません。漏洩している側の不利益になるためです。ただし、誰でも同じクエリで再現できます。GitHubアカウントがあれば30秒で確認できる事実です。
漏れているもののカテゴリ分類
実際にGitHub Searchで眺めた範囲で、CLAUDE.mdから漏洩している情報のパターンを5つに整理します。匿名化・抽象化した形で書きます。
カテゴリ1: API endpointと内部URL
## 開発環境
- API: https://api-staging.internal.example.com
- 管理画面: https://admin-dev.example.com
- DB Proxy: db-bastion.aws.internal:5432
社内DNS名や踏み台サーバーのホスト名がそのまま書かれているパターン。攻撃者の偵察フェーズに直結します。
カテゴリ2: 命名規則と内部用語
## 命名規則
- マイクロサービスの接頭辞は `xxx-` (社名の頭文字)
- 内部プロジェクトコード: Project Atlas, Phoenix, Hermes
- DBテーブルは `t_` プレフィックス、ビューは `v_`
社内のコードネームが書かれていると、未発表プロダクトの存在が露呈します。M&A交渉中の案件名が漏れた事例も(国外で)報告されています。
カテゴリ3: 認証・セキュリティ情報
## テスト用credential
- 開発用APIキー: ak_test_xxxxxxxxxxxxx (※ コミット禁止)
- IAM Role: arn:aws:iam::123456789012:role/dev-claude-access
- VPN: 接続後にのみアクセス可能
「※ コミット禁止」と書きながらコミットされているのは皮肉ですが、実例として存在します。AWSアカウントIDだけでも、攻撃者のターゲティングに使えます。
カテゴリ4: ビジネスロジックと業務知識
## 計算ルール
- 月次プラン: ベース料金 + 利用量×単価 - 法人割引(契約年数×2%、最大10%)
- 退会フロー: 30日のクーリングオフ → freeプランへ自動降格 → 90日後に完全削除
料金体系や顧客ライフサイクルがそのまま記述されているケース。競合分析の格好の材料です。
カテゴリ5: 個人を特定し得る情報
## 連絡先
- バックエンド責任者: @yamada (社内Slack)
- インフラ: @sato (PagerDuty escalation)
社内アカウントとロールの紐付けが書かれているパターン。フィッシング攻撃の標的選定に使われます。
なぜ「ローカルだけ」では済まないのか
「CLAUDE.mdは個人のローカル設定だから、リポジトリにコミットする必要なんてない」と私も最初は思っていました。
けれど現実には、以下のような流れでコミットされてしまいます。
- 個人が
git add .で全ファイルをステージしてしまう -
.gitignoreにCLAUDE.mdが入っていないので素通り - PR時にレビュアーも「コンテキストファイルだから親切」と思ってapprove
- mainにマージされ、
git pushで全世界へ
特に問題なのが、チームでClaude Codeを共有しているケース です。「CLAUDE.mdをチームで共有したい」というモチベーション自体は正しい。けれど共有先がpublicリポジトリだと、その瞬間に社内ナレッジが全公開になります。
privateリポジトリでも、退職者がforkして外部にコピーするリスクは残ります。CLAUDE.mdの本質は「Claudeに渡すコンテキスト」であって、「Gitで管理すべきコード」ではありません。
今すぐやるべきこと: .gitignoreに追加するAI関連ファイル一覧
私が現時点で .gitignore に追加することを推奨するパターンを置いておきます。プロジェクトテンプレートに直接コピーしてください。
# === AI assistant context files ===
# Claude Code
CLAUDE.md
.claude/
.claude.json
# Anthropic Agent / Skills
AGENTS.md
.agents/
# Cursor
.cursorrules
.cursor/
# Windsurf
.windsurfrules
.windsurf/
# Aider
.aider*
.aider.chat.history.md
.aider.input.history
# Continue.dev
.continue/
# Codex CLI
.codex/
# GitHub Copilot Workspace
.github/copilot-instructions.md
# 共通の作業メモ・進行状況
MEMORY.md
TODO.md
SCRATCH.md
チームで共有したい場合 は、以下の2層構成にすることを推奨します。
project/
├── CLAUDE.md # ← .gitignoreで除外、個人のローカル設定
├── CLAUDE.shared.md # ← Gitで管理、公開しても問題ない汎用コンテキスト
└── .gitignore
CLAUDE.shared.md には「コーディング規約」「テストの書き方」「PR規約」などの一般的なルールだけを書きます。社内URL、顧客名、未公開製品名は絶対に書かない。これを徹底すれば、共有とセキュリティの両立ができます。
私は CLAUDE.shared.md に書いた内容を、Claude Codeに @CLAUDE.shared.md で都度参照させています。グローバルCLAUDE.md (~/.claude/CLAUDE.md) には個人の作業スタイル、プロジェクトCLAUDE.mdには社内情報、CLAUDE.shared.md には公開可能なルール、という3層分離です。
すでにコミットしてしまった場合の取り消し方
ここからが本題です。.gitignore に追加するだけでは、過去のコミット履歴に残ったCLAUDE.mdは消えません。
git rm --cached CLAUDE.md してコミットしても、git log を辿れば誰でも昔の中身を読めます。GitHubのページからは見えなくても、git fetch --all すれば取れます。
履歴ごと消すには、以下の手順が必要です。
手順1: git-filter-repoでファイルを履歴から除去
# git-filter-repoをインストール (pipまたはbrew)
pip install git-filter-repo
# リポジトリを一旦クローン (--mirrorで全refを取得)
git clone --mirror https://github.com/your-org/your-repo.git
cd your-repo.git
# CLAUDE.mdを履歴から完全に削除
git filter-repo --invert-paths --path CLAUDE.md --force
# 強制push (要管理者権限)
git push --force --all
git push --force --tags
複数ファイルを一気に消すなら、--path を並べて指定します。
git filter-repo \
--invert-paths \
--path CLAUDE.md \
--path .cursorrules \
--path AGENTS.md \
--force
手順2: BFG Repo-Cleanerでも代替可能
filter-repoがどうしても動かない環境では、BFG Repo-Cleaner (rtyley.github.io/bfg-repo-cleaner) を使います。
# javaが必要
java -jar bfg.jar --delete-files CLAUDE.md your-repo.git
cd your-repo.git
git reflog expire --expire=now --all
git gc --prune=now --aggressive
git push --force
手順3: GitHub側のキャッシュ無効化リクエスト
force push しても、GitHubはコミットSHAをしばらくキャッシュします。検索エンジンのキャッシュも残ります。
そこで GitHub Support に「Sensitive Data Removal」のリクエストを送ります。
リクエスト先: https://support.github.com/contact/private-information
書く内容は次のテンプレでOKです。
Subject: Request to purge cached commits
Repository: github.com/your-org/your-repo
Commit SHAs containing sensitive data:
- abc1234...
- def5678...
These commits include internal API endpoints / credentials / project codenames
that were accidentally committed via CLAUDE.md before being removed via
git-filter-repo. Please purge the cached refs and search index.
通常は24〜72時間で対応してもらえます。
漏洩した認証情報そのものは別途ローテーションしてください。 git履歴から消しても、過去にcloneした第三者の手元には残っています。APIキー、内部URL、IAM Roleは「漏洩した」前提で扱うのが安全側の判断です。
手順4: 全メンバーへの再clone通知
force push 後は、すでにcloneしている全メンバーが既存のローカルリポジトリを捨てて再cloneする必要があります。これをアナウンスしないと、誰かが古い履歴をpushし直して台無しになります。
Slack等でアナウンス文を流しておきましょう。
@channel
セキュリティ対応のため、リポジトリの履歴を書き換えました。
以下を実行してください。
cd /path/to/your-repo
cd ..
rm -rf your-repo
git clone https://github.com/your-org/your-repo.git
既存のローカルブランチが残っている場合は、必ず捨てて再cloneしてください。
古いコミットをpushし直すと、対応が無駄になります。
CIで漏洩をブロックする
人間が忘れる前提で、CIで弾く仕組みを入れておきます。pre-commit hook + GitHub Actionsの2段構えがおすすめです。
pre-commit hookの例
.git/hooks/pre-commit (またはpre-commitフレームワークの設定)に以下を追加します。
#!/bin/sh
BLOCKED_FILES="CLAUDE.md|\.cursorrules|AGENTS.md|MEMORY.md"
if git diff --cached --name-only | grep -E "^($BLOCKED_FILES)$" > /dev/null; then
echo "❌ Error: AI context file detected in commit."
echo "These files should be in .gitignore:"
git diff --cached --name-only | grep -E "^($BLOCKED_FILES)$"
exit 1
fi
GitHub Actions側のサーバー側チェック
# .github/workflows/block-ai-context.yml
name: Block AI context files
on: [pull_request]
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Verify no AI context files
run: |
if git ls-files | grep -E "^(CLAUDE\.md|\.cursorrules|AGENTS\.md|MEMORY\.md)$"; then
echo "::error::AI context files must not be committed"
exit 1
fi
pre-commit hookは個人が無効化できるので、必ずサーバー側のチェックを併用してください。
最後に: AIの時代における「コミットしてはいけないもの」
エンジニアの「コミットしてはいけないものリスト」は、AIネイティブ開発の到来で確実に増えました。10年前は .env と秘密鍵だけ気をつければよかったのに、今はAIコンテキスト全般がそのリストに加わっています。
CLAUDE.md、.cursorrules、AGENTS.md、MEMORY.md。これらは便利だからこそ社内ナレッジが集約されやすく、そのまま公開されると最悪のリーク源になります。
書く内容と公開範囲の二段で考えてください。書く内容は便利さ優先で書いていい。けれど公開範囲は .gitignore で厳格に制御する。これだけで、来週の自分が朝のSlackで青ざめる確率は劇的に下がります。
知識を蓄積する仕組みは、漏洩を防ぐ仕組みとセットで揃えて初めて機能します。
詳しいClaude Code運用ノウハウは、Claude Code 完全ガイドにもまとめています。CLAUDE.mdの中身設計、グローバル/プロジェクト/共有の3層分離、チーム運用のパターンを実例つきで書いています。
まとめ
- CLAUDE.mdは「あなたのプロンプトそのもの」。書く内容はどんどん社内ナレッジに寄っていく
- GitHub Searchで
path:CLAUDE.mdだけで5万件以上、社内情報を含むものが相当数混じる -
.gitignoreにCLAUDE.md, AGENTS.md, .cursorrules, .windsurfrules, MEMORY.md などをまとめて追加する - 共有したいルールは
CLAUDE.shared.mdに分離する - すでにコミットしてしまった場合は
git filter-repoで履歴から除去 → force push → GitHub Supportにキャッシュ無効化を依頼 - 認証情報は履歴を消しても「漏洩した」前提でローテーションする
- pre-commit hook と GitHub Actions の2段でCIブロックする
今すぐ git ls-files | grep CLAUDE.md を叩いて、引っかかったら速攻で対処してください。
面白くいきましょう。
