先にに結論を言うう：モデルゲートウェイは「複数のAPIをつなぐ」ほど単純なものではなく、自ら障害に耐えなければならないインフラ層である。数年前、私たちはオンライン問診を手がけるプラットフォームのAI接続を担当し、スマートカスタマーサポートは単一のモデルAPI上で動いていた。ある火曜日の午前2時過ぎぎ、上流が504を返し始めた。SDKはデフォルトで3回リトライし、指数バックオフするが、ビジネス側は同時に数千のセッションを並行処理しており、リトライ量は瞬く間に通常リクエストの数倍に膨れ上がった。スレッドプールが埋まり、ヘルスチェックすらタイムアウトし、呼び出しチェーン全体がドミノのように倒れていった。事後の振り返りで、問題はモデル自体になく、すべての卵を一つのカゴに置き、ゲートウェイ層での受け止めが一切なかったことにあると分かった。
モデルゲートウェイは結局何を解決するのか
分解して見ると、ゲートウェイ層は4つのことを担う。マルチモデルルーティングは基本であり、同じ「カスタマーサポートQ&A」タスクでも、意図に応じて安価な国産モデルに振り分け、複雑な推論に遭遇したら上位モデルに回すことができる。レート制限とサーキットブレーカーは命綱であり、単一Keyが打ち破られる前に能動的に遮断する必要がある。プロトコル変換は最も過小評価されやすく、各社SDKのリクエストボディ、レスポンスボディ、エラー構造はすべて異なる。コスト帰属は帳尻を合わせられるかに関わり、どのビジネスライン、どのテナントがどれだけのtokenを消費したかを、個人単位まで分解できなければならない。
私たちのプロジェクトではtoken8341のモデルゲートウェイを使い、タスクごとに最適なモデルを自動選択する実践を行った。OpenAI SDKと互換性があり、base_urlを一行変えるだけで切り替えられる。この特性は既存システムにとって特に優しく、コード内の数十箇所の呼び出しポイントをすべて書き換える必要がない。SiCore TokenWorksがこの層で行っていることは、本質的にAI API集約の複雑さをゲートウェイ内部に集約することである。
SSEストリーミング出力のプロトコルの落とし穴
ストリーミング出力は落とし穴の重災区である。表面的にはどれもSSEだが、実際の差異は小さくない。チャンク戦略では、token単位で切るベンダーもあれば、文単位で切るベンダーもあり、さらに一つのセグメントに複数のデータブロックを詰め込むベンダーもある。終了标志はさらに混沌としており、OpenAIスタイルはdata: [DONE]を使うが、他のベンダーは直接ストリームを切断して标志を出さない。エラーコードも統一されておらず、タイムアウトが429であったり、503であったり、あるいは200レスポンスの中にエラーオブジェクトを伴うこともある。
ゲートウェイ層では正規化が必要だ：標準SSE形式に統一変換し、終了标志を補完し、各社のエラーコードを一つの内部エラー列挙にマッピングする。こうすれば上位ビジネスは一種類のストリームだけを扱えばよい。聞こえは泥臭い作業だが、この層をやらなければ、各ビジネスチームが同じ落とし穴を繰り返し踏むことになる。
レート制限はどう設定すれば誤爆しないか
トークンバケットは滑らかなレート制御に適し、バケット容量がバースト許容度を決め、補充レートが長期的な平均値を決める。スライディングウィンドウは統計型のレート制限、例えば「毎分N回以下」に適している。実際の本番では私たちは両方を使う：入口はスライディングウィンドウで粗粒度の保護を行い、単一Key次元はトークンバケットで精密制御を行う。
マルチKeyローテーションはもう一つの鍵である。同じベンダーで複数のKeyを申請し、ゲートウェイが重み付けでラウンドロビンし、あるKeyがレート制限に引っかかれば一時的に除外し、クールダウン期間後に戻す。これにより単一Keyのクォータ制限が直接ビジネスの天井になることを防げる。注意すべきは、ローテーションは必ずサーキットブレーカーと組み合わせる必要があり、そうでなければ一つの不良Keyが繰り返し選択されることである。
フォールバックとマルチアクティブ：RPOとRTOをどう定めるか
メインモデルがタイムアウトしたら自動的にバックアップモデルへ切り替える。この動作は速くなければならない。私たちは内部的にRTOを「障害検知からトラフィック切り替えまで」の時間と定義し、目標を秒単位に抑えている。RPOはセッション状態を対象とし、理想はゼロロスだが、ストリーミングのシナリオではすでに吐き出された内容はロールバックできず、後続リクエストが中断しないことだけを保証できる。バックアップモデルの選択は能力の整合性を考慮すべきで、メインモデルが長文推論を行い、バックアップモデルが短いQ&Aしかできないなら、切り替えは機能不全への降格に等しい。
落とし穴回避の注意：リトライロジックをビジネスコードに書いてはいけない。SDK内蔵のリトライはゲートウェイ層の外にあり、障害時にはゲートウェイのサーキットブレーカー戦略と衝突する。リトライは統一的にゲートウェイに集約すべきで、ビジネス側は成功か最終失敗だけを受け取る。
一言うでまとめると、モデルゲートウェイの価値は、マルチモデル統一接続、レート制限、プロトコル正規化、フォールバックという泥臭い作業を集中的に処理し、ビジネスコードをクリーンに保つことにある。さらに言うえば、もしあなたがAI APIゲートウェイの選定を行っているなら、base_urlを一行変えるだけで接続できるか、そして障害時の切り替え戦略が設定可能かどうかを重点的に見るべきである。
著者：陳景行
公開日：2026年10月4日