GateGuard — ファクト駆動型の操作前ゲート

Claude に編集前の調査を強制する PreToolUse フック。自己評価（「本当にですか？」）とは異なり、具体的なファクトを要求します。調査行動そのものが、自己評価では決して実現できない認知変化を生み出します。

いつ有効化するか

• ファイル編集が複数のモジュールに影響を与えるコードベースを扱う場合
• プロジェクトに特定のパターンや日付フォーマットを持つデータファイルが含まれている場合
• チームが AI 生成コードが既存パターンに一致することを要求する場合
• Claude が調査ではなく推測する傾向がある任意のワークフローで

コアコンセプト

LLM の自己評価は機能しません。「ポリシーに違反していないか？」と尋ねても、答えは常に「いいえ」です。これは実験で検証されています。

しかし「このモジュールをインポートするすべてのファイルをリストアップしてください」と尋ねると、LLM に Grep と Read を実行させます。調査そのものが出力を変える文脈を生み出します。

3段階ゲート：

1. DENY  — 最初の編集/書き込み/Bash 試行を阻止
2. FORCE — モデルに必要なファクト収集を明確に指示
3. ALLOW — ファクトが提示された後、再試行を許可

同時にこれら3つのステップを実行できる競合製品はありません。ほとんどは拒否に止まります。

エビデンス

2つの独立した A/B テスト、同じエージェント、同じタスク：

タスク	ゲートあり	ゲートなし	差分
モジュール分析	8.0/10	6.5/10	+1.5
Webhook バリデーター	10.0/10	7.0/10	+3.0
平均	9.0	6.75	+2.25

両方のエージェントが生成したコードは実行でき、テストに合格します。違いは設計の深さにあります。

ゲートのタイプ

編集/マルチエディット ゲート（ファイルごとの最初の編集）

マルチエディットは同じように処理されます——バッチ内の各ファイルは個別にゲートされます。

{file_path} を編集する前に、以下のファクトを提示してください：

1. このファイルをインポート/参照するすべてのファイルをリストアップしてください（Grep を使用）
2. この変更の影響を受けるパブリック関数/クラスをリストアップしてください
3. このファイルがデータファイルを読み込み/書き込みする場合、フィールド名、構造、日付フォーマットを表示してください（本番データではなく、脱敏またはシンセティック値を使用）
4. ユーザーの現在の指示を逐字引用してください

書き込みゲート（新しいファイルの初回作成）

{file_path} を作成する前に、以下のファクトを説明してください：

1. この新しいファイルを呼び出すファイルと行番号を指定してください
2. 同じ機能を持つ既存ファイルがないことを確認してください（Glob を使用）
3. このファイルがデータファイルを読み込み/書き込みする場合、フィールド名、構造、日付フォーマットを表示してください（本番データではなく、脱敏またはシンセティック値を使用）
4. ユーザーの現在の指示を逐字引用してください

破壊的 Bash ゲート（破壊的なコマンドごと）

トリガー条件：rm -rf、git reset --hard、git push --force、drop table など。

1. このコマンドが変更または削除するすべてのファイル/データをリストアップしてください
2. 1行のロールバック手順を作成してください
3. ユーザーの現在の指示を逐字引用してください

通常の Bash ゲート（セッションごと1回）

1. 現在のユーザーリクエストを1行で要約してください
2. この特定のコマンドが検証または生成する内容

クイックスタート

オプション A：ECC フックを使用（ゼロインストール）

scripts/hooks/gateguard-fact-force.js のフックはこのプラグインに含まれています。hooks.json 経由で有効化します。

GateGuard がセットアップまたは修正作業をブロックしている場合は、 ECC_GATEGUARD=off でセッションを開始してください。フックレベルの制御が必要な場合は、引き続き ECC_DISABLED_HOOKS と GateGuard フック ID を使用してください。

オプション B：設定を伴う完全パッケージ

pip install gateguard-ai
gateguard init

これにより .gateguard.yml が追加され、プロジェクトごとの設定（カスタムメッセージ、無視パス、ゲートトグル）が可能になります。

アンチパターン

• 自己評価で置き換えないでください。 「本当にですか？」は常に「はい。」という返答を得ます。これは実験で検証されています。
• データスキーマチェックをスキップしないでください。 両方の A/B テストエージェントは ISO-8601 日付を想定しましたが、実際のデータは %Y/%m/%d %H:%M を使用していました。データ構造を確認する（脱敏値を使用）ことでこのようなエラーを防ぎます。
• すべての Bash コマンドをゲートしないでください。 通常の bash ゲートはセッションごと1回です。破壊的 bash ゲートは実行ごとです。このバランスにより、速度低下を避けながら真の危険性をキャプチャします。

ベストプラクティス

• ゲートは自然にトリガーさせてください。ゲート質問に事前に答えようとしないでください——調査そのものが品質向上の鍵です。
• ゲートメッセージをドメインに合わせてカスタマイズしてください。プロジェクトに特定の慣例がある場合は、ゲートプロンプトに追加してください。
• .gateguard.yml を使用して .venv/、node_modules/、.git/ などのパスを無視してください。

関連スキル

• safety-guard — ランタイムセーフティチェック（補完的、重複なし）
• code-reviewer — 編集後レビュー（GateGuard は編集前調査）