開発プロセス v3
文書ID: DESIGN-PROCESS-003
Issue: #351
作成日: 2026-04-07
更新: 2026-04-14（CEOフィードバック反映）
前版: DESIGN-PROCESS-002（2026-03-18, Issue #110）
ステータス: CEOレビュー待ち
v2からの主な変更:
- Issue管理の位置づけを修正 — 開発工程の起点ではなく「全会話の追跡単位」
- ブランチルール・コミットルール・PRテンプレートを追加
- テスト分類を4分類に更新（ロジック / プロトコル / 契約 / 受入）
- レビューフローに影響度別の重み付けを追加（軽微 / 中程度 / 重大）
1. Issue管理 — 追跡の仕組み
Issueは「開発フローの起点」ではない。全ての会話の追跡単位である。
1.1 Issueの自動作成
CEOがSlackでメッセージを送ると、bot.pyが以下を自動的に行う:
- メッセージを受信し、IF層へルーティング
- IF層が
direct（雑談・即答）以外と判断した場合、GitHub Issueを自動作成
- 以降のスレッド内のやり取りはIssueにコメントとして追記される
Issueが作られるもの（例）
| CEOの発言 | 種別 | Issue作成 | その先 |
|---|
| 「〇〇のバグを直して」 |
開発タスク |
作成される |
M層 → 開発プロセスに入る |
| 「この仕組みどうなってる？」 |
調査・質問 |
作成される |
M層 → 調査して回答。開発は不要かもしれない |
| 「新機能の設計考えて」 |
設計検討 |
作成される |
M層 → 設計フェーズ。実装に進むかはCEO判断 |
| 「おはよう」「ありがとう」 |
雑談（direct） |
作成されない |
IF層が直接応答 |
1.2 Issueのライフサイクル
Slackメッセージ
│
↓
bot.py 受信 → IF層にルーティング
│
├── direct（雑談）→ IF層が直接応答。Issue作成なし
│
└── direct以外 → GitHub Issue 自動作成（追跡開始）
│
├── 質問・相談 → M層が回答 → 解決したらIssueクローズ
├── 調査依頼 → M層 → W層(researcher)調査 → 報告 → クローズ
├── 設計検討 → M層 → W層(architect)設計 → CEO判断 → 実装 or 保留
└── 開発タスク → 【開発プロセスに入る（§2以降）】
開発プロセスは、Issueが作られた後にM層が「開発が必要」と判断した場合にのみ始まる。
Issueの存在 ≠ 開発タスク。Issueはあくまで「やり取りの追跡単位」。
1.3 Issue更新ルール
- フェーズ遷移時にIssueコメントで進捗を記録する（URL・ファイルパスを含める）
- 開発が発生した場合、ブランチ名・PR番号をIssueに紐づける
- クローズは全作業完了後（開発の場合はマージ完了後）
2. 開発プロセス概観
M層が「開発が必要」と判断した場合に、以下の開発プロセスが始まる。
【前提: Issue作成済み、M層が「開発が必要」と判断】
CEO IF層 M層 W層
│ │ │ │
│ ① 要求確認 │ │ │
│←───────────────│ │ │
│ OK │ │ │
│────────────────→│ │ │
│ │ ② バンドル+委任 │ │
│ │──────────────────→│ │
│ │ │ ③ 計画立案 │
│ │ │ （規模判定+ │
│ │ │ ブランチ作成） │
│ │ │───────────────────→│
│ │ │ │ ④ Phase1: 調査+設計
│ │ │←──────────────────│
│ │ │ M層レビュー │
│ ⑤ 設計書RV │ │ │
│←──────────────────────────────────│ │
│ OK │ │ │
│─────────────────────────────────→│ │
│ │ │───────────────────→│
│ │ │ │ ⑥ Phase2: 実装
│ │ │←──────────────────│
│ │ │───────────────────→│
│ │ │ │ ⑦ Phase3: RV+テスト
│ │ │←──────────────────│
│ │ │ │
│ │ │ ⑧ PR作成+マージ │
│ │ ⑨ 成果物返却 │ │
│ │←─────────────────│ │
│ │ 受入テスト │ │
│ ⑩ 受入確認 │ │ │
│←───────────────│ │ │
│ OK │ │ │
│────────────────→│ Issueクローズ │ │
軽微タスクの場合: ④（Phase1: 調査+設計）と ⑤（設計書レビュー）をスキップ。③の計画立案後、直接⑥（Phase2: 実装）に進む。
3. CEO確認ポイントと基準
原則: CEOが介在するのは最大3箇所。影響度に応じて軽減される（§11参照）。
CEOはIF層とのみ対話する。全てIF層経由で上がってくる。
| # |
タイミング |
何を確認するか |
判断基準（CEOの視点） |
応答の選択肢 |
| GP1 |
要求確認
IF層が言語化した要求を提示 |
- IF層の解釈が自分の意図と合っているか
- 受入基準（完了の定義）に過不足がないか
- スコープが適切か（やりすぎ・足りなさすぎ）
|
「IF層が言語化した要求文を読んで、自分がやりたいことと一致しているか」
技術的な実現方法はこの時点では不問。意図の一致だけ確認する
|
OK → 次へ
修正 → IF層が再言語化
中止 → タスク終了
|
| GP2 |
設計書レビュー
M層が作成した設計書を提示 |
- §1（要求）が意図と合っているか
- §5（テスト設計）で漏れがないか
- §6（受入基準）が妥当か
※ §4（技術設計）の詳細はAI側に委任。CEOは確認不要
|
「設計書の要求・テスト・受入基準を読んで、自分の期待と一致しているか」
承認された設計書は「契約」として機能する。以降の実装でCEO確認は不要
|
OK → 実装開始
修正指示 → 設計修正
中止 → タスク終了
|
| GP3 |
受入確認
IF層が受入テスト結果を提示 |
- IF層の受入テスト判定結果（PASS/FAIL一覧）
- 必要に応じて実際の動作を確認
|
「IF層が全項目PASSと判定しているか」+「自分で触ってみて問題ないか」
IF層の判定を信頼しつつ、最終的な感触を確認する
|
OK → クローズ
差し戻し → M層に戻る
|
3.1 設計書不要タスクのCEO確認
軽微なタスク（後述§5参照）では設計書レビュー（GP2）をスキップするため、CEO確認は2箇所になる。
| タスク規模 |
GP1 要求確認 |
GP2 設計書レビュー |
GP3 受入確認 |
| 軽微 バグ修正・設定変更 |
必須 |
スキップ |
必須 |
| 中規模 機能追加・改修 |
必須 |
必須 |
必須 |
| 大規模 新規システム・大幅改修 |
必須 |
必須 |
必須 |
4. 各エージェントの役割定義
4.1 IF層（Interface Layer）
| 項目 | 定義 |
|---|
| 責務 |
- 要求の理解・言語化: CEOの曖昧な発言を検証可能な要求文+受入基準に変換する
- ルーティング: 適切なM層への振り分け
- 受入テスト: 完成物が要求を満たしているか判定する
- CEO対話の窓口: CEOとの全コミュニケーションを仲介する
|
| やらないこと |
- 技術調査・コード分析（W層の仕事）
- 要件定義・設計判断（M層+W層の仕事）
- git操作（M層に委任）
- M層の作業内容への介入（ルーティング後は成果物受領まで待つ）
|
4.2 M層（Manager Layer）
| 項目 | 定義 |
|---|
| 責務 |
- 計画立案: IF層の要求をW層タスクに分解し、実行順序を決定する
- W層への指示: 各Workerに具体的なタスクを指示する
- 品質ゲート: W層の成果物をレビューし、品質基準を満たしているか判定する
- 統合: 複数W層の成果物を統合し、IF層に返却する
- 自律ループ制御: W層のNG→修正→再レビューを自律的に回す
- ブランチ・PR管理: ブランチ作成、PR作成、マージ判断
|
| M層レビュー原則 |
W層の成果物はM層が必ずレビューする。W層の報告を無条件に信頼しない。
NG → 具体的な修正指示とともにW層に差し戻す。
OK → IF層に返却（CEO確認が必要な場合はCONSULTを返す）。
|
4.3 W層（Worker Layer）
| Worker |
投入フェーズ |
責務 |
成果物 |
| researcher |
Phase 1 |
既存コードの調査・分析。影響範囲の特定。技術選択肢の比較。 |
調査レポート |
| architect |
Phase 1 |
設計方針の策定。ファイル構成・インターフェース定義。設計書HTML作成。 |
設計書HTML |
| coder |
Phase 2 |
設計書§4に基づくコード実装。テスト不合格時の修正。 |
コード変更（git commit） |
| reviewer |
Phase 3 |
コードレビュー。セキュリティ・品質チェックリスト検証。 |
レビュー結果（PASS/FAIL） |
| tester |
Phase 3 |
テスト作成・実行。4分類のテスト（§10参照）。 |
テスト結果レポート |
| docs |
任意 |
ドキュメント作成・更新。knowledge/への知見追記。 |
ドキュメントファイル |
フェーズスキップ規則（M層が判断）:
軽微タスク → Phase 2のみ（coder直行）
中規模タスク → Phase 1 → Phase 2
大規模タスク → Phase 1 → Phase 2 → Phase 3
4.4 Bot（bot.py）
| 項目 | 定義 |
|---|
| 責務 |
- Slackメッセージの受信・送信
- エージェントプロセス（claude CLI）の起動・停止
- タスク状態管理（TaskTracker）+ フェーズ追跡
- GitHub Issue自動作成・コメント追記
- ステータスメッセージの投稿・更新
|
| やらないこと |
判断・解釈。Botは純粋なインフラ層であり、メッセージの内容を理解しない。 |
5. 設計書必須ルール
5.1 タスク規模の判定基準
M層がIF層から要求を受領した時点で、以下の基準で規模を判定する。
| 規模 |
判定基準 |
設計書 |
例 |
| 軽微 |
以下の全てに該当:
- 変更ファイルが3個以下
- 既存のインターフェースを変更しない
- 新規テーブル・APIエンドポイントの追加がない
|
不要 |
バグ修正、設定値変更、テキスト修正 |
| 中規模 |
軽微に該当しない、かつ以下に該当:
- 新規ファイルが5個以下
- 既存アーキテクチャの範囲内で実装可能
|
必須 |
機能追加、既存機能の改修 |
| 大規模 |
以下のいずれかに該当:
- アーキテクチャ変更を伴う
- 新規ファイルが6個以上
- 複数のM層/W層が連携する
|
必須 |
新規システム構築、大幅なリファクタリング |
5.2 設計書の必須セクション
| セクション |
内容 |
中規模 |
大規模 |
| §1 要求 | CEOの原文 + IF層の言語化した要求 | 必須 | 必須 |
| §2 要件 | 機能要件・非機能要件の一覧 | 必須 | 必須 |
| §3 影響範囲 | 変更ファイル・影響を受ける既存機能 | 必須 | 必須 |
| §4 設計 | 技術設計（構造・インターフェース・処理フロー） | 必須 | 必須 |
| §5 テスト設計 | テスト項目・期待結果（4分類: §10参照） | 必須 | 必須 |
| §6 受入基準 | CEOの要求が満たされたと判断する条件 | 必須 | 必須 |
| §7 代替案 | 検討した代替案とPros/Cons | 任意 | 必須 |
| §8 移行計画 | 段階的移行のステップ（破壊的変更がある場合） | — | 該当時必須 |
6. 伝言ゲーム問題の解決策
6.1 コンテキストバンドル方式（v2で採用決定）
核心: 「通信経路」と「責務」を分離する。
M層の責務（計画・品質ゲート・統合）は維持しつつ、W層が参照できる情報にCEO原文+IF層言語化を含める。
IF層がM層に委任する際、以下のコンテキストバンドルを作成する。M層はこのバンドルをW層に渡す際、そのまま添付する（要約・省略しない）。
| コンテキストバンドルの内容 | 作成者 | 参照者 |
|---|
| CEO原文: Slackでの発言そのまま |
Bot（自動コピー） |
IF層, M層, W層 |
| 言語化した要求: IF層が構造化した要求文 |
IF層 |
M層, W層 |
| 受入基準: 完了の定義（PASS/FAIL判定用） |
IF層 |
M層, W層, IF層（受入テスト時に再参照） |
| M層の実行計画: W層への具体的な指示 |
M層 |
W層 |
7. 開発プロセス全体フロー
CEO IF層 M層 W層 AI Ops
│ │ │ │ │
│ Slackメッセージ │ │ │ │
│────────────────→│ │ │ │
│ │ IF分類 │ │ │
│ │ (bot: Issue自動作成)│ │ │
│ │ │ │ │
│ │ 要求の理解・言語化 │ │ │
│ │ + 受入基準策定 │ │ │
│ │ │ │ │
│ ① 要求確認 GP1 │ │ │ │
│←───────────────│ │ │ │
│ OK/修正/中止 │ │ │ │
│────────────────→│ │ │ │
│ │ │ │ │
│ │ ② コンテキスト │ │ │
│ │ バンドル作成+委任 │ │ │
│ │──────────────────→│ │ │
│ │ │ │ │
│ │ │ ③ 計画立案 │ │
│ │ │ （規模判定 + │ │
│ │ │ ブランチ作成 + │ │
│ │ │ W層タスク分解） │ │
│ │ │ │ │
│ │ │───────────────────→│ │
│ │ │ バンドル+指示 │ │
│ │ │ │ │
│ │ │ │ ④ Phase1: │
│ │ │ │ 調査+設計 │
│ │ │ │ │
│ │ │←──────────────────│ │
│ │ │ 設計書 │ │
│ │ │ │ │
│ │ │ M層レビュー │ │
│ │ │ OK → │ │
│ │ │ │ │
│ ⑤ 設計書RV GP2 │ │ │ │
│←──────────────────────────────────│ │ │
│ OK/修正/中止 │ │ │ │
│─────────────────────────────────→│ │ │
│ │ │ │ │
│ │ │───────────────────→│ │
│ │ │ │ ⑥ Phase2: 実装 │
│ │ │←──────────────────│ │
│ │ │ │ │
│ │ │───────────────────→│ │
│ │ │ │ ⑦ Phase3: │
│ │ │ │ レビュー+テスト │
│ │ │←──────────────────│ │
│ │ │ 全テストPASS │ │
│ │ │ │ │
│ │ │ ⑧ PR作成+マージ │ │
│ │ │ │ │
│ │ ⑨ 成果物返却 │ │ │
│ │←─────────────────│ │ │
│ │ │ │ │
│ │ IF層受入テスト │ │ │
│ │ （受入基準と照合） │ │ │
│ │ │ │ │
│ ⑩ 受入確認 GP3 │ │ │ │
│←───────────────│ │ │ │
│ OK/差し戻し │ │ │ │
│────────────────→│ │ │ │
│ │ │ │ │
│ │ Issueクローズ │ │ │
│ │ │──────────────────────────────────────→│
│ │ │ │ ⑪ 監査（非同期）│
│ │ │ │ │
8. フェーズ詳細
CEO
Slackでメッセージを送る（質問・相談・依頼、何でもよい）
Bot
受信 → IF層にルーティング → direct以外なら GitHub Issue自動作成
IF層
分類判断。開発が必要と判断した場合 → 以下の開発プロセスに入る
この段階では開発は始まっていない。Issueは追跡単位であり、開発タスクの起点ではない。
IF層
CEOの発言を理解し、以下を生成してCEOに提示する:
- 言語化した要求文: 検証可能な形に変換
- 受入基準: PASS/FAIL判定可能な完了定義
CEO
IF層の解釈が自分の意図と合っているか確認 → OK / 修正 / 中止
IF層
コンテキストバンドル（CEO原文 + 言語化要求 + 受入基準）を作成し、M層に委任する。
M層
- 規模判定: 軽微 / 中規模 / 大規模を判定
- ブランチ作成:
{division}/{issue番号}-{slug}（§9参照）
- フェーズ選定: Phase 1/2/3のどれを実行するか決定
- W層タスク分解: 各Workerへの具体的な指示を作成
M層がW層に渡すもの: コンテキストバンドル（そのまま添付）+ M層の実行計画・具体的指示
researcher
影響範囲の調査。変更対象ファイル・関数の特定。技術選択肢の比較
architect
設計書HTML作成（§1〜§6）。テスト設計を含む
M層
設計書の品質レビュー。W層の成果物を統合
成果物: 設計書HTML（M層レビュー済み）
軽微タスクではスキップ。直接Phase 2に進む。
CEO
設計書を確認。§1（要求）、§5（テスト）、§6（受入基準）を重点確認
CEOの選択肢: OK（実装へ）/ 修正指示 / 中止
承認された設計書 = 契約。以降の実装・テストでCEO確認は不要。M層が自律的に進める。
軽微タスクではスキップ。
coder
設計書§4に基づくコード実装（軽微タスクの場合はM層の指示に基づく）
M層
coderの成果物をレビュー。NG → 修正指示 → 再レビュー（自律ループ）
成果物: コード変更（git commit）。コミットメッセージ末尾に (#Issue番号) を含める。
reviewer
コードレビュー。セキュリティ・品質チェックリスト検証
tester
4分類のテスト作成・実行（§10参照）
M層
レビュー指摘・テスト不合格時、coderに修正指示 → 再テスト（自律ループ）
軽微タスクではPhase 3をスキップ可能。M層の判断で構文チェック+最低限のテストのみとする。
M層
- PR作成（PRテンプレートに従う。§9参照）
- 影響度に応じた承認フロー（§11参照）
- Squash merge で main にマージ
IF層
M層からの成果物を受け取り、フェーズ①で策定した受入基準と照合する:
- 受入基準の各項目をチェック（PASS / FAIL）
- 要求の意図が実現されているか総合判定
- 判定結果をレポートとしてCEOに提示
IF層
受入テストレポートをCEOに提示
CEO
判定結果を確認。必要に応じて実際の動作を確認
CEOの選択肢: OK（クローズへ）/ 差し戻し（M層に戻る）
Bot
GitHub Issueに最終結果をコメント → クローズ
クローズ条件（全てAND）:
- テスト全項目PASS
- IF層の受入テストPASS
- CEO受入確認OK
- PRがmainにマージ済み
AI Ops
タスク完了後、非同期でスキャン:
- CLAUDE.md・knowledge/への反映漏れチェック
- 追記的更新 → 自動反映
- 破壊的更新 → IF層経由でCEO承認
メインフローをブロックしない。Issueクローズ後のバックグラウンド処理。
9. ブランチ・コミット・PRルール
9.1 ブランチ命名
| 項目 | ルール |
|---|
| 命名規則 |
{division}/{issue番号}-{slug}
例: vdu/351-dev-process |
| Division接頭辞 |
vdu/ ba/ sa/ oa/ hotfix/ |
| slug |
kebab-case、3〜4語以内 |
| main直接コミット |
禁止（CLAUDE.md変更 + CEO承認ありの場合のみ例外） |
| マージ方式 |
Squash merge |
| マージ後 |
ブランチ自動削除 |
9.2 コミットメッセージ
- 英語で記述
- 末尾に必ず
(#{Issue番号}) を含める
- 例:
Add rate limit backoff logic (#351)
- コミット前に
ruff + py_compile で構文チェック
9.3 PRテンプレート
PRには以下を含める:
- 概要: 何を・なぜ変えたか
- 関連Issue:
Closes #{番号}
- 変更内容: 変更ファイル一覧と概要
- 影響度: 軽微 / 中程度 / 重大（§11の承認フローに連動）
- テスト結果: ruff, pytest, 手動検証の結果
- M層レビュー所見
10. テスト分類
テストは依存関係の境界で4分類する。「単体テスト / 結合テスト」のような実行単位ではなく、何を検証するかで分ける。
| 分類 |
検証対象 |
具体例 |
担当 |
| ロジック |
外部依存のない純粋な処理 |
計算ロジック、データ変換、バリデーション、状態遷移 |
tester |
| プロトコル |
層間の通信規約 |
DELEGATE / STATUS / ACTION タグの形式、M→W指示フォーマット |
tester |
| 契約 |
外部APIとの境界 |
Slack API、GitHub API、MS Graph APIの呼び出し・レスポンス処理 |
tester |
| 受入 |
ビジネス要件の充足 |
設計書§6の受入基準、CEOの要求が満たされているかのE2E検証 |
IF層 |
ロジック・プロトコル・契約はtesterが作成・実行する。
受入テストはIF層が実施する（CEOの意図を最もよく知る層が担当）。
11. レビューフローと影響度別承認
11.1 レビューフロー
全てのコード変更は以下のフローを通過する:
- Coder自己チェック: ruff + pytest 実行
- M層レビュー: reviewer（W層）による品質チェック + M層による最終判断
- PR作成: 影響度に応じた承認フローへ
11.2 影響度別の承認ルール
| 影響度 |
判定基準 |
承認フロー |
例 |
| 軽微 |
- 変更ファイル3個以下
- 既存IFを変更しない
- 破壊的変更なし
|
M層 approve のみ |
バグ修正、設定値変更、テキスト修正 |
| 中程度 |
|
M層 approve + CEO事後確認
（マージ後にCEOに報告。ブロックしない） |
機能追加、既存機能改修 |
| 重大 |
- アーキテクチャ変更
- セキュリティ影響
- 破壊的変更あり
|
CEO approve 必須
（CEO承認なしにマージしない） |
レイヤ構造変更、認証変更、DB schema変更 |
main直接push、force pushはCEO承認が必須。影響度に関わらず。
12. 責務マトリクス
| フェーズ |
CEO |
Bot |
IF層 |
M層 |
W層 |
| Slack受信+Issue作成 |
起点 |
受信・Issue作成 |
分類 |
— |
— |
| ① 要求確認 GP1 |
判断 |
WAITING |
提示 |
— |
— |
| ② バンドル+委任 |
— |
— |
作成 |
受領 |
— |
| ③ 計画+ブランチ |
— |
— |
— |
主導 |
— |
| ④ 調査+設計 |
— |
— |
— |
レビュー |
実行
researcher, architect |
| ⑤ 設計書RV GP2 |
判断 |
WAITING |
— |
CONSULT |
— |
| ⑥ 実装 |
— |
— |
— |
レビュー |
実行
coder |
| ⑦ RV+テスト |
— |
— |
— |
統合判定 |
実行
reviewer, tester |
| ⑧ PR+マージ |
重大時のみ承認 |
— |
— |
主導 |
— |
| ⑨ 受入テスト |
— |
— |
主導 |
成果物提出 |
— |
| ⑩ 受入確認 GP3 |
最終OK |
WAITING |
レポート提示 |
— |
— |
| ⑪ Issueクローズ |
— |
Issue閉鎖 |
— |
— |
— |
13. v2からの変更点
| 項目 |
v2 |
v3 |
理由 |
| Issue管理の位置づけ |
開発フローの最初のステップ |
全会話の追跡単位。開発プロセスはIssue作成後にM層が判断して開始 |
CEOフィードバック: Issueは質問・相談でも作られる。開発起点ではない |
| テスト分類 |
単体テスト / 結合テスト / 構文チェックの3分類 |
ロジック / プロトコル / 契約 / 受入の4分類 |
依存関係の境界で分類する方が検証漏れを防げる |
| レビュー承認 |
一律のレビューフロー |
影響度別の3段階: 軽微（M層のみ）/ 中程度（+CEO事後確認）/ 重大（CEO必須） |
軽微な変更にCEO承認を求めるのは過剰。重大な変更は確実にCEO承認を得る |
| ブランチ・コミットルール |
明文化なし |
命名規則・コミットメッセージ・PRテンプレートを定義 |
一貫したgitワークフローの確立 |
| PR+マージフェーズ |
明示なし（Issueクローズ時にpush） |
独立したPR作成+マージフェーズを追加 |
PRベースのワークフローを正式プロセスに |
| フェーズ追跡 |
なし |
TaskTrackerにphaseフィールド追加。Slack進捗コマンド対応 |
タスク状態の可視化 |