スケルトンスクリーン

Skeleton Screen

web development beginner

読み込み中に、これから表示される内容の骨組みをグレーの図形で先に見せる表示手法のこと。

概要（サマリー）

スケルトンスクリーンとは、読み込み中に、これから表示される内容の骨組みをグレーの図形で先に見せる表示手法のことである。「スケルトン（skeleton）」は骨格という意味で、中身が届く前に器だけを先に置いておくイメージだと考えるとよい。

料理店で、注文した料理が来る前にお皿とカトラリーが並ぶのに似ている。まだ食べられないが、「何が来るか」「あとどれくらいの規模か」が分かるので、待っている感覚が和らぐ。SNSやニュースアプリを開いた直後に見える、灰色の四角がぼんやり光っている画面がこれである。

以下は、ボタンを押すとスケルトン表示から実際の内容へ切り替わるデモである。

詳細解説

スケルトンスクリーンとは何か

スケルトンスクリーンは、待ち時間そのものを短くする技術ではない。待ち時間の感じ方を変えるための表示手法である。

人は、何も情報がない状態で待たされると実際より長く感じる。空白の画面を3秒見せられるのと、これから出る内容の形が3秒見えているのとでは、後者のほうが短く感じられる。「もうすぐ来る」「こういう形のものが来る」という予告があるだけで、待つ側の不安が減るためだ。

ローディングスピナーとの違い

同じ「待ち時間の見せ方」でも、ローディングスピナーとは向いている場面が異なる。

スピナー: くるくる回るだけで、何が来るかは分からない。処理の内容や規模が事前に読めない場面に向く（保存中、送信中など）
スケルトン: 完成後のレイアウトが分かる。表示される形があらかじめ決まっている場面に向く（一覧、記事、プロフィールなど）

判断の目安は「読み込み後の形が事前に決まっているか」である。決まっているならスケルトン、決まっていないならスピナーがよい。また、待ち時間が1秒に満たないような場面では、どちらも出さないほうがちらつかず快適なこともある。

基本的な作り方

スケルトンは、灰色の四角に淡いアニメーションを付けるだけで作れる。CSSだけで完結する。

.skeleton {
  /* 左から右へ淡い光が流れる背景 */
  background: linear-gradient(90deg, #e9eef5 25%, #f5f8fb 37%, #e9eef5 63%);
  background-size: 400% 100%;
  animation: shimmer 1.4s ease infinite;
  border-radius: 6px;
}

@keyframes shimmer {
  0%   { background-position: 100% 50%; }
  100% { background-position: 0 50%; }
}

/* 文字1行ぶんの骨組み */
.skeleton-line   { height: 12px; margin-bottom: 8px; }
/* 丸いアイコンの骨組み */
.skeleton-avatar { width: 44px; height: 44px; border-radius: 50%; }

背景を実際の幅より大きく広げ、その位置を動かすことで「光が流れる」表現になる。技術的にはCSSアニメーションそのもので、特別な仕組みは要らない。

レイアウトをずらさないことが要点

スケルトンで最も大切なのは、骨組みと実際の内容の大きさを揃えることである。骨組みが小さすぎたり大きすぎたりすると、読み込み完了の瞬間に画面全体がガタッと動く。読もうとした行が突然下へ逃げる、押そうとしたボタンが動いて誤タップする、といった不快な体験につながる。

この「表示中に要素がずれる現象」は検索エンジンの評価指標にも含まれており、レイアウトの安定性として測定されている。スケルトンは本来ずれを防ぐための手法なので、寸法が合っていないと目的が逆転してしまう。骨組みの高さは、実際の文字サイズや行数から逆算して決めたい。

使いどころと避けどころ

向いているのは、次のような場面である。

記事一覧・商品一覧・タイムラインなど、繰り返しの構造が決まっているもの
プロフィールやダッシュボードなど、配置が固定されている画面
読み込みに1〜3秒程度かかることが分かっている場所

逆に避けたいのは次のような場面だ。

読み込みが一瞬で終わる場所。表示された途端に消えてちらつく
何件返ってくるか分からない検索結果。骨組みを5件出して結果が0件だと、期待を裏切る形になる
待ちが10秒を超えるような処理。骨組みが延々と光り続けると「固まった」と受け取られる。進捗が分かるプログレスバーのほうが適する

支援技術への配慮

灰色の四角は、目で見ている人には「読み込み中」と伝わるが、画面読み上げソフトを使う人には意味のない図形が並んでいるだけになる。次のような配慮を添えたい。

スケルトン部分に aria-hidden="true" を付け、読み上げ対象から外す
「読み込み中」であることを伝えるテキストを、視覚的に隠した形で置く
動きを減らす設定をしている人には、光るアニメーションを止める（prefers-reduced-motion を使う）

これらは数行で済むが、有無で体験が大きく変わる。アクセシビリティの観点でも、動きの制御は配慮すべき項目とされている。

NOVEBLOには、スケルトンスクリーンの実装手順をまとめたページがある。

AIコーディングとの関係

スケルトンスクリーンは見た目が単純なぶん、AIに頼むと「それらしい灰色の四角」はすぐ出てくる。ただし、実際の内容と寸法が合っているかまでは面倒を見てくれない。次の情報を渡すとよい。

実際の要素の寸法（アイコンは44px四方、本文は3行、など）
繰り返す件数（一覧なら何件ぶん出すか）
アニメーションの有無と、動きを減らす設定への対応
支援技術向けの扱い（aria-hidden を付けるか）

たとえば「記事カードのスケルトンを作って。左に44px四方の丸、右に見出し1行と日付1行、下に本文3行ぶん。カードは3件並べて。prefers-reduced-motion のときは光るアニメーションを止めて」と伝えると、そのまま使える形に近づく。

確認したいのは切り替わった瞬間のずれである。実データを流し込んだうえで骨組みと見比べ、行の位置が動かないかを見てほしい。ここが合っていないスケルトンは、無いほうがましなことすらある。

よくある勘違い

スケルトンを出せば表示が速くなる？

表示速度そのものは1ミリ秒も変わらない。変わるのは待っている側の体感である。読み込みが遅い根本原因（画像が重い、APIが遅いなど）を放置したままスケルトンをかぶせても、遅いことに変わりはない。あくまで体感を補う手当てである。

スケルトンはローディングスピナーの上位互換？

用途が違う。完成後の形が決まっていない処理（保存、送信、集計など）にスケルトンは使えない。形が読める場面ならスケルトン、読めない場面ならスピナー、と使い分けるものである。

とりあえず全部の読み込みに付ければよい？

読み込みが一瞬で終わる場所に置くと、表示されてすぐ消える「ちらつき」になり、かえって落ち着かない画面になる。一定時間（たとえば300ミリ秒）を超えたときだけ表示する、という制御を入れると自然になる。

灰色の四角なら中身は適当でよい？

寸法が実物と合っていないと、切り替わった瞬間にレイアウトがずれる。ずれを防ぐことがスケルトンの主目的の1つなので、ここを適当にすると導入の意味が半減する。

まとめ

スケルトンスクリーンは、読み込み中に完成後の骨組みを灰色の図形で先に見せる手法である
速度は変わらないが、何が来るか予告することで待ち時間の体感を短くする
形が決まっている画面はスケルトン、決まっていない処理はローディングスピナーが向く
骨組みと実際の内容の寸法を揃え、切り替わった瞬間にレイアウトをずらさないことが要点である
aria-hidden や動きを減らす設定への対応を添えると、より多くの人にとって扱いやすくなる

情報ソース

より詳しくAIに聞いてみよう

スケルトンスクリーンとローディングスピナーの使い分けを、具体的な画面例つきで整理してください。
スケルトンの骨組みと実際の内容で寸法を揃えるには、どう寸法を決めればよいですか。
読み込みが速いときにスケルトンがちらつく問題を防ぐ実装方法を教えてください。
スケルトンスクリーンを支援技術に配慮した形にするには、どんな属性や工夫が必要ですか。
AIにスケルトンスクリーンのCSSを生成してもらうとき、レイアウトのずれを防ぐにはどう指示すればよいですか。