LLM APIを2年間本番運用して苦労した話

2025/10/23に開催された「Product Engineering Night #10 ── LLM活用プロダクトとPdE実践の最前線」に、IVRyのべいえりあが登壇しました。

■リンク集
・コーポレートサイト：https://ivry.jp/company/
・採用ページ：https://ivry-jp.notion.site/
・イベント一覧：https://ivry.connpass.com/event/
・IVRy Tech（Xアカウント）：https://x.com/IVRy_tech

Transcript

1. LLM APIを2年間本番運⽤して苦労した話 べいえりあ @ 株式会社IVRy
2. ⾃⼰紹介 名前：べいえりあ 肩書：Principal AI Engineer @ IVRy 専門：自然言語処理（10年くらいやってます） これまでの経歴： - 理論物理博士@ミシガン大学 - データサイエンス修士 @ニューヨーク大学 - Llama作ったチームでインターンやったり - Google Assistant作ってたチーム（の中の一チーム）でテックリードをやったり
3. 今回の話
4. IVRyで落とせないLLMシステムを2年運⽤したので それにまつわる苦労話をします
5. IVRyの電話の⾃動応答システム 様々な問い合わせを認識して対応するLLMベースのシステム LLMが落ちると通話できなくなるので、LLMの安定性は死活問題 飲み放題付き3,500円のコースで 忘れ物しちゃった 予約したい 営業時間は？ 駐⾞場ある？ 12/8に2名で
6. LLM APIは実サービスを作る上で⾮常に有⽤ 社内においてはLLMは⽣成AIというよりzero-shot learnerとして利⽤ これにより、ドメインによらない機械学習ソリューションを構築 情報抽出 テキスト分類
7. LLM APIは⾮常に有⽤。 ただし、既存APIにはなかった 様々な問題も同時に存在する
8. 運⽤し始めた初期はそこまで問題は無かったが ある⽇突然問題が発⽣
9. 2024年7⽉13⽇
10. 2024/07/13、⼤規模Azure OpenAI障害
11. 2024/07/13、⼤規模Azure OpenAI障害 - Azure OpenAIが世界中で落ちた - OpenAIも同時に落ちた - 復旧まで1⽇くらいかかった - 何故か⽇本リージョンは無事 - 対話サービスはほぼ影響無し - オフラインのサービスが⼀部影響を受けた LLM APIは落ちる。落とせないサービスだとLLMが落ちた時の対策は必須
12. 監視体制の強化とフォールバックの導⼊
13. 監視体制の強化 障害が起きたらまず⾃分たちが気づけるよう、様々な項⽬を監視
14. フォールバックの導⼊ - LLMが落ちたら別のLLMを利⽤ - ライブラリとしてLiteLLMを採⽤
15. フォールバックがあればAPIが落ちても安⼼…？
16. フォールバックで解ける問題は⼀部でしかない - LLM APIの障害でもAPIが完全に落ちることはほとんどない - 障害時でも正しくフォールバックされない - LiteLLM⾃体にいろいろ問題がある
17. LLMの障害パターン
18. LLMの障害パターン① レイテンシーの悪化 - ある⽇突然、LLMのレイテンシーが悪化 - 普段は1s程度のレイテンシーが断続的に10s近くかかるように - 特定の⼊⼒モダリティでのみ発⽣（テキスト⼊⼒は影響無し） 明⽰的にエラーは出ていないので、フォールバックされない
19. LLMの障害パターン② 精度劣化 - ある⽇突然、LLMが以前と異なる出⼒をするようになる - LLMはバージョン固定すればあまりない。STTやTTSはよくある 明⽇の3時です。 アシカの惨事です。 明⽰的にエラーは出ていないので、フォールバックされない
20. 対策①：（レイテンシー悪化）監視を細かくやる LLMのレイテンシーは - モデルの種類（影響中〜⼤） - ⼊⼒トークン⻑（影響⼩） - モダリティ（影響⼤） - 出⼒トークン⻑（⻑考含む、影響⼤） などに依存するため、これらが⼤きく異なるタスクは分けて監視する
21. 対策②：障害パターン毎のplaybookを作成 1. 異常時の挙動を洗い出す a. エラー率悪化、レイテンシーの悪化、精度劣化、など 2. それぞれの挙動について、ユーザー影響を調べる 3. それぞれの挙動について、検知⽅法を考える 4. それぞれの挙動について、どういう条件が満たされた時にどういう アクションを起こすかを考える 簡単そうに⾒えても、特にアクションなどは判断が難しいことは多々ある
22. Playbookに基づく障害訓練の様⼦（本⽇） 実際に障害が起こったと想定して、Playbook通りに対応する訓練
23. LiteLLM問題
24. LiteLLM問題 - 最初にLiteLLMを導⼊した際は特に問題は発⽣しなかった - 新しいモデルを使うためLiteLLMを更新したらCPU使⽤率が爆増 - トラフィックが無くなってもCPU使⽤率が下がらない - バージョン変えて2回トライしたがどちらも上⼿くいかず…
25. 対策：別ライブラリへの移⾏ LLM APIのIF共通化 + フォールバックだけなら代替がいろいろある - Pydantic AI（Pythonライブラリ） - any-llm（Pythonライブラリ） - AI SDK（Typescriptライブラリ） - OpenRouter（統合API） IF共通化したいだけなら、⾃前実装の⽅がコントロールが効くかも？
26. まとめ
27. まとめ - LLM APIにおいては考えうる障害は⼤体実際に起こる - 障害に対応できる仕組みを考えて実装するのは必須 - フォールバックを⼊れる - LLM APIの監視は細かく⾏う - ありうる障害パターンを想定してplaybookを作成する - LLM APIのIF共通化はライブラリに頼っても良いが、不便もある
28. ご清聴ありがとうございました IVRyでは様々なポジションを絶賛採⽤中です！！！ 採⽤ページ：https://ivry-jp.notion.site/