OpenAI Decisions APIは何に向く？Responses APIと分ける分類・ルーティング

問い合わせを営業、請求、技術サポートへ振り分けたい。アップロード画像に破損があるか判定したい。障害報告を決めた基準で優先順位付けしたい。このように答えの範囲があらかじめ決まる処理へ、文章を自由生成するAPIを毎回使う必要があるのかは、AI機能の設計で見直したい点です。

OpenAIは2026年10月22日、Decisions APIの一般提供を発表しました。テキスト、画像、JSONを入力し、条件が真である確率、固定候補からの選択、段階的な評価のいずれかを型の決まった答えとして返すAPIです。利用するエンドポイントはPOST /v1/decisions、確認時点で対応モデルはgpt-6-lunaのみです。

本稿はOpenAI：Decisions APIの一般提供発表とOpenAI APIドキュメント：Decisionsを2026年10月24日に確認した開発者向けの導入解説です。APIを実行した速度・精度の独自測定ではありません。提供元の主張と、本サイトが提案する実装・評価手順を分けて説明します。

一般提供で何が変わったのか

OpenAIは、Decisions APIがResponses API経由のGPT-6 Lunaより最大10倍高速だと説明しています。ただし、これは提供元が示す比較であり、入力サイズ、同時実行数、地域、質問の種類が異なる実環境で同じ倍率になる保証ではありません。導入時には自社の入力とネットワーク条件で測定します。

パブリックベータ以降、JSON入力、質問ごとの画像、公開URLからの画像入力、会話履歴、プロンプトキャッシュ、組織単位の利用量取得、GPT-Liveとの連携が追加されました。一回のリクエストで扱える質問数は200から最大400へ増えています。一般提供という状態と、個別機能が自社のSDKや契約で利用できることは分け、利用中のSDKとAPIリファレンスで確認してください。

JSONはinput_jsonとして渡せますが、JSON内のroleやimage_urlというキーが会話や画像取得として解釈されるわけではなく、通常のデータとして評価されます。会話履歴ではメッセージに加え、関数呼び出しやカスタムツールの呼び出しと結果を順番に入力できます。一方、ファイル、音声、保存済みitemへの参照は確認したガイドでは未対応です。マルチモーダル対応という言葉だけで既存のResponses API入力をそのまま移せるとは判断せず、受け付けるcontent typeを照合します。

発表では、Boxが30件のCOI分類で同じ精度を保ちながら約5倍高速だったとする例も紹介されています。これは顧客による特定条件の結果で、一般的なベンチマークではありません。分類対象や正解データが違えば、速度と精度の関係も変わります。

predicate・choice・scoreを用途で分ける

predicateは、「返金要求を含むか」「画像に目視できる破損があるか」のような条件について、真である推定確率を0から1で返します。真偽値そのものではないため、0.5を機械的に合格線へするのではなく、誤って通す損失と誤って止める損失を比べて閾値を決めます。

choiceは、「営業」「請求」「技術」「要確認」のような順序のない候補から一つを選び、候補ごとの確率とconfidenceを返します。表示名をそのまま後続処理のキーにせず、変更しにくい識別子を用意すると、文言を変えたときの誤配送を避けやすくなります。「要確認」を候補に含めるか、人手へ戻す条件を別に持つかも業務要件として決めます。

scoreは、「外観上の問題」「回避策あり」「作業不能」のように順序を持つ段階を評価します。返るscoreはレベル番号の確率加重平均なので、1.1のように段階の間の値を取り得ます。これは文章で理由を生成する機能ではありません。監査や利用者説明が必要なら、根拠データと判定規則をアプリ側で保存し、説明文を別工程にする必要があります。

Responses APIと置き換える範囲を限定する

公式ドキュメントは、上記三種類の答えが必要な場合にDecisionsを使い、独自のJSON Schemaに沿った項目抽出や文章による説明が必要ならResponses APIのStructured Outputs、外部処理の呼び出しをモデルに選ばせるならfunction callingを使うと説明しています。

問い合わせ処理を例にすると、部署の選択はDecisions、氏名・注文番号・希望内容の抽出はStructured Outputs、チケット作成候補の提示はfunction callingに分けられます。実際にチケットを作るかは、認証・認可、値の検証、重複防止を通したアプリが決めます。型のある答えが返ることと、業務処理を自動実行してよいことは同じではありません。

既存の構造化出力とツール呼び出しを分ける設計では、データの形を整える段階と外部処理を実行する段階を扱いました。Decisionsは、その前後に置く「限られた候補から判断する段階」です。自由生成の処理をすべて移すのではなく、答えが列挙できる箇所だけを切り出すと責任を分けやすくなります。

最大400問は一括処理数ではなく共有入力への質問数

一つの入力に対して、破損の有無、製品カテゴリ、優先度など独立した質問を並べる場合、最大400問を同じquestions配列へ入れられます。同じ入力を繰り返し送る量を減らせる可能性がありますが、400件の問い合わせを一回で処理できるという意味ではありません。

前の答えを使って次の質問を変える処理は、公式資料でも別リクエストに分けるよう説明されています。まず破損を確認し、破損している場合だけ修理区分を選ぶ、といった依存関係です。独立していない質問を一括化すると、後続条件をアプリが追いにくくなります。

本番では質問ごとに固有のnameを付け、回答配列の順番だけに依存しない実装にします。期待したnameがない、拒否が返る、未知のanswer typeが現れる、許可した選択肢に対応できない場合は、後続処理を止めて記録します。タイムアウトや再試行で同じ作業を二重実行しない設計も必要です。

料金は入力とキャッシュ条件から試算する

確認時点で、/v1/decisionsの未キャッシュ入力は100万トークン当たり0.10ドルで、出力トークンへの課金はありません。キャッシュ読み取りと書き込みにはGPT-6 Lunaの標準プロンプトキャッシュ料金が適用されます。また、地域処理の割増と長いコンテキストの入力倍率が適用されるため、0.10ドルだけで全費用を固定しないでください。

共有inputの一致する先頭部分はプロンプトキャッシュの対象になります。再利用する範囲は最低1,024トークンで、質問内容はこの閾値へ数えられません。参照資料をinputへ置き、質問だけを変える構成では効果を見込めますが、日時やリクエストIDを共有部分の先頭へ毎回入れると一致しにくくなります。

利用量APIではリクエスト数とトークン利用量を確認できます。複数の質問を一つにまとめても、num_model_requestsは一件として数えられます。料金試算では、リクエスト数だけでなく、総入力、キャッシュ読み取り、キャッシュ書き込み、長い入力、地域条件を分けて記録します。

精度は業務上の誤り別に評価する

問い合わせ分類なら、過去データから個人情報を除いた評価セットを作り、正解部署と「要確認にすべき条件」を付けます。部署ごとの再現率、誤配送先、保留率を確認し、全体の正解率だけで判断しません。請求相談を営業へ送る誤りと、一般質問を要確認へ戻す誤りでは、業務上の損失が違うためです。

predicateの閾値、choiceのconfidence、scoreの境界は、ラベル付きの自社データで決めます。確率やconfidenceを、そのまま現実の正解率として扱わないでください。入力の種類や運用ルールが変われば分布も変わるため、モデルや質問文を更新したときは同じ評価セットで回帰を確認します。

評価セットの作り方と変更前後の比較は、既存のAIの評価データと回帰テストの始め方で詳しく解説しています。Decisionsでは、回答の型が限定される分、分類ごとの混同行列や閾値別の結果を自動集計しやすくなります。

本番導入前に確認する6項目

1. 答えの範囲：結果をpredicate、choice、scoreのどれかで表現できるか。説明文や複数項目の抽出が主目的ならResponses APIを検討します。
2. 候補と段階：choiceの候補が重ならず、scoreの隣接レベルを観察可能な基準で区別できるか確認します。
3. 保留条件：低いconfidence、拒否、未知の値、タイムアウト時に人手へ戻す経路を用意します。
4. 評価：誤検知と見逃しの損失を分け、用途別の閾値を固定した検証データで決めます。
5. 費用と速度：平均だけでなく上位の待ち時間、キャッシュ命中率、入力トークン、失敗率を同時に測ります。
6. データ条件：ZDRとHIPAAは対象顧客の条件付きです。データレジデンシーは対応API地域、地域処理は米国と欧州に対応するとされます。契約、保存、地域、入力内容を自社要件と照合します。

Decisions APIの価値は、生成AIを使う範囲を広げることだけではありません。自由な文章が不要な判断を限定された出力へ分け、後続処理を通常のアプリケーションコードへ戻せる点にあります。まず一つの分類や判定へ限定し、現在のResponses API構成と同じ評価データ、同じ負荷条件で比較してから移行範囲を広げるのが現実的です。

参考資料

• OpenAI：Introducing the Decisions API（2026年10月22日）
• OpenAI APIドキュメント：Decisions
• OpenAI APIドキュメント：料金
• OpenAI APIドキュメント：データ管理

情報確認日：2026年10月24日。本文の実装判断、導入順序、評価方法は本サイトの提案です。本文と概念イラストの作成に生成AIを使用し、一次資料との照合と保存内容のレビューを行っています。