先月引き継いだインテリジェントカスタマーサービスプロジェクトで、ビジネス側からDeepSeek、Qwen、Doubaoの3社の大規模モデルを同時に接続してほしいという要望がありました。理由は「安い方を使い、どれかがレート制限に引っかかったら別のに切り替える」というものです。聞く分には合理的ですが、実際にやってみると、3社のSDKの認証方式、課金基準、タイムアウトとリトライ戦略が完全に別物のロジックであることが分かりました。DeepSeekはBearer Token、QwenはDashScopeのAPI-KEYと署名、Doubaoはまた認証フィールドが異なります。課金では、入力と出力のtokenを分けて計算するもの、統合して計算するもの、キャッシュヒット時に割引があるものもあります。タイムアウトはさらに厄介で、ある社はデフォルト30秒、別の社は60秒、リトライ回数とバックオフ戦略も個別に書く必要があります。
コードを書き終えて数えてみると、3社のクライアントをラップするアダプテーション層だけで800行以上、エラーコードのマッピングは含んでいません。これが、昨年から国内のAIエンジニアリング界で「モデルゲートウェイ」という概念が繰り返し取り上げられている理由です。一言でまとめると、モデルゲートウェイとは複数の大規模モデルAPIの差異を吸収し、上位のビジネスに対して統一インターフェースを公開する中間層のことです。
直結、自社構築、アグリゲーションプラットフォーム——3つの方式のエンジニアリングコスト
まず公式SDKへの直結について。3社のモデルがあれば3套の認証、3套のエラー処理、3套のリトライロジックが必要です。ビジネスコードはどの社を使うかのif-else判定だらけになります。新しいモデルを追加するたびにアダプテーション層を修正しなければなりません。試算したところ、3社直結のアダプテーションコードの保守は、プロジェクトのバックエンド作業量のおよそ15%を占めます。モデル数が5社以上になると、この比率は制御不能になります。
自社構築ゲートウェイが2つ目の選択肢です。核心的な考え方は、自分でプロキシ層を書き、リクエストを各社APIへ転送するというものです。利点は制御可能なこと、欠点はプロトコル変換、キーローテーション、レート制限キュー、使用量統計を自分で処理しなければならないことです。社内で評価したところ、本番投入できる自社構築ゲートウェイには少なくともエンジニア2名で6〜8週間の投入が必要で、その後も各社APIのバージョン変更を継続的に保守しなければなりません。中小チームにとって、このコストは割に合いません。
3つ目はAI APIアグリゲーションプラットフォームです。こうしたプラットフォームは複数の大規模モデルAPIを統一的にラップし、外部に1套のインターフェースを提供します。エンジニアリングコストが最も低く、接続期間は通常日単位です。私たちのプロジェクトではSiCore TokenWorksを使用しており、OpenAI SDKと互換性があり、base_urlを一行変更するだけで切り替えられます。ここで注意すべき落とし穴が1つあります。アグリゲーションプラットフォームごとにタイムアウトとリトライのデフォルト戦略が異なるため、接続前に必ずカスタムタイムアウト時間をサポートしているか確認してください。そうでなければ、本番で偶発的に発生する長い応答のリクエストがプラットフォーム層で事前に切断され、エラーメッセージからもゲートウェイのタイムアウトなのかモデルのタイムアウトなのか判別できません。
モデルゲートウェイの4つの中核機能
プロトコルの正規化が基本です。各社のリクエスト形式、レスポンス形式、エラーコードを1套の標準に統一します。理想的な状態では、上位のビジネスは1つのインターフェース形式だけを認識し、モデルの切り替えはコードではなく設定の変更だけで済みます。これがOpenAI互換インターフェースが国内で普及している理由であり、エコシステムのツールチェーンは基本的にこの形式をサポートしています。
ルーティング戦略こそがゲートウェイの価値です。タスクタイプによるルーティング、たとえば簡単なQ&AはDoubao、複雑な推論はDeepSeekに回すことができます。コストによるルーティングで、現在価格が安い方に回すこともできます。可用性によるルーティングで、ある社がレート制限に達したら自動的にバックアップに切り替えることもできます。SiCore TokenWorksのマルチモデルルーティングをテストした際、タスクの複雑度による振り分け戦略が、カスタマーサービスシナリオで全体の呼び出しコストをかなり抑えられることが分かりました。大量の簡単な質問には推論能力が最も高いモデルを呼び出す必要がないからです。
レート制限・フォールバックと使用量の集約は本番環境の必須要件です。レート制限は429エラーを識別して自動的にキューに並べてリトライできる必要があり、フォールバックはある社のサービスが利用不可のときにバックアップモデルに切り替える必要があります。使用量の集約は、複数社に分散した呼び出し量、token消費、費用を統一的に集計し、コスト計算と予算管理を容易にします。この2つを自社構築すると作業量は小さくなく、特に使用量の集約は各社の課金基準が一致しないため、突合ロジックを個別に書く必要があります。
ビジネス成熟度に応じた段階的な導入
プロジェクトが始まったばかりで1社のモデルしか接続しないなら、公式SDKへの直結で十分で、ゲートウェイを導入する必要はありません。1層増えると障害点が1つ増えるだけです。ビジネスが安定し、2社目のモデルを接続する段階になってからゲートウェイ層の導入を検討すれば、この時点なら切り替えコストはまだ低いです。
ビジネスがすでに3社以上を接続し、可用性が求められるなら、AI APIアグリゲーションプラットフォームを直接導入し、アダプテーションと運用のコストを外部化することをお勧めします。選定時の重点は3点です。OpenAI SDKと互換性があるか、カスタムタイムアウトとリトライをサポートしているか、使用量統計が明確か。自社構築ゲートウェイについては、特別なコンプライアンス要件があるか、チームに十分な運用人員がある場合を除き、ビジネスの初期段階での投入はお勧めしません。
モデルゲートウェイが解決するのはマルチモデル接続のエンジニアリング複雑性の問題であり、モデル能力の問題ではありません。適切な方式を選べば、チームは精力をビジネスロジックそのものに戻せます。