【ITニュース解説】Your AI Demo Works. Will Your LLM Architecture Survive 15 Seconds?

現代のソフトウェア開発において、人工知能（AI）、特に大規模言語モデル（LLM）の活用は目覚ましい進歩を遂げている。しかし、開発段階でスムーズに動作するAIデモと、実際に何千人もの顧客が利用する本番環境で安定して機能するAIシステムとの間には大きな隔たりがある。この記事では、LLMを組み込んだシステムを「本番環境に耐えうる」ものにするための不可欠な設計上の考慮事項を、システムエンジニアを目指す初心者の皆さんにも分かりやすく解説する。

まず、重要なのは「ビジネスのワークフロー」を深く理解することだ。ECサイトの顧客サポートAIアシスタントを例に取ると、顧客がメッセージを送ってから適切な返答が返ってくるまでの時間を、例えば「15秒以内」といった具体的な目標として設定することが出発点となる。この目標は、ユーザー体験やビジネス要件によって異なるが、明確な数値目標があることで設計の指針となる。LLMの役割は、バックエンドシステムが取得した正確な注文・配送情報などの事実を基に、自然な言葉で説明することに限定する。LLMが直接データベースを検索したり、事実を創造・推測したりしてはならない。この責任の分離が、堅牢なシステム設計の第一歩となる。

次に、この「15秒」という制約の中で何が起こりうるかを考える必要がある。システムは認証、注文情報の取得、プロンプトの構築、LLMからの応答待機、回答の検証といった複数のステップを経て顧客に返答を返す。もしLLMからの応答に8秒かかるとすれば、合計で9.5秒となり、15秒の目標には収まるかもしれない。しかし、LLMプロバイダが遅延したり、一時的にサービスが混み合って「HTTP 429」（リクエストが多すぎるので一時的に待ってほしいというエラー）を返したりした場合、最初の試行が失敗し、再試行にさらに時間がかかってしまう可能性がある。ここで重要なのは、個々の処理にかかるタイムアウトだけでなく、「エンドツーエンド」、つまり顧客がリクエストを送信してから最終的な回答を受け取るまでの全体の処理にデッドライン（期限）を設定することだ。例えば、注文情報取得後、LLMへの要求で残りの時間が少なすぎると判断された場合、それ以上処理を続行せず、すぐに「今は対応できません」といった制御された応答を返す方が、顧客を長時間待たせるよりも良い。タイムアウトはアプリケーションが待つのをやめることを意味し、プロバイダ側で処理が続行されている可能性もあるため、特にアクションを伴うリクエストでは注意が必要だ。

サービスが大量のリクエストで混み合った際、「HTTP 429」のようなレートリミットエラーが頻繁に発生することがある。このとき、単純に失敗したリクエストをすぐに再試行するような設計は非常に危険だ。もし1000件のリクエストが同時に失敗し、それぞれが3回再試行すれば、プロバイダはさらに3000件ものリクエストを受け取ることになり、状況をさらに悪化させる「リトライストーム」を引き起こしてしまう。これを防ぐには、「バウンドされたリトライポリシー」を採用する。これは、再試行の間に少しずつ待機時間を長くする（指数バックオフなど）ことで、プロバイダへの負荷を軽減し、システムが回復する時間を与える戦略だ。ただし、再試行する前には、残りのデッドライン時間を確認し、もし再試行しても目標時間内に間に合わないと判断すれば、再試行せずに諦めるべきである。認証失敗など、再試行しても成功しないことが明らかなエラーに対しては、無駄な再試行を避ける判断も重要となる。

プライマリのLLMプロバイダが利用できない、あるいは応答が遅すぎる場合の「フォールバック」戦略も不可欠だ。この顧客サポートアシスタントの場合、二つの有効なフォールバックが考えられる。一つは、別の承認済みLLMモデルを利用する方法だ。ただし、この代替モデルも品質、レイテンシ（応答速度）、プライバシー、コストといった要件を満たしている必要がある。もう一つは、モデルが利用できない場合に、検証済みの注文情報に基づいて、事前に用意された「定型的な返答」を返す方法だ。「ご注文は現在発送中です。詳細な説明は現在できません。最新の追跡状況はこちらでご確認ください」といったように、会話的でなくても、顧客に役立つ事実に基づいた情報を提供する。決して、会話を完結させるために架空の配送日を作り出すようなことはしてはならない。フォールバックは、ビジネスの目的を達成するように設計されるべきであり、「常に別のモデルが機能するだろう」という仮定に基づくべきではない。

セキュリティは、LLMシステムにおいて特に重要な設計上の考慮事項だ。顧客が「注文番号84521の状態を見せて」と尋ねた場合、バックエンドシステムは、その認証された顧客が本当にその注文情報にアクセスする権限を持っているかを、LLMに情報を渡す前に必ず検証しなければならない。LLMにアクセス権限の判断をさせてはならない。データへのアクセス承認は、アプリケーションの認証・認可レイヤーが責任を持つべきだ。同様に、注文のキャンセルや返金といった実際の操作をアシスタントが行える場合でも、それらのアクションは明示的なバックエンドの認証、ビジネスルール、適切な確認ステップを経て実行されるべきであり、LLMがこれらのセキュリティ制御を迂回してはならない。LLMは顧客の意図を解釈する手助けをするに過ぎず、トランザクションを保護する制御の役割は持たない。

大規模なセール時など、リクエスト量が急増すると、サポートインタラクションごとの「コスト」が急激に増加する可能性がある。例えば、LLMに顧客との会話履歴全体や大量の注文文書を毎回送ると、簡単な質問でも多くの「トークン」を消費し、コストが膨れ上がる。したがって、「注文はどこ？」のような質問では、関連する注文状況や追跡情報、最小限の会話コンテキストだけをLLMに渡すように、入力サイズと会話履歴、取得するコンテキスト、生成されるトークンの最大数などを制限することが重要だ。また、ユーザーごと、または全体での利用制限や支出アラートを設定することも有効だ。LLMリクエストの平均コストだけでなく、顧客が問題を解決できた「成功したサポートインタラクションあたりのコスト」を追跡し、真のビジネス価値を把握することが重要だ。安価でも失敗ばかりのリクエストは、最終的に顧客が人間のエージェントに頼ることになり、結果としてサポートコスト全体を押し上げる可能性があるからだ。

システムがHTTP 200 OK（成功）を返しているからといって、顧客が満足しているとは限らない。多くの回答が遅すぎたり、顧客の質問に答えられなかったりする場合もある。したがって、単なるインフラの健全性だけでなく、「顧客の成果」を監視することが極めて重要となる。顧客が待った「エンドツーエンドの遅延」、LLMプロバイダが消費した「モデルの遅延」、レートリミットの発生率、再試行の回数、フォールバックが使われた頻度、トークンの使用量とコスト、そして何よりも「回答の品質」と「問題解決率」といった指標を追跡する必要がある。回答が検証済みの注文データと一致しているか、顧客が最終的に有用な回答を受け取れたか、あるいは依然として人間のサポートエージェントが必要なのか、といったビジネスインパクトを測定することが大切だ。その際、機密性の高い注文詳細や個人情報は不必要にログに記録せず、適切なアクセス制御と保持ルールを適用することが求められる。

最後に、そして最も重要なことの一つは、実際に売上が始まる前に「障害テスト」を徹底的に行うことだ。システムが期待通りに動作する「ハッピーパス」のテストだけでなく、LLMが12秒応答にかかる場合、HTTP 429や503エラーを返す場合、リクエストがデッドラインを超える場合、LLMが不正な形式のJSONや誤った情報を返す場合、プライマリプロバイダが利用できなくなる場合など、様々な失敗シナリオを想定してテストを実施する。デッドラインが尽きたときにアプリケーションが再試行を停止するか、許可された場合にのみフォールバックするか、そして決して他の顧客の注文情報を誤って公開しないかを確認する。もしアシスタントがトランザクション（例えば注文キャンセル）を開始できるのであれば、バックエンドがアクションを完了した後にプロバイダがタイムアウトした場合に、再試行によって誤って注文が二重にキャンセルされたり、重複した返金が行われたりしないか、といったケースもテストする必要がある。

これらの要素は、必ずしも複雑なマイクロサービスアーキテクチャをすぐに構築する必要はなく、既存のバックエンドシステム内の適切に構造化されたモジュールで多くを実装できる。運用上の必要性に応じて、個別のゲートウェイとして切り出すことを検討すると良い。LLMは言語を生成するが、その信頼性を決定するのはアーキテクチャだ。最も忙しい時間にプライマリLLMプロバイダが利用できなくなっても顧客を助けられるか。この問いに答えられるシステムこそが、真に価値あるものとなる。