ドキュメント/ 設定

Groupとチャネル

Groupには、接続先のサービス、認証情報プール、公開モデル、実行ポリシーなど、アップストリーム接続に必要な設定がまとまっています。

Groupとは§

1つのGroupは1つのアップストリームサービスに対応し、認証情報プールを持ちます。リクエストごとに利用可能な認証情報を選び、レート制限中または無効な認証情報は自動的に避けて別のものを使います。

GroupとAccessKeyの役割は基本概念を参照してください。要約すると、Groupはアップストリームに接続し、AccessKeyはアプリケーションを認可します。

35 の組み込みチャネル§

Group作成時にこれらの中から一つを選択します。よく使うチャネルはボタンとして直接表示され、その他のチャネルは「その他のチャネル」に収められます。異なるカテゴリーの認証情報の形態は異なります:

カテゴリチャネル認証情報の種類
公式 APIOpenAI · Anthropic · Gemini · xAIAPIキー
クラウドプラットフォームAzure OpenAI · AWS Bedrock · Google Vertex AIプラットフォーム認証情報(AK/SK またはサービスアカウント)
モデルサービスDeepSeek · Moonshot AI · SiliconFlow · Zhipu AI · Alibaba Cloud · Volcengine · OpenRouter · Cline · Groq · Jev · Cerebras · Mistral · Nebius · Parasail · Wafer · Hugging Face · Cohere · OpenCode Go · OpenCode ZenAPIキー
サブスクリプションアカウントCodex · Claude · Antigravity · GrokOAuth 認可
ゲートウェイ・互換GPT-Load · New API · CLIProxyAPI · Sub2API · OpenAI CompatibleAPI キー + ゲートウェイ Base URL

各チャネルは対応するプロトコルと機能を宣言します。ゲートウェイは対応する機能間を変換しますが、万能な変換器ではありません。境界はプロトコルと変換境界を参照してください。

チャネル別対応マトリクスを見る →

Groupを作成§

グループ → 新規グループを開きます。入力する中心項目は、チャネル、認証情報、モデルの3つだけです。

FIG. 1 — Group一覧各Groupには1つのアップストリームがあります

アップストリームサービスごとに1つのGroupを作成します。同じプロバイダーの複数のキーは分割せず、そのGroupにまとめてください。

チャネルパラメータ§

既存の API キーグループは、詳細設定で別の API キーチャネルへ切り替えられ、認証情報の再インポートは不要です。サブスクリプショングループはこの方法では切り替えられません。変更前に対象チャネルとの認証情報の互換性、維持されるカスタムアドレス、モデル設定を確認してください。

チャネルを選択した後、フォームにそのチャネル固有のパラメータが表示されます。一般的なものは:

  • エンドポイント URL — 公式チャネルにはデフォルト値があります。中継サービスまたは自前のサービスを使う場合だけ変更します。
  • ゲートウェイ Base URL — GPT-Load、New API、CLIProxyAPI、Sub2API には Base URL またはデプロイ接頭辞を入力し、/v1、/v1beta、クエリパラメータは付けません。
  • リージョン — AWS Bedrock や Google Vertex AI などのクラウドプラットフォームではリージョンを指定します。
  • デプロイメント名 — Azure OpenAI のモデルデプロイ識別子です。

これらの値が誤っていると、通常はすべてのリクエストが失敗します。監視とトラブルシュートのルートチェックで、候補になったGroupと現在利用可能な認証情報数を確認できます。

認証情報プールの管理§

認証情報プールはGroupの中核です。複数のキー間でゲートウェイがローテーションするため、1つのキーに問題が起きてもプール全体には影響しません。

FIG. 2 — 認証情報プール複数の認証情報 · 異なる状態

上部で状態別に統計。使用可能なものはローテーションに参加、クールダウン中は一時スキップ、ブラックリストは自動で除外。

認証情報には任意の名前を付け、一覧・ログ・ルート検査で識別しやすくできます。名前を消すと元の表示に戻ります。名前は表示専用で、キー、アカウントの識別情報、スケジューリング、健全性の状態は変わりません。

サブスクリプションアカウントは既定でマスク表示され、認証情報の詳細で明示的に表示できます。マスクは画面上の情報露出を減らすだけで、アカウント情報を削除するものでも、管理 API のアカウント項目が匿名化されることを意味するものでもありません。

認証情報は以下の操作が可能です:

  • バッチインポート——グループの認証情報ページでインポートパネルを開き、1行に1つずつ複数のキーを貼り付けます。
  • 有効化/無効化 — 無効にするとローテーションから外れますが、プールには残ります。
  • 個別ウェイト — 特定のキーに割り当てるトラフィックを増減します。
  • 接続テスト —— この認証情報で最小限の実リクエストをアップストリームへ送り、まだ使えるかをその場で確認します
  • 実際の値を確認 — 認証情報は暗号化して保存されます。必要な場合だけ明示的に値を表示できます。
  • 個別にプロキシを設定 — 特定のキーだけ別の送信経路を使う場合に設定します。代理とリクエストヘッダーを参照してください。

API Key グループで複数の認証情報を選択し、「一括テスト」で共通のプロトコルとモデルを指定します。最大 10 件を同時にテストし、停止や失敗・未完了項目の再テストができます。グループを離れるとテストはキャンセルされます。実際のリクエストが送信され、料金が発生する場合があります。有効・無効やブラックリストの状態は自動変更されません。

グループと個々の認証情報のプロキシは、「プロキシ」ページで管理する有効なプロキシから選択し、継承または直接接続も選べます。同じプロキシを複数箇所から参照できます。アドレス変更はそれらの参照先に影響し、無効化または削除すると上位設定に戻り、最終的に直接接続になる場合があります。

API キーのグループでは、認証情報ページの「全件操作 → ファイルからインポート」も利用できます。UTF-8 の TXT、JSON、JSONL ファイルを複数選び、認証情報の件数を確認して送信します。1 回の上限は 5,000 件、32 MiB です。ファイルの内容は選択したチャネルの認証情報形式に従う必要があります。

FIG. 3 — 一括インポート1行につき1つのキー

重複するキーは自動的に検出してスキップされるため、ブロック全体をそのまま貼り付けられます。

接続テストには実際に少額の費用がかかります

テストは 実際のアップストリームリクエストを送信します、少額の費用が発生します。スケジューリングやブラックリストの状態を変更しません ため、キーがまだ有効かどうかの確認に安心して使えます。
結果は 3 種類あります:テスト合格、テスト不合格(キーが無効か、アップストリームのレート制限か、モデルが利用不可かを示します)、そして 判定不能 —— 最後のケースは通常タイムアウトか、そのチャネルがプローブに対応していないことを示し、キーに問題があるとは限りません。
テストした認証情報が現在ブラックリスト入りしている場合、テストに通るとその場で復帰するかを尋ねられるため、ヘルスページに戻る必要はありません。

公開するモデル§

Groupでは、外部に公開するモデルを指定します。アップストリームから自動検出するか、手動で追加できます。

FIG. 4 — モデルと別名発見 · 手動追加 · 別名

この一覧にあるモデルだけを、このGroup経由でリクエストできます。

モデルエイリアスは同じ表で設定します。価格とコスト見積もりはモデル管理を参照してください。

運用ポリシー§

グループの基本設定で優先度と重みを設定します。その他の実行パラメーターには、タイムアウト、ブラックリストのしきい値、セッションアフィニティ、送信プロキシ、パラメーター上書きルールがあります。

優先度は既定で 0 で、負の値も指定できます。値が大きいほど優先されます。例えば主系を 100、予備を 0 に設定し、同じ層ではルーティング戦略と重みでトラフィックを配分します。リトライ時のフォールバックは失敗後を参照してください。

FIG. 5 — Group設定システムレベルのデフォルト値を上書き

継承に対応する設定は、上書きを有効にするかシステムのデフォルトに戻せます。保存後に反映されます。

各パラメーターの役割と変更すべき場面は、実行時設定を参照してください。

「パラメーター上書きルール」はクライアントのプロトコルとモデルに一致させられます。モデルは完全一致または末尾に * を付けた前方一致に対応します。一致したルールは順番に実行され、指定した JSON パスを削除してから設定をマージし、後のルールが前の値を上書きします。オブジェクトは再帰的にマージされ、配列値を直接設定すると配列全体が置き換わります。null は通常の値として扱われます。

配列内のオブジェクトには、set の * で各要素のフィールドを設定し、remove パスの * で各要素のフィールドを削除できます。既存の要素だけを走査し、他のフィールドと配列の順序を保持します。配列要素の削除や数値インデックスには対応しません。各メッセージの reasoning_content を削除する例:

パラメーター上書き:各要素のフィールドを削除
[{"remove":["/messages/*/reasoning_content"]}]

パラメーター上書きは生成、Embeddings、Rerankに適用され、画像編集、トークン計算、Responsesリソース操作、接続テストには適用されません。ルートのmodel、stream、storeやprevious_response_idの注入・書き換えはできません。

カスタムチャネル§

組み込み一覧にないサービスでも、OpenAI 互換 API ならOpenAI Compatibleを選び、エンドポイント URL とキーを入力します。中継サービスや自前の推論サービスにはこの方式を使います。

Groupを分けるタイミング§

Groupを分けるべきケース:

  • 異なるアップストリームサービスと接続する場合——これは必須で、1つのGroupは1つのチャネルしか選べません。
  • 同じサービスプロバイダーでも、2つのキーセットで異なる戦略を使う場合(例:1つは主用、1つはバックアップ)
  • 同じサービスプロバイダーでも、アプリごとに公開するモデル範囲が異なる場合

Groupを分けなくてよい場合:同じプロバイダーの複数のキーです。1つのプールにまとめることで、ゲートウェイがローテーションと障害回避を行えます。分割すると相互のフォールバックが失われます。

サブスクリプションアカウント

Codex、Claude、Antigravity、Grok などのアカウントは、APIキーではなく OAuth 認可を使います。コールバックポートやリモートデプロイなどの追加設定はサブスクリプションアカウントを参照してください。

Group とチャネル - GPT-Load