Workers AI に rejectIfBusy が追加。容量待ちのキューに入らず即失敗させる選択肢が同期推論に入った

要約

Cloudflare は 2026-09-17、Workers AI の同期推論リクエストに rejectIfBusy オプションを追加しました。

機能は1行で説明できます。容量が空いていないとき、キューで待たずにその場で失敗させます。 公式の説明も簡潔で、「アプリケーションが容量キューで待つべきでない場合に使う」とあります。

Workers AI バインディング経由では、env.AI.run() の第3引数としてオプションを渡します。

const response = await env.AI.run(
  "@cf/google/gemma-4-26b-a4b-it",
  { messages: [{ role: "user", content: "Explain capacity queues." }] },
  { rejectIfBusy: true },
);

ネイティブ REST API では、リクエストボディの options に含めます。OpenAI 互換エンドポイントでの使い方と、実際に返るエラーの挙動については、公式ドキュメントの「Reject busy requests」に記載があります。

既定の挙動は変わりません。 オプトインの追加であり、指定しなければ従来どおりキューで待ちます。

この小さなオプションが意味を持つのは、共有インフラ上の推論という前提があるからです。 Workers AI は Cloudflare のエッジで動く共有の推論基盤で、容量は常に空いているとは限りません。 空いていないときの既定の挙動は「待つ」ですが、待った結果いつ返るかは呼び出し側には分かりません。

rejectIfBusy は、その不確実性を「エラー」という確実な形に変換します。

何が変わったか

• Workers AI の同期推論リクエストに rejectIfBusy オプションが追加された
• 容量が空いていないとき、キューで待たずに即座に失敗する
• バインディング経由では env.AI.run() の第3引数として渡す
• REST API ではリクエストボディの options に含める
• OpenAI 互換エンドポイントでの使い方とエラー挙動は公式ドキュメント「Reject busy requests」に記載
• 既定は従来どおり（キュー待ち）。オプトインの追加

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

この機能の価値は、応答時間の上限が決まっている経路にあります。

分かりやすいのは対話 UI です。 ユーザーが質問を投げて、AI が答えるまで待っている画面。容量待ちのキューに入ると、何秒待つか分からないまま画面が固まります。 ユーザーから見れば「壊れている」のと区別がつきません。

rejectIfBusy を使えば、この状態を「混雑しています。少し時間をおいてお試しください」という明示的なメッセージに変えられます。 体験としては、無限に待たせるより明らかに良くなります。

もう1つは、同期 API として外部へ提供している場合です。 SLA に応答時間を書いているなら、キューで待つ挙動は SLA を守れない原因になります。 即座に失敗させて、呼び出し側にリトライを任せるほうが、契約上の説明がつきます。

ただし、使うには呼び出し側の実装が増えます。 rejectIfBusy: true を付けるだけでは、失敗したときに何をするかが決まりません。 最低限、次のどれかを決める必要があります。

• リトライする（何回、どの間隔で）
• 別の経路へ回す（他のモデル、他のプロバイダ、キャッシュ済みの応答）
• ユーザーへ明示的に返す（混雑を伝えて再試行を促す）

「失敗を選べるようになった」ということは、「失敗したときの設計をする責任が呼び出し側に来た」ということです。 既定のままキューで待つほうが、コードは単純です。単純さと予測可能性のトレードオフとして理解するのが正確です。

非同期処理で済む用途では、この機能は不要です。 バッチ処理、夜間の一括分類、非同期のキュー経由の処理——待っても構わない経路では、既定のままで問題ありません。 導入判断は「この呼び出しは待てるか」の一問で決まります。

副業・個人活用視点

Workers AI で何かを作っている個人開発者にとって、これは体験品質に直結する設定です。

個人が作るサービスは、たいてい対話型です。 チャットボット、要約ツール、翻訳フォーム——どれもユーザーが画面の前で待ちます。 無料枠や小規模な構成で動かしていると、容量待ちに当たる確率はそれなりにあります。

「混雑しています」と返すのと、固まったまま返ってこないのとでは、離脱率が違います。 ユーザーは待たされること自体より、いつ終わるか分からないことに耐えられません。rejectIfBusy とリトライの案内メッセージを組み合わせるのは、数行の実装で体験が改善する典型例です。

受託開発では、この種のオプションを知っているかどうかが差になります。 「AI が遅い」という漠然としたクレームに対して、**「容量待ちとモデルの推論時間は別の問題で、前者は失敗させる設定があります」**と切り分けられるのは、実装者としての信頼に直結します。

提案としては、フォールバック設計とセットで出すのが正しい形です。 rejectIfBusy 単体では価値が完結せず、失敗時に何をするかを決めて初めて機能します。 「オプションを1つ付ける作業」ではなく、**「混雑時の振る舞いを設計する作業」**として見積もるべきです。

教材としては、「待つ」と「失敗する」の設計判断を教える題材に向いています。 分散システムの教科書的な話題ですが、rejectIfBusy: true という1行の有無で挙動が変わるという形で示せるので、抽象論になりません。フェイルファストという考え方の入口として扱えます。

関連リンク

• 公式: Reject busy synchronous inference requests
• 調査メモ: docs/research/cloudflare/official-updates/2026-09-17T000000-workers-ai-reject-if-busy.md