はじめに
AIコーディングエージェントを使うと、実装の初速はかなり上がります。
ただ、2025年に使っていて何度も感じたのは、実装が速いほど、仕様のズレも速く混ざるということでした。
そこで、自分はAIに実装させる前に、最低限のテスト観点を書くようにしました。
この記事では、その運用を短くまとめます。
先に実装させて困ったこと
最初は、AIに次のように頼んでいました。
このIssueの内容を実装してください。
関連ファイルを読んで、必要な変更をしてください。
これでも動くコードは出ます。
でも、あとから確認すると、次のようなことが起きがちでした。
- エッジケースが抜ける
- 期待する失敗時の挙動が曖昧になる
- 実装後にテストを合わせにいってしまう
- レビュー時に「何を満たせばOKか」を再確認する
AIが悪いというより、入力が実装寄りすぎたのだと思います。
テスト観点を先に書く
そこで、実装前に次のような短いメモを置くようにしました。
この記事では、特定のフレームワークやテストランナーの設定には踏み込みません。そこを詳しく書くと技術ガイドになりますが、ここで残したいのは、チームでAIを使うときに「何を先に固定すると迷いにくいか」です。
# test-cases.md
## 正常系
- 入力Aのとき、結果Bになる
## 異常系
- 必須値がないとき、エラー表示になる
## 境界値
- 空文字のとき、保存処理を走らせない
## 回帰確認
- 既存の表示や保存処理は変えない
ポイントは、最初から完全なテストコードにしないことです。
まずは、人間が期待する振る舞いを固定します。
AIへの依頼文も変える
テスト観点を書いたあとは、AIへの依頼も変えます。
まず test-cases.md を読み、今回満たすべき振る舞いを要約してください。
その後、実装計画を作ってください。
まだコードは変更しないでください。
いきなり実装させないのがポイントです。
AIがテスト観点をどう理解したかを先に見ると、仕様のズレを早い段階で見つけやすくなります。
実装後の確認も楽になる
実装後は、AIに次の形で確認させます。
test-cases.md の各項目について、どの変更で満たしたかを説明してください。
満たせていない項目があれば、未対応として明記してください。
この出力があると、人間のレビューも始めやすくなります。
レビューの入口が「コード全体を読む」ではなく、「事前に決めたテスト観点と差分が対応しているか」になるからです。
よかったこと
このやり方でよかったのは、AIの自由度を下げすぎずに、確認の軸を固定できることでした。
AIには実装の探索を任せます。
一方で、何を満たすべきかは先に人間が決めます。
この分担にすると、AIの出力を後から追いかける時間が減りました。
特にチーム開発では、次の効果がありました。
- レビューで見る観点が揃う
- スコープ外の改善に気づきやすい
- 「動いたからOK」になりにくい
- 途中でセッションが切れても再開しやすい
注意点
テスト観点を書いたからといって、AIの出力が必ず正しくなるわけではありません。
むしろ、テスト観点はAIを信用するためではなく、人間が判断しやすくするための道具です。
曖昧な観点を書けば、曖昧な実装になります。
だから、最初は少なくてもいいので、具体的に書く方が効きます。
NG: エラー処理をちゃんとする
OK: APIが500を返したとき、保存済み表示を出さず、再試行できるエラー文言を表示する
まとめ
2025年にAIコーディングエージェントを使ってみて、実装前のテスト観点がかなり重要だと感じました。
AIはコードを書くのが速いです。
だからこそ、何を満たすべきかを先に固定しないと、あとから人間が仕様を追い直すことになります。
実装の前に、テスト観点を書く。
AIにまず理解を要約させる。
実装後に、差分とテスト観点の対応を説明させる。
この小さな順番の変更だけで、AIとのチーム開発はかなり扱いやすくなりました。