LLMをAPI経由で本番導入したあと、「ベンチマークでは優秀だったモデルが、本番だと不安定」という声に悩まされている運用担当者は少なくないはずです。
評価用データセットで比較し、指示追従性も回答品質も納得できるモデルを選んだとします。ところがAPI（アプリケーションがモデルを呼び出すための通信インターフェース）の背後に回すと、レスポンスが途中で止まる、やたら遅いリクエストが混じる、といった現象が起きます。リトライ（失敗時の自動再試行）で表面上はカバーできても、ログには何も問題が起きなかったように記録されてしまいます。
この記事は、LLM APIを本番運用していて障害調査やSLO（サービスレベル目標）設計に関わるエンジニア・SREの方に向けた内容です。「モデルの問題」と「配信基盤（サービング層）の問題」を切り分けるための判断軸を整理しました。障害対応の現場で役立てば幸いです。
なぜこの切り分けが必要になるのか
LLMをAPI経由で使う構成は、オンプレで自前ホストしていた機械学習モデルをクラウドのマネージドAPIに切り替える移行パターンの典型例です。
オンプレ時代はモデルのコンテナ、GPUリソース、推論サーバーまで自分たちで監視していました。クラウドAPI移行後は、プロバイダー側のルーティング、レート制限、内部的なモデル差し替えなど見えない部分が増えます。
障害が起きたとき「AIの品質が落ちた」と一括りにしてしまうと、根本原因分析（RCA: Root Cause Analysis）が進みません。モデル自体の出力ミスなのか、配信基盤の応答劣化なのか、呼び出し側の実装ミスなのか、まず分解する必要があります。
判断軸1: 出力の完全性(応答がそもそも使える形で届いたか)
モデルが正しく理解していても、アプリケーションが要求したフォーマットで応答が返らなければ業務は止まります。
確認すべき項目は大きく5つに整理できます。
- 出力がスキーマ(あらかじめ定めた応答形式)に沿っているか
- 出力予算(トークン数上限)に余裕があるのに途中で生成が止まっていないか
- ツール呼び出し(Function Calling)の名前や引数が契約通り有効か
- フィルタによる意図しない省略が起きていないか(プロバイダーが証跡を出す場合)
- ストリーミング応答が正しい終端シグナルで終わっているか
これらは原因が別々なので、対処法も別々です。出力予算を増やしてもツール呼び出し名の不整合は直りません。ストリームが正常終了していても、中身のオブジェクトがスキーマ違反ということもあります。
ユーザーが途中でリクエストをキャンセルした場合、それをプロバイダー起因の「切り詰め」として記録してしまうと誤った統計になります。ここの区別は監視設計の初期段階でログのタグ付けルールに組み込んでおくべきです。
判断軸2: 応答速度(ユーザーが再送する前に届いたか)
抽出結果が完全に正しくても、ユーザーが痺れを切らして2回目のリクエストを送るほど遅ければ、体験としては失敗です。
ここで見るべきは3点です。可用性(タイムアウト前に有効な応答が届いた割合)、レイテンシ分布と生成速度、そしてリトライによる増幅です。
可用性は「エンドポイントに到達できた」だけでは不十分です。プロトコルとして有効な完全応答が、締め切り内に、リトライ前の時点で届いたかで測ります。稼働率の平均値に複数プロバイダーの結果を混ぜると、調子の悪いルートが優良ルートの影に隠れてしまうため、ルート単位の可視性を保つ必要があります。
レイテンシも単純な「秒間トークン数」だけでは足りません。最初の有効トークンが届くまでの時間、トークン間の間隔、ストリーム全体の完了時間まで分解して見る必要があります。
リトライ増幅は見落とされがちな軸です。自動リトライが裏で何度も発火していると、見かけ上の成功率は高く見えても、実際のレイテンシやコストは悪化しています。
判断軸3: 失敗の帰属先(モデルかプロンプトか配信基盤か)
「AIがおかしい」という報告を、モデル起因・プロンプト起因・インテグレーション起因・配信基盤起因に仕分けるための軸です。
モデルが間違う、プロンプト設計が甘い、アプリ側の統合コードにバグがある、という3つは昔からある原因です。ここに配信基盤の問題(ルーティング変更、レート制限、内部的なモデル差し替えなど)が加わると、原因の候補が一気に増えます。
「構造として正しい」ことと「内容として正しい」ことは別の検証軸です。たとえばツール呼び出しの引数がスキーマ的に妥当でも、適格性ルールの抽出結果自体が間違っているケースは珍しくありません。
判断軸4: 運用コストとSLO設計との整合性
監視の粒度を上げるほど観測コストはかかります。すべてのリクエストでトークンごとの遅延を記録すると、ログ量もストレージコストも増えます。
ここでのポイントは、障害対応に効く最小限の指標から始めることです。可用性・レイテンシ分布・切り詰め率・スキーマ適合率の4つは、追加の計装コストが比較的小さく、SLO(サービスレベル目標)の初期設計にそのまま使えます。
選択肢の比較
監視アプローチは大きく3つに分かれます。自前で全指標を計装する方法、プロバイダーのダッシュボードに任せる方法、第三者の品質評価フレームワークを併用する方法です。
| アプローチ | 強み | 弱み |
|---|---|---|
| 自前計装 | 自社の業務要件に合わせて細かく定義できる | 実装・保守コストが高い |
| プロバイダー任せ | 追加実装がほぼ不要 | ルート単位の失敗が平均化されて見えにくい |
| 第三者フレームワーク併用 | 複数プロバイダーを横断比較しやすい | 評価基準がまだ発展途上の場合がある |
ケース別の推奨
単一プロバイダーの単一モデルしか使っていない小規模なサービスなら、プロバイダーのダッシュボードに加えて、自前でスキーマ適合率と切り詰め率だけログに追加する構成で十分です。
複数プロバイダーや複数モデルをルーティングして使い分けている構成なら、ルート単位の可用性とレイテンシ分布を必ず分離して記録すべきです。平均値だけ見ていると障害ルートが隠れます。
エンタープライズ向けに契約済みSLAがあり、障害時の責任分界点を明確にする必要がある場合は、前述の19項目のような体系立った品質チェックリストを社内監視設計のたたき台として参照する価値があります。ただし、それらが「提案段階の基準」であり、実際の評価結果や合否判定そのものではない点は確認しておく必要があります。採用プロバイダーの公開ドキュメントで、どの指標が自社の契約上の稼働率定義と一致するか照らし合わせてください。
あえて見送るべき条件
月間のAPIコール数が少なく、障害が起きても人手で原因を追えるほど小規模な場合は、重厚な指標体系を最初から入れる必要はありません。オーバーエンジニアリングになりがちです。
また、単一プロバイダーのマネージドサービスにすべてを任せ、SLA違反時の金銭的補償条項に満足している場合も、自前の詳細計装にリソースを割く優先度は下がります。まずはプロバイダー側の既存ダッシュボードとアラート機能を使い切れているか確認するのが先です。
まとめ
LLM APIの障害は「モデルが悪い」の一言で片付けず、出力の完全性・応答速度・失敗の帰属先・運用コストの4軸で切り分けると原因が見えやすくなります。
次の一歩として、まず自社のログにスキーマ適合率と切り詰め率のタグが付いているか確認してみてください。付いていなければ、そこが最初に手を入れるべき監視項目です。
複数プロバイダーを使っている場合は、可用性の数値がルート単位で分離されているかも併せて見直す価値があります。