事前準備
URLを発行したらまずシークレットウィンドウのスマホ表示でページを開き、ログインなしで表示されることと、ビューポートが正しく設定されているかを確認します。viewportメタタグのcontent値が抜けていると、PCと同じ横幅で縮小表示されます。共有前に必ずブラウザのデベロッパーツールでモバイルビューに切り替えて目視してください。
内部情報が残っていないかをHTMLソースで確認します。開発メモのコメントや、ステージング環境のAPIエンドポイントがHTMLに直書きされていないかを検索してから共有してください。スマホでページを開いたレビュー担当者がソースを閲覧することは少ないですが、情報漏洩リスクは共有前に除去しておくのが原則です。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
確認観点
スマホ表示チェックで外部scriptやiframeを含む場合、それらがモバイル環境でも意図どおりに動くかを確認します。サードパーティのチャットウィジェットがスマホ画面を占有したり、iframe内コンテンツがはみ出したりするケースは多く、レビュー担当者に「この要素は仕様通りです」と事前説明しておかないと不要な指摘が来ます。
画像やCSSのパスがすべて公開環境で解決されるかを確認し、ローカルパスや開発サーバーのURLが残っていないかをチェックします。noindexは検索エンジン対策であってアクセス制限ではないため、スマホレビュー用のURLには必ず認証を設定してください。noindexだけでは第三者が直接URLにアクセスできてしまいます。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
NG例
多いNGは、PCで確認して問題ないと判断したままスマホレビューを依頼するケースです。タップターゲットが小さすぎる・ホバー前提のUIが残っている・横スクロールが発生するなど、スマホ固有の問題はPCブラウザでは検出できません。共有前に手元のスマホで一通り操作し、明らかな詰まりポイントをつぶしてから担当者へ渡しましょう。
もう一つのNGはフォントのレンダリング差異を「仕様です」で済ませるパターンです。iOSとAndroidではフォントの表示が異なり、特にカスタムフォントをWebフォントで読み込んでいる場合はレンダリングの差がデザインの意図から外れることがあります。レビュー前に両OSで表示を確認し、許容範囲を設計段階で決めておくとレビューの基準が明確になります。
修正後の再共有
スマホ表示の修正後は差し替えアップロードを行い、同じURLで最新版が確認できる状態にします。担当者へは「No.4のタップ領域、No.8のフォントサイズを修正しました。同じURLで最新版が表示されます」と番号と対応内容を添えて連絡するとスムーズです。
再確認を依頼する際は担当者が確認すべき箇所を絞り込み、全ページを再度見直すのではなく修正箇所のみを確認してもらう旨を明示します。「前回指摘のNo.4, No.8の2点のみご確認ください」と具体的に伝えることで確認コストを最小化できます。
よくある質問
スマホレビュー用URLをSNSに貼ったとき、OGPプレビューで内容が漏れることはありますか？
OGPクローラーは認証をバイパスできないため、認証付きURLでは画像やタイトルがプレビューされません。認証なしのURLではOGPタグの内容が表示されるため、機密ページには認証を設定してください。
iOS SafariとChrome for iOSの表示差異はどの程度考慮すべきですか？
iOSはWebKitエンジン必須のため両者の差は小さいですが、アドレスバーの高さなどUIの差がビューポートの計算に影響します。100vhを使っている箇所がある場合は両ブラウザで確認することを推奨します。
ダークモードでの表示もスマホレビューの対象に含めるべきですか？
ユーザーのOSテーマ設定によって色が変わる実装をしている場合は対象に含めます。prefers-color-schemeを使っていなければ通常モードのみの確認で問題ありません。