見た目を守るテストと、スクロールに追従するUIは同じ問題を解いている

May 27, 2026

1 min read

3 views

68%

画面は静止画ではない。だからこそ、壊れ方を設計する

多くの人は、UIの品質を「正しく表示されているか」で測ろうとします。けれど本当に難しいのは、正しく見えることではありません。ユーザーが触れた瞬間に、画面がどう変形し、どこが崩れ、どこまで崩れても許容されるかを決めることです。

たとえば、ボタンの位置が少しずれた、余白が1px増えた、見出しが折り返した。こうした変化は小さく見えますが、積み重なると「なんとなく使いにくい」に変わります。逆に、スクロールに応じてAppBarが追従するような動きは、見た目の問題に見えて、実は状態遷移の設計です。UIは静止した絵ではなく、時間の中で変化するふるまいだからです。

ここに共通する問いがあります。

UI品質とは、完成した見た目を固定することなのか。それとも、変化しても壊れないふるまいを定義することなのか。

この問いを真剣に考えると、ビジュアルリグレッションテストと、スクロールに追従するUI実装は、別物どころか同じ地平に立っていることが見えてきます。前者は「壊れ方を検出する技術」、後者は「壊れない変化を設計する技術」です。そして両者をつなぐ中心概念は、視覚をコードのように扱うことです。

UIの本質は「状態」ではなく「遷移」にある

アプリの画面を設計するとき、私たちはつい最終的な静止画に目を奪われます。しかしユーザーが実際に触れるのは、ページの初期表示だけではありません。スクロールする、戻る、展開する、読み込む、押す、待つ。UIは一連の遷移の連続であり、価値はその遷移の滑らかさに宿ります。

ここで重要なのは、UIの不具合の多くは、単一の状態ではなく状態間の変化に潜むという点です。たとえば、ヘッダーが通常時は美しくても、スクロール中に高さが急に変わると違和感が生まれます。逆に、AppBarがスクロールに追従して自然に縮むなら、画面は「いま自分がどこにいるか」を身体的に理解しやすくなります。

このとき、追従するAppBarは単なる装飾ではありません。ユーザーの運動に対するフィードバック装置です。スクロール量が増えると情報の優先順位が変わる。その変化を見た目で表現することで、画面全体の認知負荷を下げます。つまり、動きは飾りではなく、意味の圧縮なのです。

ここでビジュアルリグレッションテストの役割も見えてきます。テストは、静止画の差分を見ているようでいて、本当は「遷移の結果として現れた副作用」を捕まえています。たとえばレイアウトのずれ、折り返し、余白の破綻は、何かの状態変化が予期せぬ形で表示に漏れた証拠です。静止画の比較は、遷移の健全性を間接的に検証しているのです。

追従するAppBarが教える、UIは「文脈を失わないこと」が大事だという事実

スクロールに追従するAppBarが気持ちよく感じられる理由は、派手だからではありません。ユーザーが今どこにいて、何を見ていて、何が重要かという文脈を失わないからです。画面上部のナビゲーションが消えたり戻ったりするだけでも、ユーザーの脳内モデルは揺らぎます。良い追従は、その揺らぎを最小化します。

これはWebViewのように、ネイティブUIとコンテンツ表示の境界が曖昧になる場面で特に重要です。境界が曖昧なとき、人は「これはWebの都合か、アプリの都合か」を意識しません。だからこそ、AppBarの挙動が少しでも不自然だと、全体の信頼感が落ちます。文脈の連続性は、実装の細部から生まれる体験的な信頼です。

ここで面白いのは、ビジュアルリグレッションテストもまた文脈を守るための仕組みだということです。例えば、特定の画面幅でヘッダーが1行から2行に変わったとき、見た目が少し崩れても機能は壊れていないかもしれません。しかしユーザーはその崩れから、プロダクトの一貫性や丁寧さを読み取ります。人は機能だけでなく、視覚的一貫性からも品質を推定するからです。

つまり、追従するAppBarは「いまこの画面は自分についてきてくれる」という感覚を作り、ビジュアルリグレッションテストは「その感覚を壊す偶然の変化」を防ぎます。両者は、UIを単なる情報表示ではなく、ユーザーとの暗黙の対話として扱っている点で一致しています。

見た目のテストは、見た目だけを守るのではない。ユーザーが画面に対して抱く予測可能性を守る。

では、なぜ多くのチームはこの2つを別問題として扱ってしまうのか

理由は単純です。多くの開発現場では、テストは「壊れていないことの確認」、UI実装は「動くものを作ること」として分業されているからです。すると、テストは後工程に押しやられ、動きの設計は見栄えの話として軽視されやすくなります。

しかし本来、ここには強い相互依存があります。追従するAppBarのような動的UIは、状態遷移が増える分だけ、想定外の見た目崩れを生みやすい。逆に、静的な見た目を守るだけのテストは、動的な文脈の変化に弱い。動きが増えるほど、見た目の検証はより重要になるのです。

この矛盾を解く鍵は、テストを「最終成果物の監視」ではなく、UIの契約を明文化する手段として捉え直すことです。たとえば、次のような契約が考えられます。

スクロール前後でAppBarの高さが一定のルールで変化する
画面幅ごとにタイトルの折り返しが許容範囲内に収まる
主要アクションはスクロールしても視認性を失わない
WebView内のコンテンツとネイティブヘッダーの境界が破綻しない

これらは単なる見た目の好みではありません。ユーザーに約束した振る舞いです。そしてその約束は、コードだけでなく、画像差分としても確認できる必要があります。

ここで重要な発想の転換があります。テストは「完成後に付ける保険」ではなく、UIのふるまいを設計するための言語だということです。どの画面を、どの状態で、どのサイズで、どの程度まで許容するのか。これを定義すると、実装の判断基準がぶれにくくなります。

新しい見方: UIを「静的デザイン」ではなく「可変な境界面」として扱う

最も有用なメンタルモデルは、UIを完成図としてではなく、可変な境界面として見ることです。境界面とは、内部状態と外部入力がぶつかる場所です。スクロール、端末サイズ、文字量、OS差分、WebViewの描画タイミング。UIはこうした変数を吸収しながら、意味を保たなければなりません。

この観点から見ると、追従するAppBarは単なるUI部品ではなく、境界面の安定化装置です。スクロールという外力に対して、情報の重心を滑らかに移し、画面の意味を保ちます。ビジュアルリグレッションテストは、その安定化が崩れたときに検知する観測装置です。前者は制御、後者は監視。制御と監視の両輪があって初めて、境界面は信頼できるようになります。

この考え方は、単なるフロントエンドの話にとどまりません。どんなプロダクトでも、ユーザーが触れる部分には必ず「変化」があります。新しい文言、増える機能、長くなるリスト、異なる言語、想定外の端末。変化をゼロにすることはできない以上、必要なのは変化を禁止することではなく、変化が起きても意味が壊れない仕組みです。

その意味で、スクロール追従の設計とビジュアルリグレッションテストは、同じ哲学の異なる表現です。前者は「変化に寄り添う設計」、後者は「変化の逸脱を見逃さない設計」。どちらも、UIを完成品ではなく、更新され続けるシステムとして扱っています。

Key Takeaways

UIは静止画ではなく遷移の集合です。見た目の問題に見えても、多くは状態変化の設計不足から生まれます。
追従するAppBarは装飾ではなく文脈保持の装置です。スクロール中もユーザーの認知負荷を下げ、画面の意味を保ちます。
ビジュアルリグレッションテストは見た目だけを守るものではありません。ユーザーが画面に抱く予測可能性と信頼感を守ります。
テストはUIの契約を言語化する手段です。どの状態で、何を、どこまで許容するかを明文化すると、実装判断が安定します。
UIを可変な境界面として捉えると、動的な挙動と静的な品質保証を一つの枠組みで扱えるようになります。

画面を守るとは、変化を隠すことではなく、変化に意味を与えること

UIの品質を考えるとき、私たちはしばしば「崩れないこと」に意識を集中させます。もちろんそれは大事です。しかし本当に価値があるのは、崩れないことそのものではなく、変化しても文脈が失われないことです。

スクロールに追従するAppBarは、ユーザーの動きに意味を返す仕組みです。ビジュアルリグレッションテストは、その意味が偶然の変更で失われないようにする仕組みです。片方は体験を作り、片方は体験を守る。けれど両者を深く見ると、どちらも同じ問いに答えています。

「この画面は、変化の中でも自分であり続けられるか」。

UI設計の成熟とは、見た目を整えることではありません。変化を前提にしながら、変化の先でも同じ理解が続くようにすることです。画面がユーザーのスクロールに追従するときも、テストが見た目の差分を検出するときも、私たちは同じものを作っています。それは、壊れにくいインターフェースではなく、信頼できる関係性です。