GPT-Load
GitHub
クイックスタート →
ドキュメント/ 設定

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

Codex、Claude、Antigravity、Grok などのサブスクリプション型アカウントは、APIキーではなく OAuth 認可を使います。接続後は APIキー認証情報と同じスケジューラーを共有します。

APIキーとの違い§

ゲートウェイから見れば、サブスクリプションアカウントも APIキーも同じ認証情報プールの一部であり、同じローテーション、リトライ、クールダウン、健全性分離の仕組みを共有します。サブスクリプションアカウント専用の運用手順は不要です。

相違点は3か所のみ：

  • 接続方式 — キーを貼り付ける代わりに OAuth 認可フローを完了します。
  • 認証情報は期限切れになります — ゲートウェイが自動更新します。更新に失敗すると、アカウントは再認可が必要な状態になります。
  • クォータウィンドウがある — サブスクリプションのクォータは周期ごとにリセットされ、管理画面に残りクォータとリセット時刻が表示されます。

アカウントを接続する§

サブスクリプションアカウントもGroupに属します。Group → チャネル認証情報のインポート → 新規Group作成を開き、接続方式で「サブスクリプションアカウント」を選びます。次に Codex、Claude、Antigravity、Grok のいずれかを選び、認可を完了します。

FIG. 1 — アカウント接続認可入口

認可パネルは常に展開されています。リモートデプロイでは認可リンクとコールバック URL を手動でコピーする場面が多いため、これはフォールバックではなく主要な手順です。

認可フローはチャネルによって次の2種類に分かれます：

  • ローカルコールバック（Codex、Claude、Antigravity）— ブラウザーで認可を完了すると、アップストリームがローカルの固定ポートへリダイレクトし、ゲートウェイが認可コードを受け取ります。
  • デバイスコード（Grok）— GPT-Load に表示されたコードをアップストリームの Web サイトへ入力して認可します。コールバックポートは不要です。

コールバックポート§

ローカルコールバックを使う3つのチャネルでは、ポートがアップストリームクライアントによって固定されているため変更できません：

チャネルコールバックポート説明
Codex1455コールバックアドレス http://localhost:1455/auth/callback
Claude54545アップストリームのクライアントによって固定される
Antigravity51121アップストリームのクライアントによって固定される
Grok必要ないデバイスコード認証のため、本機のポートを占有しません

Docker Compose はデフォルトで3つのポートを公開し、メインサービスと同様に127.0.0.1にだけバインドされます：

docker-compose.yml におけるポート公開
ports:
  - "$${HOST:-127.0.0.1}:$${PORT:-3001}:$${PORT:-3001}"
  - "$${OAUTH_CALLBACK_BIND_ADDRESS:-...}:1455:1455"   # Codex
  - "$${OAUTH_CALLBACK_BIND_ADDRESS:-...}:54545:54545" # Claude
  - "$${OAUTH_CALLBACK_BIND_ADDRESS:-...}:51121:51121" # Antigravity
ポートは排他

ポートはアップストリームによって固定され変更できないため、1台のホストで同時に実行できるデフォルト構成の Compose インスタンスは1つだけです。複数インスタンスを実行する場合、ローカルコールバック認可を使えるのは1つだけです。ほかはデバイスコード方式を使うか、認可中だけポートを使用しているインスタンスを停止します。

リモートデプロイでの認可方法§

ここが最もつまずきやすい点です。サービスがリモートサーバーで動作している場合、ブラウザー内のlocalhostはサーバーではなく、自分のコンピューターを指します。そのため認可後のリダイレクトは失敗します。

解決方法は2つあり、どちらかを選ぶ：

  1. 手動でコールバックアドレスを貼り付ける — リダイレクトに失敗したら、ブラウザーのアドレスバーから完全なコールバック URL をコピーし、管理画面のコールバック欄に貼り付けます。ゲートウェイが認可コードを取り出して処理を完了します。この方法は最も汎用的な方法で、ネットワーク設定の変更は不要です。
  2. SSH ポートフォワーディング — サーバーのコールバックポートをローカルに転送し、localhostからサーバーへ到達できるようにします：
SSH ポートフォワーディング（Codex を例として）
ssh -L 1455:127.0.0.1:1455 user@your-server

# Claude は 54545、Antigravity は 51121 を使用
# 転送は接続を維持している間に認証完了でOK
ライセンスのために公開ネットワークを開放しないでください

コールバックポートをインターネットへ公開してはいけません。上記いずれかの方法で認可できるため、OAUTH_CALLBACK_BIND_ADDRESSを0.0.0.0へ変更する必要はありません。

4種類の認可状態§

各サブスクリプションアカウントには認可状態があり、トラブルシューティングの際はまずそれを確認してください：

状態意味どうすべきか
準備完了認証情報は有効で、正常にスケジュールに参加しています処理不要
リフレッシュ中認証情報がまもなく期限切れ、ゲートウェイは自動更新中です待つだけで通常数秒で完了
再認可が必要自動更新に失敗しました。多くの場合、アップストリームで認証が取り消されたかパスワードが変更されました。認証プロセスをもう一度実行する
結果不明リフレッシュリクエストが明確な結果を取得できなかった場合、ネットワークの問題が考えられますまず観察し、回復しない場合は再承認
FIG. 2 — アカウント一覧状態・制限・リセット時間

クォータ期間、リセット時刻、認可状態を同じ画面で確認できます。

クォータ情報の見方§

管理画面にはサブスクリプションアカウントの残りクォータとリセット時刻が表示されます。ただし、次の点に注意してください：

制限は表示のみ

クォータ情報はスケジューリング判断に使いません。クォータ情報はアップストリーム応答から受動的に取得されるため、遅延があり、すべての課金項目を網羅するとは限りません。実際にアカウント切り替えを行うのは、アップストリームからのレート制限応答です。アカウントがレート制限されると、表示クォータに関係なく直ちにクールダウンさせ、別のアカウントへ切り替えます。

クォータ欄はアカウントを追加すべきか判断するために使い、ゲートウェイが次に選ぶアカウントの予測には使いません。候補Groupと利用可能な認証情報は、監視とトラブルシュートのルートチェックで確認します。

使用の前提条件§

  • 利用権限のあるアカウントだけを接続し、各プロバイダーのサブスクリプション規約に従ってください。クォータの共有や転売は通常禁止されています。
  • サブスクリプションチャネルはアップストリームの OAuth と互換プロトコルに依存します。アップストリームの変更に合わせて更新が必要になる場合があります。こうした変更はゲートウェイでは制御できません。
  • 認証情報はローカルで暗号化されますが、復号キーとデータベースを必ず一緒にバックアップしてください。セキュリティと本番運用を参照してください。
← 前へGroup とチャネル
サブスクリプションアカウント - GPT-Load