AIで作ったアプリが話題になった。アクセス集中に耐えられますか？

最高にうれしい「最悪の日」を想像してみてください。参加しているコミュニティでAIで作ったアプリを投稿したら、あるいはフォロワーの多い誰かが試してシェアしてくれたら、はたまた自分では投稿すらしていないフォーラムのトップページに載ったら。いつもはぽつぽつとしか来ない訪問者が、突然の洪水になります。千人が、同じ1時間のうちにあちこちをクリックしているのです。

これこそ、あなたがそのアプリを作った理由となる瞬間です。そしてそれは、多くのAI製アプリがひっそりと倒れてしまう瞬間でもあります — ページが重い、ローダーがぐるぐる回り続ける、登録フォームが送信できない。せっかく来てくれた人たちは壁にぶつかって去っていき、その大半は二度と試しに戻ってこないのです。

うれしい知らせもあります。アクセス集中を乗り切るというのは、その大半が、集中が起きる前にできる、いくつかの地味な判断にかかっているということです。エンジニアである必要はありません。どこで手を抜いてはいけないかを知っていればいいのです。

アクセスが急増すると、実際には何が壊れるのか

普段の100倍の人が一度にアプリを使うとき、物事はランダムに壊れるわけではありません。決まった順番で壊れ、しかもそれはほぼいつも同じ3か所です。

データベースが処理しきれなくなる。 誰かがページを読み込むたび、アプリはたいていデータベースに問いかけます。「このユーザーのデータは何か？」と。一人が問いかけるだけなら何でもありません。けれど千人が同じ問いを同じ1分間に投げかけると、データベースが答えられるよりも速く積み上がってしまい、全員のページが這うように遅くなります。

アプリの外にある何かが遅くなる。 ほとんどのAI製アプリは、ほかのサービスに頼っています — メールの送信、決済処理、AIモデルの呼び出し。これらのサービスは、呼び出せる速さに上限を設けていることがよくあります。通常のアクセスでは、その上限に気づくことはありません。けれど集中時には、アプリがその上限に達し、突然そのサービスに関わるすべての操作が止まってしまうのです。

アプリが同じ重い処理を何度も何度も繰り返す。 もしホームページが、誰かが訪れるたびに毎回重い計算を走らせているなら — リストを取得し、並べ替え、整形する — それは10人の訪問者なら問題なくても、千人には過酷です。その処理はもともと無駄なものでした。アクセスが少ないあいだ、それが隠れていただけなのです。

ここにあるパターンに注目してください。これらはどれも新しいバグではありません。アクセス集中が何かを壊したわけではないのです。それは、低アクセスのもとでひっそりと潜んでいた、もともとあった弱点をあらわにしただけなのです。

いちばん安上がりな対策：変わらないものをキャッシュする

キャッシュというと専門的に聞こえますが、考え方はシンプルです。もし問いへの答えが誰にとっても同じで、めったに変わらないなら、一度だけ計算して、訪問者ごとに処理をやり直す代わりにそれを再利用すればいいのです。

あなたのホームページは、おそらく訪れる1,000人全員に同じように見えています。なら、なぜデータベースにそれを1,000回も組み立て直させるのでしょう？一度だけ組み立てて、その結果を数分間だけ保存し、その保存済みのコピーを全員に配ればいい。これで、千回もの高コストなデータベース往復が、たった一度になります。

AIビルダーにはこう、そのまま伝えましょう。「ホームページと公開の商品リストを5分間キャッシュして、訪問のたびにデータベースに当たらないようにして」と。誰にとっても同じで、1秒単位の最新である必要のないもの — 料金ページ、公開のリスト、ブログの一覧 — は、すべてキャッシュの候補です。個人向けのもの（誰かの自分のダッシュボード、その人のアカウント設定）は同じようにはキャッシュできませんが、それはたいてい集中時のアクセスのうちのごく一部です。ほとんどの人は、同じいくつかの公開ページを見ているのです。

あとからでもできることを、人に待たせない

これは、やってしまいがちで、なおかつ直しやすいミスです。たとえば誰かが登録すると、アプリがその人にウェルカムメールを送るとします。もしアプリが、メールが完全に送信されるまで登録ページで待たせるのなら、メールサービスが遅いと登録も遅くなります — しかも、いちばん多くの人が登録している、まさにその瞬間に。

対策は、遅い処理を裏側で進ませることです。その人には即座に「登録完了！」が表示され、メールは誰も待たされることなく数秒後に送られていきます。結果は同じですが、訪問者は、3社向こうにあるメールサーバーがのんびり仕事をしているあいだ、ぐるぐる回るスピナーを見つめずに済むのです。

ビルダーにこう頼みましょう。「ウェルカムメールは裏側で送って、登録がそれを待たないようにして」。同じ理屈は、その人が先に進む前に終わっている必要のないものすべてに当てはまります — レポートの生成、別のツールへの同期、通知の送信。ユーザーがその結果を今すぐ必要としていないなら、それを待たせてはいけません。

「人が多すぎる」ときのプランを持っておく

ときには、用意していたどんな備えよりも集中が大きくなることがあります。そんなときの誠実な一手は、崩壊するのではなく、上品に機能を落とすことです。それでも動く遅いアプリは、壊れたアプリに勝ります。

そのいくつかのシンプルなやり方を挙げます。

やさしい待機メッセージ。 本当に何かが過負荷になっているなら、「ただいまたくさんの方にアクセスいただいています — 少々お待ちください」と表示するほうが、真っ白な画面や生のエラーよりもはるかにましです。人は混み合ったアプリを許してくれます。けれど壊れたアプリは許してくれません。
いちばん重い機能を一時的に止める。 もしある機能が高コストなもの — たとえば、クリックごとに実際のお金と時間がかかるAI生成 — であれば、急増のあいだはそれを隠して、アプリの残りを軽快に保てます。集中時の訪問者のほとんどは、いちばん負荷の重い機能を使うのではなく、どのみち眺めているだけなのです。
どこから請求が来るのかを知っておく。 もしアプリが訪問のたびに有料のAIモデルを呼んでいるなら、千人の訪問者は、ただページが遅くなるだけでなく、思わぬ請求を意味することがあります。どの操作にお金がかかるかを知っておけば、何に上限をかけるかを前もって決められます。

30分のリハーサル

弱点を見つけるのに、立派なツールは要りません。必要なのは、数人の友人と30分です。

5人か6人に、同じ瞬間にアプリを開いてもらい、数分間しっかりとあちこちクリックしてもらいましょう — 登録して、メイン機能を使い、混み合うページを読み込む。荒っぽいやり方ですが、わかりやすい問題をすばやくあぶり出してくれます。もし6人が叩いただけでアプリがもうもたついて感じるなら、千人なら押しつぶされます。もしキビキビしたままなら、少なくとも最低限のハードルはクリアしています。

彼らがクリックしているあいだ、どのページがいちばん遅く感じるかを観察してください。その遅いページこそ、本物のアクセス集中がいちばん痛手になるところであり、まず最初にキャッシュや簡素化を考える価値のある場所です。千人のユーザーをシミュレートしようとしているのではありません。6人ですでに苦しんでいる、その1ページを見つけようとしているのです。

本当の狙い

アプリを無限に鉄壁にすることはできませんし、その必要もありません。狙いは、初めてのバズの瞬間に1万人を完璧にさばくことではありません。せっかく来てくれた数百人の前で恥をかかないこと — あれほど苦労して引き寄せた人たちに、ぐるぐる回るホイールではなく、ちゃんと動くアプリを届けることなのです。

変わらないページはキャッシュする。遅い処理は裏側に回す。「人が多すぎる」ときのプランを持っておく。必要になる前に、友人5人でのリハーサルをやっておく。そのどれも、自分でコードを書く必要はありません — ただ、AIビルダーに何を頼めばいいかを知っていればいいのです。

そうすれば、いざあなたの瞬間が訪れたとき、必死にデバッグするのではなく、それを楽しめるようになります。だから今週、腰を据えて考える価値のある問いはこうです。もし明日、千人が押し寄せたら、どのページが最初に壊れるか — そして、あなたはもうそれを知っていますか？