AIで作ったアプリが遅く感じる理由（実際は速いのに）：待ち時間という錯覚

あなたのアプリはデータを1.2秒で取得する。人間が知覚できるのは100ミリ秒だ。人間の知覚より12倍も速いのに、それでも「遅い」と_感じられる_。なぜか。

体感速度（perceived latency）——アプリを使う人がどれだけ遅いと感じるか——は、実際の読み込み時間とはほとんど関係がない。重要なのは、待っている間にユーザーが「何が起きているか理解できているか」だ。速い・遅いは嘘で、本当に意味を持つのはフィードバックの有無である。

なぜ実際は速いのにアプリが遅く感じるのか？

アプリが遅く感じるのは、待ち時間の長さそのものではなく、待っている_間_に何が起きているかのせいだ。原因は主に3つある。読み込み中にフィードバックがないこと、レイアウトの見えない白紙画面、そして長い処理での進捗感の欠如だ。

1. 待機中にフィードバックがない

フォームを送信する。ボタンは非活性になる（これは標準的な作法で、二重クリックを防ぐためだ）。それ以外は何も起こらない。1秒が過ぎる。2秒が過ぎる。ユーザーには、処理中なのか、固まっているのか、ネット接続が切れたのか、クラッシュしたのか分からない。2秒間の沈黙の後、人間の脳はタブを閉じることを考え始める。

これが、1.2秒という実際には妥当な処理時間でも遅く感じられる理由だ。ユーザーの不安が沈黙を埋めてしまう。

2. 白紙画面

ページが読み込まれる。見出しは表示される。だがその下のリストを取得する間、800ミリ秒間何も起こらない。ページは壊れているように見える——不完全なレイアウト、プレースホルダーもなく、ただ……読み込み中。800ミリ秒の待ちが、体感5秒の停止に変わる。ユーザーの目は「不完全さ」を「失敗」として認識するからだ。

3. 進捗感がない

長い処理が始まる。「読み込み中……」と表示される。それから？ 10%なのか90%なのか。コーヒーを淹れる時間があるのか、それとも3秒で終わるのか。進捗が分からないことが不安を生む。速いのに謎めいている状態は、遅くても透明な状態より遅く感じられる。

遅く感じるアプリはどう直せばいいのか？

上で挙げた3つの原因には、それぞれ対応する解決策がある。ユーザーが操作した瞬間にフィードバックを見せること、データ読み込み中の空白をプレースホルダーで埋めること、そして数秒以上かかる処理には実際の進捗を表示することだ。

解決策1 — すぐに何かを見せる

データ取得の_前に_、ローディング状態を用意する。スケルトン画面、スピナー、「考え中……」というメッセージ——何でもいい。「タップは受け取った、今処理している」と伝えるものならそれでいい。

例：予約フォームを送信する。ボタンのテキストが即座に「空き状況を確認中……」に変わり、小さなスピナーが表示される。そこで初めてデータ取得が始まる。実際の処理には1.2秒かかっているにもかかわらず、ユーザーは自分の操作への反応を_即座に_目にする。この即時フィードバックが、待ち時間を短く感じさせる。

ビルダーへの指示： ユーザーがメインボタンをクリックしたら、リクエストを送る前にボタンのテキストを変更し、ローディング状態を追加する。指示としてはこれ一つで済む。

テスト： スマートフォンで実際に操作してみる。フィードバックは100ミリ秒以内に表示されるべきだ。ローディング状態の前に500ミリ秒の沈黙があれば、ユーザーはそれをアプリのせいだと感じる。

解決策2 — 空白を埋める

隅に「読み込み中……」とだけ表示された白い画面ではなく、これから表示されるものの「形」を見せる。

実例： あるウェディングプランナーの予約アプリが、予約可能な日付のリストを取得していた。白紙のページの代わりに、日付が表示される場所にグレーの長方形を5つ、プレースホルダーとして表示する。実際の日付が読み込まれると、それらと差し替わる。ユーザーの脳はこれを「瞬時」と認識する——なぜならページが一度も「不完全」に見えなかったからだ。

ビルダーへの指示： 実際のデータを取得する_前に_、リストやテーブルのプレースホルダー（スケルトン）版を追加する。データが届いたら、スケルトンを実際のコンテンツに置き換える。確かにこれは一手間多くかかる。だが体感の待ち時間を半分に減らせる価値がある。

テスト： 低速な回線（モバイル、4Gに制限）でページを読み込む。白紙が見えるか、それとも「形」が見えるか。「形」が見える方が勝ちだ。

解決策3 — 進捗を見せる

3秒を超える処理には、どこまで進んだかを表示する。

実例： あるフォームが500行のデータをスプレッドシートに書き出す。これには4秒かかる。進捗表示なしの場合：「エクスポート中……」（15秒に感じられ、ユーザーはキャンセルする）。進捗表示ありの場合：「500行中127行をエクスポート中」（200ミリ秒ごとに更新され、実際の処理時間は変わらないのに2秒程度に感じられる）。

正直に言うべき落とし穴： どれくらい時間がかかるか本当に分からない場合、進捗バーを偽ってはいけない。67%で止まったままの偽の進捗バーは、正直な「処理中です」というフィードバックよりも信頼を裏切る。計算できるなら、本物の進捗表示は偽の進捗表示に常に勝る。

ビルダーへの指示： 2秒を超える処理には、進捗の更新を発信する。ファイルのアップロードなら、何MB送信済みかを表示する。リストの取得なら「50件読み込み済み、続けて取得中……」と表示する。合計数が分からなくても、「何かが進行している」と分かるだけで体感は変わる。

テスト： ネットワークを3Gまで落として見てみる。止まっているように感じるか、それとも進んでいるように感じるか。

アプリが遅く感じるかどうかはどうテストすればいいのか？

「他人テスト」を実施しよう。自分以外の誰かのスマートフォンでアプリを立ち上げ、手を貸さずにメインの操作をタップしてもらい、速く感じたか遅く感じたかを聞く。

「遅い」と言われたら、次の3点を確認する。

100ミリ秒以内に何かフィードバックが見えたか？（テキストの変化、スピナー、状態の変化）
待っている間、ページの「形」が見えたか？（スケルトン、プレースホルダー、何かしらのもの）
どこまで進んでいるか分かったか？（3秒を超える待ちの場合）

どれか一つでも「いいえ」なら、まずそこから直す。

速さとは数字ではない。フィードバックが一切ない1.2秒のAPI呼び出しは、0.5秒ごとに進捗が見える3秒の処理よりも遅く_感じられる_。違いを生んでいるのはアプリそのものではなく、アプリと使う人との間の「会話」だ。

フィードバックを直そう。何が起きているかを理解できれば、人は「遅い」とアプリを責めなくなる。