AI処理を待たせない作り方

AI機能を組み込んだサービスで、利用者が最初に不満を持つのは出力の質ではなく待ち時間です。ボタンを押してから十数秒、画面が何も変わらない。利用者は壊れたと判断してもう一度押します。すると同じ処理が二重に走り、利用料も二倍かかります。

AIの応答には時間がかかる、という前提は変えられません。変えられるのは、その時間の扱い方です。本記事では、既存のAI APIを組み込んだWebアプリで画面を止めないための作り方を整理します。構成全体の話はAIを組み込むアプリの基本構成で扱っています。

なぜ「待たせる作り」は壊れるのか

ボタンを押して結果が返るまでサーバーが応答を保留する、いわゆる同期の作りは、処理が短いうちは素直で分かりやすい方法です。しかしAI処理では、次の三つで破綻します。

一つ目は、途中で切れることです。多くのWebサーバーやクラウドの実行環境には、一定時間で応答を打ち切る設定があります。移動中の通信も途切れます。処理は裏で進んでいるのに、利用者には失敗としか見えない、という状態が起きます。

二つ目は、同時に来ると詰まることです。AI処理が終わるまでサーバーの処理枠を一つ占有するため、同時利用者が増えると枠が尽きます。AIとは無関係な画面まで開かなくなります。

三つ目は、再実行できないことです。外部APIが一時的に失敗したとき、同期の作りでは利用者に「もう一度押してください」と伝えるしかありません。利用者が押さなければ、その依頼は消えます。

依頼を「列」に載せる

対処の基本は、依頼の受付と、実際の処理を分けることです。

利用者がボタンを押したら、サーバーはやることを一件のデータとして記録し、すぐに「受け付けました」と返します。画面は即座に次の状態へ進みます。実際のAI呼び出しは、別に動いている処理役がその記録を順に拾って実行します。この待ち行列をキューと呼びます。

キューは専用のサービスを使う方法と、データベースの表を一つ使う方法があります。小規模なうちは後者でも十分に機能します。大切なのは仕組みの豪華さではなく、受付と実行が分かれていることです。分かれていれば、処理が遅くても画面は止まらず、失敗しても記録が残っているので再実行できます。

依頼のデータには、誰の依頼か、何を処理するのか、いまどの状態か（受付済み・処理中・完了・失敗）、何回試したか、結果はどこにあるかを持たせます。この状態があることで、画面に進捗を出せるようになります。

二重実行と取りこぼしに備える

分けた瞬間に、新しい問題が二つ発生します。どちらも必ず起きるものとして設計します。

二重実行は、利用者が連打したとき、通信の再送が起きたとき、処理役が複数いるときに発生します。AI処理は一回ごとに課金されるので、そのまま費用に響きます。対策は、依頼を作るときに「同じ内容の依頼」を見分ける鍵を付けることです。同じ利用者・同じ対象・同じ入力の依頼が既に処理中なら、新しく作らずに既存の依頼を返します。利用者には「いま処理中です」と見せれば十分です。

取りこぼしは、処理役が処理の途中で落ちたときに起きます。状態が「処理中」のまま止まった依頼が残ります。対策は、一定時間以上「処理中」のままの依頼を拾い直す仕組みです。あわせて、再試行の回数に上限を設け、超えたら「失敗」として確定させます。無制限に再試行すると、返らない依頼に利用料を払い続けることになります。

失敗の扱いと再試行の判断は、AIが答えられないときの設計で詳しく扱います。

待っている間、画面に何を出すか

裏で処理する形にすると、今度は「終わったことをどう知らせるか」が問題になります。選択肢は主に三つです。

最初は定期的に問い合わせる方式で十分なことが多く、間隔を数秒に置けば体感上の差もほとんどありません。ただし、間隔を短くしすぎるとサーバーへの負荷が積み上がるので、時間が経つにつれて間隔を広げる調整を入れます。

進捗の見せ方そのものは、利用者の体感を大きく左右します。「処理中」とだけ出すのと、「あと2件で順番が来ます」「要約を作成しています」と出すのとでは、同じ待ち時間でも離脱率が変わります。この見せ方はAI機能の画面の作り方で扱います。

上限と打ち切りを決めておく

非同期にすると、利用者は結果を待たずに次の依頼を出せるようになります。便利ですが、放っておくと一人が大量の依頼を積み、列が詰まり、費用も膨らみます。

決めておきたいのは次の三つです。

• 一人あたりの同時処理数の上限：既に処理中の依頼がある間は、新しい依頼を待たせるか断ります。
• 列全体の長さの上限：超えたら受付を止め、「現在混み合っています」と伝えます。無言で遅くなるより、断るほうが親切です。
• 一件あたりの打ち切り時間：想定を大きく超えた依頼は失敗として確定させ、費用と枠を解放します。

これらは技術判断のように見えますが、実際は事業判断です。「有料利用者は先に処理する」「無料利用者は一日の上限を設ける」といった方針がそのままこの設定に反映されます。

非同期にしないほうがよい場合

ここまで非同期を前提に書きましたが、常に正解というわけではありません。

処理が1〜2秒で確実に終わり、入力の長さが利用者によってばらつかず、失敗しても押し直せばよい程度の処理であれば、そのまま待たせるほうが作りも運用も単純です。短い定型文の分類、選択肢からの判定といった処理がこれにあたります。仕組みを増やすこと自体にも保守の費用がかかります。

判断の材料は実測です。本番に近い長さの入力で、時間を測ってください。多くの場合で3秒未満、たまに10秒を超える程度なら、文字を少しずつ出す方式で吸収できます。常時10秒を超える、あるいは複数回AIを呼ぶ処理なら、非同期に踏み切る段階です。

弊社は既存のAI APIを業務システムやプロダクトに組み込む開発を行っており、この「どこまでの仕組みが要るか」の見極めを設計の最初に行います。過剰に作り込まず、かつ利用者が増えたときに作り直しにならない線を探すのが実務です。

AI活用開発やWebシステム開発で、待ち時間の設計から相談したい場合はお問い合わせからご連絡ください。