公開ベータ · 公式発表 2026-10-06

OPENAI / DECISIONS API

問い合わせの振り分けに、
長い回答はいらない

短い判断を返すAPI。振り分けのルールと確認は、アプリと人が持つ。

「どの窓口が担当するか」「人の確認が必要か」。OpenAIは、こうした分類や評価を専用の型で返すDecisions APIを公開した。窓口を実装する開発者と運用PMの視点で、既存APIとの使い分けと、試行で確かめることを整理する。[1]

掲載対象:2026-10-06号 公式発表:2026-10-06(時刻・TZ未記載) 仕様確認:2026-10-07
STATUS公開ベータ現時点の対応モデルは gpt-6-luna
OUTPUTpredicate / choice / score問いに合う型で判断を受け取る
OWNERSHIP実行と承認はアプリと人へ確率の意味と誤振り分けを評価する

ONE-PAGE BRIEF

問い合わせが届いてから、人が確認するまで

同じ問い合わせに複数の判断を問い、返った値をアプリのルールで扱う。下図は仕組みを説明する架空例です。

問い合わせの入力、3種類の判断、アプリと人の確認という流れ 架空の確認メールに関する問い合わせへ、predicateで条件の真の推定確率、choiceで担当候補、scoreで段階評価を問い、アプリがrefusalと振り分け条件を扱い、人が対応前に確認する。実測数値は示していない。 DECISION FLOW 短い判断から、振り分けを組み立てる 架空例 / 実測数値なし 01 問い合わせ 02 判断をまとめて質問 03 アプリのルール 架空の問い合わせ ログイン用の確認メールが届きません。設定の場所を教えてください。 predicate 条件が真か 真の推定確率を返す choice どの担当候補か 指定候補の選択と確率分布を返す score どの評価段階か 段階添字の確率加重平均を返す 担当者がルールを決める refusalを確認 振り分け条件を適用 人が対応前に確認 APIはツールを実行しない 判断の確率は、測定した正解率と別の指標。 返金や契約変更など、重大な処理は人が承認する。 問い合わせの振り分けを縦に読む説明図 架空の問い合わせを入力し、predicate、choice、scoreで判断する。アプリがrefusalを確認し、担当者のルールを適用する。重大な処理は人が承認する。図に実測数値はない。 DECISION FLOW 短い判断から、振り分けを組み立てる 01 問い合わせ / 架空例 実測数値は示していません ログイン用の確認メールが届きません。設定の場所を教えてください。 02 判断をまとめて質問 predicate 条件が真か 真の推定確率を返す choice どの担当候補か 指定候補の選択と確率分布を返す score どの評価段階か 段階添字の確率加重平均を返す 03 アプリのルール refusalを確認する 担当者の振り分け条件を適用 人が対応前に確認する 返金・契約変更は人が承認 判断の確率と、測定した正解率は別の指標。

図は想定用途の説明です。問い合わせの処理もAPIの実測も行っていません。

図の内容をテキストで読む
  1. 架空の問い合わせを共通の入力にする。
  2. predicateは条件が真である推定確率、choiceは指定候補の選択、scoreは順序を持つ段階の添字を確率で加重した平均を返す。
  3. アプリが質問ごとのrefusalと判断値を確認し、担当者が定めた振り分け条件を適用する。重大な処理は人が承認する。

仕様:[2] Decisionsガイド[3] APIリファレンス

WHO HAS THIS PROBLEM

問い合わせの窓口を実装する人と、運用する人へ

問い合わせの文章を読み、「担当部署」「緊急性」「追加調査の程度」を決める。窓口の実装には、こうした判断をアプリの分岐へつなぐ場面がある。

Decisions APIは共通の入力へ複数の質問を渡し、質問ごとに型の決まった回答を返す。担当候補や評価段階をあらかじめ定義できる処理が、試す用途になる。[2]

窓口の開発者
候補の定義、回答型の処理、refusal時の保留や人への引き継ぎを実装する。
運用PM
正しい担当と見逃してはいけない条件を定義し、誤振り分けと人の確認負担を評価する。

CHOOSING THE API

既存APIでもJSONは返せる。今回は判断の型に注目する

Responses APIのStructured Outputsでも、指定したJSON Schemaに沿う出力を扱える。分類をJSONで返すこと自体には、既存の選択肢がある。[4]

Decisions APIでは、predicate、choice、scoreという判断の型を選ぶ。自由な説明文や独自の出力構造も必要なら、ResponsesとStructured Outputsを含む既存APIを検討する。[2]

必要な出力から選ぶ。製品間のAPI互換性や品質の優劣を示す表ではありません。
必要なこと選択肢確かめる点
条件・候補・段階を判断するDecisions API型の意味、候補と段階の定義、拒否時の処理
説明文や独自構造も扱うResponses API / Structured Outputs必要な説明、JSON Schema、アプリ側の検証
判断専用の先例を調べるJev / Clefそれぞれの仕様、条件、同じ評価データでの結果

出典:[2] Decisions[4] Structured Outputs[5] Jev[6] Clef

AN EDITORIAL TEST PLAN

まずは、同じ問い合わせで誤振り分けと確認負担を比べる

以下は編集側の試行提案です。実施時には、利用範囲を確認したうえで匿名化し、正解ラベルを付けた過去の問い合わせを用いる。本号に載せる入力例はすべて架空で、実チケットや医療個人情報を使用していません。

  1. 正解と保留条件を先に決める

    運用担当者が担当窓口と見逃してはいけない条件を定義する。「その他」や情報不足も含め、候補から無理に担当を選ばせない。

  2. 既存方式と同じ条件で評価する

    入力、担当候補、評価対象をそろえる。Responses / Structured Outputsなどの既存方式と、処理時間と判断結果を比較する。

  3. refusalと迷う入力を人へ戻す

    質問単位の拒否を、該当質問の判断値として扱わない。確認が必要な条件と、担当者への引き継ぎ方法をアプリに持たせる。

  4. 重大な処理を人の承認に残す

    試行は振り分け案の確認から始める。返金、契約変更などの重要な実行は、判断値だけで自動承認しない。

誤振り分け正解の担当と異なる割合
見逃し要確認の条件を拾えない割合
p95待ち時間の95パーセンタイル
人の確認率保留や人への引き継ぎの割合
費用同じ対象件数で比較する

試行計画を作る依頼文

架空例で計画を検討するための依頼文です。実データやAPIキーを貼らずに使えます。

PRICE / SPEED / LIMITS

入力単価は低い。速度と判断品質は、用途で確かめる

公式の基本入力価格 / Decisions endpoint

US$0.10

100万入力トークンあたり

出力トークン、キャッシュ読み取り・書き込みの追加料金はない。地域処理の割増と長文入力の倍率は適用される。[2]

OpenAIによる速度の説明

Responsesとの比較で
約10倍の速度

OpenAIの公表値。比較条件の詳細は未確認で、このページの独立実測もない。実際の待ち時間は同じ入力でp95まで測る。[2]

公開状況・モデル
公開ベータ。2026-10-07の確認時点ではgpt-6-lunaのみ。専用エンドポイントはPOST /v1/decisions。[2]
入力
テキストとインライン画像。画像はdata URLで渡し、1リクエスト全体で最大128枚。外部画像URL、ファイル、音声、toolsは非対応。[3]
回答の意味
predicateは条件が真である推定確率。choiceは指定候補を選択。scoreは評価段階の添字の確率加重平均。確率を測定した正解率や、校正済みの保証とは呼ばない。[2]
拒否への対応
質問単位でrefusalが返ることがある。同じリクエストのほかの質問には回答が返り得る。アプリ側で回答型を確認する。[3]
SDKの版
OpenAI Python SDK 3.26.0以降、JavaScript SDK 7.30.0以降。ここで示すのはSDKの版で、PythonやJavaScriptの言語ランタイムの版ではない。[2]
比較の範囲
価格は/v1/decisions向け。ほかのgpt-6-lunaリクエストへこの価格を当てはめない。TeamsやAzureのネイティブ統合、製品間のAPI互換性は今回の確認範囲に含めない。

最初に比べたいのは、短い判断がどれだけ速く返るかと、
正しい担当へ渡すために、人がどれだけ確かめる必要があるか。

一枚で見る:問い合わせの振り分け

Escでも閉じられます。再び開くと、表示倍率とスクロール位置を初期状態に戻します。