Copilotで設計・実装・テストまで回すには？ 再現しやすい開発の進め方を整理してみた

はじめに

近年、GitHub Copilotをはじめとする生成AIを開発に取り入れる機会が一気に増えてきました。
一方で、実際に使ってみると「どこまでAIに任せるべきか」「どう進めると品質を崩さずに済むか」で悩む場面も少なくありません。

今回は、Copilotを活用しながら、設計から実装、テストまでをどのように進めると再現しやすいか、実際に試した流れをもとに整理してみます。

この記事でお伝えしたいのは、成果物そのものではなく、AIを使ってどう進めると再現しやすいか、その進め方の型です。

開発プロセスの全体像

まず全体像です。

今回の進め方は、突き詰めるととてもシンプルです。
指示を出す、mdにまとめる、実装する、差分を確認する。この流れを小さく回していきます。

重要なのは、判断は人が行い、たたき台作りはAIに寄せることです。

AIにすべてを任せるのではなく、人が決めるべきことを先に固め、その上でAIに整理や実装のたたき台を作ってもらう。
この順番にすることで、生成結果のブレを抑えやすくなります。

Step1：壁打ちしながら設計を具体化する

最初のステップは、壁打ちしながら設計を具体化することです。

すぐに決めきれない点については、いきなり実装させるのではなく、まずAIに問いかけます。
たとえば、

一般的にはどんな設計が多いか
案ごとのメリット・デメリットは何か
今回の要件ではどの案が向いているか

といった観点で整理してもらい、判断材料を揃えます。

そのうえで、API一覧、バリデーションルール、エラーハンドリング方針、データ項目の定義などをmdに落とし込みます。
必要に応じて状態遷移や異常系の扱いまで含めて先に明文化しておくと、後続の実装がかなり安定します。

ここで大事なのは、先に人間が判断を完了させることです。
AIが優秀でも、前提が曖昧なままでは解釈がぶれます。
逆に、人が判断を済ませておけば、AIは「何を実装すべきか」をかなり正確に捉えやすくなります。

Step2：mdを基準に小さく実装する

設計が固まったら、次はそのmdを基準にして、小さく実装していきます。

一気に全部を作るのではなく、1機能ずつ、あるいは1まとまりずつ、縦に切って進めるのがポイントです。
状態遷移の順に実装する、クラス単位で区切る、といった形で小さく依頼を出していくと、AIの出力も扱いやすくなります。

AIに寄せやすいのは、たとえば以下のような部分です。

コントローラーやサービスの骨格
DTOや例外クラス
テストコードの初稿

一方で、人がきちんと見るべきなのは以下のような点です。

設計方針との整合性
責務分離が適切か
不要な過剰実装が入り込んでいないか

AIは、骨格づくりや定型コードの初稿作成ではかなり強い一方で、少し先回りしすぎたり、今回の要件にはない処理まで入れてしまうことがあります。
そのため、設計は先に固める、実装は小さく回す、という形が相性の良い進め方だと感じました。

Step3：差分確認を前提に進める

AI活用で特に重要なのが、生成結果をそのまま採用しないことです。

差分確認では、たとえば次のような観点を見ています。

要件通りの挙動になっているか
入出力やエラーパターンが仕様と合致しているか
責務分離が崩れていないか
未定義の仕様を先回りした過剰実装がないか

要するに、コードが動くかどうかだけではなく、設計意図と合っているかまで確認する必要があります。

また、運用面では、実装用とレビュー用のチャットを分けるのも有効でした。
同じ文脈を長く引きずると、AIも人も見落としが出やすくなります。
一度別セッションでレビュー視点を持たせることで、少し客観的に差分を確認しやすくなります。

AIを使うと開発速度は上がりますが、そのぶん人間側のレビュー基準が曖昧だと品質が崩れやすくなります。
だからこそ、差分確認は省略せず、むしろ以前より意識的にやる必要があると感じました。

Step4：テストは観点定義から始める

テストも、いきなりコード生成から始めるのではなく、先に何を確認すべきかを言語化するところから入ります。

まず、テスト観点を洗い出し、それをmdでテストケースとして固定します。
そのあとでJUnitコードの生成に進み、失敗ログを見ながら修正ループを回す流れです。

この流れにすると、AIはかなり使いやすくなります。
特に、失敗ログをもとに修正案を出す部分は得意です。

ただし、何を期待値にするかは人が握っておく必要があります。
期待値そのものが曖昧だと、AIはもっともらしいテストコードを出してきても、本当に確認したいことを外してしまう可能性があります。

そのため、ここでも重要なのは、先に観点を決めることです。
テストコード生成の前に、何を検証対象とするのかを明確にしておくことが、結局は一番効率的でした。

成功の要因と、よくある失敗

ここまでの流れを振り返ると、うまく回しやすかった要因は主に4つあります。

1つ目は、AIとの壁打ちで設計判断を具体化したこと。
2つ目は、要件や設計をmdで固定してから実装したこと。
3つ目は、1回の依頼を小さく分割したこと。
4つ目は、毎回必ず人間による差分確認を入れたことです。

逆に、失敗しやすいのは次のようなパターンです。

いきなり「全部作って」と丸投げする
仕様や決め事が曖昧なまま進める
AIの生成結果を無批判に採用する
巨大な変更を一度に行う

結局のところ、AI活用の成否を分けるのは、AIそのものの性能だけではありません。
設計判断をどう詰めるか、どの粒度で進めるか、どうレビューするかといった、人間側の進め方の型がかなり大きいと感じています。

まとめ

今回ご紹介したのは、Copilotを使って設計から実装、テストまでをどう進めるか、という進め方です。

ポイントは、AIに全部任せるのではなく、判断や設計の視点は人が持ちながら、作業を加速する補助として使うことでした。

AIは、設計の壁打ち、実装のたたき台作成、テストコードの初稿作成、修正ループの補助など、開発のさまざまな場面で力を発揮します。
一方で、前提が曖昧なまま使うと、もっともらしいが意図とずれた成果物が出てきやすいのも事実です。

そのため、実際にうまく回すには、

先に人が判断する
判断内容をmdで固定する
依頼を小さく分ける
差分を必ず人が確認する

という進め方が重要になります。

AIを使うと、単に作業が速くなるだけではなく、どこを人が決めるべきか、どこを人が確認すべきかも、これまで以上にはっきり見えてきます。
そうした意味でも、AI活用は単なる効率化ではなく、開発の進め方そのものを見直すきっかけになると感じています。

今回の内容が、日々の開発の中でCopilotを活用する際のヒントになればうれしいです。