結論から書くと、遅かったのは「答えを出すこと」ではなく「答える前に考えること」でした。自作の1on1管理アプリには、直近のセッション内容からAIが次回の話題候補を提案する機能があります。この機能の応答が遅いと感じる場面があり、最初はログの合計時間だけを見て原因を探していました。結果的に、体感の遅さの正体は画面に表示されない「思考トークン」にありました。ここからは、原因の切り分け方と、実測でどれだけ改善したかを書きます。あわせて、同じ時期に行ったモデルの実測比較についても触れます。
症状: 提案が返ってくるまでの「間」が気になっていた
この1on1管理アプリはCloudflare Workers上で動いていて、1on1の記録を踏まえてAIが次回の話題候補を提案する機能を持っています。使っているうちに、提案が返ってくるまでの「間」が気になるようになりました。数秒待たされている感覚があるのに、ログを見ても「リクエストからレスポンスまでの合計時間」しか記録されていませんでした。
最初にやったのは、その合計時間を眺めることでした。しかし合計時間だけでは、どこで時間が消費されているのかがわかりません。ネットワークの往復なのか、Cloudflare Workers側の起動なのか、モデル自体の生成が遅いのか区別がつかないまま、「なんとなく遅い」という印象だけが残りました。
Workers側のコールドスタートも疑いましたが、同じリクエストを連続で送っても時間があまり変わらなかったため、この時点で候補から外しました。残るのはAPI呼び出しの中身です。ここでようやく、合計時間ではなく内訳を見る必要があると気づきました。
総時間ではなく「内訳」を見て、原因が変わった
使っているのはGPT-5.6系のリーズニングモデルです。リーズニングモデルは、ユーザーに見える回答を書き始める前に、内部で「どう答えるか」を考える工程を持っています。API のレスポンスには、この思考にどれだけトークンを使ったかが記録される項目があり、そこを確認して初めて内訳が見えました。デフォルト設定(medium相当)では、この回答前の思考に約200トークン・約3秒を消費していることがわかりました。
さらに厄介なのは、この思考トークンがユーザーには一切見えないのに、出力トークンとして課金対象になる点です。「遅い」という体感の正体は、ネットワークでも生成速度そのものでもなく、画面に表示されない思考の時間でした。合計時間という一つの数字だけを見ていたときは、ここに気づけませんでした。内訳を見て初めて、直すべき対象が「生成そのもの」ではなく「生成の前」にあるとわかったことになります。
reasoning_effortを下げて実測した
原因が「思考の設定」にあるとわかれば、打ち手は単純です。reasoning_effortパラメータをデフォルトからlowに下げて、まずローカルで実測しました。
response = client.responses.create(
model="gpt-5.6-luna",
reasoning_effort="low",
input=prompt,
)
結果は次の通りです。
- default: 6.6秒・思考トークン195
- low: 3.8秒・思考トークン43
思考トークンが195から43まで減り、応答時間もほぼ半分になりました。品質面でも、提案内容の機微はある程度維持されていて、下げたことによる劣化は実用上気にならない範囲でした。
本番環境でも実測しました。API側の変動があるため幅は出ますが、default設定時の9.9秒から、low設定では5.2〜8.2秒まで改善しています。数字は環境差で動きますが、方向性としては狙い通りでした。
設定変更が意図せず戻らないよう、テストにもreasoning_effortのアサーションを追加しています。218件のテストがパスすることを確認したうえで本番に反映しました。一度きりの対応で終わらせず、回帰しない形で固定したのがこの作業のポイントです。
速度だけで選んでいいのか: 3モデルの実測比較
同じ時期に、AI提案機能で使うモデルの選定についても実測比較をしました。対象は3つのモデルで、同一プロンプト・同一セッションの文脈を使い、条件を揃えて比べています。
- gemini-3.6-flash: 品質が最も良い。過去のやり取りの要約から細かい機微を拾った提案が出て、マネージャー視点の深さも感じられました。単価は100万トークンあたり入力$1.5・出力$7.5です
- gemini-3.5-flash-lite: 旧モデルのgemini-2.5-flashと同額でありながら5倍速で応答が返ってきて、しかも品質も旧モデルを上回っていました。単価は入力$0.3・出力$2.5です
- 旧gemini-2.5-flash: 3つの中で提案の内容が最も浅く、同じ提案を繰り返さないための工夫も甘いという結果でした
比較は同じプロンプトと同じセッションの会話履歴を3モデルに投げて、出てきた提案の内容と応答時間を並べて確認する形で行いました。条件を揃えずに「なんとなく前より速い・遅い」で判断すると、モデルの実力差なのか会話の内容の違いなのかが混ざってしまうため、ここは意識して揃えています。
「新しいモデルほど良い」と決めつけず並べてみると、価格・速度・品質のどれかを犠牲にしないモデルが必ずしも最新版とは限らないとわかります。今回はgemini-3.5-flash-liteが、旧モデルの完全上位互換のような立ち位置でした。そうは言っても、いま同じ比較をしたら結果が変わる可能性はあります。モデルの実力は数か月単位で入れ替わるため、この結果を固定的なものとして扱うつもりはありません。
いまのところは品質を優先してgemini-3.6-flashを採用しています。ただし利用が増えてコストが無視できなくなった場合には、無料プランはgemini-3.5-flash-lite・有料プランはgemini-3.6-flashのようにプランごとにモデルを分ける案をバックログに残しました。本番での実機確認では、1回の提案生成で813トークンを消費し、コスト表示は¥0.52でした。1回あたりの金額としては小さくても、利用者数やリクエスト頻度が増えれば効いてくる数字なので、記録として残しています。
体感速度は、サーバー側の秒数だけで決まらない
reasoning_effortの調整と並行して、UX側の対処も入れました。画面に「AI生成中」であることを示すインジケーターを追加しています。
体感速度は、待たされている時間の長さだけでなく、「いま待っていることが本人にわかるかどうか」でも変わります。同じ5秒でも、画面が固まって見える5秒と、生成中だとわかる5秒では受け取り方が違います。サーバー側の実測値を削る作業と、待っている間の見た目を整える作業は、別の軸の対処として両方やる価値がありました。
どちらか一方だけでは足りません。reasoning_effortを下げずにインジケーターだけを追加していたら、待ち時間の長さそのものは変わらないままでした。逆にインジケーターを入れずに実測値だけ削っていたら、体感としての改善は今回より小さく感じられたはずです。
EMとして持ち帰った教訓
「AIの返信が遅い」という報告は、要求としてはシンプルに聞こえます。ただ、その言葉をそのまま受け取って実装の最適化に飛びつく前に、まず内訳を測ることには意味がありました。
合計時間という一つの数字だけを見ていた間は、何を直せば良いのか判断できませんでした。思考トークン数という内訳を見て初めて、直すべき箇所が「生成の速度」ではなく「思考の設定」だとわかりました。数字の内訳を見ないまま打ち手を決めると、効かないところを一生懸命直すことになります。
これはコードの遅延に限った話ではありません。チームの1on1で「最近どうも足並みが揃わない」と相談されたとき、それを一つの感想のまま受け取って対策を打つと、たいてい的を外します。稼働時間なのか、認識のズレなのか、相談のしやすさなのか、内訳に分けて初めて、どこに手を入れるべきかが決まります。この考え方は自分のチーム運営でも繰り返し使っている手順で、今回のパフォーマンス調査でも同じ順番をなぞっただけでした。
まとめ: 「遅い」の中身を先に測る
リーズニングモデルは、既定の設定で「賢く考える」ことに時間とコストを使うようにできています。ただ、その賢さを毎回必要としているとは限りません。今回の1on1提案機能では、reasoning_effortをlowに下げるだけで応答時間がほぼ半減し、品質の劣化も実用上気にならない範囲に収まりました。
あわせて実施したモデル比較でも、最新のモデルが常に最良とは限らず、価格・速度・品質を同じ条件で並べて初めて判断できることを確認しました。結論として、「遅い」という報告を受け取ったときは、対処法を決める前に、まず時間の内訳を測ることをおすすめします。
私は現役EMとして、1on1やチーム運営の仕組み化について書いています。1on1管理のNotionテンプレート(無料Lite版)を公開中です → 試してみる。X: @anikuma_tech
コメント