要点
- 文章が出るまでの待ち時間は17.0秒〜32.1秒で、ログではGeminiの初回応答自体に時間がかかっていた（出典: 自社の実測・2026-10-12）
- 同じ語と指示で思考あり・なしを比較し、応答時間と指定した10語の有無を確認した（出典: 自社の実測・2026-10-12）
- 比較した語の組では両条件とも指定語がそろい、日本語訳の欠落もなかった（出典: 自社の実測・2026-10-12）
- 控えのモデルは思考なしで指定語を落としたため、思考を残す判断にした（出典: 自社の実測・2026-10-12）
選んだ10語を使う文章を、条件を守ったまま早く出したい
英語学習アプリWords Adminの「Reading check」は、選んだ10語を使った短い文章をGeminiに作らせる機能だ。今回の課題は、利用者がボタンを押してから文章が出るまで、17.0秒〜32.1秒かかっていたことだった。
この機能で必要なのは、文章が早く出ることだけではない。選んだ語を使って読むための文章なので、指定した10語が本文に入っていることも必要になる。待ち時間を短くできても、語が抜ければ依頼した条件を満たさない。
そこで、設定を変える前に、待ち時間がどこで発生しているかをログで確認した。そのうえで、変更前後の速さと、生成した文章が条件を満たすかを同じ比較の中で確かめることにした。
出典: 自社の実測（2026-10-12）
サーバのログで、Geminiの応答にかかった時間を見る
サーバの関数には、次のログが残っていた。
[vocab-passage] model=gemini-3.7-flash attempt=1 ok=true in 28522ms
この行は、gemini-3.7-flashの1回目の呼び出しが成功し、その応答に28522msかかったことを示している。失敗して繰り返した結果として待たされたのではなく、最初の応答そのものに約28秒かかっていた。
今回の記録では、起動の遅れ（cold start）でも通信でもなく、Geminiが答える前に使う時間が待ちになっていた。ここでいう思考時間とは、Geminiが答えを出す前に「思考」に使う時間のことだ。
また、出力の上限を指定するmaxOutputTokensは付けていなかった。そのため、思考が出力の枠を使い、空の答えになる形とは区別している。今回確認したのは、答えは成功して返るものの、その前の思考に時間を使うという挙動だった。
記録では、Gemini 2.5以降は指定がなければ答える前に思考へ時間を使い、次の設定で思考を止められるとしている。
generationConfig.thinkingConfig.thinkingBudget = 0
この指定がなくても警告は出ず、呼び出しは成功する。成功したかどうかだけを確認していては、今回の待ち時間を判断する材料が足りない。ログにある応答時間まで見ることが、設定を見直す出発点になった。
出典: 自社の実測（2026-10-12）
同じ語と指示で、速さと指定語の有無を比べる
思考を止める前に気にしたのは、文章の精度が落ち、指定した語が抜ける可能性だった。そこで、同じ語・同じ指示を使い、思考ありと思考なしを5回ずつ比較した。語の組は、やさしい10語と難しい10語の2組を用意した。
測定したのは応答の秒数と、「頼んだ10語が本文に入ったか」の両方だ。結果は次のとおりだった。
| 語の組 | 思考あり 中央値（最大） | 思考なし 中央値（最大） | 10語そろった回 |
|---|---|---|---|
| やさしい10語 | 12.9秒（24.1） | 4.5秒（5.6） | あり 5/5 ／ なし 5/5 |
| 難しい10語 | 16.3秒（19.5） | 5.1秒（5.5） | あり 5/5 ／ なし 5/5 |
やさしい語の組でも難しい語の組でも、思考なしのほうが応答時間の中央値と最大値は短かった。一方、指定した10語は、どちらの条件でも全回そろった。
確認は語の有無だけで終えていない。日本語訳も並べて読み、訳のない文は両条件とも0件で、内容も同等だった。今回比較した範囲では、指定語と訳を確認したうえで、速さが変わることを確かめられた。
この結果を受けて設定を切り替えた。本番の実測では、17.0秒だった応答に対し、切り替え後は5.4秒、5.9秒、6.4秒を記録した。変更の判断を支えたのは、この秒数だけではなく、切り替える前に文章の条件も対照つきで確認していたことだ。
出典: 自社の実測（2026-10-12）
控えのモデルには、同じ設定を広げなかった
最初に使うモデルで結果がよくても、その設定をすべての呼び出しへ適用する判断にはしなかった。
最初の生成に失敗したときに使う控えのモデルは、gemini-2.5-flashだった。このモデルでは、思考なしで試すと2回中1回、頼んだ語を1語落とした。そのため、控えでは思考を切っていない。
控えの役割は、最初の生成が失敗した後に、もう一度条件を満たす文章を作ることにある。そこで、速さよりも指定語を取りこぼさないことを優先した。同じ文章生成でも、最初の呼び出しと、やり直しを担う呼び出しでは、採用する設定を分けた。
また、同じ画面では失敗時の文言も直した。それまでは原因を問わず同じ文言を出していたため、上限によるものなのか、故障なのかが分からなかった。修正後は、失敗の理由を1語で残すようにした。
応答が成功した場合は所要時間を見て、失敗した場合は理由を残す。今回の変更では、待ち時間を短くする設定とあわせて、何が起きたかを判断するための記録も見直した。
業務に置き換えると
社内チャット、一次返信、要約などの待ち時間を見直すときも、今回の確かめ方は点検項目に置き換えられる。特に確認したいのは、次の点だ。
- AIの応答時間をログで確認できるか。 画面全体の待ち時間だけでなく、AIへの呼び出し自体にかかった時間を見る。今回の記録では、成功した初回応答に時間がかかっていた。
- 設定変更を同じ条件で比較しているか。 思考を切る前後で語や指示をそろえ、変更による違いを確認する。
- 秒数と一緒に、依頼した条件を満たすか見ているか。 今回は指定した10語の有無と日本語訳を確認した。速さの数字だけで採用を決めない。
- 最初の呼び出しと控えの役割を分けているか。 控えで条件の取りこぼしが出た場合には、同じ設定を一律に広げず、やり直しを担う役割に合わせて判断する。
「Geminiが遅い」という見え方から、すぐに思考を止める結論へ進んだわけではない。ログで待っている場所を確認し、同じ条件で文章を比べ、控えでは別の結果が出たため設定を分けた。この順番が、今回の変更を判断する根拠になった。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。