プロトコルと変換境界
ゲートウェイはプロトコル間で変換できますが、万能な翻訳機ではありません。このページでは境界と、サポートされていない組み合わせに遭遇した場合の挙動を説明します。
4 種類の会話プロトコル§
GPT-Load は対等な 4 種類の会話プロトコルを受け付け、1 つのアクセスキーで複数を同時に許可できます。画像、埋め込み、リランキング、決定、リアルタイム音声にはそれぞれ独立したプロトコル権限があります。
- 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。Gemini ネイティブでは/v1beta/models/…:embedContentまたは:batchEmbedContentsを使用します。 - 画像生成と編集 —
/v1/images/generations、/v1/images/edits - token カウント —
/v1/messages/count_tokensと Gemini のcountTokens。 - テキストのリランキング：POST /v1/rerank。独立した rerank プロトコルを使い、ストリーミングやプロトコル変換には対応しません。
- JEV 決定：POST /v1/decisions。独立した decisions プロトコルを使い、Jev または OpenRouter がネイティブに実行します。
- Codex リアルタイム音声は独立した codex-live プロトコルを使います。Responses WebSocket の別のテキストモードではありません。
Gemini、New API、GPT-Load はネイティブの gemini-embeddings に対応します。Gemini チャネルでは、OpenAI Embeddings のテキストリクエストを Gemini のネイティブ一括埋め込みへ変換でき、dimensions と float／base64 出力に対応しますが、トークン ID 入力には対応しません。
GET /v1/models は anthropic-version リクエストヘッダーが空でない場合に Anthropic のモデル一覧を返し、それ以外は OpenAI Chat Completions 形式を返します。直接呼び出す場合はクライアントプロトコルに対応するヘッダーを付けてください。
ネイティブ検索は CLIProxyAPI・New API・GPT-Load チャネルで openai-responses プロトコルの POST /v1/alpha/search を使います。チャットのプロトコル変換ではなく、すべての上流アカウントが検索に対応するという意味でもありません。
変換がどのように行われるか§
クライアントプロトコルとアップストリームチャネルのプロトコルは必ずしも同じではない。たとえば Claude Code が Anthropic Messages で OpenAI チャネルを使う場合、ゲートウェイはリクエストを OpenAI 形式へ、応答を Anthropic 形式へ変換します。
変換はクライアントから透過的です。リクエストログで変換過程を確認できます。応答形式の問題を調べるときは最初に確認してください。監視とトラブルシュートを参照してください。
プロトコルが同じ場合は変換しないため、リクエストはほぼそのまま転送されます。遅延が最も小さく、互換性も高い経路です。
変換できない場合§
各チャネルは対応するプロトコルと機能を宣言します。ゲートウェイは宣言された機能間だけを変換し、任意のプロトコルや JSON を無理に別形式へ変換しません。
よくある変換失敗シナリオ：
- 対象チャネルはその機能をサポートしていません — たとえば、テキスト専用モデルへ画像生成を要求する場合です。
- プロトコル固有のパラメータに対応物がない — 1つのプロトコルにしかないパラメーターは、変換時に破棄または拒否される場合があります。
- モデル自体が対応していません — たとえば、画像入力に対応しないモデルへ画像を送る場合です。
この種の問題では最も直接的な解決策はクライアントプロトコルとチャネルプロトコルを一致させることです。Claude クライアントには Anthropic チャネルを組み合わせ、変換を減らします。
ステートフルリクエスト§
OpenAI Responses はprevious_response_id、conversation、既存リソース ID でコンテキストを継続できます。これらのリクエストには前提条件があります：
上流ストレージに対応するネイティブHTTP/SSE Responsesでは、返された応答IDを記録します。同じアクセスキーでprevious_response_idを指定すると、現在も許可された元の認証情報だけを使用します。ソフトアフィニティに影響されず、失敗時もアカウントを切り替えません。
変換・ステートレス・明示的なstore:falseの新規応答は登録しません。不明・期限切れ・削除済みのIDは、ゲートウェイ外やアップグレード前に作成したIDも含めてローカルで拒否します。正常終了時の保存に成功した場合のみ復元でき、クラッシュ復元は保証しません。
conversationや他のリソース操作は元の認証情報へ戻る保証がありません。認証情報1つのグループを使うか、上流の共有対応を確認してください。中継チャネルでは同じ次の接続先に戻ることだけを保証します。
GET /v1/responsesはOpenAI、Codex、xAI、GPT-Load、CLIProxyAPI、Sub2APIでネイティブWebSocketに対応します。接続は上流Sessionに固定され、Codexの継続は元の接続内のみです。WS→HTTP変換や再接続後のコンテキスト復元は保証しません。スイッチは実行時設定を参照してください。
Codex WebSocket では、生成中に同じ接続の現在の応答の response_id を指定して response.interrupt を送信できます。ゲートウェイは元の上流接続ですぐに転送し、中断が確認された後は previous_response_id で会話を継続できます。終了済みの応答に対する遅延・重複した中断は無視され、次のターンに影響しません。上流が中断を response.incomplete として返し、出力がなく output_tokens が 0 の場合は、引き続き接続が閉じられ、会話を継続できません。
もう1つの方法はステートフルインターフェースを使わず、毎回完全なコンテキストを送ることです。どの認証情報でも処理でき、負荷も均等になりますが、入力トークンは増えます。
CLIProxyAPI と New API の Responses 拡張透過転送には、応答の取得・削除・取消・入力項目・Input Tokens は含まれません。通常の previous_response_id による継続は引き続き上流の保存機能に依存します。未宣言のリソース機能を必要とする入力は、上流への試行なしにローカルで拒否されます。
どのプロトコルを使うべきか§
絶対的に優れたプロトコルはありません。用途に合わせて選びます：
- クライアントがすでに決まっている — 変換を最小化するためクライアントのネイティブプロトコルを使います。Claude Code は Anthropic、Gemini CLI は Gemini を選びます。
- 自分でコードを書く — Chat Completions は互換性が最も広く、アップストリームを切り替えやすい方式です。
- セッション状態が必要——Responses。応答IDの継続と他のリソース参照の制限は異なります。
AccessKeyでは複数のプロトコルを同時に選択できます。迷った場合は必要なプロトコルをすべて有効にしても、未使用のものに副作用はありません。設定はAccessKeyを参照してください。