導入率は高いが指標が重要
Stack Overflow の 2025 年の調査では、回答者の 84% が開発プロセスで AI ツールを使用したか、使用する予定であることがわかりました。プロの開発者のうち、51% が毎日使用していると回答しました。この質問は AI ツール全般を対象としています。その割合がコードを生成することを証明するものではなく、QA チームについて具体的に説明するものでもありません。
流れの反対側を見るために、DeviQA は 2026 年 7 月に 300 人の QA 専門家、SDET、テスト リーダーを対象とした独自の調査を発表しました。 52% が AI を使用した開発を始めてからバグが増加したと感じたと回答し、58% がテスト負荷が増加したと感じたと回答しました。これは調査すべき関連シグナルであり、セクターの代表的な推定値ではありません。これは自己申告の回答と経験に基づいた内部サプライヤーのサンプルです。
DeviQA の調査では、参加者が AI 導入に一時的に関連する変化について尋ねています。 AI ありとなしの同等のリポジトリを比較したり、変更のサイズ、エクスペリエンス、配信速度、レビュー ポリシーを制御したりすることはありません。また、より多くの欠陥が検出または報告されるようになったことも影響する可能性があります。したがって、AI 自体が一般的なバグの増加を引き起こすと結論付けるのは適切ではありません。
DORA 2025 は、AI を既存の作業システムの増幅器として読み取ることを提案しています。迅速なフィードバック、社内プラットフォーム、明確な優先順位が役立ちます。弱いプロセスやレビューが難しい変更も増幅されます。研究は関連性を報告していますが、普遍的な因果律ではありません。実際的なメッセージは、変化を単一ツールのせいにするのではなく、フロー全体を測定することです。
プロセスを変更する前に何を測定するか
数回の反復にわたって行われた変更の数とサイズを記録します。公開前と公開後に発生した欠陥の数。その深刻さ。ケースが再オープンされた回数。 QAが受信して応答するまでにかかる時間。そしてどれだけの作業が繰り返されるか。 AI を利用して行われた変更を個別に行うのは、チームが各個人を監視することなく一貫して変更を識別できる場合に限られます。
期間を慎重に比較します。同じ定義を使用し、製品や機器の変更に注意し、テストで検出された内容と誤ったアラートが判明したことの両方を確認します。さらに多くの変更がリリースされると、各変更の数は減っても、欠陥の総数は増加する可能性があります。欠陥と変更の数およびサイズを比較すると、何が起こったのかを理解するのに役立ちます。
以前、チームが週に 10 件の変更をリリースし、4 つの欠陥が見つかったと想像してください。アシスタントを追加した後、20 件の変更を公開し、6 件の変更を見つけました。合計は増加しましたが、変更あたりの欠陥の割合は 0.4 から 0.3 に減少しました。分母がなければ、「バグが増えている」という見出しは、納品量とユニットあたりの品質を混同したものになります。テストの追加、ログの改善、またはレビューの強化により、検出が増加する可能性もあります。その場合、より多くの障害が発生すると、製品が悪くなったということではなく、システムの動作が良くなっていることが判明する可能性があります。
公開前に欠陥が見つかった。製造段階に達した欠陥。重大度と影響。調査と修正にかかる費用。テスト中により多くの軽微な問題が見つかっても、より多くのユーザー インシデントが発生することにはなりません。逆に、変更の数が増加した場合、または失敗が支払い、権限、またはデータに集中した場合、レートが安定していると、より大きなリスクが隠蔽される可能性があります。比較する前に何を伝えるかを決めてください。
生成されたコードをレビューすると、テストの実行以外に何が追加されますか
すべてのテストに合格したからといって、それ自体は、変更の保守が容易であること、プロジェクトのルールを尊重していること、または十分なテストが行われていることを証明するものではありません。 2026 年の調査で、METR は 3 つのプロジェクトの 4 人の保守担当者に、エージェントによって準備され自動評価によって承認された 296 件の変更をレビューするよう依頼しました。平均すると、責任者は評価者よりも少ない変更を受け入れ、その差は 24 パーセント ポイントでした。サンプルは限られており、エージェントはコメントを受け取った後に提案を修正できませんでした。この結果では、「テストに合格した」ことと「チームが変更を統合する意欲がある」ということは同じ意味ではないという違いが明確になります。
したがって、関数が期待どおりの動作をするかどうかを確認することに加えて、変更が他の関数に影響を与えるかどうか、エラーをどのように処理するか、セキュリティを考慮しているかどうか、新しいテストで本当に問題が検出されるかどうかを確認してください。生成されたテストでは、コードで発生したのと同じエラーが繰り返される可能性があります。各テストを要件に関連付けるように要求し、保護する予定の機能が削除されたときにテストが失敗するかどうかを確認します。
4 ～ 6 週間、安定した定義でベースラインを記録し、サイズ、リスク、コンポーネントごとに比較可能な変化を選択します。チームが AI を使用している場合は、個人レベルではなく、職務レベルで自発的に変更にラベルを付けます。可能な場合はグループまたは期間を比較し、同時の変更 (新しいカバレッジ、リファクタリング、チームの入れ替わり) を記録し、変更、変更された行、または露出によって正規化します。単一のパーセンテージを目標として使用しないでください。欠陥を隠したり、適用範囲を縮小したりする可能性があります。
便利なダッシュボードには、発生した欠陥の数、その深刻さ、検出された段階が表示されます。どれだけの数が本番環境に達するか、再開されるか。チームが応答を受け取るまでにかかる時間。一人の人が確認した自動アラートの数。問題の原因を理解するために例を保管してください。チームの作業が速くなったにもかかわらず、本番環境でより重大な欠陥が発生したり、手戻りが増えたりする場合、プロセスは改善されていません。公開前により多くの情報をキャッチし、運用環境に反映されることが少なくなれば、問題をより適切に発見できるようになるかもしれません。
QAチームの作業負荷増加に関する最近の調査
2026 年 9 月に公開され、4,000 人の QA 専門家が回答した DeviQA の別の調査は、フローのもう一方の端を説明するのに役立ちます。 65% は、機能がより早くテストに到達すると回答しました。 64% は、より多くの機能が同時に到着すると回答しました。 55% がより長い QA テールを観察しました。そして52%は、より多くのテスト-修正-再テストサイクルを報告しました。これらの数字は、300 人を対象とした前回の調査と混同すべきではありません。これらは異なる手段、サンプル、質問です。また、変更ごとの欠陥を測定したり、AI が原因であることを証明したりすることもありません。これらは、チームがチェックできる具体的な緊張を示しています。デプロイを高速化しても、レビュー、回帰、調整が排除されるわけではなく、QA が受ける作業が集中する可能性があります。
実際的な結果は、ブラインド テストをさらに割り当てる必要がなくなることです。環境の待機、不完全な要件、遅れたレビュー、準備が難しいデータ、断続的な障害、または多すぎる未確認のアラートなど、キューがどこに形成されるかを尋ねる価値があります。原因ごとに異なる対応が必要です。チームが配達物がいつ到着するか、何が変更されたのかを知らない場合、2 番目の AI ツールがノイズを追加する可能性があります。違い、リスク、予想される結果がわかっていれば、より適切に優先順位を付けることができます。有効なテスト時間とは別に待機時間を測定します。これが、キャパシティの問題とフローの問題を区別する方法です。
絶対数は、見つかった欠陥の数を示します。それぞれの変化が悪くなったかどうかを示すだけではありません。チームが 10 件の変更をレビューして 4 つの欠陥を発見し、次に 20 件をレビューして 6 件の欠陥を発見したとします。総額は増加したが、為替レートは下落した。新しい変更がより大規模であったり、異なるコンポーネントに影響を与えたり、より多くの範囲で行われる場合には、その割合さえも誤解を招く可能性があります。決定に応じてさまざまな分母を使用します。トリアージ負荷、サイズ、リスクの変更を改訂してエクスポージャーを比較し、実行して安定性を確保し、ユーザーまたはトランザクションを影響を推定します。コード行を品質の普遍的な尺度にしないでください。コード行は機能上のリスクの代替ではなく、コンテキストとして機能します。
また、重大度、検出のタイミング、コストも分離されます。リリース前にブロッキング欠陥が検出された場合は、テストが機能していることを示している可能性があります。実稼働環境での軽微な問題は、両方とも「バグ」とみなされますが、アクセス許可の失敗ほど深刻ではない可能性があります。問題が要件、実装、統合、データ、環境のいずれにあったのかを記録します。この分類はプロセスを修正するのに役立ち、作成者やツールを非難するものではありません。代表的な例を保持し、期間間の変化を確認します。ケースの説明のない指標は、チームに間違った数値の最適化を強いる可能性があります。
ツールを破棄する基準に基づいてツールを評価する方法
AI をサイクルに追加する前に、否定的な回答を許可する質問を定義します。たとえば、「ストーリーベースのテストは、レビュー時間を増やさずに漏れを減らすことができますか?」制限されたフローを選択し、ベースラインを設定し、スキップ、重複、有効なアラート、および再作業としてカウントされる内容に同意します。同様のリスクの複数の反復と変更を比較します。可能であれば、タスクまたはチームを交代します。そうでない場合は、違いを説明できる可能性のある対象範囲、担当者、リリース、およびツールの変更に注目してください。同時に他の変更があった場合は、前後の比較に因果関係があると考えないでください。
管理されたテストには停止ルールも必要です。ツールに十分なコンテキストがない場合、実際のデータを許可なく使用する場合、分離されていない環境を変更する場合、または誰も再現できない結果を生成する場合は、ツールを停止して実行を保留する必要があります。人間によるレビューは、モデルが生成するすべてを受け入れるのではなく、関連するリスクに焦点を当てます。最後に、サンプル制限、誤検知、回避された欠陥、レビュー時間コストとともに結果が表示されます。データが結論を裏付けていない場合、それは有効な結論です。次のステップは、成功を宣言するのではなく、測定を改善することです。
自動アラートは、まだ分類されていない観測です。これは、新しい欠陥、既知の回帰、影響を及ぼさない視覚的な違い、環境の問題、または予期した動作を示さなくなったテストを示している可能性があります。ダッシュボードがすべてを「バグ」として追加すると、そのほとんどが重複またはノイズであっても、ツールはさらに多くの問題を検出するように見えます。受信済み、レビュー済み、再現可能、確認済み、重複、および破棄された検出結果の個別のステータスを維持します。破棄の理由も記録されます。このようにして、チームは有効なシグナルを平均以下に隠すことなく、トリアージの精度とコストを測定できます。
分析では時間にも注目する必要があります。数分で検出される障害のコストは、毎晩のスイートの最後に表示されるレポートと同じではありません。リリース後まで誰も目にしない正しいアラートでも、予防は向上しません。システムが報告するまでにかかった時間、いつ誰かがレビューしたか、いつ閉じられたかに注目してください。アラートの生の数が増加しても、確認されたパーセンテージが低下し、レビュー時間が増加した場合、次の実験では、さらに多くのケースが生成されるのではなく、選択とコンテキストが改善されるはずです。関連する欠陥の早期検出が増加し、その後の手戻りが減少すれば、有用性のシグナルがより強くなります。