【2026年版】GitHubに2,900万件のシークレット漏洩：AIコーディングツール時代のシークレット管理を見直す

DevOps

この記事の概要

GitGuardianの「State of Secrets Sprawl 2026」レポートによると、2025年だけでGitHubの公開リポジトリに約2,900万件のシークレット（APIキー・認証情報など）が漏洩し、前年比34%増と過去最大の増加幅を記録した。AI関連サービスの漏洩は81%増、MCP設定ファイルという新しい攻撃面も登場しており、インフラエンジニアは今すぐシークレット管理の体制を見直す必要がある。

シークレットをコードに書くと、GitHubで即公開される時代になった

「APIキーをコードに書いてしまった」――多くのエンジニアが経験するヒヤリ案件だが、2026年現在そのリスクは以前と比べものにならないほど高まっている。

GitGuardianが2026年3月に公開した「State of Secrets Sprawl 2026」によると、2025年1年間だけで公開GitHubリポジトリに2,865万件の新たなハードコードされたシークレットが追加された（前年比34%増・過去最大）。さらに深刻なのは修復率の低さで、2022年に有効と確認されたシークレットの64%が2026年1月時点でもまだ失効処理されていない。AWS認証情報・kubeconfigファイル・CI/CDトークンなど、インフラ業務で日常的に扱う認証情報が大量に漏洩し続けている。

なぜシークレット漏洩は年々加速しているのか

漏洩が加速している最大の原因はAIコーディングツールの普及だ。GitGuardianのデータによると、AIツールが関与したコミットは、そうでないコミットと比べておよそ2倍の頻度でシークレットを含む傾向がある。

なぜそうなるのか。AIコーディングツールは「動くコードを素早く生成する」ことに最適化されている。コンテキストとして環境変数や設定ファイルを渡すと、そのAPIキーをコードに直接埋め込んだサンプルを生成することがある。開発者がその出力をそのままコミットしてしまうケースが後を絶たない。

もう一つの要因がAIサービス自体の普及だ。OpenAI・Anthropic・Gemini・Hugging Faceなどへのアクセスに必要なAPIキーの数が急増しており、AIサービス関連のシークレット漏洩は2024年比で81%増、計1,275,105件が検出された。

内部リポジトリの方が危険

見落とされがちなのが内部リポジトリのリスクだ。「公開リポジトリだけ注意すればいい」と思うかもしれないが、GitGuardianの調査では内部リポジトリの32.2%に少なくとも1件のハードコードされたシークレットが含まれていた。これは公開リポジトリ（5.6%）の約6倍の密度だ。内部リポジトリには、CI/CDのサービストークン、クラウドのアクセスキー、データベースのパスワードなど、攻撃者が侵入後に狙う高価値の認証情報が集中している。

MCPという新しい攻撃面

2026年に新たに浮上したリスクがMCP（Model Context Protocol）設定ファイルからの漏洩だ。AIエージェントの普及に伴い、MCP設定ファイルにAPIキーを直接記述するケースが増えており、GitGuardianは24,008件のユニークなシークレットをMCP設定ファイルから検出した。うち2,117件は有効なシークレットとして確認されている。

人気のMCPセットアップガイドの多くが「設定ファイルにAPIキーを直接書く」方法を推奨している。利便性優先のドキュメントがセキュリティリスクを生む典型例だ。

GitGuardian 2026レポートで見えてきた「漏洩シークレットの実態」

レポートが明らかにした漏洩シークレットの内訳を整理する。インフラエンジニアが注意すべき主要カテゴリは、クラウド認証情報（AWS Access Key・GCPサービスアカウントキー・Azure SASトークン）、CI/CDトークン（GitHub Actions PAT・GitLab CI Token）、Kubernetesのkubeconfig、AIサービスのAPIキー（81%増）、TerraformのStateファイルに埋め込まれたシークレットなどだ。

実装例：プリコミットフックでシークレットをブロックする

最も効果的な対策の一つが、コミット前にシークレットを検出するプリコミットフックの導入だ。GitGuardianが提供するOSSツール ggshield を使えば、ローカルで検出できる。

# ggshieldのインストール
pip install ggshield

# GitGuardianのAPIキーを環境変数に設定（.envファイルに書かず必ず環境変数で）
export GITGUARDIAN_API_KEY="your-api-key-here"

# プリコミットフックの設定（pre-commitを使う場合）
# .pre-commit-config.yaml に追記

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitguardian/ggshield
    rev: v1.35.0
    hooks:
      - id: ggshield
        language_version: python3
        stages: [pre-commit]

# インストールと有効化
pip install pre-commit
pre-commit install

# 手動でスキャン実行（既存コミットの確認）
ggshield secret scan repo .

GitHub Actionsに組み込む場合は以下のようなワークフローを追加する。

# .github/workflows/secret-scan.yml
name: Secret Scan

on:
  push:
    branches: ["**"]
  pull_request:
    branches: [main, develop]

jobs:
  secret-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # 全コミット履歴を取得

      - name: GitGuardian scan
        uses: GitGuardian/ggshield-action@v1
        env:
          GITHUB_PUSH_BEFORE_SHA: ${{ github.event.before }}
          GITHUB_PUSH_BASE_SHA: ${{ github.event.base }}
          GITHUB_PULL_BASE_SHA: ${{ github.event.pull_request.base.sha }}
          GITHUB_DEFAULT_BRANCH: ${{ github.event.repository.default_branch }}
          GITGUARDIAN_API_KEY: ${{ secrets.GITGUARDIAN_API_KEY }}

MCP設定ファイルのシークレット管理

MCP設定ファイルへの直書きを避け、環境変数経由で渡すように変更する。

// ❌ 危険: APIキーを直書き（MCP設定ファイル）
{
  "mcpServers": {
    "my-service": {
      "command": "node",
      "args": ["server.js"],
      "env": {
        "API_KEY": "sk-abcdefghijklmnop1234567890"
      }
    }
  }
}

// ✅ 安全: 環境変数参照（値はOSの環境変数やVaultから注入）
{
  "mcpServers": {
    "my-service": {
      "command": "node",
      "args": ["server.js"],
      "env": {
        "API_KEY": "${MY_SERVICE_API_KEY}"
      }
    }
  }
}

実務での活用シナリオ

既存リポジトリを確認する場合は ggshield secret scan repo . でスキャンし、問題が見つかれば git-filter-repo で履歴から除去して該当キーを即座にローテーションする。チームへの展開はリポジトリのデフォルトテンプレートにggshieldを組み込み、新規リポジトリ作成時に自動で有効化される仕組みを整える。AWS Access Keyがコミットされた場合はまずIAMコンソールで即座に無効化し、CloudTrailで不正利用の有無を確認してから新しいキーを発行しSecrets Managerへ移行する流れが基本だ。

今日からできるシークレット管理の3ステップ

GitGuardianのレポートが突きつける現実は厳しいが、対策は明確だ。

Step 1: 現状把握 — ggshield やGitHubの組み込みスキャン機能で内部・外部リポジトリを棚卸しする。内部リポジトリは公開リポジトリの約6倍の密度でシークレットを含んでいるため優先確認を。

Step 2: 予防の自動化 — プリコミットフックとCIパイプラインへのスキャン組み込みで、「コミット前に防ぐ」フローへ移行する。

Step 3: 集中管理へ移行 — AWS Secrets ManagerまたはHashiCorp Vaultにシークレットを集約し、アプリは動的取得する構成に切り替える。ソースコードに認証情報が触れない状態が最終ゴールだ。

AI時代のシークレット管理は「気をつける」だけでは追いつかない。自動化と仕組みで対処することが2026年のスタンダードだ。

まとめ

GitGuardianの「State of Secrets Sprawl 2026」が示したのは、AIコーディングツールの普及がシークレット漏洩を加速させているという厳しい現実だ。2,900万件の漏洩シークレット、AI関連81%増、MCP設定ファイルという新たなリスク――インフラエンジニアが日常的に扱う認証情報が漏洩の標的になっている。

対策の核心は3点だ。①ggshieldなどのスキャンツールで現状を把握する、②CI/CDへの組み込みで予防を自動化する、③Secrets ManagerやVaultによる集中管理へ移行する。「AIツールを使うなら、シークレット管理も一緒に強化する」を2026年のチーム標準として採用してほしい。

参考リンク

コメント