AIに作業を委任するためのタスク分解術 — Phase/Stage/SubStageパターン

はじめに

AIコーディングエージェントにシステム移行のような大規模タスクを任せたい。 しかし「○○システムを移行して」と丸投げしても、良い結果は得られない。

本記事では、実際のプロジェクトで試行錯誤しながら確立した タスク分解の方法論 を紹介する。 ポイントは「AIが迷わず着手でき、人間が進捗を追え、レビューが回る」粒度にタスクを分解すること。

全体構成: 3層のタスク階層

Phase（フェーズ）  ← プロジェクトのマイルストーン（数週間〜数ヶ月）
  └─ Stage（ステージ）  ← 技術的なまとまり（数日〜1週間）
       └─ SubStage（サブステージ）  ← AIに1回で委任できる作業単位（数時間〜1日）

なぜ3層なのか

• Phase だけだと粒度が粗すぎて進捗が見えない
• Stage だけだとAIに渡すには大きすぎる
• SubStage まで分解すると、AIが1回のセッションで完了できるサイズになる

SubStageの設計原則

1. 終了条件を検証可能にする

曖昧な終了条件はAIが完了判断できない。

# Bad
- [ ] 適切に実装されている
- [ ] テストが十分にある

# Good
- [ ] `./gradlew test` を連続2回実行しても全てパスする
- [ ] XxxServiceクラスが YyyInterface を実装している
- [ ] プロセス終了コードが規約（0:正常/1:警告/2:異常）に準拠している

コマンド実行結果、ファイルの存在、テストパスなど 客観的に判定できる基準 にする。

2. Stage終了条件とSubStage終了条件の2層にする

### Stage2: メール送信機能

| SubStage | タイトル |
|----------|---------|
| Stage2-1 | メール送信基盤構築 |
| Stage2-2 | 通知メールA 実装 |
| Stage2-3 | 通知メールB 実装 |
| Stage2-4 | メール送信テスト |

**Stage終了条件:**          ← Stage全体のゴール（人間が確認）
- [ ] 2種類の通知メールが動作する
- [ ] モックSMTPでメール送信内容が検証済み

#### Stage2-1: メール送信基盤構築
**終了条件:**               ← SubStage単位のゴール（AIが判定）
- [ ] メール送信用のBean定義が存在する
- [ ] テスト用のモックSMTP設定が導入されている

Stage終了条件は「人間がマイルストーンを確認する」ため、SubStage終了条件は「AIが作業完了を判断する」ために使う。

3. インプット・アウトプット・後続依存を明示する

AIは文脈を持たない。何を読んで、何を出して、誰が使うのかを書く。

#### Stage1-2: DBテーブル・SQL分析

**インプット:**
- `docs/phase1/stage1-1/class-inventory.md` — 前SubStageの成果物
- テーブル設計書 — テーブル定義の原典
- 移行元ソース内のSQLファイル — SQL文の原典

**アウトプット:**
- `docs/phase1/stage1-2/table-usage.md` — テーブル使用一覧 → 後続: Stage2-2, Stage2-3
- `docs/phase1/stage1-2/sql-inventory.md` — SQL一覧 → 後続: Stage2-3, Phase2全般
- `docs/phase1/stage1-2/transaction-boundary.md` — トランザクション境界定義 → 後続: Stage1-3

**終了条件:**
- [ ] 機能ごとの使用テーブル一覧がドキュメント化されている
- [ ] 各DAOのSQLが一覧化されている
- [ ] トランザクション境界が明記されている

この構造により：

• AIは インプットを読んで、アウトプットの形式に従って成果物を作る
• 人間は 終了条件をチェックリストとして使う
• 後続タスクの担当者は アウトプットの所在がわかる

4. SubStageごとにフォルダを用意する

docs/
├── phase1/
│   ├── stage1-1/           ← SubStage専用フォルダ
│   │   ├── class-inventory.md          ← 成果物
│   │   ├── processing-flow.md          ← 成果物
│   │   └── reviews/                    ← レビュー結果
│   │       ├── review-1-correctness.md
│   │       ├── review-2-robustness.md
│   │       └── review-3-quality.md
│   ├── stage1-2/
│   │   └── .gitkeep        ← 未着手（構造だけ先に作る）

レビュー結果、中間成果物、メモなどを散逸させずに管理できる。 全SubStageのフォルダを最初に作っておくと、プロジェクトの全体像が見通せる。

5. テストの冪等性を終了条件に含める

副作用のある処理（DB書き込み、ファイル生成、メール送信等）を扱う場合、テストが2回目以降に壊れる問題を防ぐため、冪等性を明示的に要求する。

**終了条件:**
- [ ] テストの冪等性が確保されている
  - DB: テスト後にロールバック
  - ファイル: テスト後に生成ファイル削除
  - 外部サービス: モックをテスト後にリセット
- [ ] テストを連続2回実行しても全てパスする

計画を育てる: 対話的な改善プロセス

最初から完璧な計画は作れない。以下のサイクルで育てる。

Step 1: まずPhaseとStageを決める

大枠を決めて全体像を把握する。この段階ではSubStageは不要。

Step 2: StageをSubStageに分割する

AIに依頼できる粒度まで分解する。終了条件を付ける。

Step 3: 設計書・ソースコードを読み込む

既存の設計書を読むと、計画の抜け漏れが見つかる。よくある発見：

• 対象の数や範囲が想定と違った
• 起動方式やスケジューリングの前提が違った
• 単純と思っていた処理に複雑な分岐ロジックがあった
• 他システムとの連携が存在した

Step 4: 発見を計画にフィードバックする

設計書から得た知見でSubStageの内容・終了条件を更新する。 新しいSubStageの追加が必要になることもある。

Step 5: 横断的な観点を確認する

ひととおり計画ができたら、以下の観点で漏れをチェックする：

Step 6: レビューを回す

計画自体もレビュー対象。AIに3回のレビューイテレーション（正確性→堅牢性→品質）を実行させると、数値の不整合や記述の抜け漏れが見つかる。

進捗管理

SubStage単位の進捗管理ファイルを用意する。

| SubStage | タイトル | 状態 | 完了日 | 備考 |
|----------|---------|------|--------|------|
| Stage0-1 | プロジェクト雛形作成 | done | 2026-04-02 | レビュー済み |
| Stage0-2 | CI/CD構築 | todo |  |  |
| Stage0-3 | DB管理基盤 | todo |  |  |

状態は todo / in-progress / done の3段階で十分。 末尾にPhase別サマリーを付けると全体の進捗が一目でわかる。

AI委任のコツ

並列実行

依存関係のないSubStageは並列で実行できる。 例：「プロジェクト雛形作成」と「レガシーコード調査」は独立しているので同時にAIに投げる。

worktree分離

並列実行時はgit worktreeで分離すると、ファイル競合を避けられる。 各worktreeの成果物を確認後、mainにマージする。

レビューの自動化

各SubStageの完了後に3回のレビューイテレーションを実行する：

1. 正確性: 事実誤認、技術的な誤り
2. 堅牢性: エッジケース、依存関係の整合性
3. 品質: 可読性、冗長性、命名

観点を分離することで、1回のレビューでは見落とす問題を段階的に検出できる。

設計書の活用

レガシーシステムの設計書は .doc / .xls など、AIが直接読めない形式が多い。 PDFに変換するツールを用意しておくと、設計書の内容を計画に反映しやすい。

変換時の注意：

• 日本語の文字化け対策が必要
• 表計算ソフトのレイアウトは変換で崩れやすいので、元アプリケーション経由での変換が確実

まとめ

完璧な計画を最初から作ろうとしない。 対話的に育てる。AIに質問され、設計書を読み、計画を更新する。 そのサイクルが回る仕組みを作ることが、AI時代のプロジェクト計画の要点だ。

最新の30件