OpenAI が Decisions API を public beta で公開 — 分類・ルーティングを「型のついた答え」で10倍速く返す

要約

OpenAI が 2026-10-06 付の API changelog で、Decisions API を public beta として公開しました。専用エンドポイントは POST /v1/decisions です。

これは「生成しない API」です。 文章を作らせるのではなく、こちらが定義した質問に対して、型の決まった答えだけを返させるためのエンドポイントです。公式の表現は「Turn text and images into typed answers 10x faster than the Responses API」で、Responses API より約10倍速いことを打ち出しています。

なぜこれが必要になったかというと、分類やルーティングを生成 API でやるのが構造的に無駄だったからです。 「この問い合わせは返品・技術・課金のどれか」を判定させたいだけなのに、Chat Completions や Responses API を使うと、トークンを1つずつ生成する処理が走り、JSON の形を守らせるためのプロンプトとパースのコードが要り、それでも形が崩れることがあるという状態でした。Structured Outputs はこのうち形崩れを解決しましたが、生成という処理そのものは残っていました。

Decisions API は、そこを作り変えています。 リクエストは3つのフィールドだけです。model（評価に使うモデル）、input（質問が共有する根拠。テキスト文字列、またはテキストと画像を含む user メッセージ）、questions（評価したい内容の配列。各要素に type、name、instructions、型ごとのパラメータ）。1回のリクエストに複数の質問を入れられるので、同じ入力に対して「返品かどうか」「緊急度」「担当部署」をまとめて聞けます。

出力が3種類に型付けされている点が、設計上もっとも効きます。 Predicates は「その記述が真である確率」を probability（0〜1）で返します。公式例は商品写真に破損が写っているかの判定です。Choices は定義済みの選択肢から1つを選び、選んだ値だけでなく全選択肢の probabilities と confidence を返します。 Scores は順序のある水準（例: 1〜5）に対して評価し、水準インデックスの確率加重平均を score として返します。水準ごとの確率と confidence も付きます。

確率と confidence が返ることの意味は大きいです。 「カテゴリAと判定しました」だけが返る設計では、自信のない判定と自信のある判定を区別できません。 確率分布が返るなら、「confidence が 0.9 未満なら人間のキューへ回す」という分岐をモデルの外側で書けます。これは AI を業務フローに入れるときに、最初に決めなければならない設計です。

価格は 入力 $0.10 / 1M トークンで、出力課金とキャッシュ課金はありません。 地域プレミアムと long-context の乗数は適用されます。米国と欧州でのリージョン処理・データレジデンシーに対応します。

制約も明確です。 対応モデルは gpt-6-luna のみです。画像は base64 のインライン入力だけで、ホストされた HTTP / HTTPS の画像 URL と file_id 入力は使えません。 公式は「public beta であり、数週間のうちに GA を予定」と書いています。

何が変わったか

• POST /v1/decisions という専用エンドポイントが追加された（public beta、2026-10-06）
• 対応モデルは gpt-6-luna のみ
• リクエストは model / input / questions の3フィールド。1リクエストに複数の質問を入れられる
• 出力は3種類
  • Predicates: 記述が真である確率を probability（0〜1）で返す
  • Choices: 選択肢から1つ選び、全選択肢の probabilities と confidence を返す
  • Scores: 順序のある水準に対し、確率加重平均の score と水準ごとの確率、confidence を返す
• 公式の性能表現は「Responses API より約10倍速い」
• 価格は 入力 $0.10 / 1M トークン、出力課金なし、キャッシュ課金なし（地域プレミアムと long-context 乗数は適用）
• 米国・欧州のリージョン処理とデータレジデンシーに対応
• 入力画像は base64 インラインのみ。HTTP / HTTPS の画像 URL と file_id は非対応
• 公式は「数週間のうちに GA を予定」と記載

業務インパクト（一般企業向け）

まず確認すべきは、社内で動いている「生成 API に分類をさせている処理」です。

問い合わせの振り分け、申請書の種別判定、レビュー対象の抽出、ドキュメントのタグ付け——これらは生成ではなく判定です。 現状これを Chat Completions や Responses API でやっているなら、レイテンシとコストの両方が見直し対象になります。 「10倍速い」は公式の表現なので自社ワークロードでの実測が必要ですが、出力課金がない料金体系は、件数が多い処理では効き方が大きいです。

次に、confidence を使った運用設計です。 判定を AI に任せるときの最大の論点は、**「間違ったときにどう気づくか」**です。従来は「モデルの出力をそのまま信じる」か「全件を人が見る」の両極になりがちでした。確率と confidence が返るなら、中間を設計できます。 confidence が高い帯は自動処理、低い帯は人のキューへ、という二段構えです。この閾値をどこに置くかは業務側の判断なので、情報システム部門だけでは決められません。業務部門と合意して文書化してください。

運用で見落としやすいのが、閾値の見直しサイクルです。 モデルが更新されれば確率分布は変わります。「一度決めた閾値を放置する」のは、精度が落ちたことに気づかない設計です。 月次でサンプリングして、自動処理に流した判定の正解率を測る工程を入れてください。

ガバナンス面では、「判定を AI に任せている箇所」の棚卸しが必要です。 生成なら出力を読めば分かりますが、判定は裏で静かに動きます。 人事評価、与信、採否のような人に影響する判定を自動化していないかは、法務・コンプライアンス部門が把握しておくべき項目です。Decisions API のように判定が安く速くなると、気軽に使われて棚卸しから漏れるリスクが上がります。

調達の観点では、public beta である点に注意してください。 公式は数週間で GA と書いていますが、beta のうちは仕様変更とエンドポイント挙動の変更が起こり得ます。 本番の基幹処理に入れるなら、GA を待つか、フォールバック経路（従来の生成 API での判定）を残しておくのが現実的です。

副業・個人活用視点

単価の取れる使い方は「判定の自動化」です。

中小企業の現場には、人が目で見て振り分けている作業が大量に残っています。メールの一次振り分け、問い合わせフォームの内容分類、申込書の不備チェック、写真の良否判定。これらは生成 AI の派手な用途ではないので、提案されていないことが多いです。 そして件数が多いので、効果が数字で出ます。

提案資料で使える具体性が、今回の発表にはあります。 「AI で自動化できます」ではなく、「判定専用のエンドポイントが公式に用意されていて、入力 $0.10 / 1M トークン・出力課金なしです。月1万件なら概算でこれくらいです」と言える状態です。料金体系が単純な案件は、見積もりが通りやすいです。

confidence を使った段階導入は、受注の確度を上げます。 「全部 AI に任せます」は決裁が止まります。「まず confidence 0.9 以上だけ自動化して、残りは今まで通り人が見ます。3か月後に数字を見て範囲を広げます」なら通ります。最初から全置換を狙わないのが、この種の案件の勝ち筋です。 そして段階導入は、閾値の調整という継続的な仕事を自分の手元に残せます。

写真判定の案件は、制約を先に確認してください。 Decisions API の画像入力は base64 インラインのみで、URL と file_id は使えません。つまり画像をアップロードして URL で渡す設計は組めません。 ファイルサイズとリクエスト上限を踏まえた実装が必要で、ここを見積もりに入れておかないと工数が溢れます。

もう1つ、技術ブログや登壇のネタとして筋が良いです。 「Structured Outputs で JSON を固めた」の次の話として、**「そもそも生成させない選択肢が出てきた」**という整理は、まだ記事が少ない領域です。自分のワークロードで Responses API と比べたレイテンシとコストの実測値を出せれば、それだけで読まれる記事になります。公式の「10倍」を引用するだけの記事とは差が付きます。

関連リンク

• Decisions（OpenAI API Docs）
• OpenAI API Changelog（2026-10-06 エントリ）