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

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

Codex、Claude、Antigravity、Grok などのサブスクリプション課金アカウントは、OAuth 認可を完了するか、既存の OAuth JSON をインポートできます。接続後は API キーと同じスケジューリングを共有します。

APIキーとの違い§

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

相違点は3か所のみ：

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

アカウントを接続する§

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

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

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

接続方法は、チャネルと認可済みの認証情報を既に持っているかどうかによって 3 種類あります：

  • ローカルコールバック（Codex、Claude、Antigravity）— ブラウザーで認可を完了すると、アップストリームがローカルの固定ポートへリダイレクトし、ゲートウェイが認可コードを受け取ります。
  • デバイスコード（Grok）— GPT-Load に表示されたコードをアップストリームの Web サイトへ入力して認可します。コールバックポートは不要です。
  • OAuth JSON のインポート（4 つのサブスクリプションチャネルすべて）——既存の OAuth JSON をアップロードまたは貼り付けます。このマシンでローカルコールバックを完了する必要はありません

コールバックポート§

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

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

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

docker-compose.yml におけるポート公開
ports:
  - "$${BIND_ADDRESS:-${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 つだけです。他のインスタンスは既存の OAuth JSON をインポートでき、Grok はデバイス認可も使えます。

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

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

解決方法は 3 つあります。いずれかを選んでください：

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

# Claude は 54545、Antigravity は 51121 を使用
# 転送は接続を維持している間に認証完了でOK

既存の OAuth JSON がある場合は、そのままアップロードまたは貼り付けてインポートできます。コールバックポートは不要です。

ライセンスのために公開ネットワークを開放しないでください

コールバックポートをインターネットへ公開してはいけません。コールバックを手動で貼り付ける、SSH 転送を使う、または既存の OAuth JSON をインポートしてください。OAUTH_CALLBACK_BIND_ADDRESS を 0.0.0.0 に変更する必要はありません。

4種類の認可状態§

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

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

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

クォータ情報の見方§

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

制限は表示のみ

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

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

Codex のリセットクレジット

利用可能なリセットクレジットが表示される可能性があるのは Codex アカウントだけです。管理画面で手動消費し、自動スケジューリングには参加しません。操作後はクォータ情報が更新されて結果を確認できるまで待ってください。

使用の前提条件§

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