PlanGate は すべての AI コーディング に向くわけではありません。以下のケースでは導入コストの方が便益を上回ります。
理由: PBI INPUT PACKAGE → plan → C-3 承認 → exec の正規フローが overhead になる。 代替: 直接 AI に依頼 (Cursor / Copilot)、後で正規化が必要なら PBI 化。
理由: PlanGate の中核は 人間承認ゲート (C-3 / C-4) であり「承認なしで AI に書かせない」を絶対化する。完全自律と相反。 代替: LangGraph / AutoGen / 独自 agent framework。
理由: PlanGate は docs/working/TASK-XXXX/ の Markdown を「正本」とする。外部 SaaS と二重管理になる。
代替: SaaS の Webhook / API で承認境界を実装。
理由: PlanGate のガバナンスコスト (PBI 記入 / C-3 承認 / handoff 発行) は 3 人以上のチーム & 3 ヶ月以上の継続運用 で元が取れる設計。 代替: Cursor + git だけで十分。
理由: PlanGate の hook / gate は秒〜分単位の人間判断を介在させる。millisec オーダーでは不適。 代替: GitHub Copilot / Cursor の inline completion。
PlanGate を採用する場合、以下のコストを受け入れる必要があります。
| コスト | 内容 | 緩和策 |
|---|---|---|
| PBI 記入コスト | Why / What / AC / Constraints / Non-goals を毎タスクで明文化 | テンプレ化、bin/plangate brainstorm で対話的生成 |
| C-3 承認の同期遅延 | 人間が plan を読んで判定するまで exec 待機 | lite_eligible で非同期降格 (条件付き)、light mode で簡略化 |
| 学習負荷 | EH-X / WF-XX / V-X / C-X 略号、mode 分類、責務 4 分類 | glossary.md でクイックリファレンス、Staged Adoption Guide で段階導入 |
| handoff 維持コスト | 全 PBI で 6 要素 handoff.md を発行・保管 | テンプレ自動生成 (bin/plangate handoff)、light mode で簡易版 |
| hook の摩擦 | EH-1〜EH-9 が誤検知する局面がある | PLANGATE_BYPASS_HOOK=1 で一時 bypass (監査ログ記録) |
参考までに、PlanGate が最も価値を出すシナリオ: