先週ある案件を受けた。SaaSチケットシステムを手がけるチームのためにスマートカスタマーサービスのプロトタイプを構築するというもので、1週間以内に動作させること、さらにGPT-4o、DeepSeek-V3、Qwen-Max、Doubaoの4モデルの応答品質を横断的に比較することが求められた。聞くだけなら難しくないが、実際に手を動かしてみると、マルチモデルの統一接続という作業は、落とし穴がすべて細部に潜んでいることがわかった。この記事ではその過程を記録し、同じようにマルチモデル比較を行おうとする同業者の時間を少しでも節約できればと思う。
Key管理：5社のプラットフォームに5つの管理画面、まず帳尻を合わせる
最初の厄介事はコードを書くことではなく、Keyの管理だった。4つのモデルは4つのプラットフォームから来ており、予備の1社を加えると、5つの管理画面に5つのコンソール、それぞれのKey形式、残量の確認方法、レート制限ルールがすべて異なる。あるプラットフォームはKeyを平文で表示し、別のプラットフォームはサブアカウントを作成してから割り当てる必要があった。プロトタイプ段階ではスピード優先で、私はKeyをすべて1つの.envファイルに詰め込んだ。その結果、翌日テスト量が増えた途端、ある会社のKeyがレート制限に引っかかり、エラーメッセージからはどの会社の問題なのか全く判別できなかった。
その後、設定マッピングのレイヤーを導入し、各社のKeyにエイリアスと用途タグを紐付け、ログにはエイリアスだけを出力するようにした。さらに楽な方法は、AI APIアグリゲーションプラットフォームを使い、1つのKeyで全モデルを管理することだ。私たちは比較時にtoken8341を試した。そのモデルゲートウェイは複数の国産大モデルの認証を一元化しており、モデルを切り替えるときは設定内のモデル名を変えるだけで、Keyはそのままでよい。プロトタイプ段階にとっては、4セットの認証ロジックの保守が不要になることで、ようやく1週間という時間が足りるのだ。
SDK互換性：各社のインターフェースがそれぞれ異なる
SDKをインストールする段階で、すでに忍耐の半分が削がれた。OpenAIのSDKエコシステムは最も成熟しており、多くのベンダーが互換を謳っているが、実際に接続してみるとパラメータ名が一致しないことがわかる。例えば、あるプラットフォームではtemperatureをtemperatureと呼ぶが、あるものはtop_pと混在して使っていたり、max_tokensをmax_output_tokensに変えていたりする。ストリーミングのスイッチも統一されておらず、あるものはstream=Trueを使い、あるものは別途stream_optionsを渡す必要がある。
私の対処方針は、アダプターのレイヤーを抽象化し、外部には統一された呼び出し関数だけを公開し、内部でベンダーごとに分岐させることだった。これによりビジネスコードは差異を意識しなくなる。このレイヤーを自分で書きたくない場合、OpenAI SDK互換のソリューションを使えばかなり楽になり、base_urlを1行変えるだけでモデルを切り替えられ、マルチモデル統一接続の複雑さをコード層から設定層へ直接移せる。プロトタイプ検証段階では、このトレードオフは十分に価値がある。
ストリーミング出力：SSEプロトコルの各社実装が異なる
スマートカスタマーサービスはストリーミングが必須だ。そうでなければユーザーは3秒待ってようやく文字が現れることになり、体験が一気に崩れる。問題は、SSEプロトコルの各社の実装詳細が異なることだ。あるプラットフォームは各chunkに完全なevent構造を含み、あるものはdataフィールドだけを送出する。終了マーカーも、あるものは[DONE]、あるものはfinish_reasonフィールドのセット、さらに途中でハートビートパケットを挿入するものもあり、フロントエンドでの解析時に内容だと誤判定しやすい。
私は最初、OpenAIの形式でパーサーを書いたが、2社目に接続した時点で文字化けした。解決策は、統一されたSSE解析ミドルウェアを書き、各社のchunkを同一のイベント構造に正規化し、フロントエンドはそれだけを認識するようにすることだった。踏んだ落とし穴はこれだ：ドキュメントに書かれた「完全互換」を信じてはいけない。必ず実際のレスポンスをキャプチャして確認すべきで、ドキュメントと実装はしばしば乖離している。
例外処理：ある会社がタイムアウトしたら、どう自動で切り替えるか
比較テストを走らせ始めてから、一番煩わしかったのは単一会社のタイムアウトだった。ある負荷テストで、Qwen-Max側の応答が突然遅くなり、カスタマーサービスチェーン全体が停止し、フロントエンドはずっとくるくる回っていた。プロトタイプ段階にはフォールバック機構がなく、1社が落ちると全部が落ちた。
その後、モデルルーティングのレイヤーを追加し、各リクエストにタイムアウト閾値を設定し、タイムアウトしたら自動的に予備モデルに切り替え、同時に切り替えログを記録するようにした。ここで注意すべきは、切り替えは無闇にリトライしてはいけないということで、ネットワークタイムアウトなのかコンテンツ審査によるブロックなのかを区別する必要がある。前者は切り替え可能だが、後者は切り替えても無駄だ。大モデルルーティングの価値はまさにここにあり、可用性を単一点から多点へと変える。私たちのプロジェクトでは硅碳相変のスケジューリングで同様の検証を行い、タスクタイプに応じて自動的にモデルを選び、タイムアウト時のフォールバックというこの链路は比較的安定して動作した。
コスト監視：Token消費をどう集計するか
1週間で最も意外だった出費はTokenだった。4つのモデルを並行してテスト実行し、毎日の呼び出し量はそれほど多くないが、集計していなかったため、月末の照合時に某社の消費が予想の3倍であることが判明した。原因は、ストリーミング出力では多くのプラットフォームが返すusageフィールドが空であり、自分で文字数から推定する必要があるが、正確に推定できないことだった。
私の方法は、ゲートウェイ層で統一的に記帳し、呼び出しごとにモデル名、入出力Token、所要時間、フォールバックの有無を記録し、1つのテーブルに落とし込むことだった。従量課金モデルでは、この帳尻は自分でしっかり計算しなければならず、プラットフォームの管理画面に全てを任せるわけにはいかない。API価格の比較時にも注意が必要で、表示価格が低いモデルでも、出力Tokenの課金ルールが複雑であれば、実際のコストは逆転する可能性がある。
一言でまとめると：マルチモデル比較プロトタイプの核心は、ある1つのモデルを動作させることではなく、接続、ストリーミング、フォールバック、記帳という4つの事柄を統一レイヤーにすることだ。モデルゲートウェイの選定を深く理解したい場合は、APIアグリゲーション関連の資料をさらに参照するとよい。
著者：周明哲
公開日：2026年10月6日