# モデルの自動選択

Source: https://docs.aiand.com/ja/models/auto/

`auto` は予約されたモデル名です。`model` に指定すると、ai& がそのリクエストに対して具体的なモデルを選択し、通常どおり処理します。リクエスト / レスポンスの形式、ストリーミングの挙動、課金ルールは、モデル名を直接指定した場合と同じです。

用途の異なるリクエストが混在するワークロードで、すべてを最も高価なモデルに送らずに済ませるための機能です。短い検索的な質問は安価なモデルに、推論を要する処理はそれが可能なモデルに解決されます。

## 使い方

<Tabs>
<TabItem label="curl">

```bash
curl -i https://api.aiand.com/v1/chat/completions \
  -H "Authorization: Bearer sk-your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto",
    "messages": [{"role": "user", "content": "日本の首都は?"}]
  }'
```

</TabItem>
<TabItem label="Python">

```python
from openai import OpenAI

client = OpenAI(base_url="https://api.aiand.com/v1", api_key="sk-...")

response = client.chat.completions.with_raw_response.create(
    model="auto",
    messages=[{"role": "user", "content": "日本の首都は?"}],
)
print(response.headers["x-model"])
print(response.parse().choices[0].message.content)
```

</TabItem>
<TabItem label="Node.js">

```ts

const client = new OpenAI({ baseURL: "https://api.aiand.com/v1", apiKey: "sk-..." });

const { data, response } = await client.chat.completions
  .create({
    model: "auto",
    messages: [{ role: "user", content: "日本の首都は?" }],
  })
  .withResponse();

console.log(response.headers.get("x-model"));
console.log(data.choices[0].message.content);
```

</TabItem>
</Tabs>

`auto` は `/v1/chat/completions`、`/v1/completions`、`/v1/responses`、`/v1/messages` で利用できます。

## 実行されたモデルの確認

解決されたモデルのカタログ名（小文字化）は、レスポンスヘッダ `X-Model` で返されます。比較は大文字小文字を区別せずに行ってください。ストリーミングでも同様に取得できます — レスポンスヘッダはボディの最初のチャンクより先に到達するため、ストリームが開いた時点で読み取れます。

```
X-Model: deepseek-ai/deepseek-v4-flash
```

このヘッダは CORS で公開しているため、ブラウザのクライアントからも読み取れます。[リクエストログ](/ja/analytics/logs/) と利用実績にも解決後のモデル名が記録されます (`auto` は記録されません)。そのため、自動選択を使っているかどうかに関わらず、コストの按分や分析はそのまま機能します。[レスポンスヘッダ](/ja/reference/response-headers/) も参照してください。

## モデルの選択方法

以下の 3 ステップで決定します。

1. **絞り込み** — **そのリクエスト**に対して組織が呼び出せるモデルに限定します。自動選択のプールに追加されていること、プラン上の利用権があること、プロンプトがコンテキストウィンドウに収まること、リクエストに含まれるすべての入力モダリティ (画像・動画・音声) に対応していること、が条件です。
2. **並べ替え** — 残ったモデルを能力の低い順に並べます。能力が同等のモデル同士では、価格の安い方が先になります。
3. **選択** — リクエストの複雑さを 4 段階のティアに分類し、ティアがそのリストの中の位置を決めます。

| ティア      | 解決先の傾向         | 典型的なリクエスト                                   |
| ----------- | -------------------- | ---------------------------------------------------- |
| `simple`    | 最も能力の低いモデル | 挨拶、相槌、短い答えが決まっている事実の確認         |
| `medium`    | リストの下寄り中間   | ある程度の説明を要する日常的なリクエスト             |
| `complex`   | リストの上寄り中間   | 平易でないコード、多段階の分析、専門知識を要するもの |
| `reasoning` | 最も能力の高いモデル | 証明、導出、症状からのデバッグ、設計上のトレードオフ |

能力の順位は価格ではなく、公開されているベンチマーク結果に基づきます。価格と能力は必ずしも一致せず、高価であることは性能が高い根拠にはならないためです。まだ順位付けされていないモデルは `auto` の選択対象になりません。利用する場合はモデルを直接指定してください。

**プールは、能力と価格が揃って上がるように選定しています。** 上の説明で「安価なモデル」と「最も能力の低いモデル」が同じ選択を指しているのはこのためで、両者は競合する基準ではありません。あるモデルがプールに入るのは、それより安価で同等以上に能力の高いモデルが存在しない場合に限られるため、能力順に並べることは価格順に並べることでもあります。価格ではなくベンチマークで順位付けしているのは、カタログが変化してもこの前提を保つためです。能力が変わらないまま価格だけが上がったモデルは、リストの上位へずれていくのではなく、プールから外れます。

`reasoning` ティアでは、組織が `reasoning` capability を持つモデルを利用できる場合、まずそれらに絞り込みます。

**難易度の判定には通常、別のモデルが介在します。** 挨拶や相槌はローカルで判別し、プール内で最も能力の低いモデルに解決します。それ以外はすべて当社が選定した小規模モデルが判定し、これが唯一の難易度判定です。難しいリクエストをローカルでスコアリングすることはありません。キーワードの一覧では、あらゆる言語で難易度を確実に判定できないためです。

この問い合わせが行われる場合、リクエストのテキスト (一定の長さに切り詰め、システム指示は別のラベルを付与したもの) が、回答するモデルの実行前にその判定用モデルへ送信されます。判定用モデルは当社のカタログから選ばれ、お客様の組織が通常利用しているモデルとは限らないため、別のプロバイダになることもあります。この判定分が課金されることはなく、使用量にも表示されません。なお、較正のため、それ以外のリクエストのごく一部も背後で判定しています。指定したモデル以外にリクエストが渡らないことがデータ取り扱い上の要件である場合は、モデルを直接指定してください。

**`auto` は `reasoning_effort` を受け付けません。** 指定した場合は 400 になります。effort を自分で選びたい場合は、モデル名を直接指定してください。上記の並び順は各モデルの公開指標に基づいており、この指標はモデルごとに 1 つの構成で計測された値です。そのため、呼び出し側が effort を指定すると、並び順が前提としているその計測点からモデルがずれてしまいます。`auto` はモデルのみを選び、effort はそのモデル本来の既定値 — つまり指標が計測された設定 — のままにします。

`reasoning_effort: "none"` も同様に拒否します。理由はより明確で、推論モデルの思考を抑制した状態は、そのモデルが順位付けされた計測点から最も遠い状態だからです。

`/v1/responses` の `reasoning.effort` も同じ扱いです。エンドポイントごとのフィールド名の違いに関わらず、規則は変わりません。

**クレジット残高がない場合は、ティアに関わらず無料モデルへ優先的に絞り込みます。** 有料モデルを選んでも、指定していないモデルに対してクレジット不足のエラーが返るだけだからです。プール内に無料モデルがない場合は、通常どおりそのエラーが返ります。

プールは組織ごとに異なるため、同じプロンプトでも組織が違えば別のモデルに解決されることがあります。

## 課金

解決されたモデルの通常の入力 / 出力単価で課金されます。`auto` の利用に対する追加料金はなく、明細も分かれません。実行されたモデルに対する課金として計上されます。

つまり、プールが変われば**同一のリクエストでも呼び出しごとにコストが変わり得ます**。単一モデルの単価ではなく、[利用状況](/ja/billing/usage/) の合計値を基準に予算を見積もってください。

## 会話

`auto` はリクエストごとに判定するため、複数ターンの会話は毎ターン再判定されます。前のターンより難しいと判定された追加質問は別のモデルに解決されることがあり、`X-Model` はスレッドの途中で変わり得ます。

これには把握しておくべきコストがあります。[プロンプトプレフィックス割引](/ja/models/pricing/)は会話が同じモデルに続く間だけ適用されるため、モデルが切り替わったターンではその割引を失います。会話全体で 1 つのモデルを使う必要がある場合は、モデルを直接指定してください。指定したモデルが再ルーティングされることはありません。

## その他の制約

- **判定用モデルが利用できない場合、リクエストはプールの中間に解決されます。** タイムアウトや障害時には難易度を判定する材料がないため、挨拶と判別されなかったリクエストは推測に頼らず、中位の能力のモデルに解決します。これは意図的に最も能力の低いモデルではありません — 難しいリクエストが黙って格下げされることはない、という意味です — が、`X-Model` が同じリクエストの通常の解決先と異なり得ることは意味します。固定する必要がある場合は、モデルを直接指定してください。
- **`auto` は `GET /v1/models` に含まれません。** モデルではなくルーティングの指示であり、固有の capability・コンテキストウィンドウ・価格を持ちません。
- **プールは変化します。** カタログの更新に伴い、モデルは追加も削除もされます。特定のプロンプトが常に特定のモデルに解決されることを前提としたロジックは避けてください。
- **capability の要件は絞り込むだけで、上書きはしません。** 画像を含むリクエストは画像に対応したモデルのみを対象とします。プール内に該当するモデルがなければ、画像を黙って無視するのではなくリクエストを拒否します。

## エラー

| ステータス | メッセージ                                             | 原因                                                                                                   |
| ---------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ |
| 400        | `Model 'auto' is not supported.`                       | 自動選択が有効化されていません。モデル名を直接指定してください。                                       |
| 400        | `No model available to 'auto' can serve this request.` | プール内にリクエストを処理できるモデルがありません。多くはモダリティまたはコンテキスト長の不一致です。 |
| 400        | `Model 'auto' does not accept reasoning_effort.`       | `auto` は effort もモデルと併せて決定します。自分で指定する場合はモデル名を直接指定してください。      |

いずれも [エラー](/ja/errors/) に記載の `invalid_request_error` の形式です。`param` は `model`、最後の 1 件のみ送信した effort のフィールド名になります。