こんにちは。Mitz（ミッツ）です。
最近はAIを開発に取り入れることが当たり前になりつつありますが、
「実際どのくらい効率化できるの？」
「AIに任せても精度大丈夫？」
と感じている方も多いと思います。
今回、Devin × Cursor を活用しつつ TDD を取り入れることで、工数を約1週間短縮できたので、その具体的なやり方をシェアします 🚀
ざっくり結論
- 要件整理とタスク分解はAskDevinで一気に効率化
- 実装はCusor×TDDで「AIに任せる部分の精度」を担保
- 並行開発が可能になり、結果的に1週間短縮できた
AskDevinで要件整理からタスク分解まで
Devin には「AskDevin」というリポジトリ解析機能があります。
既存コードへの影響調査などの理解やコンテキストの持ち方がタスク分解仕様調査に向いていると感じてるのでDevinを愛用してます
これを活用して、着手からリリースまで約2週間かかりそうな機能開発の 要件整理〜タスク分解 を進めてみました。
ステップ1 要件の整理
PdMが作った仕様書を Devin に渡し、仕様や達成すべきゴールを整理。
疑問点が出たらPdMに確認し、その回答をまたDevinにフィードバックすることで認識をすり合わせました。
今回はサンプルの要件を使用します！
# タスク概要 ユーザーのログイン機能
# 実現したいこと ユーザーがサービスにログインできること
# 前提・制約 ログインのログはDBに保存する
# 詳細
## ログ
1. ユーザーがログインした際にユーザーID/ログイン日時をDBに保存する
2. ユーザーが複数回ログインした際は日時を更新し、複数レコードは作成しない
3. 過去の確認日を保持する必要はない
プロンプトは以下のようにしました
以下のタスクについて、実装者がスムーズに実装できるように、詳細な実装プランを立ててください。
# タスク概要 ユーザーのログイン機能
# 実現したいこと ユーザーがサービスにログインできること
# 前提・制約 ログインのログはDBに保存する
# 詳細
## ログ
1. ユーザーがログインした際にユーザーID/ログイン日時をDBに保存する
2. ユーザーが複数回ログインした際は日時を更新し、複数レコードは作成しない
3. 過去の確認日を保持する必要はない
期待するアウトプット
- 実装のステップを順序立てて記述（大まか → 詳細へ）
- コンポーネント構成・関数・ロジック単位に分解
- 必要に応じてコード例も含める
- 実装者が迷わずタスクを進められるレベルで具体的に
具体的なコードを含むのでテキストのみになりますが、以下のような内容がDevinから返ってきました。
今回のタスクは ユーザーがサービスにログインできる機能 を実装するものです。 加えて、ログイン日時をDBに保存し、複数回ログイン時には日時を更新、過去の記録は保持しない、という要件があります。
実装プランのサマリ
1. データベース構造の確認
ユーザーIDとログイン日時を格納するテーブルを用意
ユーザーIDにユニーク制約を設け、複数レコード作成を防止
カラム例：
user_id (UUID)
last_login_at (Timestamp)
2. バックエンド実装ステップ
ログイン処理
ユーザー認証を行うコントローラー／サービスを実装
ログイン成功時に last_login_at を現在時刻で更新（既存レコードがあれば更新、なければ新規作成）
複数ログイン対応
upsert 的な処理で、複数回ログイン時も同一ユーザーで単一レコードを維持
テスト
正常系：ログイン成功時に日時が更新されるか
異常系：存在しないユーザーや認証失敗時にレコードが更新されないか
複数回ログイン時に重複レコードが作成されないか
3. フロントエンド実装
ログインフォームコンポーネントを用意
バックエンドAPIにリクエストし、レスポンスに応じてログイン状態を管理
入力バリデーションやエラーハンドリングも必要
4. 実装時の注意点
トランザクション管理
同時ログインなどで日時更新が競合しないように注意
セキュリティ
パスワードや認証トークンの管理は安全な方法で実装
テストの粒度
正常系から先に実装し、異常系は後回しでPRを分けることも検討
ログの保守性
将来的にアクセス解析などで利用する場合はスキーマやカラム名を拡張しやすく設計
ステップ2 動作確認項目を生成
整理した要件をもとに、AIに「動作確認項目」を出してもらいました。
統一フォーマットで出力されるので、仕様の抜け漏れや影響範囲を俯瞰しやすいのがメリットです。
ただし、たまに仕様の誤解が混ざるので、人間のレビューは必須でした。
動作確認項目は、チーム内で既に運用しているフォーマットを Devin に渡して作成してもらいました。
フォーマットはこんな形です：
| No. | 画面 | 条件1 | 条件2 | ユーザー操作 | 期待される挙動 | デグレチェック？ | OK / NG |
|---|---|---|---|---|---|---|---|
| 1 | ログイン | 正しいID入力 | 正しいPW | 「ログイン」ボタン押下 | ダッシュボードに遷移する | No | |
| 2 | ログイン | 誤ったID入力 | 正しいPW | 「ログイン」ボタン押下 | エラーメッセージを表示する | No |
ステップ3 タスク分解
次にタスク分解を依頼。
「Jr.エンジニアが4時間で終わる粒度で」と指定すると、ちょうどよい大きさのチケットに分割されました ✅
さらに、実装箇所のサンプルや作業毎の見積りも出してくれるので、チケット運用がスムーズになりました。
ステップ4 TDDプランを作成
最後に「t-wada流のTest-Driven Development で進める計画を出して」と依頼。
「t-wada流の Test-Driven Development で進める計画を出して」と依頼したのは、ちょっとした“おまじない的”な意味があります。なぜなら、t-wadaさんが複数の執筆・発言で 「Red → Green → Refactor」のサイクルを丁寧に積み重ねる TDD の流儀 を繰り返して紹介されており、プロンプトに「t-wada流」を付けることで AI の出力がそのスタイルに近づきやすかったからです。
このおまじないについては、t-wada氏自身も「TDDで進めて」と言うだけだと、単に「先にテストをたくさん書く」といった振る舞いになりがちで、「一つテストを書いて、わざと失敗させてから、それをクリアにするコードを書く」という、より古典的で厳格なTDDをやってほしい。そのことを伝えるのに、自分やケント・ベックのような人名を使うのが便利であるという現象が報告されています。
実際、この「おまじない」については、t-wada氏自身も発言の中で触れています。
単に「TDDで進めて」と指示すると、「テストを大量に先に書く」といった誤解された振る舞いに寄りやすい。
そこで、「一つテストを書き、必ず失敗させてから、それを通すコードを書く」という古典的かつ厳格なTDDをきちんと伝えるには、
自分やケント・ベックのような人名を添えるのが有効だというのです。
これで 実装計画のひな形 ができたので、すぐにコードへ移行できました。
下はKent Beck氏の投稿の翻訳を含む**和田卓人氏(T-wada)**の記事です。
TDDについて興味のある方は一度読んでみてください！
シンプルな例ですが、最初のテストはこんなイメージです：
// login.e2e-spec.ts
it("正しいIDとPWでログインが成功すること", async () => {
const requestArgs = {
email: 'test@example.com',
password: 'validPassword123'
};
await request(app.getHttpServer())
.post('/login')
.send(requestArgs)
.expect(204);
});
Cursor × TDDで実装を加速
実装フェーズでは主に Cursor を活用しました。
まずは 正常系のテストケースから優先して実装 を進め、異常系は後回し（場合によっては PR を分けて対応）しました。
AI エージェント（Cursor など）は、往々にして一気に実装を生成しがちです。そこであえて TDD を意識して「小さなステップで進めてもらう」ように指示 をしました。
具体的には、AI に渡す際に「このテストが Green になれば、仕様の一部が満たせる」という粒度でテストを用意。そのテストが担う仕様を意識しながら、一つずつ実装を積み上げていきました。
この進め方により、人間側でも AI が生成したコードをステップごとに確認でき、仕様の網羅性や抜け漏れをチェックしやすかった のが大きなメリットでした。
PR の粒度としては、いくつかの正常系が Green になった時点でレビュー依頼を行い、短いサイクルで進められたのが良かったです。
AI に BE 実装を任せつつ、自分は FE を進めるなど、並行開発がしやすくなったのもメリットでした。
結果として、レビュー時の修正も少なく、予定より1週間早く完了できました🎉
やって良かったこと
- 仕様の解像度があがった
→ Devinと要件をすり合わせることで仕様の解像度が上がり、漏れや影響範囲を事前に洗い出すことができた。 - 曖昧な実装が減った
→ 達成すべき要件をテストとして先に定義していたため、AIに依頼する際も具体的な指示になり、期待通りの実装が返ってきやすかった。 - 並行開発がスムーズになった
→ Devinに任せられる部分を切り出せたことで、FEとBEを同時並行で進めやすかった。結果的に工数短縮につながった。 - 現行仕様のキャッチアップが早くなった
→ 「まずAIに投げてみる」ことで、現行仕様のキャッチアップが早くなり、開発に取りかかるまでのスピードが上がった。
難しかったこと
-
タスク依存関係の調整が大変
→ ファイル分割が適切でないと、AI実装でコンフリクトが起きやすい
-
テストの冗長化
→ AIが生成するテストはカバレッジが高い一方で、意味の薄いテストも混ざりやすかった。 -
プロンプト粒度の調整
→ 指示が抽象的すぎると実装がブレる。細かすぎると自分で書いた方が早い。このバランス感覚が難しかった。
まとめ
- 効率化の面では Devin を使うことで仕様の理解やタスク分解が格段に早くなり、タスク粒度も適切にそろえられました。その結果、AI に任せやすい単位で依頼できるようになり、人間側の作業も並列で進められたため、全体で約1週間の工数短縮につながりました。
- 精度の面では 「テストが Green になれば仕様がひとつ満たされる」という形で AI に依頼することで、実装の正しさをステップごとに確認しながら進められ、安心感がありました。
AIをそのまま実装に適用するには、まだ人間の工夫や補完が欠かせません。
しかしTDDと組み合わせることで、信頼性を担保しつつ開発スピードを加速できることを実感しました。
これからの時代は、間違いなく「AIとの協業」が当たり前になっていきます。ワクワクしますね。
👉これからAIを開発に取り入れる方へのTips：
- AIをメイン担当者として置きつつ、自分が壁打ち相手になる動き方だと相性が良いです
- AIと仕様の整理やタスク分解を行い、スコープとコンテキストの最小化しておくと良いです
- 実装は仕様をベースにテストから作成を指示すると精度が上がります
アスエネでは全方位で採用を強化中です！もし、SaaSの開発やマッチングビジネスなどに興味があれば、ぜひ採用サイトをチェックしてみてください。
💼 採用情報はこちら → アスエネ採用サイト
また、SNSからのカジュアルなご連絡も大歓迎です！興味のある方は、ぜひ気軽にご連絡ください。お待ちしています！
Discussion