４層防御：Claudeと一緒に開発しながらシークレット漏洩を止める方法

以前、顧客向けの運用マニュアルをそのままコミットしてしまいました。サーバーのログイン情報、管理画面のURL、メール設定——すべて。プライベートリポジトリとはいえ、GitHubに。そして気づかずに作業を続け、気づいた時には上に14コミットが積み重なっていました。

そこから始まったのは、git filter-repo での履歴削除、強制プッシュ、そしてそのファイルにあったパスワード・APIキー・トークンの全ローテーション。最悪だったのは——そのドキュメントを書いていたのはClaudeだったということ。AIは速く、締め切りは迫っていて、私のレビュー帯域はAIの出力速度に追いつけなかった。

この記事は、その事件の後に何を変えたかについてです。習慣ではなく——仕組みを。

本質的な問題：注意力は枯渇するリソース

Claude、Cursor、その他のAIアシスタントと一緒にコードを書くと、アウトプット速度が劇的に上がります。2時間かかっていたドキュメントの初稿が10分で出てくる。それが価値です。しかし、*レビュー帯域*は変わらない——むしろ、AIの作業テンポは容赦がないため、かえって下がる。

この環境では、「もっと気をつけよう」は戦略にならない。注意力はなくなるリソースです。締め切り前、疲労時、生産的なClaudeセッションの勢い——そういう条件の時にこそ、シークレットは漏れる。

実際に機能するのは、シークレットが*構造的に混入できない*ようにするか、それが難しければ、人間が見落とすものを決定論的な機械に止めさせることです。

VAONで使っている4層フレームワークを紹介します。

４層防御の全体像

順序が重要です。多くの開発者は直感的にLayer 4に手を伸ばします——「Claudeフックを追加しよう」。それは逆です。Claudeフックが発火するのは、Claudeが書く時だけ。直接入力、別のAIツール、シェルからの貼り付け——すべて素通りします。

Layer 1から始めて外側に広げていきましょう。

Layer 1 — 設計層：混入不可能な構造を作る

最もコストが低く、最も強力な層です。原則は：機密情報をgitがトラックしない場所に置く。

_credentials/` ディレクトリ（名前は何でも構いません）を作り、.gitignore に追加します：

# .gitignore
_credentials/
*.local.md
*.secret.md
credentials*.md
**/draft/

これで運用マニュアル、ランブック、クライアント向け引き継ぎ書を _credentials/ の中に自由に書けます。本物のパスワード、本物のトークン、人間が読みやすい形で。そのファイルは絶対にgit履歴に触れない。トリックもテンプレートもプレースホルダーも不要——ただ、構造だけ。

失うもの：これらのファイルのgitによるバージョン管理。
得るもの：認知的オーバーヘッドがゼロ。Claudeがどれだけ速く書いても、漏洩は*構造的に不可能*。

バージョン管理が必要な認証情報は、1Password共有Vault、Bitwarden、または適切なACLが設定されたNotionページで管理してください。秘密情報にgitは間違ったツールです。

Layer 2 — git pre-commit / gitleaks：決定論的ゲート

ここが本命の自動化です。2つのツールをインストールします：

- gitleaks — - ステージされたファイルに対してregexパターンマッチングでシークレットを検出。Goバイナリ、高速、AWSキー・GitHubトークン・Stripeシークレット・OpenAIキーなど数百のパターンをカバー。
- lefthook — YAMLでgit hooksを宣言的に管理。1ファイル、並列実行、チームでの共有が容易。

brew install gitleaks lefthook

リポジトリのルートに lefthook.yml を作成：

pre-commit:
 commands:
   gitleaks:
     run: gitleaks git --staged --redact --verbose

フックをインストール：

lefthook install

これだけで、毎回のコミット時に決定論的スキャンが走ります。AWSキーの形式、GitHubトークンのプレフィックス、ベアラートークンなど——パターンにマッチすればコミットはブロックされます。警告ではなく、ブロック。

プロジェクト固有のルール を .gitleaks.toml に追加：

# Project-specific detection

[[rules]]
id = "japanese-password-field"
description = "Detect passwords in Japanese-language documentation"
regex = '''(?i)(パスワード|password|pw|pass)\s*[:：=]\s*["']?[A-Za-z0-9!@#$%^&*\-_=+]{6,}["']?'''
tags = ["password"]

[[rules]]
id = "internal-api-key"
description = "Company-specific API key format"
regex = '''mycompany_(live|test)_[A-Za-z0-9]{24,}'''
tags = ["api-key"]

# Suppress false positives from templates
[[allowlists]]
paths = ['''docs/.*\.template\.md''']
regexes = ['''DUMMY_|<placeholder>|xxxxxxxx''']

ポイント：汎用パターン（APIキーの形式）＋プロジェクト固有パターン（ドキュメント内のフィールド名） の両建て。日本語の運用マニュアルは `パスワード:` という書き方が多いため、カスタムエントリが必須です。

Layer 3 — GitHub Push Protection：最後の砦

pre-commitフックがあっても、開発者はバイパスできます：

git commit --no-verify -m “quick fix”

Layer 3はサーバー側のフェイルセーフです。GitHubの Push Protection は、ローカルのフック状態に関係なく、プッシュを受け入れる前に既知のシークレットパターンをスキャンします。

有効化： Settings → Advanced Security → Secret Protection → Push protection

重要：publicリポジトリは無料で自動有効。privateリポジトリにはGitHub Team以上 + Secret Protection有効化（GitHub Advanced Securityの一部、有料）が必要です。クライアントワークのプライベートリポジトリで使いたい場合は、組織の課金プランを確認してから有効化してください。

プッシュがブロックされると、GitHubはマッチした箇所を正確に表示し、理由付きの明示的なオーバーライドを要求します——監査証跡が残ります。

Layer 4 — Claude Code hook：補助として置く

ようやく、Claudeに固有のツールの話です。これは意図的に最後にしました。

~/.claude/settings.json に追加：

json
{
 "hooks": {
   "PreToolUse": [
     {
       "matcher": "Write|Edit",
       "hooks": [
         { "type": "command", "command": "~/.claude/hooks/secret-guard.sh" }
       ]
     }
   ]
 }
}

~/.claude/hooks/secret-guard.shを作成：
 

#!/usr/bin/env bash
set -euo pipefail

PAYLOAD=$(cat)

CONTENT=$(printf '%s' "$PAYLOAD" | jq -r '
 .tool_input.content //
 .tool_input.new_string //
 empty
')

[[ -z "$CONTENT" ]] && exit 0

TMP=$(mktemp -t secret-guard.XXXXXX)
trap 'rm -f "$TMP"' EXIT
printf '%s' "$CONTENT" > "$TMP"

if gitleaks dir "$TMP" --no-banner --redact >/dev/null 2>&1; then
 exit 0
fi

cat >&2 <<'EOF'
secret-guard: Potential secret detected. Write/Edit blocked.
→ Move credentials to _credentials/ (gitignored)
→ Use <PLACEHOLDER> in templates
→ Add false positives to .gitleaks.toml [[allowlists]]
EOF
exit 2
 

chmod +x ~/.claude/hooks/secret-guard.sh

なぜこれがLayer 4（補助）なのか：

1. Claudeが書く時にしか発火しない。直接編集、別のAIツール、シェル貼り付け——全部素通り。
2. AI検知は確率的。gitleaksは決定論的。機械の方が信頼できる。
3. 「AIが見てるから大丈夫」という感覚は人間の注意を弱める。最終防衛線をAIに任せると組織として脆くなる。

Claudeを主な書き手にしているなら補助として入れる価値はあります。でもLayer 1〜3なしにここだけ入れるのは順序が逆です。

もし、すでに漏らしてしまったら

1. 履歴から削除:

# Use git filter-repo (not the deprecated filter-branch)
git filter-repo --path path/to/secret-file.md --invert-paths
git push origin --force --all

2. 必ず全部ローテーション。例外なし。
一度pushされたシークレットは——privateリポジトリでも——漏れたものとして扱う。履歴を消すのは「なかったことにする」ためではなく、「これ以上の露出を防ぐ」ため。認証情報そのものを必ず新しい値に切り替えてください。

3. キャッシュ問題を理解する：
GitHubはforce push後も一定期間データを保持します。フォークがあればそこにも残ります。publicリポジトリで漏らした場合はGitHub Supportにキャッシュ削除を依頼できます。詳細はGitHubのセンシティブデータ削除ガイドを参照してください。

AI時代はシステムレベルの思考が必要

AIツールが出力を加速させるほど、意志力では対処できないリスクカテゴリが生まれます。「書く速度」と「レビュー帯域」のギャップは広がるだけです。合理的な対応は、決定論的に機械が止められる障害モードから人間の注意への依存を取り除くことだけです。

Layer 1（設計）＋Layer 2（gitleaks）で現実的な漏洩シナリオの95%以上をカバーします。Layer 3はエッジケースとバイパス対策。Layer 4はAIループの早期に問題を捕捉します。

一度セットアップすれば、永続的に動き続けます。

VAONでは、すべてのクライアントプロジェクトにこのスタックを導入しています。セットアップに費やした1時間が、過去1年間で少なくとも3件のインシデントを防ぎました。

参考: https://zenn.dev/takna/articles/secret-leak-prevention-4-layer