Decisions API は 2026 年 10 月 6 日、OpenAI の発表によりパブリックベータに入った。9 月 29 日の DevDay では限定プレビューだった新しいインターフェースが、すべての開発者に開かれ、公式ドキュメントとデバッグ用 Playground も同日に公開された。一般提供は今後数週間以内とされる。やることは絞られている。文章は生成しない。問いに答えるだけであり、しかも開発者が与えた答えの中から選ぶだけだ。
3 つの設問タイプ：判断、選択、採点
Decisions のリクエストは、モデル、証拠となる入力（テキスト、画像、または混在）、そして設問の組という 3 部分で構成される。現在利用できるモデルは gpt-6-luna のみで、呼び出しは専用の /v1/decisions エンドポイントを使う。設問は 3 種類ある。predicate（判断）は条件が成り立つ確率（0〜1）を返す。例えば写真の製品に目に見える破損があるかどうか。choice（選択）は開発者が用意した固定の選択肢から 1 つを選び、各選択肢の確率分布も返すもので、部門や分類のような順序のない集合に向く。score（採点）は問題の深刻度のような順序ある等級を相手に、確率で重み付けした平均スコアを返し、等級と等級の間の値にもなりうる。
OpenAI の示す速度は、同種の判断が Responses API 経由より約 10 倍速いというものだ。理由は単純で、対話型インターフェースは回答を一語ずつ生成し、アプリ側がテキストを構造へ戻す解釈まで担うのに対し、Decisions は確率と選択を直接返すため、生成と解釈の両方を省ける。公式の用途は、コンテンツ分類、リクエストの振り分け、作業の優先順位付け、そしてエージェントの次の一手の決定だ。
構造化出力とは別物
Responses API 既存の構造化出力や関数呼び出しと混同しやすい。OpenAI はドキュメントで境界を明示している。独自の JSON スキーマでフィールドを抽出したり説明文を生成したりするなら構造化出力、引数を伴うツール呼び出しをモデルに起こさせるなら関数呼び出し、プログラムの分岐を直接駆動できる判断・選択・スコアだけが必要なら Decisions、という使い分けだ。つまり、アプリ内で最も頻繁で最も「文才」を必要としない種類の呼び出しを切り分け、生成能力と引き換えに遅延と決定性を得ている。
意思決定モデルが独立した品目になりつつある
タイミングも注目に値する。OpenAI がベータを発表したまさに同じ日、Perplexity は自社の Decision API の価格を半額にした。数時間以内の応酬は、「判断だけをするモデル」がニッチな試みから正面の戦場へ移ったことを示している。その数週間前には、TypeSafe のようなスタートアップが判断専用モデルを先行して投入していた。背景はコストだ。本番システムの呼び出しの多くは、旗艦モデルに長文を書かせる必要がなく、チケットを正しいチームへ回し、コンテンツに正しいタグを付け、エージェントの最初の一歩を決めるだけでよい。こうした呼び出しは大量で、遅延に敏感で、答えの空間が限られるため、小さなモデルと専用インターフェースの組み合わせに向く。本サイトでは以前、GPT-6 ファミリー3 階層の価格と役割分担を整理した。Decisions が採用する Luna はファミリーで最も軽く最も安い階層であり、それを「対話モデル」から「判断エンジン」へ作り替えるのは、この製品ラインの自然な延長だ。
開発者にとって移行コストは低い。既存の分類・振り分けロジックがあるシステムなら、実トラフィックで遅延と精度を比べてから採用を決められる。注意すべき空白は、専用料金がまだ公表されていないこと、現時点でモデルが Luna のみであること、そして確率出力の較正品質は自社の業務データで検証しなければならないことだ。OpenAI が提供するのはインターフェースであり、判断が正しいかどうかは自社のチケットとコンテンツで証明する必要がある。
