「つくるAI」だけではバグは見つからない ～テストに必要な「見つけるAI」を分離させる戦略～

Developers Summit KANSAI 2026(2026/08/21)にてお話しした際のスライドです。

AI駆動開発で開発が爆速化する中、テスト保守が最大のボトルネックです。テストをつくるAIにコード修正まで任せると、テストを通すことが目的化し、アプリの本質的な課題が見過ごされがちです。品質を高めるには、テストをつくるAIとは独立して、アプリの課題を見つけるAIが必要です。本セッションではmablのAIエージェントとMCPを用いて、仕様からのテスト作成、想定外の動作に対するリカバリ処理、失敗テストの原因分析のデモを紹介し、明日から着手できる「課題を見つけるAI」導入の第一歩を持ち帰っていただきます。

Transcript

1. 「つくるAI」だけではバグは見つからない 〜テストに必要な「見つけるAI」を分離させる戦略〜 Developers Summit 2026 KANSAI mabl 株式会社 舟木将彦 (@mfunaki)
2. C OMP AN Y OVE RVI EW mabl（めいぶる）とは 2017年ボストン創業。2021年8月には日本法人を設立。 01 02 グローバル展開 約500社が導入 グローバル社員数 約100名 Fortune Global 35社を含む 少数精鋭＋AI活用で世界展開 約500社が採用(日本では80社が採用) 03 04 AI Breakthrough Award 7,700万ドルを調達 Best AI-based Solution for Engineering 約120億円 2020〜2024 Vista Equity Partners, Presidio より 5年連続受賞 GV, CRV, Amplify, 2
3. T OD AY'S RE ALIT Y 開発は加速する一方、QAが追いつけていない 開発現場 QA現場 手動テスト GitHub Copilot （Excel等のテスト仕様書に基づく目視確認・手作業） Claude Code OSSテストツールによる自動化 Cursor… （Selenium, Playwright, Cypressなど） レコーディングベースのノーコード自動化 （Selenium IDEなどの従来型キャプチャ＆リプレイツール） AIコーディングツール(LLM) の導入により、 人がコーディングするスピードに合わせた コーディング速度は飛躍的に向上している 手法のまま、ボトルネック化している コーディング速度の上昇に、既存のQA手法が追いつかずボトルネックになっている 3
4. 開発を加速させたAIに、 そのままテストも任せれば解決するのでしょうか？ — 答えはノーです。 それは静かな『報酬ハッキング』を生み出します。 4
5. T HE PR OB L EM AI生成テストに潜む「4つの限界」 01 02 検証の浅さ 壊れやすいセレクター • 非公開画面などLLMが学習していないUIでは、 • 要素の確認が、エレメント名や属性、XPathといった ソースコード表示の確認に頼りがち。 • 結果として、見た目だけをチェックして 「合格する」浅いテストに陥る。 DOM構造に大きく依存する。 • UI変更やリファクタリングのたびに壊れ、 都度メンテナンスが必要になる。 03 04 類似処理を毎回独自に実装 並列実行への未対応 • ログイン等、複数のテスト間で共通する手順を • テストごとのデータの独立性が担保されず、テスト同士が 毎回独自に実装してしまう。 • 共通画面に変更が生じると、作成されたテストの数だけ 修正作業が発生する。 干渉してしまう。 • CI上で自動実行はできても、高速化のための並列実行が 実現できない。 ※ r/Playwright（2026）：AI生成テストで本番に耐えられるのは30〜40%のみ 5
6. RO O T CAUS E AIコーディングツールの「4つの限界」の原因 文脈の不足 メンテナンスの困難さ • AIはプロンプトと画面情報だけでテストを作ろうとし、 • テスト「作成」にAI(LLM)を使っても、 本来必要な情報が欠けている。 • 「何をするためのアプリか」「どんなユーザー体験を 担保するか」という深い文脈が必要。 テスト「実行」時にはAIが介在していない。 • UI要素の変更(機能追加、リファクタリング)や想定外の ポップアップに対応できず、テストは簡単に壊れ失敗。 ゴールの不一致 • AIコーディングツールの目的は「指示された内容を満たす動くコードのクイックな生成」。 テスト作成時に「あなたはシニアQAエンジニアです」と指示しても本質が変わるわけではない。 • 自分で宿題をして自分で答え合わせをするようなもので、「自分が書いたコードなら大丈夫だろう」という前提から 間違いを見過ごす。 6
7. WH AT GAR TN E R S AYS Gartner が示す、「つくるAI」と「見つけるAI」の分離 「コーディングAIは最初のパスに過ぎない」— 専用テストエージェントを別途設けよ Gartner「Don't Use AI Coding Agents for Every Software Engineering Task」（G00847655） 専用エージェントの分離 模範からの自動学習 コードを生成するAIと、それを独立して検証するAIは 人が定義した模範テストからAIに学習させる 分離すべき。 「テスト自動生成」にこそ価値がある。mablは 自作自演からの脱却が品質保証の前提となる このアプローチに適したツールとして挙げられている。 7
8. O UR OW N FAIL U R E mablも、最初は同じ発想で失敗した 2023年夏、mablもテストエージェントを『行動させる』ものとして作れると考えていました Google PaLMで自律型テストエージェントを構築しましたが、 単純なログイン画面すら安定してナビゲートできず、 <3% DOM要素をハルシネーションしてしまうなど、失敗の連続でした。 LLMは、Wikipediaのように学習データに含まれる公開アプリケーションは それらしく扱えても、ログインが必要な未知のアプリケーションでは AIツールを実際に信頼していた 精度が急落しました。 開発者 （2023年8月時点） 「行動させる」という発想そのものに、無理があった 8
9. T HE TU RN I N G P O I NT 失敗から生まれた設計図：生成AIの得意と不得意 2023年8月、mablは「生成AIはテストのどこに向いているか」を整理したレポートを公開 得意 不得意 自由度の高いタスク（ブレインストーミング、 テストの計画・実行のような、複雑な制約・推論を モックデータ生成など高ボリュームな作業） 要するタスク 「AIは役に立たない」ではなく——この整理が、次の一手への設計図になっていました 9
10. T HE PI V OT 「事前に作る」ではなく「実行時に判定させる」への転換 LLM-as-a-Judgeの応用 2023年6月の論文「LLM-as-a-Judge」にヒントを得て、AIに事前に『行動（コーディング）』させるのではなく、 実行時に『判定』させる方向へ転換しました。 パラダイムシフト 「正しい自動テストスクリプトを事前に生成する」アプローチから脱却。AIをテスト実行エージェントとして組み込み、 実行時に動的に画面を判断・判定させながらテストを進めるアーキテクチャへ進化させました。 進化と試行錯誤 2024年初頭から開発を開始し、ビジュアルアサーション機能は急成長。しかしモデル（Gemini 2, 2.5, 3…）の進化に伴い、 通算5回の全面書き直しを経て、現在の強固な実行エージェント基盤に辿り着きました。 10
11. では、実際にご覧いただきます mabl MCP × Claude Code によるテスト作成・実行・分析の実演 11
12. LI VE D EMO デモ：mabl テスト作成、実行、分析エージェント 作成から実行、分析まで、3つのステップでご覧いただきます 1 テスト作成 VSCode + Claude Code + mabl MCP 自然言語の仕様からプロンプトベースで堅牢なテスト手順を高速構築。 2 テスト実行 視覚的探索 & ビジュアルアサーション DOM要素の特定だけでなく、画面全体の表示状態を視覚的にテスト。 3 テスト分析 失敗原因＋修正案の自動提示 正常ログと異常ログを多角的に比較し、エラーの根本原因と解消プロンプトを即座に特定。 12
13. H OW IT WO RK S テスト作成：VSCode + Claude Code + mabl MCP 仕様から高レベルなテスト意図を生成し、多角的なコンテキストで実行手順に落とし込む アプリ・機能仕様からの生成 多角的なコンテキストの参照 アプリケーションの要求仕様や機能仕様をもとに、 mabl MCPは「単なる文字列」だけでなく、 LLM（Claude Code等）が人間にとっても 以下を参照しながらブラウザ上での正確な 理解しやすい高レベルなテスト手順・意図を 自動実行手順を組み立てます。 自律的に生成します。 • テスト手順（プロンプト） • 既存の成功テストパターン • テストログ （スクリーンショット、DOMスナップショット、 ネットワークログ、パフォーマンスログ） 13
14. GO VE RN AN C E AT SC AL E テスト実行１：要素を視覚的に探索 視覚的特徴と画面の文脈から要素を特定し、UI変更に強いテスト実行を実現 1 2 XPath/DOM依存からの脱却 自己修復メカニズム 従来の自動テストのように 実行時に要素が見つからない場合、 脆いDOM構造やXPathだけに頼るのではなく、 mablの実行エージェントが 要素を一意に特定するための 「過去の視覚的スコア」と「現在の画面表示」を 「プロンプト（視覚的特徴＋文脈）」を自動生成 比較し、 します。 意図したターゲット要素を自動で再特定して ボタンの位置、ラベルテキスト、周辺のUI文脈を総合 実行を継続します。 的に判断するため、軽微なUI変更やリファクタリング でもテストが途中でクラッシュしません。 14
15. GO VE RN AN C E AT SC AL E テスト実行２：表示内容を視覚的にテスト 「面」で捉える次世代のE2Eテスト戦略（ビジュアルアサーション） 1 2 「点（DOM）」から「面（視覚）」へ 自然言語プロンプトによる柔軟な評価 単一のDOMタグテキストを取得・判定するだけでは、 「合計金額が税込表示で正しく計算されているか」 レイアウトの崩れや意図しない重複、視覚的矛盾を 「警告文が適切な色とレイアウトで表示されている 見過ごしてしまいます。 か」といった マルチモーダルLLMを活用し、人間が画面全体を 目視確認するのと同じ「面」の視点での検証を 複雑なドメイン条件も、自然言語のプロンプト1行で 高精度にAI判定させることが可能です。 実現します。 15
16. GO VE RN AN C E AT SC AL E テスト分析：テストの失敗原因＋修正案を提示 失敗原因の切り分けから修正案の提示まで、AIが一気通貫で支援 1 2 失敗箇所の即座な切り分け 自然言語による修正案 テストが失敗した際、正常時ログと失敗時ログ 単にエラーを報告するだけでなく、アプリのUI変更に （スクリーンショット、DOM、ネットワークエラー、 追随するための「テスト手順修正案」をAIがその場で パフォーマンス）を高度に比較分析します。 提示します。 原因が 開発者は1クリックまたはプロンプト指示のみで 「アプリのバグ」「テストの不備」「環境障害」の テスト手順を最新化できます。 どこにあるかを一瞬で特定します。 16
17. T AKE AWAYS まとめ つくるAIと見つけるAIを分離する テストを「つくる」のはコーディングAI。「見つける」のは実行時に画面を判 断するテスト実行AI。 役割を分けることが、AIに自分の答え合わせをさせないための答えです。 17
18. 「スピード」と「信頼性」を、 妥協なく両立させる決断を 独立した、強固なテスト検証レイヤーを設計することが、 プロダクトとビジネスの価値を守る防波堤となります。 ご清聴ありがとうございました mabl 株式会社 舟木将彦 アンケートにご協力ください 18