要点
- 見本カードが出ない検査の失敗に対し、画面のコンソールのエラーは0件だった（出典: 自社の実測・2026-10-16）
- 関数の応答に約18秒かかった回があり、画面側の締め切りは15秒だった（出典: 自社の実測・2026-10-16）
- 取得を1度だけやり直し、「本当に0件」と「読めなかった」を別の表示にした（出典: 自社の実測・2026-10-16）
- 修正後は、最初の通信だけを落としてもカードが表示され、取得は2回だった（出典: 自社の実測・2026-10-16）
ログイン前の訪問者に、見本カードを届けたかった
英語学習アプリ Words Admin では、ログインしていない訪問者に見本のカードを3枚表示している。カードを返すのは、Firebase の Cloud Functions だ。呼ばれたときだけ動くサーバーレスの関数を、見本の取得に使っていた。
今回のコールドスタートとは、呼ばれていなかった関数が冷えた状態から起動することだ。
問題は、主要な導線を毎日自動で通す検査で見つかった。検査は25段のうち24段まで通り、「ログインしていない訪問者に、45秒以内に見本カードが出ない」という段で落ちた。
そのとき、画面のコンソールに出ていたエラーは0件だった。通信の打ち切りが静かに起きるため、コンソールのエラーを見ているだけでは、この失敗に気づけなかった。一方で、訪問者が見る画面にはカードがなく、「混み合っています」だけが表示されていた。
確かめるべきだったのは、エラーの有無だけではない。ログインせずに訪れた人へ、見本を実際に届けられたかどうかだった。
出典: 自社の実測（2026-10-16）
関数の時間と、画面側の締め切りを照らし合わせた
落ちた回の直前、関数は5時間呼ばれていなかった。その回について、起動から実行開始、応答までの時間を調べ、画面側が待つ時間と比較した。記録の値は次のとおりだ。
| 測ったもの | 結果 |
|---|---|
| その回の 起動→実行開始→応答 | 約18秒 |
| 同じ日のもう1回の 起動→実行開始 | 26.3秒 |
| 普段（3日分のログ） | 2.3 / 2.6 / 3.0 / 3.4 / 3.9 / 4.1 / 4.5 秒 |
| 画面側の締め切り | 15秒・取得は1回きりでやり直し無し |
| 温まっているとき | 2.3〜2.6秒・カード3枚 |
約18秒という応答までの時間は、画面側の15秒の締め切りを超えていた。取得は1回きりで、打ち切ったあとにやり直す処理もなかった。そのため、関数が応答を返すまで待てず、カード0枚の表示へ倒れていた。
同じ日に記録した26.3秒は「起動から実行開始まで」の値であり、約18秒の「応答まで」とは測定区間が異なる。ただし、どちらも画面側の締め切りを超える時間が記録されている。
自分たちのコードの読み込みも手元で測り、0.66〜0.89秒だった。今回の記録では、これを遅さの原因とはしていない。関数が温まっているときには、2.3〜2.6秒でカード3枚を返していた。
検査の見方が古くなったための失敗ではなく、製品の画面で実際に起きている問題だった。告知のリンクから来た最初の訪問者がこの状態に当たると、見本を確認できず、製品が止まっているように見えてしまう。
出典: 自社の実測（2026-10-16）
再取得を1回だけ加え、空の結果と取得失敗を分けた
修正では、取得を1度だけやり直すようにした。2回目には関数が温まっているため、速く返せる。見本の URL は10分の区切りの中では同じなので、1回目の結果が配信網に載っていれば、そこから即座に返る。
あわせて、「本当に0件だった」と「読めなかった」を別の文にした。取得に失敗した場合には「やり直す」ボタンを出し、1回の失敗で行き止まりにしないようにした。
この区別は、訪問者の操作だけでなく、問題を調べる側にも必要だった。今回の検査は、失敗を「外枠だけ」と報告していた。しかし実際の画面には「混み合っています」と出ていた。報告だけでは、見本の中身がないのか、通信や関数に問題があるのかを判断できなかった。
そこで検査の失敗文言も、「読めなかった」「0件だった」「まだ読み込み中」「画面の外枠だけ」の4通りに分けた。結果が空であることと、結果を取得できないことを分ければ、確認する相手も分かれる。画面の表示と検査の報告の両方で、この区別を持たせた。
出典: 自社の実測（2026-10-16）
通信を落として確かめ、残った待ち時間も記録した
修正後は、単体テスト163件が通った。追加した3件のうち2件は負のテストであり、やり直しの処理を外すと2件が落ちることも確かめた。修正が入った状態で通ることに加え、その処理をなくした場合に検査が失敗を捉えるかも確認した。
本番の画面では、通信をわざと失敗させて動きを見た。1回目だけ落とした場合はカードが表示され、取得は2回だった。2回とも落とした場合は、「読み込めませんでした」と「やり直す」ボタンが1つ表示され、「混み合っています」は出なかった。
さらに、関数を出し直して冷えた状態で本番を開くと、8.0秒でカードが表示され、例外は0件だった。主要な導線の検査も25/25に戻った。
ただし、再取得を加えたことで、冷えた最初の呼び出しの待ち時間までなくなったわけではない。今回の確認では8.0秒で済んだが、記録には18〜26秒の回があり、訪問者を最長で十数秒待たせる弱点は残る。
根本から直す案としては、見本3枚を静的なファイルに置き、画面が先にそれを読む方法を挙げている。毎日の処理で差し替えれば鮮度を保てるが、この方法はまだ実施していない。関数を常に温めておく最小インスタンス数の設定も、常に課金されるため採用しなかった。今回実施したのは、再取得と表示、検査の改善までだ。
出典: 自社の実測（2026-10-16）
業務に置き換えると
社内ツールや問い合わせ窓口の画面でサーバーレスの関数を使う場合にも、今回の記録から点検できるのは、最初の呼び出し、再取得の回数、失敗時の表示、関数を通さずに見せる方法だ。
- 夜間や休日明けの最初の1回を確認する。 温まっているときの応答だけで判断せず、呼ばれていなかった関数を使うときにも、画面の締め切りまでに必要な内容が届くかを見る。
- やり直しは1回にとどめる。 今回は1回の再取得でカードを表示できた。何度もやり直すと、遅い日に関数を余計に起こすため、回数も確認対象にする。
- 「0件」と「読めなかった」を分ける。 中身がない場合と、通信や関数から取得できない場合では、直す相手が違う。画面と検査の文言で、その違いを読み取れるか点検する。
- 常に温める前に、静的な控えを考える。 常時稼働には費用が伴う。見本のような内容なら、関数を訪問者の経路から外して先に見せる方法を検討する。
今回の確認では、カードが出ることだけでなく、再取得も失敗したときに何が表示されるかまで確かめた。業務の画面でも、取得成功と取得失敗をそれぞれ確かめることで、利用者が目にする状態と、調査する側が受け取る報告を照らし合わせられる。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。