「ITニュース」｜AIテスト自動化「80%」の裏側——20年選手が実測した“本当のコスト”

2026年7月16日 17:02

はじめに

2026年7月15日、テスト自動化エンジニアのSuneet Malhotra氏がInfoWorldに寄稿した記事が、AI活用の現場で静かに話題になっています。Malhotra氏はTinder・Amazon（Ring）・Live Nation/Ticketmasterなどで20年のテスト自動化経験を持ち、ICSE 2027（ソフトウェア工学分野の国際会議）のプログラム委員も務める人物です。

この記事の読みどころは2点あります。ひとつは「AIがテストコードの80%を書く」という業界の触れ込みが、実測してみると「タイピング作業の80%」でしかなかったという指摘。もうひとつは、その差分（レビュー・不安定性修正・インフラ対応）が実際にはどれだけの人的コストとして残るのか、という具体的な数字です。

※ 本記事は公開情報に基づく整理であり、著者本人の単一パイプラインでの実測値である点にご留意ください。

この記事での用語

1. 何が起きたのか（結論）

Suneet Malhotra氏が2026年7月15日、InfoWorldに意見記事（Opinion）を寄稿しました。
Figmaのデザインを入力とし、MCP経由でWebDriverIOの実行可能テストコードを出力する6段階のエージェント型パイプラインを自ら構築し、実測データを提示しています。
合成的な新規画面（synthetic net-net screen）1件でのパイプライン全体の実行時間は約16分でした。
参照実装はGitHub（github.com/SuneetMalhotra）にMITライセンスで公開されています。
「AIがコードの80%を書く」という宣伝文句に対し、実際にはコードレビュー（60〜180分）、自動化レビュー・不安定性修正（30〜90分）、チケット設計（30〜60分）などの人的工数が残ると報告しています。

忙しい方向けに一言でいうと、
「AIがテストの80%を書く」は「タイプ量の80%」であって「仕事の80%」ではない——実測すると人手に残る労力は元の2〜3割に達する、という20年選手の反証。

2. なぜこの数字が出てきたのか

Malhotra氏の主張の核心は、「コード生成」と「エンジニアリング作業」を分けて考える必要がある、という点です。AIがテストコードのテキストを書く作業（タイピング）は確かに大幅に自動化できますが、そのコードが実際に信頼できる形で動くようにする作業――レビュー、不安定性の修正、CI環境の整備――は依然として人間が担っています。

同時期には、GitClear（開発生産性を分析する企業）が211百万行の変更コードを分析した調査を公表しており、2026年に5行以上の重複コードブロックが8倍に増加し、リファクタリングの割合が25%から10%未満に低下したという結果が示されています。これは本記事の直接の引用元ではありませんが、AI生成コードの「隠れコスト」への関心が業界内で高まっている同時期の関連動向として位置づけられます。

3. パイプラインで実際に起きた問題

Malhotra氏が挙げるのは、AIモデル自体のバグではなく、インフラ起因の問題です。

モデルバックエンドのタイムアウト
認証情報が予告なく失効する
共有APIエンドポイントの競合（HTTP 409エラー）
環境変数が無言でローテーション（変更）される

これらへの対策として、サーキットブレーカー、純データフォールバック（処理失敗時に安全な代替データへ切り替える仕組み）、シングルオーナーリース（リソースの排他制御）、合成カナリア（本番影響前に異常を検知する仕組み）という「4ガード規律」を運用設計に組み込む必要があると述べています。

4. 短期・中期・長期の整理

時間軸定義:

短期: 0〜3か月
中期: 3か月〜1年
長期: 1年以上

4-1. 短期（0〜3か月）

予想される動き: AI生成テストパイプラインを試験導入するチームが、コードレビューや不安定性修正の工数を過小評価し、当初期待（工数8割削減）と実績（2〜3割の削減）のギャップに直面する可能性が高いと考えられます。
不確実性: 組織やコードベースの成熟度によって「タイピング作業」対「エンジニアリング作業」の比率は大きく異なり、著者の数値がそのまま一般化できるかは未検証です。
効果が出にくい条件: Figmaのデザインが詳細にアノテーションされていない、または受け入れ基準が曖昧なプロジェクトでは、レビュー負荷がさらに増える可能性があります。

4-2. 中期（3か月〜1年）

予想される動き: 「生成量」ではなく「手直し量」を測る80/20リワークルールのような指標が、テスト自動化・QA分野の一部チームで採用される可能性があります。
不確実性: 業界標準の指標として定着するかは、他の実務者による追試やデータ蓄積に依存します。
効果が出にくい条件: 各チームが独自の測定基準を使い続け、横比較できるデータが蓄積されない場合、指標としての定着は進みにくいと考えられます。

4-3. 長期（1年以上）

予想される動き: レガシーコードや規制・安全性が重要な領域ではAI生成テストパイプラインの適用が慎重になり、「Figmaアノテーション済み・受け入れ基準明確・レビュー容量あり」という適用条件が業界のベストプラクティスとして定着する可能性があります。
不確実性: AIモデル自体の信頼性向上（タイムアウトや認証エラーなどインフラ起因の不具合の減少）次第で、長期的なコスト構造は変わり得ます。
効果が出ない条件: モデルベンダー側のインフラ品質が改善しない場合、人的レビュー・監視コストは高止まりし続けると考えられます。

5. 混同しやすい点

6. まとめ

「AIがテストの80%を書く」は、コード生成量の話であり、レビュー・修正・インフラ対応まで含めた実務工数の80%削減を意味しません。
実測ベースでは、人間側に元の労力の20〜30%が残るとされています。
導入判断では「生成量」ではなく「手直し量」を測る指標を自チームに組み込むことが実務上の目安になります。
パイプラインの不具合の多くはインフラ起因であり、サーキットブレーカーなど運用面の備えが重要です。

主な参照

免責

本記事は公開情報に基づく整理であり、投資判断・技術導入の可否を保証するものではありません。記載の数値は著者本人が構築した単一パイプラインでの実測値であり、他社・他チームでの再現性は未検証です。自社での導入検討にあたっては、一次情報源（InfoWorld原文、参照実装）をご確認のうえ、自社環境での検証を行ってください。

【PR】
私も転職エージェントを利用して転職しました。