フェーズ・状態色・依存ゲートで設計の正本を描く
― AI と人間が同じ図を見て手戻りを防ぐ

1.解決したい課題

1 つの機能を複数コミットに分けて段階導入するとき、進捗の状態は「文章のログ」に溜まりがちだ。文章ログには 3 つの弱点がある:

• 依存関係が読み取りにくい ― 「フェーズ B はフェーズ A の前提が真でないと無駄」という関係が、長い文章に埋もれる。
• 状態が一目で分からない ― 完了・保留・凍結・仮説が散文の中で混ざり、「いま何が止まっているか」を把握するのに読み込みが要る。
• 読み手によって解釈がぶれる ― 特に AI エージェントは、毎回ゼロから文脈を再構築するため、前提の確度を取り違えて未検証の前提のまま後続を実装してしまう。

結果として、誤った前提に基づく手戻りが起きる。本手法は、進捗を 1 枚の図に正本化し、特に依存ゲートを視覚的に明示することで、これを防ぐ。

2.手法の概要

段階導入タスクごとに、設計文書（テキスト正本）に加えてフェーズ・フロー図を 1 枚用意する。図は次の 3 要素を同居させる:

1. フェーズ番号（0 → 1 → 2 …）で時系列・依存順に並べる。各コミット段階に対応させる。
2. 状態色で各フェーズの状態を一目化する（完了・ブロッカー・凍結・仮説・要人手）。
3. 依存ゲートを矢印＋一言で挟む（「この前提が崩れると以降が無駄」「突破して初めて次が活きる」）。

原則は単純で、テキスト正本（設計文書）が真実、図はその視覚ビュー。状態が変わったら両方を同期する。図だけが更新されて文書が古い、という乖離を作らない。

3.図の構成要素

3-1. 状態色の語彙

3-2. 依存ゲートの書き方

フェーズの間に矢印を置き、「何が真でないと先に進めないか」を一言で添える。これが本手法の中核だ。ゲートが無い図は単なる進捗リストだが、ゲートがある図は「未検証の前提のまま後続へ進むこと」自体を止める装置になる。

フェーズ1：当初の仮説（⚙️ 要確証）
        ↓  この前提が真でないと、以降の実装は無駄になる
フェーズ2：安全な土台（✅ 挙動不変）
        ↓  緩和の前に、前提を実機で必ず確かめる
フェーズ3：前提検証（★最重要ゲート）
        ↓  前提が覆ったら → 後続は凍結
フェーズ4：判断（❄️ 凍結 / ⚙️ 真の経路へ）

4.実例：前提が覆って後続を凍結できた

本手法は、あるコメント収穫タスクで実際に手戻りを防いだ。当初の仮説は「配信サイトがコメント行から番号セルを外したので、受理判定を緩めれば直る」だった。この仮説を図のフェーズ 1（⚙️ 仮説）に置き、フェーズ 3 に「緩和の前に実機 DOM で前提を確かめる」依存ゲートを明示した。

効果: フェーズ 3 の依存ゲートが図にあったから、前提が間違っていた緩和（フェーズ 4 の本来の続き）を盲目的に実装せずに済んだ。図が無ければ、もっともらしい仮説のまま緩和を実装し、働いているガードを弱めて機能を退化させていた可能性が高い。

5.なぜこの設計なのか（原則）

1. 依存ゲートを視覚化することが本質 ― 進捗リストではなく「前提 → 後続」の依存を明示する。未検証の前提のまま進むことを止める。
2. 状態色で「いま止まっているもの」を即読する ― 散文を読み込まずに、赤（ブロッカー）と青（凍結）が一目で分かる。
3. AI と人間が同じ正本を見る ― AI は毎回ゼロから文脈を再構築するため、確度の取り違えが起きやすい。同じ図を参照させることで前提の解釈を揃える。
4. テキスト正本が真実・図は視覚ビュー ― 設計文書を真実とし、図はそれを映す。状態変化で両方を同期し、片方だけ古い乖離を作らない。
5. 「凍結」を一級市民にする ― 「やらない判断」を再開条件つきで明記する。中断を曖昧に放置せず、なぜ止めたか・いつ再開するかを残す。
6. 段階導入と相性が良い ― フェーズ番号がコミット段階に対応するので、図の更新と実装の進行が自然に同期する。

6.運用ルール（いつ作り・いつ更新するか）

• 作る対象 ― 段階導入（複数コミット）・前提に不確実性がある・真因究明を伴う、実質的なタスク。1 ファイル挙動不変の軽微な修正には作らない（過剰になる）。
• 置き場所 ― 設計文書（テキスト正本）と同じディレクトリに、視覚ビューとして 1 枚。先頭に設計文書へのリンクと最終更新日を入れる。
• 更新タイミング ― コミットで状態が変わったら（完了／凍結／前提否定）図の色とゲートを同期する。設計文書を更新するのと同じタイミングで図も直す。
• 更新の責務 ― 正本の更新者を 1 つに固定する（複数のツール／人が別々に書くと食い違う）。

7.関連する既知技術（先行技術）

7-1. Stage-Gate（フェーズゲート法）

製品開発で各段階の出口に「ゲート」を置き、次へ進むか止めるかを判定するマネジメント手法。本手法は、これを1 枚の図に圧縮し、AI も読める粒度に落とし込んだもの。

7-2. カンバン / 状態の可視化

作業項目を状態（To Do / Doing / Done 等）で色分け・列分けする可視化。本手法の状態色（完了／ブロッカー／凍結／仮説）はこの語彙を、依存関係を持つフェーズに適用したもの。

7-3. RFC / ADR（Architecture Decision Record）

設計判断とその背景・却下案をテキストで残す文化。本手法の「テキスト正本が真実・凍結理由と再開条件を残す」は、ADR の判断記録の発想と一致する。

7-4. 推測でなく観測で前提を検証する

「もっともらしい仮説」をコードに落とす前に、実機・実データで前提そのものを確かめる規律。本手法は、その検証を図の中の依存ゲートとして手順に強制する点が特徴。

8.本記事の位置づけ・ライセンス

本記事は、Chrome 拡張機能『君斗りんくの追憶のきらめき』の開発運用で 2026 年 6 月 18 日に確立した「フェーズ・状態色・依存ゲートによる設計正本図」の手法を、同日付で公開するものである。実プロジェクトでは設計文書（SYNTHESIS 等のテキスト正本）とセットで、視覚ビューの HTML を 1 枚用意し、AI エージェントと人間が同じ図を参照する運用を採っている。

手法は「フェーズ番号で依存順に並べる」「状態色で止まっているものを即読する」「依存ゲートで未検証の前提のまま後続へ進ませない」「テキスト正本が真実・図は視覚ビュー」という再利用可能な原則にまとめられる。先行技術として Stage-Gate 法・カンバン・RFC / ADR・CI の required check を参照した。

参考実装（図のテンプレート）は MIT、本記事文章は CC BY 4.0 のもとで自由に複製・引用可。