OpenAIは、Containersの課金を分単位へ変更し、各セッションに最低5分の課金を適用した。以前はContainerセッションが20分単位で課金されていた。
対象にはResponses APIで利用するCode InterpreterやHosted Shellなどのコンテナ実行が含まれる。変更後は短時間処理の費用を抑えやすい一方、セッションを細かく作り過ぎる実装では最低課金が積み上がる。
何が変わったか
Containerは、モデルがコード実行、ファイル処理、シェル操作などを行う隔離実行環境である。料金はモデルのトークン料金とは別に発生する。
課金単位が20分から実利用時間ベースの分単位へ変わったが、1セッション当たり最低5分が適用される。30秒の処理を10セッション起動すれば、実行時間5分ではなく課金対象50分相当になり得る。
変更前後の差
| 項目 | 以前 | 変更後 |
|---|---|---|
| 課金単位 | セッション当たり20分 | 分単位 |
| 最低課金 | 20分相当 | 5分 |
| 短時間処理 | 割高になりやすい | 改善しやすい |
| セッション乱立 | 20分ずつ増加 | 5分ずつ増加 |
| 最適化焦点 | 起動回数削減 | 再利用、終了、アイドル、並列数 |
分課金は自動的な値下げではない。ワークロードの平均セッション時間と作り方で結果が変わる。
誰に影響するか
- PDF、CSV、Excel、画像などをCode Interpreterで処理する
- エージェントがHosted Shellでコマンドを実行する
- 一つのユーザー操作ごとに新しいContainerを作る
- 短時間ジョブを大量に並列実行する
- 失敗時にセッションごと再作成する
- 大きなContainerサイズを選んでいる
- モデルトークン費用だけを予算監視している
特に、デモ段階から本番へ移行し、同時利用者が増えたシステムは再計測が必要である。
必要な対応
費用を次の式で分解する。
総費用 =
モデル入力
+ モデル出力
+ キャッシュ
+ Containerサイズ単価 × max(実利用分, 5分) × セッション数
+ その他Tool料金平均だけでなくP95、失敗ジョブ、再試行、並列ピークを計測する。予算はユーザー数ではなく、セッション作成率と課金分数で管理する。
実装・移行手順
1. セッション生成箇所を特定する
ユーザー操作、会話、ジョブ、ファイル単位のどこでContainerを作成しているか確認する。SDKが暗黙に新規セッションを作る場合もある。
2. 利用パターンを分類する
- 1分未満の単発処理
- 5〜20分の分析
- 20分超の長時間処理
- 対話中に複数回コードを実行
- バッチで多数のファイルを処理
- 失敗率の高い不安定処理
分類ごとに再利用方針を変える。
3. セッション再利用を設計する
同じ利用者・同じ業務・同じデータ境界で複数の処理を行う場合、適切な範囲でContainerを再利用する。ただし、異なる顧客や権限間で共有しない。
4. 明示的な終了とTTLを設定する
処理完了後のアイドル状態を放置しない。終了APIやセッションTTLが利用できる場合は実装し、クライアント切断、例外、タイムアウトでも終了処理が走るようにする。
5. 並列上限を設ける
Queueを使い、ユーザー・テナント・Project単位で同時Container数を制限する。レスポンスを速くするために無制限並列を許可しない。
6. コストメタデータを記録する
Session ID、Containerサイズ、開始・終了、課金対象分、ジョブID、利用者、成功・失敗、再試行理由を保存する。入力ファイル内容は費用ログへ含めない。
失敗しやすい点
- 1リクエスト1Containerで最低5分課金を大量発生させる
- 不要な大型サイズを常時選ぶ
- 再試行のたびに新しいContainerを作る
- 処理終了後のアイドル時間を計測しない
- 成功ジョブ単価だけを見て失敗費用を除外する
一時的なモデル応答エラーと、Container自体の破損を区別する。すべての再試行で環境を作り直さない。
評価方法
- 1成功ジョブ当たりContainer課金分
- セッション当たり実利用時間と課金時間
- 最低5分に切り上げられた比率
- セッション再利用率
- アイドル時間率
- Containerサイズ別の成功率・処理時間・費用
- ユーザー・テナント別の同時実行ピーク
- 失敗・キャンセル・再試行による費用
- モデル費用とContainer費用の構成比
- 旧20分方式を基準にした差額
評価は同じ業務データと同じ品質条件で行う。単純に処理を短くして品質を落とさない。
ロールバック
新しい再利用設計でデータ混在や状態汚染が起きた場合は、再びジョブ単位の分離へ戻す。その際、最低5分課金増を一時的に受け入れ、安全性を優先する。
- 再利用Feature Flagを停止する
- 新規ジョブを専用Containerへ切り替える
- 既存共有セッションを終了する
- テナント間データ混在がないか監査する
- 費用上限とQueueを一時的に厳しくする
- 原因修正後、限定テナントで再開する
課金方式そのものを元へ戻すことはできないため、ロールバック対象はアプリケーションのセッション管理である。
編集部分析
20分固定から最低5分の分課金へ変わることで、短い分析や軽いShell処理の採用障壁は下がる。ただし、価格体系が細かくなるほど、アプリケーション設計の差が費用差として直接現れる。
最適化の中心は、単にセッション数を減らすことではない。データ分離、再現性、障害隔離を維持しながら、同じ作業単位の処理を適切にまとめることである。過度な再利用は、別ユーザーのファイルや変数が残る危険を生む。
FinOpsは請求後の集計だけでなく、Queue、並列制御、サイズ選択、終了処理を設計レビューへ含める必要がある。
実務チェックリスト
- [ ] Containerを作成する全コード経路を特定した
- [ ] 最低5分を含む費用式へ更新した
- [ ] セッションの開始・終了・アイドルを記録した
- [ ] 異なる顧客や権限間で再利用していない
- [ ] 適切なContainerサイズを実測で選んだ
- [ ] 同時実行数とユーザー別上限を設定した
- [ ] 失敗・キャンセル・再試行費用を計測した
- [ ] 予算超過時に新規セッションを抑制できる
- [ ] 再利用停止Feature Flagを用意した
- [ ] 旧方式との費用差を業務シナリオで比較した