Status: Stable Review cadence: Monthly Owner: Product / Maintainer これは何: PlanGate 導入検討者が最初に読む 1 ページ。3 分で「自分に必要か」を判断し、5 分で導入を始められるように構成しています。
PlanGate は、AI コーディングエージェントを 承認境界・監査可能性・スクラム親和性 を保ったままプロダクト開発へ接続するためのゲート型ハーネスです。
AI がいきなり本番コードを書くのではなく、まず 何を作るか / Done は何か を成果物として固定し、人間が承認してから実装へ進みます。
No approved plan, no code.
PlanGate は AI ツールの代替ではありません。Claude Code / Codex などの実行エージェントの 上位に乗せる補完レイヤー として、速度を落とさずに統制を取り戻します。
AI 開発で次のいずれかに心当たりがあれば、PlanGate が効きます。
| 価値 | 何が起きるか | 主に効く人 |
|---|---|---|
| 間違ったものを速く作るリスクを止める | AI は C-3 承認前に本番コードを書けない。何を作るか・Done は何かを実装前に成果物として固定し、AI の先回りをワークフローで抑える | PM / PO / EM |
| 承認境界を 2 ゲートに集約 | 人間判断を C-3（実装前の計画承認）と C-4（PR 最終レビュー）の 2 点に集約。APPROVE / CONDITIONAL / REJECT の三値で残す。過剰監視でもフル自律でもない中間設計 | EM / CTO / Tech Lead |
| 会話ログでなく成果物で監査できる | plan / review / verification / handoff を docs/working/ に残す。承認後の plan 改変は plan_hash、scope 外編集は forbidden_files を hook（12/12 実装済）で機械検知 |
CTO / 監査・規制対応チーム |
さらに、
損益分岐点の目安: 3 人以上 & 3 ヶ月以上続くプロジェクトで効果が出ます。単発の使い捨てスクリプトには過剰です。
| 観点 | 自律エージェントフレームワーク | PlanGate |
|---|---|---|
| 最適化する対象 | 自律性・速度・タスク完遂 | 承認境界・監査可能性・スクラム親和性 |
| 人間の関与 | 最小化する | C-3 / C-4 の 2 点に集約して固定する |
| AI ツールとの関係 | それ自体が実行主体 | 実行エージェントの上位ハーネス（代替ではなく接続） |
| 成果物 | 主にコード | plan / review / verification / handoff（全て Markdown） |
PlanGate は「AI をどれだけ自由に走らせるか」ではなく、「どこで人間が止め、何を証跡として残すか」 を設計するためのレイヤーです。
導入は実質 3 コマンドです。
Claude Code セッション内:
/plugin marketplace add s977043/PlanGate
/plugin install plangate
CLI から（Claude Code / Codex 両対応, v8.11.0〜）:
# Claude Code
claude plugin marketplace add s977043/PlanGate
claude plugin install plangate
# Codex（marketplace 登録 → スキル展開）
codex plugin marketplace add s977043/PlanGate
sh install.sh --codex
次のステップ 2・3 を実行するには、PlanGate リポジトリの clone が必要です。 Marketplace 導入はスキル / コマンドを配布しますが、ゲートを機械強制する
bin/plangateと hook 本体は PlanGate リポジトリに含まれます。clone してそのルートで作業してください。git clone https://github.com/s977043/PlanGate.git cd PlanGate # 以降のコマンドはこのルートで実行前提:
python3（hook / doctor が使用）。python3 --versionで確認できます。
承認境界の保護（plan_hash / forbidden_files）は hook で機械強制されます。これを配線しないと保護が無効 です。PlanGate リポジトリのルートで実行します。
bin/plangate doctor --fix
# 事前に差分を確認したい場合
bin/plangate doctor --fix --dry-run
# CI など非対話環境
bin/plangate doctor --fix --yes
同じく PlanGate リポジトリのルートで実行します。
bin/plangate init <TASK-番号> # 例: bin/plangate init TASK-0001
# 対象ファイルを直接編集してコミット
bin/plangate doctor # ハーネスの健全性を確認
ultra-light モードでは計画フェーズを省略し、1 タスクを最後まで通す体験 に集中できます。
最初から全部使う必要はありません。チーム合意の上で、フェーズ境界ごとに強度を上げていきます。
| Phase | やること | ゲート強度 |
|---|---|---|
| Phase 0 | ultra-light で 1 タスクを最後まで完了。ツールに慣れる | hook 配線のみ |
| Phase 1 | 計画を書く習慣をつける。PBI INPUT → plan.md → C-3 承認 → exec → PR → C-4 を light モードで運用 |
C-3 / C-4（warning） |
| Phase 2-3 | EH-1〜EH-7 を warning→block へ昇格 + EH-9、standard 以上で V-3 外部レビュー必須化 | フル運用（block） |
Phase の詳細・各コンポーネントの昇格手順は 段階的導入ガイド を参照してください。
迷ったら Phase 0 を 1 タスクだけ 試してください。チーム全体の合意も、フル運用の決断もまだ要りません。git clone → bin/plangate doctor --fix → bin/plangate init TASK-0001 の 3 コマンドで、AI が承認前にコードを書かない体験を 5 分で確認できます。合わなければ捨てるだけ、コストはほぼゼロです。
ツールは導入した瞬間が完成形になりがちで、半年後には現場とずれていきます。PlanGate は固定されたワークフローではなく、製品自身を測りながら改善し続けるハーネスです。だから、今効くだけでなく、使い続けるほど現場に合っていきます。
PlanGate には製品自身を育てる改善ループが組み込まれています。「感覚で仕様を足す」のではなく「測って判断する」ため、機能は思いつきで膨らまず、現場に効いたものだけが残ります。
仮説 → 変更 → eval（評価）→ 計測 → 採用 / rollback → 振り返り
これまでに計画された改善フェーズは、設計・ガバナンス・品質チェックまで含めて全工程を完走済みです。「将来の約束」ではなく、すでに走り切った実績がこの改善文化を裏づけます。
継続改善は「なんでも自動化して暴走させる」ことではありません。C-3 / C-4 の人間ゲートと検証は弱めず、LLM の判定を最終ゲートにもしません。 守るべき承認境界は固定したまま、使い心地と品質だけを磨き続けます。これが「速度を落とさず統制を保つ」という本ページの主張を、リリースを重ねても裏切らない理由です。
改善ループとロードマップ、およびこれまでの実績の詳細は Harness Improvement Roadmap を参照してください。
| ドキュメント | 内容 |
|---|---|
| はじめる（Getting Started） | 3 ステップで基本的な流れを手を動かして体験する |
| 段階的導入ガイド | Phase 0 〜 Phase 3 の成長パスと各フェーズで使うコンポーネント |
| Product FAQ | 導入検討時の FAQ / 反論処理 |
| Product Overview | 概要、対象ユーザー、価値、仕組み |
| Positioning | 競合・代替手段との差別化 |
| Harness Improvement Roadmap | 継続改善ループとロードマップ、および実績の詳細 |