自動化したのに回らない テスト運用の壁 ―AI時代の品質責任と生産性 mabl株式会社 舟木将彦 | AI DevEx Conference 2026 

自己紹介 舟木将彦 mabl株式会社 Sales Engineer | @mfunaki 

開発は「日単位」、テストは「手動」のまま リリースサイクルはAIコーディングエージェントで『日単位』に。 しかし、テストやテストの保守は『手動』のまま。 エージェント開発 DevOps 品質ギャップ 速度 ウォーターフォ アジャイル ール 開発 生成AIが補助する QA モダンフレームワーク（ 手動 Playwrightなど） レガシー自動化 （Selenium時代） 時間 自動化テスト 

これは他人事ではない：mabl開発現場のリアルな数字 ● mablの開発現場： 25名のエンジニアが100以上のリポジトリをま たがって開発 ● インフラ系リポジトリ： 6割のコミットがAIによるサポート ● アプリ系リポジトリ： 10→39% 月230件→370件以上のプルリクが行き交う しかし、この加速の裏で ーテストは同じスピードで回っていただろうか？ AIによるPRサポート比率 （2025/8→2026/2） ※mabl社内の分類基準による 

組織が直面する「2つの壁」 壁①： テストは作れるが 誰もメンテナンスしない 壁②： 自動化したはずなのに 手作業が減らない 画面の変更やリファクタリングで 要素名・属性値が変わり、 識別のためのコンテキストが失われる。 テストの実行と、実行時のログ収集は 自動化された。 テストは静かに壊れ、CIが赤くなっても、 追う人がいない。 しかし、原因分析も、テストの修正も、 コードの修正も、結局人間が引き受けている。 それなら、コーディングエージェント(Claude CodeやGitHub Copilot)にテストも書かせればいい －そう思うのは自然ですが、そこに罠があることを数多く見てきました。 

「つくる」と「検査する」、求められる視点は根本的に違う つくる＝コーディングエージェント 検査する＝テストエージェント ゴールは「動くコードを早く届ける」こと。 ゴールは「ユーザーの一連の操作が 本当に正しく動くか」を疑うこと。 公開されたコードやパターンから学習し、 コードを提案すること自体は、何の問題もない。 しかし、そのコードが実際に動くアプリケーシ ョン固有のコンテキストーログイン後の画面で 何が起きるかーまでは知らない。 CIにおいては「ビルドが通った／テストが緑」 という自動的な合否シグナルがある。 しかし、アプリケーションの動作には、 そうした自動判定の仕組みが存在しない。 だからこそ mabl は、そのアプリ固有のコンテキストを補うために、 過去のテストやテスト結果を参照しながら、テストを作成している。 Gartnerも同じ結論に達している。コーディングエージェントは開発フェーズに特化した設計だが、 テストフェーズに「対応はできるが特化していない」—テスト専用エージェントの例として、mablの名前が挙がっている。 

mablも、最初は同じ発想で失敗した テストエージェントも、コーディングエージェントと同じように 「テストという行動をさせる」ものとして作れるはずー2023年夏、mablもそう考えていました。 結果は失敗でした。 Google PaLMで自律型テストエージェントを構築しましたが、単純なログイン画面すら安定して ナビゲートできず、DOM要素をハルシネーションしてしまうなど、失敗の連続でした。 LLMは、WikipediaやYahoo!のように学習データに含まれる公開されたアプリケーションについては、 それらしいテストをかけます。しかし、ログインが必要なアプリケーションや社内イントラネットの ように、学習データに存在しない未知のアプリケーションを相手にすると、途端に精度が落ちました。 －DOM要素のハルシネーションも、その症状の一つだったのです。 「行動させる」という発想そのものに無理があったのです。 

失敗から生まれた設計図：生成AIの得意と不得意 2023年8月の失敗を受け、同月、mablは 「生成AIはテストのどこに向いているか」を整理した レポートを公開。 当時、AIツールを実際に信頼していた開発者は、 わずか3%未満(Stack Overflow調査) 「AIは信頼できない」が業界の一般的な理解でした。 レポートの結論は「AIは役に立たない」ではなかった。 自由度の高いタスクは得意な一方、 テストの計画・実行のような複雑な制約・推論には 向かないーこの整理が、振り返ってみれば、次の一手 への設計図になっていました。 <3% AIツールを実際に信頼していた開発者 （2023年8月時点） 

「作る」ではなく「判定させる」への転換 生成AIアサーション(現:ビジュアルアサーション)誕生秘話 モデルの得意・不得意を見極める中で、 2023年6月発表の論文「LLM-as-a-Judge」にヒントを得て、 AIに「行動」させるのではなく、 AIに「判定」させる(LLMを評価者として採用する)方向へ転換。 2024年初頭に開発を開始し、2024年夏リリース（同年秋Gemini 1.5でGA）。 mabl社史上最速の成長を遂げた機能となった。 しかし、生成AIアサーションは、テスト作成エージェント全体のごく一部に過ぎなかった。 その後も Gemini 2, 2.5, 3 － モデルが変わるたびに、エージェントの土台そのものを作り直す 日々が続いた。気づけば、テスト作成エージェントは通算5回、全面的に書き直されていた。 

5回の書き直しから生き残った5つの教訓 モデルの 得意な方向に 合わせて 設計する エージェントの 質は 入力の質で 決まる 非決定性を 意図的に 受け入れる 信頼は 勘ではなく データで 測る AIは 土台をそのまま 増幅する 

では、実際にどう解決したのか 生成AIをテストに使う、と聞いて多くの人が まず思い浮かべ、 そしてそこで止まってしまうのが 「Claude Code + Playwrightでテストコードを生成させる」というアプローチです。 これでテストは書けます。しかしテストの一生は、生成だけでは終わりません。 mabl MCP × Claude Code — ここからは実際の画面でご覧いただきます 

テスト作成：mabl Agentによるテスト生成 自然言語でテスト作成に対応。 クリック、ドロップダウン選択、日付選択、条件 分岐、MFAログイン、アクセシビリティチェック、 PDF検証まで、幅広いWeb操作をカバーする。 クラウドでの並列実行（最大10セッション同時）、 あるいはローカルでのヘッドレス実行を選択可能。 クラウドが届かないlocalhostのようなプライベー ト環境でも作成できる。 mabl MCP経由で、Claude CodeやCursor、Kiro のようなAIコーディングエージェントからも テストの生成、実行、分析などが可能。 単にプロンプトだけでテストを作成しているので はなく、これまでに作成したテストや、過去の実 行結果（スクリーンショット、DOMスナップシ ョット、ネットワークログ、パフォーマンスロ グ）を参照しながらテストを作成します。 その際に、共通部分は自動的に切り出され、再利 用されます。 したがって、テストの生成精度と速度は、使えば 使うほど高まっていきます。 

No content

テスト作成：ビジュアルアサーション 従来の検証は、画面上の「文字」「数値」が正 しいかという「点」の確認にとどまっていまし た。 ビジュアルアサーションは、グラフのような 非文字情報も含めて、UIの特定領域（面）の 文脈的な妥当性を検証することができます。 初回テスト時にAIが判定基準を自動生成し、後 から編集・再生成も可能です。 チェックできる内容はこれらにとどまりません。 「技術的には正しく実装されているが、利用者の観 点からは望ましくない」動作——たとえば商品名と 写真の不一致や、法令・コンプライアンス上の表示 チェック——にも踏み込んだテストが可能です。 つまり、これからのQAは、 「アプリのふるまい・ユーザー体験はこうあるべき、 こうあってはならない」を見極める、 PM的な視野で 「品質をデザインする」 →自動テストに落とし込むことが必要となります。 

テスト作成：ビジュアルアサーションの例(非文字情報) https://qiita.com/mfunaki/items/6b21c1673357f8a72a88 

テスト作成：ビジュアルアサーションの例(データ整合性) https://qiita.com/mfunaki/items/6b21c1673357f8a72a88 

テスト実行：自動修復 / ビジュアル検索 / エージェント実行時リカバリ 要素レベル：自動修復 DOM属性の最良マッチに加え、意味的な 類似性をAIが判定します。 確信度が低ければ、ビジュアル検索↓を 適用します。 視覚レベル：ビジュアル検索 DOM属性に頼らず、スクリーンショット の見た目でクリック位置を特定できます。 canvasやPDF、地図のような属性の乏し い要素にも対応が可能です。 エージェント実行時リカバリ－ 想定外のモーダルやページネーション、 残ったフィルターなど、実行時の想定外 に対処して、「テストを最後まで何とか 実行する」ことで、「テストシナリオの 中のチェック項目のどこまでできたか」 ではなく、「チェック項目の何がOK/NG なのか」を早期に確定します。 ただし、テストの意図に照らして「これ は本質的な失敗だ」と判断すれば、無理 に回復しようとはしない。 

テスト実行：自動修復 / ビジュアル検索の例(1) 

テスト実行：自動修復 / ビジュアル検索の例(2) 

テスト実行：エージェント実行時リカバリの例 

テストのメンテナンス：対話型結果分析 壁② テストに失敗した場合、 原因分析・修正は結局人間が引き受けている mablは、テストが成功した時と失敗した時 の両方の「ログ・スクリーンショット・ DOM構造・ネットワークログ」を保持して います。 テスト失敗時、AIはこの正常時と異常時の差 分を比較することで、原因がテスト側・アプ リケーション側・インフラ側のどこにあるか を切り分けて提示します。 DOMの変更がテスト失敗の原因であれば、 どう変更されたことにより問題が生じたのか を特定し、開発側にフィードバックできます。 

No content

視点の転換：テスト運用の壁 → 品質責任と生産性 ここまでは、テストエージェントとしてmablが向き合ってきた壁の話でした。 しかし品質責任の問題は、テストだけでは終わりません。 mabl自身が「コードを書くAI」を大量に活用する開発現場そのものになった今、 その品質責任をどう設計しているか——ここからは、その話をします。 

mablが辿り着いた4層アーキテクチャ 1. リポジトリ横断基盤 2. スキル基盤 LLMは本来、依存関係を一望できるモノリポ的な世界の方 が精度を発揮しやすい。しかし既存の100以上のリポジト リ構成を捨てる必要はない。ルールと依存関係グラフ （850行以上、79リポジトリ）を「横断基盤」として整 備することで、モノリポ化せずとも、複数リポジトリをま たぐ文脈をAIが把握できるようにした。 Claude Codeの「スキル」を個人のローカル環境に閉じ ず、チームで管理・共有する仕組み（MCPサーバー＋36 以上のスキル）を構築。これにより、AI活用の恩恵は「使 い方がうまい一部の個人」の生産性向上にとどまらず、チ ーム全体の生産性向上につながる。 3. 運用とガバナンス 4. 人間による承認 AIコードレビューは、コーディング規約違反や既知のバグ パターンなど「機械的に判定できるチェック」を自動化し、 差し戻しで効率化を担う。一方「承認」は構造的に行わせ ない。連続する自動修正が続けば自動停止する仕組みも備 え、AIが自分にOKを出す事態を防いでいる。 AIによる大量PR生成は、開発現場全体で今や共通の悩み になっている。規約違反や重複コードのチェックはAIに任 せ、「このPRは本当にビジネス要件を満たしているか」 という最終判断だけは、常に人間が行う。 

品質責任の設計図：4フェーズパイプライン 1. 分析 2. 計画 チケットと関連リポジトリ・過去のgit履歴を調査し、技 術サマリと疑問点をJiraに投稿。ここで確信度が低ければ 「claude-blocked」ラベルを付けて人間の回答を待ち、 無理に前進しない。 具体的なファイルパス・APIエンドポイント・テストケー スまで含めて実装計画を立てる。ここまで具体化してから コードを書くことで、実装フェーズの失敗率が約60%減 少した。 3. 実装 4. レビュー コードを書き、ローカルでテストを実行してPRを提出。 ここまでの確信度がどれだけ高くても、実装フェーズだけ は常に「低確信度」として扱われる——つまり自動でマー ジされる可能性は設計上ゼロになっている。 AIコードレビューとauto-fixエージェントがPRを整形し、 規約違反や重複コードを検出する。しかし承認・マージの 権限は与えられていない。最後にPRを見て意思決定する のは、常に人間である。 

QAには安いチェックと高いチェックがある。 規約違反やテスト漏れのような、ファイルを 読むだけで分かる安いチェックは、 AIが正確に検出できる。 しかし「本当に実環境で動くか」を確かめる 高いチェックは、 いつも同じ理由—早く出荷したい—によって、 実行される前になし崩しにされてしまう。 Geoff Cooney fab.mabl.com（mablエンジニアリングログ） 

品質指標はどう変わったか 従来の指標 ● テストケース数：いくつのテストを書いた か、という「量」の指標 ● カバレッジ率：コードのどれだけをテスト が網羅しているか、という「範囲」の指標 mablが実際に使っている指標 ● コンテキストドリフト率：AIがリポジトリ 間の依存関係を見失う頻度（リポジトリ横 断基盤の導入で40%→5%未満に改善） ● 計画フェーズによる実装失敗率の削減： 計画フェーズを挟むことで、実装の手戻り をどれだけ減らせたか ● API誤解の検出率：AIが古い・存在しない APIを使おうとした際、レビューで発見でき た割合 

開発生産性を「アウトカム」で測る 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% 

まとめ：明日から使える3つのTips コードを書くAIとテストするAIは必ず分離する——コーディングエージェントは 自分の宿題を自分で採点できない 実装フェーズだけは常に「低確信度」扱いにする——確信度が高くても人間の承認 なしにマージされるシナリオを作らない 生産性は「作業量」ではなく「コンテキストドリフト率」や「PRスループット」 （PR数はこの半年で2.5倍に増加）など、アウトカムで測る 

ご清聴ありがとうございました mabl株式会社 舟木将彦 | Qiita @mfunaki