> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aihubmix.com/llms.txt
> Use this file to discover all available pages before exploring further.

# モデル自動ルーティング（LLM Router）

> AIHubMix の自動ルーティング：モデル名を auto にするだけで、ゲートウェイがリクエスト内容に応じて最適なモデルを自動選択。コスト優先 / 品質優先 / 低レイテンシのポリシーに対応し、実際にヒットしたモデルで課金、クライアントのコード変更は不要。

> たった一つの `model=auto` で、「どのモデルを選ぶか」をゲートウェイに任せましょう。

**自動ルーティング（LLM Router）** は、リクエスト内容に応じて**プラットフォーム上の数百のモデル**から最適な一つを**リアルタイムで選び出します**。あなたは `model` を `auto` にするだけ——モデルを選ぶ必要も、価格を比べる必要も、モデルの更新を追いかける必要もありません。

<Note>
  **実際にヒットしたモデル**で課金され、追加料金はかからず、クライアントのコード変更も不要です。どのモデルがヒットしたかは応答ヘッダーと応答ボディに記録され（[実際にヒットしたモデルの確認方法](#実際にヒットしたモデルの確認方法)を参照）、完全に追跡可能です。
</Note>

## ユースケース

* **コンテキストに応じた自動振り分け**：ユーザーの現在のコンテキストに応じて最適なモデルを自動的に割り当てます——特に、モデルを何度も呼び出し、各ステップのモデル選択を事前に固定しづらい agent / アプリのシナリオに有用です。
* **コスト最適化**：簡単なタスクを自動的により安く、より速いモデルに割り当てます（`auto` はデフォルトでコスト優先）。
* **品質最適化**：複雑なリクエストを、より能力の高いモデルへ確実にルーティングします（`auto:quality_first`）。
* **低レイテンシのシナリオ**：マルチターンの agent ループ、リアルタイム対話チャットなど応答速度に敏感なシナリオでは、最速応答のモデルを優先します（`auto:latency_critical`）。
* **統一エントリ・モデル選定不要**：異なるタイプのリクエストを自動的にそれぞれ最適なモデルへ振り分け——「タスク → モデル」の対応表を保守する必要も、モデルの更新を追いかけて手動で価格比較やモデル名の差し替えをする必要もありません。

***

## クイックスタート

`model` を `auto` に設定するだけで、その他のリクエストボディは通常の呼び出しとまったく同じです。base\_url には `https://aihubmix.com/v1` を使用します。

<CodeGroup>
  ```bash curl theme={null}
  curl https://aihubmix.com/v1/chat/completions \
    -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
    -H "Content-Type: application/json" \
    -d '{
      "model": "auto",
      "messages": [
        { "role": "user", "content": "What is the meaning of life?" }
      ]
    }'
  ```

  ```python Python (openai SDK) theme={null}
  from openai import OpenAI

  client = OpenAI(
      api_key="<AIHUBMIX_API_KEY>",
      base_url="https://aihubmix.com/v1",
  )

  resp = client.chat.completions.create(
      model="auto",  # モデル選択をゲートウェイに任せる
      messages=[
          {"role": "user", "content": "What is the meaning of life?"},
      ],
  )

  print(resp.choices[0].message.content)
  print("実際にヒットしたモデル：", resp.model)  # "auto" ではなく、実際のモデル名
  ```

  ```javascript Node.js (openai SDK) theme={null}
  import OpenAI from "openai";

  const client = new OpenAI({
    apiKey: "<AIHUBMIX_API_KEY>",
    baseURL: "https://aihubmix.com/v1",
  });

  const resp = await client.chat.completions.create({
    model: "auto", // モデル選択をゲートウェイに任せる
    messages: [
      { role: "user", content: "What is the meaning of life?" },
    ],
  });

  console.log(resp.choices[0].message.content);
  console.log("実際にヒットしたモデル：", resp.model); // 実際のモデル名
  ```
</CodeGroup>

<Tip>
  自動ルーティングはリクエストが上流に到達する**前に**解析を完了し、ストリーミング（`stream: true`）と非ストリーミングのリクエストを同等に扱い、追加パラメータは不要です。決定処理全体で**増えるオーバーヘッドは約 1ms のみ**で、エンドツーエンドのレイテンシにはほとんど影響しません。
</Tip>

***

## 実際にヒットしたモデルの確認方法

これが自動ルーティングの信頼の拠り所です：**そのリクエストで最終的にどのモデルが使われたかを、あなたは常に把握できます。**

**方法 1 · AIHubMix コンソールの「ログ」**：[console.aihubmix.com/logs](https://console.aihubmix.com/logs) で、各リクエストの実際にヒットして課金された本物のモデル名を、コードを書かずに目視で確認できます。

**方法 2 · レスポンスフィールド**（プログラムからの読み取りに便利）：

* **応答ボディの `model` フィールド**には、`auto` ではなく実際にヒットしたモデル（例：`mimo-v2.5-pro`）が書き戻されます。
* **応答ヘッダー**には完全な決定情報が含まれます：

| 応答ヘッダー                             | 意味                                | 値の例                                                                |
| ---------------------------------- | --------------------------------- | ------------------------------------------------------------------ |
| `X-Aihubmix-Router-Resolved-Model` | 実際にヒットし、それに基づいて課金されるモデル           | `xiaomi-mimo-v2.5-pro`                                             |
| `X-Aihubmix-Router-Policy`         | 今回使用されたポリシー                       | `cost_optimized`                                                   |
| `X-Aihubmix-Router-Dimension`      | 識別されたタスクの次元                       | `text.overall`                                                     |
| `X-Aihubmix-Router-Decision-Id`    | 今回の決定の一意な ID、トラブルシュートに便利          | `05dbad09-33c5-42de-…`                                             |
| `X-Aihubmix-Router-Reason`         | 決定の簡潔な説明（ポリシー / 次元 / 最高スコア / 候補数） | `policy=cost_optimized dim=text.overall top=0.182 survivors=20/33` |
| `X-Aihubmix-Router-Fallback`       | **候補なしのフォールバックが発生したときのみ**出現       | `true`                                                             |

> HTTP 応答ヘッダーは大文字小文字を区別しません：上表では慣例的に頭文字を大文字にしていますが、実際の HTTP/2 の返却は小文字の `x-aihubmix-router-*` であり、両者は等価です。

ルーティング決定の読み取り方（curl では応答ヘッダーを見る、SDK では生の応答オブジェクトから header を取得する）：

<CodeGroup>
  ```bash curl theme={null}
  curl -i https://aihubmix.com/v1/chat/completions \
    -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
    -H "Content-Type: application/json" \
    -d '{
      "model": "auto",
      "messages": [
        { "role": "user", "content": "What is the meaning of life?" }
      ]
    }' | grep -i "^x-aihubmix-router"
  ```

  ```python Python (openai SDK) theme={null}
  # 上で作成した client を再利用。with_raw_response で応答ヘッダーを取得できる
  raw = client.chat.completions.with_raw_response.create(
      model="auto",
      messages=[
          {"role": "user", "content": "What is the meaning of life?"},
      ],
  )

  print("ヒットしたモデル：", raw.headers.get("x-aihubmix-router-resolved-model"))
  print("ポリシー：", raw.headers.get("x-aihubmix-router-policy"))
  print("次元：", raw.headers.get("x-aihubmix-router-dimension"))

  completion = raw.parse()  # 通常の completion オブジェクトに解析する
  print("body.model：", completion.model)
  ```

  ```javascript Node.js (openai SDK) theme={null}
  // 上で作成した client を再利用。.withResponse() で生の応答ヘッダーを取得できる
  const { data: completion, response } = await client.chat.completions
    .create({
      model: "auto",
      messages: [
        { role: "user", content: "What is the meaning of life?" },
      ],
    })
    .withResponse();

  console.log("ヒットしたモデル：", response.headers.get("x-aihubmix-router-resolved-model"));
  console.log("ポリシー：", response.headers.get("x-aihubmix-router-policy"));
  console.log("次元：", response.headers.get("x-aihubmix-router-dimension"));
  console.log("body.model：", completion.model);
  ```
</CodeGroup>

curl の実際の出力（本番環境。ヒットするモデルは本番の catalog によって変わります）：

```text theme={null}
x-aihubmix-router-decision-id: 05dbad09-33c5-42de-85b5-559fdb73eb4c
x-aihubmix-router-dimension: text.overall
x-aihubmix-router-policy: cost_optimized
x-aihubmix-router-reason: policy=cost_optimized dim=text.overall top=0.182 survivors=20/33
x-aihubmix-router-resolved-model: xiaomi-mimo-v2.5-pro
```

`reason` の読み方：`survivors=20/33` は、33 個の候補のうち 20 個がハードフィルタを通過してスコアリングに進んだことを示し、`top=0.182` は勝ち残ったモデルが候補プール内で正規化された後の総合スコア（能力 / コスト / レイテンシをポリシーに従って重み付け）です。

<Note>
  例の `Resolved-Model` は本番 catalog の現在の候補と価格に依存し、プラットフォームのモデルの追加・廃止に伴って変化します——これこそが自動ルーティングの価値です：あなたはこうした変化を追いかける必要がありません。決定を後から検証できるようにするには、固定だと仮定せず、応答ヘッダー / 応答ボディに記録された実際のモデル名を基準にしてください。
</Note>

***

## ルーティングポリシー

サフィックスなしの `auto` はデフォルトポリシー `cost_optimized` を使用します。`auto:<ポリシー>` で重視する点を明示的に指定できます：

| ポリシーの書き方                        | 重視する点                         | 適した場面                  |
| ------------------------------- | ----------------------------- | ---------------------- |
| `auto`（= `auto:cost_optimized`） | **コスト優先**：能力が基準を満たせば最も安いものを選ぶ | バッチ処理、コストに敏感な場合        |
| `auto:balanced`                 | **バランス**：能力 / コスト / レイテンシを両立  | 汎用、迷ったときの無難な選択         |
| `auto:quality_first`            | **品質優先**：能力が最も高いものを優先         | 複雑な推論、重要な出力            |
| `auto:latency_critical`         | **低レイテンシ優先**：応答が最も速いものを優先     | agent ループ、リアルタイム対話チャット |

ポリシーは固定された「モデル一覧」ではなく、**能力 / コスト / レイテンシ** に対する重み付けの違いです。`auto` はまず今回のリクエスト内容でタスク次元を絞り込み、その次元の **プラットフォーム上の数百のモデル** の候補プールから、選択したポリシーに従ってリアルタイムで最適を選びます——したがって同じポリシーでも内容によって異なるモデルにヒットします。現在プール内にあるモデルと各ディメンションのスコアは、[自動ルーティング戦略の対象モデル範囲](/jp/api/RouterEndpoints/leaderboard)エンドポイントで照会できます。下の「同じリクエスト・異なるポリシー → 異なるヒット結果」の実測表がこの仕組みを直感的に示しています。毎回どのモデルになるかは、応答ヘッダー / コンソールログの実際のモデル名を基準にしてください。

ポリシーの指定は `model` にサフィックスを付けるだけです：

<CodeGroup>
  ```bash curl theme={null}
  # 品質優先 + コーディングタスク
  curl -i https://aihubmix.com/v1/chat/completions \
    -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
    -H "Content-Type: application/json" \
    -d '{
      "model": "auto:quality_first",
      "messages": [
        { "role": "user", "content": "Write a Python function to reverse a linked list." }
      ]
    }' | grep -i "^x-aihubmix-router"
  ```

  ```python Python (openai SDK) theme={null}
  raw = client.chat.completions.with_raw_response.create(
      model="auto:quality_first",  # 品質優先
      messages=[
          {"role": "user", "content": "Write a Python function to reverse a linked list."},
      ],
  )

  print(raw.headers.get("x-aihubmix-router-resolved-model"))
  print(raw.headers.get("x-aihubmix-router-dimension"))
  ```

  ```javascript Node.js (openai SDK) theme={null}
  const { response } = await client.chat.completions
    .create({
      model: "auto:quality_first", // 品質優先
      messages: [
        { role: "user", content: "Write a Python function to reverse a linked list." },
      ],
    })
    .withResponse();

  console.log(response.headers.get("x-aihubmix-router-resolved-model"));
  console.log(response.headers.get("x-aihubmix-router-dimension"));
  ```
</CodeGroup>

**同じリクエスト、異なるポリシー → 異なるヒット結果**（本番での実測。同じ一文 `What is the meaning of life?` で、いずれも `text.overall` 次元に落ちる）：

| ポリシー                       | ヒットしたモデル                | top スコア |
| -------------------------- | ----------------------- | :-----: |
| `auto`（= `cost_optimized`） | `xiaomi-mimo-v2.5-pro`  |  0.182  |
| `auto:balanced`            | `claude-opus-4-6-think` |  0.488  |
| `auto:latency_critical`    | `claude-opus-4-6`       |  0.646  |
| `auto:quality_first`       | `claude-opus-4-6-think` |  0.758  |

> `latency_critical` は\*\*`-think` 版ではない\*\*ものを選びました——thinking バリアントは推論のレイテンシが高く、低レイテンシポリシーはこれを積極的に避けます。ポリシーの重み付けが「能力 / コスト / レイテンシ」のトレードオフに実際に作用しており、能力だけを見ているのではないことが分かります。

> **内容も結果を変えます**：同じ `auto:quality_first` を**コーディングタスク**（上の例のリクエスト）に使うと、次元は `text.overall` から `text.coding` に変わり、実測では `claude-opus-4-6-think` がヒットしました——ポリシーとリクエスト内容が共同で最終的なモデルを決定します。

<Note>
  未知のポリシーサフィックス（例：`auto:fast`）は**デフォルトポリシー `cost_optimized` にフォールバック**し、エラーにはなりません。
</Note>

***

## 仕組み

`model=auto` を受け取ると、ゲートウェイは 3 ステップで「意図」を「具体的なモデル」に変換します：

<Steps>
  <Step title="リクエスト特徴の抽出">
    今回のリクエストの入力 / 出力モダリティ（テキスト、画像、ファイル）、内容の意図（コード、数学、OCR、図表、言語、ネット検索の有無など）、およびリクエスト規模（入力 / 出力 token の推定）を分析し、一つの**タスク次元**へ正規化します。例えば：コードを含む質問 → `text.coding`；画像付きで OCR を要求 → `vision.ocr`；通常のテキスト → `text.overall`。
  </Step>

  <Step title="候補のハードフィルタ">
    **必須の制約**を満たさないモデルを直接除外します：必要な入力 / 出力モダリティに非対応、コンテキストウィンドウに収まらない、サーキットブレーカーで切り離されている（[信頼性とフォールトトレランス](#信頼性とフォールトトレランス)を参照）、またはあなたのこの Key で利用可能なモデルの範囲外、といった場合です。
  </Step>

  <Step title="ポリシーに基づく重み付けスコアリング">
    フィルタを通過した候補に対し、**業界で権威ある基準**によるモデル能力スコアに、リアルタイムの価格とパフォーマンスデータを重ね合わせ、選択したポリシーに従って「能力 / コスト / レイテンシ」の 3 次元で重み付けスコアリングを行い、最高スコアの一つを採用します。最終的なモデル名はリクエストと応答ヘッダーに書き戻されます。
  </Step>
</Steps>

実際のスコアリング例（`quality_first` ポリシー下、同一候補プールの top 3。サンプルデータは過去の本番意思決定ログに基づく）：

| 候補モデル                   | 能力スコア | 相対コスト |  レイテンシ  |   総合スコア   |
| ----------------------- | :---: | :---: | :-----: | :-------: |
| `claude-opus-4-6-think` |  1504 |  220  |  1963ms | **0.758** |
| `claude-opus-4-6`       |  1498 |  220  |  822ms  |   0.721   |
| `claude-fable-5`        |  1510 |  484  | 11130ms |   0.600   |

> `claude-fable-5` の**能力スコアが最も高い**（1510）にもかかわらず、コストが高くレイテンシも大きいために総合スコアで 3 位に押し下げられている点に注目してください。これこそが重み付けスコアリングの意義です：「能力至上主義」ではなく、ポリシーに従って能力 / コスト / レイテンシの間でトレードオフを取っているのです。

<Note>
  `claude-fable-5` は段階的に公開されたプレビューのベースラインモデル（staged preview baseline）で、現在は **提供終了（deprecated）** となり、提供されていません。ここでは加重スコアリングの仕組みを説明するために過去のスコアのみを残しており、実際のリクエストがこのモデルにヒットすることはもうありません。
</Note>

次元の識別は自動です——自動ルーティングには **30 以上の細分化されたタスク次元**（コード / 数学 / OCR / 図表 / 長文 / 中国語 / ネット検索…）が組み込まれており、「モデルファミリーによる大まかな振り分け」よりもはるかに精緻です。同じ `auto` でも、内容が異なれば異なる次元へルーティングされます：

| あなたのリクエスト                            | 識別される次元                   |
| ------------------------------------ | ------------------------- |
| 通常のテキスト質問                            | `text.overall`            |
| コードを含み、プログラムの作成 / デバッグを要求            | `text.coding`             |
| 数学の証明 / 求解                           | `text.math`               |
| 非常に長い質問（約 500+ token）                | `text.longer_query`       |
| 中国語の質問                               | `text.language.chinese`   |
| 画像入力 + "What is in this image?"      | `vision.overall`          |
| 画像入力 + "OCR…" / "文字を認識"              | `vision.ocr`              |
| 画像入力 + 図表 / フローチャート                  | `vision.diagram`          |
| ネット検索を有効化                            | `search.overall`          |
| 画像生成（`/v1/images/generations`）       | `text_to_image.overall`   |
| 画像編集（`/v1/images/edits`、画像入力 → 画像出力） | `image_edit.single_image` |

これらの次元名は、モデルの**細分化された能力**を分解した業界の権威あるリーダーボードに由来し、`auto` はこれに基づいて各種類のリクエストをその細分能力が最も強いモデルに送ります。よくある領域の例：

* **テキスト**：`text.coding`＝コードの記述 / デバッグ、`text.math`＝数学の求解、`text.longer_query`＝長文処理、`text.language.chinese`＝中国語、`text.occupational.legal` / `text.occupational.medicine`＝法律 / 医療などの職業シナリオ。
* **ビジョン**：`vision.ocr`＝画像内の文字認識、`vision.diagram`＝図表 / フローチャートの理解、`vision.overall`＝汎用的な画像理解。

<Tip>
  次元の識別は保守的なマッチング（高精度、低誤判定）を採用しています：ロングテールで曖昧なリクエストは、無理に分類されるのではなく、より汎用的な次元（例：`text.overall` / `vision.overall`）に落とされることで、誤ルーティングを回避します。
</Tip>

<Note>
  **画像入力も自動ルーティングを通ります**：`/v1/chat/completions` で画像を含める場合、画像タスクとして視覚能力の高いモデルへルーティングされます。本番での実測——「OCR this image」→ `vision.ocr`、`qwen3.5-397b-a17b` がヒット；汎用の画像理解「What is in this image?」→ `vision.overall`、`gpt-5.4-mini` がヒット。（ここでいうのは画像の**理解**です。画像の**生成** `/v1/images/*` も `auto` に対応しています。[FAQ](#よくある質問-faq) を参照。）
</Note>

***

## スコアリーダーボードとモデルプール

各ディメンションのモデルスコアリーダーボードと現在のモデルプールは、[LLM Router ページ](https://aihubmix.com/llm-router/auto?lang=en)でインタラクティブに閲覧できるほか、ログイン不要のオープンエンドポイント（[自動ルーティング戦略の対象モデル範囲](/jp/api/RouterEndpoints/leaderboard)、[モデルベンダーアイコン](/jp/api/RouterEndpoints/vendors)）から直接取得できます。リーダーボードの表示範囲はルーティング候補と一致します。現在正常にルーティング可能なモデルのみが表示され、スコアは各ディメンション内で 0–100 に正規化され、モデルプールに合わせて継続的に更新されます。

***

## 信頼性とフォールトトレランス

自動ルーティングには**多重のフォールトトレランス**が組み込まれており、`auto` パスが**理由もなく失敗することは決してありません**：

<AccordionGroup>
  <Accordion title="サーキットブレーカー：故障モデルを自動的に切り離す">
    ゲートウェイは各モデルについてスライディングウィンドウの失敗率統計を保持します。あるモデルがウィンドウ内で十分な回数失敗し、かつ失敗率がしきい値を超えると、一時的に候補プールから切り離され、一定時間のクールダウン後に自動で復帰します——後続のリクエストを、調子を崩しているモデルに送り続けるのを避けるためです。失敗のシグナルは**上流がそのリクエストに返したエラー**に由来します。ゲートウェイ自身の「利用可能なチャネルなし」はカウントされません（それはモデル自体の問題ではないため）。
  </Accordion>

  <Accordion title="候補なしフォールバック：auto では決して 400 を返さない">
    万が一ハードフィルタですべての候補が除外された場合（例えばあるモダリティの組み合わせに一時的に利用可能なモデルがない場合）でも、ゲートウェイは直接エラーを返さず、出力タイプに応じてフォールバック用のモデルを割り当てて応答を保証し、応答ヘッダーに `X-Aihubmix-Router-Fallback: true` を付与してあなたに知らせます。
  </Accordion>

  <Accordion title="権限逸脱防止線：制限付き Key はフォールバックで回避されない">
    あなたの Key が利用可能なモデルの範囲を限定している場合、自動ルーティング（フォールバックを含む）が選ぶモデルは**常に**その範囲内です。範囲内にこのリクエストを処理できるモデルが本当に一つもない場合は、範囲外（より高価かもしれない）のモデルを黙って使うのではなく、明確に 403 を返します。
  </Accordion>
</AccordionGroup>

***

## 課金について

**実際にヒットしたモデルの定価で課金され、自動ルーティング自体はいかなる追加料金も徴収しません。**

最終的にどのモデルが応答したかに応じて、そのモデルの価格・能力・コンテキスト制限で計算されます——このモデルが、応答ヘッダー `X-Aihubmix-Router-Resolved-Model` と応答ボディの `model` フィールドの値です。言い換えれば、自動ルーティングが「こっそり高いモデルを使う」ことはありません：ヒットのたびに応答に記録され、一件ずつ照合できます。

***

## 制限事項

* 自動ルーティングは現在**チャット補完** `/v1/chat/completions` と**画像生成 / 編集** `/v1/images/*` インターフェースを対象としています（詳細は [FAQ：対応しているインターフェース](#よくある質問-faq) を参照）。

* `?router=off` またはリクエストヘッダー `X-Router-Off` は、`model=auto` に対して直接 **400** を返します——これは「auto を使いたいがルーティングはオフにしたい」という曖昧な使い方を黙って無視するのではなく、明確に拒否するものです：

  ```bash theme={null}
  curl -i "https://aihubmix.com/v1/chat/completions?router=off" \
    -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
    -H "Content-Type: application/json" \
    -d '{"model":"auto","messages":[{"role":"user","content":"hi"}]}'
  # → HTTP/1.1 400 Bad Request
  # {"error":{"message":"auto requires router enabled; remove ?router=off / X-Router-Off", ...}}
  ```

* 候補の集合はプラットフォームの catalog に応じて動的に変化します：同じ `auto` でも、時点が異なれば異なるモデルがヒットすることがあります（これは設計上の仕様であり、応答ヘッダーで後から検証できます）。現在の候補範囲は[自動ルーティング戦略の対象モデル範囲](/jp/api/RouterEndpoints/leaderboard)エンドポイントで照会できます。

***

## OpenRouter / LiteLLM との違い

「モデルを自動選択する」のは AIHubMix 独自のものではなく、OpenRouter と LiteLLM も同様の機能を提供しています。違いは主に**導入コスト**と**ホスティング方式**にあります：

| 違いの観点                                               | OpenRouter | LiteLLM | AIHubMix |
| --------------------------------------------------- | :--------: | :-----: | :------: |
| リクエスト内容に応じた自動モデル選択                                  |      ✅     |    ✅    |     ✅    |
| 設定不要・すぐ使える（ルーティングルール / utterances の記述が不要）           |      ✅     |    ❌    |     ✅    |
| プラットフォームでホスト、proxy の自前構築 / 自己デプロイが不要                |      ✅     |    ❌    |     ✅    |
| コスト / 品質 / レイテンシの複数ポリシーを 1 パラメータで切り替え               |      ❌     |    ❌    |     ✅    |
| ヒット決定が追跡可能（応答ヘッダーに dimension / policy / reason を含む） |      ❌     |    ❌    |     ✅    |
| 最終的にヒットしたモデルで課金                                     |      ✅     |    ❌    |     ✅    |

***

## よくある質問 FAQ

**Q：自動ルーティングはどのインターフェースに対応していますか？**
A：現在 `model=auto` は **OpenAI 互換のチャット補完インターフェース** `/v1/chat/completions` と、**画像生成 / 編集インターフェース**（`/v1/images/generations`、`/v1/images/edits`）に対応しています。音声、`/v1/embeddings`、`/v1/rerank` などのインターフェースは現在 `auto` に非対応のため、具体的なモデルを直接指定してください。

**Q：自動ルーティングは画像入力に対応していますか？**
A：対応しています。`/v1/chat/completions` で画像（`image_url`）を含めた質問は画像の**理解**にあたり、画像タスクとして視覚能力の高いモデル（`vision.ocr`＝画像内の文字認識 / `vision.diagram`＝図表 / フローチャートの理解 / `vision.overall`＝汎用的な画像理解 など）へルーティングされます。画像の**生成**も `auto` に対応しています。`/v1/images/*` インターフェースで `model` に `auto` を指定すると、画像生成ディメンション（例：`text_to_image.overall`）に基づいてモデルが選択されます。

**Q：そのリクエストで結局どのモデルが使われたか、どうやって知るのですか？**
A：応答ヘッダー `X-Aihubmix-Router-Resolved-Model`、または応答ボディの `model` フィールドを見てください——どちらにも実際のモデル名が書き戻されます。[実際にヒットしたモデルの確認方法](#実際にヒットしたモデルの確認方法) を参照。

**Q：自動ルーティングはこっそり高いモデルを使いませんか？**
A：使いません。デフォルトポリシー `cost_optimized` はコスト優先です。さらに、ヒットしたモデルは毎回応答に記録され、その定価で課金されるため、一件ずつ照合できます。[課金について](#課金について) を参照。

**Q：コストはどう制御 / 予測しますか？**
A：3 つの手段を重ねます——① デフォルトの `auto`（`cost_optimized`）がそもそもコスト優先；② **Key の利用可能モデル範囲**を使って候補を許容する価格帯に絞り込み、コストの上限を設けるのに相当；③ ヒットのたびに応答ヘッダー `Resolved-Model` のモデルの定価で課金されるので、一件ずつ照合できます。より高い能力が必要なときに、明示的に `auto:quality_first` を使ってください。

**Q：`auto` と「モデルマッピング / フォールバック」の違いは何ですか？**
A：[モデルマッピング / フォールバック](https://docs.aihubmix.com/jp/api/Model-Mapping-Fallback) は **Key レベルの固定エイリアス + 失敗時の順序付きフォールバック**（毎回同じターゲット）です；自動ルーティングは**リクエストごとの内容に応じた動的なモデル選択**です。前者は「クライアントが特定の名前しか認識しない / メインモデルが落ちたら予備に切り替える」を解決し、後者は「どれでもいいので、最も適したものをくれ」を解決します。

**Q：自動ルーティングが特定の数モデルからだけ選ぶよう限定できますか？**
A：できます——**Key の利用可能モデル範囲**で制約します：自動ルーティングはその Key で許可されたモデルからのみ選び、範囲外のモデルがヒットすることはありません。

**Q：ストリーミングリクエストに対応していますか？**
A：対応しています。ルーティングはリクエストが上流に到達する前に完了し、ストリーミング / 非ストリーミングを同等に扱います。

**Q：なぜ同じ一文を 2 回呼び出すと異なるモデルがヒットしたのですか？**
A：候補の集合と価格はプラットフォームの catalog に応じて動的に変化します。これは設計上の仕様です。応答ヘッダーの `Decision-Id` と `Resolved-Model` を使えば、各決定を後から検証できます。現在の候補範囲は[自動ルーティング戦略の対象モデル範囲](/jp/api/RouterEndpoints/leaderboard)エンドポイントで照会できます。

**Q：リクエストが安定して同じモデルにヒットするようにするには（例えば prompt キャッシュを再利用したい）？**
A：`auto` は現在の catalog に応じて動的にモデルを選ぶため、決定論性は保証されません。同じモデルへの安定したヒットが必要な場合（例えば上流の prompt キャッシュに依存する、または厳密に再現したい場合）は、**具体的なモデル名を直接指定する**か、**Key で利用可能範囲を単一のモデルに限定**してください——この 2 つの方法ではヒットは確定的になります。

***

## 関連リソース

* [モデルマッピングとフォールバック](https://docs.aihubmix.com/jp/api/Model-Mapping-Fallback)：Key レベルの固定エイリアス + 失敗時フォールバックで、自動ルーティングを補完します。
* [統一推論パラメータ](https://docs.aihubmix.com/jp/api/unified-inference)：モデルをまたいで一貫したリクエストパラメータ。
* [AIHubMix モデルページ](https://aihubmix.com/models)：モデル名・価格・`Input Modalities` を確認できます。
* [自動ルーティング戦略の対象モデル範囲](https://docs.aihubmix.com/jp/api/RouterEndpoints/leaderboard)：30+ のルーティングディメンションのうち公開されている 5 カテゴリ 23 サブディメンションのスコアと稼働中モデルプールを、ログイン不要で取得できます。