PlanGate実践：計画を先に書いて承認するWF

TL;DR

• PlanGate の中核アイデアは 計画先行：PBI から plan / todo / test-cases を作り、承認前の実装を禁止する（公式 README、確認日: 2026-05-17）。
• 実務フローは /working-context → /ai-dev-workflow <TASK> plan →（C-3 人間承認）→ /ai-dev-workflow <TASK> exec の 3 ステップ（公式 README クイックスタート）。
• 状態は docs/working/TASK-XXXX/ に計画・レビュー・検証・handoff として永続化される。会話は流れても成果物は残る設計。最新は v8.6.0（公式リリース、確認日: 2026-05-17）。

はじめに

こんにちは、みねです。

この記事は PlanGate 入門（概念編）を読んだ方向けの 中級記事 です。概念編では「承認なしにコードを書かせない道具」だと説明しました。本記事ではその核心である 計画先行ワークフロー——plan / todo / test-cases を実装より先に書く進め方——を、公式リポジトリの一次情報で具体化します。

この記事のゴール:

• PBI から計画を起こし C-3 承認を経て実装する一連の手順を、自分の TASK で再現できるようになる
• なぜ「会話ではなくファイルに状態を残す」のかを説明できるようになる

計画先行とは何か

PlanGate の中核アイデアは公式 README に明記されています（公式 README、確認日: 2026-05-17）。

ポイントは「実装の前に、検証可能な受入基準（test-cases）まで含めて計画を固める」ことです。曖昧なまま AI に実装させると、後半でスコープがずれます。先に test-cases を書いておくと、AI の実装が計画に一致しているかを機械的に判定できます。

PlanGate 全体の流れは公式 README が次のように図示しています。

人間が PBI を書く → AI が計画を生成 → [C-3: 人間が承認]
→ AI が実装（TDD）→ 自動検証（L-0, V-1…V-4）
→ PR 作成 → [C-4: 人間が GitHub でレビュー] → マージ

実務フロー：3 ステップ

公式 README のクイックスタートは 3 コマンドです（公式 README、確認日: 2026-05-17。コマンド表記は記事執筆時点の公式値）。

# 1. 作業コンテキスト作成
/working-context TASK-XXXX

# 2. Plan + ToDo + Test Cases 生成、セルフレビュー
/ai-dev-workflow TASK-XXXX plan

# 3. [C-3 ゲート] 人間がレビュー後、実行
/ai-dev-workflow TASK-XXXX exec

ステップ 1：作業コンテキストを作る

/working-context TASK-0001 で docs/working/TASK-0001/pbi-input.md と関連成果物が作られます（公式 README 10 分チュートリアル）。

ステップ 2：PBI を人間が記入する

pbi-input.md に Why（解決する問題）/ What（スコープ内外）/ 受入基準（検証可能・テスト可能な条件） を書きます。ここを人間が書くのが計画先行の起点です。受入基準が曖昧だと後工程が全部ぶれます（経験則）。

ステップ 3：計画生成 → C-3 → 実行

/ai-dev-workflow TASK-0001 plan で AI が plan.md / todo.md / test-cases.md / review-self.md を生成します。次に C-3 ゲート——人間が plan.md を読み、次のいずれかを判断します（公式 README）。

• APPROVE → exec に進む
• CONDITIONAL → 必要な修正を記録して進む
• REJECT → PBI を修正して計画を再生成する

承認後に /ai-dev-workflow TASK-0001 exec で実装に入ります。承認前の実装は禁止——これを「お願い」ではなく hook で強制する仕組みが、姉妹記事「PlanGate v8.6 Hookで承認境界を強制する」で解説されている v8.6 の Hook Enforcement です（v8.5 から plan / approval / evidence / scope / review の不変条件を hook と CLI で検査、公式 README）。

なぜファイルに状態を残すのか

公式 README は「状態の永続化」を中核アイデアの一つに挙げ、docs/working/TASK-XXXX/ に計画・レビュー・検証・handoff を残すと述べています（公式 README、確認日: 2026-05-17）。

AI とのやり取りは会話として流れて消えます。しかし PlanGate では合意（承認した plan）・判断（C-3/C-4）・証拠（検証結果）が TASK ディレクトリのファイルとして残る。これにより「誰がいつ何を承認したか」を後から説明でき、セッションが切れても TASK ディレクトリから再開できます。承認後の plan.md 改変は plan_hash で検知される、と概念編でも触れたとおり、計画の同一性も保たれます。

計画先行を回すときの注意（中級）

• test-cases を先に書く：受入基準を検証可能な形（TC として）に落としてから実装に入る。後付けの test は計画適合の判定に使えない（経験則）。
• C-3 を形骸化させない：CONDITIONAL を多用しすぎると承認境界が緩む。修正が大きいなら一度 REJECT して PBI から作り直す方が安全（経験則）。
• TASK ディレクトリを正本にする：会話で決めたことは必ず plan/todo/status へ書き戻す。「会話は流れるがファイルは残る」を運用で守る。

まとめ：次のアクション

• PlanGate の実務は「PBI → plan/todo/test-cases → C-3 承認 → exec」。先に検証可能な test-cases を書く。
• 状態は docs/working/TASK-XXXX/ に残す。会話ではなくファイルを正本にする。
• 概念の入口は PlanGate 入門、hook による強制の実装詳細は PlanGate v8.6 Hook 記事 を参照。

FAQ

Q1. なぜ実装より先に test-cases を書くのですか？

受入基準を検証可能な形にしてから実装すると、AI の実装が計画に一致しているか機械的に判定できるためです。公式 README は「PBI から plan/todo/test-cases を作り承認前の実装を禁止する」を中核アイデアに挙げています。

Q2. C-3 で CONDITIONAL を選ぶのはどんな時ですか？

公式 README では C-3 の判断は APPROVE / CONDITIONAL / REJECT。CONDITIONAL は「必要な修正を記録して進む」場合ですが、修正が大きい場合は REJECT して PBI から作り直す方が承認境界を保てます（経験則）。

Q3. 状態はどこに残りますか？

公式 README によれば docs/working/TASK-XXXX/ に計画・レビュー・検証・handoff が永続化されます。会話が切れても TASK ディレクトリから再開できます。

Q4. 承認した計画を後で書き換えたらどうなりますか？

PlanGate は承認後の plan.md 改変を plan_hash で検知します（公式 README）。承認した計画の同一性が保たれます。

Q5. 入門記事との違いは？

入門記事は「PlanGate とは何か・どの導入レベルから始めるか」を扱う概念入口です。本記事は計画先行ワークフローの実務手順に踏み込む中級編です。

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）

• シリーズ親（PlanGate 入門）: /articles/plangate-intro-gate-driven-dev/

• 関連記事（v8.6 Hook 実装詳細）: /articles/plangate-v86-hook-enforcement/

• Anthropic Claude 公式