LLM×API連携を安定させる実践的な解決策｜エラー処理・遅延対策・コスト管理

LLMとAPIの組み合わせは強力ですが、前回の記事で見たように遅延・無限ループ・非決定性・コスト爆発・レートリミット超過といったリスクがあります。
本記事では、それらを防ぐための実務的な対策を「設計段階で必ず押さえるべきポイント」として紹介します。

エラー処理の型を決める

最も重要なのは「例外時の振る舞いを定義しておく」ことです。特にリトライ処理は現場で事故を招きやすいため、型をあらかじめ決めておくと安心です。

• HTTPエラー別の対応方針
  • 400系：入力検証に戻す（ユーザーに再入力を促すUIを設ける）
  • 500系：指数バックオフで最大3回までリトライ、その後はフォールバック処理へ
• フォールバック例
  • 翻訳APIが落ちている場合はキャッシュ済み訳文を返す
  • 検索APIがエラーなら「関連情報は現在取得できません」と明示的に返答

これにより、無限ループやサービス全停止を防ぐことができます。

レスポンス遅延を抑える工夫

遅延は「LLMの処理時間＋API応答時間」で累積するため、いかに待ち時間を短く見せるかが鍵です。

• 非同期処理の活用
  並列でAPIを叩き、最初に返ってきた結果だけ利用する「レース戦略」を採用。
• キャッシュの利用
  同じ問い合わせは15分間キャッシュするなど、重複リクエストを減らす。
• 段階的応答
  まず暫定回答を即時表示し、その後API結果をマージして完成版を出す。

UXを優先するなら「全て待ってから返す」設計を避けるのがポイントです。

非決定性への対処

LLMの出力が揺れる問題は、正規化を挟むことでコントロール可能です。

• 地名はGeo APIでID変換してから利用
• 日付や数値は正規表現で整形してからAPIに渡す
• JSON Schemaを用いて出力をバリデーション

これにより「東京駅／東京ステーション／丸の内1丁目東京駅」といった表記ゆれを吸収できます。

コストを見積もり・監視する

コスト膨張は多くの現場で実害が出ている部分です。対策は「事前に見積もり、運用で監視する」の二段構えです。

• 見積もり方法
  テスト環境で平均トークン数を計測し、1リクエストあたりの単価を算出
  → 「平均5,000トークン × 0.002ドル × 想定件数」で概算コストを計算
• 監視方法
  ダッシュボードで日次のトークン数とAPIコール数を可視化
  → 月額上限に近づいたらSlackに通知

「どれくらい使っているか分からない状態」を絶対に避けることが重要です。

レートリミット対策

最後に忘れがちなのがベンダーのレート制限です。大型連休やイベントでアクセスが集中すると一気に制限に引っかかります。

• 事前調査：APIごとのリクエスト制限を確認（例：1秒10リクエスト）
• キューイング：大量リクエストは順番待ちに並べる
• キャッシュ：同じ観光地の情報を複数人がリクエストしたら共通キャッシュを返す

この仕組みがないと「ピーク時に全サービス停止」という最悪のシナリオを招きます。

現場で必ず押さえるべき6つのチェックポイント

以下のチェック項目を設計レビューやテスト計画に組み込むと、安全性が一気に高まります。

チェック項目	タイミング	担当
エラー処理（リトライ上限・フォールバック）	実装前レビュー	SE・PG
レスポンス時間合計の見積もり	要件定義	PM
出力正規化・Schemaバリデーション	実装時	PG
トークン消費とAPIコール数の試算	設計レビュー	PM
コスト監視ダッシュボードとアラート設定	運用開始前	運用担当
レートリミット仕様とキューイング	設計時	SE

このチェックリストは「誰が・いつ・何を確認すべきか」を明示するためのものです。
たとえば PM（プロジェクトマネージャー）は要件定義の段階でレスポンス時間を合計し、現実的なUX目標を立てることが求められます。
一方でPG（プログラマー）は実装時にSchemaバリデーションを入れて、LLMの出力が揺れてもAPIに安全に渡せる状態に整えるのが役割です。
また、運用担当は日々のコスト監視やアラート設定を管理することで、予算オーバーを防ぎます。

つまり、この表は単なるチェック項目リストではなく、役割ごとにどの段階で責任を持つのかを整理したマップです。
レビュー会議や設計レビューの際に「各担当者が表を見ながら自分の担当部分を確認する」運用を想定しています。