TL;DR
- PlanGate v8.6.0 は 承認境界 + 監査可能性 + スクラム親和性 を中心に AI コーディングを統治する。autonomy 中心のフレームワークと逆方向。
- C-3（計画承認）と C-4（PR レビュー） の 2 ゲートで「承認なし、コードなし」を強制し、不変条件は 10/10 hooks（公式値）で runtime ブロックする。
- v8.6 では Metrics v1 と Harness Improvement Governance が加わり、改善サイクルを baseline 比較で判断できるようになった。
はじめに
こんにちは、みねです。
Claude Code や Codex を本格導入すると、プロンプトに「plan.md を書いてから実装してください」と書いても、エージェントは 長いセッションの後半でルールをすり抜けます。レビュー経験のある CTO / EM / Platform Lead なら、1 度は「承認していない設計が main に入っていた」という事故を踏んだはずです。
この記事のゴール:
AI コーディングエージェントを「承認なし、コードなし」で統治する設計を、PlanGate v8.6.0 の Hook Enforcement 10 種と Metrics v1 を題材に整理する。
題材にする PlanGate は、s977043 が公開している MIT ライセンスの ガバナンス優先ワークフローハーネスです。一般的なエージェントフレームワークが autonomy（自律性）を重視するのに対し、PlanGate は 承認境界・監査可能性・スクラム親和性 を中心に据えます。同じ「ガードレール」というワードでも、立ち位置がだいぶ違います。
本記事は v8.6.0 リリース（2026-05-04 公開、Releases）時点の正本ドキュメントを一次ソースに整理しています。
カバーしないこと:
- Claude Code / Codex の API 仕様詳解（→ Claude Code 公式）
- 一般的なセキュリティ層構造（→ AIコーディング導入のセキュリティ設計）
1. なぜ「autonomy」より「承認境界」が要るのか
1.1 プロンプト依存の限界
AI コーディングのガバナンスは、最初は プロンプトに書く ことから始まります。CLAUDE.md、AGENTS.md、システムプロンプト。しかし、これだけだと次の 3 つで破綻します。
| 破綻パターン | 起きること |
|---|---|
| 長セッションの忘却 | コンテキストが伸びると、冒頭で指定した制約が後半で効かなくなる |
| workflow 改変 | エージェントが「効率化のため」スキップする手順を提案・実行してしまう |
| 監査の不在 | 「指示は読んだはず」では、後から検証できない |
PlanGate の哲学はここに踏み込みます。プロンプトに頼らず、runtime で決定論的にブロック する。さらに append-only の監査ログ で「いつ、何が、どの hook で止まったか」を残す。
1.2 PlanGate の差分（承認境界・監査可能性・スクラム親和性）
公式 README は PlanGate を次のように位置づけます。
一般的なエージェントフレームワークが「自律性」を重視するのに対し、PlanGate は 承認境界・監査可能性・スクラム親和性 を重視します。 — s977043/PlanGate README
3 つの軸を実務語に翻訳すると:
- 承認境界: 人間の判断点（C-3 / C-4）の前後に「進めない壁」を置く
- 監査可能性: 計画・レビュー・検証・引き継ぎを
docs/working/TASK-NNNN/に永続化する - スクラム親和性: PBI（Product Backlog Item）を入口に置き、スプリントの単位とそろえる
セキュリティ全体の中での位置づけは AIコーディング導入のセキュリティ設計 の L3 実行時制御層 に相当します。
2. 2 ゲート構造（C-3 / C-4）でワークフローを固定する
2.1 ワークフロー全体図
PlanGate は AI 実装の 前後 に 2 つの人間承認ゲートを置きます。
人間が PBI を書く → AI が計画を生成 → [C-3: 人間が承認]
→ AI が実装（TDD）→ 自動検証（L-0, V-1〜V-4）
→ PR 作成 → [C-4: 人間が GitHub でレビュー] → マージ
| ゲート | タイミング | 判断 |
|---|---|---|
| C-3 | 計画レビュー後、実装前 | APPROVE / CONDITIONAL / REJECT |
| C-4 | AI 実装後、GitHub PR 上 | APPROVE / REQUEST CHANGES |
判断材料は plan.md / todo.md / test-cases.md / 検証 evidence で、すべて docs/working/TASK-NNNN/ 配下に残ります。「読みました」では完結せず、ファイルが揃わないと進めない設計です。
2.2 中核アイデアと Iron Law
公式 README から中核アイデアを抜粋します（一部、本記事の言葉で補足）。
| 中核アイデア | 内容 |
|---|---|
| 計画先行 | PBI から plan / todo / test-cases を作り、承認前の実装を禁止する |
| ゲート制御 | C-3（計画承認）と C-4（PR レビュー）で人間の判断点を固定する |
| Hook 強制 | plan / approval / evidence / scope / review の不変条件を hook と CLI で検査する |
| 検証内蔵 | L-0 / V-1〜V-4 により、実装後の検証をワークフローに組み込む |
| 状態の永続化 | docs/working/TASK-NNNN/ に計画、レビュー、検証、handoff を残す |
Iron Law 7 項目（core-contract.md § 4）には「C-3 承認前 production 編集禁止」「PBI 外 scope 追加禁止」「検証証拠なし完了禁止」「2 段階レビューなしマージ禁止」などが含まれ、これらが後述の Hook 群とほぼ 1:1 で対応します。
レビュー観点で workflow をどう設計するかは AI レビュー workflow の設計 も参考になります。
3. Hook Enforcement 10 種で何を runtime ブロックするか
PlanGate は v8.5.0 で 10/10 hooks 実装完了（公式値）、v8.6 でもこの状態を維持しています。Hook テストは 42 PASS（公式値、sh tests/hooks/run-tests.sh）。
3.1 EH-1〜EH-7（基本 7 件）
docs/ai/hook-enforcement.md から表化します。
| Hook | 種別 | 不変条件 | 対応 Iron Law |
|---|---|---|---|
| EH-1 | PreToolUse | plan.md なしの production code 編集を block | #1 / #5 |
| EH-2 | PreToolUse | C-3 未承認のまま exec フェーズに進むのを block | #1 |
| EH-3 | PreToolUse + CLI | c3.json の plan_hash と plan.md sha256 の不一致（承認後改竄）を検知 | #5 |
| EH-4 | CLI | test-cases.md 不在のまま V-1 を実行するのを block | #3 |
| EH-5 | CLI | 検証 evidence なしの PR 作成を block | #3 |
| EH-6 | PreToolUse + CLI | 子 PBI YAML の forbidden_files glob と編集対象 path を fnmatch で照合し、scope 外編集を block | #2 |
| EH-7 | CLI | C-3 + C-4 のいずれかが APPROVED でない状態でのマージを block | #7 |
特に EH-3 plan_hash 改竄検知 は、承認済の plan.md をエージェントが「微修正」しても検知できる仕組みで、公開リポジトリで実装している例は希です。approvals/c3.json を発行した時点の sha256 を保存し、PreToolUse hook が次の編集前に比較します。
3.2 EHS-1〜EHS-3（strict プロファイル拡張）
Model Profile の validation_bias: strict（gpt-5_5_pro 等）では、さらに 3 件追加されます。
| Hook | 種別 | 不変条件 |
|---|---|---|
| EHS-1 | CLI（mode 連携） | standard / high-risk / critical で V-3 外部 AI レビュー必須化、light / ultra-light は SKIP |
| EHS-2 | CLI | handoff.md 必須 6 要素（要件適合 / 既知課題 / V2 候補 / 妥協点 / 引き継ぎ文書 / テスト結果）の欠落で WF-05 を block |
| EHS-3 | CLI | V-1 FAIL → fix → V-1 のループが 5 回を超過したら ABORT してエスカレーション |
EHS-3 は fix loop 暴走防止 が本質で、AI が「直したつもり」を繰り返して時間を溶かす状況を停止させます。経験上、これが効くと 1 PBI あたりの平均待ち時間が体感で 1/3 〜 1/4 になります（経験則）。
3.3 3 mode 設計と監査ログ
10 hook はすべて 3 mode 設計 で書かれています。
| モード | 環境変数 | 挙動 |
|---|---|---|
| default（推奨初期値） | なし | 違反検出時は warning のみ。continue:true で block しない |
| strict | PLANGATE_HOOK_STRICT=1 | 違反検出時に block / exit 1。本番運用 / CI で有効化 |
| bypass | PLANGATE_BYPASS_HOOK=1 | 常時 pass。緊急対応のみ。監査ログに必ず記録 |
判定はすべて docs/working/_audit/hook-events.log に append-only（タブ区切り）で記録されます。フォーマットは:
<ISO8601 UTC>\t<level>\t<hook-name>\t<task-id>\t<message>
level: PASS / VIOLATION / BYPASS / SKIP / INCREMENT。bypass まで監査対象に入れている点が 監査可能性 の真面目さで、後から「いつ誰が逃げたか」を追えます。
Claude Code の hook 機能（公式ドキュメント）でこういう不変条件を設計する一般パターンは Claude Code hooks の実践パターン集 でも整理しているので、PlanGate を入れる前段の理解にどうぞ。
4. v8.6 で何が増えたか — Metrics v1 と Governance
v8.6.0（2026-05-04）の P0 milestone は 4 件すべて完走（公式値、CHANGELOG）。順序にも意味があります。
#194 Baseline 固定 → #201 Issue Governance → #202 Metrics Privacy → #195 Metrics v1
「先に baseline と privacy を整え、その上に metrics を載せる」順番です。Privacy ポリシーが先にあるから、§4 Forbidden のフィールドは schema 上に存在させない という設計強制が効きます。
4.1 bin/plangate metrics（11 events / NDJSON）
新しく追加された CLI サブコマンドは次の通りです（bin/plangate v0.2.0、公式実装）。
plangate metrics <TASK-NNNN> [--collect|--report] [--aggregate] [--json]
--collect Append metrics events to docs/working/_metrics/events.ndjson
--report Print summary
--aggregate Cross-TASK aggregate
集計対象は 11 events（公式値）:
task_initialized / plan_generated / c3_decided / exec_started / hook_violation / v1_completed / fix_loop_incremented / external_review_completed / pr_created / c4_decided / handoff_completed
NDJSON 形式で append-only。schema は schemas/plangate-event.schema.json で conditional required（c3 / c4 / v1 / hook / fix_loop で必須フィールドが切り替わる）になっています。
4.2 Metrics Privacy Policy
docs/ai/metrics-privacy.md で、metrics に何を保存していいかが厳密に定義されました。
| 区分 | 内容 |
|---|---|
| 保存可 | 12 カテゴリ（公式値、TASK ID / mode / 時刻 / 件数 / hook 名 / 判定など） |
| 禁止 | 9 カテゴリ（公式値、file path / stack trace / command output / provider metadata / 個人情報など） |
| 保持期間 | 90 日（公式値、retention） |
Public repo に commit させないため docs/working/_metrics/events.ndjson は .gitignore 済み（v8.6 で追加、CHANGELOG）。public-private 別運用差分も明記されています。
4.3 Issue / Label / Milestone Governance
docs/ai/issue-governance.md で、Issue 必須セクション・Label taxonomy（kind / area / priority / status の 4 軸）・Milestone mapping policy（推測禁止条項）・Roadmap PBI 作成 checklist 10 項目が正本化されました。
ここは地味ですが、CTO / EM 視点では効きます。「milestone は人が明示的に紐付けるもので、AI に推測させない」 というルールが文書化されたことで、v8.6 リリース時に過去 11 PBI の milestone 不整合（v7.x 系列に誤紐付き）も全件訂正されています。
4.4 Baseline 比較の基盤
docs/ai/eval-baselines/2026-05-04-baseline.{md,json} に v8.5.0 直後の baseline が固定されました。代表 5 TASK（TASK-0050/0054/0055/0056/0057）で 8 観点 eval を回し、機械可読の JSON snapshot を残しています。
これにより v8.7 以降の harness 改善（#196 Eval expansion / #197 Model Profile v2 / #198 Keep Rate / #199 Dynamic Context）を 比較で判断 できる土台が整いました。bin/plangate eval --baseline がこの仕組みを直接使います。
CLI eval の使い方や、レビュー workflow との接続は AI レビュー workflow の設計 も参照してください。
5. 導入の段階設計（3 ステップ）
PlanGate を最初から strict mode で入れると、既存チームは「うざい hook」が刺さって離脱します。段階導入が現実的です。
5.1 Step 1: default mode で hook を入れる
.claude/settings.example.json を .claude/settings.json にコピーすると、PreToolUse に EH-1 + EH-2 + EH-3 + EH-6 + SessionStart（gh-pin-account）が登録されます。default mode なので warning のみ。1〜2 スプリント走らせて、hook がどこで warning を出すかチームに眺めてもらいます。
5.2 Step 2: CI で schema 検証 + eval を回す
CI に次を追加します。
bin/plangate validate-schemas: JSON artifact（c3.json / c4-approval.json / handoff metadata 等）の schema 検証bin/plangate eval <TASK-NNNN>: 8 観点機械評価、release blocker 違反検知（exit 1 で CI 停止）.github/workflows/check-pr-issue-link.yml: 子 PBI auto-close 漏れ検知
CLI tests は sh tests/run-tests.sh で 32 PASS（公式値、v8.6.0 時点）。CI 統合の境界線は GitHub agentic workflows と CI/CD の整理が下敷きになります。
5.3 Step 3: strict mode + metrics で改善ループ
ここで初めて PLANGATE_HOOK_STRICT=1 を CI / 本番運用で立てます。同時に bin/plangate metrics TASK-NNNN --collect を CI に組み込み、docs/working/_metrics/events.ndjson を集計します（metrics --collect は TASK ID 必須、複数 TASK を扱う CI では対象 TASK を列挙して collect、集約は bin/plangate metrics --report --aggregate に分ける）。
schema は 11 events が定義されていますが、v8.6 で --collect が TASK artifact から自動導出するのは task_initialized / plan_generated / c3_decided / exec_started / v1_completed / handoff_completed / external_review_completed の 7 eventsです。hook_violation は手動 append（hook 側自動 emit は v8.7+ の候補）、pr_created / c4_decided の GitHub API 取得は v2 の候補と公式 docs に明記されています（公式値、出典: docs/ai/metrics.md / CHANGELOG.md）。最初に効くのは:
hook_violationの発生数（どの TASK / mode / hook で何回発生したか ── Metrics Privacy が個人・プロジェクト固有名を Forbidden に指定しているため、人単位ではなく TASK / mode / hook 名の集計に限定する）c3_decided/c4_decidedの APPROVE 比率と CONDITIONAL 内訳fix_loop_incrementedの最大値（5 を超えたら EHS-3 で ABORT）
組織展開の段取りは AI コーディング組織展開の段階設計 で詳細に整理しています。
6. ガードレール導入チェックリスト
CTA 直前の自己診断です。12 項目中 8 つ以上が Yes なら導入準備が整っている目安です。
-
docs/working/TASK-NNNN/のような 作業コンテキストの永続化先 を 1 箇所に決められるか - PBI（Product Backlog Item）が 入口で書き起こされ、AI 着手前にレビュー可能か
- 計画レビュー（C-3）の 判断者 1 名 を任命できるか
- PR レビュー（C-4）を 必ず人間で通すブランチ保護を有効化できるか
-
plan.md/todo.md/test-cases.mdの テンプレート 3 種 を持っているか - CI で JSON artifact の schema 検証 を入れる準備があるか
- append-only の監査ログ をどこに置くか決まっているか
- hook を default → strict で段階導入する 2〜3 スプリントを確保できるか
- fix loop 上限 をチームで合意できるか（PlanGate 既定は 5）
-
forbidden_filesを PBI 単位で指定 する運用に違和感がないか - metrics の保存可 / 禁止 9 カテゴリ を社内 privacy ポリシーと照合できるか
- 緊急時の bypass mode 利用ルールを書面化できるか
導入支援が必要であれば、お問い合わせ からどうぞ。サンプル PBI / hook 設定例 / CI workflow をまとめたチェックリストを共有します。
まとめ
- PlanGate v8.6.0 は 承認境界・監査可能性・スクラム親和性 を中心に、AI コーディングを統治するハーネス。
- C-3 / C-4 の 2 ゲート + 10/10 hooks（公式値）で、不変条件を runtime ブロックする設計。
- v8.6 では Metrics v1（11 events、保存可12 / 禁止9 / 90日 retention の privacy policy 準拠）と Issue/Label/Milestone Governance が加わり、改善サイクルを baseline 比較で判断できるようになった。
- 導入は default → CI → strict の 3 ステップ。最初から strict にしないこと。
PlanGate の hook が tool 呼び出し境界として保護する MCP サーバーそのものの設計（tool 粒度・OAuth 2.1・transport 選定）は MCPサーバー設計パターン集 で別途扱っています。
FAQ
CI ですでに型チェックや lint があるが、hook と被らないか
被りません。hook は エージェントの 1 操作前 に介入する層、CI は PR 単位 で全開発者に一律ブロックする層です。PlanGate の hook は「plan.md がない」「c3.json の APPROVED がない」「plan_hash が一致しない」など、CI では検知しにくい 計画整合性 をターゲットにしています。役割分担は Claude Code hooks の実践パターン集 で整理しています。
Cursor や Codex でも使えるか
CLI（bin/plangate）と監査ログ（docs/working/_audit/）は エージェント非依存です。Claude Code 専用なのは .claude/settings.example.json の PreToolUse 登録部分のみで、Codex / Cursor の場合は事前 commit hook や CI に bin/plangate validate-schemas / eval を呼び出す形で導入できます。
既存リポジトリに途中から入れられるか
入れられます。Option A の plugin 登録か、Option B で .claude/ をコピーする方法のいずれか（公式 README）。最初は default mode で警告のみに留め、PBI 1〜2 件で運用感を掴んでから strict に上げる順序が安全です。
Iron Law や Hook を独自に増やしてもよいか
Hook は 3 mode 設計（default / strict / bypass）と監査ログ仕様（タブ区切り、append-only）に従えば追加できます。Iron Law を増やす場合は core-contract.md と responsibility-boundary.md の両方に追記し、対応 hook を tests/hooks/run-tests.sh のテストに足すのが正規ルートです。
Metrics v1 はチーム外に出してよいか
docs/ai/metrics-privacy.md の 保存可 12 カテゴリ / 禁止 9 カテゴリ（公式値）に従えば、TASK ID・mode・hook 判定・時刻・件数などは公開可能です。file path / stack trace / command output / provider metadata は 完全除外。events.ndjson は public repo にコミットしない（.gitignore 済み）のが推奨運用です。
