AI駆動開発入門！具体的なタスクの進め方【全ツール対応】
Cursor、Windsurf、Cline……。昨今たくさんのAIコーディングツールが出てきていますが、意外と他人がどんなプロンプトを書いているか知らない人も多いのでは？
雑に「〇〇を実装して」だけでもそれっぽいものができますが、実務だとそうはいきません。
この記事では、筆者が実践している AI駆動開発の「設計やコーディング段階」の具体的な進め方 を解説します。どのAIコーディングツールでも使えます。
「TODOアプリとかテトリスを作るのではなく、日ごろの開発で使えるテクニックを知りたい」という人向けです。
先にまとめ
「ラベル付きタスクファイル」を用意して、タスクを進めるときは最初に添付します。
ラベル付きタスクファイルとは
ラベル付きタスクファイルが何かを説明する前に、先にテンプレートを見たほうが早いので載せます。
# タスク「」のタスクを整理するためのチェックリストです。チェックリストを作成したりタスクが増えたら、ユーザーの指示がなくても編集してください。チェックリストのタスクが完了したらユーザーの指示がなくても編集してください。
## やりたいこと
## チェックリスト
`A: `のようにアルファベットのラベルをつけることで、参照しやすくする
### 1. タスク分解
- [ ] A: タスク分解して2以降のチェックリストを書き換える
### 2. ここを書き換える
- [ ] A: ここを書き換える
### 3. ここを書き換える
- [ ] A: ここを書き換える
……※最後の……の部分は省略ではなく実際に……と書いています。
上記がラベル付きタスクファイル（以下タスクファイル）です。
「〇〇の機能追加」「〇〇のバグ調査・修正」など、タスク毎に作成するファイルです。AIがそのタスクを進めるにあたって必要な情報を管理します。
タスクファイルを使ったAI駆動開発の流れ
まずは流れを解説 します。「メリット」「Tips」は後で書きます。プロジェクトの「概要」「ディレクトリ構成」「使っている言語やフレームワーク」などはプロジェクトルールに書いているものとします。
1. タスクファイルを作成する
まず前述のテンプレートを使ってタスクファイルを作ります。置き場所はどこでもいいです。ファイル名はtask_〇〇.mdとします（理由は後述）。
たとえばこんな感じ。
# タスク「GoogleマップにDBデータをピンとして表示するやつを実装」のタスクを整理するためのチェックリストです。チェックリストを作成したりタスクが増えたら、ユーザーの指示がなくても編集してください。チェックリストのタスクが完了したらユーザーの指示がなくても編集してください。
## やりたいこと
- packages/front/src/components/Map.ts に実装したい- Google Maps APIのライブラリは[@vis.gl/react-google-maps](https://www.npmjs.com/package/@vis.gl/react-google-maps)を使う - 関連する環境変数はまだ packages/front/doc/env.md に書いてないから追記したい - ピンをクリックしたらモーダル表示- DBの取得は packages/front/src/components/Schedule.ts を参考にする - スキーマは packages/api/src/drizzle/schema/m_pins.ts にある- デザインは後で直すのでtailwindで適当に書く
## チェックリスト
`A: `のようにアルファベットのラベルをつけることで、参照しやすくする
### 1. タスク分解
- [ ] A: タスク分解して2以降のチェックリストを書き換える
### 2. ここを書き換える
- [ ] A: ここを書き換える
### 3. ここを書き換える
- [ ] A: ここを書き換える
……タスクの下に「大まかなタスクの内容」、「やりたいこと」に今考えていることを思いつくままに書きます。
2. まずはタスク分解させる
ファイルを作ったらAIにタスク分解をしてもらいます。プロンプトは次のような感じです。
@docs/task_google_maps.md に沿ってタスクを進めてて、今は1-A。足りない情報があれば質問してね※「タスク分解（タスクばらし）って何？」という方はてぃーびーさんのタスクばらし入門を読みましょう。コーディング以外でも使えるテクニックです。
※@ファイル名はファイルの添付を表現したもので、ツールによって表示が異なります。
こうすると、AIが「やりたいこと」に基づいてタスク分解をして曖昧な部分は質問してくれるので、人間側はそれに回答していきます。こうしてタスクを進めるためのチェックリストができあがります。
ある程度まとまったらAIが「ファイルに書き込もうか？」って聞いてくるので書き込んでもらいます。
3. いったんコミット
タスク分解が終わったら、いったんコミットします。筆者はAIにコミットメッセージを書かせることも多いですが、ここではトークンを節約したいのでAIを使わず、chore: タスクの整理というメッセージにしてます。
4. 新しいチャットにする
チェックリストができたら、新しいチャットにしてからタスクを進めます（プロンプトは次のセクションで説明します）。「タスクファイル1つ」に対して「複数のチャット」でタスクを完了させる、というイメージです。
なんで新しいチャットにするの？
まずは単純に、会話が長くなるとAIが最初の方の忘れていくためです。
また、全部同じチャットだとスクロールが長くなって履歴が見づらくなります。
チャットをリセットするたびに「同じ質問・指示が出てきた」場合、 頭の中にしかなかったものをファイルに記述するよい機会 にもなります。
たとえば、チャットをリセットするたびに「デザインはインラインスタイルじゃなくてTailwind CSSで書いて」と指示を出していたとします。すると、
「これはプロジェクト共通のルールだから、ツールのルールファイルに書くか」
「これはこのタスク共通だからタスクファイルに書いておこう」
などなど、改善のための気づきが生まれます。
5. まずは実装方針を考えてもらう
チャットをリセットしたら、次はより具体的・詳細な実装方針を考えてもらいます。
@docs/task_google_maps.md に沿ってタスクを進めてて、今は2-A。まずは実装方針を考えてね上記のように指示をすると、AIがチェックリストを読み取って実装方針を考えてくれます。
「実装が決まりました」とか「これでいい？」みたいなことを聞かれるまで会話しましょう。
6. 実装してもらう
実装方針が決まったら、後は実装してもらうだけです。
じゃあ実装よろしく！7. 修正がある場合
修正させたい場合は、そのケースに応じて次のいずれかを行います。
- 追加で指示をする
- チェックポイント機能を使って会話を途中からやり直す
- 実装方針が悪かったらチャットをリセットしてやり直す
- いったんコミットして、タスクファイルに新しくチェックリストとして追加する
8. コミットする
チェックリストにチェックを入れるのもAIがやってくれます。が、たまにやってくれないこともあるのでそのときは人間がやりましょう。
チェックを確認したらコミットします。
9. 繰り返す
全部のチェックが埋まるまで4（チャットのリセット）～8（コミット）までを繰り返します。
メリット
「いやファイルに書くだけじゃん」と思うかもしれませんが、いくつかメリットがあります。
タスク分解をAIに任せられる
タスク分解はAIがやってくれます。人間側は「やりたいこと」に「思いつくまま」書くだけでよいです。あなたの頭にしかない情報をコンテキストとして共有する準備になります。
「思いつくままに」というのがミソです。人間に対する指示だと正直「ふざけんな！」と思う曖昧な表現でも、AIとの会話を通じてちゃんと深堀りできます。きれいな文章やタスクの順番・粒度を考えるのはAIに任せられるのです。
AIとのやりとり効率化
ラベルをつけることで、「1-Bのタスクを進めて」のように指示がしやすくなります。
「次はMapsコンポーネントの承認ボタンを実装して」とかいちいち書くよりもラベルの方が入力は楽です。
チェックリストなんだから「続きを進めて」でいいと思うかもしれませんが、実際には最適な順番が前後することもあるので、ラベルを付けた方がよいです。
プロンプトが短くスッキリ
タスクに関係することを1つのファイルに集約するため、プロンプトが短くなります。
プロンプトの入力欄はそもそも長文の入力に適していない実装が多いですよね。「タスクファイルを書くときだけ別のエディタを使う」というのも可能です。
変更差分がわかりやすくなる
タスクファイルをコミットに入れることで、人間にもAIにも変更差分が明確になります。
チェックリストのチェックが付いた差分を見れば、「このタスクが終わったんだな」というのが分かりやすいです。コミットメッセージを考えるAI（や人間）にとって、うれしいメリットです。
月曜朝の救世主
「金曜の夕方にやっていたタスク」を「月曜の朝に再開する」というように、間が空いてからタスクを再開するときに便利です。タスクファイルを見ればどこまで進めたかが一目瞭然です。
「これまでの実装概要」を伝えられる
「これまでの実装概要」がチェックリストに書かれています。このおかげで、会話をリセットした後に「この関数さっき書いたのに また似たような関数書いているな」というのを防げます。
別のタスクでも使ってほしい関数なら「ルールファイル」に書いたり、その都度ファイルを添付して伝えればよいです。「AIって同じ処理何回も書いてくるよね」と言っている人の大半は、適切なコンテキストを与えていないのが原因です。
どのツールでも使える
タスクファイルはどのAIコーディングツールでも使えるテクニックです。途中からツールを変えたくなっても対応できます。
Claude CodeにはTODO機能もありますが、タスクファイルと一緒に使ったほうが筆者は進めやすかったです。タスクファイルのチェックリストをそのTODO機能に反映してくれます。
Tips
「流れ」に書くと長くなってしまうのでいったん省いた内容をここに書いていきます。
モードを適宜切り替える
「モード切り替え」ができるツールの場合は適宜切り替えましょう。
たとえば「タスク分解」「実装方針を考えてもらう」段階では「思考・設計」に適したモードに切り替えておきます。
| ツール例 | モード |
|---|---|
| Cline | Planモード |
| Roo Code | Architectモード |
併せて、Reasoning Model（推論モデル）を使える場合はこちらも適宜切り替えましょう。
「ファイル編集」が発生する段階に移ったら、コーディングに適したモードやモデルを切り替えます。
メインファイルは適宜添付
そのタスクのメインとなるファイルが存在すれば、チャットの最初のメッセージでは添付しておいたほうがよいです。「AIがファイルを検索する」という手間が省けます。
タスク分解のときのプロンプトの例は次のとおりです。
@docs/task_google_maps.md に沿ってタスクを進めてて、今は1-A。足りない情報があれば質問してね関連ファイル: @packages/front/src/components/Map.ts参考ファイルがあればそれも添付しておくとよいでしょう。
@docs/task_google_maps.md に沿ってタスクを進めてて、今は3-D。まずは実装方針を考えてね。メインファイル: @packages/front/src/components/Map.css参考ファイル: @packages/front/src/components/Book.cssタスクファイルって削除するの？
タスクが完了したら見返すことは少ないと思うので削除してよいです。というかファイルの添付の入力で補完候補が多くなって邪魔なので削除したほうがいいです。
筆者は 次のタスクファイルを作成したタイミングで 削除することが多いです。「次のタスクファイル」が前回のタスクファイルと似ていて一部をコピペすることもあるからです。
commit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxDate: Sat May 31 17:42:01 2025 +0900
chore: task update--- docs/task_action.md | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ docs/task_parser.md | 69 -------------------------------------------------- 2 files changed, 87 insertions(+), 69 deletions(-)タスクファイルの場所・名前は？
場所は分かりやすければどこでもいいと思います。筆者はだいたいdocs/に配置してます。タスクファイルは複数並行することもあるのでdocs/task/みたいなディレクトリを作るのもアリです。
ファイル名はtask_*.mdのようにprefixを付けてます。ツールによっては次のように「ファイルの添付の入力で、補完候補のファイル名だけが目立つ」表示になっています。そのためprefixを付けておくと 区別しやすい です。
task_foo.md docs/Maps.ts src/components/後からタスクが増えた・変わった場合
タスクが増えた場合、次のように手動で編集すればよいです（もちろんAIにやらせてもよいです）。
### 2. コンポーネントの実装
- [ ] A: Map.tsの作成- [ ] A-1: Maps.tsの作成- [ ] A-2: Maps.cssの作成ラベル付けはあくまでプロンプトで参照しやすくするためのものです。前述のように必ずしもラベルの順に実装してくわけではありません。そしてB->C・C->Dのようなアルファベットずらしは面倒です。
そのため、筆者は番号を生やすだけの編集にしてます。
そのタスクではやらないことも明記
そのタスクではやらないことを明記するのもよいです。たとえば筆者がタスクファイルによく書いているのは次のような文章です。
デザインは後で決めるので適当でいいよすでにビジネスロジックは実装済みなので、そこは変えずにテンプレート・スニペットとして管理しよう
タスクファイルやプロンプトはテンプレート・スニペットツールに登録しておくとよいでしょう。
筆者はタスクファイルのテンプレートをdotfilesとして管理しています。
以上、AI駆動開発の「コーディング」「壁打ち」などの段階における具体的な進め方の解説でした。
もう少し日が経ってから書こうかなと考えていたのですが、先日登壇したAI駆動開発勉強会の沖縄支部第1回の懇親会でちょっと盛り上がったので、前倒しで記事にしました。