実行時設定
これらの設定は管理画面で保存するとすぐに反映され、再起動は不要です。環境変数は別で、変更後に再起動が必要です。
二層の設定§
タイムアウトやブラックリストのしきい値などの実行時パラメーターは、2層の設定に対応します：
- システムレベル — 「設定」ページで指定するグローバルデフォルトです。
- Groupレベル — Groupの「設定」タブで指定し、上書きを有効にして編集し、デフォルトに戻すとシステム値を継承します。保存後に反映されます。
上流によって特性が異なります。遅いが安定したサービスも、速いが時々不安定なサービスもあります。同じタイムアウトやブラックリストのしきい値では対応できません。
グループで上書き可能な設定は、上書きしない場合にシステム値を継承します。
Groupの「設定」タブには、システムから継承した値とこのGroupで上書きした値が表示されます。Groupごとの動作差を調べるときは、まずここを確認してください。
三種類のタイムアウト§
3つのタイムアウトはリクエストの異なる段階を対象にします。症状に合う項目を調整してください：
| パラメータ | 管理内容 | 調整すべき症状 |
|---|---|---|
| 最初のバイトのタイムアウト | リクエスト送信から最初のバイト受信まで | アップストリームで待機が長い場合、リクエストが応答を開始する前に失敗と判定される |
| 上流リクエスト1回のタイムアウト | 上流への各試行の時間上限で、リトライを含む合計時間ではありません | 長出力タスクが途中で中断された |
| ストリームアイドルタイムアウト | ストリーミング応答で、二つのデータブロック間の最大間隔 | ストリーミング出力が途中で長時間停止するが、接続は切れない |
推論モデルは最初のバイトタイムアウトに特に注意 — 出力開始前に長時間推論することがあるため、デフォルト値が短いと失敗と誤判定されます。
同時実行数の上限§
「設定 → ルーティング」で全体、アクセスキーのデフォルト、Group のデフォルトの同時実行数上限を設定します。初期値はすべて 0（無制限）です。毎分のリクエスト数ではなく、処理中のリクエスト数を制限します。
アクセスキーは個別に上書きでき、空欄ならデフォルトを継承します。Group は実行時設定で上書きを有効にします。明示的な 0 はその層の制限だけを解除し、他の層の上限は引き続き適用されます。
上限に達すると新しいリクエストを待機させずに即座に拒否し、HTTP では 429 と concurrency_limit_exceeded を返します。ストリーミング中も枠を使用します。上限を下げても、すでに受け付けたリクエストを強制終了しません。
同時実行数は現在の GPT-Load プロセス内でのみ数えられ、複数インスタンスで共有する総上限ではありません。JEV の判定呼び出しも Group の上限に従い、ガードレールの異常時転送によって同時実行数制限を回避することはできません。
再試行とブラックリスト§
- 再試行回数——グローバルの追加リトライ予算で、グループでは上書きできません。増やすと成功率が上がる場合もありますが、失敗時の所要時間も長くなります。
- ブラックリスト閾値 — 連続失敗が何回で自動的にブラックリストへ入るかを設定します。小さくすると不良認証情報を早く隔離できますが、一時的な失敗にも反応しやすくなります。
両方の詳しい仕組みはスケジューリングの仕組みを参照してください。
「空応答の再試行」は既定で無効で、グループごとに上書きできます。有効にすると、クライアントへの送信前に上流が何も出力せず自然終了したストリーミング会話で、次の候補を試します。予算を使い切ると元の空応答を返します。WebSocket、非ストリーミング、ウォームアップ、履歴リソース参照付きのリクエストや、拒否・コンテンツフィルター・出力予算切れなど明確な理由のある空応答は対象外です。
再試行される空応答でも、上流では課金済みの場合があります。ゲートウェイが使用量と費用を記録するのは最終的に返した試行だけなので、この見積もり上の制限を理解してから有効にしてください。
上流エラールール§
「設定 → ルーティング → エラー処理ルール」で全体のルールを追加します。グループの実行時設定では、全体のリストを丸ごと上書きできます。上書きしない場合は全体のルールを継承し、空のリストで上書きした場合は組み込みの処理だけを使います。一致するルールがないエラーにも組み込みの方針を適用します。Modern と Classic の両方で設定できます。
ルールは上から順に照合し、最初に一致したものを適用します。ステータスコードは 200–599 の整数で、複数指定した場合はいずれかに一致すれば条件を満たします。キーワードは認識済みエラーのコード・種類・メッセージに対し、大文字小文字を区別せず部分一致で照合します。複数ある場合はいずれかの一致で条件を満たします。両方の条件を指定した場合は両方の一致が必要です。少なくとも一方の条件を指定してください。
各ルールで再試行の有無と、状態を変更しない・現在の認証情報の現在のモデルをクールダウン・認証情報全体をクールダウン・ブラックリスト判定の失敗を加算・今回のリクエストでグループを除外、のいずれか一つを選びます。クールダウン時間は正の整数秒です。ブラックリスト判定には引き続き失敗回数のしきい値を使い、モデルのクールダウンは対応する操作にだけ適用されます。
保存後に反映されます。リストは最大 100 件、エンコード後のサイズは 65,535 バイト以内です。ルールは HTTP 200 ですでに認識されたエラーも含む、認識済みの上流エラーだけを使い、正常な回答文は走査しません。認証情報の検査と復旧方法は変わりません。
ルールはクライアントのリクエストエラー、認証の復旧、リクエスト単位のレート制限に関する保護を回避しません。クライアントへの出力が始まっている場合や実行結果が不明な場合に、再試行を強制することはできません。再試行回数には引き続き全体の予算を適用します。
ルーティング戦略§
「設定 → ルーティング」でグローバルのルーティング戦略を選びます。既定の「ネイティブ優先」は、同じ優先度の層でネイティブルートを優先します。「重みを混合」は、その層のネイティブ候補と変換候補を有効な重みで競合させます。グループでの上書きはできません。実際のトラフィックは、認証情報の可用性、アフィニティ、プロトコルの対応範囲にも依存します。
Responses WebSocketはデフォルトで有効です。グループは継承または上書きできます。無効化すると対象接続を中断しますが、HTTP/SSEには影響しません。グローバルで無効にしても、明示的に有効にしたグループには適用されません。
セッションアフィニティ§
有効にすると、アクセスキー、クライアントプロトコル、リクエスト内の指示または最初のユーザー入力のプレフィックスからソフトアフィニティキーを生成します。同じ安定したプレフィックスを持つリクエストは、現在の優先度とルーティング戦略で許可された候補の中で、できるだけ同じ認証情報を使います。設定は 3 つです：
- スイッチ — 機能の有効・無効を設定します。
- TTL — アフィニティレコードの保持時間です。
- 容量 — 記憶するセッションの最大数です（デフォルトは10,000）。
ソフトアフィニティは認証情報の再利用を優先するだけで、リソースの帰属を保証しません。Responsesのprevious_response_idは独立した継続バインディングを使い、アフィニティのスイッチに影響されません。conversationや他のリソース参照は保証対象外です。
ログの保持§
リクエストログの保持日数でログ保持期間を設定します。デフォルトは7日で、期限後に自動削除されます。
増やすと古い履歴を確認できますが、データベースは増え続けるため、リクエスト量が多い場合はディスク容量に注意してください。SQLiteでは特に注意が必要です。
アクセスキーごとに有効化した元のリクエスト本文も同じ保持期間を使い、ログとともに削除されます。独立した全体記録スイッチはありません。キーの記録を無効にしても、その後のリクエストにのみ影響し、保存済みの内容は削除されません。データベースやバックアップが大きくなるため、調査に必要な範囲と期間に限定してください。
その他の設定§
全体の上流プロキシは設定ページの「上流プロキシ」で選択します。プロキシアドレスはサイドバーの「プロキシ」ページで追加・一括インポート・編集・テストし、全体・グループ・認証情報の設定で再利用できます。テストはサーバーから指定のプロキシ経由でテスト URL にアクセスし、プロキシを自動で有効化・無効化することはありません。
リクエストのマスキングは専用の設定欄、自動モデル選択と JEV AI ガードレールは「実験機能」で設定します。音声モードは「接続とタイムアウト」にあり、Codex グループごとに上書きできます。詳しい手順はこちらです。
- チェック間隔 — 認証情報の可用性を検証する間隔です。
- モデル価格自動同期 —— 公開データソースから価格を同期するかどうか（モデル管理 を参照）。この項目は環境変数
MODELS_DEV_AUTO_SYNC_ENABLEDに引き継がれる場合があり、その変数を設定するとここは読み取り専用になります（環境変数 を参照） - 上流リクエストヘッダー・下流レスポンスヘッダー・CORS——特殊な要件がある場合に使用します。代理とリクエストヘッダーを参照してください。
いつ調整すべきか§
デフォルト値はほとんどの場合に適用されます。明確な症状がない場合は変更しないでください。タイムアウトやリトライをむやみに増やすと、失敗までの時間が延びるだけです。
症状に応じて調整します：
- 推論モデルが頻繁にタイムアウトする → 最初のバイトまでのタイムアウトを延長します。まず対象Groupだけで調整してください。
- 長文タスクは短縮されます → リクエストタイムアウトを延長します。
- ストリーミング出力が途中で切断される → ストリームアイドルタイムアウトを延長します。
- 良い認証情報が頻繁にブラックリストに入る → ブラックリストしきい値を上げます。
- 無効な認証情報の隔離が遅すぎる場合 → ブラックリストしきい値を下げます。
- ステートフルリクエストでコンテキストが見つからないと報告される → 応答IDの登録と元の認証情報の可用性を確認します。他のリソース参照には単一の認証情報か、上流の共有対応が必要です。
調整前に監視とトラブルシュートで症状を確認し、症状に関連する項目だけを変更する。変更後はしばらく観察してから次の項目を調整します。