AIに検索結果カードを作らせると、スクリーンショットはすぐ出てくる。幅の広い画面で整っていても、通信を遅くしたときの読み込み表示や、失敗後の再試行ボタンにTabで届くかは、その1枚からは分からない。
以下はReact/TypeScriptの架空の検索画面を使った検査手順です。特定のアプリや製品で実験して得た結果ではありません。焦点はコード生成の速さではなく、ブラウザで何を見たかを別の人が追える形にすること。
まず「動かした画面」を検査対象にする
エージェントが出した差分を読む前後に、実際のアプリを開く。手元のリポジトリなら、起動コマンドは思い込みで決めずにscriptsを確認する。
node -p 'JSON.stringify(require("./package.json").scripts, null, 2)'
実在する開発用またはプレビュー用scriptでローカル画面を起動し、検索結果カードを表示する。バックエンドが必要なら、リポジトリに既存のモックやテスト用環境があるかを先に確認する。本番のデータやAPIで失敗を再現しない。
Chrome DevTools for agents 1.0は、MCP server、CLI、agent skillsからブラウザの情報を扱う選択肢を用意している。Lighthouse監査や画面幅・ネットワーク・CPU条件のエミュレーションも利用できる。ただし導入・接続方法は環境ごとに異なるし、CLIとMCPの機能が完全に同じという意味ではない。エージェントにブラウザを渡す場合も、まず自分の環境で接続できる検査面を確保したい。
状態と条件を掛け合わせて、見たものだけ記録する
架空の検索画面について、最初から全組み合わせを網羅しようとはしない。事故になりやすい操作から選ぶ。
| 状態・条件 | 操作 | 期待すること | 実際の観測・証拠 |
|---|---|---|---|
| 読み込み中 × 遅い通信 | 検証用の遅延応答で検索する | 処理中と分かり、連打で意図しない重複リクエストが起きない | 未実施。Networkのリクエスト記録と画面を確認して記入 |
| 成功 × 狭い画面幅 | 結果カードを表示し、横方向を確認する | カードや操作ボタンが隠れない | 未実施。幅と画面の保存先を記入 |
| 失敗 → 再試行 × キーボード | 検証用の失敗応答に切り替え、Tabで移動する | エラーが読めて、再試行に到達できる | 未実施。フォーカス順と再試行後の画面を記入 |
ここでの「期待」は仕様の例であって、合格したという報告ではない。失敗応答を作る手段も、既存のモックや検証環境に合わせて選ぶ。Networkパネルでリクエストを眺めるだけでは、失敗後にボタンを操作できるかまでは判定できない。
Lighthouseを走らせるのは有益だが、監査結果が良くても、この表の「失敗 → 再試行」を人が操作できた証拠にはならない。自動監査と操作確認は別欄に分ける。
引き継ぐのは画像より「再現条件」
たとえばこんな短いメモを、レビュー対象の変更と一緒に残す。空欄を埋めずに「確認済み」と書くくらいなら、未実施のまま渡した方が安全です。
変更箇所: （実際のファイル名・PRを記入）
観測条件: （画面幅、通信条件、使用ブラウザ、データの作り方）
操作順: （検索 → 応答を失敗させる → Tabで再試行へ、など）
実際の結果: （画面、Network記録、監査結果の保存先）
未実施: （まだ確かめていない状態と理由）
次の操作: （再現する担当者が最初に行うこと）
GitHub Copilotのconnected cloud experienceは、対応するクラウドセッションを複数のサーフェスから続けられる方向に進んでいる。ただし提供は有料Copilot向けに順次進むもの。セッションを再開できても、別のブラウザで人が見た画面や判定まで自動で共有されるとは限らない。検査メモの保存先はチームで明示する必要がある。
エージェントの作業環境に差分や承認、未確認事項をどう残すかは、英語の記事エージェントの作業場所に証拠を残す考え方でも掘り下げられている。ここではその考え方を、ブラウザで見た状態の引き継ぎに絞って使いたい。
実行時にAIがUIを選び直す場合
AIが一度Reactのコードを書き、その後は決まったコンポーネントを表示する検索画面は、それだけでGenerative UIとは呼ばない。一方、実行時にAIがユーザーの文脈に応じて表示部品や操作を選ぶ仕組みなら、同じ「成功」でも出てくる画面が変わり得る。その場合は、どの入力・文脈でどの部品が出たかも観測条件に足す。
ケースを洗い出す入口として、Generative UIの実際の画面事例を見比べると、固定画面では見落としがちな操作を考えやすい。ただし事例集は検査ツールではない。自分のアプリの合否は、結局そのアプリのブラウザ上で確かめる。
スクショは証拠の一部にはなる。でもレビューで知りたいのは、その画像に至る操作と、まだ見ていない状態だ。次に触る人が同じ条件を再現できるメモがあれば、AIの「完了しました」をそのまま合格判定にしなくて済む。