OpenAIは9月29日（米国時間）、開発者があらかじめ設定した質問と複数の回答候補から、適切なものを選ぶ「Decisions API」を発表し、限定プレビューとして提供を開始した。GPT-6 Lunaを使い、コンテンツの分類やリクエストの振り分け、AIエージェントが次に取る行動の選択などに利用できる。
生成AIの出力を決められた形式や選択肢に限定する仕組みは、これまでも存在した。今回OpenAIが打ち出したのは、アプリや業務システムの途中で繰り返し発生する「判断」を、低遅延で処理するための専用APIである。
判断が速くなれば、AIをソフトウェアの分岐処理に組み込みやすくなる。ただし、速く選べることと、その判断を安心して自動処理に任せられることは別だ。実際の業務で使うには、速度だけでなく判断の正確さや信頼性をどう確かめるかが重要になる。
既存のStructured Outputsと何が違うのか
OpenAI Developersの発表によると、開発者は質問と回答候補を設定し、アプリにリアルタイムの判断機能を組み込める。
たとえば問い合わせの振り分けなら、「配送」「返金」「アカウント」「要確認」といった候補を用意し、問い合わせ本文を読ませて適切な処理先を選ばせる使い方が考えられる。これは仕組みを説明するための例であり、OpenAIが発表した実際の導入事例ではない。振り分け後の転送や返信は、通常のプログラムや別の生成モデルに任せられる。
もっとも、決められた候補の中から回答させる仕組み自体はOpenAIにも以前から存在する。
Structured Outputsは、モデルの出力をJSON Schemaで定義した形式に従わせる機能だ。必須項目を指定したり、値をあらかじめ列挙した候補だけに制限したりできる。
つまり、「この問い合わせが返金なのか配送なのかを、決まった形式で返す」といった処理は、既存の生成APIでも実装できる。
では、Decisions APIは既存機能とどう違うのか。公開資料で示されている用途を整理すると、次のようになる。
| 方式 | 開発者が設定するもの | 公開資料が示す主な役割 |
|---|---|---|
| Structured Outputs | 生成内容の指示とJSON Schema | モデルの出力を指定した形式に従わせる |
| Decisions API | 質問と回答候補 | 内容を分類し、処理先や次の行動を選ぶ |
| Moderation API | 判定対象となるテキストや画像 | OpenAIが定めたカテゴリについて判定とスコアを返す |
公開資料の役割で分けると、Structured Outputsは主に出力形式を制約する仕組み、Decisions APIは開発者が設定した質問と候補から判断する仕組み、Moderation APIはOpenAIがあらかじめ定めたカテゴリについて判定する仕組みと整理できる。
この表は2026年9月30日時点で確認できる公開資料を基に、各機能の役割を整理したものであり、同じ条件で性能を比較したものではない。
Structured Outputsでも候補を限定した分類処理はできる。そのため、Decisions APIによって「分類」という能力が初めて追加されたわけではない。
新しいのは、質問と回答候補を与えて判断させる処理を、低遅延で繰り返し呼び出せる独立したAPIとして提供する点にある。
一方、Moderation APIは以前から、長い文章を生成するのではなく、入力に対する判定結果を返す用途に使われてきた。今回のDecisions APIは、こうした「判定だけを返す」仕組みを、開発者自身が設定するさまざまな業務上の判断へ広げたものと捉えられる。
150ミリ秒という数字をどう読むか
OpenAIのTibo氏（@thsottiaux）は、Decisions APIが画像入力にも対応し、入力から判断結果を得るまでの処理を数百ミリ秒未満に抑えるよう最適化されていると説明した。
文章だけでなく、文書や画面の画像も判断材料にできるため、用途はテキストの振り分けに限られない。ただし、画像のサイズや内容によって性能がどの程度変わるかは、この投稿では示されていない。
より具体的な数字を報じたのが、OpenAI広報にも取材したThe New Stackだ。
同媒体はOpenAIの説明として、Decisions APIが約150ミリ秒で結果を返すのに対し、GPT-6 Lunaを通常の方法で利用した場合は約1.6秒かかると伝えている。
単位をそろえると、
1,600ミリ秒 ÷ 150ミリ秒 ≒ 10.7
となるため、単純計算では約10倍速いことになる。
ただし、これはOpenAIの説明を基にした報道値であり、第三者が同じ条件で測定したベンチマークではない。
比較条件についても不明な点が残る。入力の長さ、回答候補の数、画像を含めた場合かどうか、通信する地域、同時アクセス時の負荷などは明らかになっていない。通常のLuna側でどの推論設定を使ったのか、150ミリ秒や1.6秒が平均値なのか中央値なのかも分からない。
したがって、「どのような入力でも150ミリ秒で結果が返る」と解釈したり、日本から利用した場合も同じ応答時間になると考えたりすることはできない。
それでも、処理の分岐を決めるまでの時間が短くなれば、その後に続く検索やツール実行を早く開始できる。
たとえば、問い合わせを読んで担当部署を選ぶだけの処理で長い文章生成を待つ必要がなくなれば、最終的に利用者へ回答するまでの時間を短縮できる可能性がある。
ただし、データベースへのアクセスや、振り分け先で実行する処理の時間は別にかかる。Decisions API単体の応答速度と、アプリ全体の処理時間は分けて評価する必要がある。
Jevが先行した「文章を生成しないAI」
TypeSafe AIは9月15日、判断処理に特化したモデル「Jev」を早期アクセスとして発表した。
同社によると、Jevは文章を生成するのではなく、プログラムがそのまま扱える型付きの判断結果と、確信度を示す確率を返す。
長い説明文を生成させるのではなく、ソフトウェアがそのまま条件分岐に利用できる結果を返すという設計思想は、Decisions APIが狙う用途と重なる。
ただし、内部の技術まで同じだと判断できる情報はない。
TypeSafeはJevについて、新しいモデル構造や並列サンプリングに加え、判断時に返す確率の校正を目的とした強化学習手法「RLCD」を採用していると説明している。
一方、OpenAIが今回のDecisions APIについて明らかにしているのは、GPT-6 Lunaを利用するという点までである。Jevと同じ訓練方式や並列処理を採用していると推測できる根拠はない。
Jevの公称応答時間は70～500ミリ秒だが、TypeSafeは公開している評価の多くを、米国西海岸のノートPCから実施したと記している。
また、並列サンプリングの効果を示す比較デモでは、短く情報密度の高い入力を使っており、この条件がJevに有利であることも同社自身が説明している。
一方、ワークフロー評価ではGPT-6 AstraとFable 5.1による予測の平均を参照値としている。人間が正解ラベルを付け、それに対する正答率を測った評価とは性質が異なる。
こうした異なる条件の数字とOpenAI側の公称値を直接比べ、両社の速度や判断精度に順位を付けることはできない。
それでも、両社が狙う方向には共通点がある。生成AIの用途が、自由な文章を返す対話だけでなく、ソフトウェアの中で何度も呼び出される小さな判断処理へ広がっているということだ。
ただし、その判断をどこまで自動化できるかは、速度だけでは決まらない。
実務で問われるのは、速さより「正しく選べるか」
OpenAI自身も、Structured Outputsについて、形式が正しくても内容そのものが誤っている可能性は残ると明記している。
指定した形式で答えることと、正しい候補を選ぶことは別の問題である。
たとえば問い合わせを「配送」と「返金」のどちらかに分類するとする。出力形式が常に正しくても、返金を求める文章を「配送」と判断すれば、その後の業務処理は誤った方向へ進んでしまう。
The New Stackは、Decisions APIが判断結果とともに確信度を返すと説明している。
ただし、Decisions APIの詳しいレスポンス形式や、その確信度が実際の正答率とどの程度一致するかを検証した結果は、今回確認できた公開資料からは分からない。
ここで重要になるのが「確率校正」だ。
モデルが90%の確信度を示した判断を100件集めたとき、そのうちおよそ90件が実際に正しければ、確信度と正答率がよく対応していると考えられる。
これは確率校正を説明するための例であり、OpenAIやJevについて実際に測定された結果ではない。
仮に確信度が提供されるとしても、「90%だから自動処理する」といった基準をそのまま決めるのは適切ではない。
まず、自社で実際に扱う日本語の問い合わせや、分類が難しい境界事例を使って正答率を測る必要がある。そのうえで、どの程度の確信度なら自動処理へ進め、どの程度なら人間の確認に回すのかを決めることになる。
判断が難しいケースに備え、回答候補として「要確認」を用意する方法も考えられる。
速度についても平均値だけでは十分ではない。典型的な応答時間に加え、処理が大きく遅れるケースがどの程度発生するのかを確認すれば、実際の利用者が感じる待ち時間をより正確に評価できる。
一般提供について、The New Stackは今後数日以内に対象を広げる予定だと報じ、OpenAI広報もその際に詳しい情報を公表する方針だと伝えている。
専用の料金体系、回答候補数の上限、自社データを使った調整が可能かどうかなどは、現時点で確認できる資料では明らかになっていない。
GPT-6 Lunaを利用するという説明だけから、通常のLuna APIと同じ料金になると判断することもできない。
一般提供が始まった後に比較するのであれば、同じ入力と同じ回答候補を使って正答率を測り、モデルが返す確信度と実際の正答率がどの程度一致するかを確認する。そのうえで、応答時間と料金を比較する必要がある。
こうした条件がそろえば、開発者は、多少の誤りを許容できる判断と、人間による確認が必要な判断を分けられる。
Decisions APIの価値は、単にAIの回答を速くすることではない。問い合わせの振り分けやAIエージェントの次の行動選択といった小さな判断を、ソフトウェアの中で低遅延に繰り返し実行できる点にある。
実用性を決めるのは、その速さに加えて、どれだけ正しく選べるか、そして間違えたときに安全に処理を止められるかである。