AIエージェントのタスク分解｜指示書テンプレートと粒度の判断表

AIエージェントのタスク分解とは、大きな依頼を「差分を1文で言えて、検証コマンドが1つある」大きさの作業に割り、1つずつ指示書にして渡すことです。 割り方が決まると、エージェントは自分で検証して完了まで進められ、人は結果の確認に集中できます。

この記事には、そのまま貼って使える1タスク分の指示書テンプレートと記入例、タスク一覧のYAML、依存関係の循環や完了条件の抜けを見つける検査スクリプト（実行結果つき）、切り口・並列可否・粒度の判断表を載せています。

確認環境：Ubuntu 24.04 / Python 3.11.15 / PyYAML 6.0.3。Mermaid の図は mermaid-cli 12.0.0 で描画できることを確かめています。公式ドキュメントの確認日は 2026年10月7日です。

タスク分解の早見表

分解がなぜ効くのか

理由は3つあり、いずれも公式ドキュメントに根拠があります（確認日：2026年10月7日）。

Claude Code の Best practices には、仕様書について「関係するファイルとインターフェースを名指しし、範囲外を明記し、最後に端から端までの検証手順で終える」ものが最も役に立つ、という趣旨の記述があります。この記事のテンプレートの項目（対象ファイル／範囲外／完了条件／検証コマンド）は、この考え方を1タスクの大きさに当てはめたものです。

• Claude Code Best practices: https://code.claude.com/docs/en/best-practices
• Building effective agents（Anthropic、2024年12月19日公開）: https://www.anthropic.com/engineering/building-effective-agents

1タスク分の指示書テンプレート

6項目（目的／対象ファイル／範囲外／完了条件／検証コマンド／報告形式）を埋めれば、1タスク分の指示書になります。 ファイル名は tasks/T2.md のようにタスクIDと合わせると、一覧と突き合わせやすくなります。

# タスク {ID}: {やることを1文で}

## 目的
{なぜこの作業が要るのか。誰が何をできるようになるのか。1〜3行}

## 前提
- 先に終わっているタスク: {ID。無ければ「なし」}
- 参考にする既存コード: {パス。似た実装があれば必ず書く}
- 読んでおく資料: {仕様書やメモのパス}

## 対象ファイル
- {変更してよいファイルのパス}
- {新しく作るファイルのパス}

## 範囲外（触らないこと）
- {変更しないファイル・ディレクトリ}
- {今回はやらない機能や改善}
- {追加しない依存ライブラリなど}

## 完了条件
- [ ] {外から見て確かめられる状態を1行で}
- [ ] {境界値やエラー時の振る舞い}
- [ ] 下の検証コマンドが成功する

## 検証コマンド
```bash
{合否が終了コードで分かるコマンドを1つ}
```

## 報告形式
作業が終わったら、次の4点を箇条書きで報告してください。
1. 変更したファイルと、変更の要約（各1行）
2. 検証コマンドと、その出力の末尾
3. 完了条件のうち満たせなかったものと理由
4. 範囲外だが気づいた点（直さずに報告だけ）

記入例（CSV変換関数を追加するタスク）

# タスク T2: 会員一覧をCSV文字列に変換する関数 to_csv を追加する

## 目的
会員一覧画面からCSVを出力できるようにするための土台です。
このタスクでは変換関数だけを作り、APIと画面は別タスクで扱います。

## 前提
- 先に終わっているタスク: T1（docs/notes/member-list.md に調査メモあり）
- 参考にする既存コード: src/orders/export.py（注文のCSV出力。同じ書き方に合わせる）
- 読んでおく資料: docs/notes/member-list.md

## 対象ファイル
- src/members/export.py（新規）
- tests/test_export.py（新規）

## 範囲外（触らないこと）
- src/members/api.py と web/ 以下（T3・T4 で扱う）
- 既存の src/orders/export.py の変更
- 新しい依存ライブラリの追加（標準ライブラリの csv を使う）

## 完了条件
- [ ] to_csv(members) が、見出し行 `id,name,email,joined_on` つきのCSV文字列を返す
- [ ] 氏名にカンマや改行が入っていても、1件が1レコードとして読み戻せる
- [ ] 会員が0件のときは見出し行だけを返す
- [ ] 下の検証コマンドが成功する

## 検証コマンド
```bash
pytest tests/test_export.py -q
```

## 報告形式
作業が終わったら、次の4点を箇条書きで報告してください。
1. 変更したファイルと、変更の要約（各1行）
2. 検証コマンドと、その出力の末尾
3. 完了条件のうち満たせなかったものと理由
4. 範囲外だが気づいた点（直さずに報告だけ）

各項目の役割

毎回同じ内容（ビルド手順、コード規約、テストの流儀）は指示書に書かず、リポジトリ直下の AGENTS.md にまとめると指示書が短くなります。AGENTS.md は「エージェント向けのREADME」にあたる公開フォーマットで、Linux Foundation 傘下の Agentic AI Foundation が管理し、公式サイトには6万を超えるオープンソースプロジェクトで使われていると書かれています（確認日：2026年10月7日、https://agents.md/ ）。サブディレクトリにも置け、エージェントは最も近い階層のファイルを読みます。

なお、機能全体の仕様書（要件・設計・タスクの3文書）の書き方は、当サイトの記事「仕様駆動開発（SDD）とは？AIに渡す仕様書テンプレートと進め方」で扱っています。この記事は、そこから切り出した1タスクを渡す場面に絞ります。

タスク一覧YAMLと検査スクリプト

タスクが3つを超えたら、一覧をYAMLにして機械で検査すると、順番の矛盾や完了条件の抜けを渡す前に見つけられます。

タスク一覧（tasks.yaml）

# tasks.yaml : 会員一覧にCSV出力を追加する作業のタスク一覧
goal: 会員一覧画面にCSV出力ボタンを追加する
tasks:
  - id: T1
    title: 既存の一覧取得処理を調べて要約する
    kind: 調査
    files: []
    depends_on: []
    done_when: docs/notes/member-list.md に取得処理の呼び出し経路が書かれている
    verify: test -s docs/notes/member-list.md
  - id: T2
    title: CSV変換関数 to_csv を追加する
    kind: 実装
    files: [src/members/export.py, tests/test_export.py]
    depends_on: [T1]
    done_when: 会員3件の入力から見出し行つきCSVが返る
    verify: pytest tests/test_export.py -q
  - id: T3
    title: 出力用のAPI GET /members.csv を追加する
    kind: 実装
    files: [src/members/api.py, tests/test_api_csv.py]
    depends_on: [T2]
    done_when: GET /members.csv が 200 と text/csv を返す
    verify: pytest tests/test_api_csv.py -q
  - id: T4
    title: 一覧画面に出力ボタンを置く
    kind: 実装
    files: [web/members/List.tsx, web/members/List.test.tsx]
    depends_on: [T1]
    done_when: ボタンを押すと /members.csv へのリンクが開く
    verify: npm test -- List.test.tsx
  - id: T5
    title: 差分全体を別の文脈でレビューする
    kind: 検証
    files: []
    depends_on: [T3, T4]
    done_when: 範囲外の変更が無く、指摘が0件または対応済み
    verify: git diff --stat main

検査スクリプト（check_tasks.py）

必須項目の空欄、存在しない依存先、IDの重複、依存関係の循環を調べ、同時に出せるタスクの組（波） を表示します。同じ波の中で同じファイルを触るタスクがあれば注意を出します。標準ライブラリの graphlib（Python 3.9 以降）と PyYAML を使います。

#!/usr/bin/env python3
"""tasks.yaml を検査する。使い方: python3 check_tasks.py tasks.yaml"""
import sys
from graphlib import CycleError, TopologicalSorter

import yaml  # pip install pyyaml

REQUIRED = ("id", "title", "done_when", "verify")
MAX_FILES = 5  # 1タスクで触るファイル数の目安


def main(path: str) -> int:
    with open(path, encoding="utf-8") as f:
        tasks = yaml.safe_load(f)["tasks"]
    ids = [t.get("id") for t in tasks]
    errors, warns = [], []

    for t in tasks:
        tid = t.get("id", "?")
        for key in REQUIRED:
            if not str(t.get(key) or "").strip():
                errors.append(f"{tid}: {key} が空です")
        for dep in t.get("depends_on") or []:
            if dep not in ids:
                errors.append(f"{tid}: depends_on の {dep} が一覧にありません")
        if len(t.get("files") or []) > MAX_FILES:
            warns.append(f"{tid}: 対象ファイルが {len(t['files'])} 個あります（目安は {MAX_FILES} 個まで）")
    for tid in sorted({i for i in ids if ids.count(i) > 1}):
        errors.append(f"{tid}: id が重複しています")

    # 依存関係の循環を調べ、同時に出せる組（波）を作る
    graph = {t["id"]: [d for d in (t.get("depends_on") or []) if d in ids] for t in tasks if t.get("id")}
    waves = []
    try:
        ts = TopologicalSorter(graph)
        ts.prepare()
        while ts.is_active():
            ready = sorted(ts.get_ready())
            waves.append(ready)
            ts.done(*ready)
    except CycleError as e:
        errors.append("依存関係が循環しています: " + " -> ".join(e.args[1]))

    # 同じ波の中で同じファイルを触るタスクは、並列に出すと衝突する
    files = {t["id"]: set(t.get("files") or []) for t in tasks if t.get("id")}
    for n, wave in enumerate(waves, 1):
        for i, a in enumerate(wave):
            for b in wave[i + 1:]:
                for f in sorted(files[a] & files[b]):
                    warns.append(f"第{n}波: {a} と {b} が同じファイル {f} を触ります（直列にするか分担を変える）")

    for n, wave in enumerate(waves, 1):
        mode = "並列可" if len(wave) > 1 else "単独"
        print(f"第{n}波（{mode}）: {', '.join(wave)}")
    for w in warns:
        print("注意:", w)
    for e in errors:
        print("エラー:", e)
    print(f"タスク {len(tasks)} 件 / エラー {len(errors)} 件 / 注意 {len(warns)} 件")
    return 1 if errors else 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1]))

実行結果（問題のない一覧）

$ python3 check_tasks.py tasks.yaml
第1波（単独）: T1
第2波（並列可）: T2, T4
第3波（単独）: T3
第4波（単独）: T5
タスク 5 件 / エラー 0 件 / 注意 0 件
$ echo $?
0

T2（変換関数）と T4（画面のボタン）は、どちらも T1 にだけ依存し、触るファイルが重ならないので同時に出せます。

実行結果（直す点がある一覧）

次の一覧は、T1・T2・T3 の依存が輪になっており、T2 の完了条件が空、T3 に検証コマンドが無く、T4 が存在しない T9 に依存しています。

goal: 会員一覧画面にCSV出力ボタンを追加する
tasks:
  - id: T1
    title: CSV変換関数を追加する
    kind: 実装
    files: [src/members/export.py]
    depends_on: [T3]
    done_when: 会員3件の入力から見出し行つきCSVが返る
    verify: pytest tests/test_export.py -q
  - id: T2
    title: 出力用のAPIを追加する
    kind: 実装
    files: [src/members/api.py]
    depends_on: [T1]
    done_when: ""
    verify: pytest tests/test_api_csv.py -q
  - id: T3
    title: APIの入力チェックを直す
    kind: 実装
    files: [src/members/api.py]
    depends_on: [T2]
    done_when: 不正な並び順の指定で 400 を返す
  - id: T4
    title: 一覧画面に出力ボタンを置く
    kind: 実装
    files: [web/members/List.tsx]
    depends_on: [T9]
    done_when: ボタンを押すと /members.csv へのリンクが開く
    verify: npm test -- List.test.tsx
  - id: T5
    title: 一覧画面の文言を直す
    kind: 実装
    files: [web/members/List.tsx]
    depends_on: []
    done_when: 見出しが「会員一覧」になっている
    verify: npm test -- List.test.tsx

$ python3 check_tasks.py tasks_ng.yaml
エラー: T2: done_when が空です
エラー: T3: verify が空です
エラー: T4: depends_on の T9 が一覧にありません
エラー: 依存関係が循環しています: T1 -> T2 -> T3 -> T1
タスク 5 件 / エラー 4 件 / 注意 0 件
$ echo $?
1

終了コードが 1 になるので、CI やコミット前のチェックにそのまま組み込めます。

実行結果（並列に出すと同じファイルを触る一覧）

goal: 会員一覧画面の文言とボタンを直す
tasks:
  - id: T1
    title: 一覧画面に出力ボタンを置く
    kind: 実装
    files: [web/members/List.tsx, web/members/List.test.tsx]
    depends_on: []
    done_when: ボタンを押すと /members.csv へのリンクが開く
    verify: npm test -- List.test.tsx
  - id: T2
    title: 一覧画面の見出しを直す
    kind: 実装
    files: [web/members/List.tsx]
    depends_on: []
    done_when: 見出しが「会員一覧」になっている
    verify: npm test -- List.test.tsx

$ python3 check_tasks.py tasks_warn.yaml
第1波（並列可）: T1, T2
注意: 第1波: T1 と T2 が同じファイル web/members/List.tsx を触ります（直列にするか分担を変える）
タスク 2 件 / エラー 0 件 / 注意 1 件

依存関係が無くても、同じファイルを触る2つは depends_on で順番を付けるか、1つのタスクにまとめます。

分解の切り口一覧

切り口は5つあり、迷ったら「調査と実装の分離」と「検証の分離」から始めると外しにくくなります。

それぞれ、公式ドキュメントに対応する記述があります（確認日：2026年10月7日）。

• 調査と実装の分離：Claude Code Best practices は「まず探索、次に計画、それから実装」の流れを勧め、調査をサブエージェントに任せると別のコンテキストで読み込みが行われ、要約だけが戻ると説明しています。
• 検証の分離：同ドキュメントは、実装したセッションとは別の新しい文脈で差分をレビューさせる方法（Writer/Reviewer パターン）を紹介しています。レビュー役には「正しさと要件に関わる抜けだけを報告する」と伝えると、過剰な作り込みを避けられるとも書かれています。
• ファイル別：同ドキュメントの「Fan out across files」は、一覧をファイルに書き出し、最初の2〜3件で指示を整えてから全体に流す手順を示しています。/batch を使うと変更を5〜30のサブエージェントに分け、それぞれが独立した worktree で作業すると書かれています。
• 層別・機能別：Building effective agents は、固定の小タスクにきれいに分けられる作業を順につなぐ形（prompt chaining）と、独立した小タスクを同時に走らせる形（parallelization の sectioning）を挙げています。小タスクを事前に予測できない複雑な作業には、中心の役が動的に分けて渡す形（orchestrator-workers）が向くとされています。

並列に出せる条件・直列にする条件

上の tasks.yaml の依存関係を図にすると次のようになります。T2 と T4 が横に並ぶ部分が、同時に出せる組です。

flowchart LR
    T1["T1 調査<br>一覧取得処理を要約"] --> T2["T2 実装<br>CSV変換関数"]
    T1 --> T4["T4 実装<br>出力ボタン"]
    T2 --> T3["T3 実装<br>GET /members.csv"]
    T3 --> T5["T5 検証<br>差分レビュー"]
    T4 --> T5

並列に出すときは、先に境目（関数のシグネチャ、APIのパスとレスポンスの形）を決めて各指示書の「前提」に書いておくと、後で合わせる手間が減ります。この例では、T1 の調査メモに /members.csv というパスを書いておくことで、T3 と T4 が同じ前提で進められます。

粒度の判断基準

1タスクの大きさは「差分を1文で言えるか」「検証コマンドが1つあるか」「触るファイル数」の3点で判断します。 1点目は Claude Code Best practices の「差分を1文で説明できるなら計画は省いてよい」という記述を目安に転用したもので、ファイル数などの数値はこの記事の目安です。チームで調整してください。

• 大きいとき：完了条件を1〜2個ずつに分け、それぞれに検証コマンドを付けます。聞く点が複数あるなら、先に調査タスクを切り出します。
• 小さいとき：同じファイル・同じ検証コマンドのものはまとめます。指示書を書く時間のほうが長くなるなら、対話でそのまま頼みます。

大きな指示を3つに割り直す例

直す前（1つの指示に3つの差分が入っている）

会員管理を改善してください。CSV出力を付けて、検索も速くして、テストも増やしてください。

差分を1文で言えず、検証コマンドも決まっていません。どこまでやれば終わりかが、渡す側と受ける側で揃いにくい形です。

直した後（3つのタスクに分け、それぞれ1文と検証コマンドを持たせる）

【タスクA】会員一覧をCSV文字列に変換する関数 to_csv を src/members/export.py に追加する。
対象: src/members/export.py, tests/test_export.py（どちらも新規）
範囲外: API と画面。既存の注文CSV出力は変更しない。
完了条件: 見出し行つきCSVが返る／氏名にカンマがあっても1件が1レコードで読み戻せる。
検証: pytest tests/test_export.py -q

【タスクB】会員検索で氏名の前方一致が遅い原因を調べ、docs/notes/member-search.md にまとめる。
対象: docs/notes/member-search.md（新規）。コードは変更しない。
範囲外: インデックスの追加やSQLの書き換え（結果を見てから別タスクにする）。
完了条件: 実行計画の出力と、遅くなっている箇所の説明、直し方の候補が2つ以上書かれている。
検証: test -s docs/notes/member-search.md

【タスクC】src/members/service.py の退会処理に、退会済み会員を再度退会させた場合のテストを追加する。
対象: tests/test_service_withdraw.py（新規）
範囲外: service.py 本体の変更（テストが通らない場合は直さずに報告する）。
完了条件: 退会済み会員への退会要求で AlreadyWithdrawn が送出されることを確かめるテストが1件ある。
検証: pytest tests/test_service_withdraw.py -q

「検索を速くする」は原因が分かるまで差分を1文で言えないため、まず調査タスク（B）にして、実装は結果を見てから別のタスクにするのがこつです。「テストを増やす」も対象の振る舞いを1つ決めると、検証コマンドが1つに定まります。

人に頼むWBSとの違い

WBS（作業分解構成図）は、成果物を階層的に分けて担当と期間を割り当てる、人のチーム向けの分解の道具です。スコープは、PMIのPMBOKガイド第8版（2025年11月発行）でも7つのパフォーマンス領域の1つに挙げられています（確認日：2026年10月7日、https://www.pmi.org/standards/pmbok ）。考え方は共通ですが、渡す相手がエージェントのときは次の点が変わります。

特に違いが出るのは背景の共有です。人は前回の会議や雑談を覚えていますが、新しく起動したエージェントは指示書と AGENTS.md、リポジトリの中身から始めます。「参考にする既存コード」をパスで書くのは、この差を埋めるためです。人への依頼の書き方は、当サイトの記事「仕事の任せ方と依頼テンプレート｜5W1Hと権限委譲レベル表」で扱っています。

よくあるつまずきと直し方

3行目は Claude Code Best practices の記述に沿っています。同じ点を2回直しても解決しないときは、文脈を空にして、分かったことを盛り込んだ指示で始め直すほうが良い結果になりやすい、と説明されています。

よくある質問

Q. 分解そのものをエージェントに任せてもよいですか？ A. 任せられます。計画用のモードで「どのファイルを変える必要があるか、計画を作って」と頼み、出てきた案を tasks.yaml の形に直してもらうと、検査スクリプトで確かめられます。完了条件と範囲外だけは、人が目を通して決めるのがおすすめです。

Q. 検証コマンドが作れない作業（調査や文書）はどうしますか？ A. 成果物のファイルが存在することを確かめるコマンド（test -s パス）を置き、完了条件に「何が書かれているか」を具体的に書きます。内容の確認は、別の文脈でのレビュータスクに分けます。

Q. 指示書は長いほどよいですか？ A. 長さよりも6項目が埋まっていることが大切です。毎回同じ内容は AGENTS.md に移し、指示書にはそのタスクに固有のことだけを書くと、読み落としが減ります。

Q. 並列はいくつまで出せますか？ A. 上限は道具と作業内容によります。目安として、触るファイルが重ならず、境目の形が決まっている組だけを同時に出します。検査スクリプトの「波」がその組を示します。

まとめ

• 1タスクは「差分を1文で言える・検証コマンドが1つある・触るファイルは1〜5個」 を目安にする
• 指示書は6項目（目的／対象ファイル／範囲外／完了条件／検証コマンド／報告形式）を埋める
• 範囲外と検証コマンドが、人への依頼と比べて特に効く項目
• タスク一覧はYAMLにして検査し、循環・完了条件の抜け・ファイルの重なりを渡す前に見つける
• 切り口は5つ。迷ったら調査と実装を分け、最後に検証を別の文脈で行う
• 並列は「ファイルが重ならない・結果を使い合わない・境目が決まっている」 ときに出す
• 毎回同じ前提は AGENTS.md に置き、指示書を短く保つ

参考・出典（確認日：2026年10月7日）

• Claude Code Docs「Best practices for Claude Code」 https://code.claude.com/docs/en/best-practices
• Anthropic「Building effective agents」（2024年12月19日公開） https://www.anthropic.com/engineering/building-effective-agents
• AGENTS.md https://agents.md/
• PMI「PMBOK Guide」第8版（2025年11月発行）の紹介ページ https://www.pmi.org/standards/pmbok

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。