【要約】「なぜかAIツールが遅い」の正体は、最初の60秒の沈黙だった話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発チームがCodensのAI解析ジョブにおいて、Webhookの失敗時にユーザーが「システム停止」と誤認する問題に直面した。バックエンドの設計方針が、ユーザーの認知速度と乖離していたことが原因である。
- ・Webhookが失敗した場合、保険のPollingが動き出すまで15分間の「沈黙」が発生する。
- ・サーバー負荷軽減を優先した指数バックオフ設計が、ユーザー体験を阻害していた。
- ・ユーザーが「ツールが壊れている」と判断し、サポートへの問い合わせが急増した。
// Approach
開発者は、Pollingの目的を「サーバー保護」から「Webhook失敗の早期検知」へと再定義した。標準的な設計テンプレートを疑い、初動の密度を高めるアプローチを採用している。
- ・Pollingのスケジュールを、最初を短く密にし、後を疎にする構成に変更した。
- ・初回Pollingの待ち時間を900秒（15分）から60秒（1分）へ大幅に短縮した。
- ・リトライ間隔を [60, 60, 120, 240, 480, 480, 480, 480, 480, 480, 480, 480] 秒に設定した。
- ・ジョブの総予算（タイムアウトまでの時間）は維持しつつ、初動の検知力を高めた。
// Result
Pollingの設計変更により、Webhookが届かない場合の検知時間が劇的に改善された。ユーザーの体感品質が向上し、運用負荷の軽減にも成功している。
- ・Webhook抜け検知の最悪ケースが約15分から約2分へ短縮された。
- ・検知の平均時間が約7.5分から約30秒へと大幅に改善した。
- ・サポートへの「動かない」という問い合わせが消失した。
- ・Webhookが正常な99%のケースでは、通信量への影響は無視できるレベルに抑制された。
Senior Engineer Insight
> 本件は「何を最適化するか」という設計思想の転換である。AIプロダクトでは推論時間を制御できないため、UXは「待ち時間の伝え方」に依存する。サーバー負荷を考慮した「正しい設計」が、必ずしも「正しいUX」を生むわけではない。特に長時間ジョブでは、初動のレスポンス（動いている感）が信頼性を左右する。設計レビュー時には、サーバー視点の作法とユーザー視点の体感の乖離を常に疑うべきである。