2026 年 10 月 6 日、OpenAI は Decisions API をパブリックベータとして全開発者に公開しました。専用エンドポイント POST /v1/decisions、公式ガイド、5 言語の SDK、Playground が揃い、API Changelog にも「Released the Decisions API in beta with gpt-6-luna」と載りました。
前回の記事（10 月 1 日）では、DevDay の発表文と報道だけを頼りに、確率の有無・料金・リクエスト形式を「未公表」とし、出力の型と提供状況は発表文からの推定で置きました。公式ドキュメントが出た今、その 6 項目がどう変わったか、前回の読みのどこが当たりどこが外れたかを、公式ガイドに沿って答え合わせします。情報の確認日は 2026 年 10 月 8 日です。本記事は公式ドキュメントの読解に基づいており、私たち自身の API 実測はまだ行っていません。
答え合わせ：前回の 6 項目はこう変わった
まず結論を 1 枚にまとめます。
図1：6 項目のうち、未公表だった 4 つは 3 つが公式ガイドで埋まり、1 つ（1 リクエストの上限）は依然未公表です。推定で置いた 2 つ（出力の型・提供状況）は公式値で更新されました。
前回の読みで最も大きく外れたのは出力の型です。公式説明の「あらかじめ定めた有限の回答候補」から、私は「候補からの単一選択の 1 種類」と置きました。実際には 3 つの質問型があり、確率分布と confidence も返ります。これは TypeSafe Jev の 3 プリミティブ（Noul・Choice・Score）とほぼ 1 対 1 で対応する構成で、前回「公表されている出力仕様は Jev のほうが詳しい」と書いた差は、公式仕様の公開でほぼ消えました。
一方、入力単価は前回の仮定どおりでした。前回は「通常の Luna と同じ入力・出力トークン課金で、返る値も候補名程度に短いと仮定すれば、費用の大半は入力トークンで決まる」と書きましたが、公式は入力 100 万トークン 0.10 米ドル、出力・キャッシュ読み書きは一切課金しないと明記しています。出力課金ありという仮定は外れ、よい方向に外れました。
3 つの質問型：predicate / choice / score
公式ガイドは、質問型を次の 3 つに整理しています。
| 型 | 問うこと | 主な返り値 | 公式の例 |
|---|---|---|---|
predicate |
ある条件が真か | probability（0〜1 の推定確率） |
商品写真に目に見える損傷があるか |
choice |
固定の候補からどれか | choice（候補の値）＋ probabilities ＋ confidence |
問い合わせの担当部署 |
score |
順序つきの段階のどこか | score（段階インデックスの確率加重平均）＋ probabilities ＋ confidence |
不具合の深刻度 |
図2：3 つの質問型。choice と score は候補ごとの確率分布と confidence を返し、predicate は確率だけを返します。score は段階の間の値を取れます。
公式ガイドは使い分けも明確に書いています。順序の無いカテゴリ（部署など）には choice、順序のある段階（深刻度など）には score。score は段階のインデックス（0 から始まる）の確率加重平均を返すので、「0.1 / 0.7 / 0.2」なら 1.1 という段階の間の値になります。
Jev を知っている人へ。この 3 型は Jev の Noul（真偽の確率）・Choice（候補と確率分布）・Score（段階の加重平均）と設計上ほぼ同じ構造です。フィールド名は違います（Jev の noul が Decisions API では probability、Jev の criteria が choices / levels）。「predicate に confidence が無く、choice と score にはある」という非対称性まで一致しています。
もう 1 つ、公式ガイドのコード例には refusal という応答型が登場します。質問が拒否された場合、その質問の name を持つ refusal 型の answer が返るので、アプリ側は 3 型に加えてこの分岐を持つ必要があります。
リクエストの形：model・input・questions
図3：リクエストは model・input・questions の 3 部品。画像は base64 のデータ URL のみで、ホストされた URL や file_id は使えません。
構造は前回の図 2 で推測した「質問・候補・コンテキスト」とほぼ同じですが、公式仕様で確定した点が 3 つあります。
- 画像は base64 のインライン data URL のみ。HTTP(S) の画像 URL や
file_idは受け付けません。画像を扱うアプリは自分でエンコードして送る設計になります - 独立した質問は同じ
questions配列に入れる。商品写真に対して「損傷があるか」と「カテゴリは何か」を 1 リクエストで聞けます。前の答えに依存する判断は別リクエストに分けます。これは Jev の「質問は同じ state に対して独立に評価される」と同じ考え方です - Structured Outputs や function calling との住み分けを公式が明記しました。自分の JSON Schema に従うオブジェクト（抽出フィールドや説明文）が欲しいなら Responses API の Structured Outputs、ツール呼び出しの引数を作らせたいなら function calling、確率・選択・スコアのどれかが欲しいなら Decisions API です。前回は、公開まで Structured Outputs で候補を enum として指定して疑似的に試すことを勧めましたが、公式の整理では両者は別の用途で、Decisions API は代替品ではなく専用の入口という位置づけです
料金と運用面：入力トークンだけを払う
図4：Decisions API は入力トークンだけに課金されます。生成文章の長さで費用が膨らむ Responses API との違いはここです。入力単価そのものは Jev のほうが安いままです。
公式ガイドの料金節は短く、要点は 3 つです。
gpt-6-lunaの入力 100 万トークン当たり 0.10 米ドル。出力トークン、キャッシュ読み取り、キャッシュ書き込みは課金なし- リージョン処理の割増と、長文入力の倍率は別途かかる
- Zero Data Retention（ZDR）と HIPAA 対応は対象顧客向けに提供。データレジデンシーとリージョン処理は米国と欧州（EEA ＋スイス）で対応
「キャッシュ課金なし」は「キャッシュが無料で効く」という意味ではありません。OpenAI Developer Community の告知スレッドでは、OpenAI 側の投稿者が「現時点で Decisions API にキャッシュ機能は無い（there’s currently no caching available for the Decisions API）」と答えています。同じ長いコンテキストに何度も質問を投げる設計では、毎回フルの入力トークンを払うことになります。
前回の記事で「Luna 相当の単価なら Jev のほうが入力単価で 2 倍強安い」と仮定つきで書いた計算は、入力単価の仮定が当たったので、そのまま成り立ちます。0.10 と 0.042 の比は約 2.4 倍です。ただし Jev には 1 リクエスト 64k トークンの上限があり、Decisions API 側の上限は確認日時点で公表されていないので、長い入力をどちらに流せるかはまだ比べられません。
Jev との再比較：差はどこに残ったか
前回の比較表を公式値で更新します。太字が今回変わった項目です。
| 項目 | OpenAI Decisions API（10 月 8 日時点） | TypeSafe Jev（jev-1.13.0） |
|---|---|---|
| 提供状況 | パブリックベータ（GA は数週間内の見込みと公式が明記） | API 公開中。Vercel AI Gateway 経由でも利用可 |
| エンドポイント | POST /v1/decisions |
POST /v1/systemone |
| 使えるモデル | gpt-6-luna のみ |
jev-1.13.0（jev-latest） |
| コンテキスト入力 | テキストと画像（画像は base64 のみ） | テキストのみ（文字列・JSON・配列） |
| 出力の型 | predicate / choice / score の 3 型 ＋ refusal | Noul / Choice / Score の 3 型 |
| 確率・confidence | choice と score に probabilities ＋ confidence、predicate は probability のみ | Choice と Score に confidence、Noul は 0〜1 の確率 |
| 複数質問 | 独立質問は 1 リクエストに同梱可。依存関係があれば別リクエスト | 同じ state に対して独立に評価 |
| 公称の応答速度 | Responses API 比 約 10 倍（公式ガイド） | 70〜500 ms（公式発表） |
| 入力トークン料金 | $0.10 / 100 万トークン | $0.042 / 100 万トークン |
| 出力トークン料金 | 無料（キャッシュ読み書きも課金なし。キャッシュ機能は無し） | 無料 |
| 1 リクエストの上限 | 依然未公表 | 64k トークン（state ＋最長の質問で 32k まで） |
| レート制限 | 未公表 | 100K トークン/秒・80 リクエスト/秒（Models ページの 10 月 1 日確認時は 40。同ページは「需要により動的に調整中」と注記） |
| データ管理 | ZDR・HIPAA（対象顧客）、米国・欧州リージョン | ZDR はエンタープライズ顧客向け。顧客のリクエスト・レスポンスで学習しないと明記。HIPAA の記載なし |
| SDK | Python / JS / Go / Ruby / Java（公式） | Python / JavaScript（公式） |
| 公開ドキュメント | 公式ガイド・Playground | docs.typesafe.ai |
図5：前回、確認日時点で対応状況が未確認の領域と書いた右上に、Decisions API が入りました。出力の表現力の差はほぼ無くなり、残る差は入力モダリティ・入力単価・上限と制限・ベースモデルの出自です。
残った差を 4 つに絞ると次のとおりです。
- 入力の幅: 画像を読めるのは Decisions API だけ。ただし base64 限定なので、画像 URL をそのまま渡す設計はできません
- 入力単価: Jev は約 1/2.4（0.042 対 0.10）。大量の短いテキストを分類する用途では効いてきます
- 上限と制限: Jev は 64k トークン・80 rps と公表済み。Decisions API は未公表で、ベータ中は変わる可能性があります
- ベースモデルの出自: Jev は判断専用に学習したモデル（RLCD）、Decisions API は汎用の
gpt-6-lunaを専用エンドポイントで動かすもの。公式ガイドは学習手法に触れていないので、較正の良し悪しは自分のデータで測るしかありません
較正については、告知スレッドに気になる報告が 1 件あります。ある投稿者が「1,000 回の試行で、表が 70% の偏りのあるコインを題材に、predicate では 70% 前後が返るのに、choice では 98% が返った」と書いています。コミュニティの 1 投稿で、再現条件も限られるため事実として扱うことはできませんが、「choice の確率をそのまま較正済みの確率として読まない」という注意点としては覚えておく価値があります。公式ガイド自身も、閾値は自分のアプリのラベル付きデータで決めるよう求めています。
どれを使うか：判定フロー
図6：Decisions API を使うのは「確率・選択・スコアのどれかが欲しいとき」。オブジェクト生成やツール引数は従来の経路に残ります。
公式ガイドの質問設計の推奨は、前回の記事で紹介した Jev のそれと驚くほど似ています。観測できる基準で質問を書く、関心事ごとに質問を分ける、候補には重ならない意味を持たせる、段階は隣同士の基準がはっきり違うように定義する。choice には "other" のようなフォールバック候補を入れ、そこへ落ちたものは人の確認キューへ回す、という運用も公式が勧めています。
音声エージェントへの組み込み
公式ガイドには、Live API の client delegation と組み合わせる節があります。音声モデル（GPT-Live）がユーザーと話し続けている間に、アプリ側が Decisions API でユーザーの要求と現在の画面状態から「次に実行するアクション」を選び、実行結果を delegation ID で音声モデルへ返す構成です。前回の記事で描いた「遅いループ（熟慮）と速いループ（即断）」の分担が、音声の文脈で公式に例示された形です。
試しに使うには
Playground で形を確かめる
Playground で質問と入力を打ち込み、3 型の返り値を見てから書き始めるのが最短です。OpenAI アカウントと API の利用設定が必要です。
curl で 1 回叩く
公式ガイドの choice の例をそのまま載せます。日本語の入力でも、候補の値と説明を日本語で書けば同じ形で使えます。
curl https://api.openai.com/v1/decisions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-6-luna",
"input": "I was charged twice for my order.",
"questions": [{
"type": "choice",
"name": "department",
"instructions": "Which department should handle this complaint?",
"choices": [
{"value": "billing", "description": "Payments, invoices, and refunds."},
{"value": "technical", "description": "Problems using the product."},
{"value": "shipping", "description": "Delivery and tracking."},
{"value": "other", "description": "Requests outside these categories."}
]
}]
}'返るのは answers[0] に type: "choice"、choice: "billing"、候補ごとの probabilities、confidence を持つオブジェクトです。
SDK から呼ぶ
公式 SDK は Python 3.26.0、JavaScript 7.30.0、Go 3.73.0、Ruby 0.101.0、Java 4.78.0 以降で decisions.create を持ちます。Python の最小例です。
from openai import OpenAI
client = OpenAI()
decision = client.decisions.create(
model="gpt-6-luna",
input="Export fails in Safari but works in Chrome.",
questions=[
{
"type": "score",
"name": "severity",
"instructions": "How severe is this issue?",
"levels": [
{"label": "Cosmetic", "description": "Appearance only; no lost functionality."},
{"label": "Workaround available", "description": "A task fails, but another way works."},
{"label": "Fully blocked", "description": "A task fails with no workaround."},
],
}
],
)
answer = decision.answers[0]
if answer.type == "refusal":
print(f"Refused: {answer.name}")
elif answer.type == "score":
print(f"Severity: {answer.score} (confidence: {answer.confidence})")refusal の分岐を先に書くのが公式例のパターンです。3 型の if / elif だけで組むと、拒否されたときにどの分岐にも入らず結果が黙って欠けます。最後を else にして answer.score のような型固有の属性へ無条件に触れる書き方なら AttributeError で落ちます。どちらも拒否応答を処理できていない点は同じです。
前回「形だけ先に作る」と書いた人へ
前回の記事では、公開を待つ間に Structured Outputs の enum で「候補から選ぶ」形を作っておくことを勧めました。公式仕様が出た今、その形は questions 配列の choice 型に素直に写せます。enum の値はそのまま choices[].value へ、各値の説明を description へ移すだけです。差し替え時に新たに増えるのは、probabilities と confidence をどう使うかの設計と、refusal の分岐です。
読むときの留保
- パブリックベータです。公式ガイドは「数週間内に GA を見込む」と書いていますが、GA 時に料金・制限・フィールド名が変わる可能性はあります
- 「約 10 倍速」は OpenAI 自身の説明で、比較対象は Responses API 経由の
gpt-6-lunaです。測定条件は公表されておらず、独立の測定ではありません - 1 リクエストの上限とレート制限は未公表です。質問数・候補数・入力長の上限は公式ガイドに書かれていません
- 較正の品質は自分のデータで測る必要があります。コミュニティの報告は 1 件の観察であって、確定した性質ではありません
- 私たちはまだ API を実測していません。本記事は公式ガイドと告知スレッドの読解に基づきます。実測した結果は別の記事で報告する予定です
まとめ：空欄は埋まり、問いは「どちらが速いか」から「どう使い分けるか」へ
公式仕様の公開で、Decisions API と Jev は「同じ 3 型の判断を返す API が 2 つある」状態になりました。前回の記事で書いた比喩（仕分け係・受付・カーナビ）はいずれも候補からひとつ選ぶ用途で、公式の型名では choice に写せます。そこに、深刻度のような段階を測る score と、真偽を判定する predicate が加わり、より具体的に設計へ落とせます。
残った差は、画像を読めるか、入力単価、上限、ベースモデルの出自です。どちらを選ぶにしても、公式ガイドが繰り返し書いているとおり、閾値は自分のアプリのラベル付きデータで決めることに変わりはありません。答えの選択肢を決めるのも、その答えをどう信じるかを決めるのも、相変わらず人の仕事です。
参考資料
- OpenAI：Decisions（公式ガイド）／Decisions with the Live API（client delegation）／API Changelog（2026 年 10 月 6 日の項）／料金ページ／Playground
- OpenAI Developer Community：Decisions API is now available in Public Beta（2026 年 10 月 6 日。キャッシュ非対応の回答と較正の報告を含む）
- TypeSafe AI：Models／HTTP API／Primitives
- フィールフロウ：OpenAI Decisions API を読む：Jev と並んだ「判断だけを返す AI」の使いどころ（2026 年 10 月 1 日）／TypeSafe AI「Jev」を読む（2026 年 9 月 19 日）