OpenRouterと直接接続の比較：LLMの呼び出し方法を選ぶ

LLM呼び出しを本番運用する方法

1）プロバイダーのAPIを直接利用

単一ベンダーのエンドポイントと連携し、それ以外のリトライ、フォールバック、使用量の追跡、キーのローテーション、フェイルオーバーはすべて自分たちで管理します。

次のような場合には、これが最もシンプルな方法です。

• 使いたいモデルがすでに決まっている、
• レイテンシーが重要である、
• コンプライアンス上、関与するベンダーを少なくしたい、
• そして、単一プロバイダーの制限を踏まえて計画できるほどトラフィックが安定している。

2）ゲートウェイ／アグリゲーター／リレー

リクエストを中間層に送り、その中間層が複数のプロバイダーのいずれかに転送します。OpenRouterは最もよく知られた例ですが、この仕組みは特定の企業に限られるものではありません。

次のような場合に魅力的な選択肢です。

• 単一の連携で複数のモデルを選べるようにしたい、
• フォールバックルーティングが必要である、
• モデルの実験を頻繁に行う、
• または、複数のベンダーのSDKや請求アカウントを管理したくない。

3）セルフホスト

自社のインフラでオープンモデルを実行します。通常は、自社のルーターを介して利用します。

次のような場合に最も有利です。

• データの管理権を譲れない、
• ハードウェアを継続的に稼働させられるほど処理量が多い、
• または、トークン単位の採算を予測可能にする必要があり、運用負担を引き受けられる。

実際の運用で変わること

見落とされがちなのは、次の点です。 最適な選択は、通常、単純なトークン価格だけでは決まりません。重要なのは、障害に至る連鎖全体です。

この表からは見えない重要な事実があります。 ゲートウェイが魔法のようにコストを削減してくれることは、ほとんどありません。コスト削減につながるのは、過剰な設計を防ぎ、ダウンタイムを減らし、要件を満たす最も安価なモデルへタスクを自動的に振り分けられる場合です。

実際にコストが変わるところ

すべてに同じモデルを使うなら、直接呼び出す方法が最もシンプルで安価なことが多いでしょう。ただし、実際のシステムの多くはもっと複雑です。

• プロダクト内のチャットには高性能なモデルを使い、
• サポート返信の下書きには安価なモデルを使い、
• 要約には小型で高速なモデルを使い、
• さらに、トラフィックが急増したときには追加の処理容量が必要になります。

そこで役立つのが中継サービスです。表示価格が安いからではなく、ルーティングの判断を一元化できるからです。

単純なポリシーは、次のようになります。

{
  "primary": "anthropic/claude-sonnet-4.6",
  "fallbacks": [
    "openai/gpt-5.5",
    "google/gemini-3"
  ],
  "cheap_path": "openai/haiku-class",
  "timeout_ms": 8000,
  "retry_on": ["rate_limit", "timeout", "upstream_5xx"]
}

この設定は特定のベンダーに依存するものではなく、適切なルーターの基本形です。実際のコスト削減は、無駄を避けることから生まれます。

• すべての抽出タスクを最も高価なモデルに送らないこと、
• 不安定なプロバイダーへのリトライを際限なく続けないこと、
• 金曜日に急増する2%のトラフィックのためだけに、別の連携を維持しないことです。

よくある落とし穴は、 アプリにツール呼び出しや副作用がある場合、リトライによって同じ操作が重複して実行される可能性があることです。ゲートウェイがタイムアウト後にリクエストを再試行すると、モデルが同じ関数呼び出しを再び出力する可能性があります。冪等性キーと慎重なツール設計がなければ、「便利なフォールバック」が「チケットの重複作成」や「二重請求」に変わってしまいます。

ゲートウェイが本当に役立つ場面

次の条件のいずれかに当てはまるなら、私はアグリゲーターや中継サービスを選びます。

• ワークロードの特性をまだ把握している段階である。 初期段階では、GPT-5.5、Claude Opus 4.8、Sonnet 4.6、Gemini 3、あるいはオープンモデルのどれが自分のタスクに最適かはわかりません。
• ベンダーではなく、タスクに応じてルーティングしたい。 分類器を使えば、短いプロンプトを安価で高速なモデルに送り、長いコンテキストを扱う処理は、実際に適している場合にFable 5のようなモデルへ送れます。
• 迅速にフォールバックできる仕組みが必要である。 あるプロバイダーがレート制限をかけ始めても、中継サービスならユーザーが気づく前にトラフィックを切り替えられます。
• 複数の請求システムを管理したくない。 請求書と連携先をそれぞれひとつにまとめるほうが、複数のキー、クォータ、利用額ダッシュボードを管理するより簡単です。
• マルチテナント製品向けの抽象化が必要である。 ゲートウェイを使えば、アプリを書き直さずに内部のプロバイダーを切り替えられます。

これは、特に小規模なチームに役立ちます。私は、スタートアップのチームがプロダクトの価値を生み出すよりも、プロバイダー固有のリトライ処理を組み込むことに多くの時間を費やすのを見てきました。中継サービスを使えば、その作業をひとつの場所に集約できます。

直接呼び出しのほうが適している場面

次のいずれかを重視する場合、通常はプロバイダーのAPIを直接使うほうが有利です。

• 最小限のレイテンシ。 プロダクトで許容される応答時間が短い場合、経由する箇所を減らすことが重要になります。300ミリ秒で「瞬時に感じる」操作を実現したいなら、ネットワークとルーティングの追加負荷が、その時間のかなりの部分を消費しかねません。
• 厳格なコンプライアンス上の境界。 処理者が増えるたびに、関係先、データ保持ルール、契約審査も増えます。
• ベンダー固有の機能。 プロバイダーによっては、アグリゲーターが共通化の過程で省いてしまう機能や、対応が遅れている機能を提供しています。
• 大量で予測可能な利用。 利用量が安定すれば、中間レイヤーに料金を支払うより、独自のルーティングのほうが安くなる場合があります。
• 明確なサポート窓口。 何かが故障したときに、責任の押し付け合いが少なくなります。

見落とされがちな利点は、運用上の見通しがよくなることです。呼び出し経路が直接的なら、障害の根本原因を切り分けやすくなります。失敗した場合、原因はたいてい自分のコードかプロバイダーです。ゲートウェイを使う場合は、中継サービス、そのルーティングレイヤー、上流のプロバイダーのどこに原因があったのかも確認する必要があります。

セルフホスティングは別の課題

オープンモデルのセルフホスティングは、単なる「自分のサーバーで動く安価なAPI」ではありません。システム全体に関わる課題です。

次の点を考慮する必要があります。

• GPUのサイジングと稼働率、
• バッチ処理、
• 量子化、
• KVキャッシュへの負荷、
• オートスケーリング、
• ウォームスタート、
• 安全性フィルター、
• モデルの更新、
• そしてロールバック手順です。

利点は制御できることです。ワークロードが安定していて十分な規模があるなら、セルフホスティングは経済的に魅力的な選択肢になります。ただし、採算が合うのはハードウェアを継続的に稼働させられる場合だけです。遊休状態のGPUには高いコストがかかります。高負荷の状況でもモデル配信基盤を正常に動かすためのエンジニアリング時間も同様です。

もうひとつのよくある落とし穴は、品質の変動です。現時点では要約に十分使えるオープンモデルでも、プロンプトの長さ、文体の要件、ツールの使い方が変わると、評価結果が大きく崩れる可能性があります。「オープン」だからといって、自動的に「マネージドAPIを置き換えられるほど安価」になるとは考えないでください。

実用的なハイブリッド構成

実際のシステムでは、複数の方式を組み合わせたアーキテクチャが最適なことがよくあります。

# direct path for latency-sensitive traffic
export LLM_ROUTE=direct
export LLM_PROVIDER=anthropic
export LLM_MODEL=claude-sonnet-4.6

# relay path for experimental or burst traffic
export LLM_ROUTE=gateway
export LLM_MODEL=openai/gpt-5.5

そして、アプリ内では次のようにします。

def choose_route(task_type, tenant_tier, prompt_tokens):
    if task_type == "tool_calling":
        return {"route": "direct", "model": "anthropic/claude-sonnet-4.6"}
    if prompt_tokens > 120_000:
        return {"route": "gateway", "model": "openai/gpt-5.5"}
    if tenant_tier == "free":
        return {"route": "gateway", "model": "openai/haiku-class"}
    return {"route": "direct", "model": "google/gemini-3"}

この構成なら、クリティカルパスをシンプルに保ちつつ、ルーティングの柔軟性も確保できます。私の経験では、本番運用を始めて最初の月を過ぎた頃に、多くのチームがこの形に落ち着きます。主要なUXには直接呼び出し、実験や処理容量を超えたトラフィックにはゲートウェイを使い、セルフホスティングは経済性やプライバシー上の利点が明白な場合に限ります。

プライバシー、レイテンシ、信頼

ここからは、エンジニアリングがポリシーの問題になります。

プライバシー

ゲートウェイを使うと、信頼境界が変わります。プロンプトが上流に転送されるだけであっても、次の問いに答える必要があります。

• 中継サービスはプロンプトをログに記録しますか？
• どのくらいの期間保持されますか？
• どの再委託先が閲覧できますか？
• 特定のテナントを制限された経路に留められますか？
• リージョンの固定に対応していますか？

規制対象のワークロードでは、「プロバイダーが適切な対応を約束した」だけでは不十分です。文書による記録と、それに合致する設計が必要です。

レイテンシ

中継サービスを使うと、経由する箇所が増えます。それだけでアプリが遅くなるわけではありませんが、不確実性は増します。アプリでやり取りが頻繁に発生し、トークンのストリーミングが重要なら、レイヤーが増えるたびに最初のトークンが届くまでの時間を予測しにくくなる可能性があります。

レート制限

直接連携では、プロバイダーの制限がそのまま適用されます。ゲートウェイは複数のプロバイダーにトラフィックを分散して影響を和らげられますが、独自の制限を設ける場合もあります。つまり、ある制限を別の制限に置き換えるだけかもしれません。利点は柔軟に処理容量を拡張できることであり、制限を免れることではありません。

私が使う判断基準

選び方をひとつの文にまとめるなら、次のようになります。 使うモデルが決まっていて呼び出し経路を重視するなら直接呼び出しを、選択肢の確保と耐障害性を重視するならゲートウェイを、制御性と安定した稼働率が運用コストに見合うならセルフホスティングを選びます。

具体的な目安をいくつか挙げます。

• 初めての本番機能をリリースし、必要なモデルがひとつだけなら、直接呼び出しから始めます。
• 異なる種類のモデルが複数必要になったとき、またはインシデントの振り返りでフェイルオーバーが課題になり始めたときに、ゲートウェイを追加します。
• セルフホスティングは、実際の稼働率のデータがあり、基盤を自ら保有する明確な理由がある場合に限ります。
• ルーティングの実験にはゲートウェイを使い、クリティカルパスでは冪等性を保ちます。
• トークン単価だけでなく、エンドツーエンドのコストを測定します。

実践上のポイント

• 優先的に選ぶのは 直接API です。余計なレイテンシを最小限に抑え、デバッグを簡単にし、ベンダー固有のサポートを最大限に受けられます。
• 優先的に選ぶのは ゲートウェイ／アグリゲーター です。複数モデルへのルーティング、フォールバックの確保、多数のプロバイダーとの連携の一本化が必要な場合に適しています。
• 優先的に選ぶのは セルフホスティング は、ハードウェアを継続的に稼働させられ、運用の複雑さを受け入れられる場合に限ります。
• 確立するのは 冪等性と適切なリトライ運用 です。自動フォールバックを追加する前に整えてください。
• 比較する 総コスト：トークン、上乗せ料金、リトライ、エンジニアリング時間、インシデントからの復旧。
• 次の値を保持してください： プライバシーとデータ保持 は、調達部門から確認されてからではなく、最初から判断に組み込んでください。
• 採用するのは ハイブリッドアーキテクチャ ワークロードにプレミアムな処理経路と汎用的な処理経路の両方がある場合。

ご希望であれば、スタートアップの開発者、プラットフォームチーム、コンプライアンス要件の厳しいエンタープライズチームなど、特定の読者層に向けて、より明確な見解を打ち出した内容に書き換えることもできます。