AI Gateway に Auto Router — モデル名を `cloudflare/auto` にするとタスクごとに最安モデルへ振り分ける

要約

Cloudflare は 2026-09-30、AI Gateway に Auto Router をパブリックベータで追加しました。モデル指定を cloudflare/auto にするだけで、リクエストごとに「そのタスクを十分にこなせる最も安いモデル」へ自動で振り分けます。

この機能が解こうとしている問題を先に整理します。

LLM を本番で使うとき、モデル選定は最も答えが出ない判断の1つです。 最上位モデルを全リクエストに使えば品質は安定しますが、単純な処理に高額なモデルを使うことになります。 下位モデルで統一すれば安いですが、難しいリクエストで品質が落ちます。 多くの組織は「とりあえず上位モデル」を選び、コストが読めないまま運用しています。

条件分岐で振り分ける手もありますが、これも難しいです。 「短いリクエストは安いモデルへ」のような単純なルールは、文字数と難しさが相関しないため機能しません。「この機能は上位、あの機能は下位」という機能単位の振り分けは、同じ機能に簡単なリクエストと難しいリクエストが混ざると破綻します。

Auto Router は、この判定を2段構えで行います。

第1段は、タスク分類です。 エッジに配置したマルチヘッド分類器が、リクエストを 14種のタスク型に分類し、さらに4軸を1〜5で評点します。4軸は 複雑さ（complexity）/ 曖昧さ（ambiguity）/ 失敗時の重大さ（stakes）/ 文脈依存度（contextual dependence） です。

この4軸の選び方が、よく考えられています。 「難しさ」を1つの数字で測るのではなく、種類の違う難しさを分けている点です。曖昧なリクエスト（何を求めているか不明確）と、複雑なリクエスト（求めていることは明確だが処理が重い）は、必要なモデルの性質が違います。 失敗時の重大さを別軸にしているのも実務的で、「間違えても構わない処理」に高いモデルを使わない判断ができます。

第2段は、スコアリングと選択です。 4軸の評点とモデルのベンチマークデータを組み合わせた評点行列で適合度を推定し、次の式で品質とコストを均衡させます。

utility = 期待品質 − 適応的なコストペナルティ

さらに、長いセッションでは2つの要素が加わります。 キャッシュの読み書きコストと、モデル切り替えのペナルティです。後者が重要で、会話の途中でモデルを切り替えるとプロンプトキャッシュが効かなくなるため、切り替えの損失を計算に含めています。単発のリクエストだけを見て最安を選ぶ実装では、ここが抜けます。

公式が出している数字。 内部計測で、一般知識タスクにおいて成功率 86.6%、成功1回あたり 0.0084 ドル。これは GPT-6 Sol の約80%、Claude Opus の約35%のコストにあたると説明されています。

この数字の読み方には注意が必要です。 「成功1回あたりのコスト」という指標は、成功率とコストを同時に扱うための計算です。安いモデルで失敗してリトライすれば、総コストは上がります。成功あたりで割ることで、その影響を織り込んでいます。 指標としては妥当ですが、「一般知識タスク」という限定条件が付いており、自社のワークロードで同じ結果が出る保証はありません。

提供条件。 パブリックベータで、ベータ期間中は追加料金なしです。使い方は、モデル名に cloudflare/auto を指定するだけです。

今後の予定として、対応モデルの拡大、ゼロデータ保持（ZDR）によるフィルタリング、プロバイダー側の空き容量の考慮、リクエストごとの reasoning 強度の最適化、構造化された意思決定モデルの検討が挙げられています。

何が変わったか

• モデル名に cloudflare/auto を指定すると、リクエストごとに自動でモデルを選択
• 第1段: タスク分類 — エッジのマルチヘッド分類器が 14種のタスク型に分類し、4軸を各1〜5で評点
  • 複雑さ / 曖昧さ / 失敗時の重大さ / 文脈依存度
• 第2段: スコアリング — 4軸 + モデルのベンチマークデータによる評点行列で適合度を推定
  • utility = 期待品質 − 適応的なコストペナルティ
• 長いセッションではキャッシュの読み書きコストとモデル切り替えのペナルティも計算に含める
• 公式の内部計測（一般知識タスク）: 成功率 86.6%、成功1回あたり 0.0084 ドル
  • GPT-6 Sol の約80%、Claude Opus の約35%のコスト
• パブリックベータ。ベータ期間中は追加料金なし
• 今後: 対応モデルの拡大、ZDR フィルタリング、プロバイダーの空き容量考慮、reasoning 強度の最適化

業務インパクト（一般企業向け）

この機能の価値は、コスト削減そのものよりも「モデル選定という判断を手放せること」にあります。

社内で LLM を使うシステムを運用していると、必ず同じ会議が繰り返されます。 「このモデルで十分か」「上位モデルに変えたら品質は上がるのか」「コストが見積もりを超えているが、どこを下げればいいか」。これらに答えるには、モデルごとの品質とコストを自社のワークロードで比較する必要があり、その検証自体に工数がかかります。 結果として、検証されないまま「とりあえず上位モデル」で運用が続きます。

Auto Router は、この判断を外部化します。 自社で比較表を作る代わりに、Cloudflare が持つベンチマークデータと分類器に任せるという選択です。

導入を検討する際の判断軸を、3つに分けて書きます。

1つ目は、監査と再現性の要求です。ここが最大の論点になります。

Auto Router を使うと、どのモデルが使われたかが実行時に決まります。 これは、次のような要求と衝突します。「この処理はこのモデルで行っている」と文書化する必要がある場合。 過去の出力を再現する必要がある場合。 特定のモデルプロバイダーへのデータ送信を制限している場合。

3番目が特に重要です。 多くの組織は「どのモデルプロバイダーへデータを送るか」を審査しています。Auto Router が審査外のプロバイダーへ振り分けると、統制が崩れます。 公式が今後の予定に ZDR フィルタリングを挙げているのは、この問題への対応と読めますが、現時点では未提供です。

したがって、現時点の推奨は「統制要求が低い処理から試す」です。 社内向けの検索補助、ドキュメントの要約、分類の下書き。顧客データを含まず、出力の再現性を求められない処理が、最初の対象として適切です。

2つ目は、効果の測定方法です。

「80%のコストになった」という公式の数字を、自社の削減見込みとして使ってはいけません。 条件が違います。測定は自分で行う必要があります。

現実的な測定方法は、並行実行です。 同じリクエストを、現行のモデル固定と cloudflare/auto の両方へ流し、出力品質とコストを比較します。 一定期間（2週間程度）のデータが取れれば、判断できます。

比較すべきは、コストだけではありません。 (1) コスト — これは明確に出ます。(2) 出力品質 — 人が評価する必要があり、ここが工数のかかる部分です。(3) レイテンシ — 分類器が1段挟まるため、理論上は増えます。実測値を確認してください。

3番目のレイテンシは見落としやすい点です。 分類はエッジで行われるため影響は小さいはずですが、対話型のインターフェースでは数十ミリ秒が体感に出ます。 バッチ処理なら無視できます。

3つ目は、ベータという状態です。

追加料金なしは魅力的ですが、ベータ期間が終われば価格が付く可能性があります。 価格が未定の機能に依存した構成を本番の中心に置くのは、避けた方が安全です。

より実務的な懸念は、挙動の変更です。 分類器とスコアリングは Cloudflare 側で更新されます。 つまり、自社のコードを変えていないのに、選ばれるモデルが変わる可能性があります。品質が上がる方向の変更であっても、「先週と同じ結果が出ない」という事象として現れます。

対策は、固定モデルへの切り戻し経路を用意しておくことです。 cloudflare/auto と明示的なモデル名を設定で切り替えられる構成にしておけば、問題が出たときに戻せます。これは数行の作業です。

最後に、この機能が示している方向について。

「モデル選定」は、2023年以降ずっと人間が判断してきた領域です。 それが機械的な判定へ移りつつあります。これは、モデルの性能差が「どちらが優れているか」から「どのタスクにどちらが適しているか」へ変わったことの帰結です。 一方的に優れたモデルがあるなら、振り分ける意味はありません。振り分けに価値が出るのは、適性が分かれているからです。

組織としての含意は、「モデル選定の知識」への投資配分を考え直すことです。 どのモデルが何に強いかという知識は、こうした機能に吸収される方向にあります。 代わりに価値が残るのは、自社のタスクをどう分類するか、どの程度の品質で十分とするかという判断です。これは外部化できません。

副業・個人活用視点

個人開発や小規模な受託で LLM を使っている場合、この機能は直接的にコストへ効きます。

個人開発のコスト構造は、企業と違います。 企業は「月額数万円の API 費用」を許容しますが、個人の趣味プロジェクトでは月数千円でも痛みます。 その結果、無料枠の範囲で動かすか、安いモデルで統一するという選択になりがちです。

安いモデルで統一する運用の問題は、品質の悪化が見えにくいことです。 難しいリクエストで微妙に間違った出力が出ても、ユーザーが少なければ気づきません。 気づいたときには、「このツールは使えない」という評価が付いています。

Auto Router は、ここに効きます。 簡単なリクエストは安いモデルへ、難しいリクエストだけ上位モデルへ。この振り分けを自分で実装しようとすると、分類のロジックを書くことになり、現実的ではありません。 cloudflare/auto を指定するだけで済むなら、個人のプロジェクトでも実装できます。

ベータ期間中は追加料金なしという点も、個人には大きいです。試すコストがゼロに近いです。

受託の文脈では、提案材料として使えます。

「LLM のコストが読めない」は、AI 機能を入れた顧客からほぼ必ず出る相談です。 多くの場合、顧客は上位モデルで全リクエストを処理しています。理由は、他の選択肢を検討する工数がなかったからです。

ここで提案できる作業は、こうです。 (1) 現在のリクエストの分布を調べる（どんなリクエストが何割か）。(2) cloudflare/auto との並行実行で比較する。 (3) 品質が落ちない範囲での削減幅を出す。

この作業の価値は、削減額が数字で出ることです。 「月の API 費用が3万円から1万円になりました」という報告は、支援の効果として最も説明しやすい形です。 品質改善の提案は効果を証明しにくいですが、コスト削減は請求書で証明できます。

提案時の注意点を2つ書きます。

1つ目。削減幅を事前に約束しないこと。 公式の「約80%」は一般知識タスクの数字です。顧客のワークロードが難しいタスクに偏っていれば、振り分けても上位モデルが選ばれ続け、削減は出ません。 「測定します」と言うべきで、「削減できます」と言ってはいけません。

2つ目。顧客のデータ統制を先に確認すること。 どのモデルプロバイダーへデータが行くかを顧客が管理している場合、Auto Router は提案できません。 ZDR フィルタリングは今後の予定であり、現時点では未提供です。この確認を飛ばして提案すると、情報セキュリティの審査で止まります。 止まるだけなら構いませんが、確認不足と見られると、以降の提案の信頼が落ちます。

学習の観点では、4軸の分類そのものを覚える価値があります。

複雑さ / 曖昧さ / 失敗時の重大さ / 文脈依存度。 この4つは、自分がリクエストを設計するときのチェックリストとしても使えます。

特に「曖昧さ」と「複雑さ」を分けて考える習慣は、プロンプト設計の質を上げます。 出力が期待と違うとき、原因が**「指示が曖昧だった」のか「処理が重くてモデルが足りなかった」のか**を切り分けられるようになります。前者はプロンプトを直し、後者はモデルを上げる。この切り分けができないと、曖昧な指示のままモデルを上げ続けることになり、コストだけが増えます。

「失敗時の重大さ」を軸に持つことも実務的です。 すべての処理に同じ品質を求める必要はありません。下書きの生成に最上位モデルを使う理由は、普通はありません。 この判断を意識的に行えるかどうかが、小さな予算で運用する人の実力差になります。