レスポンスと待ち時間設計 (Response Latency)

ボタンを押した。画面が固まった。もう一度押した。まだ動かない——これは「遅い」のではなく、「何が起きているかわからない」という体験です。人間は待つことができます。しかし、いつまで待てばいいかわからない待ち時間には耐えられません。

よくある失敗パターンは「送信ボタンを押したら画面が真っ白になった」です。処理中なのか、フリーズしたのか、成功したのか、失敗したのか——ユーザーには何もわかりません。不安になって連打し、二重送信が発生します。あるいは「Loading...」の文字だけが表示され、あと何秒待てばいいのかわからない。ユーザーは待つことをやめて離脱します。

待ち時間設計が崩れたUIは、ユーザーを「時間の感覚を失った状態」に放置します。それは不安・不信・離脱の温床です。

1. 原則の定義

レスポンスと待ち時間設計（Response Latency）とは、ユーザーの操作に対してシステムが適切なタイミングで反応を返し、待ち時間の長さに応じた適切なフィードバック（即時変化・スピナー・スケルトン・プログレスバー）を提供することで、体感速度を最適化する設計原則。

本質は「速くすること」ではなく、「待たされている感を消すこと」です。物理的な処理速度を改善するのはエンジニアの仕事ですが、ユーザーが感じる体感速度を設計するのはUIデザインの仕事です。同じ3秒でも、何も表示されない3秒と、スケルトンが表示されている3秒では、ユーザーの体験はまったく異なります。

2. いつ使うか（適用場面）

特に重要になるケース

• 非同期処理全般: API呼び出し・ファイルアップロード・検索・フォーム送信など、結果が即座に返らないすべての操作。
• モバイル・低速回線環境: 通信速度が不安定な環境では、同じ処理でも待ち時間が伸びる。スケルトンスクリーンや楽観的UIが特に効果的。
• 初回ロード・ページ遷移: コンテンツが大量にある場合、ページ全体が表示されるまでの間に何を見せるかが体験を左右する。
• 連続操作が発生するUI: 検索フィルター・ソート・タブ切り替えなど、ユーザーが繰り返し操作する場面では、毎回の応答速度が積み重なってUXを決定する。

トレードオフが起きる場面

• 楽観的UIのリスク: 処理が失敗した場合の「巻き戻し」が複雑になる。決済・削除など失敗の影響が大きい操作には慎重に適用する。
• スケルトンの過剰使用: 処理が0.5秒未満で完了する場合にスケルトンを表示すると、一瞬ちらついて逆に不快感を与える。短い処理にはスピナーの方が適切なことが多い。

3. なぜ重要か（設計判断の核）

待ち時間設計は「速くする」技術ではなく、「待たされている感を消す」設計である。

設計判断の基準

• 「この操作の後、ユーザーは0.1秒以内に何かが変わったと知覚できるか？」→ できなければ即時フィードバック（ボタンの色変化・スピナー開始）を追加する。
• 「処理が3秒以上かかる場合、ユーザーはあと何秒待てばいいか見当がつくか？」→ つかなければプログレスバーか残り時間の目安を表示する。

優先順位の考え方

• 1. 0.1秒以内の即時反応（最優先）: 操作を受け付けたことを示す視覚変化（ボタンの押し込み・色変化・スピナー開始）。これがなければ他のすべてが無意味。
• 2. 1〜3秒の処理中表示: スピナーまたはスケルトンスクリーンで「処理中」を示す。
• 3. 3秒以上の進捗表示: プログレスバーと残り時間の目安で「終わりが見える」状態にする。

例外条件

• 自動保存など、バックグラウンドで頻繁に走る処理は毎回通知しない。「最終保存：2分前」のような控えめな表示で十分。
• 処理が速すぎる（0.1秒未満）場合、あえて短いアニメーションを入れて「処理した感」を演出することがある（人工的な待機時間）。

4. 具体の設計ルール（チェックリスト）

最低ライン（Must - これ守らないと危険）

これがないと、ユーザーは操作が受け付けられたかどうかすら確認できません。

操作への即時反応があるか: ボタンクリック後0.1秒以内に視覚変化（色変化・スピナー開始・ボタン無効化）が起きるか？何も変わらない「無反応」状態になっていないか？
処理中状態が表示されているか: 1秒以上かかる処理では、スピナー・スケルトン・プログレスバーのいずれかで「処理中」を示しているか？ボタンは二重送信を防ぐため無効化されているか？
完了・失敗が明確に伝わるか: 処理が終わった後、成功なのか失敗なのかが一目でわかるか？エラー時は「何が失敗したか」「どうすれば直るか」まで伝えているか？

理想ライン（Better - できると強い/プロの品質）

「安心して待てる」「速く感じる」状態です。

待ち時間の長さに応じた表示を使い分けているか: 0.4秒未満は即時反応のみ、1〜3秒はスピナーまたはスケルトン、3秒以上はプログレスバー＋残り時間の目安、という使い分けができているか？
楽観的UIを適切に活用しているか: 「いいね」「ブックマーク」など失敗の影響が小さい操作では、サーバーレスポンスを待たずに即座にUI更新し、体感速度を0秒にしているか？
スケルトンスクリーンのレイアウトが実際のコンテンツと一致しているか: スケルトンが表示されてからコンテンツが表示される際に、レイアウトのガタつき（Layout Shift）が発生していないか？

5. UI例

同じ「データ読み込み」でも、待ち時間の見せ方でユーザー体験は大きく変わります。

改善プロセス

1. 処理時間を計測する: 実際のAPIレスポンスタイムを計測し、「0.4秒未満」「1〜3秒」「3秒以上」のどのゾーンに入るかを把握する。ゾーンによって適切な表示手法が変わる。
2. 即時反応を最優先で実装する: どんな処理でも、ボタンを押した瞬間（0.1秒以内）に何かが変わるようにする。最低限ボタンを無効化してスピナーを表示するだけでよい。
3. 楽観的UIの適用範囲を決める: 「いいね」「ブックマーク」「既読マーク」など、失敗しても影響が小さい操作をリストアップし、楽観的UIを適用する。決済・削除・送信など影響が大きい操作は対象外にする。

6. 関連リンク

• 関連リファレンス（理論）: ドハティの閾値
• 用語集（定義）: レイテンシ (遅延), スケルトンスクリーン, プログレスバー
• 関連するUI原則（横）: フィードバック (Feedback), 状態の可視化 (Visibility of System Status)

7. まとめ

今日から直せる一手 担当しているサービスのAPIリクエストを一つ選び、レスポンスを受け取るまでの間にスピナーが表示されているか確認してください。表示されていなければ、ボタンのクリックハンドラーの先頭に「ローディング状態をtrueにする」一行を追加するだけで、ユーザーの不安は大きく減ります。

チームに共有するなら一言 「ユーザーは3秒待てる。でも、あと何秒待てばいいかわからない3秒には耐えられない。」