開発エージェント活用方法 ― Why / What / How で構造化する設計ドリブン開発
概要
本記事では 開発エージェント (Cursor, Github Copilot Agent, Claude Code, Devinなど) を主役に据え、人間は副操縦士として
設計 と ドメイン判断 に集中する開発スタイルを解説します。Why / What / How でタスクを階層化し、
エージェントに最小単位の How を委譲することで スピード・品質・学習コスト を最適化します。
1. 考え方の転換 — Pilot Shift
1‑1 実装という操縦席をエージェントに譲る
GitHub Copilot が登場した 2021 年当時、エージェントは 副操縦士 でした。しかし 2025 年の現在、
最新モデルは大半の開発者よりも広範な実装知識と生成速度を備え、人間がレビューと意思決定に回る構図 が現実的になりました。
2021年:人間が操縦士、エージェントが副操縦士
2025年:エージェントが操縦士、人間が副操縦士
1‑2 期待値思考で判断する
イメージ: 「1 つの機能を完成させるまでに平均で何時間かかるか?」で比べる。
実装手段 | 1 回あたり所要時間 | 1タスク平均成功率 | 機能 1 つを仕上げる平均時間 |
---|---|---|---|
人間のみ | 1 時間 | 90 % | 約1.11 時間 (1 ÷ 0.9) |
エージェント主導 | 0.2 時間 | 50 % | 0.4 時間 (0.2 ÷ 0.5) |
多少やり直しが発生しても、トータルで効率的なら迷わずエージェントを使う──これが期待値思考です。
※ここでは品質について考慮してないですが、後述の設計がきちんとしていれば、ほとんどの場合、シニアのエンジニアに匹敵するでしょう(主観)
2. 方法論概要
フェーズ | ゴール | 主担当 | 産物 |
---|---|---|---|
概要設計 | Why / What を定義してスコープ確定 | 人間 + Agent(Thinking モデル推奨) | *_task_overview.md |
詳細設計 | 各フェーズの How をブレイクダウン | 人間 + Agent | phases/*_detail.md |
実装 | コード生成・テスト自動実行 | ほぼAgentのみ | コード & PR |
検証 | 手動チェック & 結果ファイル化 | 人間 + Agent | results/*_result.md |
コツ : How を 1 タスク = 1 プロンプトで完結する粒度に保つと、再実行コストを最小化できます。
3. フェーズ別ガイド
3‑1 概要設計
- Why : 課題と成功基準 (KPI) を 1 行で定義。
- What : 必要機能・制約・完了条件を列挙。
- How : まだ書かない。次フェーズに委譲。
3‑2 詳細設計
- 各 What を エージェント実行可能な How に落とし込む。
- 擬似コード・I/O 例・テストケースを具体化。
- "チェックリスト" を添付し、Agent が自己検証できるようにする。
3‑3 実装と検証 — “作って → 測って → 次へ” の小刻みループ
- 実装依頼 : 各フェーズ、もしくはその下位ステップを 1 つずつエージェントに実装させる。
- 完了判定 : 出力がチェックリストを満たすかを エージェントまたは人間 がレビュー。
- 次フェーズへ : 合格なら次のタスクへ進み、不合格ならフィードバックして再実行。
このループにより、ミスは早期に発見・修正され、1 回あたりのリトライコストも小さく済みます。
3‑4 結果報告とドキュメント化
- 合格したアウトプットとレビュー結果を
results/
に保存。 - 以降のフェーズや将来のリファクタで再利用できるよう、情報を資産化します。
3‑5 詳細手順修正(オプション)
- 各フェーズの実行後、必要に応じて手順を修正。
- 例えば、テストケースが不十分だった場合、次回は「テストケースを 3 つ以上作成する」といった修正を加えます。
4. ディレクトリ構成例
implementation-docs/
├── <task>_overview.md
├── phases/
│ ├── phase1_detail.md
│ ├── phase2_detail.md
│ └── ...
└── results/
├── phase1_result.md
├── phase2_result.md
└── ...
5. 成功のコツ
- Why → What → How の順序を死守する。
- 設計・実装結果をすべてテキストファイルでバージョン管理。
- 設計には Thinking モデル、実装には Implement モデルを使い分ける。
- 否定形より肯定形プロンプトの方が実装精度は高い。
エージェント別ベストプラクティスと公式ドキュメント
エージェント | 粒度分解に関する公式推奨ポイント | 公式リソース |
---|---|---|
Devin | * 大きな課題は 先に分割 して渡すのが推奨。 * 1 セッション ≒ 3 h 以内を想定。 * プロンプトが長大な場合、Devin 自身が粒度分解を促す。 |
Release Notes |
OpenAI Codex | * 1 コマンド=1 目的 が基本設計。 * Starter Tasks (テスト生成・バグ修正など) = 小粒タスク例として提示。 |
Codex CLI Getting Started / Codex in ChatGPT FAQ |
Cursor | * Rules 機能でプロジェクト・ユーザ単位の “ステップ指針” を明示。 * AI が常にルールを読み込むことでタスク境界がはっきりする。 |
Rules for AI |
GitHub Copilot Agent | * Well‑scoped issues が必須条件として列挙。 * 複雑/曖昧タスクは 人間が細分化 してから渡す。 |
Best Practices |
Dynamic Task Decomposition (研究) | * グラフ分解+ツール選択で agent の成功率・コスト効率を改善。 | Li et al. 2024 Paper |
まとめ
設計段階でタスクを粒度良く Why / What / How へ分解し、実装をエージェントに任せることで、
開発者は 戦略・品質・ドメイン価値 に集中できます。判断基準は「効率的か?」──
完璧主義を捨て、期待値思考でハンドルを渡す。それが 2025 年版の開発ワークフローであると考えています。
Discussion