2つの LLM を同じコードで呼ぶために、API 接続を一元化した話

2つの LLM を同じコードで呼ぶために、API 接続を一元化した話
最近、エージェント系の処理は GPT-5.6 Sol、長いドキュメントの読み込みは Claude Opus 5.5 というように、用途によってモデルを使い分けるようになりました。どちらも日々の開発ワークフローに欠かせなくなった一方で、同じプロジェクトから両方を呼ぼうとすると、思っていたより地味なコストが積み上がりました。この記事は、その接続まわりを整理したときのメモです。
直面した課題は3つありました。
1つ目はアカウントと請求まわりです。サービスごとに登録・チャージ・明細が分かれているため、複数アカウントと支払い手段を管理することになり、経理の突き合わせも別々に発生します。小さなチームほど、この手間が効いてきます。
2つ目はインターフェースの差です。リクエスト形式、パラメータ名、ストリーミングの返り方、エラーコードの定義がモデルごとに違うので、併用するには自前のアダプタ層が必要になります。モデルが増えるほど組み合わせも増え、1つ差し替えるたびに同じ修正を繰り返すことになりがちです。
3つ目は単一障害点です。上流を1つだけに固定していると、レート制限や障害のときに切り替え先がなく、アプリ側がそのまま止まってしまいます。開発中は再現しにくいので、原因の切り分けにも時間がかかります。
やったことは、このアダプタ層を1回だけにすることでした。
OpenAI 互換形式の統一エンドポイントを用意し、コード側の base_url をそのアドレスに向けて、発行された API キーに差し替えます。すると、もともと OpenAI SDK で書いていた呼び出し方のまま、GPT-5.6 Sol も Claude Opus 5.5 も、他の主要モデルも同じ書き方で呼べるようになりました。業務ロジックは書き換えず、モデルの切り替えは設定値1か所に集約されます。あわせてトークン使用量の統計と明細も1つの画面にまとまるので、請求まわりの確認がかなり楽になりました。
既存のツールチェーンとの相性も悪くありませんでした。
LangChain や LlamaIndex でエージェントを組む場合、基盤モデルは初期化時に指定することが多いので、設定を1か所変えるだけで差し替えられます。Cursor や VS Code なら、設定画面に API アドレスとキーを入れれば、エディタ上でコード生成やリファクタリングをそのまま使えます。function calling / tool calling も OpenAI 互換のままなので、既存のエージェント実装でツール層を書き直す必要はありませんでした。すでに OpenAI SDK で動いているプロジェクトほど、移行の手間は小さい印象です。
課金は従量制で、最低消費はありません。 使ったトークン分だけ計上されるため、チャージの档位に合わせて先に資金を置いておく必要がありません。複数モデルが1つのアカウントにまとまるので、サービスごとに残高を確認する作業も減ります。モデルの組み合わせをまだ試行錯誤している段階だと、このあたりは地味ですが効いてきます。
本番運用で気になるのは、回線の安定性です。 複数回線とキープールで上流を振り分け、1本が不調なときは別の回線へ流すようにしています。アプリ側で中断を感じる場面は減りました。成功率・レイテンシ・使用量のモニタリング画面もあるので、調子が悪いときの切り分けがやりやすくなっています。
まとめると、モデルごとの差分、請求、回線の揺れを接続層に押し込めると、アプリ側は業務ロジックだけを見ていればよくなります。モデルを1つ増やすたびにアダプタコードを足す、という作業からは解放されました。同じ悩みを持つ方の参考になれば嬉しいです。「うちはこうしている」という話もコメントで聞いてみたいです。
なお、今回の検証で使った統一 API サービス FLYSTAR は、私自身が運営に関わっているものです（いわゆるステマにならないよう明記しておきます）。詳細とリンクはプロフィール欄に置いてあります。