Batch APIと同じ料金で使えるOpenAI APIのFlex processingを試してみる

リテールアプリ共創部の末永です。

Batch APIは通常料金の半額で利用できますが、非同期で実行され、完了まで最大24時間かかります（実際にはより早く完了する場合もあります）。Batch APIより早く、同じリクエスト内で結果を受け取りたい場合に使えるのがFlex processingです。

Flex processingとは

Flex processingは、応答速度と一時的なリソース不足を許容する代わりに、Responses APIまたはChat Completions APIを低い料金で利用できる処理方式です。

料金はBatch APIと同じで、通常料金の半額です。さらにPrompt cachingの割引も併用できます。

リクエストにservice_tier: "flex"を追加するだけなので、Batch APIのようなファイル作成、ジョブ登録、ステータス確認、結果ファイルの取得は必要ありません。APIのレスポンスとして、そのまま生成結果を受け取れます。

一方で、以下のようなデメリットもあります。

• 通常処理より応答に時間がかかる可能性がある
• リソースが不足すると429 Resource Unavailableになる場合がある
• ベータ版で、対応モデルが限られている（GPT-5.6シリーズはすべて対応）

エンドユーザーが画面の前で待つ処理ではなく、評価、データの付加、夜間処理など、多少遅くても問題ない処理が主な用途です。

Standard、Flex、Batch APIの違い

ざっくり整理すると次のようになります。

Batch APIには同期APIとは別の大きなレート制限枠もあります。大量のリクエストをまとめて処理でき、完了まで最大24時間を許容できるなら、要件によってはBatch APIが向いていると思います。

Flexは、1件ずつの処理フローを保ちたいものの、応答速度よりコストを優先したい場合の中間的な選択肢です。

料金

記事執筆時点では、Flex processingに対応しているgpt-5.6-sol、gpt-5.6-terra、gpt-5.6-lunaの料金はいずれもStandardの半額です。ここではgpt-5.6-terraを例にします。単位は100万トークンあたりで、短いコンテキストの場合です。

入力、出力、Prompt cachingのいずれも半額になっています。対応モデルと最新の料金はOpenAI APIのPricingを確認してください。

実際に使ってみる

公式のOpenAI SDKでは、Responses APIのservice_tierにflexを指定します。

import OpenAI from "openai";

const client = new OpenAI({
  timeout: 15 * 60 * 1000,
});

const response = await client.responses.create({
  model: "gpt-5.6-terra",
  input: "この文章を3行で要約してください。\n\n<要約する文章>",
  service_tier: "flex",
});

console.log(response.output_text);
console.log(response.service_tier);

呼び出し方は通常のResponses APIとほとんど変わりません。レスポンスのservice_tierを見ると、実際に適用された処理方式も確認できます。

Flexは通常より時間がかかる可能性があるため、OpenAI公式のFlexサンプルではSDKのタイムアウトを15分に設定しています。サードパーティのSDKを使う場合も、そのSDK側でタイムアウトを長めに設定しておくのが良いと思います。

例えば、Vercel AI SDKのOpenAI providerを使う場合は、providerOptionsでFlexを指定できます。

import { openai } from "@ai-sdk/openai";
import { generateText } from "ai";

const result = await generateText({
  model: openai.responses("gpt-5.6-terra"),
  prompt: "この文章を3行で要約してください。\n\n<要約する文章>",
  timeout: 15 * 60 * 1000,
  providerOptions: {
    openai: {
      serviceTier: "flex",
    },
  },
});

console.log(result.text);
console.log(result.providerMetadata?.openai?.serviceTier);

100回実行して時間と拒否率を確認する

Flexが実際にどのくらい遅くなるのか、リソース不足でどの程度拒否されるのかを確認しました。

検証条件は次のとおりです。

• モデル: gpt-5.6-terra
• StandardとFlexを各100回実行
• 各処理方式について最大20並列
• 短い日本語の判断・要約タスクを2文以内で出力
• 1リクエストあたり平均約190入力トークン、約65出力トークン
• Reasoning effortはnone
• Prompt cachingは未使用
• リトライ処理なし

Flex自体の拒否率を見るため、今回はリトライを行っていません。

結果はこちらです。時間はリクエスト開始からレスポンス全体を受け取るまでを計測しています。

今回の検証では、Flexでも100件すべて成功し、429 Resource Unavailableは発生しませんでした。レイテンシもStandardとほぼ同じで、Flexの方がわずかに短い結果になりました。

今回はたまたまFlexの方が速い結果になりました。一方、私が実際に利用した際は、混雑時のエラーで処理が止まったり、リトライが発生したりして、結果的に時間がかかることもありました。

実際に消費したトークンから料金も計算しました。

生成ごとに出力トークン数が少し変わったため厳密に50%ではありませんが、実測でもほぼ半額になりました。同じトークン数であれば、料金表どおり50%になります。

エラーと再試行を考える

Flexでリソースを確保できない場合は429 Resource Unavailableが返り、そのリクエストには課金されません。

エラー処理は公式ドキュメントに倣い、指数バックオフ（再試行までの待ち時間を1秒、2秒、4秒……と延ばす方法）でFlexのまま再試行するか、完了を優先する場合はStandardへ切り替えて再試行するのが良いと思います。

夜間処理など、次の実行機会まで待てる処理であればFlexのまま再試行し、その実行内での完了を優先したい処理ならStandardへフォールバックする、といった使い分けが考えられます。

また、FlexにはBatch APIの「24時間以内」のような完了時間の保証はありません。長時間のリクエストではタイムアウトも起こりうるため、再実行しても問題ない処理に使うのが安全です。

最後に

同期的に結果を受け取りたいものの、API利用料金がネックになる処理では、Flex processingを検討してもよいと感じました。
余談ですが、Amazon Bedrockにも同名のFlex Tierを含むService Tiersがあり、似た考え方で処理方式を選択できます（対応モデルや料金は異なります）。

では👋