OpenAI Decisions API を読む:Jev と並んだ「判断だけを返す AI」の使いどころ

OpenAI が DevDay 2026 で発表した Decisions API は、文章を生成せず、用意した候補から答えを選ぶ API です。何ができるのか、どんな場面で効くのか、TypeSafe の Jev と何が違うのかを、6 枚の図解と比較表で整理します。料金や試し方も、公表済みと未公表を分けて確認します。

著者
岡崎 太
CTO / AIアーキテクト
公開日
読了時間
15分で読めます
Share

2026 年 9 月 29 日の OpenAI DevDay で、20 を超える発表のなかに小さく「Decisions API」という項目がありました。常時稼働エージェントの dots や GPT-6.1 Sol の陰に隠れがちですが、私はこれを今回の DevDay で最も「設計思想」が表れた発表だと受け止めています。

DevDay の 2 週間前に TypeSafe AI が発表した Jev を、前回の記事で取り上げました。「文章を生成せず、型付きの判断を返す」モデルです。Decisions API は、OpenAI が同じ方向へ踏み出したものと読めます。

本記事では、Decisions API とは何か、どんな場面で使えるのか、Jev と何が違うのか、そして今すぐ試すにはどうすればよいかを、図解を中心に整理します。情報の確認日は 2026 年 10 月 1 日です。Decisions API は限定プレビュー段階で、公開された技術ドキュメントはまだ確認できていません。公表済みの情報と未公表の情報を分けて書きます。

おさらい:System One Models とは何だったか

前回の記事で扱った概念を 1 枚で振り返ります。TypeSafe AI は、自社のモデル群を System One Models と呼びました。Daniel Kahneman の「速い直感(System 1)と遅い熟慮(System 2)」の区別に着想を得た命名です。

普通の LLM に自由文で分類を頼むと、入力に対して文章が返ります。アプリケーションがその答えを使うには、文章を解析して値を取り出す必要があります。System One 型のモデルは、入力に加えて「質問」と「答えの候補」を受け取り、候補のどれかを選んだ結果を返します。アプリは解析なしに、その値で分岐できます。

なお、一般的な LLM でも Structured Outputs のような仕組みで出力の形を候補に固定することはできます。System One 型の違いは出力の形そのものより、この判断だけに特化して速く・安く答えることに置かれています。後述の Decisions API の速度の主張も、その文脈で読んでください。

「文章を返す AI」と「判断を返す AI」A. 一般的な LLM(自由文で分類させた場合)問い合わせ文LLM「このお問い合わせは請求に関する内容と思われます…」文章を解析し値を取り出すB. System One 型(Jev / Decisions API)問い合わせ文+ 質問+ 回答候補(3 つ)判断モデル候補から選ぶ“請求”そのままif / switch へ

図1:一般的な LLM に自由文で分類させると解析工程が要る。System One 型は候補のどれかを返すので、コードがそのまま分岐に使える。

TypeSafe の Jev は、この「候補から選ぶ」を 3 種類の型(Choice・Score・Noul)に広げ、確率や confidence も返します。詳しくは前回の記事を参照してください。OpenAI の発表文には System One という語は出てきません。本記事では、この設計の系統を指す言葉として借りています。

Decisions API とは何か

OpenAI の DevDay 2026 の振り返りは、Decisions API を次のように説明しています。

Decisions API は、あらかじめ定めた有限の回答候補を持つ、ユーザー定義の特定の質問群に Luna の知能を集中させることで、リアルタイムの意思決定を可能にします。開発者がテキストや画像でコンテキストを提供すると、コンテンツの分類、リクエストの振り分け、エージェントの次のアクションの選択に使える回答が返されます。

要素を分解すると、入力は 3 つ、出力は 1 つです。

Decisions API に渡すもの・返るもの(公式説明からの整理)① 質問「この問い合わせの担当はどこか」② 有限の回答候補請求 / 技術 / 解約 / その他③ コンテキストテキスト または 画像Decisions APIGPT-6 Luna の特化版④ 回答“技術”分類振り分け次の一手※ リクエストの正確なスキーマや、確率・スコアが返るかどうかは、確認日時点で未公表

図2:Decisions API の入出力。公式説明に書かれているのは「質問」「有限の候補」「テキストか画像のコンテキスト」を渡し、候補から選ばれた回答が返ることまでです。

公式の発表から読み取れる特徴は次の 4 点です。

  • モデルは GPT-6 Luna の特化版。Luna は OpenAI の低価格帯のモデル系統で、推論とマルチモーダル入力に対応しています
  • 答えは開発者が決めた候補の中から返ります。自由文は返しません
  • コンテキストに画像を渡せます。ここは後述のとおり Jev との明確な違いです
  • 想定用途は分類・振り分け・エージェントの次のアクション選択の 3 つです

速度については、The Decoder が DevDay の報道で「OpenAI は、通常の API 経由の GPT-6 Luna より 10 倍速く判断すると説明した」と伝え、チャートのキャプションに Decisions API 約 150 ミリ秒、GPT-6 Luna API 約 1.6 秒という数値を載せています。これは OpenAI 側の説明に基づく比較値で、測定条件は公表されておらず、独立に測定された値ではありません。

提供状況は、発表日時点で「限定プレビュー、数日以内に広く公開予定」です。OpenAI Developers の X 投稿(9 月 30 日)も「limited preview」と書いています。確認日時点で API Changelog に Decisions API の項目はなく、料金ページにも載っていません。

どういう場面で使えるのか:3 つの比喩

「候補から選ぶだけ」の API は、何に使えるのでしょうか。公式が挙げた 3 用途を、身近な仕事の役割に置き換えると見通しがよくなります。

「候補から選ぶ」が仕事になる 3 つの場面① 郵便の仕分け係= コンテンツの分類届いたものを、決まった棚のどれかに入れる。棚を新しく作る権限はない。例:レビューの感情、投稿のポリシー違反有無、文書の種別② 病院の受付= リクエストの振り分け内科外科救急来た人を診るのではなく、どの窓口に案内するかをその場で決める。例:問い合わせの担当部署、どのモデル・ツールに回すか③ カーナビの分岐案内= エージェントの次の一手今の位置と目的地から、次に曲がる方向をひとつ選ぶ。運転するのはあなた。例:続行 / 人に確認 / 中止、次に呼ぶツールの選択共通点:答えの選択肢は前もって決まっていて、求められるのは「速く・一貫して選ぶこと」

図3:3 つの比喩に共通するのは、仕事の中身が「新しい答えを作る」ことではなく「決まった選択肢から、速く一貫して選ぶ」ことです。

3 つの比喩に共通するのは、選択肢は人が前もって決めていることです。仕分け係は棚を増やせませんし、受付は診療しませんし、カーナビは運転しません。それでも、この役割がいないと全体が回りません。

逆に、こうした役割に「文章を書くのがうまい人」を当てると無駄が出ます。手紙を 1 通仕分けるたびに所見を書かれては、棚に入るまでの時間も人件費もかさみます。LLM に分類を頼むと「このお問い合わせは請求に関する内容と思われます。理由は…」と返ってきて、アプリ側で解析する、というのがまさにこの状態です。

エージェントの中での位置

3 つ目の「次の一手」は、AI エージェントの設計に直結します。エージェントは「状況を見る → 次に何をするか決める → 実行する」のループを何十回も回します。この「決める」の多くは、実は選択肢が決まっています。ツール A を呼ぶか B を呼ぶか、作業を続けるか人に確認するか、終了するか。

エージェントの「速いループ」と「遅いループ」遅いループ(熟慮)GPT-6.1 Sol / Astra、Claude Fable 5.1 など計画を立てる・分解する文章やコードを生成する結果をまとめて人に説明する1 回あたり 数秒 〜 数十秒速いループ(即断)Decisions API / Jev次に呼ぶツールを選ぶ続行 / 人に確認 / 中止 を決めるログや入力を分類・検査する1 回あたり 0.07〜0.5 秒(各社公表・報道値)状況判断何十回も回る内側の判断を軽くすると、エージェント全体の速度と費用が変わる

図4:熟慮が必要な工程と、選択肢が決まっている判断を分ける。後者を軽いモデルに任せるのが、Decisions API と Jev に共通する狙いです。

前回の記事で「定型判断を短い経路で終え、必要な場面に熟慮を集中する」と書きました。Decisions API は、この分担を OpenAI のスタックの中で実現するための部品です。同じ DevDay で発表された Agents API(コンピューター操作対応)と合わせて読むと、「大きなモデルが計画し、小さなモデルが現場で即答する」構成を OpenAI 自身が推し進めていることが分かります。

Jev との違い:何が同じで、何が違うのか

同じ系統に見える 2 つを、公表情報の範囲で並べます。「未公表」は、確認日時点で公式情報が見つからなかった項目です。

項目 OpenAI Decisions API TypeSafe Jev(jev-1.13.0)
発表 2026 年 9 月 29 日(DevDay) 2026 年 9 月 15 日
ベースモデル GPT-6 Luna の特化版 専用学習の System One モデル(RLCD)
コンテキスト入力 テキストと画像 テキストのみ(文字列・JSON・配列)
出力の型 候補からの選択(1 種類) Choice・Score・Noul の 3 種類
確率・confidence 未公表 Choice と Score に confidence、Noul は 0〜1 の確率
公称の応答速度 約 150 ms(通常の Luna 比 10 倍。報道のチャートより) 70〜500 ms(公式発表)
入力トークン料金 未公表(通常の Luna は $0.10 / 100 万トークン) $0.042 / 100 万トークン
出力トークン料金 未公表(通常の Luna は $0.50 / 100 万トークン) 無料
1 リクエストの上限 未公表 64k トークン(state+最長の質問で 32k まで)
提供状況 限定プレビュー(数日以内に拡大予定と発表) Quick start からキー取得・呼び出し可(前回記事時点の待機リスト表記から変化)。Vercel AI Gateway 経由でも利用可
公開ドキュメント 確認日時点でなし docs.typesafe.ai

Jev 側の数値は Models ページと公式発表、OpenAI 側は DevDay 振り返り・料金ページ・The Decoder の報道に基づきます。

違いを 2 つの軸に落とすと、位置関係がはっきりします。

入力の幅 × 出力の表現力で見る 2 つの位置コンテキスト入力 →テキストのみテキスト+画像出力の表現力 →単一選択選択+確率+段階+真偽TypeSafe JevChoice / Score / Noul確率と confidence を返すDecisions API画像コンテキストに対応出力は候補からの選択画像も読めて、確率も返す(確認日時点では空白)

図5:公表済みの出力機能は Jev のほうが詳しく、入力の幅は Decisions API が広い。Decisions API の出力に確率が付くかは未公表のため、公式説明の範囲で「単一選択」に置いています。公開仕様で位置が動く可能性があります。

違い①:画像を読めるのは Decisions API だけ

Jev の Models ページは「テキストのみ。画像・音声・動画の入力は不可」と明記しています。Decisions API は公式説明に「テキストや画像でコンテキストを提供」とあります。

これは用途を分けます。たとえば画面のスクリーンショットを見て「次に押すボタンはどれか」を選ぶ、商品画像を見て「どのカテゴリか」を分類する、といった判断は、この 2 つのうち Decisions API にしかできません。前回の記事で触れた Jev の DOOM デモが、画面の画像ではなくテキストで表した構造化状態を入力していたのは、この制約の裏返しです。

違い②:公表されている出力仕様は Jev のほうが詳しい

Jev は 3 つの型を持ち、Choice なら候補ごとの確率、Score なら段階の間の値、Noul なら真である確率を返します。「請求 0.62、技術 0.35、解約 0.03」のように分布が見えるので、拮抗していれば人に戻す、という設計がしやすくなります。

Decisions API の公式説明は「回答が返される」までで、確率やスコアが付くかは書かれていません。一部の解説記事には「confidence score」と書くものもありますが、OpenAI 自身の表現ではないため、本記事では未公表として扱います。公開ドキュメントが出たら、ここが最初に確認すべき点です。

違い③:料金は「Luna 相当か、それより安いか」が焦点

Jev は入力 $0.042 / 100 万トークン、出力無料です。Decisions API の料金は未公表ですが、ベースの GPT-6 Luna は入力 $0.10・出力 $0.50(いずれも 100 万トークン当たり)です。Decisions API が通常の Luna と同じ入力・出力トークン課金で、返る値も候補名程度に短いと仮定すれば、費用の大半は入力トークンで決まることになります。ただし課金単位も応答形式も未公表なので、これは仮定の上の見積もりです。

その仮定のうえで Luna 相当の単価なら、Jev のほうが入力単価で 2 倍強安い計算です。ただし Jev は 1 リクエスト 64k トークン、state は最長の質問と合わせて 32k トークンまでという上限があり、長い文書を一度に判断させたい場合は分割が要ります。Luna 本体の 100 万トークン超のコンテキストが Decisions API にも適用されるかは未公表です。

同じところ:答えの候補を人が決める

どちらも「答えの選択肢は開発者が定義する」設計です。これは制約であると同時に、品質保証の土台です。返り値が候補の外に出ないので、アプリ側の分岐が崩れません。前回の記事で書いたとおり、これは、候補のなかから誤った答えを選ぶ可能性まで消すものではありません。精度は業務データで検証する必要があります。

試しに使うには

「今日試せるか」で分けると、答えははっきりしています。

今日、判断専用モデルを試すには(2026 年 10 月 1 日時点)画像コンテキストが必要?いいえはいJev を今すぐ試す1. console.typesafe.ai で API キーを取得2. curl か Python / JS SDK でPOST /v1/systemone3. state と questions を渡し、answers を読む別経路:Vercel AI GatewayDecisions API の公開を待つ1. 限定プレビュー。API Changelog を監視2. それまでは GPT-6 Luna のStructured Outputs で候補を enum 指定し「候補から選ぶ」形を先に作っておく公開後は呼び出し先を差し替えるだけにする

図6:Jev は今日から試せます。Decisions API は公開待ちですが、「候補から選ぶ」形のコードは先に作っておけます。

Jev:API キーを取って 1 回叩く

TypeSafe の Quick start に従えば、SDK なしでも試せます。コンソールで API キーを取得し、次のように呼びます。

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": "請求書の金額が先月と違います。契約内容を確認したいです。",
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "この問い合わせの担当部署はどこか",
        "criteria": {
          "請求": "金額・請求書・支払いに関する内容",
          "技術サポート": "製品の不具合や使い方に関する内容",
          "解約": "契約の終了や解約手続きに関する内容",
          "その他": "上のどれにも当てはまらない内容"
        }
      },
      "urgent": {
        "type": "noul",
        "instructions": "この問い合わせは至急の対応を求めているか"
      }
    }
  }'

answers.department に選ばれた候補(choice)と候補ごとの確率(probabilities)、confidence が、answers.urgent の noul に 0〜1 の値が返ります。Python なら pip install typesafe-sdk、JavaScript なら npm install @typesafe-ai/sdk(JavaScript SDK)で SDK を導入できます。日本語入力について、Models ページは、英語が主で、CJK を含む他言語は同等には扱えないので自分のデータで試すよう注記しているので、日本語の業務データでは必ず精度を測ってください。

Decisions API:公開を待ちつつ、形だけ先に作る

確認日時点で、Decisions API は限定プレビューで、申し込みフォームや待機リストも見つけられませんでした。API Changelog と OpenAI Developers の X アカウントが、公開を知る最短の経路です。

待っている間にできることがあります。通常の GPT-6 Luna を Responses API から呼び、Structured Outputs で候補を enum として指定すれば、「候補から選ぶ」形の入出力は今日から作れます。

{
  "type": "object",
  "properties": {
    "department": {
      "type": "string",
      "enum": ["請求", "技術サポート", "解約", "その他"]
    }
  },
  "required": ["department"],
  "additionalProperties": false
}

この形でアプリ側の分岐を組んでおけば、Decisions API が公開されたときに作り直すのは接続部分に絞れます。公式説明にある「質問・候補・コンテキストを渡し、候補のひとつが返る」という使い方は共通していますが、実際のリクエスト形式は未公表なので、接続方法は公開仕様に合わせて書き直す前提でいてください。

読むときの留保

本記事は発表から 2 日後の公開情報に基づいています。次の点は、公式ドキュメントが出た時点で読み直してください。

  • 「150 ms・10 倍」は OpenAI 側の説明に基づく比較値です。報道のチャートに載った数値で、どの入力長・どのリージョンで測ったかは不明です。Jev の 70〜500 ms も同様にベンダー公称で、両者を同じ条件で比べた測定は確認できていません
  • 出力に確率が付くかは未公表です。「confidence」と書く二次情報は OpenAI の表現ではありません
  • 料金・レート制限・候補数の上限は未公表です。ベースの Luna と同じ単価と決めつけないでください
  • System One という呼称は TypeSafe のもので、OpenAI は使っていません。「OpenAI が System One Models を出した」という表現は、設計の系統としては妥当でも、公式の用語としては不正確です

まとめ:選択肢を決めるのは、相変わらず人

Decisions API と Jev は、どちらも「AI に文章を書かせない」使い方を API の形にしたものです。違いは、Decisions API が画像を読めること、Jev は公表されている出力仕様が詳しく確率まで返すことにあります。料金は Jev が公表済みで、Decisions API は本稿の確認日時点では公開待ちです。

どちらを使うにしても、仕事の本質は変わりません。答えの選択肢を人が決め、速く一貫して選ぶ役割をモデルに渡す。仕分け係の棚、受付の窓口、カーナビの分岐を設計するのは私たちです。

前回の記事で書いた運用原則、定型判断を短い経路で終え、熟慮は観測できる条件で始めるという分担は、使うベンダーが増えても変わりませんでした。むしろ OpenAI が同じ方向へ来たことで、この分担が業界の共通言語になりつつあると感じています。

AI エージェントのループの中で、何十回も回っている「選ぶだけの判断」はありませんか。そこに大きなモデルを使い続ける理由があるか、一度数えてみることをお勧めします。

参考資料