ChatGPT

OpenAI Decisions APIとは?分類と振り分けの実装・料金【2026年10月】

OpenAI Decisions APIとは?分類と振り分けの実装・料金【2026年10月】

OpenAI Decisions APIは、テキストや画像と「答えの候補が決まった質問」を渡すと、文章ではなく確率付きの判断だけを返すAPIです。2026年10月6日にパブリックベータとなり、使えるモデルは gpt-6-luna だけ、課金は入力トークンのみです。この記事では、POST /v1/decisions の仕組みと3種類の質問、Structured Outputsとの使い分け、月100万件の費用試算、問い合わせを部署へ振り分けるPythonコードと閾値の決め方までを公式ドキュメントで確認します。TypeSafe JevやMicrosoft-Decision-1など同じ形式の判断モデルとの比較と、採用・見送りの条件も整理しました。仕様と価格は2026年10月16日時点の情報です。

まとめ:OpenAI Decisions APIは候補が決まった判断を確率で返す分類専用API

Decisions APIが向くのは、問い合わせの担当部署の選択、商品写真の破損チェック、障害の深刻度付けのように、答えの候補を先に列挙できる処理です。返ってくるのは選んだ値と確率だけ。理由の文章は返りません。

費用面の特徴ははっきりしています。入力100万トークンあたり0.10ドルで、出力トークン・推論トークン・キャッシュの読み書きには課金されません。1件500トークンの問い合わせを月100万件さばいても、入力の50ドルで収まる計算です。

採用の判断は「確率の閾値を自社のデータで決められるか」で分かれます。正解ラベル付きのデータを数百件用意でき、低確信度の案件を人に戻す運用を組めるなら、まずベータのうちに検証してよいAPIです。理由の説明文や抽出項目まで欲しい処理、日本国内での処理が契約上必須の処理は、Structured Outputsや別の手段を選びます。

OpenAI Decisions APIの仕組みと型付き回答の入出力条件

まず、専用エンドポイント POST /v1/decisions のリクエストとレスポンスの形を押さえます。チャット形式のAPIとはエンドポイントも返り値も別物です。

model・input・questionsの3要素で送りanswers配列で受け取る構造

OpenAIのDecisionsガイドによると、リクエストは3つの項目で組み立てます。model は現時点で gpt-6-luna だけ、input は判断材料となる文字列かメッセージの配列、questions は聞きたい質問の一覧です。応答の answers 配列には質問と同じ順で答えが入り、質問に付けた name がそのまま返ります。

上限はAPIリファレンスのCreate a decisionに載っています。1リクエストの質問は1〜200問、choice の選択肢は2〜255個で重複不可、画像は1リクエスト128枚までです。土台の gpt-6-luna は2026年9月22日に公開された軽量モデルで、上位のSolやAstraとの関係はGPT-6 SolとLuna・Astraの使い分けを整理した記事で扱いました。

predicate・choice・scoreの3種類の質問で返る値と使い分けの基準

質問の型は3つです。どれを選ぶかで返る値の形が変わります。

型 問いの形 主な返り値 向く処理の例
predicate この条件は真か probability(0〜1) 破損の有無、緊急かどうか
choice どれに当たるか choice・各候補の確率・confidence 担当部署やカテゴリの選択
score どの段階か score・各段階の確率・confidence 深刻度、優先度

迷いやすいのは choice と score の境目です。順序の無い分類は choice、軽微から致命的のように順序のある段階は score を使います。score は段階番号(0始まり)を確率で重み付けした平均なので、ガイドの例では確率0.1・0.7・0.2から1.1という段階の間の値が返ります。

どの質問にも、答えの代わりに type: "refusal" が返る場合があります。リファレンスでは、ある質問が拒否されても同じリクエストの他の質問には答えが返ると明記されています。コード側で拒否を個別に処理しておく必要があるのはこのためです。

DevDayの限定プレビューから10月6日のパブリックベータまでの経緯

提供状況は短期間で変わりました。DevDay 2026のまとめでは、9月29日の発表時点で「限定プレビュー」とされていました。その後、APIのchangelogの10月6日付けでベータとして公開され、10月15日にはGPT-Liveとの連携が追加されています。

ガイドは現在の段階をパブリックベータとし、GA(一般提供)は「数週間以内」の見込みと書いています。発表直後の海外記事には「招待制で403が返る」「料金は未公表」とするものが残っていますが、10月6日以降の公式ドキュメントとは食い違います。調べるときは記事の日付を確かめてください。

Decisions APIの使いどころと構造化出力・関数呼び出しとの比較

OpenAIにはStructured OutputsやFunction Callingのように、出力の形を縛る仕組みがすでにあります。Decisions APIを足す意味は、用途の線引きと料金の違いにあります。

JSON Schemaで生成させる構造化出力と候補から選ばせるDecisionsの境界

ガイドは使い分けを明記しています。答えが真偽の確率・候補からの選択・段階評価のどれかで済むならDecisions。自前のJSON Schemaに沿ったオブジェクト(抽出した項目や説明文)が要るならStructured Outputs。モデルに引数付きでツールを呼ばせたいならFunction Callingです。

Structured Outputsでも enum で候補を縛れば分類はできます。仕組みと見送り条件はLLM構造化出力の解説に、ツール呼び出しはFunction CallingのOpenAI実装にまとめました。それでもDecisionsを選ぶ理由は、候補ごとの確率が返る点です。構造化出力では選ばれた1つの値しか分からず、「どのくらい迷ったか」で人に回すかを決める設計が組めません。

入力だけ課金で出力・推論トークンがかからない料金体系と月100万件の試算

ガイドの料金欄によると、gpt-6-luna でのDecisionsは入力100万トークンあたり0.10ドルで、出力トークン・キャッシュ読み込み・キャッシュ書き込みの料金はありません。リファレンスの応答例でも output_tokens と reasoning_tokens は0です。

同じLunaをResponses APIで使う場合、GPT-6 Lunaのモデルページの単価は入力0.10ドル・出力0.50ドルで、推論の強さの既定値は medium です。推論トークンは出力として数えられます。1件あたり入力500トークンで月100万件を処理すると、次の差が出ます。

呼び出し方 入力(5億トークン) 出力・推論 月額の目安
Decisions API 50ドル 課金なし 50ドル
Responses API(試算条件は下記) 50ドル 2億トークン×0.50ドル=100ドル 150ドル

Responses APIの試算では、出力と推論で計200トークンと仮定しています。この200トークンは説明のための仮定で、実際は推論の強さと出力形式で増減します。注意点は割増です。ガイドは地域処理の割増と長文入力の倍率がDecisionsにも掛かるとしており、モデルページでは272Kトークンを超える入力で単価が2倍、地域処理で10%増しです。長い会話履歴を丸ごと渡す設計にすると、この試算は崩れます。

Pythonで問い合わせを部署に振り分けるDecisions APIの実装手順と閾値設計

ここからは、問い合わせ本文を担当部署へ振り分ける最小構成を組みます。コードはガイドとリファレンスの仕様に沿った例で、出力値は環境によって変わります。

SDKの対応バージョン確認とcurlで最初のリクエストを送る手順

ガイドが示すSDKの下限は、Python 3.26.0・JavaScript 7.30.0・Go 3.73.0・Ruby 0.101.0・Java 4.78.0です。導入方法は公式のSDK一覧にあります。まずはSDKを入れる前に、curlで1問だけ送って応答の形を確かめます。

curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "input": "注文した商品が二重に請求されています。",
    "questions": [{
      "type": "choice",
      "name": "department",
      "instructions": "この問い合わせを担当すべき部署はどれか。",
      "choices": [
        {"value": "billing", "description": "請求・支払い・返金"},
        {"value": "technical", "description": "製品の不具合や使い方"},
        {"value": "shipping", "description": "配送と追跡"},
        {"value": "other", "description": "上記のどれにも当たらないもの"}
      ]
    }]
  }'

応答の answers[0] に、選ばれた choice、4候補それぞれの probabilities、全体の confidence が入ります。候補に other を入れているのはガイドの推奨に沿ったもので、どこにも当てはまらない問い合わせを汎用の確認キューへ流す受け皿になります。

3種類の質問を1回で聞き拒否と低確信度を人に戻すPythonコード

実運用では、部署の選択・緊急かどうか・深刻度を1回のリクエストでまとめて聞けます。互いに独立した質問は同じ questions に並べ、前の答えで次の質問が変わる場合だけリクエストを分けるのがガイドの指針です。

pip install "openai>=3.26.0"
from openai import OpenAI

client = OpenAI()

# 振り分け先の候補(説明文で各候補の適用範囲を区別する)
CHOICES = [
    {"value": "billing", "description": "請求・支払い・返金に関する問い合わせ"},
    {"value": "technical", "description": "製品の不具合や使い方に関する問い合わせ"},
    {"value": "shipping", "description": "配送・追跡に関する問い合わせ"},
    {"value": "other", "description": "上記のどれにも当たらない問い合わせ"},
]

# 閾値は仮の値。正解ラベル付きデータで決め直す
CONFIDENCE_MIN = 0.80
URGENT_MIN = 0.70


def route(ticket_text: str) -> dict:
    decision = client.decisions.create(
        model="gpt-6-luna",
        input=ticket_text,
        questions=[
            {
                "type": "choice",
                "name": "department",
                "instructions": "この問い合わせを担当すべき部署はどれか。",
                "choices": CHOICES,
            },
            {
                "type": "predicate",
                "name": "urgent",
                "instructions": "顧客がサービスを使えない状態にあると明記しているか。",
            },
            {
                "type": "score",
                "name": "severity",
                "instructions": "顧客の業務への影響はどの段階か。",
                "levels": [
                    {"label": "軽微", "description": "見た目だけで機能は失われていない"},
                    {"label": "回避策あり", "description": "作業は失敗するが別の方法で進められる"},
                    {"label": "完全停止", "description": "作業が失敗し回避策がない"},
                ],
            },
        ],
    )

    answers = {a.name: a for a in decision.answers}

    # 質問ごとに拒否が返りうるので、1つでも拒否なら人の確認へ回す
    if any(a.type == "refusal" for a in answers.values()):
        return {"queue": "human_review", "reason": "refusal"}

    dept = answers["department"]
    # 受け皿の other と確信度の低い判断は、自動で振り分けない
    if dept.choice == "other" or dept.confidence < CONFIDENCE_MIN:
        queue = "human_review"
    else:
        queue = dept.choice

    return {
        "queue": queue,
        "urgent": answers["urgent"].probability >= URGENT_MIN,
        "severity": round(answers["severity"].score, 2),
        "input_tokens": decision.usage.input_tokens,
    }


if __name__ == "__main__":
    print(route("昨日の注文が二重に請求されています。今日中に返金してください。"))

このコードの要は、モデルの答えをそのまま信じない3つの分岐です。拒否が1つでもあれば人へ、other が選ばれたら人へ、confidence が閾値未満でも人へ回します。usage.input_tokens を記録しておけば、件数あたりの費用を後から実測できます。

確率の閾値を正解ラベル付きデータで決める手順と誤判定コストの置き方

ガイドは閾値について、自社アプリのラベル付き例を使い、誤検知と見逃しのコストで決めるよう述べています。数字の決め方を手順に落とすと次のとおりです。

  1. 過去の問い合わせから300件程度を抜き出し、担当者が正解の部署を付ける
  2. 同じ文面をDecisions APIに送り、choice と confidence を記録する
  3. 閾値を0.5から0.95まで0.05刻みで動かし、自動処理に回る割合と、その中の誤振り分け率を表にする
  4. 誤振り分け1件の手戻りと人の確認1件の手間を比べ、総コストが最小になる閾値を採る

請求のように誤りの影響が大きい部署だけ閾値を高くする、という部署別の設定も有効です。判断の妥当性を人手の評価と突き合わせる考え方はLLM-as-a-Judgeでの人手との一致率の測り方が参考になります。なお9月25日のchangelogには、Lunaの画像エンコードの不具合修正と評価の再実行の推奨が載っています。画像を含む評価は、それ以降のデータで取り直してください。

画像入力・GPT-Live連携・データ管理で確かめる実装前の制約

テキストの分類以外に広げる前に、3つの制約を確認します。

画像はbase64のdata URLで渡すガイドの指定とリファレンスの記載差

ガイドは、画像はインラインのbase64のdata URLに限り、HTTP(S)でホストした画像URLと file_id は使えないと書いています。一方、APIリファレンスの DecisionInputImage の説明には「base64のdata URLまたは公開されたHTTP(S)のURL」とあり、記載が揃っていません(2026年10月16日時点)。

ベータ中の仕様差なので、実装はガイドに合わせてbase64で送るのが安全です。URL渡しを前提にした設計は、GAの時点でどちらに寄せられたかを確認してから採ります。画像の解像度は detail で low・high・auto・original を選べ、既定は auto です。

10月15日に加わったGPT-Liveのネイティブ委譲で音声中に判断を返す構成

音声とDecisionsをつなぐガイドによると、GPT-LiveのセッションにDecisionsを組み込むと、Liveが自社アプリを経由せずにDecisionsを直接呼び出せます。session.delegation に質問を定義する方式と、利用者や Live の発話の文字起こしに反応する session.triggers の方式があり、どちらも api.decisions.write の権限が必要です。

ガイドの例は車内のエアコン操作で、「暖かくして」という発話に対し温度を上げる選択肢が返ります。選択肢 none を何もしない合図として扱い、実際の操作と結果の確認はアプリ側で行う作りです。GPT-Live自体の仕組みはGPT-Live-1の解説で整理しています。音声の受付で用件を振り分ける用途なら、この連携が最も効きます。

ZDR・HIPAA対応と米国・欧州に限られるデータ所在地の条件

ガイドでは、Decisions APIは対象となる顧客向けにZDR(ゼロデータ保持)とHIPAAでの利用に対応しています。データ所在地と地域処理は米国と欧州(EEAとスイス)のみで、日本は含まれていません。適用条件と必要な契約はOpenAIのデータ管理のページで確認します。

日本国内での処理を契約で求められる業務データには、現時点で使えないということです。個人情報を含む問い合わせを流すなら、氏名や連絡先を除いた本文だけを送る前処理を入れるか、法務と保持条件を詰めてから進めます。

OpenAI Decisions APIと判断専用モデルの比較による採用条件

判断専用のモデルは2026年9〜10月に相次いで出ています。最後にJev・Clef・Microsoft-Decision-1と横並びで比べ、採否を条件付きで決めます。

判断専用モデル4製品の採用検討に向けた単価・入力形式・提供段階の比較表

OpenAIの値(モデルは gpt-6-luna)はDecisionsガイドとモデルページ、他3製品の値は各製品の解説記事に記した公式情報によります(2026年10月14〜16日時点)。

製品 入力単価(100万トークン) 入力形式 提供段階
OpenAI Decisions API 0.10ドル テキスト・画像 パブリックベータ
TypeSafe Jev 0.042ドル テキストのみ 早期アクセス
Cloudflare Clef-flash 0.038ドル テキスト・JSON・画像 Workers AIで公開
Microsoft-Decision-1 0.042ドル テキスト・JSON パブリックプレビュー

単価だけならOpenAIが2倍以上高い製品です。それでも選ぶ理由は、既存のOpenAIの契約・APIキー・データ管理の設定をそのまま使えることと、GPT-Liveの音声セッションから直接呼べることにあります。質問の型名もJev系の noul に対しOpenAIは predicate と異なるため、製品間の乗り換えではリクエストの組み立てを書き換えることになります。

OpenAI Decisions APIを採用してよい処理と見送る処理の条件

採用してよいのは、すでにOpenAIのAPIを使っていて、答えの候補を列挙できる大量の判定を、Responses APIからコストを下げて置き換えたい場合です。問い合わせの振り分け、投稿の一次審査、商品写真の検品、音声受付での用件判定がこれに当たります。確率が返るので、人に回す件数を閾値で調整できるのも利点です。

見送るのは3つの場面です。1つめは、判断の理由を文章で残す必要がある処理で、Decisionsは理由を返しません。2つめは、日本国内での処理が契約で必須のデータです。3つめは、ベータ版を本番の唯一の判定経路にする設計で、GAまでに仕様が変わる前提で切り戻し先を用意しておかないと止まります。「閾値を決めずに最上位の候補をそのまま採用する」のは、どの製品でも避けるべき失敗パターンです。

既存の問い合わせ管理や審査の仕組みに判断APIを組み込む場合、工数がかかるのはAPI呼び出しより、正解データの整備・閾値の設計・人に戻す画面と記録の側です。要件が固まった段階で生成AI開発・AI受託開発の相談窓口に持ち込めば、評価データの作り方から本番の切り戻し設計まで一緒に詰められます。

OpenAI Decisions APIの導入検討でよくある質問と公式情報に基づく回答

公開直後に多い疑問に、2026年10月16日時点の公式情報で答えます。

OpenAI Decisions APIの料金はいくらですか?

gpt-6-luna での入力100万トークンあたり0.10ドルで、出力トークンとキャッシュの読み書きには課金されません。ただし地域処理の割増と長文入力の倍率は掛かり、モデルページでは272Kトークン超の入力で2倍、地域処理で10%増しとされています。この単価は /v1/decisions に限ったもので、同じLunaをResponses APIで呼ぶと出力0.50ドルが加わります。

Structured OutputsとDecisions APIは何が違いますか?

Structured OutputsはJSON Schemaに沿ったオブジェクトを生成させる仕組みで、抽出項目や説明文まで返せます。Decisions APIは候補からの選択・真偽の確率・段階評価だけを返し、候補ごとの確率と confidence が付く点が両者の相違点です。理由の文章が要るならStructured Outputs、確率で人に回すかを決めたいならDecisionsを選びます。

gpt-6-luna以外のモデルは使えますか?

使えません。ガイドとAPIリファレンスのどちらも、対応モデルは gpt-6-luna のみと明記しています。より強いモデルで判定したい場合は、Responses APIで gpt-6-sol などを呼び、Structured Outputsで出力を縛る方法になります。対応モデルの追加予定は公式には書かれていません。

「Responses APIより10倍速い」という数字はそのまま信じてよいですか?

OpenAIの公式の記載は「Responses APIより約10倍速い」という比較だけで、測定条件やミリ秒単位の値はガイドに載っていません。海外記事にはミリ秒単位の数字も出ていますが、公式文書では確認できませんでした。応答時間が要件になるなら、自社の入力の長さと質問数で計測してから設計してください。

OpenAI Decisions APIは日本から使えますか?

ガイドに利用地域の制限は書かれておらず、パブリックベータとして提供されています。ただしデータ所在地と地域処理の対象は米国と欧州だけで、日本国内で処理させる選択肢はありません。国内処理が要件にない検証用途なら、通常のAPIキーで /v1/decisions を呼んで試せます。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.16 テックブログ バーガーキング不正アクセスで約1,118万件の情報漏洩|対象確認・案内メールの真偽と運営側のログ点検
  2. 2026.10.16 テックブログ ソースネクスト不正アクセスで最大2,252万件流出|ログインできない理由・パスワード再設定と会員APIの点検
  3. 2026.10.15 テックブログ リゾートトラスト不正アクセス:会員2.6万件・カハラ横浜3.6万件の対象確認と窓口
  4. 2026.10.15 テックブログ 銀のさら不正アクセス:最大650万件の対象確認と窓口、パスワード変更の手順
  5. 2026.10.16 テックブログ ワラウ不正アクセスで連携トークン流出|Yahoo! JAPAN ID再連携と対象確認

RELATED POSTS 関連記事

目次