PlanGate

PlanGate v6 ロードマップ – ハーネスエンジニアリング差分解消

v7 ハイブリッドアーキテクチャ: 本書の方向性を踏まえ、実行層を Workflow / Skill / Agent 3 層で再構築したのが v7。詳細は docs/plangate-v7-hybrid.md 参照。v6 は本書のロードマップとして維持される。

責務境界の大原則

PlanGateはスクラムのDone定義の中で「AIにコードを書かせるフェーズ」を安全に回す仕組みである。

以下はスクラムの責務であり、PlanGateのスコープ外とする:

PBIの情報管理・更新（リファインメント・プランニング）
Done条件の確認・判定（PO / スクラムチーム）
ベロシティ計測・スループット管理
フレームワーク変更の意思決定（レトロスペクティブ）
UIレベルのE2E検証（CI/CDの範囲）

PlanGateが担うのは、C-3承認後のexecフェーズ内部と、それを囲むAI制御の仕組みである。

ハーネスエンジニアリング差分の再分類

スコープ外（スクラム側の責務）

要素	理由
リポジトリ＝唯一の真実の源泉（C4）	PBI情報管理はNotionとスクラムイベントで担保済
ADRによるハーネス変更追跡（O5）	フレームワーク変更の意思決定はレトロスペクティブの範囲
スループット・人間負荷のメトリクス（O7の一部）	スクラムチームのベロシティ計測の範囲
エージェント検証可能アプリケーション（F6）	Done条件の検証はPO/チームの責務。UI E2EはCI/CDの問題

PlanGateのスコープ内（v6候補）

優先度	要素	概要	期待効果
P1	決定論的フック（A3）	Claude Code HooksでIron Lawを100%強制	CLAUDE.md遵守率~70% → 100%
P2	ガベージコレクション（O1）	定期的バックグラウンド品質スキャン+自動リファクタリングPR	AI生成コードの経年劣化防止
P3	段階的ルール昇格（F2）	Iron Lawの強制レベルをデータ駆動で進化	ルールの持続的改善サイクル確立
P4	推論サンドイッチ（A7）	plan/V系=高推論、exec=標準	コスト最適化+タイムアウト回避
P5	ファセットプロンプティング（C7）	workflow-conductorのプロンプトを関心事分離	ルール変更時の影響範囲最小化

境界が曖昧（チームと要相談）

要素	論点
漸進的コンテキスト開示 / Skills（C3）	CLAUDE.mdの設計問題だがチームの開発基盤に影響
サブエージェント（A6）	マルチエージェント構成はチーム全体のアーキテクチャ判断
トレース分析（F5）	レトロでの改善材料として使うならスクラム側
TAKT YAML宣言型エンジン（A4）	3コマンドシステムの代替となる可能性。チーム合意が必要

P1: 決定論的フック（Claude Code Hooks）

背景

CLAUDE.mdの指示遵守率は約70%。Iron Lawが破られる可能性が30%存在する。AnthropicのHooksは13種のライフサイクルイベントに紐づくシェルスクリプトで、100%強制される。

実装イメージ

Iron Law	Hook種別	実装例
NO EXECUTION WITHOUT REVIEWED PLAN	PreToolUse	execコマンド実行前にreview-self.mdの存在を検証。なければ`exit 1`でブロック
NO SCOPE CHANGE WITHOUT USER APPROVAL	PreToolUse	plan.mdのIn Scope外のファイルへの編集を検出・ブロック
NO MERGE WITHOUT TWO-STAGE REVIEW	Stop	PR作成前にV-3完了ログの存在を検証。未完了なら`exit 2`で続行強制
NO COMPLETION CLAIMS WITHOUT EVIDENCE	Stop	status.mdにテスト全パス証拠がなければ`exit 2`

導入ステップ

.claude/settings.jsonにhooksセクションを追加
最も違反頻度の高いIron Law 1つからパイロット開始
1週間のトライアルで誤検知率を計測
問題なければ全Iron Lawに拡大

スコープ制約

PlanGate内部のAI制御に限定。スクラムイベントには影響しない
HooksはClaude Codeの設定ファイル内で完結
チームへの影響: 「今まで通っていた操作がブロックされる」場合があるため、パイロット期間が必要

P2: ガベージコレクション

背景

OpenAIが実践。定期的にバックグラウンドタスクを実行し、AIが書いたコードの経年劣化を検知・修復する。

実装イメージ

GitHub Actionsで週次定期実行
検査対象: リンター違反・型エラー・構造テスト違反・未使用コード
決定論的ルールのみで検査（AIの「判断」に依存しない）
結果: 自動リファクタリングPR作成（軽微なものは自動マージ候補）

スクラムとの接点

ガベコレPRはPBIとは無関係に発行される
スプリント計画には影響しない（バックグラウンド実行）
重大な問題が見つかった場合のみチームにエスカレーション

P3: 段階的ルール昇格

背景

GMOの4段階エスカレーションラダー（L1ドキュメント → L2 AIセマンティック → L3 CI → L4構造テスト）をPlanGate用に適応させる。

PlanGateへの適応イメージ

GMOのレイヤー	PlanGateでの対応	現状
L1ドキュメント	CLAUDE.mdのIron Law	対応済
L2 AIセマンティック	C-1/C-2+V-3	対応済
L3 CI	L-0（v5）+exec（TDD）	v5で対応
L4構造テスト	V-4（詳細未定義）	v6でV-4に組み込む

昇格メカニズム

V-3で週次3回以上検出されたパターン → L-0のリンタールールへの追加を検討
L-0で繰り返し検出されるパターン → 構造テスト（V-4）への昇格を検討
昇格判断はデータ駆動（違反頻度の集計に基づく）

P4: 推論サンドイッチ

背景

LangChainの実証。計画フェーズ＝xhigh、実装フェーズ＝high、検証フェーズ＝xhighという推論計算量の戦略的配分。全工程xhighよりスコアが高かった。

PlanGateへの適用

フェーズ	推論レベル	理由
plan（B）	高	計画の質が全体を左右
C-1/C-2	高	レビューの見落とし防止
exec（D）	標準	タイムアウト回避+コスト最適化
V-1〜V-4	高	検証精度の最大化

導入条件

Claude Codeのモデル設定でフェーズごとの切り替えが可能かの技術検証が必要
最初はplanとexecでモデルを分けるシンプルな実験から

P5: ファセットプロンプティング

背景

成瀬允宣（TAKT作者）の提唱。プロンプトを5つの直交する関心事（Persona/Policy/Instruction/Knowledge/Output Contract）に分解。ルール変更時にPolicyだけ修正すれば全役割に自動反映されるDRYな設計。

PlanGateへの適用

workflow-conductorの8つの役割のプロンプトをファセット分解
C-1の15項目レビューとC-2の外部AIレビューでPolicyファセットを共有
Iron LawをPolicyファセットとして切り出すことで、ルール変更の影響範囲を最小化

前提条件

P1（フック）とP3（段階的昇格）が先行していることが望ましい
ファセット分解はworkflow-conductorの内部構造変更であり、チームに見えるインターフェース（3コマンド）は変わらない

実装ロードマップ

フェーズ	内容	前提	目安
Phase 1	P1: 決定論的フック導入（1ルールからパイロット）	v5トライアル完了	1-2週間
Phase 2	P1: 全Iron Lawへのフック拡大	Phase 1の誤検知率確認	1週間
Phase 3	P2: ガベージコレクション（GitHub Actions定期実行）	P1完了（検査ルールが確立）	2-3週間
Phase 4	P3: 段階的ルール昇格の仕組み構築	P2完了（違反データの蓄積）	2-3週間
Phase 5	P4: 推論サンドイッチ実験	並行実施可	1週間
Phase 6	P5: ファセットプロンプティング適用	P1+P3完了	2-3週間

合計目安: 8-12週間（Phase 5は並行実施可）

PlanGateのポジショニング

v6が完了すると、PlanGateはハーネスエンジニアリング4領域のうち、スクラムの責務外の要素を除きほぼ全域をカバーする。

ハーネス領域	v3	v4	v5	v6（予定）
コンテキスト設計	対応済	対応済	対応済	対応済
行動設計	対応済	対応済	対応済	強化（Hooksで100%強制）
フィードバック設計	部分的	対応済	強化（L-0）	さらに強化（段階的昇格）
運用設計	部分的	部分的	部分的	対応（ガベコレ）

PlanGateの独自の価値は「ゲートベースの厳格な人間承認」と「スクラムへの自然な組み込み」にある。ハーネスエンジニアリングの「環境設計」思想を取り込みつつ、PBI単位の開発フローとスクラムのリズムを崩さないことが大原則である。

This site is open source. Improve this page.