AIエージェントに仕事を渡すタスク分解テンプレ
「Claude Codeに作業を頼んだら、見当違いのことをやられた」「Copilot Agentが途中で止まって、何が問題かわからない」——こういう経験、ありませんか。
原因の多くは、タスクの渡し方にある。人間同士なら「いい感じにやっといて」で通じることも、AIエージェントには通じない。曖昧な指示は曖昧な結果を生む。
この記事では、AIエージェントに仕事を任せるときに使えるタスク分解のテンプレートを紹介する。特別なツールは不要で、今日から使える考え方だ。
なぜタスク分解が必要なのか
AIエージェントは「自律的に動く」のが売りだが、自律的に動くからこそ危ない。前提を勝手に推測して、意図しない方向に突き進むことがある。
たとえば「このコードをリファクタリングして」と頼むと、エージェントは「何をリファクタリングするか」を自分で判断する。結果、触ってほしくないファイルまで変更されたり、動作確認なしに本番に近いコードを書き換えたりする。
これを防ぐには、作業を細かく分けて、途中で確認できる状態にしておくのが効果的だ。MicrosoftのAutoGenドキュメントでも、タスクを分解して複数のエージェント（Planner、Engineer、Reviewerなど）に役割分担させる設計が紹介されている。
基本の流れは4ステップ
タスク分解の基本は「曖昧さの解消→分割→実行→検証」の順番で進めることだ。
1. 曖昧さを解消する
最初のステップは、曖昧な部分を潰すこと。OpenAIのドキュメントでも、曖昧なタスクでは推測で進めるより確認質問でギャップを埋めるのが有効とされている。
「ユーザー情報を更新する機能を作って」という依頼があったら、まず確認すべきことをリストアップする。どの情報を更新するのか、バリデーションは必要か、既存の更新処理との違いは何か。エージェントに確認質問をさせるのも手だが、自分で事前に整理しておくほうが確実だ。
2. サブタスクに分ける
作業を小さな単位に分解する。このとき、各サブタスクに「役割」を割り当てると整理しやすい。
- Planner: 何をやるか決める
- Engineer: 実際に作る
- Reviewer: 結果を確認する
役割が混ざると、エージェントが設計しながら実装しながらレビューする、という混沌とした動きになる。分けておけば「この段階では設計だけ出して」「実装は次のステップで」と制御できる。
3. 実行する
分解したサブタスクを順番に実行させる。ここで重要なのは、ツールがないとエージェント同士が会話だけしてトークンを浪費しがちという点だ。
「検索する」「ファイルを操作する」「コマンドを実行する」といった、現実に作用する手段をエージェントに与えておかないと、延々と考えるふりをして何も進まないことがある。
4. 検証する
最後に、出力が正しいかを確認する。Anthropicのドキュメントでは、「changes.json」のような検証可能な中間成果物を作ってから実行するパターンが推奨されている。
たとえば「10ファイルを一括変更する」というタスクなら、いきなり変更せずに「変更計画をJSONで出力→スクリプトで妥当性をチェック→問題なければ実行」という流れにする。機械的にチェックできるゲートを挟むと、破壊的な操作を未然に防げる。
実際に使えるテンプレート
各サブタスクには、最低限これだけ書いておくと安定する。
## サブタスク名
- 目的: このタスクで何を達成するか
- 入力: 何を受け取るか（前のタスクの出力、ファイルパスなど）
- 出力: 何を生成するか（ファイル、JSON、レポートなど）
- 受け入れ条件: どうなったら完了か
- 制約: やってはいけないこと、触ってはいけない範囲
- 失敗時: うまくいかなかったら何をするか例として「APIエンドポイントを追加する」タスクを分解してみる。
## サブタスク1: 設計
- 目的: エンドポイントの仕様を決める
- 入力: 要件定義書、既存のAPI一覧
- 出力: API設計書（パス、メソッド、リクエスト/レスポンス形式）
- 受け入れ条件: 既存APIと命名規則が統一されている
- 制約: 既存のエンドポイントと競合しないこと
- 失敗時: 不明点をリストアップして確認を求める
## サブタスク2: 実装
- 目的: 設計に基づいてコードを書く
- 入力: サブタスク1の設計書
- 出力: 実装コード（Pull Request用のdiff）
- 受け入れ条件: リンターエラーがない、テストが通る
- 制約: 関係ないファイルを変更しない
- 失敗時: エラー内容を報告して停止
## サブタスク3: レビュー
- 目的: 実装が設計通りか確認する
- 入力: サブタスク1の設計書、サブタスク2の実装コード
- 出力: レビューコメント（修正点があれば指摘）
- 受け入れ条件: 設計と実装の差異がない
- 制約: コードの書き換えはしない（指摘のみ）
- 失敗時: 不明点を質問として返す破壊的な操作には承認ステップを入れる
データ削除、本番環境への反映、課金が発生する処理など、取り返しのつかない操作がある場合は、実行前にユーザー承認を必須にする段階をテンプレートに含めておくのが無難だ。
## サブタスク4: 承認待ち
- 目的: 本番反映前に人間が最終確認する
- 入力: 変更内容の差分、影響範囲のサマリ
- 出力: 承認 or 差し戻し
- 受け入れ条件: 承認が得られた
- 制約: 自動で承認を通過しない
- 失敗時: 差し戻し理由を記録して前のステップに戻る粘り強さ（リトライ回数）やリスク評価を設定できるエージェントもある。暴走や無限ループを防ぐために、実行時の上限を決めておくとコスト面でも安心だ。
向いていない場面もある
このテンプレートは、作業が明確に定義できるタスクには有効だが、探索的な作業には向かない。「なんかいい感じのUIを考えて」みたいなオープンエンドな依頼は、そもそも分解しにくい。
また、タスクを分解する作業自体に時間がかかる。5分で終わる作業をわざわざテンプレートに落とし込むのは本末転倒だ。目安として、「30分以上かかりそう」「複数ステップがある」「失敗すると面倒」なタスクに使うのがいい。
毎回ゼロから書くのは面倒なので、よく使うパターンはテンプレートとして保存しておくと楽になる。