Olenro
プロキシ

モデルテスト

機能説明

モデルテスト機能(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/... を優先)。これにより、使用可能なプロバイダーが誤って利用不可と判定されることを防ぎます。

設定を開く

設定 → 詳細 → モデルテスト

テストモデルの設定

各アプリのテスト用モデルを設定します:

アプリ設定項目デフォルト値説明
ClaudeClaude モデルシステムデフォルトHaiku シリーズの使用を推奨(低コスト・高速)
CodexCodex モデルシステムデフォルトmini シリーズの使用を推奨
GeminiGemini モデルシステムデフォルトFlash シリーズの使用を推奨
OpenCodeOpenCode モデルシステムデフォルトv3.13.0 で追加、npm パッケージマッピングで自動検出
OpenClawOpenClaw モデルシステムデフォルトv3.13.0 で追加、全プロトコルバリアントとカスタム auth-header に対応

モデル選択のアドバイス

テストモデルを選択する際の考慮事項:

  1. コスト:低価格のモデルを選択(例:Haiku、Mini、Flash)
  2. 速度:応答が速いモデルを選択
  3. 可用性:プロバイダーがサポートしているモデルを選択

テストパラメータの設定

タイムアウト時間

パラメータ説明デフォルト値範囲
タイムアウト時間1 回のリクエストのタイムアウト45 秒10-120 秒

短すぎると誤判定の可能性があり、長すぎると障害検出が遅れます。

リトライ回数

パラメータ説明デフォルト値範囲
最大リトライ失敗時のリトライ回数2 回0-5 回

ネットワークが不安定な場合はリトライ回数を増やすことを推奨します。

デグレード閾値

パラメータ説明デフォルト値範囲
デグレード閾値この時間を超えるとデグレードとマーク6000ms1000-30000ms

閾値を超えたプロバイダーは「デグレード」状態としてマークされますが、引き続き使用可能です。

モデルテストの実行

手動テスト

プロバイダーカードの「テスト」ボタンをクリックします:

  1. 設定されたエンドポイントにテストリクエストを送信
  2. 設定されたテストモデルを使用
  3. レスポンスまたはタイムアウトを待機
  4. テスト結果を表示

テスト内容

テストリクエストは:

  • 短い prompt(例:"Hi")を送信
  • 最大出力 Token を制限(通常 10-50)
  • ストリームレスポンスで初バイト時間を検出

テスト結果

ヘルスステータス

ステータスアイコン説明
健康レスポンス正常、レイテンシが閾値内
デグレードレスポンス正常だが、レイテンシが閾値超過
利用不可リクエスト失敗またはタイムアウト

結果情報

テスト完了後に表示:

  • 応答レイテンシ(ミリ秒)
  • 初バイト時間(TTFB)
  • エラー情報(失敗した場合)

フェイルオーバーとの連携

モデルテストはフェイルオーバー機能と連携して使用します:

ヘルスチェック

プロキシサービスを有効にすると、システムはフェイルオーバーキュー内のプロバイダーに対して定期的にヘルスチェックを実行します:

  1. 設定されたテストモデルでリクエストを送信
  2. レスポンスに基づいてヘルスステータスを更新
  3. 不健康なプロバイダーは一時的にスキップ

サーキットブレーカーからの復旧

プロバイダーがサーキットブレーカー状態から復旧する際:

  1. モデルテストで可用性を確認
  2. テスト合格後、正常状態に復旧
  3. テスト不合格の場合、サーキットブレーカーを継続

よくある質問

テストは失敗するが実際には使用可能

考えられる原因

  • テストモデルと実際に使用するモデルが異なる
  • プロバイダーが設定されたテストモデルをサポートしていない

解決方法

  • テストモデルをプロバイダーがサポートするモデルに変更
  • プロバイダーのモデルリストを確認

レイテンシが高すぎる

考えられる原因

  • ネットワークレイテンシ
  • プロバイダーのサーバー負荷が高い
  • モデルの応答が遅い

解決方法

  • より高速なテストモデルを使用
  • デグレード閾値を調整
  • ミラーエンドポイントの使用を検討

頻繁にタイムアウトする

考えられる原因

  • タイムアウト時間の設定が短すぎる
  • ネットワークが不安定
  • プロバイダーのサービスが不安定

解決方法

  • タイムアウト時間を延長
  • リトライ回数を増加
  • ネットワーク接続を確認

注意事項

  • モデルテストは少量の API 枠を消費します
  • テストには低コストのモデルの使用を推奨
  • テスト頻度は高すぎないように、枠の浪費を避けてください
  • プロバイダーごとにサポートするモデルが異なる場合があります

目次