- 公開日
結果を待っても業務が止まらず、回収・確認と失敗分への対応を締切までに終えられる処理は、Batchや非同期処理の候補になります。利用者がその場で判断する窓口回答などは、必要な時間内に答える経路を確保します。料金が下がるかは、同じ品質と期限を満たした件数に対し、再処理や回収の手間まで含めて比べます。
非同期処理とは、依頼の受付と結果の受取りを時間的に分ける方式です。Batchは複数の依頼をまとめて処理する方式で、提供サービスによって実行枠や料金が異なります。非同期で受け付けられることだけでは、安価であることも、必要な時刻までに全件が揃うことも決まりません。
最初に決めるのは「何時までに、何が使える必要があるか」
比較する数値は、処理単価、受付から結果が使えるまでの時間、期限内の受理件数です。応答が返った後にも、出力の検査や業務システムへの取り込みが残ります。「受付完了」「生成完了」「確認を終えて利用可能」のどれを締切とするかで採用判断が変わります。
たとえば月次分類で翌営業日の集計会議までに結果があればよい場合は、会議時刻から、集計担当者の確認時間、取り込み時間、失敗分への対応時間を差し引きます。その残りが処理を待てる時間です。夜間に投入すればよいと先に決めると、朝に失敗へ気づいても間に合わない設計になりかねません。
処理期限とは別に、代替手段へ切り替える判断時刻を置くと、担当者が対応できる時間を確保しやすくなります。判断時刻に、未完了件数、手作業で処理できる量、残り時間を照合します。代替が使えないなら、早めに業務責任者へ期限の相談をします。提供者が定める最大の待ち時間いっぱいまで待つことと、業務上いつまで待てるかは別の判断です。
用途ごとに、次の条件を分けて記録します。
| 判断する条件 | 月次分類のような後続作業 | 利用者が待っている窓口回答 |
|---|---|---|
| 待ち時間の許容 | 確定した締切まで待てるか | 対話の途中で判断を止められるか |
| 結果の鮮度 | 対象月の確定版を使えるか | 回答時点の在庫や受付状態が必要か |
| 欠けた結果の扱い | 欠損表示や部分集計が許されるか | 個別回答を省略してよいか |
| 失敗時の代替 | 再処理・手作業の時間があるか | 有人窓口への移行や保留案内ができるか |
待てない業務にも、受付番号の発行だけは即時に行い、調査結果は後から知らせる設計があります。ただし、利用者が後日の回答を受け入れ、回答期限と確認方法が明示されていることが条件です。「受け付けました」を実際の回答の代わりに数えて、応答要件を達成した扱いにしてはいけません。
2026年10月25日に確認したOpenAIのBatch APIは、非同期向けの処理枠として24時間、同期APIに対する50％の割引、別のレート制限枠を説明しています。これは当該サービスの条件です。期限切れや個別失敗の扱いもあるため、24時間を全件成功や翌朝の業務完了の保証へ読み替えません。利用するモデル、対象API、地域、入力形式が対応するかも導入時に照合します。
架空の月次分類を、同じ入力で比較する
以下は実行していない架空例です。担当者は、個人情報を含まない合成の問い合わせ1,000件を「請求・操作・その他」に分類します。原文と照合できないものは要確認とし、分類結果を直接顧客へ送信しません。対象データ、分類定義、モデルと設定、出力形式、受理基準を固定し、通常のAPI経路とBatch経路だけを変えます。
受理条件は、全件に一意の業務IDがあり、指定分類と根拠箇所が揃い、担当者の照合を通り、10月12日12時までに台帳へ取り込めることとします。時刻はこの例では日本時間です。入力の確定は10月10日12時で、48時間の余裕があります。想定する処理枠に加え、結果の回収、確認、代替処理の時間を確保する設計です。この余裕で必ず足りると測定したわけではありません。
一方、窓口では「この申請を今日受け付けられるか」という問い合わせに、その対話中に回答する必要があると仮定します。こちらはBatchの完了を待つ経路から外し、現在の受付状態を照会して即時回答するか、確認できなければ有人担当へつなぎます。同じAIを使うという理由で、両業務を同じ待ち時間へ揃えません。
月次分類の試算条件は、1件当たり入力1,000トークン、出力200トークンです。トークンはモデルが文章等を扱う単位で、文字数とは一致しません。ここでは追加の推論やツール利用を含めず、この数量が各成功要求の課金量と一致すると仮定します。実運用では実際の使用量と課金対象を照合し、推定だけで確定費用にしません。
| 費用条件 | 通常API経路 | Batch経路 |
|---|---|---|
| 入力1,000トークン当たり | 2円 | 1円 |
| 出力1,000トークン当たり | 8円 | 4円 |
| 1件のAPI費用 | 3.6円 | 1.8円 |
| 1,000件が一度で完了する場合 | 3,600円 | 1,800円 |
金額はすべて仮定単価です。特定モデルの価格表や円換算した実見積ではありません。1件は入力1,000÷1,000×2＋出力200÷1,000×8＝3.6円で、Batch側も同じ式です。この計算だけなら差は1,800円ですが、結果が揃うまでの負担はまだ含まれていません。
比較期間は、この1,000件の受付から締切後の費用照合までとします。共通の分類ルール整備費は両方式から除き、税・為替・初期構築費・保存料金・重大障害による損失も含めません。実際の採用で差が生じる項目は追加し、見積もれていない費用をゼロと扱わないことが必要です。
受付IDと明細IDを分け、回収できた範囲を確かめる
一括依頼の受付IDと、各問い合わせの業務IDは役割が違います。受付IDではまとまり全体の状態を追い、明細ごとのIDでは入力と結果を結びます。両者に、入力の版、提出時刻、処理期限、結果の保存先、最後に照会した時刻を関連付けます。記録の名称は独自設計であり、どのAPIにも同じ項目があるとは限りません。
OpenAIのBatch APIの結果取得では、出力の順番が入力と同じとは限らず、custom_idで対応付けるよう説明されています。先頭行から順に元データへ貼り付ける方式では、別の問い合わせへ分類結果を付けるおそれがあります。サービスの識別子を業務IDへ対応させ、同じ結果を二度取り込んでも重複登録しない取り込み方法を設けます。
本例なら、受け付けた1,000個の業務IDの一覧を回収の基準にします。成功結果、確定失敗、処理中、結果不明のIDを分け、どこにもないIDや複数区分に入るIDがあれば調査します。件数の合計だけでは、重複した一件と欠けた一件が相殺されるため、集合として一致するかも確認します。分類結果があることと内容が受理基準を満たすことは別に判定します。
実行状態と回収状態も分けます。たとえば「生成完了・未回収」「回収済み・内容確認待ち」「内容確認済み・取込済み」を区別すれば、完了したのに担当者が結果を取得していない事故を見つけられます。全体の完了通知だけを見て、業務を完了に変更しない設計です。
回収担当を決め、予定時刻に通知が来ない場合にも受付IDで状態を照会します。通知だけに依存すると、通知の欠落と処理の失敗を区別できません。照会間隔、結果を保持する期限、回収後の削除条件は、提供者の仕様と業務要件を確認して決めます。結果保管先のアクセス制御や入力・出力の保持条件も、同期経路から変更した箇所を点検します。
遅延、部分失敗、回収漏れでは次の動作が違う
本例では、投入後24時間の照会時に980件の完了結果と、期限切れになった20件が判明したと仮定します。980件は回収して検査し、20件は元入力と状態を照合して代替処理を検討します。OpenAIのBatch expirationにも、期限内に終わらない要求がある場合と、完了分の結果取得・課金が記載されています。全体がexpiredでも、全件未実行とは扱えません。
| 観測した状態 | 最初に確かめること | この例での次の対応 |
|---|---|---|
| 処理中で予定より遅い | 残り時間と後工程、サービス側の状態 | 代替へ切り替える最終判断時刻を決めて照会を続ける |
| 個別の失敗が確定 | 失敗理由と入力、再試行可能な条件 | 入力修正や回数上限を決め、対象IDだけ再計画する |
| 完了だが結果が手元にない | 保存先・権限・取得処理の記録 | 結果を再取得する。生成要求の再送と混同しない |
| 応答も状態も確認できない | 受付記録と要求識別子、運用窓口 | 結果不明を保持し、重複実行のおそれがある再送を保留する |
締切が近いという理由で、元の処理がまだ動いている対象を別経路へ無条件に再送すると、二重の費用や登録が発生し得ます。取消が使える場合も、取消要求を送った段階と、取消が成立して遅れて実行されないことを確認した段階を分けます。取消できないなら、重複した結果の扱いと費用を許容する判断が必要です。
AWSのMaking retries safe with idempotent APIsは、応答がない場合でも処理の副作用が生じている可能性と、重複適用を避ける冪等性の契約を扱っています。要求IDがあるだけで再実行の安全性が決まるわけではありません。分類そのものが読取りでも、実行には費用がかかり、後続の台帳登録には更新が伴うため、生成と取込を別に確認します。
本例の20件は、元の要求が終端状態で再開しないことと、結果がないことを確認し、残り時間で通常API経路へ回す想定です。入力・出力と受理基準は維持します。20件を処理できるという見込みが立たなければ、残るIDを担当者へ渡し、締切変更または未完了を含む提出の可否を判断してもらいます。依頼側の同意なしに全件完了の要件を部分完了へ変更しません。
再処理と回収工数を加えると、費用の差をどう読めるか
先の仮定を続け、980件はBatchで一度ずつ課金され、20件は未実行で元の料金が発生せず、通常経路で一度ずつ処理して全件が期限内に受理されたとします。未実行分をゼロと置くのは、この計算例の確認済み条件という設定であり、実際の期限切れや失敗が常に無料という意味ではありません。
通常経路では1,000件が一度で完了し、確認・回収の作業に10分、Batch経路では部分失敗の照会と再処理の手配を含め30分を要すると仮定します。どちらも人の時間を1分40円で換算します。照合対象と品質基準は同じで、20分の差は照会や手配の追加作業として置いた想定です。
- 通常経路：API費用3,600円＋10分×40円＝4,000円
- Batch経路：980件×1.8円＋20件×3.6円＋30分×40円＝3,036円
- 期限内受理1件当たり：通常4.00円、Batch3.04円
最後の単価は1,000件で割り、小数第3位を四捨五入しています。この条件では差は964円です。APIの単価が半分という説明から、業務費用も半分になるとは結論できません。同じ式でBatch側の作業が60分になれば、合計は4,236円となり、通常経路を上回ります。
この仮定で費用が等しくなるBatch側の総作業時間は、（4,000円−1,836円）÷40円／分＝54.1分です。ただし、この境界はAPI使用量や失敗件数が固定の場合だけに使えます。失敗が増えて再処理費も上がるなら、作業時間だけで採否を決めず両方を更新します。初期構築費を除いているため、この数字から投資回収期間を導くこともできません。
受理できたのが980件までなら、期限内受理率は980÷1,000＝98％です。費用を比較する際は未受理20件への支出も分子に残し、受理できた件数を分母にします。ただし、全件が必須の業務なら98％は要件未達であり、安い単価で補えるものではありません。部分提出が許される場合も、未確認や期限後受理を期限内の成功へ混ぜません。
導入判断では、許可された合成データで、結果の並び替わり、一部失敗、通知欠落、取込の重複を想定して回収手順を確かめます。受付一覧と回収結果が一致しない、結果不明のまま再送する、失敗分を隠して完了表示するなら、その経路は採用を保留して修正します。ここで示した費用と時間は実測ではありません。実際の締切内受理率、再処理費、回収工数が揃った段階で、業務ごとの振り分けを見直します。
対象月の確定データを後から差し替えた場合は、以前の結果と新しい入力を混ぜないことも確認点です。入力版を変えた対象だけを特定し、再分類が必要かを判断します。返却が速くても古い入力への回答なら受理できないため、待ち時間の評価と同時に、締切時点で必要な鮮度を満たしているかを確かめます。
実行順序と時間・費用・回数の上限をまとめて決める基本は「AIエージェントの実行順序と時間・費用・回数の上限を決める」、エージェントの費用上限と予算の事前確保は「Agentの反復とツール呼び出しに費用上限を設ける方法」で解説しています。
