Tsuzura

AIに渡す実装タスクの切り方

AIへ実装を頼む前に、一機能を自己完結したタスクへ分け、依存順・確認方法・停止条件を決める手順です。

公開日
更新日

要件と受入条件が決まっても、その全体をAIへ一度に渡すとは限りません。実装を始める前に、人が一つずつ完了を確認できる実装タスクへ分けます。

この記事でいう実装タスクは、一つの変更と、そのタスクの完了条件、確認方法をまとめた作業単位です。必要なら複数のファイルや処理を含めます。新しい動作の実装と、完了判断に欠かせないテスト変更は同じタスクに保ちます。各タスクの後には、コードをビルド（実行・配布できる形へ整える処理）または実行し、完了条件を確認できる状態にします。

主な対象は、コード一式を読み、ファイルを直接変更し、テストやコマンドを実行できるコーディングAIです。会話だけを行うAIでも分割方法とタスク票は使えますが、ファイルの読み書きやネットワークの権限欄は該当しません。

対象読者は、要件と受入条件を一機能分まで決め、これからAIへコード変更を依頼する人です。読み終えると、実装タスクの一覧と、次にAIへ渡す一件分のタスク票を作れます。Gitの操作、テストの種類、生成コードの詳しいレビュー、公開方法は扱いません。

なぜ実装タスクへ分けるのか

実装タスクへ分ける目的は、AIが一度に生成できる量を減らすことではありません。何を変更し、どの結果を確かめれば、その一件を完了と判断できるかを明確にすることです。

要件、実装タスク、プロンプト、検証の違い

要件は、利用者やシステムに何が必要かを示します。受入条件は、どうなれば要件を満たしたと判断するかを示します。実装タスクは、その条件を満たすために行う一つの変更です。タスクの完了条件は、その一件を終えたと判断できる状態を示します。プロンプトは、タスクをAIへ伝えるメッセージです。検証は、実装後の結果を確かめる行為です。

用語 答える問い 記録する内容
要件 何が必要か 必要な結果と制約
受入条件 どうなれば満たしたと言えるか 合否を決める条件
実装タスク 今回、どの状態まで変更するか 一つの完了条件、範囲、確認方法、停止条件
プロンプト AIへ何を伝えるか タスク票をもとにした指示と質問
検証 何をどう確かめるか テストや確認手順、期待結果、実際の結果

同じ実装タスクでも、使うAIによってプロンプトの書式は変わります。反対に、丁寧なプロンプトでも、複数の結果、未決の判断、広い変更範囲が混ざっていれば、タスクの境界は曖昧なままです。

GitHub Copilot cloud agentの公式ガイドは、AIへ渡す作業に、解く問題、受入条件、変更対象の案内を含め、範囲を明確にするよう勧めています。これはCopilot固有の案内ですが、この記事でも、目的と合否を一件に絞るための確認項目として使います。

大きすぎても、分けすぎても確認できない

大きすぎるタスクには、複数の変更結果、無関係なコード整理、未決の選択が混ざります。途中で失敗したとき、どの判断や変更が原因かを追いにくくなります。テストが一部通っても、タスク全体を受け入れてよいか判断できません。

分けすぎたタスクは、それだけでは意味のある結果になりません。新しい動作の実装と、その完了判断に欠かせないテスト変更を理由なく分けたり、途中のタスクを反映するとシステムが動かなくなったりすれば、一件ごとの確認ができません。一方、既存の動作を記録するテスト追加など、それ自体で完了を確認できる変更は、先行タスクへ分けられます。

Googleのコードレビュー指針は、小さな変更を「一つの自己完結した変更」と説明し、行数だけで決める厳密な規則はないとしています。また、関連するテストを同じコード変更へ含め、各変更後もビルドやシステムを壊さないよう求めています（Small CLs）。これはレビューへ出すコード変更の指針です。本記事では、人が一度に受入判断する実装タスクへ応用します。実装タスクと、Gitで変更を保存する単位やレビューに出す単位を、必ず同じにするという意味ではありません。

分ける前に決める

実装タスクへ分ける前に、要件、受入条件、未決事項、既存コードの影響範囲を確認します。ここが決まっていなければ、タスクを細かくしてもAIが空白を推測する状態は変わりません。

承認済みの要件と受入条件を入力にする

最初に、一機能分の要件メモから、今回扱う要件と受入条件を選びます。各実装タスクは、少なくとも一つの受入条件またはその前提へ対応づけます。どの条件にも対応しない変更が見つかったら、必要な変更か、範囲外の追加かを先に判断します。

この記事では、受入条件と、それを確かめる具体的なテストケースを役割で区別します。受入条件は合否の条件であり、テストケースはその条件を確かめる前提、入力、操作、期待結果を定めます（ISTQB Foundation Level Syllabus v4.0.1）。実装タスクには、最終的に支える受入条件と、そのタスクで実行する確認方法の両方を記録します。

未決事項があれば判断者へ戻す

結果を変える未決事項が残っている場合、実装タスクにはしません。選択肢、解決に必要な行動、判断する人、期限または停止条件を記録し、判断者へ戻します。未決の値や方針をAIに選ばせ、そのまま決定済みの要件としては扱いません。未決事項の記録方法は、NASAの要件記述ガイドでも、理由、解決方法、責任者、期限を残す形で示されています。

個人情報、決済、認証（利用者が本人か確かめること）・認可（その利用者に許す操作を決めること）、本番データへの書き込み、外部公開に関する判断が未決なら、必要な責任者が決めるまで止めます。タスクを小さくすることは、承認や安全設計の代わりにはなりません。

AIへ任せる範囲そのものが決まっていない場合は、先にAIにどこまで任せてよいかを決めるで、人が説明・検証する範囲と相談条件を整理します。

影響範囲が分からなければ調査だけを依頼する

どのコードを変えるか、既存の設計にどう合わせるか分からない場合は、実装と調査を同じ依頼にしません。最初のタスクを「変更せずに調査し、実装計画を出す」に限定します。

調査タスクでは、次の結果を求めます。

  • 要件に関係するファイル、処理、データの流れ
  • 既存の設計ルールと、変更時に守る制約
  • 必要になりそうな変更と、その理由
  • 実行できるテストまたは確認手順
  • 追加の判断、権限、情報が必要な箇所
  • 自己完結した実装タスクへの分割案と依存順

GitHubのCopilot公式ガイドは、Copilotにすぐコード変更を作らせず、コード一式の調査と実装計画を先に確認する進め方を案内しています。Claude Codeの公式ガイドも、方針が不明な変更や広い変更では、調査・計画と実装を分ける方法を示しています。

調査と計画を挟んでも、複雑、広範囲、機密性が高い、重要な判断を含む、または曖昧なタスクをAIへ任せてよいとは限りません。人が担当するか、必要な責任者へ戻す判断も行います。一方、範囲と方法が明確な小さい変更に、毎回独立した計画タスクを加える必要はありません。

一つのタスクの大きさを決める

一つの実装タスクは、一つの完了条件を人が確認し、受け入れるか差し戻すか判断できる大きさにします。これは本記事の実務上の基準であり、標準で決められたファイル数や行数ではありません。

完了条件は、そのタスクの終了を判断する条件です。最終的な利用者の受入条件と同じとは限りません。前提タスクは、最終的に支える受入条件を参照しながら、ビルド、テスト、設定確認など、そのタスクだけで確かめられる完了条件を持たせます。

次の四点をすべて説明できるか確認します。

  1. このタスクの完了条件は一つか。
  2. 最終的に支える受入条件と、今回の確認方法を特定できるか。
  3. このタスクだけを反映しても、ビルドや必要な動作を壊さないか。
  4. 人がこのタスクだけを受け入れるか、差し戻すか判断できるか。

必要な変更が複数のファイルや処理層にまたがっても、完了条件が一つなら同じタスクに含められます。一つの受入条件に複数の前提変更が必要なら、複数のタスクになる場合があります。受入条件とタスクの数を機械的に一対一へそろえません。

分ける変更

次の変更は、別の実装タスク、調査タスク、または判断事項へ分けます。

状態 分けた後の扱い
別々に受入可否を判断できる結果が混ざっている 結果ごとに実装タスクを分ける
動作変更と、直接関係しないコード整理が混ざっている コード整理を別タスクにする
実現方針や変更範囲が分からない 調査タスクを先にする
業務判断、権限、費用、公開範囲が未決である 判断者へ戻し、決定後に実装タスクを作る
追加の外部サービスや依存関係が必要になる 採用判断と影響確認を別に行う

ここでいうコード整理は、外から見える動作を変えずに、コードの構造を直す変更です。一般にリファクタリングと呼ばれます。Googleの指針も、リファクタリングを機能追加や不具合修正から原則として分け、小さな変数名修正などの整理は同じ変更へ含められるとしています（Small CLs）。同じ変更へ含めるかは、変更の理解しやすさをもとに、実装する人と確認する人が判断します。

同じタスクに保つ変更

次の変更は、別ファイルや別の処理に見えても、機械的に分けません。

状態 同じタスクに保つ理由
新しい動作の実装と、完了判断に欠かせないテスト変更 テストを含めて完了を判断するため
分けるとビルドや必要な動作が壊れる変更 各タスクを反映した状態で確認できないため
一つの結果を成立させるために不可欠な複数箇所の変更 一部だけでは受入条件を確かめられないため
定義だけでは動作を確認できず、利用する処理も必要な変更 使われる状態まで含めないと意味を確認できないため

既存の動作を記録するテスト追加、テストコードだけの整理、大きなテスト基盤の準備など、それ自体で完了を確認できる変更は、先行タスクへ分けられます。

同じタスクに保つ理由を説明できても、変更範囲が大きく人が確認できない場合は、設計や実現方法を見直します。分割できないことを理由に、無制限に大きなタスクをAIへ渡しません。

実装する順番を決める

実装タスクは、前提となる判断や変更が終わる順に並べます。依存関係とは、あるタスクを始める前に、別のタスクや判断を終える必要がある関係です。この記事では、初めて進める読者は一件ずつ完了・確認し、その結果を後続タスクへ反映します。

まず、未決の判断と調査を置きます。次に、後続タスクが必要とする前提変更を置きます。各タスクには確認方法を含め、実際の結果が計画と違えば、未着手のタスクを修正します。

Gemini CLIのタスク計画チュートリアルは、複雑なタスクを順序付きの手順へ分け、計画を確認、並べ替え、更新、中止する方法を示しています。これはGemini CLI固有の機能ですが、実装中に計画を固定せず、確認結果を受けて更新する考え方は本記事の依存表にも使えます。

次の空欄表に、実装タスクを並べます。

ID このタスクの完了条件 最終的に支える受入条件 前提タスク・判断 確認方法 状態
未着手 / 調査中 / 実装中 / 確認中 / 完了 / 停止

前提欄が空でも、同じファイル、データ、外部サービスを同時に変更するタスクは互いに影響する可能性があります。この記事では並行実行の判断を扱いません。初めて進める場合は一件ずつ実行し、確認後に次へ進みます。

一件分のタスク票を書く

AIへ渡す前に、次の一件について、結果、理由、範囲、確認方法、停止条件を一枚にします。作業名だけでは、AIも確認する人も、なぜその変更が必要か判断できません。

Googleの変更説明に関する指針は、何を変えるかと、なぜ変えるかに加え、必要な背景や採用した方針の欠点を記録し、実際の変更後に説明を見直すよう求めています（Writing good CL descriptions）。これはコードレビューの説明に関する指針ですが、タスク票にも同じ情報を残します。

OpenAIのCodex Prompting Guidanceは、期待する結果、有用な前提情報、出力、境界、検証方法を必要に応じて伝えるよう案内しています。Claude Codeの公式ガイドも、対象、利用場面、制約、既存の設計規則、完成状態、実行可能な確認を具体化するよう案内しています。次の書式は、これらの公式資料とソフトウェア開発の指針を統合した、本記事独自のタスク票です。

タスク票は一度に全欄を埋めません。AIへ渡す前に書く欄、AIの返答後に追記する欄、人が確認した後に追記する欄に分かれています。前提タスクや明文化された既存設計がなければ「なし」、既存資料に記録済みなら内容を写さず場所だけを書きます。条件付きの項目が当てはまらなければ「該当なし」と記録します。本番環境とは、実際の利用者やデータを扱う環境です。破壊的な変更とは、データや設定の削除・上書きなど、元に戻すのが難しい変更です。

# 実装タスク名

## AIへ渡す前に書く項目

### このタスクの完了条件
- このタスクだけで確認できる状態:
- その状態が必要な理由:

### 要件との対応
- 要件メモの場所:
- 最終的に支える要件・受入条件:
- 前提タスク・判断と、その完了記録:

### 前提情報と変更範囲
- 現在の動作と、関連するファイル・処理・データ:
- 再現手順または確認した調査結果:
- 守る既存設計とコード一式の規則:
- 変更してよい範囲:
- 変更しない範囲:

### 確認方法
- 実行するテスト・ビルド・確認手順:
- 期待する結果:
- 実行できない場合に報告する内容:

### 停止して人へ戻す条件
- 未決の判断、対象外の変更、確認失敗を見つけた場合:

## AIの返答後に追記する項目

### AIから受け取る記録
- 変更した場所と理由:
- 実行したコマンド・テスト・確認結果:
- 実行していない確認と理由:
- 追加した仮定、残った未決事項:

## 人の確認後に追記する項目

### 人による判断
- 確認する人:
- 受け入れる / 修正を依頼する / 要件・設計へ戻す:
- 判断日:

## 条件があるとき、AIへ渡す前に書く項目
- 新しい外部ライブラリ・サービス・費用の可否:
- 読み取り・書き込みを許可する範囲:
- ネットワーク、外部ツール、追加インストールの可否:
- 秘密情報、破壊的な変更、本番操作に関する禁止事項:

許可する操作と停止条件を分ける

タスク票に「変更しない」と書くことと、AIが技術的に変更できないよう制限することは別です。利用するAIが実行範囲の制限、権限設定、承認機能を持つ場合は、タスク票の範囲に合わせて設定します。

Codexでは、サンドボックスがAIに技術的に可能な操作範囲を、承認設定が承認判断を必要とする地点を制御します（Agent approvals and security）。サンドボックスは、ファイルの書き込みやネットワーク利用等を制限する仕組みです。この仕組みと設定名はCodex固有です。ほかのAIでは、読み取れる情報、書き込める場所、ネットワーク、外部ツール、承認の既定値を、その製品の公式資料で個別に確認します。

権限制御がない場合、秘密情報、本番環境、破壊的な操作をAIへ許可しません。必要な操作だけを人が別に行うか、適切な責任者と管理された環境へ戻します。

AIへ渡して結果を確認する

この記事では、初めて進める読者は、依存表で次に進める一件のタスク票だけをAIへ渡します。調査タスクならコード変更を許可せず、実装タスクなら対象範囲と確認方法を明示します。関連箇所が分からないのに、存在しないファイル名や処理名を推測して指定しません。並行実行には依存関係、同時に触る箇所、権限の別の評価が必要なため、本記事では扱いません。

AIからは、生成したコードだけでなく、変更した場所と理由、実行した確認、実行できなかった確認、追加した仮定を受け取ります。「テスト済み」とだけ報告された場合は、実行したコマンド（端末への指示）や手順、結果を確認します。実行していない確認は、成功したものとして扱いません。

結果を受け取った人は、次の順に確認します。

  1. タスク票の対象外へ変更が広がっていないか。
  2. 対応する受入条件を、決めた方法で確認できたか。
  3. 必要なテストとビルドが実際に実行され、結果が記録されているか。
  4. 未承認の依存関係、権限、外部通信、費用が追加されていないか。
  5. 変更が要件の意図と既存の設計に合っているか。

テスト結果とは別に、AI生成コードが要件、意図、既存の設計へ合っているかを人が確認します（GitHubのAI生成コードのレビューガイド）。テストが通ったことだけで、要件の正しさや範囲外の変更がないことまで証明したとは扱いません。

確認が終わるまで、後続タスクを完了扱いにしません。結果が計画と違えば、未着手のタスク、依存順、確認方法を更新します。変更をGitで確認し、保存または戻す手順はGitで変更を確認・保存・戻すで扱います。AI生成コードの確認手順はAI生成コードをレビューするで、テストの選び方はテストの種類と選び方で扱います。

次へ進むか判断する

結果を確認した後、次の五点を説明できれば、次の一件の実装タスクをAIへ渡せます。

  • このタスクの完了条件と必要な理由が一つに絞られている
  • 最終的に支える要件・受入条件を特定でき、前提タスクと判断が完了している
  • 変更範囲が分かり、分からない部分は調査タスクへ分けている
  • 確認方法があり、必要なテスト変更を同じタスクへ含めたか、確認可能な先行タスクとして完了している
  • 許可する操作、停止条件、結果を確認する人が決まっている
状態 次の行動
完了条件が複数ある 実装タスクを分け直す
影響範囲や実現方針が分からない 調査タスクへ戻す
業務判断、権限、費用、公開範囲が未決である 判断者へ戻す
既存コードの責務や依存関係を説明できない コードアーキテクチャの種類と選び方を確認する
五点を満たしている 次の一件をAIへ渡す

実装タスクは、一度決めたら変えない計画ではありません。一件を実装して確認するたびに、実際に分かったことを次のタスクへ反映します。AIへ次の依頼を送る前に、人による受入結果を記録してから次へ進みます。

出典