Jason
04af87bc7b
Backfill the empty [Unreleased] CHANGELOG section with the Codex Chat Completions feature (Chat-to-Responses bridge, 23 third-party presets, model mapping table, Stream Check routing, error-envelope conversion, "custom" history bucket) plus the community fixes landed since v3.15.0. Update the zh/en/ja user manual: split the Codex preset tables by upstream protocol (native Responses vs Chat Completions), add a "Codex Local Routing and Model Mapping" section covering the Needs Local Routing toggle and the model catalog, and note Chat-format probing in the Stream Check guide. Manual wording matches the live UI strings.
7.0 KiB
4.5 モデルテスト
機能説明
モデルテスト機能（Stream Check とも呼ばれる）は、プロバイダーに設定されたモデルが使用可能かどうかを確認するために、実際の API リクエストを送信してテストします：
- モデルが存在するか
- API Key が有効か
- エンドポイントが正常に応答するか
- 応答レイテンシが正常か
- ストリーミングレスポンスの初回トークン時間（TTFB）
v3.13.0 より、Stream Check の対応範囲が Claude / Codex / Gemini / OpenCode / OpenClaw に拡張され、OpenClaw の全プロトコルバリアント（openai-completions など）も含まれます。OpenCode は npm パッケージマッピングで自動識別、OpenClaw はカスタム auth-header 検出、Bedrock エラーメッセージ、baseURL フォールバックなどのエッジケースにも対応しています。
Chat Completions プロトコルを使用する Codex 第三者プロバイダー（DeepSeek、Kimi、MiniMax など）の場合、Stream Check は /responses ではなく /chat/completions エンドポイントをプローブし、実際のプロキシ転送パスと URL フォールバック順序を一致させます（origin-only アドレスは /v1/... を優先）。これにより、使用可能なプロバイダーが誤って利用不可と判定されることを防ぎます。
設定を開く
設定 → 詳細 → モデルテスト
テストモデルの設定
各アプリのテスト用モデルを設定します：
| アプリ | 設定項目 | デフォルト値 | 説明 |
|---|---|---|---|
| Claude | Claude モデル | システムデフォルト | Haiku シリーズの使用を推奨（低コスト・高速） |
| Codex | Codex モデル | システムデフォルト | mini シリーズの使用を推奨 |
| Gemini | Gemini モデル | システムデフォルト | Flash シリーズの使用を推奨 |
| OpenCode | OpenCode モデル | システムデフォルト | v3.13.0 で追加、npm パッケージマッピングで自動検出 |
| OpenClaw | OpenClaw モデル | システムデフォルト | v3.13.0 で追加、全プロトコルバリアントとカスタム auth-header に対応 |
モデル選択のアドバイス
テストモデルを選択する際の考慮事項：
- コスト：低価格のモデルを選択（例：Haiku、Mini、Flash）
- 速度：応答が速いモデルを選択
- 可用性：プロバイダーがサポートしているモデルを選択
テストパラメータの設定
タイムアウト時間
| パラメータ | 説明 | デフォルト値 | 範囲 |
|---|---|---|---|
| タイムアウト時間 | 1 回のリクエストのタイムアウト | 45 秒 | 10-120 秒 |
短すぎると誤判定の可能性があり、長すぎると障害検出が遅れます。
リトライ回数
| パラメータ | 説明 | デフォルト値 | 範囲 |
|---|---|---|---|
| 最大リトライ | 失敗時のリトライ回数 | 2 回 | 0-5 回 |
ネットワークが不安定な場合はリトライ回数を増やすことを推奨します。
デグレード閾値
| パラメータ | 説明 | デフォルト値 | 範囲 |
|---|---|---|---|
| デグレード閾値 | この時間を超えるとデグレードとマーク | 6000ms | 1000-30000ms |
閾値を超えたプロバイダーは「デグレード」状態としてマークされますが、引き続き使用可能です。
モデルテストの実行
手動テスト
プロバイダーカードの「テスト」ボタンをクリックします：
- 設定されたエンドポイントにテストリクエストを送信
- 設定されたテストモデルを使用
- レスポンスまたはタイムアウトを待機
- テスト結果を表示
テスト内容
テストリクエストは：
- 短い prompt（例："Hi"）を送信
- 最大出力 Token を制限（通常 10-50）
- ストリームレスポンスで初バイト時間を検出
テスト結果
ヘルスステータス
| ステータス | アイコン | 説明 |
|---|---|---|
| 健康 | 緑 | レスポンス正常、レイテンシが閾値内 |
| デグレード | 黄 | レスポンス正常だが、レイテンシが閾値超過 |
| 利用不可 | 赤 | リクエスト失敗またはタイムアウト |
結果情報
テスト完了後に表示：
- 応答レイテンシ（ミリ秒）
- 初バイト時間（TTFB）
- エラー情報（失敗した場合）
フェイルオーバーとの連携
モデルテストはフェイルオーバー機能と連携して使用します：
ヘルスチェック
プロキシサービスを有効にすると、システムはフェイルオーバーキュー内のプロバイダーに対して定期的にヘルスチェックを実行します：
- 設定されたテストモデルでリクエストを送信
- レスポンスに基づいてヘルスステータスを更新
- 不健康なプロバイダーは一時的にスキップ
サーキットブレーカーからの復旧
プロバイダーがサーキットブレーカー状態から復旧する際：
- モデルテストで可用性を確認
- テスト合格後、正常状態に復旧
- テスト不合格の場合、サーキットブレーカーを継続
よくある質問
テストは失敗するが実際には使用可能
考えられる原因：
- テストモデルと実際に使用するモデルが異なる
- プロバイダーが設定されたテストモデルをサポートしていない
解決方法：
- テストモデルをプロバイダーがサポートするモデルに変更
- プロバイダーのモデルリストを確認
レイテンシが高すぎる
考えられる原因：
- ネットワークレイテンシ
- プロバイダーのサーバー負荷が高い
- モデルの応答が遅い
解決方法：
- より高速なテストモデルを使用
- デグレード閾値を調整
- ミラーエンドポイントの使用を検討
頻繁にタイムアウトする
考えられる原因：
- タイムアウト時間の設定が短すぎる
- ネットワークが不安定
- プロバイダーのサービスが不安定
解決方法：
- タイムアウト時間を延長
- リトライ回数を増加
- ネットワーク接続を確認
注意事項
- モデルテストは少量の API 枠を消費します
- テストには低コストのモデルの使用を推奨
- テスト頻度は高すぎないように、枠の浪費を避けてください
- プロバイダーごとにサポートするモデルが異なる場合があります