AIエージェントを使う開発チームで、最近よく見かける光景がある。機能の実装をエージェントに任せると、コードを書き、テストを実行し、失敗すればテストのほうを黙って書き換えて、すべてが緑になるまで調整する。ダッシュボードを見ると、ビルドは通り、パイプラインは緑、テストはシステムが正しく動くことを確認している——一見、健全に見える。
だが、「何に対して」正しいのか。
これが、エージェンティック・コーディングの時代に浮上してきた、少し落ち着かない問いだ。実装と、その実装が正しいという証拠を、同じプロセスが両方作り出しているとき、誰が独立した立場で検証するのか。
自作自演のテスト——便利だが、コードの鏡になりかねない
従来、自動テストは独立した審判のような役割を期待されていた。あるべき振る舞いを記述し、コードがそこから逸脱したときに警告を出す存在だ。
問題は、AIエージェントがコードを書き、同時にテストも書いたり修正したりする場合、この独立性が静かに失われてしまうことだ。エージェントは機能を実装し、テストを実行し、失敗を見つけ、テストが通るまで調整する。理屈は通っているように見えるが、結果として出来上がるテスト一式は、いま実装が実際にやっていることを単に記述しているだけで、本来やるべきことを検証してはいない、という状態になりかねない。
このリスクは、エージェントが期待される振る舞いをソースコード自体から推測している場合、さらに深刻になる。実装に要件の誤解があれば、そこから生成されたテストも同じ誤解をそのまま追認してしまう。この時点で、テスト一式はもはや検証の道具ではなく、コードを映す鏡にすぎない。
非常に現実的な兆候がある。エージェントが毎セッション、E2Eテストの「修繕」だけに十分以上を費やしている——アサーションを書き直し、セレクタを差し替え、スナップショットを再生成する。セルフヒーリングのツールは技術的な部分(UIが少し変わっただけでテストが壊れない)は解決してくれるが、もっと重要な部分——そのテストの背後にある期待される振る舞いが今も正しいかどうか——は解決してくれない。テストの修繕が延々と続くのは、たいてい、コードから独立した「期待される振る舞い」の定義がチームにそもそも存在しない、という兆候であり、エージェントには意図的な仕様変更なのか、本物のリグレッションなのかを見分ける手立てがない。
業界の他のチームからも、それぞれ独自の視点から似たような観察が上がっている。一つのエージェントがコードとそのテストの両方を書く場合、二つのアウトプットは同じ死角を共有してしまう。エージェントが要件を読み違えれば、そこから生まれるテストはその誤りを見つけるどころか、そのまま追認するだけになる。だからこそ、一部のチームは、コードを書くエージェントとは文脈もプロンプトも目的も切り離した、完全に独立した検証エージェントを用意するようになっている——エージェントに自分の答案を自分で採点させないために。
では、手作業でテストケースを書く時代に戻るべきなのか
「リリースのたびに人間が一手順ずつクリックして確認する」という意味ではない——これはよくある誤解だ。実際に提案されているのは、自動化コードとは独立して表現されたテストケースである。自然言語、Markdown、Gherkinなど、プロダクト担当者もエンジニアもQAも——そしてAIエージェントも——読んでレビューできる形式で書かれたものだ。
良い手動テストケースは、ビジネスシナリオ、前提条件、ユーザーの操作、期待される結果、関連するネガティブケースや境界条件、そしてどの要件・受け入れ基準を検証しているのかを明確に示す。
技術的なテストフレームワークを理解していなくても読める形式であるため、関係者全員——AIも含めて——にとっての共有契約のようなものになる。実装前にレビューでき、ステークホルダーと合意でき、他の成果物と同様にバージョン管理できる。そして何より、Markdownのシナリオを直すほうが、複雑なE2Eテストのデバッグを繰り返すよりもはるかに安価だ。
エージェンティックなワークフローのための、より健全な役割分担
より良いアプローチは、「期待される振る舞いを定義する人」「それを実装する人」「それを検証する人」という三つの役割を明確に分けることだ。一つのエージェントが同じ閉じたループの中でその三つ全部をこなすのではなく。
この体制では、要件と受け入れ基準が「なぜこの機能が必要なのか」に答える。QAまたは専用エージェントが作成する手動テストケースが、その意図を具体的でレビュー可能なシナリオに落とし込む。開発エージェントはその振る舞いを実装し、テストケースに曖昧な点を見つければ指摘はできるが、期待値そのものを黙って書き換えることはできない。別の自動化エージェントが、現在のUIやコードからではなく、承認済みのテストケースからE2Eチェックを生成する。そして、エージェントを含む誰かがテストケースを変更しようとした場合、専用のレビュー層が、その変更が承認済みの要件によって本当に認められているのか、それとも実質的にリグレッションをこっそり正当化しているだけなのかを確認する。
手間が増えるように見えるかもしれないが、目的はシンプルだ。あるエージェントが間違ったものを作り、その間違いに合わせてテストを書き換え、自分で自分に合格点をつける——そういう事態を防ぐことにある。
なぜこれが見た目以上に重要なのか
AIエージェントがコードを素早く生成できるのは事実であり、その速さには確かに魅力がある。しかし、速さは、システムの振る舞いが実際に検証されたことを意味しない。コードから独立した「期待される振る舞い」の記述層がなければ、チームは簡単に「実装→失敗→修正→リグレッション」というループに陥ってしまう。AIを使えば使うほど、プロダクトが本来守るべきものを守る代わりに、テストをコードに合わせる作業に時間が吸い取られていく。
一方、レビュー済みでバージョン管理され、要件と明確に紐づいた手動テストケースの一式は、繰り返されるE2E修繕作業を大きく減らし、気づかないうちにリグレッションを受け入れてしまうリスクを下げ、複数のエージェントが重複したテストを量産する事態を防ぐ。CTOはどの要件が実際に守られているかを一目で把握でき、QAエンジニアは境界条件のカバレッジがどこで欠けているかをすぐに見つけられるようになる。
つまり、エージェンティックな時代において、手動テストケースは自動化からの後退ではない。それは、自動化が勝手にルールを書き換えてしまわないようにするための契約なのだ。
参考ソース：
- Manual Test Cases in the Agentic Era: The Baseline AI Agents Need — testomat.io, Michael Bodnarchuk
- Why AI Coding Agents Need a Dedicated AI Testing Agent — Autonoma
- How I Validate Quality When AI Agents Write My Code — DEV Community
- Why Coding Agents Need Independent Quality Gates to Work at Scale — Codacy