はじめに

AIコーディングエージェントを使うと、実装の初速はかなり上がります。

ただ、2025年に使っていて何度も感じたのは、実装が速いほど、仕様のズレも速く混ざるということでした。

そこで、自分はAIに実装させる前に、最低限のテスト観点を書くようにしました。

この記事では、その運用を短くまとめます。

先に実装させて困ったこと

最初は、AIに次のように頼んでいました。

このIssueの内容を実装してください。
関連ファイルを読んで、必要な変更をしてください。

これでも動くコードは出ます。

でも、あとから確認すると、次のようなことが起きがちでした。

AIが悪いというより、入力が実装寄りすぎたのだと思います。

そこで、実装前に次のような短いメモを置くようにしました。

この記事では、特定のフレームワークやテストランナーの設定には踏み込みません。そこを詳しく書くと技術ガイドになりますが、ここで残したいのは、チームでAIを使うときに「何を先に固定すると迷いにくいか」です。

# test-cases.md

## 正常系

- 入力Aのとき、結果Bになる

## 異常系

- 必須値がないとき、エラー表示になる

## 境界値

- 空文字のとき、保存処理を走らせない

## 回帰確認

- 既存の表示や保存処理は変えない

ポイントは、最初から完全なテストコードにしないことです。

まずは、人間が期待する振る舞いを固定します。

テスト観点を書いたあとは、AIへの依頼も変えます。

まず test-cases.md を読み、今回満たすべき振る舞いを要約してください。
その後、実装計画を作ってください。
まだコードは変更しないでください。

いきなり実装させないのがポイントです。

AIがテスト観点をどう理解したかを先に見ると、仕様のズレを早い段階で見つけやすくなります。

実装後は、AIに次の形で確認させます。

test-cases.md の各項目について、どの変更で満たしたかを説明してください。
満たせていない項目があれば、未対応として明記してください。

この出力があると、人間のレビューも始めやすくなります。

レビューの入口が「コード全体を読む」ではなく、「事前に決めたテスト観点と差分が対応しているか」になるからです。

このやり方でよかったのは、AIの自由度を下げすぎずに、確認の軸を固定できることでした。

AIには実装の探索を任せます。

一方で、何を満たすべきかは先に人間が決めます。

この分担にすると、AIの出力を後から追いかける時間が減りました。

特にチーム開発では、次の効果がありました。

テスト観点を書いたからといって、AIの出力が必ず正しくなるわけではありません。

むしろ、テスト観点はAIを信用するためではなく、人間が判断しやすくするための道具です。

曖昧な観点を書けば、曖昧な実装になります。

だから、最初は少なくてもいいので、具体的に書く方が効きます。

NG: エラー処理をちゃんとする
OK: APIが500を返したとき、保存済み表示を出さず、再試行できるエラー文言を表示する

2025年にAIコーディングエージェントを使ってみて、実装前のテスト観点がかなり重要だと感じました。

AIはコードを書くのが速いです。

だからこそ、何を満たすべきかを先に固定しないと、あとから人間が仕様を追い直すことになります。

実装の前に、テスト観点を書く。

AIにまず理解を要約させる。

実装後に、差分とテスト観点の対応を説明させる。

この小さな順番の変更だけで、AIとのチーム開発はかなり扱いやすくなりました。