AIで作ったWebアプリの実機確認｜スマホ公開前の検証

対象端末と公開版を記録する

最初に対象の端末、OS、ブラウザー、向き、公開URL、アプリの版を記録します。すべての機種を一度に確認したと説明せず、使う人が多い構成から始めて未確認の条件を残します。Bolt、Lovable、Replitで作った場合も、開発用プレビューと公開先は別の確認対象です。架空の演習では、申請フォームの公開版で入力から結果表示までを通します。前の版を開いたまま修正の効果を判断しないよう、確認するURLと版を揃えることが、端末差と変更の効果を分ける出発点です。

エミュレーションと実機の役割

Chromeの公式資料はDevice Modeを近似として説明し、実際のモバイル端末でコードが動くわけではないと明記しています。画面幅、向き、通信条件等を早く試す助けになりますが、実機のCPUや入力、ブラウザー固有の動作をすべて代わりに確かめるものではありません。まず開発画面で大きな崩れを直し、次に実機で同じ操作を通します。AndroidのChromeでは公式のリモートデバッグ手順も利用できますが、他のOSやブラウザーまで同じ手順と仮定せず、それぞれの対象環境で確認してください。

• AI生成UIを公開前に確認する｜キーボード・ラベル・エラー表示

ソフトウェアキーボードで最後まで入力する

入力欄へフォーカスした時、キーボードで送信ボタンやエラーが隠れないかを見ます。複数の入力を移動し、スクロールして訂正し、必要な結果へ進めるかを確認してください。日本語入力、長い文、コピーした文字列など、利用者が使う入力を見本で試します。画面幅が合うことだけでは、操作が完結するとは分かりません。AIへ修正を頼む時は、端末条件、どの入力で何が隠れたか、望む動作を示します。画像だけでキーボードや保存の前提を推測させず、再現手順も渡すと確認を繰り返せます。

架空の例：通信失敗後の再送

架空の申請フォームで、送信時に通信が失敗した場合を考えます。入力を失わずエラーが伝わり、再試行した結果が二重に保存されないことを期待条件として決めます。これは対象アプリで必要な仕様を決める例で、製品が自動で保証する動作ではありません。復帰後は保存結果を読み直し、成功表示だけで完了にしません。戻る操作、向きの変更、別タブから戻った場合も必要に応じて追加します。確認の途中で実際の顧客へ通知が飛ばないよう、見本データと検証用の接続を用意してください。

• AIで表示の遅さを調べる｜測定・仮説・修正を分ける

AIには観測と推測を分けて渡す

「スマホで使えない」だけでは、修正をどこで確認するか決まりません。観測した操作、表示、保存結果と、考えている原因を別に書きます。Cursor等のリポジトリ支援へ渡す場合は関係する画面とスタイル、必要な実行条件を示し、無関係な画面の作り直しを含めません。修正後は同じ実機で同じ手順を再実行し、デスクトップの既存操作も必要な範囲で確認します。アクセシビリティや速度の確認は別の観点もあるため、この一つの実機試験だけで完全な対応を宣言しないでください。

費用と引き継ぎは検証記録へ結び付ける

追加のAI利用量が必要かは、同じ不具合の再試行と確認時間を含めて判断します。利用枠を増やしても、未取得の端末情報や再現手順は補えません。引き継ぎには端末の一覧、公開版、確認した操作、失敗時の見本、残る条件を残します。スクリーンショットやログに個人情報が含まれる場合は、共有前に内容を確認してください。契約や作成ツールを替える時も同じ操作を移行先で試すと、元の見た目を再現できたことと、必要な端末でサービスを使い続けられることを分けて判断できます。

• 初心者のAIアプリ制作｜三つの題材から最初の道具を選ぶ