AIコーディングエージェントが2,900万件のシークレットを漏洩させた — MCP設定ファイルセキュリティの盲点

先週GitGuardianが発表した State of Secrets Sprawl 2026 レポートを読んでいて、手が止まりました。GitHubで1年間に検出されたシークレットが2,900万件。しかし本当の問題はその次の一文でした。AIコーディングツールを使用しているリポジトリのシークレット漏洩率が、GitHub全体平均の2倍だというのです。

私は毎日Claude CodeとMCPサーバーを接続して作業しています。正直に言うと、このレポートを読んだ後、まず自分の.claude/ディレクトリとMCP設定ファイルを点検しました。結果的に問題はありませんでしたが、「なぜAIコーディングツールがシークレット漏洩を加速させるのか」という構造的な理由を理解することができました。

AIコーディングツールがシークレット漏洩を2倍にする理由

一般的な開発でシークレットが漏洩する経路は比較的シンプルです。.envファイルを.gitignoreに入れ忘れたり、テストコードにAPIキーをハードコーディングしたり。しかしAIコーディングエージェントを使い始めると、漏洩経路が急激に増えます。

1つ目の問題はコンテキストインジェクションです。 AIエージェントに「このAPIを呼び出して」とリクエストすると、エージェントが生成するコードに実際のAPIキーが含まれることがあります。特にエージェントが環境変数の代わりに値を直接インラインで埋め込むパターンが意外と多いです。人間が書く場合は「これは環境変数に切り出さないと」という習慣がありますが、AIは「動くコード」を最優先で生成します。

2つ目の問題はもっと深刻です。MCP設定ファイルです。 Claude Code、Cursor、WindsurfなどのツールがMCPサーバーに接続する際に使う設定ファイルには、データベース接続情報、APIキー、OAuthトークンが平文で入っています。GitGuardianによると、公開リポジトリのMCP設定ファイルだけで24,008件のユニークなシークレットが発見されました。MCPエコシステムが60日で30件のCVEが報告された攻撃面であることを考えれば驚くことではありません。

// このような設定ファイルがそのままコミットされるケースが数万件
{
  "mcpServers": {
    "database": {
      "command": "mcp-server-postgres",
      "args": ["postgresql://admin:P@ssw0rd123@prod-db.example.com:5432/main"]
    },
    "slack": {
      "command": "mcp-server-slack",
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-your-token-here"
      }
    }
  }
}

このファイルが.gitignoreに入っていなければ、git add -A一発でプロダクションDBのクレデンシャルがGitHubにアップロードされます。AIコーディングエージェントが「このファイルもコミットしますか？」と聞いてきたら、ほとんどの人が「はい」と答えるのが現実です。

実際に点検してみました

自分の作業環境を基準にチェックした項目を共有します。

1. MCP設定ファイルの場所を確認

# Claude CodeのMCP設定ファイルの場所
ls -la ~/.claude/mcp_settings.json 2>/dev/null
ls -la ./.claude/settings.local.json 2>/dev/null

# プロジェクト内のMCP関連設定を検索
grep -r "mcpServers" . --include="*.json" -l

2. .gitignoreの点検

# MCP設定ファイルがgitignoreに含まれているか確認
grep -E "mcp|settings\.local" .gitignore

私の場合、.claude/settings.local.jsonは.gitignoreに入っていましたが、プロジェクト別のMCP設定が別のJSONファイルとして存在するケースがあり、そのファイルは含まれていませんでした。これはすぐに追加しました。

3. Gitヒストリーで既に漏洩したシークレットを検索

# 過去のコミットにシークレットが含まれていたか確認
git log --all --diff-filter=A -- '*.json' | head -20
git log -p --all -S 'SLACK_BOT_TOKEN' -- '*.json'
git log -p --all -S 'postgresql://' -- '*.json'

ここで重要なのは、.gitignoreに追加しても、既にコミットされたファイルはヒストリーに残っているということです。一度でもシークレットがコミットされたなら、キーをローテーションするのが唯一の解決策です。

GitHub MCPサーバーのシークレットスキャニング

3月17日、GitHubがMCPサーバーにシークレットスキャニング機能をパブリックプレビューとして追加しました。AIコーディングエージェントがGitHub MCPサーバーを通じて作業する際、プッシュ前に自動でシークレットを検出してくれる機能です。

設定はGitHubリポジトリのSettings > Code security and analysisで「Secret scanning」と「Push protection」を有効化すれば完了です。既に有効化しているリポジトリであれば、MCPサーバーを通じた作業にも自動適用されます。

個人的にこの機能に期待している理由は、AIエージェントが生成するコードのシークレット漏洩をエージェントワークフロー内でキャッチしてくれる点です。人間がレビューする前にシステムが先に検出してくれるので、「エージェントがコミットしたコードを自分がレビューする」という現実的なワークフローにうまくフィットします。

しかしこれだけでは不十分です

正直に言えば、GitHubのシークレットスキャニングは既知のパターンのシークレットしか検出しません。カスタム内部APIキーや非標準フォーマットのトークンは見逃す可能性があります。そしてGitHub以外のリポジトリ（GitLab、Bitbucket、セルフホスティング）を使っているチームには適用されません。

もう1つ、MCP設定ファイルのクレデンシャル管理のための標準がまだ存在しません。AnthropicやMCPコミュニティから「シークレットはこのように管理してください」という公式ガイドラインがなく、各自で環境変数に切り出したり、シークレットマネージャーを接続したりしている状況です。

私はMCPエコシステムが成熟するためには、設定ファイルのクレデンシャル参照標準が必要だと考えています。Docker Composeのsecrets:ブロックや、KubernetesのsecretKeyRefのようなパターンをMCP設定にも導入すべきです。現在のMCP設定でenv:ブロックを使って環境変数を参照することまでは可能ですが、シークレットマネージャー（HashiCorp Vault、AWS Secrets Managerなど）との統合は各MCPサーバーの実装ごとにバラバラです。

チェックリスト：AIコーディングエージェントのシークレットセキュリティ

私が実際に適用している項目です。

• .claude/settings.local.jsonが.gitignoreに入っているか確認
• MCP設定ファイルに平文クレデンシャルの代わりに環境変数参照を使用（"env": {"KEY": "環境変数名"}）
• GitHub Push Protectionの有効化（Settings > Code security）
• git add -Aの代わりにgit add <ファイル名>で明示的にステージング
• AIエージェントが生成したコードにハードコーディングされたシークレットがないかコミット前に確認
• 四半期ごとのGitヒストリーのシークレットスキャン（gitleaksまたはtruffleHogを使用）
• MCPサーバー接続に使用するトークンへの最小権限の原則の適用

まとめ

2,900万件という数字は恐ろしいですが、実際のところほとんどのシークレット漏洩は複雑な攻撃ではなく、「うっかりコミットしてしまった」レベルのミスから発生しています。AIコーディングエージェントがこのミスの頻度を高めているというのが、今回のレポートの核心です。AIコーディングツールのプロンプトインジェクション脆弱性がクレデンシャル窃取につながる経路も同じ文脈です。

私にとって最も響いた教訓は、AIエージェントを使うとコード生成の速度が上がる分、セキュリティレビューの速度も追いつかなければならないということです。エージェントが10秒で作ったコードを30秒も見ずにコミットする習慣が最も危険です。少なくともgit diffは一度目を通しましょう。特に.json、.yaml、.env拡張子のファイルがステージングに含まれている場合は。