Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
「見た目」と「意味」をAIが判定 ~ビジュアルアサーションで変わる テストの守備範囲~
Search
Masahiko Funaki(舟木 将彦)
March 25, 2026
Technology
65
0
Share
「見た目」と「意味」をAIが判定 ~ビジュアルアサーションで変わる テストの守備範囲~
2026年3月25日に開催したmablウェビナーのスライドです。
録画ビデオはこちらです
https://mabl.wistia.com/medias/1uxtgi6h00
Masahiko Funaki(舟木 将彦)
March 25, 2026
More Decks by Masahiko Funaki(舟木 将彦)
See All by Masahiko Funaki(舟木 将彦)
202605-進化し続けるUIに追従.pdf
mfunaki
0
19
mablの要素選択を完全理解〜壊れないテストを作るための技術選択
mfunaki
0
41
知って得するmabl活用Tips〜「こんな時どうする?」実践機能ガイド
mfunaki
0
53
20260422-mablで変わるテスト自動化_品質_速さ_コストの三角形を崩す5つのアプローチ.pdf
mfunaki
0
80
手順(プロンプト)だけで テストを自動作成~テスト作成エージェントを使いこなすための 実践プロンプト術
mfunaki
0
140
イントラネットの社内アプリからローカル開発環境まで〜mabl Linkで実現する閉域網アプリケーションのセキュアなテスト実行
mfunaki
0
44
フルスタックQAへの第一歩。Web UIとAPIテストを統合した品質保証戦略
mfunaki
0
100
mabl新機能解説:プロンプトによるテスト生成とローカル/クラウド実行のシームレスな統合
mfunaki
0
110
mabl MCP x 生成AIによる開発・テスト自動化の未来 - コンテクスト駆動型のAI体験 -
mfunaki
1
130
Other Decks in Technology
See All in Technology
形式手法特論:公平性制約の位相的特徴づけ #kernelvm / Kernel VM Study Kansai 12th
ytaka23
1
750
Building applications in the Gemini API family.
line_developers_tw
PRO
0
1.5k
PHP と TypeScript の型システム比較:AI 時代の「型」は誰のためにあるのか? #frontend_phpcon_do / frontend_phpcon_do_2026
shogogg
1
250
JJUG CCC 2026 Spring AI時代の開発こそ標準化を武器に! ― 方式・プロセス・プラットフォームの標準化
s27watanabe
2
720
イベントストーミングとKiroの仕様駆動開発で実現する要件の認識合わせプロセス
syobochim
7
1.2k
「速く作る」から「正しく作る」へ ─ 生成AI時代の開発フロー改革の ロードマップと実行 ─
starfish719
0
7.6k
美味しいスイスチーズを作ろう🧀🐭
taigamikami
1
240
AI-DLCを活用した高品質・安全なAI駆動開発実践 / AI Driven Development with AI-DLC
yoshidashingo
0
140
AI駆動開発が変える、大規模開発の前提 ーHuman in the Loop から Human on the Loop へ / AIE2026
visional_engineering_and_design
7
4.7k
Oracle AI Database@AWS:サービス概要のご紹介
oracle4engineer
PRO
4
2.8k
ブロックチェーン / Blockchain
ks91
PRO
0
110
AI Adaptable なテストを整える工夫 / Ways to Make Your Tests AI-Adaptable
bitkey
PRO
3
210
Featured
See All Featured
A designer walks into a library…
pauljervisheath
211
24k
BBQ
matthewcrist
89
10k
Prompt Engineering for Job Search
mfonobong
0
330
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
360
Are puppies a ranking factor?
jonoalderson
1
3.5k
We Analyzed 250 Million AI Search Results: Here's What I Found
joshbly
1
1.3k
Being A Developer After 40
akosma
91
590k
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
250
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
220
SERP Conf. Vienna - Web Accessibility: Optimizing for Inclusivity and SEO
sarafernandez
2
1.5k
Art, The Web, and Tiny UX
lynnandtonic
304
22k
We Are The Robots
honzajavorek
0
240
Transcript
「見た目」と「意味」をAIが判定 ~ビジュアルアサーションで変わる テストの守備範囲~ 2026年3月25日(水) 13:00~14:00 | 舟木 将彦 (Sales Engineer,
mabl)
今日お伝えすること • 従来のアサーションが苦手だったこと • ビジュアルアサーションの3つの価値 ◦ 視覚的判定 (Visual Judgement): 見た目・状態を判定
◦ 意味的分析 (Semantic Analysis): 文脈・言語・関連性を判定 ◦ ノーコード (Zero Code): すべてが自然言語で書ける • 具体的なユースケース4選とデモ • 信頼性を高めるベストプラクティス
従来のアサーションが届かない領域 課題提起 • セレクタ・固定値依存 → UIの小変更で壊れやすい • DOM構造だけでは「見た目の崩れ」「デザインの違和感」は検出できない • 翻訳漏れ・検索結果の妥当性など「意味」は比較できない
• グラフ・PDF・画像ファイルの内容確認は手動(目視)に頼っていた
ビジュアルアサーションとは 課題提起 • 自然言語プロンプトでページ・ダウンロードファイルの内容を検証 • 大規模言語モデル(LLM)が「判定」する → 意味・文脈・傾向を理解 • Google
Cloud Vertex AI (Gemini) 基盤 (顧客データをトレーニングに不使用) • ルールベースのアサーションでは難しかったケースをAIで解決
Zero Code ー すべてが自然言語で書ける Zero Code: 共通メリット • コードを書かずに自然言語でアサーションを記述 •
エンジニア以外もアサーションを作成・レビュー可能 • 「何を確認したいか」をそのまま書けばよい ◦ 例:「週次売り上げチャートが上昇傾向を示し、エラーアイコンがないこと」
デモ: アサーションを書いてみる Zero Code: 共通メリット • mablトレーナー上での操作 • テキストボックスに自然言語を入力 →
即時検証
DOM構造だけではわからない「見た目」を検証 Visual Judgement: 見た目の判定 • 画面の配置崩れ・デザインの違和感・UI状態を判定 • 「正しい値」ではなく「正しい状態・傾向」を確認 • canvas
/ SVG など従来セレクタが届かない要素も対象
ユースケース1:グラフ・チャートの検証 Visual Judgement: 見た目の判定 • 例:「週次売上チャートが月~金で上昇傾向を示し、エラーアイコンが表示されて いないこと」 • 従来:数値をAPIで取得・比較できるコードが必要 •
今は:スクリーンショットを自然言語で判定 • 活用シーン:ダッシュボード・レポート画面の回帰テスト
ユースケース2:エラー状態・UIの検証 Visual Judgement: 見た目の判定 • 例:「フォーム送信時にエラーメッセージが赤字で表示され、送信ボタンが無効化 されていること」 • 従来:個別要素ごとにアサーションを列挙 •
今は:画面の「状態」をまとめて1文で検証 • 活用シーン:バリデーション・空状態・ローディング状態の確認
文脈・意味・言語をAIが理解して検証 Semantic Analysis: 意味の判定 • テキストの「値」ではなく「意味・関連性・言語」を判定 • 完全一致では検出できない問題を捉える • データの整合性・翻訳品質など「人が読んで判断していた」領域へ
ユースケース3:多言語対応の検証 Semantic Analysis: 意味の判定 • 例:「ブランド名・固有名詞・頭字語を除き、ページが日本語で表示されていること」 • 従来:全テキスト要素を個別チェック or 目視確認
• 今は:例外を含む自然言語ルールで一括判定 • 活用シーン:ローカライズリリース前の品質確認
補足:例外を自然言語で指定できる強み Semantic Analysis: 意味の判定 • 「NEW」「webhook」「URL」「API」は英語のまま許可 • 「Submit」「Cancel」は日本語化が必要 • プロンプトに成功・失敗の具体例を付記することで精度が向上
ユースケース4:検索結果・データ整合性の検証 Semantic Analysis: 意味の判定 • 『東京 ホテル』の検索結果がすべて東京都内の宿泊施設であること • 従来:特定キーワードの部分一致チェックのみ •
今は:結果の「関連性・妥当性」を意味的に検証 • 活用シーン:検索・レコメンド・フィルタリングの品質保証
ダウンロードファイル検証 2軸の統合例 • 対応形式:PDF, PNG, JPG, GIF, WEBP, BMP •
Visual Judgment: 画像レイアウト・デザイン確認 • Semantic Analysis: 請求書の顧客名・金額・振込先の確認 • ここにもZero Code: 専用パーサー不要、自然言語で完結
信頼性の高いアサーションを書く4つのポイント ベストプラクティス • 意図に焦点を当てる • 適切な厳密さを指示する • 例を追加する • 成功・失敗シナリオ両方でテストする
ポイント①:意図に焦点を当てる ベストプラクティス • ❌「月曜の売上バーの高さが200px以上」 • ✅「週次売上チャートが上昇傾向を示していること」
ポイント②:適切な厳密さを指示 ベストプラクティス • 曖昧過ぎ → 「ページが読み込まれた」(重要要素の欠落を見逃す) • 厳密すぎ → 条件が多すぎて評価困難
(複数アサーションに分割を) • 具体例:ソートされたテーブルの検証 ◦ ❌「テーブルが昇順にソートされていること」→ 重複値があるとFAIL ◦ ✅「テーブルが昇順にソートされていること(同じ値が連続する場合も許容)」 → PASS
ポイント③④:例を追加して成功・失敗でテスト ベストプラクティス • アサーション末尾に成功・失敗の例を付記 • Chrome DevToolsでページを手動編集し、失敗シナリオを再現 • 結果フィードバックをもとにプロンプトを反復改善
知っておくべき制限事項 制限・注意事項 項目 内容 上限数 テスト当たり最大30個。 追加コスト クラウド実行で0.5クレジット/回。 非対応 パフォーマンステスト内では失敗。
結果の言語 英語で返る傾向あり。日本語で受け取るにはプロンプト末尾に「結果 を日本語で返してください」と追記。 評価範囲 ビューポート内の表示部分のみ。画面外の要素は評価されない。
ビジュアルアサーションで変わるテストの守備範囲 クロージング 従来のアサーション ビジュアルアサーション 見た目の崩れ ❌ ✅Visual Judgement 意味・翻訳品質 ❌
✅Semantic Analysis ファイル内容 ❌ ✅両方の融合 実装コスト コード必要 ✅Zero Code
次のステップ クロージング • mablトレーナーでビジュアルアサーションを追加してみる • 参考: ビジュアルアサーション作成 ベストプラクティス
Q&A