【ITニュース解説】Half Price Until You Pay Twice: 6 Ways an OpenAI Batch Job in .NET Quietly Costs You More

OpenAIのバッチAPIは、大量のテキストデータなどをAIモデルに処理させる際に、非常にコスト効率が良いとされる機能だ。例えば、即座の応答を必要としない何万行ものデータを一晩で分類するような作業で、通常のAPIよりも半額で利用できるという点が大きな魅力だ。しかし、この「半額」という割引は、バッチ処理の実装方法に少しでもミスがあると、簡単に失われてしまう。最悪の場合、支払うコストが倍になったり、処理されるべきデータが静かに失われたりすることもある。バッチジョブは完了までに数時間かかることが多いため、その長い実行時間の間にシステムがクラッシュしたり、再試行が必要になったり、処理の期限が迫ったりといった様々な問題に直面する可能性がある。これらの状況に適切に対処するための考慮事項がいくつかある。

まず一つ目の間違いは、「システムクラッシュ後に同じバッチジョブを再度作成してしまうこと」だ。バッチファイルがアップロードされ、バッチ作成のAPIが呼び出された後、そのバッチのIDをデータベースに保存する前にシステムがクラッシュすることがある。システムが再起動すると、その処理がまだ行われていないと判断され、同じ内容のバッチを再度作成して送信してしまう可能性がある。結果として、二つのバッチが同じリクエストを同時に処理し、両方に対して課金されてしまう。これを防ぐには、バッチ作成時にジョブIDやシャードIDといった独自の識別子を「メタデータ」としてバッチに付与する。システムが再起動した際は、すぐに再送信するのではなく、まず進行中のバッチリストを確認し、そのメタデータに一致するものが無いかを探す。もし見つかれば、それはすでに進行中のバッチなので、それを「採用」して処理を継続し、見つからなければ新たに作成する。また、バッチの計画、ファイルのアップロード、バッチ作成といったAPI呼び出しの直前には、必ずその時点での状態を保存しておくことが重要だ。

二つ目の間違いは、「失敗したすべてを無条件に再試行すること」だ。バッチ処理が完了し、一部のリクエストが失敗として報告された場合、手軽な方法として、失敗したすべてを次のバッチで再試行しようとすることがある。しかし、中には何度再試行しても成功しない種類のエラーが存在する。例えば、リクエスト内容に問題があることを示す400番台のエラーや、AIモデルがコンテンツの生成を拒否した場合などは、同じリクエストを再送しても結果は変わらず、無駄な課金を招くだけだ。正しい対処法は、失敗の種類によって再試行の要否を判断することだ。一時的なネットワーク問題やシステムの一時的な負荷が原因で発生する可能性のあるエラー（例：タイムアウト、リクエスト過多、サーバーエラー、バッチの期限切れ、結果が返ってこなかった場合など）は再試行すべきだ。また、応答が途中で切り詰められた場合は、max_completion_tokensを増やして再試行すると良い。一方で、リクエスト内容の根本的な問題を示すエラーや、AIモデルによる拒否・コンテンツフィルターによる停止は、再試行すべきではない。さらに、各アイテムには再試行回数の上限（「試行予算」）を設定し、その回数を超えても成功しなかった場合は、それ以上再試行せず、「デッドレター」状態として記録することで、無限ループと無駄な課金を防ぐ。なお、途中で切り詰められたリクエストでも、使用されたトークンに対しては課金されるため、コスト報告時には各試行のトークン数を加算して正確な費用を把握することが大切だ。

三つ目の間違いは、「出力ファイルを基準にループ処理を行うこと」だ。OpenAIのバッチAPIでは、出力結果が入力時と同じ順序で返ってこないことがあるため、多くの開発者はcustom_idを使って入力と出力を紐付けている。しかし、さらに注意が必要なのは、出力結果のファイルだけを基準にして処理を進めてしまうことだ。この方法では、もし何らかの理由で全く結果が返ってこなかった入力アイテムがあった場合、それらが処理されずに見過ごされてしまう。例えば、バッチがキャンセルされたり、期限切れになったり、あるいは個々の結果が失われたりした場合に、ジョブは「完了」と報告されても、実際には一部のデータが未処理のまま残ってしまう可能性がある。この問題を避けるためには、自分が送信した入力データを基準にしてループ処理を行い、各入力項目に対して対応する出力結果が返ってきているかを一つずつ確認するべきだ。出力が見つからない場合は、それを「欠落」と判断し、適切な理由を付与して再試行するなどの対応を取る。また、バッチ処理で失敗したリクエストは、メインの出力ファイルとは別にエラーファイルに記録されるため、このエラーファイルも必ず確認する必要がある。

四つ目の間違いは、「再試行時に同じcustom_idを再利用すること」だ。あるリクエストアイテムが最初のバッチで失敗し、2番目のバッチで再試行されることになったとする。もしこの再試行時にcustom_idが前のバッチと同じままだと、最初のバッチから遅れて結果が返ってきた場合と、2番目のバッチから新しく返ってきた結果が区別できなくなり、古い結果が新しい結果を誤って上書きしてしまう可能性がある。これを解決するには、custom_idに「試行回数」を含めるのが有効だ。例えば、{ジョブID}:{アイテムID}:a{試行回数}のような形式でIDを生成する。これにより、遅れて返ってきた古い試行の結果は明確に区別でき、無視することができる。データベース側でも、更新を行う際は、そのアイテムがまだ該当する試行段階にあり、結果を待っている状態である場合にのみ更新を行うようにすることで、古い結果による上書きを防げる。

五つ目の間違いは、「JSONエンコーダーによって入力ファイルが肥大化すること」だ。OpenAIのバッチAPIの入力ファイルには、リクエスト数とファイルサイズの制限がある。デフォルトのJSONエンコーダーは、非ASCII文字（日本語やアラビア語など）を\uXXXX形式のエスケープシーケンスに変換する。英語のテキストでは問題ないが、非英語のテキストではこのエスケープ処理によってファイルサイズが大幅に膨らむことがある。ファイルサイズが早く制限に達すると、同じジョブでも多くのファイルとバッチに分割して処理する必要が生じ、管理が複雑化し、オーバーヘッドが増えてしまう。この問題を解決するには、JSONエンコーダーの設定を変更し、非ASCII文字をエスケープせずにUTF-8として出力するようにする。これによりファイルサイズが圧縮され、効率的に処理できるようになる。この設定変更は、改行などの制御文字は依然として適切にエスケープするため、JSONLの行が途中で分割される心配はない。さらに、ファイルをアップロードする前に、custom_idの一意性やファイルごとのモデルの一貫性、サイズ制限内であることなど、入力ファイルのローカルでの検証を行うことが非常に重要だ。ローカルでの検証であれば、もし間違いが見つかってもコストは一切かからない。

最後の六つ目の間違いは、「処理の締め切り時にパニックになること」だ。バッチAPIは通常24時間以内に完了すると約束されているが、レポート提出などの締め切りが迫っている状況で、バッチ処理がまだ完了していないという事態に直面することがある。ここでパニックに陥り、「残りのバッチをキャンセルして、すべてを通常のAPIで再実行しよう」とすると、大きな問題が起こる。既にバッチAPIで処理された分に対しても、通常のAPIで再度支払うことになり、さらにキャンセルされたバッチであっても、キャンセルまでに完了した分については課金されてしまうため、二重、三重のコストが発生する可能性がある。この状況を避けるには、事前に「締め切り計画」を立てておくことが重要だ。これは、バッチ処理の進捗を監視し、もし計画通りに進まない場合に、どの時点でバッチ処理の完了を諦め、残りの未処理部分だけを効率的に通常のAPIなどで処理に切り替えるかという判断基準と具体的な手順を含む。事前に計画を立てておくことで、予期せぬ事態でも冷静に対応し、無駄なコストを発生させずに済む。

これらの注意点を踏まえ、バッチ処理の実装時に適切な対策を講じることで、OpenAIバッチAPIのコストメリットを最大限に活かし、安定したデータ処理を実現できる。事前の計画と丁寧な実装が、成功への鍵となるだろう。