AIで作ったあなたのアプリが遅く感じる理由（と、その対処法）

あなたがAIで作ったアプリは動きます。ボタンはあるべきところに行き、画面はそろい、データは保存される。でも、何かがしっくりこない。ページの読み込みにほんの少し時間がかかる。50項目のリストが一瞬固まる。「保存」をクリックすると待たされ、もう少し待たされ、もう一度クリックしたほうがいいのかと思い始める。何も壊れていない — ただ遅く感じるのです。

AIアプリビルダー でリリースする非エンジニアの創業者なら、これは最もよくある「何が悪いのか分からない」瞬間の一つです。良い知らせは、遅いAIで作ったアプリの80%は、同じ一握りの理由で遅いということです。そのどれも、データベースの仕組みを学ぶ必要はありません。どれも、AIビルダーに平易な言葉で頼める対処法があります。

この記事が、そのカンニングペーパーです。

なぜ「遅い」はたいてい4つのことなのか

ユーザーがアプリを遅いと言うとき、彼らはほぼ決して「サーバーが非力だ」という意味で言っているのではありません。次の4つのうちの一つを指しています。

最初の描画が遅い — リンクをクリックして、何かが現れるまで2秒間、真っ白な画面を見つめる。
長いリストがもっさりする — スクロール、フィルター、「全プロジェクトを読み込む」が、Instagramをスクロールするより時間がかかる。
アクションが、何が起きているか伝えないまま長くかかる — 「保存」や「送信」をクリックしても、目に見える反応がない。
データベースに質問しすぎている — 複数の場所のデータを表示するページが、それぞれを別々に取得し、待ち時間を積み重ねる。

それだけです。私が見てきた遅いAIで作ったアプリのほぼすべてが、その4つのうちの一つで遅くなっています。それぞれの見分け方と、ビルダーに頼むべきことを解説します。

遅い理由 #1：最初の描画

どう見えるか：アプリへのリンクをクリックすると、URLバーの読み込みは終わるのに、何かが現れるまで1〜2秒、ページが真っ白になる。

たいていの原因：アプリが、何かを見せる前に、必要かもしれないあらゆるJavaScriptを読み込んでいる。AIアプリビルダーは気前よくまとめる傾向があり — 含め損ねるより含めたほうがいい — そのまとまりは、機能を足すほど大きくなります。

AIビルダーに頼むこと：「最初のページ読み込みが遅く感じる。ホームページが管理セクション全部をダウンロードしなくて済むように、JavaScriptのバンドルをルートごとに分割できる？」あるいは、もっと簡単に：「ホームページ以外のルートに遅延読み込みを追加して。」 ほとんどのモダンなフレームワークは、これを1〜2行の設定でサポートします。AIはやり方を知っています — あなたはただ頼めばいいのです。

ついでに：「ランディングページに、最適化できそうな大きな画像はある？」 4MBのヒーロー画像は、どんなコードの問題よりも、体感速度を台無しにします。

遅い理由 #2：長いリスト

どう見えるか：リスト — プロジェクト、連絡先、投稿、何でも — があって、40〜50項目を超えると、スクロールがガクつく、あるいはフィルターに目に見えて間が空く。

たいていの原因：アプリが、見えていないものまで含めて、すべての項目をページに一度に描画している。10項目なら問題ありません。500だと、ブラウザが詰まります。

AIビルダーに頼むこと：「項目が多いとプロジェクトのリストが遅い。ページネーションを足すか、見えている行だけ描画するようにリストを仮想化できる？」 ページネーション（「1ページに20件、次へ／前へボタン付き」）がいちばん簡単な対処です。仮想化（「ユーザーがスクロールするにつれ画面にあるものだけ描画する」）はより滑らかに感じますが、少し手間がかかります。どちらでも構いません。

リストに検索やフィルターもあるなら：「検索フィルターを、ブラウザではなくサーバーで処理できる？」 サーバー側のフィルターなら、ブラウザは一致する行だけを抱え、データセット全体を抱えずに済みます。

遅い理由 #3：無言の待ち

どう見えるか：「保存」「送信」「生成」をクリックする。目に見えて何も起きない。2秒後に画面が更新され、ずっと処理していたのだと気づく。

たいていの原因：アプリは実際に仕事をしている — データベースへの保存、APIの呼び出し — のに、AIビルダーがローディング状態を足さなかった。だから、あなたの視点では、クリックは何もしなかったように見える。

これは実は性能の問題ではありません。体感の 性能の問題で、そういうものは本物のものより痛いことがよくあります。フィードバックのない200ミリ秒のアクションは、スピナーのある2秒のアクションより遅く感じます。ユーザーの頭の中が真っ暗だからです。

AIビルダーに頼むこと：「アクションを起こすすべてのボタンにローディング状態を足して。処理中はスピナーか『保存中…』のテキストを表示して、ユーザーがダブルクリックできないようにボタンを無効化して。」これは、どんなアプリでも費用対効果が最も高い性能対策で、コストはほぼゼロです。

ついでに：「結果が分かっているアクションについては、UIを楽観的に更新できる — 変更を即座に表示して、サーバーが拒否したら巻き戻す？」 楽観的更新は、電波が最悪のときでもSNSアプリの「いいね」ボタンが即座に感じる理由です。

遅い理由 #4：おしゃべりなデータベース

どう見えるか：項目のリストを表示するページで、それぞれに追加情報が付いている — 各プロジェクトのタスク数が付いたプロジェクト一覧のような — のが、ただのリストよりずっと読み込みに時間がかかる。

たいていの原因：ページが、プロジェクトを1つのクエリで読み込み、それから各プロジェクトのタスク数を別々のクエリで読み込んでいる。プロジェクト10個？クエリ11個。100個？101個。これは「N+1クエリ」と呼ばれ、AIで作ったアプリで最もよくあるデータベースの性能バグです。AIが、効率よく動くコードではなく、はっきり 読める コードに最適化しているからです。

AIビルダーに頼むこと：「このページが項目ごとに1クエリを投げている。関連データを全部1つのクエリで取得できる — joinか集計で？」 どちらの言葉の意味も知る必要はありません。AIは知っています。遅いページを見せて「これN+1問題だと思う」と言えば、たいていそれで十分です。

N+1問題は、ツールなしで見つけられます。ページを開いて、どれくらいかかるか数え、それから元のリストに10倍の項目を足してみましょう。ページが今や10倍遅くなったら、N+1があります。ほんの少し遅くなっただけなら、ありません。

早すぎる最適化について一言

新しいビルダーが陥る罠：誰も使う前から、すべてのページを速くしようとすること。やめましょう。

性能の作業には本物のコストがあります。一生20行しか持たないリストにページネーションを足すのは無駄な労力です。一日に2回読み込まれるページを最適化するのは無駄な労力です。ユーザー3人の社内ツールのためにバンドルを分割するのは無駄な労力です。遅いページを直す正しいタイミングは、そのページ、そのアクション、そしてそれにいら立った人を名指しできるときです。

だから、まずは普通に作りましょう。リリースしましょう。どう使われるか観察しましょう。本物の人 — あなた自身も含め — が何かを遅いと感じたら、その症状を上の4つのカテゴリのどれかに当てはめ、その具体的な対処を頼みましょう。ユーザーが決して気づかないインフラに一週間を費やすことなく、より速いアプリが手に入ります。

速さについてAIビルダーに伝える方法

うまくいくパターン：解決策 ではなく症状を説明すること。AIは、本当に何が悪いのかさえ分かれば、あなたが思うよりずっと上手に正しい対処を選びます。

コピーして使える良いプロンプト：

「設定ページを開くと、何かが現れるまで1秒の遅れがある。最初の描画を妨げているものを突き止められる？」
「ダッシュボードのほうが表示するデータは少ないのに、ホームページより読み込みに時間がかかる。どうやってデータを取得しているか見てもらえる？」
「プロフィールページで『変更を保存』をクリックすると、2秒間何も起きない。ローディング状態を足して、ボタンがダブルクリックできないようにして。」
「このリストを500件の偽の項目でテストして、どこで遅くなるか教えて。」

最後のは過小評価されています。AIにテストデータを生成させ、ページ自体を試させるのは、あなたができる最も役立つことの一つです。たいてい、ユーザーより先に遅い箇所を見つけ — 同じ返答の中で対処を提案してくれます。

AIで作ったアプリの速さは、魔法の話ではありません。自分の問題が4つのバケツのどれに入るかを知り、はっきりした言葉で正しい対処を頼むことです。それをやれば、「遅く感じる」は、一握りの小さな的を絞った変更で「快適に感じる」になります — 作り直しではなく。