エージェント型AIの時代、テスターは減らすのではなく増やす必要がある

エージェント型AIによって、ソフトウェアのリリースのあり方が塗り替えられている。アシスタントがプルリクエストの草案を作成し、エージェントがマイグレーションを開始し、レビュー用ボットは人間がコーヒーを飲み終える前に変更に問題はないと言い切る。業界では、この流れを品質管理に携わる人員を減らす道筋として捉えることが多い。しかし、その見方は逆だ。コードベースのより多くを機械が作成するようになれば、希少なスキルはコード生成ではない。独立した検証だ。

2025年のStack Overflow開発者調査によると、回答者の84%が開発でAIツールを利用中、または利用を予定しており、プロの開発者の51%が毎日利用している。AIへの好意的な見方は60%に低下し、AIの正確性を信頼する開発者（33%）より、積極的に信頼していない開発者（46%）のほうが多かった。66%が挙げた最大の不満は、ほとんど正解だが、完全には正しくない解決策だった。Google Cloudの2025年のDORAの調査では、ソフトウェア開発の専門家におけるAI導入率は90%で、80%超がAIによって生産性が向上したと回答した一方、AIを大いに、または非常に信頼していると回答したのはわずか24%だった。信頼されていないのに有用だという状況こそ、テスターの仕事を縮小するのではなく、拡大させる。

速さは証明にならない

私は、エージェント型テストとAIが作成したコード向けのCIゲートを専門とするソフトウェア品質エンジニアとして働いている。社内では、プルリクエストのレビューツールとテストケース生成ツールをリリースした。どちらも草案を作るためのツールだ。自分の仕事を自分で採点させることはない。このルールが重要なのは、エージェントが確信に満ちた口調で話すからだ。確信があることと、正しいことは違う。

私たちは、そのことを高くつく形で学んだ。AIが構築したプルリクエストレビューツールの試験運用では、ある変更が4分未満でCIを通過した。2日後、後続のダッシュボードにあり得ない温度が表示された。摂氏から華氏への換算倍率が逆転する問題が、テストスイートで一度も実行されなかったコードパスに潜んでいた。パイプラインは成功を示していた。製品は間違っていた。難しい問いを一度も投げかけないままCIが成功を示すのは、見せかけにすぎない。

この事例は、より広く見られる傾向の一部でもある。CodeRabbitのAIと人間のコード生成の現状に関するレポートは、オープンソースのGitHubプルリクエスト470件（AIと人間が共同作成したもの320件、人間のみが作成したもの150件）を分析した。AIが作成した変更では、問題が全体で約1.7倍多く発生し、ロジックと正確性に関する問題は75%多く、セキュリティ上の問題は最大2.74倍に上った。Veracodeの2026年版生成AIコードセキュリティレポートは、複数のセキュリティタスクでモデルをテストし、セキュリティテストの平均合格率が56%だったと報告した。これは前回レポートの55%からほとんど変わっていない。また、AIによるコード生成タスクの約44%で、既知の脆弱性が持ち込まれていた。構文の問題はほぼ解決されている。しかし、安全で正確な動作はそうではない。テスターとは、その2つを混同しない人たちだ。

幻覚による依存関係の生成もテストの課題

コード生成では、存在しない依存パッケージまで作り出される。USENIX Security 2025の研究「パッケージを用意しました！」は、コード生成を行う16種類の大規模言語モデルを対象に、576,000件のサンプルでパッケージの幻覚を評価した。商用モデルがパッケージを幻覚で生成する割合は平均で少なくとも5.2%だった。オープンソースモデルでは平均21.7%に上り、幻覚によって生成された固有の名前は205,474件に達した。こうした架空のパッケージが長期間残ると、スロップ・スクワッティングの格好の標的になる。攻撃者がその架空の名前でパッケージを登録し、開発者やエージェントがインストールするのを待つのだ。

依存関係の出所を確認するチェックは、機能テストと同じ水準で実施すべきだ。エージェントがNuGetやnpmのパッケージをでっち上げた場合、ユニットテストが十分だったかを議論する前に、マージを失敗させなければならない。出所の確認は、任意の衛生管理ではない。AIが作成した変更に対する品質ゲートだ。

エージェントの規模に応じて機能するゲート

AI支援による自動化を使い、組織全体の.NET 8から.NET 10へのアップグレードを約2週間で実施した際、私は品質ゲートを担当した。実際に速く進められた。一方で、エージェントの要約を鵜呑みにしないチェックも必要だった。変更されたコードに対して実施するゲートは、次のとおりだ。

• 変更箇所のロジックに対し、ミューテーションスコアの目標を60%～70%に設定する。これにより、テストスイートは行をカバーするだけでなく、実際の変異を検出して失敗させる必要がある
• 例だけでは動作を十分に規定できない、リスクの高いロジックに対するプロパティベーステスト
• スロップ・スクワッティングや、幻覚によって生成されたパッケージを防ぐための依存関係の出所確認
• エージェントによるコピー＆ペーストの繰り返しを検知する、重複と変更頻度のシグナル
• 「マイグレーション完了」など、エージェントの主張を独立して検証すること。証拠が示されるまでは、主張は仮説にすぎない

ミューテーションスコアは、見栄えのための指標ではない。意図的に不具合を仕込んだときに、テストがそれに気づくかを測るものだ。カバレッジが上がっても、テストスイートが摂氏のコードパスを見逃すことはある。プロパティベースのチェックでは、都合のよい一つの経路だけでなく、さまざまな範囲でシステムのモデルが成り立つことを確かめる。出所確認によって、パッケージの保管庫を守る。変更頻度と重複を調べれば、エージェントが同じアイデアを3通りに書き直す癖を検知できる。これらを組み合わせて、エージェントはテストスイートが正しさを証明するまで間違っていると見なす姿勢をつくる。レビューでは、この基準を保っている。

これらは、APIテスト、認証テスト、スモークテスト、UI自動化の代わりにはならない。FlaUIとPowerShellは、APIでは見つからない問題を今も検知する。NuGet、MSI、MSMを通じたパッケージ化にも、インストールとサイレント実行経路の検証が必要だ。エージェント型ワークフローは作業量を増幅させる。こうした専門領域が不要になるわけではない。

テスターを増やし、仕事の内容を変える

エージェントがテストを書き、人間が不要になるのではないかという懸念がある。エージェントはテストケースの草案を作成できる。しかし、その草案を自ら認定すべきではない。今後、テストにAIを活用する予定のStack Overflowの回答者も、人間による不信感を依然として重要な要素に挙げている。他の人に助けを求める理由として最も多かったのは、AIの回答を信頼できないことだった。その直感こそ、この職業の強みである。

ここでは、従来とは異なる経歴を持つ人を採用し、力を発揮できるよう支援することが重要だ。私は人事オペレーションとデータ関連の仕事を経て品質分野に転身し、2024年5月にUMBCで情報システム学の修士号を取得した。現在は、エージェント型システムのゲートを実用的なものにする仕事に日々取り組んでいる。エージェント型AIは、特定の経歴を持つ人材が現れるまで待ってはくれない。必要なのは、証拠を設計できる人材を増やすことだ。ビルドが成功したというだけで承認する人を増やすことではない。

製品に関する問いは単純だ。検証が考えるよりも速くエージェントをリリースしているなら、生産性が向上したとは言えない。それは、先送りされたインシデントを抱えているということだ。エージェントの主張をすべて疑ってかかり、ミューテーションテストと来歴情報をCIに組み込み、モデルが最も流暢で、最も信頼性に欠ける場面でも独立した判断を保てるテスターに投資しよう。エージェント型AIに必要なのは、より多くのテスターであり、より少ないテスターではない。