「ローディング画面なんて、グルグル回るアイコンを置いておけばいいんじゃないの？」
Google Stitch でUIを設計するようになってしばらくは、そう思っていた。でもあるとき、スケルトン画面とローディングUIを真剣に設計してみたことで、考えが大きく変わった。
コンテンツが読み込まれるまでの「待ち時間」は、ユーザーが必ず体験する瞬間だ。その体験を「仕方ない空白」として放置するか、「設計された体験」として作るかで、プロダクトへの印象は変わる。
Stitch でスケルトン画面を設計したのは、フィードアプリのUIを担当したときだった。コンテンツ読み込み中の状態をどう見せるか——そこに本腰を入れて向き合った結果、「待ち時間のUI設計」は単なる「つなぎ」ではないと気づいた。
結論から言うと——スケルトン画面は「ローディング中です」という事実を伝えるだけでなく、「もうすぐコンテンツが来る」という期待を作り、体感速度を向上させる設計ツールだ。Google Stitch では静的なスケルトンUIの見た目を詳細に設計でき、コンテンツ表示後との一貫性を作るうえで特に有効に機能する。
スケルトン画面とは何か
スケルトン画面（Skeleton Screen）とは、コンテンツが読み込まれる前の状態に表示される「仮のレイアウト」のことです。テキストや画像の代わりに、グレーの矩形や円形のプレースホルダーが実際のコンテンツと同じ位置・サイズで表示されます。スピナー（グルグル回る円形アイコン）と異なり、「どんな内容が来るか」の形を先に見せることで、体感的な待ち時間を短く感じさせる効果があります。
スケルトン画面が広く使われるようになったのは、FacebookやLinkedInが採用したことがきっかけとされています。現在ではほぼすべての主要アプリで使われている標準的なUIパターンです。
スピナーとスケルトンの違い
ローディングUIには主に2種類のアプローチがある。
- スピナー（Spinner）：回転する円形アイコン。「読み込み中」という事実だけを伝える。コンテンツの形が予測できない場合や、処理が短時間で完了するケースに適している
- スケルトン画面（Skeleton Screen）：コンテンツの「型」を先に見せる。体感速度を上げ、レイアウトシフトを防ぐ。コンテンツの形が予測できる場合（記事一覧・プロフィール画面など）に特に有効
どちらを使うべきかは「読み込み時間の長さ」と「コンテンツの形の予測可能性」によって決まる。短い処理（0.5秒以下）には過剰で、スケルトン自体がチラつきの原因になることもある。
体感速度が上がる理由
スケルトン画面を表示することで、ユーザーが「何かが起きている」「もうすぐ内容が来る」という感覚を持てる。これが体感速度の向上につながる。
心理学的には「進捗の知覚」と呼ばれる現象で、白紙（スピナー）より「次に来るものの輪郭」が見えている方が、待ち時間のストレスが少ない。これはファストフード店が調理を客席から見えるようにすると待ち時間の苦痛が減る、という研究と同じ原理だ。
Google Stitch でスケルトン画面を設計した体験
フィードアプリのUI設計で、記事カードの一覧画面を作ることになった。読み込み中の状態をどう見せるか——Stitch に初めてスケルトンのプロンプトを書いたのは、そのときだった。
最初のプロンプトとその結果
「記事一覧のスケルトン画面を作って」というプロンプトで生成してみた。
出てきたのは、確かにスケルトンっぽい画面だった。でも、実際のコンテンツ表示画面と比べると、カードのサイズが微妙に違う。アイキャッチ画像の縦横比がずれている。テキストのプレースホルダーの行数が実際のコンテンツと合っていない。
これでは、コンテンツが読み込まれた瞬間に「ガタッ」とレイアウトがずれる「レイアウトシフト」が発生してしまう。スケルトン画面の最大の価値のひとつは、このレイアウトシフトを防ぐことにある。
「実際のコンテンツと同じ寸法」を徹底する
プロンプトを書き直した。「記事一覧画面のスケルトン。同じプロジェクトで作成した記事カードのサイズ（画像エリア160px高、タイトル2行分、本文2行分、著者アバター32px）に完全に合わせたプレースホルダーで構成すること。グレー#E5E7EB、角丸4px。アニメーションはSTATIC（静止）で、shimmer効果の表現は不要。」
今回は実際のコンテンツ画面と並べて比較しても、ほぼズレのないスケルトンが生成された。「コンテンツと同じ寸法で作る」という原則を明示することが重要だとわかった。
注意点として、Stitch はローディングアニメーション（shimmerのキラキラと流れるエフェクト）を設計・実装することはできない。Stitch で設計できるのはスケルトンUIの見た目（静止状態）のみで、アニメーションはFigmaへのエクスポート後または実装段階で追加する必要がある。
スケルトン画面の設計パターン
Stitch を使いながら、さまざまな画面タイプのスケルトンを設計してきた。よく使うパターンをまとめる。
カード一覧型スケルトン
SNSフィード・ニュース一覧・商品一覧など、カードが縦に並ぶ画面のスケルトン。設計のポイントは以下の通り：
- 画像エリアのアスペクト比を実際と一致させる
- テキスト行数を実際のコンテンツの最大行数に合わせる
- アバター画像は円形プレースホルダーで表現する
- カード間の余白は実際のUIと同じ値にする
Stitch へのプロンプトには「カード内のすべての要素の寸法を〇〇pxと指定」という形で数値を明示する。
詳細ページ型スケルトン
記事詳細・商品詳細・プロフィール詳細など、縦長のコンテンツページのスケルトン。
詳細ページのスケルトンで重要なのは「ファーストビューだけスケルトンにする」という判断だ。スクロールしないと見えない部分もすべてスケルトンにすると、初回表示の印象が「スケルトンだらけ」になって不自然に感じる。ファーストビュー（スクロールなしで見える範囲）のみにスケルトンを適用し、スクロール後のコンテンツは「スクロールしながら読み込む」設計の方が自然なことが多い。
ローディング体験の全体設計
スケルトン画面単体の設計だけでなく、「読み込み→コンテンツ表示→エラー」のフロー全体を設計することも重要だ。
エラー状態を忘れない
読み込みが失敗したとき、ユーザーは何を見るべきか。スケルトン画面を設計するとき、同時に「エラー状態の画面」も設計することを忘れやすい。
Stitch でスケルトン画面を設計したら、必ずセットで「読み込みエラー画面（エラーアイコン + エラーメッセージ + 再試行ボタン）」も生成する。この「エラー→再試行→再読み込み」のフローが設計されていないと、ユーザーは何が起きているかわからないまま取り残される。
プルトゥリフレッシュ（引っ張って更新）のUI
モバイルアプリでは「下に引っ張ると更新される」プルトゥリフレッシュも、ローディング体験の一部だ。引っ張っている最中・更新中・更新完了のそれぞれの状態をセットで設計することで、一貫したローディング体験が作れる。
Stitch に「プルトゥリフレッシュの3状態（引っ張り中・読み込み中・完了）を3画面で生成」というプロンプトを書くと、フロー全体の見た目を一気に確認できる。
よくある失敗と対処法
- 失敗1：実際のコンテンツと寸法が違う——スケルトンとコンテンツのサイズが違うと、コンテンツ読み込み時にレイアウトが大きくズレます。Stitch で設計するとき、実際のコンテンツ画面のサイズ仕様をプロンプトに明示的に含めましょう。
- 失敗2：ページ全体をスケルトンにしすぎる——ヘッダー・ナビゲーションまですべてスケルトンにすると、ユーザーは「アプリが壊れた？」と感じることがあります。静的な要素（ナビゲーション・タイトルバーなど）はスケルトンにせず、動的なコンテンツ部分のみにスケルトンを使いましょう。
- 失敗3：エラー状態を設計していない——読み込み失敗時の画面がないと、スケルトンが永遠に表示され続けます。エラー状態は必ずスケルトンとセットで設計しましょう。
- 失敗4：カラーが目立ちすぎる——スケルトンのプレースホルダーカラーが濃すぎると、実際のコンテンツより目立ってしまいます。プレースホルダーには背景より少し濃い程度のグレー（例：背景#FFFFFFなら#E5E7EB）を使うのが一般的です。
- 失敗5：行数・要素数を多くしすぎる——実際のコンテンツより多くの行やカードをスケルトンとして表示すると、コンテンツ読み込み後に要素が「減る」ように見えて不自然です。スケルトンの要素数は実際のコンテンツと同等か、わずかに少なめにしましょう。
よくある質問（FAQ）
Q. Google Stitch でスケルトン画面のアニメーション（shimmerエフェクト）まで設計できますか？
A. できません。Stitch で設計できるのはスケルトンUIの静止状態のビジュアルのみです。shimmerエフェクト（明るさが左から右へ流れるアニメーション）は、FigmaでSmartAnimateを使って表現するか、実装段階でCSS animationを適用するのが一般的です。Stitch はあくまで「スケルトンがどう見えるか」の見た目設計に使うツールと割り切って使いましょう。
Q. スケルトン画面はモバイル・デスクトップどちらで使うべきですか？
A. どちらでも有効ですが、特に有効なのはモバイルアプリです。モバイルはネットワーク速度が変動しやすく、読み込み時間が長くなりやすいため、スケルトン画面の効果が大きいです。デスクトップのWebアプリでも、コンテンツが多いページ（記事一覧・商品一覧など）にはスケルトンが有効です。
Q. スケルトン画面を使わない方がいいケースはありますか？
A. 読み込み時間が0.5秒以下のケースではスケルトン自体がチラつきの原因になるため、使わない方が自然なことがあります。また、コンテンツの形が毎回大きく変わる（何が来るか予測できない）ページでは、スケルトンのレイアウトとコンテンツのレイアウトが一致せず、かえって違和感が生じます。このような場合はスピナーが適切です。
Q. ダークモードでスケルトン画面のカラーはどう設定すればいいですか？
A. ダークモードのスケルトンでは、背景色より少し明るいグレーをプレースホルダーに使います。例：背景#111827なら、プレースホルダーは#1F2937〜#374151あたりが自然です。Stitch のプロンプトに「ダークモード、背景#111827、スケルトンプレースホルダー#374151」と指定することで、適切な配色が生成されます。
Q. スケルトン画面を設計するとき、実装担当エンジニアへの仕様の伝え方は？
A. Stitch で生成したスケルトン画面をFigmaにエクスポートし、各プレースホルダーのサイズ・カラー・角丸をFigmaのInspectパネルで確認できる状態にしておくと、エンジニアが実装しやすくなります。さらにDESIGN.mdにスケルトンのデザイントークン（プレースホルダーカラー・アニメーション速度など）を記述しておくと、一貫した実装につながります。
まとめ：待ち時間も「体験」として設計する
Google Stitch でスケルトン画面を設計してみて、「待ち時間のUI」に対する考え方が変わった。
ローディング中の画面は、ユーザーがプロダクトに触れている「確実な時間」だ。その時間を「何もない空白」にするか、「次に来るものへの期待」にするかは、設計者の選択にかかっている。
スケルトン画面は地味だ。コンテンツが表示されれば消えてしまう。ユーザーも意識しないかもしれない。でもその「気づかれない自然さ」こそが、良いスケルトン設計の証だと思っている。
次のステップ：自分のプロダクトで読み込み中に表示されているUIを確認し、スケルトン化できるページをリストアップしてみましょう。まずは最もよく使われるページ（ホーム・一覧画面）のスケルトンをStitchで設計するところから始めてみてください。
