OpenAIのプロンプトは、1行だけ試すと安く感じられます。しかし、同じ処理をスプレッドシートの10,000行、100,000行に繰り返すと、トークン料金は無視できない金額になります。OpenAI Flex Modeは、処理速度が遅く、応答時間を予測しにくい点を許容できる場合に、対応モデルの処理コストを抑えられる仕組みです。
Datablistなら、このトレードオフを実際の業務に取り入れやすくなります。CSVまたはExcelファイルをインポートし、Ask ChatGPT/OpenAI enrichmentで各行に1つずつプロンプトを実行できます。出力をプレビューしてFlexを有効にし、失敗した行を確認するところまで、APIパイプラインを構築せずに進められます。まず基本的な設定を確認したい場合は、CSVやExcelの各行にChatGPTプロンプトを実行する方法をご覧ください。
本記事では、サポートチケットの分類を例に、Flexが適しているかの判断方法、StandardとFlexのコスト比較、実行設定、遅延・失敗した行への対処方法をご説明します。目的は、モデルを高速化したり、回答品質を高めたりすることではありません。時間よりコストを優先できる場合に、同じ行単位の処理をより低いトークン単価で実行することです。
クイックリンク
- OpenAI Flex Modeで変わること
- Flex Modeが適しているケース
- CSVとプロンプトの例
- 実行前にStandardとFlexのコストを比較する
- DatablistでAsk ChatGPT/OpenAIを設定する
- プレビュー・実行・結果確認
OpenAI Flex Modeで変わること
Flexは、対応するOpenAI APIモデル向けのservice tierです。リクエストは通常どおりResponses APIまたはChat Completions APIを経由しますが、service_tier: "flex"が使用されます。処理速度の低下や一時的なキャパシティ不足を許容する代わりに、Flexのトークン料金が適用されます。
OpenAIによると、FlexのトークンにはBatch APIの料金が適用されます。2026年7月16日に確認したOpenAIの料金ページでは、FlexとBatchの料金が同額でした。gpt-5.4-miniの場合、Flexの入力・出力料金はStandardより50%低く設定されていました。
これは処理方法の選択であり、別のモデルを使用するわけではありません。プロンプト、入力行、出力スキーマはそのまま維持できます。運用上のトレードオフは次のとおりです。
- 応答に時間がかかる場合がある
- 完了時間を予測しにくい
- リクエストがタイムアウトしやすい
- Flexのキャパシティを利用できない場合、OpenAIから
429 Resource Unavailableが返されることがある
OpenAIのFlex processingガイドによると、リソース不足で処理できなかったリクエストには料金が発生しません。後から再試行するか、コスト削減より完了を優先したい場合は、失敗した行だけStandard processingに切り替えられます。
FlexはOpenAI Batch APIとも異なります。Batchは、送信したジョブを処理する専用の非同期APIです。一方、Flexは、対応する通常のAPIリクエストで利用するservice tierです。Datablistがリクエスト前後の行単位のワークフローを処理するため、Batchジョブを自分で作成・監視する必要はありません。
また、ChatGPTのWeb版サブスクリプションに含まれる機能でもありません。APIとChatGPTアプリでは、料金体系もワークフローも別です。Datablistでは、ご自身のOpenAI APIキー、または対応モデル向けのDatablist creditsを利用できます。
🔑 押さえておきたいポイント
Flexで変わるのは処理コストと所要時間です。出力品質が向上するわけではなく、すべてのモデルで利用できるわけでもありません。
プロンプトを大規模に繰り返し実行する方法について詳しくは、LLMのバッチ処理をご覧ください。
Flex Modeが適しているケース
最初に確認すべきなのは、コストを抑えられるなら、処理時間が長くなっても問題ないかという点です。
答えが「はい」なら、Flexを検討する価値があります。たとえば、夜間のチケット分類、レビューの要約、テキストからの構造化データ抽出、バックグラウンドでのLead分類などです。ChatGPTによるECカタログ翻訳のような大規模かつ緊急性の低い処理も、選択したモデルがFlexに対応していれば適しています。
これらのタスクには、3つの共通点があります。多数の行に安定したプロンプトを繰り返し適用すること、出力を後から確認できること、そして各回答を人がリアルタイムで待つ必要がないことです。
次のような場合は、Standard processingをお使いください。
- 同じセッション中に結果が必要な場合
- 1行の失敗や遅延が緊急のワークフローを止める場合
- 選択したモデルがFlexに対応していない場合
- 低コストより予測可能なレイテンシが重要な場合
新しいプロンプトを、いきなりFlexで大規模実行することも避けています。まず少量のプレビューで、プロンプトと出力スキーマを安定させましょう。Flexで処理料金は下げられますが、曖昧な指示、不要な入力テキスト、過大な出力を補うことはできません。
💡 プロンプトが安定してからFlexを使う
まず10〜20行でテストしてください。ラベル、要約、レビュー条件に問題がなければ、バックグラウンド処理でFlexを標準的な選択肢にできます。
DatablistのAsk ChatGPT/OpenAI enrichmentは、各行に1つのプロンプトを実行し、回答をプロパティに保存したうえで、行単位の処理ステータスを確認できるため、この用途に適しています。
CSVとプロンプトの例
ここでは、DatablistのSupport tickets AIサンプルを使用します。サンプルCSVファイルライブラリから入手できます。100行版は設定やスクリーンショットの確認に手頃で、10,000行版ではコスト差をより把握しやすくなります。
入力データには、次の列があります。
Ticket SubjectTicket TextCustomer PlanPriority Hint
各行で行う処理は同じです。チケットを分類し、緊急度を付け、問題を要約したうえで、判断が難しいケースをレビュー対象としてマークします。処理をバックグラウンドで実行でき、出力も短いため、Flexに適したタスクです。
最初に使用するプロンプトは次のようになります。
このサポートチケットを業務レポート用に分類してください。
チケットの件名:{{Ticket Subject}}
チケット本文:{{Ticket Text}}
顧客プラン:{{Customer Plan}}
優先度のヒント:{{Priority Hint}}
短い構造化データのみを返してください。
二重波括弧で囲まれた式は、prompt variablesです。Datablistが、処理対象行の値に置き換えます。
1つの長い文章ではなく、次の4つのstructured outputsを使用することをおすすめします。
Ticket Topic:Billing、Bug、Feature Request、Account Access、Cancellation、OtherのいずれかUrgency:Low、Medium、HighのいずれかOne Sentence Summary:簡潔な1文Needs Review:チケットが曖昧、不完全、優先度のヒントと矛盾する、または結果が返らない場合はYes
このスキーマなら結果を絞り込みやすく、出力トークンも抑えられます。また、不確かな判断を文章の中に埋もれさせず、通常のキューから分けて確認できます。
実行前にStandardとFlexのコストを比較する
本格的な設定を始める前に、コストを見積もりましょう。実際の行数に対して、処理速度の低下に見合う削減効果があるかを確認するためです。
計算には次の2つの要素を使用します。
- 入力コスト = 行数 × 1行あたりの平均入力トークン数 × 1トークンあたりの入力料金
- 出力コスト = 行数 × 1行あたりの平均出力トークン数 × 1トークンあたりの出力料金
- 合計コスト = 入力コスト + 出力コスト
この例ではgpt-5.4-miniを使用し、1行あたりの入力を250トークン、出力を30トークンとします。以下は2026年7月16日時点で確認した料金です。
| Service tier | 入力100万トークンあたりの料金 | 出力100万トークンあたりの料金 |
|---|---|---|
| Standard | $0.75 | $4.50 |
| Flex | $0.375 | $2.25 |
1,000行の場合、Standardの入力コストは250,000 × $0.75 ÷ 1,000,000で、$0.1875です。出力コストは30,000 × $4.50 ÷ 1,000,000で、$0.135です。合計すると、実行コストは約$0.32になります。
この例ではFlexによって両方の単価が半分になるため、同じ処理を約$0.16で実行できます。
| 行数 | Standardの見積もり | Flexの見積もり | 推定削減額 |
|---|---|---|---|
| 1,000 | $0.32 | $0.16 | $0.16 |
| 10,000 | $3.23 | $1.61 | $1.61 |
| 100,000 | $32.25 | $16.13 | $16.13 |
ここでの金額が小さいのは、プロンプトと出力がコンパクトだからです。短いチケットを長い文字起こし、商品説明、スクレイピングしたWebページなどに置き換えると、入力コストは急速に増えます。4つの短いフィールドではなく詳細な回答を求めれば、出力コストも上昇します。
この表は料金表ではなく、計算方法のひな型として使用しています。実際に処理する前に、モデル、service tierの料金、平均入力トークン数、平均出力トークン数の4項目を更新してください。対応モデルや料金は変更されるため、過去の見積もりを流用せず、OpenAIの料金ページを再確認しましょう。
ご自身のAPIキーを使用する場合、OpenAIアカウントに請求されます。Datablist creditsを使用する場合は、対応モデルの処理量がDatablist creditsに換算されます。正確なcredit使用量はモデルとトークン消費量によって変わるため、いずれの場合もプロンプトと出力は簡潔に保つことをおすすめします。
⚠️ 料金は変更される可能性があります
50%の削減率は、上記の対応モデルと確認時点の料金に基づくものです。この計算は再利用可能なひな型として扱い、恒久的な料金表や、すべてのモデルに対する保証とは考えないでください。
DatablistでAsk ChatGPT/OpenAIを設定する
ワークロードと削減効果に納得できたら、enrichmentを設定します。わずかな設定の緩みも全行に影響するため、一つひとつ慎重に進めましょう。
1. CSVをインポートするかcollectionを開く
CSVまたはExcelファイルをDatablistにインポートするか、対象行がすでに存在するcollectionを開きます。4つの入力列に、有用な値が入っていることを確認してください。意味のある入力がない行に料金をかけてもメリットはないため、モデルを呼び出す前に、チケット本文が空の行を除外します。
2. Ask ChatGPT/OpenAIを選択する
Enrichを開き、Ask ChatGPT/OpenAIを選択します。このenrichmentは、選択した各行に1件ずつリクエストを送信し、設定した出力プロパティに回答を書き込みます。
3. 処理料金の支払い方法を選ぶ
OpenAIから直接請求を受ける場合は、ご自身のOpenAI APIキーを使用します。選択したモデルとアカウントが対応している場合は、Datablist creditsも選択できます。Processing tierの選択と支払い方法は、それぞれ独立した設定です。
4. 行単位のプロンプトを追加する
サポートチケット用のプロンプトを貼り付け、variable pickerから各フィールドを挿入します。指示は短くまとめ、最後に希望する出力形式を指定します。背景情報を各行で何度も繰り返すと、入力トークンを無駄に消費します。
チケットのフィールドが空になることが多い場合は、モデルにどう処理させるかを決めておきましょう。たとえば、モデルに不足情報を推測させるより、Needs Review = Yesとする方が安全です。
5. Structured outputのプロパティを設定する
Structured outputオプションを有効にし、例で示した4つのプロパティを追加します。各フィールドには短い説明を設定し、必要に応じて許可するラベルを定義してください。
Structured outputは後工程のクリーンアップを減らせますが、ここでの最大の利点は出力を制御できることです。Urgencyというフィールドに3つの許可ラベルを指定すれば、モデルが長い説明を返す余地を減らせます。
6. Flex対応モデルを選択する
モデルセレクターを開き、flex compatibleと表示されたモデルを選択します。Datablistでは、選択したモデルが対応している場合にのみFlexの設定が表示されます。
このコスト例では、GPT-5.4 miniを使用します。同じモデルが今後も利用できるとは限りません。新しいワークフローを開始するときは、Datablist上のラベルと最新のOpenAI料金ページをご確認ください。
7. Flex Modeを有効にする
Advanced Settingsをオンにし、Use Flex Modeを有効にします。
トグルが表示されない場合、選択したモデルはDatablistでFlex対応と認識されていません。対応モデルを選ぶか、Standard processingをご利用ください。
8. デフォルトのタイムアウトで開始する
DatablistにおけるFlexの現在のデフォルトタイムアウトは360秒、つまり6分です。最初のプレビューでは変更せずに使用します。タイムアウトが発生し、かつ処理時間がさらに延びても問題ない場合にのみ、値を増やしてください。
設定できるタイムアウトは30〜1,500秒です。値を大きくすると、遅いリクエストが完了するまで長く待てますが、キャパシティや一定時間内の応答が保証されるわけではありません。
9. 重複の可能性がある場合はキャッシュを維持する
Datablistでは、設定が同一の同じプロンプトを48時間キャッシュできます。重複したチケットや説明文から同じリクエストが生成される場合、キャッシュされた結果を使えば、新たな有料リクエストを避けられます。
ただし、キャッシュは重複削除の代わりにはなりません。まず不要な行を除外し、キャッシュは2段目の対策として活用します。
10. 出力トークンと同時実行数を制限する
4つの短いフィールドに適したmax-token値を設定します。ラベルと1文だけが必要なときに、長文を出力できる余地を残す必要はありません。
ご自身のAPIキーを使用する場合は、同時リクエスト数を控えめに設定してください。同時実行数を増やしてもFlexのキャパシティを予測できるようにはならず、rate limitエラーが増える可能性があります。再試行が続く一時的なバーストより、安定したバックグラウンド処理をおすすめします。
📘 Flexのトグルが表示されませんか?
まずモデルのラベルをご確認ください。Datablistでは、対応モデルとしてマークされた場合にのみFlex設定が表示されます。それ以外の場合は、別の対応モデルを選ぶか、Standardで実行してください。
プレビュー・実行・結果確認
ファイル全体を処理する前に、10〜20行をプレビューしてください。一見明確なプロンプトでも、この確認は欠かせません。わずかな表現の違いが、数千件のリクエストにおけるラベル、出力長、トークン使用量を変えることがあります。
プレビューでは、次の点を確認します。
- 期待するすべてのプロパティに値が入っている
Ticket Topicのラベルが一貫しているUrgencyがPriority Hintをそのままコピーせず、チケット本文も考慮している- 要約が1文に収まっている
Needs Reviewで情報の不足や矛盾を検出できている- 入出力の長さがコスト見積もりに近い
代表的な結果は次のようになります。
| Ticket Subject | Ticket Topic | Urgency | One Sentence Summary | Needs Review |
|---|---|---|---|---|
| パスワード再設定後にログインできない | Account Access | High | パスワードを再設定した後も、お客様がアカウントにアクセスできません。 | No |
モデルが一貫しないラベルを返す場合は、全件実行の前に許可する値を厳密に指定します。要約が長すぎる場合は、指示を短くしてmax tokensを減らしてください。10行の処理後にプロンプトを直すコストはわずかですが、100,000行の処理後ではそうはいきません。
プレビューが安定したら、対象行にenrichmentを実行します。Datablistは処理済みアイテムを記録するため、完了した行にOpenAIを再度呼び出すことを避けられます。
実行後は、failed、timed-out、no-resultのステータスを持つ行を絞り込みます。再試行する前に、各グループからサンプルを確認してください。
- 一時的なエラーと考えられ、待機できる場合はFlexで再試行する
- 有効な長い入力でタイムアウトが続き、待機できる場合はFlexのタイムアウトを延長する
- コストより完了や速度が重要な行は、Standard processingで再試行する
- リクエストに再度料金をかける前に、不足している入力データを修正する
結果のレビューが完了したら、処理済みのcollectionをCSVまたはExcelにエクスポートします。後工程で別の担当者が不確かなチケットを検証する場合は、Needs Reviewもエクスポートに含めてください。
コストをさらに削減する方法
Flexはコスト削減策の一つです。多くのファイルでは、送信データを減らし、不要なリクエストを避ける方が大きな効果を得られます。
処理前に行を絞り込む
空の行、分類済みのチケット、処理対象外のレコードを除外します。最も安いリクエストは、送信しないリクエストです。
プロンプトと入力を短くする
モデルが必要とするフィールドだけを含めます。Customer IDは後から結果を結合する際に役立つ場合がありますが、モデルが読み取る必要はありません。長い署名、引用されたメールスレッド、チケット内の定型文も同様です。
出力を短い構造化データにする
ラベル、boolean、簡潔な要約を使用してください。一般に出力トークンは入力トークンより高いため、小さなmax-token制限でも大きなコスト削減につながる可能性があります。
繰り返されるプロンプトをキャッシュする
同一のリクエストが繰り返される可能性がある場合は、キャッシュを有効にします。複数ファイルのインポート後に説明文やテキストが重複しているケースで効果的です。
品質要件を満たす最小モデルを選ぶ
モデルを変更する前に、同じ代表的な行をプレビューしてください。安価なモデルでも、ラベルの品質やレビュー対象の割合が許容範囲に収まらなければ、十分な効果は得られません。
定型処理には専用enrichmentを使う
LLMは柔軟ですが、常に最も安いツールとは限りません。必要なのが言語ラベルだけなら、汎用モデルに各行の言語を推測させる代わりに、言語検出専用のワークフローを使用してください。
コストを見積もるのは、プロンプトを短くし、データセットを絞り込んだ後です。そうしなければ、そもそも実行すべきでない処理の料金を計算することになります。
制約とトラブルシューティング
Flexには、あらかじめ想定しておくべきいくつかの失敗パターンがあります。
選択したモデルにFlexが表示されない
対応モデルは限られており、今後変更される可能性があります。DatablistにFlexのトグルが表示されない場合は、対応済みと表示されたモデルに切り替えるか、Standard processingをご利用ください。検証されていないcustom modelを大規模処理に無理に使用しないでください。
応答に予想以上の時間がかかる
処理が遅く、完了時間を予測しにくいことは、Flexの基本的なトレードオフです。出力品質が低いことを意味するわけではありません。緊急性の低い行はそのまま処理を続け、急ぎの処理はStandardに切り替えてください。
行がタイムアウトする
まずはDatablistのデフォルト値である360秒を使用します。有効な行がタイムアウトし、かつ処理時間が延びても問題ない場合は、対応範囲内でタイムアウトを増やしてください。失敗した重要な行が少数なら、処理全体を遅らせるより、その行だけStandardで再試行することをおすすめします。
OpenAI SDK自体のタイムアウトは、DatablistのFlex timeout設定とは別です。このワークフローでは、Datablistに表示される値に従ってください。
OpenAIから429 Resource Unavailableが返る
Flexのキャパシティを利用できないことがあります。OpenAIによると、この場合のリクエストには料金がかかりません。最低コストを優先する場合は後から再試行し、確実な完了を重視する場合はStandard processingをご利用ください。
多数の行でrate limitが発生する
Flexを使用してもAPIのrate limitはなくなりません。同時リクエスト数を減らすか、対象を小さなセグメントに分けて再試行してください。大量の失敗が一度に発生するより、低速でも制御された処理の方が確認しやすくなります。
Flex・Batch API・ChatGPTの違いが分からない
それぞれの役割をシンプルに整理すると、次のようになります。
- Flexは、対応するAPIリクエストを低コストで処理するservice tier
- Batch APIは、独立した非同期API
- ChatGPTはWeb・アプリ向けの製品であり、ここで使用する行単位のAPIワークフローとは別
- Datablistはスプレッドシート向けのワークフローを提供し、APIキーまたはcreditsを利用可能
まとめ
選択したモデルが対応しており、応答時間よりコストを重視し、バックグラウンドで処理できる場合はFlexを使用しましょう。緊急性が高い行、対話的な処理、失敗を許容しにくい行にはStandard processingが適しています。
おすすめの手順はシンプルです。トークンコストを見積もり、ファイルを絞り込み、短いstructured outputsを設定し、10〜20行をプレビューしてからFlexを有効にします。その後、リスト全体を処理し、必要な行だけ再試行します。CSVワークフローをシンプルに保ちながら、確認済みモデルの処理コストを半分にできます。
FAQ
OpenAI Flex Modeでは必ずコストを50%削減できますか?
いいえ。2026年7月16日時点では、gpt-5.4-miniのFlexにおける入力・出力料金はStandardより50%低く、Batch APIと同額でした。料金と対応モデルは変更される可能性があります。大規模処理の費用を計算する前に、対象モデルの最新料金をOpenAIの料金ページでご確認ください。
Flex Modeに対応しているOpenAIモデルは?
対応モデルは限られており、随時変更されます。OpenAIの最新料金表を確認し、Datablistのモデルセレクターでflex compatibleラベルを探してください。Flexのトグルは、対応モデルを選択した場合にのみ表示されます。
Flex ModeとOpenAI Batch APIは同じですか?
いいえ。Flexは、対応するResponsesまたはChat Completionsリクエスト向けのservice tierです。Batch APIは、送信されたバッチを処理する独立した非同期APIです。トークン料金が同じでも、ワークフローは異なります。
Flex Modeで出力品質は変わりますか?
Flexは異なる品質レベルを提供するものではありません。変わるのは、リクエストのprocessing tierと処理時間です。結果を左右するのは、引き続きモデル、プロンプト、出力スキーマです。tierにかかわらずプロンプトの品質は重要なため、必ずサンプル行をプレビューしてください。
DatablistのFlex Modeではタイムアウトを何秒に設定すべきですか?
まずはデフォルトの360秒で開始してください。有効な行がタイムアウトし、処理時間が長くなっても問題ない場合にのみ増やします。Datablistでは30〜1,500秒の値を設定できます。タイムアウトを長くするとリクエストの待機時間を延ばせますが、キャパシティは保証されません。
Datablist creditsでFlex Modeを使えますか?
Datablistでは、対応するモデルとアカウント設定に対して、OpenAI APIキーまたはDatablist creditsを利用できます。Credit使用量はモデルとトークン消費量によって異なるため、サンプルをプレビューし、入力と出力を簡潔に保ってください。
Standard processingを使うべきケースは?
対話的な作業、緊急のジョブ、担当者が結果を待っている行、Flex非対応モデル、応答の遅延が問題になる処理にはStandardを使用してください。大部分をFlexで処理し、重要な少数の行だけStandardで再試行することもできます。
ExcelファイルでもFlex Modeを使えますか?
はい。DatablistはCSVとExcelファイルをインポートできます。Flexが適用されるのは、対応するOpenAI APIリクエストであり、元ファイルの形式ではありません。どちらの形式でも、同じ行単位のプロンプトワークフローを使用できます。






