F-8: 単一プロバイダ vs マルチプロバイダ¶

この相反は何か¶

エージェントが利用するLLMプロバイダを1社に統一する（単一プロバイダ）か、複数社を併用する（マルチプロバイダ）かという二者択一です。ここでいう「プロバイダ」はLLM API提供元（OpenAI、Anthropic、Google、Azure OpenAI、AWS Bedrockなど）を指し、同一プロバイダ内の複数モデル（GPT-4oとGPT-4o-mini）の使い分けは含みません。

この選択が排他的として扱われる理由は、プロバイダ間の差異がインフラ・プロンプト・評価のすべてに波及するためです。各プロバイダはAPIの仕様（ツール呼び出しの形式、ストリーミングのプロトコル、構造化出力の対応）、料金体系、レート制限、可用性SLAが異なります。マルチプロバイダに移行するには、これらの差異を吸収する抽象化層を構築し、プロバイダごとのプロンプト調整・品質評価を維持する必要があり、運用コストが非連続的に増大します。

AIエージェント固有の事情として、プロバイダの可用性が不安定（F7）という力学があります。LLMプロバイダの障害やレート制限は、従来のSaaSと比べて頻度が高く予測しにくい傾向があります。可用性SLAが厳しいシステムでは、単一プロバイダへの依存がシステム全体の可用性を制約します。一方、マルチプロバイダは「プロバイダAがダウンしたらBにフォールバック」という冗長性を提供しますが、その代償として複雑性が増大します。

選択肢A：単一プロバイダ¶

1社のLLMプロバイダのみを利用し、そのプロバイダのAPIに直接統合します。プロンプトはそのプロバイダのモデル特性に最適化し、ツール呼び出しやストリーミングもプロバイダ固有のAPIをそのまま使います。

単一プロバイダの最大の利点は単純さと最適化の容易さです。抽象化層が不要なため、プロバイダ固有の機能（キャッシュAPI、バッチAPI、ファインチューニング、特殊な構造化出力モード）をフル活用できます。プロンプトのチューニングも1つのモデルファミリーに集中でき、品質評価も一元化されます。

キャッシュの効率も高いです。同一プロバイダの同一モデルであれば、プロンプトのプレフィックスキャッシュ（Prompt Caching）やコンテキストキャッシュを活用でき、コストとレイテンシを大幅に削減できます。マルチプロバイダではキャッシュがプロバイダ間で共有できず、キャッシュヒット率が低下します。

出力の一貫性も利点です。同一モデルを使う限り、出力の品質・スタイル・構造化の精度が安定します。プロバイダ間でモデルを切り替えると、微妙な出力の違い（JSONのフォーマット、数値の丸め方、文体の差異）がダウンストリームに影響しえます。

弱点はベンダーロックインと可用性リスクです。プロバイダが障害を起こすとシステム全体が停止します。料金改定やAPIの破壊的変更にも対抗手段がありません。長期的にはプロバイダの競争力の変化（新しいモデルの登場、性能の逆転）に対応できず、移行コストが蓄積します。

選択肢B：マルチプロバイダ¶

複数のLLMプロバイダを併用し、抽象化層を通じてリクエストを適切なプロバイダにルーティングします。フォールバック（プライマリがダウンしたらセカンダリへ）、コスト最適化（安い方を優先）、品質最適化（タスクに最適なモデルを選択）など、目的に応じたルーティング戦略を構成します。

マルチプロバイダの最大の利点は耐障害性とコスト最適化です。プロバイダAが障害やレート制限に達したとき、自動的にプロバイダBにフォールバックすることで、システムの可用性を維持できます。また、タスクの複雑さに応じて安価なプロバイダを選択したり、トラフィックを分散してレート制限を回避したりすることで、コストを最適化できます。

戦略的にも、ベンダーロックインを回避し、新しいモデルの登場や料金改定に対して交渉力を持てます。「いつでも切り替えられる」状態を維持することで、プロバイダ選択の自由度を確保します。

弱点は運用の複雑性です。具体的には以下が必要になります。

抽象化層の構築・維持：各プロバイダのAPIの差異（ツール呼び出しの形式、ストリーミングプロトコル、エラーコード体系）を吸収するアダプタが必要です。プロバイダがAPIを更新するたびにアダプタも更新が必要です。
プロバイダごとのプロンプト調整：同じプロンプトでもプロバイダによって品質が異なります。プロバイダごとにプロンプトを微調整し、品質を評価する必要があります。
フォールバック時の品質劣化の管理：プライマリからセカンダリにフォールバックした場合、品質が許容範囲に収まるかを事前に検証する必要があります。
監査・ログの統一：複数プロバイダのログ形式を統一し、リクエストの追跡を一元化する必要があります。

選定基準¶

選定は [provider_trust] と [cost_sensitivity] の2つの駆動変数で判定します。

マルチプロバイダに倒す条件：

[provider_trust] が低い：プロバイダの可用性SLAがシステムのSLA要件を満たさない、または過去に障害が頻発しています。
システムの可用性SLAが概ね99.9%以上で、単一プロバイダの可用性がそれを下回ります。
[cost_sensitivity] が高く、タスクの複雑さに応じたモデル選択でコストを最適化する価値があります。
規制やデータ主権の要件で、特定のリクエストを特定のリージョン/プロバイダに送る必要があります。

単一プロバイダに留まる条件：

[provider_trust] が高い：プロバイダのSLAがシステム要件を満たしており、過去の障害も許容範囲です。
プロバイダ固有の機能（キャッシュ、バッチAPI、FT）への依存が大きく、抽象化による機能喪失が許容できません。
チームの規模が小さく、複数プロバイダの運用・プロンプト調整・品質評価を維持するリソースがありません。
プロトタイプ段階で、可用性より開発速度を優先します。

デフォルトとハイブリッド¶

デフォルト：単一プロバイダで開始してください。 マルチプロバイダの運用コストは過小評価されがちです。ただし、最初から抽象化層を挟んで単一プロバイダを利用してください。抽象化層があれば、可用性やコストの問題が顕在化した時点で、2つ目のプロバイダを追加する移行が比較的容易です。抽象化層なしで直接統合すると、後からの移行コストが膨大になります。

ハイブリッド：抽象化層越しにマルチプロバイダが定石です。LiteLLM、AI Gatewayなどの抽象化層を導入し、プライマリプロバイダを通常時に使いつつ、障害時にセカンダリにフォールバックする構成です。フォールバック先の品質は事前に評価し、許容範囲に収まることを確認しておきます。A6 適応タイムアウト・リトライのサーキットブレーカパターンと組み合わせ、プロバイダの障害を自動検出してフォールバックします。

判断を誤ったときの症状¶

単一プロバイダを選ぶべきだったのにマルチを選んだ場合：

抽象化層の維持にエンジニアリング工数の相当部分が費やされ、本来のプロダクト開発が遅延します。
プロバイダごとのプロンプト調整・品質評価の負担が大きく、いずれかのプロバイダの品質管理がおろそかになります。
プロバイダ固有の機能（キャッシュ、バッチAPI）を抽象化層が吸収できず、「最大公約数」の機能しか使えなくなります。
実際にはフォールバックがほとんど発生せず、マルチ化のコストが可用性の改善に見合いません。

マルチプロバイダを選ぶべきだったのに単一を選んだ場合：

プロバイダの障害がシステム全体の停止に直結し、SLA違反が発生します。
プロバイダのレート制限に頻繁に達し、リクエストが大量にリジェクトされます。
プロバイダの料金改定に対して交渉力がなく、コスト増を受け入れるしかありません。
新しいモデルが他のプロバイダから登場しても、移行コストが大きく試せません。