# 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 に対応 |

### モデル選択のアドバイス

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

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

## テストパラメータの設定

### タイムアウト時間

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

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

### リトライ回数

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

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

### デグレード閾値

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

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

## モデルテストの実行

### 手動テスト

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

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

### テスト内容

テストリクエストは：
- 短い prompt（例："Hi"）を送信
- 最大出力 Token を制限（通常 10-50）
- ストリームレスポンスで初バイト時間を検出

## テスト結果

### ヘルスステータス

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

### 結果情報

テスト完了後に表示：
- 応答レイテンシ（ミリ秒）
- 初バイト時間（TTFB）
- エラー情報（失敗した場合）

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

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

### ヘルスチェック

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

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

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

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

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

## よくある質問

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

**考えられる原因**：
- テストモデルと実際に使用するモデルが異なる
- プロバイダーが設定されたテストモデルをサポートしていない

**解決方法**：
- テストモデルをプロバイダーがサポートするモデルに変更
- プロバイダーのモデルリストを確認

### レイテンシが高すぎる

**考えられる原因**：
- ネットワークレイテンシ
- プロバイダーのサーバー負荷が高い
- モデルの応答が遅い

**解決方法**：
- より高速なテストモデルを使用
- デグレード閾値を調整
- ミラーエンドポイントの使用を検討

### 頻繁にタイムアウトする

**考えられる原因**：
- タイムアウト時間の設定が短すぎる
- ネットワークが不安定
- プロバイダーのサービスが不安定

**解決方法**：
- タイムアウト時間を延長
- リトライ回数を増加
- ネットワーク接続を確認

## 注意事項

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