LLM（大規模言語モデル）を組み込んだシステムの基盤設計を任されているSREやインフラ担当の方に向けた内容です。GPUコストの高騰、モデル更新のたびに揺れるレイテンシとコスト、ベンチマークの数字と実運用の乖離。こうした違和感を抱えたまま次のアーキテクチャ判断を迫られている方の参考になれば幸いです。
1980〜90年代のPC業界には「Wintel」と呼ばれる構造がありました。Intelが高性能・高価格のCPUを作り、Microsoftがそれに応じて重いOSやアプリを出す。結果として利用者は同じ作業をこなすためだけに、延々とハードウェアを買い替え続ける羽目になりました。今のAI業界でも、NvidiaのGPUを筆頭に高価な計算資源を、OpenAIやAnthropic、Googleといった各社のモデルが食いつぶす構図が指摘されています。ベンチマーク（性能評価指標）は毎回更新されますが、実際の本番環境ではレイテンシがわずかに縮まる程度で、劇的な改善は感じにくいという声もあります。
この構図が意味するのは、LLM APIへの依存度を上げるほど、将来のコストとロックイン（特定ベンダーへの依存で乗り換えが困難になる状態）のリスクを背負い込むということです。SREの立場からは、この依存をどこまで許容し、どこから自前のインフラ設計で吸収するかを判断する必要があります。
どんな場面でこの判断が必要になるか
次のような場面で、LLM依存の設計判断が必要になります。
- 新規プロダクトにLLM APIを組み込む際、単一ベンダーに全処理を任せるかマルチベンダー構成にするか決めるとき
- 既存システムでモデルのバージョンアップ（例: GPT系やClaude系の新モデル）が来るたびにコストとレイテンシが変動し、SLO（サービスレベル目標）維持が難しくなっているとき
- GPUインフラをクラウド上で確保する契約を更新するとき
- 障害対応の運用フローにLLM呼び出しを組み込み、依存先の障害がサービス全体に波及するリスクを評価するとき
いずれの場面でも「今のベンチマークの良さ」ではなく「1〜2年後の運用コストと可用性」を軸に判断する視点が求められます。
判断軸を整理する
軸1: コスト弾力性
LLM APIの料金体系は、トークン数・モデルバージョン・リクエスト量によって変動します。
価格改定や新モデルへの移行が起きたとき、既存のコスト試算がどれだけ崩れるかを事前に見積もっておく軸です。
たとえば、旧モデルが廃止予定になり新モデルへの移行が必須になった場合、単価が2倍になっても許容できる設計か、それとも即座に予算超過するかを確認します。TerraformなどのIaC（Infrastructure as Code、インフラ構成をコードで管理する手法）でGPUインスタンスやAPIゲートウェイの設定を管理していれば、コスト試算の前提条件をコードのコメントやvariablesファイルに明記しておくと、後から見直す際に役立ちます。
軸2: SLO維持可能性
LLM APIのレイテンシやエラー率は、自社が完全にコントロールできるものではありません。
外部ベンダーのモデル更新やインフラ障害によって、SLOの達成が突然難しくなるリスクをどう見積もるかという軸です。
具体的には、LLM呼び出しをクリティカルパス（サービスの成否を直接左右する処理経路）に置くか、非同期・フォールバック可能な位置に置くかを分けて設計します。オブザーバビリティ（システムの内部状態を外部から観測できる仕組み）ツールでLLM呼び出しのレイテンシとエラー率を独立したSLI（サービスレベル指標）として計測し、既存のSLOに影響が出た際にすぐ切り分けられる体制が前提になります。
軸3: ロックインの深さ
特定ベンダーのAPI固有機能（関数呼び出し・特定のプロンプト形式・専用のファインチューニング）にどれだけ依存するかという軸です。
Wintel時代のPC業界では、特定OS専用のアプリを作り込むほど、乗り換えコストが跳ね上がりました。LLM API依存でも同じ構造が起こり得ます。
たとえば、あるベンダーの関数呼び出し仕様に強く依存したプロンプト設計をしていると、他社モデルへの切り替え時に大幅な作り直しが必要になります。抽象化層（LLM呼び出しを共通インターフェースでラップする層）を用意しておくかどうかで、この軸への耐性が大きく変わります。
軸4: 障害対応の仕組み化のしやすさ
LLM API呼び出しの失敗や遅延を、既存の障害対応フロー（インシデント管理・オンコール体制）にどれだけ自然に組み込めるかという軸です。
外部APIのステータスページやエラーコードが、自社のアラート基準やランブック（障害対応手順書）とどれだけ整合しているかを確認します。
具体的には、LLM APIのレート制限エラーやタイムアウトを、既存のPagerDutyやOpsgenieなどのアラートルールにマッピングできるか、事前にテストしておくことが判断材料になります。
選択肢の比較
主な設計選択肢を整理すると、次のようになります。
| 選択肢 | コスト弾力性 | SLO維持 | ロックイン耐性 |
|---|---|---|---|
| 単一ベンダーAPIに直結 | 低い（価格改定の直撃を受ける） | ベンダー障害がそのまま自社障害 | 低い（API仕様への依存が深い） |
| 抽象化層+単一ベンダー | 中程度（切替準備はできる） | 切替の選択肢はあるが即応は難しい | 中程度 |
| マルチベンダー+ルーティング | 高い（安価なモデルへ動的振替可） | フォールバック先を持てる | 高い |
| 自前ホスティング（OSSモデル） | 初期投資は重いが長期的に安定 | 自社SREの運用力に依存 | 最も高い |
ケース別の推奨
プロトタイプや検証段階のプロジェクトなら、単一ベンダーAPIへの直結で十分です。ロックインの心配より、検証速度を優先すべき段階だからです。
既に本番稼働していてSLOを持つサービスなら、最低限「抽象化層+単一ベンダー」構成を推奨します。プロンプトや呼び出し処理を共通インターフェースでラップしておけば、価格改定やモデル廃止の際に切り替え作業を局所化できます。
LLM呼び出しがサービスの中核機能で、可用性要件が厳しいなら、マルチベンダー構成を検討する価値があります。コスト面でも、リクエストの性質に応じて安価なモデルと高性能なモデルを振り分けるルーティング層を持てば、コスト弾力性の軸を強化できます。
大量のリクエストを継続的に処理し、長期運用が前提のプロダクトなら、自前ホスティングによるOSSモデル運用も選択肢に入ります。ただしGPUインフラの調達・運用ノウハウ・オブザーバビリティの整備コストを、自社SRE体制が引き受けられるかが前提条件です。
あえて見送るべき条件
次のような条件では、マルチベンダー化や自前ホスティングへの投資を見送るのが妥当です。
- リクエスト量がまだ小さく、コストが誤差の範囲に収まっている場合
- チームにLLM呼び出しの障害対応ノウハウやオブザーバビリティ整備の余力がない場合
- プロダクト自体の方向性がまだ固まっておらず、LLM機能を頻繁に変更している段階の場合
- ベンチマーク上の性能差だけを理由にベンダーを増やそうとしている場合（実運用での差が確認できていない）
特に最後の項目は注意が必要です。ベンダー各社が公開するベンチマークは、実運用のデータの汚さ（未整備のレガシーデータ・ドキュメント化されていない業務ロジック）を反映していません。自社のログとオブザーバビリティデータで実際のレイテンシ・エラー率・出力品質を計測してから判断する方が、後戻りが少なくなります。
まとめ
LLM API依存の設計判断は、コスト弾力性・SLO維持可能性・ロックインの深さ・障害対応の仕組み化しやすさの4軸で整理すると見通しが立ちやすくなります。
まず着手できることとして、現在のLLM呼び出しがクリティカルパスにあるかどうかをオブザーバビリティツールで確認し、独立したSLIとして計測を始めてみてください。
そのうえで、抽象化層の有無・マルチベンダー化の必要性を、実際のトラフィックデータをもとに判断していく流れが、Wintel型の依存構造を繰り返さないための現実的な一歩になります。