Vercel だけ東京にしても、まだ遅かった。データベースがムンバイにいたから

日本向けのアプリが、なんだかもっさりしている。そういう時、最初に疑うのは Vercel の実行場所でした。

Vercel の関数は、何も書かないと アメリカ東海岸（iad1） で動きます。日本からの通信は、まず太平洋を渡る。これを東京（hnd1）に変えるだけで、驚くほど速くなる。実際、そうでした。

でも、それだけでは終わらなかった、という話です。

vercel.json に "regions": ["hnd1"] を1行足すだけです。short-maker というアプリで測ると、こうでした。

測る時の注意が1つ。静的なページやキャッシュから返るページで測ると、どこで動いていても速く見えます。必ず動的なルートに curl -sD- -o /dev/null を投げて、返事の x-vercel-id の2つ目を見ます。iad1 なら米国、hnd1 なら東京です。静的なページで測って「速い」と言ったら誤診です。

東京にしても、まだ遅いアプリがある。調べると、データベースが別の場所にいました。

うちの複数のアプリが、ひとつの共有の Supabase（データベースを貸してくれるサービス）を使っていました。そのリージョンを supabase projects list で見ると、ムンバイ（ap-south-1）。インドです。

関数が東京にいても、データを読むたびに東京からインドまで往復します。日本からムンバイの認証の窓口を5回叩いて測ったら、1回 0.25〜0.37秒。

1回の往復なら、0.3秒ほどです。困るのは、往復が重なる時でした。迷子札のアプリ（NFCドッグタグ）で、タグへの書き込み1回あたりの通信を数えたら、約25往復。単純に掛け算すると 6〜9秒分になります（これは計算で、書き込み全体の時間を測った数字ではありません）。

そこで 2026-10-08、この迷子札アプリのデータだけを、東京の新しいプロジェクトへ移しています。拾った人が開くページの表示は、移す前の 0.31〜0.73秒 から、移した後の 0.20〜0.29秒 に。この日に測った数字で、今の速さを保証するものではありません。

全部は移していません。ログインだけは、ムンバイのままです。配布済みの iOS アプリが、ログインの URL を中に持っているからです。アプリを更新しないと、ログインは動かせません。

データだけ東京に移し、サーバーはログインの印（トークン）の署名を、元の鍵でその場で確かめます。合わない時は拒まず、本来の確認に回す。鍵を間違えて全員を締め出す事故を避けるためです。

もう1つ。「元に戻す」が使えなくなります。Vercel の「前の版に戻す」を押すと、データの向き先もムンバイに戻って、東京で増えたデータが見えなくなる。なので、ムンバイ側の表は消さずに残す。戻すなら、差分を写してから。そう決めています。

恥ずかしい話が1つあります。

うちのアプリが全部で何本、いまも実行場所が米国のままなのかは、数えていません。東京にする決まりは全アプリが対象ですが、既存のものを1本ずつ x-vercel-id で測り直してはいません。

言えるのは、Vercel だけ東京にして安心すると、データベースが遠くに残る、ということ。関数とデータベースの両方が東京にいて、はじめて往復が最短になります。次は、いまのアプリを1本ずつ x-vercel-id で測って、結果をここに足します。ほかの作品は 制作実績、開発の記録は ブログ にまとめています。