AIが作ったUIの画面確認｜スクリーンショットと操作で確かめること

AIが生成した一覧画面が整って見えても、データがないとき、文字が長いとき、幅が狭いとき、通信などの失敗から戻るときに同じ判断はできません。四つを独立したチェック欄にすると、「狭い画面は見た」「エラー表示も見た」という記録は残っても、狭い画面でエラーから戻れるかは空白のままです。受入条件には、利用者がたどる状態と操作のつながりを置きます。

たとえば、空の一覧を狭い幅で開き、再読み込みを実行し、失敗表示を経て再試行し、空状態へ戻るまでを一つの行にします。別の行では、長い入力や表示名がある狭い画面で操作し、失敗後に入力内容と操作可能な状態が期待どおりかを見ます。合格にする期待結果はプロダクト仕様から書き起こし、AIが生成した現在の挙動をそのまま正解にはしません。

この組み合わせ台帳は、後述する公式資料の一般原則を基に記事が提案する実務上の方法で、各原典が定める分類や義務ではありません。画面ごとに前提状態、実行操作、期待結果、スクリーンショット、判定を一続きで残すことが要点です。実装を速く作れることと、受け入れてよいことを分ける考え方は、AI駆動開発の開発フロー｜レビュー・テスト・CIで人の判断を残すともつながります。

組み合わせる条件は、画面の主操作が壊れたときに判断できなくなるものから選びます。次の例をそのまま共通仕様へ流用すると、画面固有の期待結果が抜けます。対象画面の仕様に合わせて書き換え、該当しない条件には理由を残します。復帰後に利用者が作業を続けられるかまでが判定範囲です。

一覧なら「空状態×狭い画面×取得失敗からの再試行」を一行にできます。最初に空状態の案内と主操作を確認し、失敗を起こす操作を行い、エラー表示から再試行します。最後は、空状態へ戻るのか別の状態へ移るのかを仕様と照合し、その時点で主操作が使えるかを判定します。失敗中の画像から分かるのは途中経過です。再試行ボタンの動作や、表示の重なりが解消したことは復帰後の画像で判断します。

入力画面なら「長文×狭い画面×送信失敗からの復帰」を一行にします。長い内容を入力した状態で狭い幅にし、送信、失敗表示、所定の復帰操作、再操作まで進めます。期待結果には、入力内容を保持するのか破棄するのか、どこへ遷移するのか、ボタンや入力欄が再び操作できるかを仕様どおりに記します。長文の折り返しだけを切り出さず、エラー文や操作部と同時に現れた状態を画像に残します。

詳細画面なら「長い表示名×狭い画面×再読み込み後の復帰」を候補にします。見出し、補助情報、操作部が同時にある状態で、失敗前、失敗中、復帰後を比べます。「きれいに見える」では合否が担当者の印象に左右されます。内容を読める、必要な操作に到達できる、仕様で定めた情報と操作状態へ戻る、と対象ごとに観察可能な言葉へ変えます。

エラー画面の静止画がきれいでも、再試行後に入力が意図せず変わる、遷移先が期待と異なる、操作不能なままになるなら受入完了とはいえません。エラー復帰では、失敗を表示できたことと、利用可能な状態へ戻れたことを別の節目として記録します。狭い画面や長文条件でも同じ操作を繰り返し、復帰後の画像を判定対象に含めます。これも公式資料の一般原則を基にした実務提案であり、原典所定の試験分類や義務ではありません。

2026-09-21時点で、[Playwright公式のVisual comparisons](https://playwright.dev/docs/test-snapshots)は、`toHaveScreenshot`の初回実行で基準スクリーンショットを生成し、以後の実行結果をその基準と比較すると説明しています。自動比較を使うなら、まず人が仕様に合う状態を確認して基準にする必要があります。偶然できた生成UIを承認前に基準へ置けば、その誤りも比較の出発点になります。

同資料は、画像のレンダリングがOS、バージョン、設定、ハードウェア、電源状態、ヘッドレス実行などで変わり得るため、基準画像を作った環境と同じ環境での実行も案内しています。したがって台帳の画像には、何を確認したかだけでなく、基準と比較結果をどの環境で作ったかを結び付けます。差分が出たら、UI変更なのか実行環境の違いなのかを切り分けてから判定します。

「スマートフォン相当で確認」とだけ記録すると、再現する幅が分かりません。対象画面の幅を決め、空状態や長文を表示し、エラーから復帰する一連の操作を同じ条件で通します。幅は自社の画面を基準に、レイアウトの切り替わり付近や、操作部と長文が競合する条件から選びます。端末名とともに幅の数値も台帳へ記録します。

2026-09-21時点で、[Chrome for DevelopersのDevice Mode公式資料](https://developer.chrome.com/docs/devtools/device-mode)は、Responsive Viewport Modeでハンドル操作または幅・高さの直接入力によりviewportを変更でき、表示したmedia queryのbreakpoint間を選んで該当幅を発火させられると説明しています。台帳には選んだ幅と、その幅を選んだ根拠となる対象画面の切り替わりを残すと、担当者が変わっても同じ条件を再現できます。

ただし同資料は、Device Modeをモバイル表示・操作の一次近似とし、実機上でコードを実行するものではないと明示し、疑わしい場合は実機で確認するよう案内しています。狭い画面の受入条件には、エミュレーションで完了できる範囲と、挙動に疑いが残ったとき実機へ進む条件を分けておきます。エミュレーションの画像だけで実機確認済みとは扱いません。

台帳がプルリクエストの外にあると、差分と判定が離れます。確認した組み合わせごとに、前提、操作、期待結果、画像、判定、未解決事項をプルリクエストからたどれるようにします。差し戻すときは「画面が崩れている」だけでなく、どの行のどの操作後が期待結果と違うかを示します。修正後は完成画面だけを撮り直さず、同じ前提から復帰後までを再実行します。

2026-09-21時点で、[GitHub Docsのpull request review公式資料](https://docs.github.com/en/pull-requests/how-tos/review-pull-requests/reviewing-proposed-changes-in-a-pull-request)は、レビュー結果としてComment、Approve、Request changesを選べると説明しています。一方、Request changesがマージを防ぐのは、pull requestを必須にするrulesetまたはclassic branch protection ruleが設定される場合です。レビュー画面での差し戻しに加えて、実際のマージ条件と設定が一致するかを確認します。

証跡を添えてApproveまたはRequest changesで結果を残し、Request changesを停止条件にするなら対応する設定の有無も確かめる。この方法は公式資料の一般原則を基に記事が提案する実務上の運用で、GitHubが定める受入分類や義務ではありません。AI生成コード全体の権限や情報管理も同時に整理する場合は、Claude Codeのセキュリティ｜法人導入前に決める権限とデータ管理も確認できます。

導入時に決める中心は、スクリーンショットの枚数よりも操作列です。どの画面のどの主操作に、空状態または長文、狭い幅、失敗と復帰を重ねるか。期待結果を誰が仕様から決めるか。どの節目を画像に残し、誰が合格と差し戻しを判断するか。この一続きが決まれば、AIが作ったUIを再実行できる条件で受け入れられます。

対象画面ごとの台帳を作り、四条件を主操作へ結び付けます。復帰後の入力内容・遷移先・操作可能状態を期待結果として明記し、狭い画面は幅と確認環境を記録します。挙動に疑いが残れば実機で確かめます。証跡と未解決事項をプルリクエストへ添え、レビュー結果が実際のマージ条件になる設定かまで確認すれば、実行者と承認者の役割も明確になります。

受入の最小単位は、「空状態を狭い画面で開き、失敗から所定の操作で復帰し、期待した表示と操作可能状態へ戻った」という操作列です。長文が主なリスクなら空状態と置き換えるか、必要な画面だけ重ねます。全画面へ同じ四条件を課す必要はなく、除外理由を説明できることも判断の一部です。どこまで組み合わせれば十分かは、画面の主操作と失敗後の継続可否で決められます。自社の画面に合わせた台帳や受入条件を研修・導入支援で整理したい場合は、初回60分の無料相談で対象範囲を確認できます。