プロトコルと変換境界
ゲートウェイはプロトコル間で変換できますが、万能な翻訳機ではありません。このページでは境界と、サポートされていない組み合わせに遭遇した場合の挙動を説明します。
4種類のプロトコル§
GPT-Load は4つのクライアントプロトコルを受け付けます。これらは独立したプロトコルで、1つのAccessKeyから複数を許可できます：
- OpenAI Chat Completions — 最も互換性が広く、多くの互換クライアントやサードパーティサービスが使います。
- OpenAI Responses — ステートフルな複数ターンの継続に対応する新しい API です。
- Anthropic Messages — Claude クライアント向けネイティブエンドポイントです。
- Gemini — Gemini クライアント向けネイティブエンドポイントです。
Chat Completions と Responses は二つの独立したプロトコルで、同じ API の旧版・新版ではありません。OpenAI プリセットは両方を有効にしますが、それぞれ独自のエンドポイントと機能があります。
プロトコルエンドポイント§
クライアントは各自のプロトコルの習慣に従ってアクセスし、パスにGroup名を含める必要はありません：
| プロトコル | 主なエントリーポイント |
|---|---|
| OpenAI Chat Completions | /v1/chat/completions |
| OpenAI Responses | /v1/responses およびそのリソースパス |
| Anthropic Messages | /v1/messages |
| Gemini | /v1beta/models/… |
対話以外に、これらのインターフェースも提供されます（可用性はアップストリームチャネルに依存します）：
- モデルリスト —
/v1/modelsと/v1beta/models。 - ベクトル埋め込み —
/v1/embeddings - 画像生成と編集 —
/v1/images/generations、/v1/images/edits - token カウント —
/v1/messages/count_tokensと Gemini のcountTokens。
変換がどのように行われるか§
クライアントプロトコルとアップストリームチャネルのプロトコルは必ずしも同じではない。たとえば Claude Code が Anthropic Messages で OpenAI チャネルを使う場合、ゲートウェイはリクエストを OpenAI 形式へ、応答を Anthropic 形式へ変換します。
変換はクライアントから透過的です。リクエストログで変換過程を確認できます。応答形式の問題を調べるときは最初に確認してください。監視とトラブルシュートを参照してください。
プロトコルが同じ場合は変換しないため、リクエストはほぼそのまま転送されます。遅延が最も小さく、互換性も高い経路です。
変換できない場合§
各チャネルは対応するプロトコルと機能を宣言します。ゲートウェイは宣言された機能間だけを変換し、任意のプロトコルや JSON を無理に別形式へ変換しません。
よくある変換失敗シナリオ：
- 対象チャネルはその機能をサポートしていません — たとえば、テキスト専用モデルへ画像生成を要求する場合です。
- プロトコル固有のパラメータに対応物がない — 1つのプロトコルにしかないパラメーターは、変換時に破棄または拒否される場合があります。
- モデル自体が対応していません — たとえば、画像入力に対応しないモデルへ画像を送る場合です。
この種の問題では最も直接的な解決策はクライアントプロトコルとチャネルプロトコルを一致させることです。Claude クライアントには Anthropic チャネルを組み合わせ、変換を減らします。
ステートフルリクエスト§
OpenAI Responses はprevious_response_id、conversation、既存リソース ID でコンテキストを継続できます。これらのリクエストには前提条件があります：
コンテキストはアップストリーム側にあり、通常は作成元の認証情報に紐づいています。別の認証情報へ切り替えてリクエストすると、アップストリームは以前のセッションを見つけられません。
現在のセッションアフィニティはプロンプトのプレフィックスに基づき、previous_response_id、conversationなどのリソース ID を参照しないため、強い整合性を持つルーティングは保証できません。ステートフルなリソースを確実に利用するには、Group の認証情報を1つだけにするか、異なる認証情報間で同じリソースを共有できることをアップストリーム側で確認してください。
もう1つの方法はステートフルインターフェースを使わず、毎回完全なコンテキストを送ることです。どの認証情報でも処理でき、負荷も均等になりますが、入力トークンは増えます。
どのプロトコルを使うべきか§
絶対的に優れたプロトコルはありません。用途に合わせて選びます：
- クライアントがすでに決まっている — 変換を最小化するためクライアントのネイティブプロトコルを使います。Claude Code は Anthropic、Gemini CLI は Gemini を選びます。
- 自分でコードを書く — Chat Completions は互換性が最も広く、アップストリームを切り替えやすい方式です。
- セッション状態が必要 — Responses を使い、セッションアフィニティを有効にします。
AccessKeyでは複数のプロトコルを同時に選択できます。迷った場合は必要なプロトコルをすべて有効にしても、未使用のものに副作用はありません。設定はAccessKeyを参照してください。