【通算091｜要求AI 08】設計書からタスクリストへ——AIが書いた「実装計画」には何が書かれているのか

2026年7月21日 21:15

Kiroに関するこれまでの記事は以下のとおり。

前回、要件定義書から技術設計（書）ができた。SDD（仕様駆動開発）の3点セットの最後はタスクリスト（実装計画）だ。kiroは技術設計書からタスクリスト（実装計画）を生成する。
要件定義（書）、技術設計（書）、タスクリスト（実装計画）のそれぞれは、管理番号で紐付けされている。変更があれば、管理番号から影響範囲を追跡できる。

生成は8分半

入力欄に「タスクリストを生成してください」と送ると、Kiroは「requirements.md と design.md の両方が揃っているので、タスクリストを生成します」と、ファイルの存在で前提条件を確認してから進んだ。要件が無ければ設計は作れない、設計が無ければタスクは作れない。

スペックのフォルダに tasks.md が加わり、要件・設計・タスクの3点セットが揃う

約8分30秒・1.53クレジットで tasks.md（276行）が完成した。

実装計画に書かれていたもの

中身は15個のタスクに分解され、注目すべき仕掛けが4つ入っていた。

1. 各タスクに要件番号が付いている。 たとえば「締め日ルールの実装」タスクには Requirements: 1.3, 1.4, 6.3 と参照が付く。これで要求（4つの視点の指示）→要件（Requirement N）→設計（Validates: N）→タスク（Requirements: N）と、ひとつの番号が文書3つを貫通した。要件トレーサビリティが、20分・5クレジット弱で組み上がったことになる。

2. テストタスクに「スキップ可」の印。 プロパティテストやユニットテストの作成タスクには * 印が付き、「MVP（最小限の製品）を急ぐならスキップ可能」と明記される。品質と速度のトレードオフを、計画の段階で選べるようにしてある。

3. 人間のチェックポイントが3か所。 「ここまでのテストが全て通ることを確認する。疑問があればユーザーに聞く」というタスクが、序盤・中盤・終盤に埋め込まれている。

4. 末尾にタスクの依存関係グラフ。 どのタスクとどのタスクが並列に実行できるかを、14段階の「ウェーブ」としてJSON形式で定義している。これは飾りではなく、後の実行エンジンが実際にこの通りに並列実行する（次回、その様子を紹介する）。

タスクリストは「ドキュメント」であり「実装指示」だった

tasks.md をKiroで開くと、Markdownファイルの表示（中央）と実行ボタン（上部の紫のボタン）が表示される。

中央に表示された、タスクの上には「Start task」（1つずつ実行）、画面右上には「Run all tasks」（全タスク一括実行）。
つまりこのタスクリストは、人間が読むための実装計画（書）であると同時に、AIに渡す実行指示（書）でもある。実行が始まるとチェックボックスがライブで [x] に変わっていき、文書がそのまま進捗管理表になる。

気になる綻びも、引き継がれた

前回、設計書に紛れ込んだ「下書き（DRAFT）」は、タスクリストではどうなったか——型を定義するタスクはあるのに、下書きを扱う実装タスクはどこにも無い。このまま実装すれば、誰も使わない状態が型にだけ残る。

これで文書は揃った。あとは右上のボタンを押すだけ——次回は、42タスクの一括実行で何が起きたかを、クレジットの消費もつまずきも含めて時系列で紹介する。

タクスリスト（tasks.md）の実際

タスクを含むディレクトリとオーバービュー

タスクリストの一部
タスクリストの実際例、タスク名と実装の内容の実際、タスクの先頭に実装済みのチェックマークがある。タスク名の最後に要件定義との対応番号

今日のまとめ

タスクリストは8分半・1.53クレジットで生成。15タスク、各タスクに要件番号付きで、要求→要件→設計→タスクの番号貫通が完成した
テストのスキップ可否、人間のチェックポイント、並列実行の依存関係グラフまで、実行を見据えた計画になっている
tasks.md は読む文書ではなく「押す文書」。実行ボタンが付き、チェックボックスが進捗板になる
一方で「下書き」の綻びは3文書を素通り——文書間の整合はAIも見落とす