［開発者向け］OpenAIのDecisions APIが一般提供開始、分類や振り分けを高速・低コストに判定

2026-10-252026-10-27

はじめに

　OpenAIは2026年10月22日、Decisions APIの一般提供を発表しました。分類や振り分けなど、答えの範囲が決まった判定に特化したAPIです。本稿では、回答タイプや料金、GPT-Liveとの連携、導入企業の事例をもとに、使いどころと導入時の注意点を解説します。

参考記事

タイトル: Build more responsive apps with the Decisions API
著者: 記載なし
発行元: OpenAI
発行日: 2026年10月22日
URL: https://openai.com/index/decisions-api

要点

OpenAIはGPT-6 Lunaを基盤とするDecisions APIを一般提供した。Responses API経由のGPT-6 Lunaより最大10倍高速に判定できるとしている。
回答タイプはpredicate（確率）、choice（選択肢）、score（段階評価）の3種類である。
公開ベータ以降、GPT-Live連携、プロンプトキャッシュ、米国・EUでの推論レジデンシー、JSON入力、1リクエスト最大400問などが加わった。
料金は入力100万トークンあたり0.10ドル、キャッシュ入力は0.01ドルで、出力トークンには課金されない。
Box、Datadog、Ramp、Sierra、Speakの5社が、速度やコストの改善を報告している。

詳細解説

Decisions APIとは何か

　OpenAIによると、アプリやエージェントはワークフローの中で小さな判断を何度も行います。入力の分類、リクエストの振り分け、次に取る行動の選択などです。一つひとつは単純でも、規模が大きくなると遅延とコストが積み重なります。

　Decisions APIは、こうした「答えの範囲が限られた問い」に特化したAPIです。基盤はGPT-6 Lunaで、テキスト・画像・構造化データからほぼリアルタイムに判定を返します。Responses API経由でGPT-6 Lunaを使う場合と比べ、最大10倍高速だとOpenAIは説明しています。

　LLM（大規模言語モデル）で分類を行う場合、文章を生成させてから答えを取り出す方法がよく使われてきたと思います。Decisions APIは、決められた選択肢や確率を直接返す設計です。後段の処理で出力を解釈し直す手間は減ると考えられます。なお「最大10倍」は上限値と読むのが自然で、実際の効果は入力の長さや問いの数で変わると思います。

一般提供に合わせて追加された機能

　Decisions APIは公開ベータを経て、今回一般提供となりました。ベータ以降に追加・改善された主な点は次のとおりです。

GPT-Liveとのネイティブ連携: 音声会話の最中に判定を行える
プロンプトキャッシュ: 繰り返し使う文脈をキャッシュできる
推論レジデンシー: 米国とEUで推論処理を行える
ネイティブJSON入力: 構造化データをそのまま渡せる
指示への画像添付: 問いの指示文に画像を含められる
1リクエスト最大400問: 従来の上限の2倍に拡大
レイテンシの改善: アジアの複数地域で処理能力を追加

　1リクエストで多くの問いを扱えると、1つの入力を複数の観点でまとめて判定しやすくなると考えられます。たとえば問い合わせ1件について、カテゴリ・緊急度・感情を同時に判定する使い方です。ただし、問いの数と応答時間の関係は元記事に示されていません。実際の構成で計測するのがよいと思います。

　アジアでの処理能力の追加は、日本から使う際の応答速度に関係する可能性があります。一方、処理地域を指定できるのは米国とEUで、日本国内での処理には触れられていません。本稿としては、速度の話とデータの処理地域の話は分けて整理しておくのが安全だと考えています。

3つの回答タイプと使い分け

　OpenAIによると、使い方はシンプルです。開発者は問いと、許される答えを定義します。そのうえで、テキスト・画像・ネイティブJSONで文脈を渡します。APIは確率・選択肢・スコアのいずれかを返し、アプリはその結果で次の処理を決めます。

タイプ	用途	主な結果
predicate	条件が真である確率を推定する（例: 商品に目に見える傷があるか）	probability: 条件が真である確率を0〜1で推定した値
choice	事前に定義した選択肢から1つ選ぶ（例: エージェントが続行・再試行・確認質問のどれを行うか）	choice: 指定した値のいずれか。確率と信頼度も返る
score	段階的な評価基準（ルーブリック）に沿って入力を評価する（例: 損傷の深刻度）	score: 各段階のインデックスを確率で重み付けした平均値

　predicateは「はい／いいえ」の判定を確率で受け取れるのが特徴です。一定以上なら自動処理、それ未満なら人の確認に回すといった、しきい値の設計がしやすいと考えられます。choiceも確率と信頼度を返すため、同じ考え方を当てはめられると思います。

　scoreは各段階のインデックスの加重平均なので、段階と段階の間の値が返ることがあると読めます。どの値で区切って扱うかは、アプリ側で決めておく必要があると考えられます。

導入企業の活用例と公表された数値

　OpenAI社内では、プロダクトや業務の複数のワークフローで使われています。

dotsチーム: 応答時間の短縮と対話性の向上
Personal Financeチーム: 取引明細の説明文の分類
Communicationsチーム: 報道をテーマ別に分類し、主要なメッセージを補強するか揺るがすかを採点。詳しく確認すべき記事の特定に活用

　顧客企業の事例も紹介されています。数値は各社が自社の条件で評価した結果です。

Box: Box Extractと組み合わせ、業務文書を分類して次の工程へ振り分けています。保険証明書30件の評価では、経路選択がResponses APIの約5倍速く、精度は同等でした。確信度の低いケースは担当者に回しています。
Datadog: エージェントが生成したrshellコマンドを、実行前にリスク評価しています。障害の自動修復に使い、利用可能なフロンティアモデル比でp95が40倍速く、精度は同程度でした。
Ramp: AIのコストを実際の業務に紐づける処理に使っています。GPT-6 Lunaと比べ、精度を落とさずに4倍高速、30%安価になりました。
Sierra: 顧客との会話中、オーケストレーションの一部で次の行動を選んでいます。p95は280ミリ秒未満で、従来手法より約3倍速く、1回あたりのコストは90%低いとしています。顧客対応の成果は落ちていません。
Speak: GPT-Live連携のテストで、次の行動までの時間が1.4秒から0.13秒に縮みました。90%以上の短縮で、語学学習の対話性が高まったとしています。

　p95は、全リクエストの95%がその時間内に収まることを示す指標です。遅い側のばらつきを反映するため、リアルタイム処理の評価でよく使われます。

　これらは各社のコメントとして示された数値で、比較対象も条件も異なります。Boxの評価は30件と小規模です。本稿としては、自社でも同じ改善が得られるとは限らず、実データでの検証が前提だと考えています。それでも、分類・振り分け・リスク判定・次の行動の選択という用途の幅は、使いどころを考える手がかりになると思います。

GPT-Liveとの連携でリアルタイム音声に組み込む

　GPT-Liveは、自然で表現豊かな会話を音声アプリに組み込むためのモデルです。OpenAIによると、割り込みにも滑らかに対応し、会話の流れを保てます。Decisions APIはこのGPT-Liveとネイティブに連携し、会話の最中に素早く判定できるようになりました。

　元記事では次の使い方が挙げられています。

カスタマーサポートのエージェントが、確認の質問・振り分け・エスカレーションのどれを行うか判断する
アバターがユーザーの発話に合わせて表情を変え、ウインクや笑顔で反応する

　以下は、発話の文字起こしの更新に応じてアバターの表情を選ぶ設定例です。既存のGPT-Liveセッションの`session.triggers`に追加して使います。元記事のサンプルをそのまま掲載しており、本稿では実行確認をしていません。元記事のコード表示に含まれていた行番号は除いています。

{
  "type": "decisions",
  "event_type": "session.input_transcript.delta",
  "decisions": {
    "questions": [{
      "type": "choice",
      "name": "reaction",
      "instructions": "Choose an appropriate reaction for the avatar based on the user's latest message.",
      "choices": [
        { "value": "neutral" },
        { "value": "happy" },
        { "value": "sad" },
        { "value": "concerned" }
      ]
    }]
  }
}

　主な項目は次のとおりです。

`type`: トリガーの種類。ここでは`”decisions”`を指定している
`event_type`: 判定を起動するイベント。`session.input_transcript.delta`は、ユーザー発話の文字起こしの更新を指すと考えられる
`questions`: 判定する問いの配列。ここではchoiceタイプの問いを1つ定義している
`name`: 問いの名前。結果を読み取る際のキーになる
`instructions`: 判定の指示文。ここでは「ユーザーの最新の発言に合うアバターの反応を選ぶ」と指示している
`choices`: 選べる値の一覧。neutral・happy・sad・concernedの4つ

　判定が終わると、GPT-Liveが`decision.event`を発行します。アプリは選ばれた`reaction`を読み取り、キャラクターを動かします。音声との接続方法の詳細は、元記事からリンクされた開発者ガイドを参照してください。

　文字起こしの更新ごとに判定が走るため、発話中に何度も判定が行われる可能性があります。料金が入力トークン量で決まる点を考えると、渡す文脈の長さとキャッシュの使い方が運用コストを左右すると考えられます。