WebとネイティブアプリのクロスプラットフォームUIパリティチェックリスト

UIパリティとは（なぜ簡単に崩れるのか）

UIパリティとは、Webアプリとネイティブモバイルアプリが同じプロダクトとして感じられることを指します。ピクセル単位で同じである必要はありませんが、意味や期待、タップや入力、待機の結果が一致している必要があります。

簡単なテスト：ある画面でユーザーが学んだことが、別のプラットフォームの同等の画面でも通用するかどうかを見てください。

多くの場合、問題を招くのは小さな違いです。Webでボタンが「Save」でモバイルが「Done」ならユーザーは一瞬止まります。あるプラットフォームで余白が狭ければ、機能は同じでも画面が窮屈に感じられます。リスト行をタップするとモバイルでは詳細が開くのにWebではチェックボックスが出る、といった違いは、ユーザーの信頼を損ねます。

何を正確に合わせるべきか？理解と信頼に影響するものなら合わせるべきです。多くのプロダクトでは、次が該当します：

• 同じ操作に対する名称とラベル、表示場所
• 主要画面のコアレイアウト（ナビゲーション、主要アクション、重要情報）
• 読み込み、エラー、無効、結果なしといった状態
• コンポーネントの挙動（タップ、スワイプ、長押し、キーボード、フォーカス）
• メッセージの口調と構成（何が起きたか、次に何をするか）

適応してよいのは各プラットフォームでの快適さに関する部分です。フォント描画、Safe area、iOSの戻るジェスチャーやAndroidのシステムボタンといったネイティブパターンは差があって構いません。重要なのはユーザーが同じ場所にたどり着き、変化を理解できることです。

実用的な目標は「予測できるパターン」です。たとえばWebでプロフィールを更新したら、モバイルでも同じフィールド、同じバリデーションルール、同じ成功メッセージが認識できるべきです。AppMasterのようなツールで素早くWebとネイティブを作る場合でも、パリティは明確なルールが必要です。そうしないと、似ているが別の2製品になってしまいます。

比較する前に共有のベースラインを決める

各プラットフォームが「正しい」と考える基準が違うとパリティレビューは崩れます。Webとネイティブの画面を比べる前に、「同じとみなす基準」を合意して文書化してください。地味ですが再作業を防げます。

大きな仕様は要りません。よく起きるズレを止めるためのルール数個があれば十分です：

• タイポグラフィ：サイズ、行間、テキストの折り返しや省略の扱い
• 間隔：パディング、マージン、グリッドのステップ、コンパクトと快適レイアウトの使い分け
• カラーロール：primary、danger、muted、コントラスト最低値、ダークモードの期待値
• コンポーネント：承認済みのボタン、入力、カード、ナビゲーションパターン
• 状態：読み込み、エラー、空、無効、成功のフィードバック

次に、真実のソースを1つに決めます。デザインファイルを使うチームもあれば、トークンと短いガイドを使うチームもあります。重要なのはルールが一箇所にあり、変更が記録されることです。AppMasterで作るなら、WebとモバイルのUIビルダでトークンと再利用コンポーネントを揃えておくと同じ選択肢がどこでも出ます。

最後に実行頻度と責任を決めます。パリティをリリース直前の仕上げではなくテストの一部として扱ってください。レビューのタイミング（リリース前や共有コンポーネント変更後）、誰がサインオフするか（デザインは見た目、プロダクトは意図、QAは端末カバレッジとエッジケース）、"Done"の定義（不一致は修正するか明確に受容する）を決めます。

例：顧客ポータルに新しい「請求書」ページを追加する場合、モバイルでテーブルがどう折りたたまれるか、空の状態が請求書不足をどう説明するか、オフライン時の「今すぐ支払う」ボタンの挙動を事前に決めておきます。基準があれば、レビューは討論ではなく差のチェックになります。

プラットフォーム間で一貫させるタイポグラフィのルール

タイポグラフィは「ほぼ同じ」が「違う製品」に感じられる場所です。まずスタイルに分かりやすいトークン名（H1、H2、Body、Caption）を付け、Webとネイティブで同じように適用してください。

プラットフォームに合わせたフォントファミリーを選びます。各プラットフォームで同じ雰囲気と密度を持つ主要フォントを一つ決め、フォールバックを定義します。例：iOSはSF（システムフォント）、AndroidはRoboto（システムフォント）、Webは近い外部フォント＋system-ui。目的は字形を完全に一致させることではなく、同じトーンと読みやすさです。

タイプスケールは一度定義して、小さく保ちます。誰も新しいサイズを勝手に作らないようにするためです。例えば：

• H1: 28–32px、行高 1.2–1.3
• H2: 20–24px、行高 1.25–1.35
• Body: 16px、行高 1.4–1.6
• Secondary: 14px、行高 1.4–1.6
• Caption: 12–13px、行高 1.3–1.5

サイズと同じくらいテキスト挙動も重要です。長いタイトルや予測しにくいデータ（名前、住所、チケットの件名）の扱いを決めておくと、Webとモバイルのずれを防げます：

• タイトル：最大2行、その後は省略記号で切る
• テーブルセル：1行で省略、タップ／ホバーで全体を表示
• 段落：自然に折り返す。単語の途中で切らない
• 数字：可能なら等幅数字を使い、小数点を揃える

整列もよくズレます。フォームやリストなどは左揃えを基本にし、短く単独の目的の見出しや空の状態のタイトルなどにだけ中央揃えを使ってください。

アクセシビリティの最低基準は譲れません。モバイルの本文は最低16pxを目安にし、小さいサイズで細いウェイトは避け、屋外でも読めるコントラストを保ちます。AppMasterを使っているなら、これらを共有デザイントークンにしておくと一貫性が出ます。

間隔とレイアウトのルール（モバイルSafe areaを含む）

間隔は「ほぼ同じ」が「違う印象」になる原因です。Webがゆったりしているのにモバイルが窮屈なら、ユーザーは違いを感じます。

両プラットフォームで使う一つの間隔スケールから始めてください。シンプルな4の倍数スケールはCSSやネイティブのレイアウトに合いやすいです。ルールは単純に：関連する項目は小さめの間隔、セクション間は広め、デフォルトのスクリーンパディングは固定、例外は稀で文書化する。

典型的なベースライン例：

• 共通ステップ：4、8、12、16、24
• 関連項目の間隔：8–12
• セクション間の間隔：16–24
• デフォルトのスクリーンパディング：16

次にモバイルのSafe areaを標準化します。コンテンツがノッチやホームインジケータ、システムバーの下に入らないようにします。明快なルール例：「主要コンテンツは常にSafe area + 基本パディングを尊重する」。下部にバーがあるなら、その分だけコンテンツのインセットに含めて最後のリスト行が到達可能になるようにします。

リストの密度も明確に決めます。compactとcomfortableの2択を名付け、行高、垂直パディング、区切り線の有無を定義します。同じ画面タイプでは両プラットフォームで同じオプションを使い、「請求書一覧」が別物に見えないようにします。

タッチターゲットは間隔に含まれます。モバイルではコントロールが押しやすいことが大事です。最低44x44は確保し、誤タップを防ぐためにアクション間のスペースも保ってください。

Webでは主要なブレークポイントでの応答（カラム数、サイドバーの振る舞い、リストがカードになるタイミング）を書き残してください。パリティレビューではピクセルを比較するのではなく意図を比較します。Webは一度に多く表示して良いですが、階層や重要アクションを隠してはいけません。

AppMasterで構築する場合は、WebとモバイルのUIビルダで同じ間隔トークンを使うと、最初から画面の一致度が高くなります。

状態：読み込み、エラー、無効、空の画面

一貫性が崩れるのはハッピーパスではなく、状態の扱いです。状態のUIを第一級のデザインとして扱い、Webとネイティブで構造、口調、アクションを揃えてください。

まずアクション配置を決めます。主要アクションは明確で一貫した位置に置く（例：Webのダイアログ右下、モバイルの固定ボタン）。副次アクションは主張しすぎないように。破壊的アクションには追加の摩擦を入れます：明確なラベル（「プロジェクトを削除」）、確認ステップ、戻れる方法（「キャンセル」）。

無効化されたコントロールはバグのように見えないように。無効は本当に実行できない場合だけ使い、コントロール近くに理由を説明してください。モバイルで見つけにくいツールチップよりヘルパーテキストの方が有効です。ユーザーが直せるなら方法を示し（「チェックアウトを有効にするには支払い方法を追加してください」）、直せないならいつ解除されるかを書きます（「承認後に利用可能」）。

読み込みのルール

コンテキストごとに読み込みパターンを一つ選び、両プラットフォームで安定して使います：

• テーブルやカード、リストなどページのコンテンツはスケルトンを使う。
• 短いブロッキング待ち（サインイン、フォーム送信）はスピナーを使う。
• インジケータはユーザーの視線がある位置に置く：タップしたボタンの内部、または変化しているコンテンツエリア。
• 主要要素（タイトル、主要ボタン）のためのスペースを確保し、レイアウトジャンプを防ぐ。

エラーと空の状態のルール

エラーは具体的で落ち着いた言い回しにし、回復可能なアクションを一つ示します。可能なら問題の近くに表示（フィールドレベル）、そうでなければバナーやダイアログで一つの明確な復旧アクション（「再試行」「編集する」「サポートに連絡」）を付けてください。ユーザーを責める表現は避けます。

空の状態はテンプレート化すると効果的です：短い見出し、1文のガイダンス、次にユーザーが取りそうな主要アクション。例：AppMasterで作られた顧客ポータルの「請求書」タブが空の場合は「請求書はまだありません」と表示し、CTAは「請求書を作成」にしてWebとモバイルで文言と挙動を揃えます。

コンポーネントの挙動ルール（見た目だけでなく）

見た目が似ていても、挙動が違うとユーザーの第一印象が壊れます。タップを2回するとどうなるか、エラーはどう出るか、戻るで期待した場所に戻るか、こうした挙動をチェックリストに含めてください。

コアコンポーネントの相互作用ルールを定義する

各コンポーネントについて一つの“真実”を書き、それを各プラットフォームの慣習に合わせてマッピングしますが、結果は変えないようにします。

• Buttons：押下のフィードバック（リップル、ハイライト、ハプティクス）、長押しの挙動、二重送信防止（短時間無効化かリクエスト完了まで無効）を定義する。
• Forms：いつバリデーションするかを決める。多くはメールのような必須項目はblurで検証し、任意項目は送信時のみエラー表示にする。最初の無効フィールドにフォーカスするのは常に行う。
• Lists：主要な更新パターンを選ぶ。モバイルはプル・トゥ・リフレッシュ、Webは更新ボタンでも良いが、両方とも同じデータを更新しスクロール位置を予測可能に保つ。ページング方式（ページ番号、Load more、無限スクロール）も統一する。
• Navigation：戻るの挙動は意図に合わせる。ディープリンクの扱い、モーダルの閉じ方、フローがフルスクリーンかモーダルかを定義する。
• Search：クリアボタンの挙動（テキストのみか結果も消すか）、空結果の文言、フィルターチップの1タップでの削除などを標準化する。

テストできる小さな例

請求書を検索し詳細を開いて支払うというフローを想像してください。モバイルで「支払う」を素早く2回タップすると、スピナーは表示されてもアクションがロックされていなければ二重請求が発生します。WebではEnterで無効なフィールドがあるのに送信されてしまうことがあります。

AppMasterで作るなら、Business Processのロジックで単一のインフライト支払いリクエストにする、検証トリガーを揃えるなど同じルールを設け、WebとモバイルのUIビルダでも挙動を合わせます。

一度決めたら毎リリースで検証してください：タップを2回、エラーのある送信、リフレッシュ、戻る、検索のクリアなどを試します。

手順：パリティレビューのやり方

パリティレビューは繰り返し可能な儀式にすると効果的です。目的は「同じ機能なのに体験が違う」ことをユーザーより先に見つけることです。

まず並べて比べる画面セットを選びます：サインイン、検索、詳細画面、フォーム送信、設定など。同じテストデータを使って、挙動の違いではなく内容の違いを比較します。

レビューは一定の順で行います：

• ラベル、アクション、結果が一致しているか確認する。
• 状態を検証する：読み込み、エラー、空、無効、成功。
• 挙動をチェックする：タップ、フォーカス、キーボード、スクロール、確認。
• その後で間隔、タイポグラフィ、視覚的な仕上げを確認する。
• 修正後は少なくとも一つのゴールデンパスで再テストする。

スコアカードで判断を早めます。各画面やコンポーネントに対し、次のいずれかを付けます：

• Match：意図と挙動が同じで、プラットフォーム固有の差だけ
• Acceptable difference：UIは違うが結果は同じで文書化済み
• Mismatch：意味が変わる、ステップが増える、ルールを壊している

ミスマッチを記録する際は、2枚のスクリーンショット、破られたルール名（例：「主要アクションの配置」や「空の状態のトーン」）、そしてユーザー影響を一文で書いてください。AppMasterのようにWebとネイティブでロジックを共有できる場合は、問題がUIビルダの設定なのか共有コンポーネントのルールなのか、プロセスの問題なのかも記録します。

同じミスマッチが繰り返されるなら、ルールがあいまいか現実的でない可能性が高いです。スクリーンを個別に直すのではなく、ガイドラインを更新してください。

不一致を生むよくある落とし穴

ほとんどのパリティ問題は大きな決断ではなく、実装やバグ修正、最後の変更で忍び込む小さな差分です。チェックリストは役に立ちますが、どこからズレが始まるかを知っておくことが重要です。

コピーのずれはよくある問題です。Webでは「Save changes」なのにモバイルは「Update」となっていると、同じことでもユーザーには摩擦が生まれます。パスワードリセットやプロフィール編集、支払い確認などで特に目立ちます。

間隔のずれは静かに広がります。ある画面の6pxを増やしたのが広がり、数回のスプリント後にはWebはゆったり、モバイルは窮屈、という状態になります。

状態の欠落が最も混乱を招きます。Webは空の状態やエラーを明確に出しているのに、モバイルは空のリストや永遠のスピナー、あるいは無言の失敗になっていることがよくあります。これは状態を扱う場所が異なる（Webはフロントエンド、モバイルはネイティブビュー）と起きやすい問題です。

レビュー時に注意する点：

• 同じアクションに対する異なるラベルやトーン
• 間隔スケール外のランダムなパディングやマージン
• 片方のプラットフォームで読み込み・エラー・空・無効状態が欠けている
• プラットフォームのデフォルトがルールなしに混入している（トグル、日付ピッカー、アラート）
• アクセシビリティの後退：Webのフォーカス順の混乱やモバイルのターゲットが小さすぎる

単純な例：顧客ポータルでWebは「No invoices yet」とヒントと追加ボタンを表示しているのに、モバイルは空のリストだけ表示している場合、修正は見た目の調整ではなく空の状態の内容とボタンの期待挙動を合意することです。

AppMasterで両方作っている場合でも、テキスト、間隔トークン、状態処理のルールがないと各画面が例外になりがちです。

リリース前の5分チェック（クイックパリティチェック）

短いパリティチェックでユーザーが最初に気付く違和感を捕まえます：文言の違い、ボタンの挙動の違い、未完成に見える画面。

Webと実機の参照画面を一つずつ開き、最も使われるフロー（ログイン、検索、チェックアウト、申請フォーム）を選んで次を確認します：

• タイポグラフィスケール：見出し、本文、キャプションが同じサイズステップとウェイトルールに従っているか。特に小さい画面での行間を確認。
• 間隔とタッチの快適さ：カード、フォーム、ダイアログ周りのパディングが一貫しているか。モバイルでノッチやホームインジケータの近くが窮屈でないか確認。
• 画面状態：主要画面が読み込み、エラー、空、無効状態を明確に示しているか。ユーザーが常に次に何をすべきか分かるか。
• コンポーネントの挙動：主要アクションが同じ方法で送信され、同じフィードバックを出し、二重タップ／二重クリックを防いでいるか。戻るで入力データが失われないか。
• コピーの意味：ラベルやエラーメッセージが同じ意味か。Webが「Billing address」と呼ぶものをモバイルが「Payment info」としてしまっていないか確認。

失敗が見つかったら一つの質問をする："ユーザーは別の製品に切り替わったと感じるか？" 最も大きな不一致を優先して直します。

例：AppMasterで作られた顧客ポータルで、Webと同じフォームがモバイルにあり、ネットワークが遅い状態でモバイル版が「Submit」を2回許してしまうなら、ボタンを読み込み中に無効化して二重送信を防ぐなどの修正を入れてください。

例：顧客ポータルをWebとモバイルで一致させる

簡単な顧客ポータルにログイン、プロフィール、注文一覧の3画面があるとします。Webはサポート担当がラップトップで使い、モバイルは顧客が外出先で使うケースです。UIの細部は違っても同じフローと意味が伝わるようにしたい場面です。

よくある不一致は注文がまだ無い場合です。Webはアイコン、短いメッセージ、主要ボタン（「商品を探す」）を表示する親切な空の状態を出すのに、モバイルは空のリストだけで案内がないことがあります。ユーザーはアプリが壊れていると感じます。

修正はルール化です。適用例：

• 空の状態テンプレート：タイトル（「注文はまだありません」）、短い案内文、明確な主要アクションを両プラットフォームで共通にする。副次アクションはリンクにしてボタンを乱立させない。
• ボタンの階層：画面ごとに主要アクションは一つ。両方で「商品を探す」を主要にする。「サポートに連絡」は副次で見た目を軽くする。
• 間隔スケール：同じステップ（例：8、16、24）を使う。モバイルはタッチ領域のために縦のパディングを少し増やして良いが、スケール自体は共通にする。

挙動面で壊れやすい点も明確にします：

• 更新：モバイルはプル・トゥ・リフレッシュ、Webは更新アイコンでも良いが、どちらも同じ読み込み状態を出し、可能な限りスクロール位置を維持する。
• ページング：WebはLoad moreやページサイズを見せても良いが、モバイルは無限スクロールやLoad moreを使い、いずれも新しい項目は追加で表示される方式にする。
• エラー：Ordersの読み込みが失敗したら、両方で同じメッセージと再試行アクションを出す。片方だけトーストで、片方は全画面といった差は避ける。

重要なのは結果です。ユーザーが何が起きているか、次に何をすべきかを理解できれば、UIは各プラットフォームに合わせつつ一貫したプロダクトに感じられます。

次のステップ：プロダクトの成長とともにパリティを維持する

一度うまくいっても、機能追加や早急な修正、プラットフォーム限定の要望ですぐに崩れます。目標は「一貫性を保つことが最も簡単な選択肢」になることです。

チェックリストは生きたドキュメントにしてください。各リリース後に何が変わったか、何が驚きだったかを記録します。モバイルで空の状態が違って出たなら、それをルールか例にして再発を防ぎます。

一貫性を最短ルートにする

再利用できる部品とページテンプレートを作ると判断回数が減ります。リスト画面、詳細画面、フォーム、結果なしビューのテンプレートを少数用意し、共通のコピー（ボタンラベル、空の状態メッセージ）を一箇所で管理すればWebとネイティブのトーンが乖離しません。

簡単な運用例：

• パリティルールはリリースノートで更新し、数週間後にまとめて対応しない。
• 機能の受け入れ基準にパリティ項目（状態、間隔、挙動）を含める。
• PRやQAのサインオフに両プラットフォームのスクリーンショットや短い録画を必須にする。
• "承認された差分" を記録して例外を明示的にする。
• デザインシステム変更後に素早いパリティチェックを入れる。

パリティを開発プロセスに組み込む

どんなツールを使うにせよ、共有トークン、共有テンプレート、共有の挙動ルールを目指してください。AppMasterを使う場合は、トークンや再利用UIパターンをWebとモバイルのビルダで共有資産として扱い、重要な挙動はBusiness Process Editorで一元管理すると、パリティが作り方によって支えられます。

これを定着させるには、次に作る機能のDefinition of Doneにパリティチェックを入れてみてください。それだけで「一貫性を保つ」ことがチームで検証可能な作業になります。