自動化したのに回らない テスト運用の壁 ―AI時代の品質責任と生産性

AI DevEx Conference 2026にて、私(mabl 舟木将彦)が30分お話しさせていただいた内容です。
AIによるコード生成が当たり前になった今、開発速度は劇的に上がっています。しかしその裏で、「テストが追いつかない」「誰がどこまで品質に責任を持つのか」という問いに直面するエンジニアリングマネージャーが増えています。
本セッションでは、テスト自動化の導入・運用を通じて実際に直面した組織的な壁—「テストは作れるが誰もメンテナンスしない」「自動化したはずなのに手作業が減らない」—とその乗り越え方をご紹介します。
品質に関する指標の変化、そして開発生産性を測るための考え方まで踏み込みます。

Transcript

1. 自動化したのに回らない テスト運用の壁 ―AI時代の品質責任と生産性 mabl株式会社 舟木将彦 | AI DevEx Conference 2026
2. 自己紹介 舟木将彦 mabl株式会社 Sales Engineer
3. 開発は「日単位」、テストは「手動」のまま リリースサイクルはAIコーディングエージェントで『Daily』に。 しかし、テストやテストの保守は『手動』のまま。 エージェント開発 DevOps 品質ギャップ 速度 ウォーターフォ ール アジャイル 開発 QA 手動 レガシー自動化 （Selenium時代） モダンフレームワーク（ Playwrightなど） 時間 生成AIが補助する 自動化テスト
4. これは他人事ではない：mabl開発現場のリアルな数字 • mablの開発現場： 25名のエンジニアが100以上のリポジトリをま たがって開発 • インフラ系リポジトリ： 6割のコミットがAIによるサポート • アプリ系リポジトリ： 10→39% 月230件→370件以上のプルリクが行き交う しかし、この加速の裏で ーテストは同じスピードで回っていただろうか？ AIによるPRサポート比率 （2025/8→2026/2） ※mabl社内の分類基準による
5. 組織が直面する「2つの壁」 壁①： テストは作れるが 誰もメンテナンスしない 壁②： 自動化したはずなのに 手作業が減らない 画面の変更やリファクタリングで 要素名・属性値が変わり、 識別のためのコンテキストが失われる。 テストの実行と、実行時のログ収集は 自動化された。 テストは静かに壊れ、CIが赤くなっても、 追う人がいない。 しかし、原因分析も、テストの修正も、 コードの修正も、結局人間が引き受けている。 それなら、コーディングエージェント(Claude CodeやGitHub Copilot)にテストも書かせればいい －そう思うのは自然ですが、そこに罠があることを数多く見てきました。
6. 「つくる」と「検査する」、求められる視点は根本的に違う つくる＝コーディングエージェント 検査する＝テストエージェント ゴールは「動くコードを早く届ける」こと。 ゴールは「ユーザーの一連の操作が 本当に正しく動くか」を疑うこと。 公開されたコードやパターンから学習し、 コードを提案すること自体は、何の問題もない。 しかし、そのコードが実際に動くアプリケーシ ョン固有のコンテキストーログイン後の画面で 何が起きるかーまでは知らない。 CIにおいては「ビルドが通った／テストが緑」 という自動的な合否シグナルがある。 しかし、アプリケーションの動作には、 そうした自動判定の仕組みが存在しない。 だからこそ mabl は、そのアプリ固有のコンテキストを補うために、 過去のテストやテスト結果を参照しながら、テストを作成している。
7. mablも、最初は同じ発想で失敗した テストエージェントも、コーディングエージェントと同じように 「テストという行動をさせる」ものとして作れるはずー2023年夏、mablもそう考えていました。 結果は失敗でした。 Google PaLMで自律型テストエージェントを構築しましたが、単純なログイン画面すら安定して ナビゲートできず、DOM要素をハルシネーションしてしまうなど、失敗の連続でした。 LLMは、WikipediaやYahoo!のように学習データに含まれる公開されたアプリケーションについては、 それらしいテストをかけます。しかし、ログインが必要なアプリケーションや社内イントラネットの ように、学習データに存在しない未知のアプリケーションを相手にすると、途端に精度が落ちました。 －DOM要素のハルシネーションも、その症状の一つだったのです。 「行動させる」という発想そのものに無理があったのです。
8. 失敗から生まれた設計図：生成AIの得意と不得意 2023年8月の失敗を受け、同月、mablは 「生成AIはテストのどこに向いているか」を整理した レポートを公開。 当時、AIツールを実際に信頼していた開発者は、 わずか3%未満(Stack Overflow調査) 「AIは信頼できない」が業界の一般的な理解でした。 レポートの結論は「AIは役に立たない」ではなかった。 自由度の高いタスクは得意な一方、 テストの計画・実行のような複雑な制約・推論には 向かないーこの整理が、振り返ってみれば、次の一手への 設計図になっていました。 <3% AIツールを実際に信頼していた開発者 （2023年8月時点）
9. 「作る」ではなく「判定させる」への転換 生成AIアサーション(現:ビジュアルアサーション)誕生秘話 モデルの得意・不得意を見極める中で、 2023年6月発表の論文「LLM-as-a-Judge」にヒントを得て、 AIに「行動」させるのではなく、 AIに「判定」させる方向へ転換。 2024年初頭に開発を開始し、2024年夏リリース（同年秋Gemini 1.5でGA）。mabl社史上最速の 成長を遂げた機能となった。 しかし、生成AIアサーションは、テスト作成エージェント全体のごく一部に過ぎなかった。 その後も Gemini 2, 2.5, 3 － モデルが変わるたびに、エージェントの土台そのものを作り直す 日々が続いた。気づけば、テスト作成エージェントは通算5回、全面的に書き直されていた。
10. 5回の書き直しから生き残った5つの教訓 モデルの 得意な方向に 合わせて 設計する エージェントの 質は 入力の質で 決まる 非決定性を 意図的に 受け入れる 信頼は 勘ではなく データで 測る AIは 土台をそのまま 増幅する
11. あるエンジニアが週末にUIをリファクタリングしていた。 PRがまだ開いている段階、 つまりマージすらしていない時点で、mabl MCPが 「ログインに関わる全テストが壊れる」ことを警告。 原因分析まで自動で行い、修正案まで提示してくれた。 これまでならデプロイして初めて気づいていた問題を、 コードレビュー中に気づくことができた。 Dan Belcher fab.mabl.com（mablエンジニアリングログ）
12. では、実際にどう解決したのか mabl MCP × Claude Code — ここからは実際の画面でご覧いただきます
13. 見た目が変わらない限り、テストは壊れない 壁① 画面の変更やリファクタリングで 識別情報が失われ、テストが静かに壊れる 根本原因は、 多くのテストツールがDOM属性・要素名で ボタンやフィールドを識別しているため。 mablなら、DOMの属性値だけではなく、 画面上の見た目 （位置・形・周辺のテキスト）を手がかりに 要素を認識できます。 裏側のclass名やIDがリファクタリングで変わ っても、ユーザーの目に映る見た目が変わら ない限り、テストは影響を受けません。
14. 「予期しないこと」が起きても、テストは止まらない 従来のテストは、あらかじめ定義した テストステップの通りにしか進めません。 1つのテストに20のチェックポイントがある 場合、3番目で想定外の結果に当たると、 そこで停止し、残りの17チェックは 永久に実行されず、「3番目がうまくいって いたらどうなっていたのか」を知る方法は ありません。テストを修正して、再実行し ても、4番目以降で想定外の結果だと… mablは、 - 探していた情報がなければ次ページを探す - ダイアログがブロックしていれば閉じる - 検索フィルターが残っていればクリアする といった対応を、 テストステップとして事前定義しなくても QAエンジニアが問題を回避するように、 実行時に自動で適用することができます。 テストの完走率そのものが底上げされ、 「実行できたかどうか」に品質判断が左右さ れにくくなります。
15. AIに「判定」をさせる、ビジュアルアサーション AIに「判定させる」という設計思想は、 ビジュアルアサーション (生成AIアサーション)として実装されて います。 ビジュアルアサーションでは、 画面のスクリーンショットや状態を 見て「意図した通りの結果になってい るか」をAIが判定します。 厳密なDOM属性や座標、テキストの完 全一致ではなく、人間がレビューする のと同じように、視覚的・意味的に正 しいかどうかを判断します。 これにより、細かいレイアウト変動で は失敗と判定せず、本当に意味のある 差分だけを検出します。
16. 「なぜ壊れたか」の分析も、AIに任せられる 壁② テストに失敗した場合、 原因分析・修正は結局人間が引き受けている mablは、テストが成功した時と失敗した時 の両方の「ログ・スクリーンショット・ DOM構造・ネットワークログ」を保持して います。 テスト失敗時、AIはこの正常時と異常時の差 分を比較することで、原因がテスト側・アプ リケーション側・インフラ側のどこにあるか を切り分けて提示します。 DOMの変更がテスト失敗の原因であれば、 どう変更されたことにより問題が生じたのか を特定し、開発側にフィードバックできます。
17. デモ：mabl × Claude Code / MCP ここまで紹介した4つの機能が、実際にどう組み合わさって動くかをご覧いただきます。 1. Claude CodeにmablのMCPサーバーを接続（.mcp.jsonに1行URL） 2. UIのコード変更をコミットし、PRを作成 3. PRがまだ開いている段階で、mabl MCPが影響範囲を自動分析 4. 原因の特定と修正案の提示までを、その場で確認
18. 視点の転換：テスト運用の壁 → 品質責任と生産性 ここまでは、テストエージェントとしてmablが向き合ってきた壁の話でした。 しかし品質責任の問題は、テストだけでは終わりません。 mabl自身が「コードを書くAI」を大量に活用する開発現場そのものになった今、 その品質責任をどう設計しているか——ここからは、その話をします。
19. mablが辿り着いた4層アーキテクチャ 1. リポジトリ横断基盤 2. スキル基盤 LLMは本来、依存関係を一望できるモノリポ的な世界の方 が精度を発揮しやすい。しかし既存の100以上のリポジト リ構成を捨てる必要はない。ルールと依存関係グラフ （850行以上、79リポジトリ）を「横断基盤」として整 備することで、モノリポ化せずとも、複数リポジトリをま たぐ文脈をAIが把握できるようにした。 Claude Codeの「スキル」を個人のローカル環境に閉じ ず、チームで管理・共有する仕組み（MCPサーバー＋36 以上のスキル）を構築。これにより、AI活用の恩恵は「使 い方がうまい一部の個人」の生産性向上にとどまらず、チ ーム全体の生産性向上につながる。 3. 運用とガバナンス 4. 人間による承認 AIコードレビューは、コーディング規約違反や既知のバグ パターンなど「機械的に判定できるチェック」を自動化し、 差し戻しで効率化を担う。一方「承認」は構造的に行わせ ない。連続する自動修正が続けば自動停止する仕組みも備 え、AIが自分にOKを出す事態を防いでいる。 AIによる大量PR生成は、開発現場全体で今や共通の悩み になっている。規約違反や重複コードのチェックはAIに任 せ、「このPRは本当にビジネス要件を満たしているか」 という最終判断だけは、常に人間が行う。
20. 品質責任の設計図：4フェーズパイプライン 1. 分析 2. 計画 チケットと関連リポジトリ・過去のgit履歴を調査し、技 術サマリと疑問点をJiraに投稿。ここで確信度が低ければ 「claude-blocked」ラベルを付けて人間の回答を待ち、 無理に前進しない。 具体的なファイルパス・APIエンドポイント・テストケー スまで含めて実装計画を立てる。ここまで具体化してから コードを書くことで、実装フェーズの失敗率が約60%減 少した。 3. 実装 4. レビュー コードを書き、ローカルでテストを実行してPRを提出。 ここまでの確信度がどれだけ高くても、実装フェーズだけ は常に「低確信度」として扱われる——つまり自動でマー ジされる可能性は設計上ゼロになっている。 AIコードレビューとauto-fixエージェントがPRを整形し、 規約違反や重複コードを検出する。しかし承認・マージの 権限は与えられていない。最後にPRを見て意思決定する のは、常に人間である。
21. QAには安いチェックと高いチェックがある。 規約違反やテスト漏れのような、ファイルを 読むだけで分かる安いチェックは、 AIが正確に検出できる。 しかし「本当に実環境で動くか」を確かめる 高いチェックは、 いつも同じ理由—早く出荷したい—によって、 実行される前になし崩しにされてしまう。 Geoff Cooney fab.mabl.com（mablエンジニアリングログ）
22. 品質指標はどう変わったか 従来の指標 • テストケース数：いくつのテストを書いた か、という「量」の指標 • カバレッジ率：コードのどれだけをテスト が網羅しているか、という「範囲」の指標 mablが実際に使っている指標 • コンテキストドリフト率：AIがリポジトリ 間の依存関係を見失う頻度（リポジトリ横 断基盤の導入で40%→5%未満に改善） • 計画フェーズによる実装失敗率の削減： 計画フェーズを挟むことで、実装の手戻り をどれだけ減らせたか • API誤解の検出率：AIが古い・存在しない APIを使おうとした際、レビューで発見でき た割合
23. 開発生産性を「アウトカム」で測る PR 732件（+291%） PR 291件 PR 約700件 PR 370件以上 PR 230件 2025 8月 10月 2026/1 2月 3月 39%（インフラ系60%） 17% AI支援コミット 10% 2026 転換点 直近90日 PR数 2.5倍 70%
24. まとめ：明日から使える3つのTips コードを書くAIとテストするAIは必ず分離する——コーディングエージェントは 自分の宿題を自分で採点できない 実装フェーズだけは常に「低確信度」扱いにする——確信度が高くても人間の承認 なしにマージされるシナリオを作らない 生産性は「作業量」ではなく「コンテキストドリフト率」や「PRスループット」 （PR数はこの半年で2.5倍に増加）など、アウトカムで測る
25. ご清聴ありがとうございました mabl株式会社 舟木将彦 | Qiita @mfunaki