TL;DR
- PlanGate は AI コーディングエージェントのための「ゲート型ワークフローハーネス」。人間が承認した計画・タスク・受入テストが揃うまで、AI にプロダクションコードを書かせない（公式 README、確認日: 2026-05-17）。
- 一般的なエージェントフレームワークが 自律性 を志向するのに対し、PlanGate は 承認境界・監査可能性・スクラム親和性 を志向する（公式 README）。
- 中核は C-3（計画承認） と C-4（PR レビュー） の 2 ゲート。最新リリースは v8.6.0（公式リリース、確認日: 2026-05-17）で、Level 1〜5 の段階的導入が用意され、初回は Level 1 の plan 承認だけから始められる。
はじめに
こんにちは、みねです。
Claude Code や Codex を本格的にチームへ入れると、最初に壊れるのは「設計を承認してから実装する」という当たり前の順序です。プロンプトに「plan.md を書いてから実装して」と指示しても、エージェントは長いセッションの後半でその約束をすり抜け、承認していない設計が main に入る——レビュー経験のある方なら一度は踏んだ事故でしょう。
この記事は PlanGate を初めて知る人 に向けて、「何を解決する道具なのか」「どう導入を始めればよいか」を、公式リポジトリと公式ドキュメントの一次情報だけを根拠に整理する入門記事です。実装の細部（v8.6 の Hook Enforcement など）は別記事に譲り、ここでは概念と入口に絞ります。
この記事のゴール:
- PlanGate が何を「やる/やらない」道具なのかを 1 分で説明できるようになる
- 自分のチームがどの導入レベルから始めるべきか判断できるようになる
PlanGate とは何か
PlanGate は、AI コーディングエージェントのための ガバナンス優先ワークフローハーネス です。リポジトリの説明は端的に "Gate-based workflow for AI coding agents"（公式 GitHub、確認日: 2026-05-17）。
公式 README が掲げる本質的価値は「AI 開発の安全な型 を配布すること」で、AI に何でも自動でやらせる枠組みではない、と明言されています。具体的には次の対比で説明されています（公式 README、確認日: 2026-05-17）。
| PlanGate がやること | PlanGate がやらないこと |
|---|---|
| 計画 → 承認 → 実装 → 検証 → 引き継ぎの型を提供する | AI に勝手に skill / プロンプトを書き換えさせる |
| C-3 / C-4 / V-1〜V-4 で人間の判断点を固定する | 自律エージェントを目指す |
| 失敗・成功を後から説明可能にする（観測・再現基盤） | 全実行ログを完璧に再現する durable engine になる |
| 段階的に採用できる導入レベル（Level 1〜5）を提供する | 全機能を最初から強制する |
| Markdown ベースで認知負荷を抑える | SaaS / 外部ストアを前提にする |
設計の中心は観測ループそのものではなく「評価 → 学習 → ガバナンス」だと公式 README は述べています。つまり「ログを全部残して再生する基盤」が主役なのではなく、「承認境界を固定して、結果を後から説明できる状態にする」ことが狙いです。
2 つの人間承認ゲート
PlanGate は AI 実装の前後に 2 つの人間承認ゲートを置きます（公式 README、確認日: 2026-05-17）。
| ゲート | タイミング | 判断 |
|---|---|---|
| C-3 | 計画レビュー後・実装前 | APPROVE / CONDITIONAL / REJECT |
| C-4 | AI 実装後・GitHub PR 上 | APPROVE / REQUEST CHANGES |
ポイントは、この承認境界を「プロンプトのお願い」ではなく仕組みとして固定することです。たとえば v8.6.0 では次のような不変条件を hook / CLI で検査できると公式 README に列挙されています（公式値、確認日: 2026-05-17）。
plan.mdなしの production code 編集を検知する- C-3 承認なしの実装をブロックする
- 承認後の
plan.md改変をplan_hashで検知する - 検証 evidence なしの PR 作成を検知する
- C-3 / C-4 承認なしのマージを検知する
hook による強制の実装詳細（10/10 hooks の内訳・Metrics v1 等）は、姉妹記事「PlanGate v8.6 Hookで承認境界を強制する」で扱います。本記事は概念入口に徹し、実装記事と役割を分けています。
段階的に導入できる（Level 1〜5）
PlanGate の入門でつまずきやすいのは「全部入りに見える」ことです。公式 README は すべての機能を最初から使う必要はない と明記し、5 段階の導入レベルを定義しています（公式 README、確認日: 2026-05-17）。
| Level | スコープ | 適用シーン |
|---|---|---|
| Level 1 | plan 承認だけ | AI に実装させる前に計画を承認したい |
| Level 2 | + handoff まで | 完了時の引き継ぎを標準化したい |
| Level 3 | + hooks / validate | scope / approval / evidence の不変条件を hook で強制したい |
| Level 4 | + metrics / outcome review | 改善判断を計測ベースで行いたい |
| Level 5 | + eval / timeline | dogfooding eval などの上級機能 |
公式は 初回利用者は Level 1 から始める ことを推奨しています。Level 4 以降は経験を積んでから検討、という運用指針も README に明記されています。「まず plan 承認だけ」を入口にできるのは、入門のハードルを大きく下げます。
最初の一歩（導入の入口）
公式の導入手順はおおむね次の流れです（公式 README、確認日: 2026-05-17。コマンドは記事執筆時点の公式表記）。
# Option A: clone + plugin 登録（推奨）
git clone https://github.com/s977043/plangate.git
cd plangate
# Claude Code plugin 登録手順に従う、または .claude/ をコピー
clone / plugin 導入だけでは hook 強制は配線されません。導入先で次の 1 コマンドを実行して .claude/settings.json への hook 配線を確立します（公式 README）。
bin/plangate doctor --fix # 変更前に確認を求める
bin/plangate doctor --fix --dry-run # 書き換えず変更計画だけ確認
--fix は settings.example.json を正本に hooks を merge-only で適用し、実行ビット付与・.gitignore 追記・docs/working/ 作成を行う、と README に説明されています。最初は --dry-run で差分を見るのが安全です（経験則）。
バージョンについての注意
PlanGate は更新が速いプロジェクトです。本記事執筆時点（確認日: 2026-05-17）の公式リポジトリの最新リリースは v8.6.0（"Harness Improvement Roadmap Phase 0/1 + Governance"、2026-05-03 公開、公式リリースページ）で、開発中の v8.7.0 は自己進化機能ではなく OSS 整備（段階的導入ガイド / Plugin 成熟化 / バージョニング安定性ポリシー） を主軸に据えていると公式 README に記載されています。
過去の解説（docs サイトの旧版表記など）に v7 系の記述が残っている場合がありますが、本記事の数値・機能は 執筆時点の公式リポジトリ（v8.6.0） を一次情報として確定しています。導入時は必ず最新のリリースページを確認してください。
まとめ：次のアクション
- PlanGate は「AI に承認なしでコードを書かせない安全な型」。自律エージェントの対極にある設計（公式 README）。
- 入口は Level 1（plan 承認だけ）。まず
--dry-runで差分を確認してからdoctor --fixする。 - 次に読むなら、ワークフローの実務（plan/todo/test-cases を先に書く進め方）を扱う中級記事と、v8.6 の hook 実装詳細記事へ。
FAQ
Q1. PlanGate は自律型 AI エージェントですか？
いいえ。公式 README は「自律エージェントを目指さない」と明記しています。人間が承認した計画・タスク・受入テストが揃うまで AI に実装させない、承認境界優先の設計です。
Q2. 最初から全機能を使う必要がありますか？
ありません。公式は Level 1（plan 承認だけ）から始めることを推奨しています。hooks / metrics / eval は Level 3 以降で段階的に追加できます。
Q3. C-3 と C-4 の違いは？
C-3 は「計画レビュー後・実装前」の承認ゲート（APPROVE/CONDITIONAL/REJECT）、C-4 は「AI 実装後・PR 上」の承認ゲート（APPROVE/REQUEST CHANGES）です（公式 README）。
Q4. 記事に書かれた版は最新ですか？
執筆時点（確認日: 2026-05-17）の公式リポジトリ最新リリース v8.6.0 を一次情報としています。更新が速いため、導入時は公式リリースページで最新版を確認してください。
Q5. 既存の Claude Code 設定を壊しませんか？
公式 README によれば doctor --fix は hooks を merge-only（既存キー温存）で適用し、実行前に確認を求めます。--dry-run で書き換えなしの差分確認も可能です。
References
- PlanGate 公式リポジトリ: https://github.com/s977043/PlanGate （確認日: 2026-05-17）
- PlanGate 公式ドキュメントサイト: https://s977043.github.io/PlanGate （確認日: 2026-05-17）
- PlanGate リリース v8.6.0: https://github.com/s977043/PlanGate/releases/tag/v8.6.0 （確認日: 2026-05-17）
- PlanGate リリース一覧: https://github.com/s977043/PlanGate/releases （確認日: 2026-05-17）
- 姉妹記事（v8.6 Hook 実装詳細）: /notionnext-blog/plangate-v86-hook-enforcement/
