OpenAI Decisions APIとは？分類・確率・スコアの使い分けと実装例

Decisions APIは、入力に対する分類や採点を、決まった型で受け取るためのAPIです。自由な回答文を作る工程と、次にどの処理へ送るかを決める工程を分けて設計できます。2026年10月6日に公開ベータとして提供が始まり、2026年10月22日（日本時間23日）に一般提供（GA）へ移りました。対応モデルはgpt-6-lunaだけで、料金は入力100万トークンあたり0.10ドルです。出力トークンには課金されません。

この記事は、2026年10月23日にOpenAIの公式資料と発表記事を確認して更新しました。確認した資料は、Decisions guide、API changelog、Create a decisionの仕様、Connect voice to Decisions、料金表、Structured model outputs、OpenAIの発表記事です。編集部はDecisions APIを実際に呼び出していません。料金・速さ・判定の精度は実測しておらず、記事中のリクエスト例と期待値は、公式の仕様に沿って編集部が作った教材です。

Decisions APIの一般提供（GA）で変わったこと

一般提供と同時に、公式ガイドに「公開ベータ以降に追加された機能」がまとめられました。1回のリクエストに入れられる質問は、ベータ中の200問から400問に増えています。主な追加は次のとおりです。

この記事の以前の版では、ベータ時点の仕様に沿って「画像はdata URLで渡す」「ツール呼び出しは入力の対象外」と説明していました。一般提供の時点では上の表のとおり変わっているため、該当の節を書き直しています。ベータ中に作った処理を見直すときは、画像の渡し方と、1リクエストにまとめる質問の数から確認すると差分を把握しやすくなります。

Decisions APIが向いている処理

問い合わせの振り分け、条件に当てはまるかの確認、段階別の採点など、答えの範囲を先に定義できる処理が主な用途です。OpenAIの発表では、エージェントが「続ける」「やり直す」「確認を求める」のどれを選ぶかを決める例も挙げられています。エンドポイントはPOST /v1/decisionsです。公式ガイドは、同じgpt-6-lunaをResponses APIで呼ぶ場合と比べて約10倍速いと説明しています。公式ガイド

自分で決めたJSONの形で項目を抜き出したり、説明文を書かせたりしたいなら、Responses APIのStructured Outputsが向いています。モデルに道具を呼ばせたい場合は、関数呼び出し（function calling）の範囲です。Decisions APIは答えを返すだけで、選ばれた処理を実行するのはアプリ側です。

たとえば顧客の文章から「配送の相談らしい」と判定する工程と、注文情報を確認して返信する工程は分けられます。分類の結果だけでは、注文の事実、返金の可否、顧客へ送る文面まで確定しません。この記事では、社内の担当へ振り分ける場面を編集部の教材例として設計します。

Decisions APIの料金は、入力トークンだけ

gpt-6-lunaで/v1/decisionsを使う場合、キャッシュされていない入力は100万トークンあたり0.10ドルです。出力トークンには課金されません。キャッシュの読み込みと書き込みは、gpt-6-lunaの標準のプロンプトキャッシュ料金と同じと説明されています。

表の値は、公式料金表のうち、標準の処理区分で短いコンテキストを使う場合のgpt-6-lunaの料金です。長いコンテキストでは入力料金に倍率がかかり、地域を指定した処理には追加料金が上乗せされます。どちらも表の値には含まれていません。Decisions以外の呼び出し（Responses APIなど）でgpt-6-lunaを使う場合は、通常のモデル料金です。料金は変わることがあるため、使う前に公式の料金表を確認してください。

共通の前置きをキャッシュで使い回す

判定の基準になる資料や基準画像をinputに置き、質問だけを替えて何度も送る場合は、共通部分がプロンプトキャッシュの対象になり、2回目以降は割引の料金で読み込まれます。既定ではinputの末尾がキャッシュの区切りになるため、リクエストの形を変えなくても対象になります。使い回す部分は1,024トークン以上必要で、questionsの中身（質問ごとの画像を含む）はキャッシュされません。

キャッシュが効いたかは、応答のusage.input_tokens_details.cached_tokens（読み込み）とcache_write_tokens（書き込み）で確認します。どちらもusage.input_tokensの内訳なので、input_tokensにさらに足すと二重に数えることになります。

料金とキャッシュ以外の利用条件も確認しておきます。データを保持しない設定（Zero Data Retention）とHIPAAに沿った利用は、条件を満たす顧客だけが使えます。地域を指定した処理は、米国と欧州（EEA＋スイス）で選べます。なお、使用量APIのリクエスト数は、質問をいくつ入れても1リクエストにつき1回です。

Decisions APIの3つの型：predicate・choice・score

choiceとscoreの答えには、選択肢ごとの確率と、別項目の確信度（confidence）も付きます。scoreの段階は2〜10個で、低い順に並べます。

「緊急度」を扱う場合は特に、単なるカテゴリなのか、軽い順に並ぶ段階なのかを決めます。「技術」「請求」「配送」は大小関係のない分類です。一方、「無傷」「軽微」「大きな損傷」には順序を定義できます。この区別が、返ってきた数値の解釈を変えます。

外箱に目立つ損傷なし

軽微な損傷

大きな損傷

公式画像で見たいのは、段階をどのように言語化するかです。箱に傷があることと、中の商品が使えないことは同じではありません。画像で見えない商品内部まで判定させるのではなく、「外箱に見える損傷」など観察できる対象を質問に含めます。

Decisions APIの最小実装：問い合わせの種類を返す

次は、Bash・zshで使う、架空の問い合わせを1件分類するリクエスト例です。個人情報や注文番号を使わず、結果が想定した型で返るかを確認するところから始められます。APIの利用権限と利用料は、ChatGPTの画面の契約とは分けて確認してください。

curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @- <<'JSON'
{
  "model": "gpt-6-luna",
  "input": "注文した商品がまだ届きません。配送状況を知りたいです。",
  "questions": [{
    "type": "choice",
    "name": "support_route",
    "instructions": "問い合わせの主な目的を分類してください。配送は到着日や配送状況、請求は支払いや請求書、技術は製品の操作や不具合です。複数の目的があり一つに絞れない場合や情報不足はotherにしてください。",
    "choices": [
      {"value": "shipping", "description": "配送状況や到着日の問い合わせ"},
      {"value": "billing", "description": "支払いや請求書の問い合わせ"},
      {"value": "technical", "description": "製品の操作や不具合の問い合わせ"},
      {"value": "other", "description": "複数の意図、情報不足、その他"}
    ]
  }]
}
JSON

APIキーは環境変数で扱い、記事やリポジトリへ直接書きません。この入力の期待分類はshippingです。ただし、ここに示した期待値は教材の設計値で、実APIの応答ログではありません。

API仕様では、結果にrefusalが返る場合もあります。返却された型と質問名を確認してから処理し、成功時の形を前提に配列の値だけを読む実装にしないことが必要です。Create a decisionの仕様

応答のanswersでは、nameがsupport_routeで、typeがchoiceであることを照合します。そのうえで選択結果のchoiceと確信度のconfidenceを読みます。質問が増えても、配列の位置だけで意味を決めないようにします。

Decisions APIに業務データをJSONのまま渡す

一般提供で追加されたinput_jsonを使うと、問い合わせ本文と注文記録のような構造のあるデータを、文字列に変換せずに一緒に渡せます。次は、二重請求の訴えが注文記録と合っているかを確かめる、編集部の教材例です。金額や内容は架空です。

{
  "model": "gpt-6-luna",
  "input": [{
    "role": "user",
    "content": [
      {"type": "input_text", "text": "問い合わせを、注文記録と照らし合わせて判定してください。"},
      {"type": "input_json", "data": {
        "ticket": {"body": "同じ注文で2回請求されています。返金してください。"},
        "order": {"charges": [4900, 4900]}
      }}
    ]
  }],
  "questions": [{
    "type": "predicate",
    "name": "duplicate_charge",
    "instructions": "問い合わせは、注文記録で裏付けられる二重請求を訴えていますか？"
  }]
}

上のJSONをリクエストの本文としてPOST /v1/decisionsへ送ると、duplicate_chargeの答えとして「当てはまる確率」が返ります。input_jsonを使えるのはuserのメッセージの中だけです。dataの中にroleやimage_urlという名前のキーがあっても、ただのデータとして扱われ、メッセージの追加や画像の読み込みは起きません。

確率が高くても、それだけで返金を実行しないでください。Decisions APIは判定を返すだけなので、返金するかどうかは自社のルールと担当者の確認で決めます。

Decisions APIの画像入力と、複数の質問の分け方

画像は、base64のdata URLか、公開されたHTTP/HTTPSのURLで渡します。file_idでの指定には対応していません。ファイルの入力、音声の入力、以前のやり取りの項目を参照する入力（item reference）も使えません。音声の内容を判定したい場合は、文字起こしをしてからテキストで渡すか、次に説明するGPT-Liveとの連携を使います。

質問ごとに別の画像を見せたい場合は、その質問のinstructionsを、input_textとinput_imageの配列にします。たとえば基準の画像Aをinputに置き、比べたい画像B・C・Dを1問に1枚ずつ入れれば、「この画像は画像Aを加工したものか」を画像ごとに判定できます。質問に入れた画像も、リクエスト全体の画像の上限に数えられる点に注意してください。

1回のリクエストには1〜400問を入れられます。同じ入力に対する独立した質問はまとめられますが、「カテゴリが請求の場合だけ、この条件を判定する」のように前の結果へ依存する質問は、リクエストを分けます。質問に名前を付けておくと、後から順番が変わっても記録を読みやすくなります。

分類後の処理まで設計する

分類の正答率だけでは、業務に使えるか判断できません。誤分類したときに誰が気づくか、分類できないものがどこに残るかを決めます。以下は編集部が提案する運用設計です。

「確信度0.8以上なら自動処理」のような値を、すべての業務へ共通適用するのは避けます。配送と請求を取り違える損失、見落としたときの対応時間などを踏まえ、自分たちの正解付きデータで基準を決めます。外部送信を伴う処理なら、分類の導入と送信の自動化は別段階で評価します。

Decisions APIを試す前に用意する評価用データ

まずは担当者同士で判断が一致する例と、判断が割れる例を分けます。人が同じ基準で分類できない状態では、APIの出力だけを見ても改善点が分かりません。評価用の入力は、機密情報を除いた架空文や、利用許可のある記録から用意します。コードを書く前に、公式のDecisions Playgroundで手元の文章や画像を入れて、質問の書き方を試すこともできます。

1. カテゴリごとに明確な例を用意する。
2. 「届かないので返金してほしい」など、複数の意図を持つ例を入れる。
3. 挨拶だけ、添付への言及だけなど、情報不足の例を入れる。
4. 正解分類と、迷った場合の扱いを人が決める。
5. モデルの結果と照合し、誤分類の種類と人の確認件数を数える。
6. 判定の文言を変えたら、同じ入力で再評価する。

採点の例なら、「0＝外箱に目立つ損傷なし」「1＝小さなへこみ」「2＝破れや大きな変形」のように、段階の意味を具体化します。商品自体の安全性を判断するなど、写真だけで分からない評価は分けてください。scoreの小数をそのまま整数のランク名として表示する場合も、丸め方の設計が必要です。

6件の小さな評価データから、分類基準を点検する

以下は、この記事の問い合わせ分類に合わせて編集部が設計した架空データです。APIの出力ではなく、事前に決める期待値の例です。複数の意図を持つ入力はotherへ送る、という本文のルールに合わせています。

最初の3件だけで評価すると、はっきりした質問には強いが、情報不足でも分類してしまう問題を見落とします。D04をどのカテゴリへ送るべきか担当者間で意見が割れる場合は、モデルを調整する前に業務ルールを決めてください。

結果は正答数だけでなく、「otherに送るべきものを断定した」「technicalをbillingへ送った」など、誤りの種類で残します。誤分類したときの影響が違うため、全カテゴリを一つの正答率にまとめるだけでは導入判断に不足します。

分類を実装するときの処理順と、未処理の残し方

1. 入力に内部IDを付ける
2. 利用する分類ルールの版を記録する
3. APIへ送る
4. 通信結果と応答の型を確認する
5. 対象の質問名に対応する回答を探す
6. 許可した分類値か確認する
7. 担当キューまたは人の確認キューへ登録する
8. 登録後の状態を読み直し、処理済みIDを記録する

分類が返っていても、担当キューへの登録に失敗すれば、問い合わせはまだ処理途中です。再開時は内部IDで登録済みかを調べ、同じ問い合わせを二重登録しないようにします。通信エラー、拒否、想定外の型は、既定の担当へ黙って流さず未処理として残してください。

この処理順は実装設計の例であり、APIが業務キューへの登録を自動で行うという意味ではありません。まず分類だけを既存業務と並行して試し、人の判断と比較してから、書き込み範囲を広げると検証しやすくなります。

Decisions APIとResponses API、どちらを選ぶ？

先に出力の完成形を書き出してみてください。「担当カテゴリを一つ返す」ならDecisionsを検討できます。「問い合わせを要約し、必要事項を抽出して返信案も書く」なら、複数の出力や生成文が必要です。後者はStructured Outputsなどの設計が候補になります。

Codexへ開発を頼む場合は、APIをつなぐ依頼に加えて、失敗時の扱い、評価用データ、入力の記録方法、既存システムへ書き込む範囲を渡します。共通の開発ルールはAGENTS.mdに、繰り返す評価手順はSkillsに整理すると、変更時に同じ確認を行いやすくなります。

Decisions APIを音声アプリで使う（GPT-Live連携）

音声対話のGPT-Liveには、Decisions APIを直接呼ぶ連携が加わりました。使い方は2つです。1つは、Liveが「アプリで処理できる依頼だ」と判断したときに、Decisionsに次の動作を選ばせる方法です。選択肢はsession.delegationに設定しておきます。もう1つは、利用者やLiveの発話の文字起こしが届くたびに判定を走らせる方法で、session.triggersに設定します。Connect voice to Decisions

公式ガイドでは、車の音声アシスタントの例が紹介されています。運転している人が「ちょっと寒い」と話すと、Decisionsが選択肢の中から「車内の温度を上げる」を選びます。OpenAIの発表では、話し手の言葉に合わせてアバターの表情を選ぶ例もあります。どちらも、Decisionsが選ぶのは「どの動作にするか」までで、実際に温度を変えたり表情を動かしたりするのはアプリ側です。

Decisions APIのよくある質問

これだけで顧客対応を自動化できますか？

分類だけでは顧客情報の確認や返答内容の確定はできません。まず担当の振り分けや確認の優先順位に使い、業務の結果と照合してから次の範囲を検討します。

速さの公式説明を、そのまま導入効果として使えますか？

使えません。API単体の比較と、入力準備、通信、人の確認まで含めた処理時間は別です。実際の業務効果は、同じ入力群と同じ終了条件で測定します。

出力が無料なら、質問を増やすほど得ですか？

得になるとは限りません。課金されるのは入力トークンで、質問の指示文や質問ごとの画像もリクエストの一部として送ります。質問を増やす前に、判定に必要な質問だけに絞れているかを評価用データで確かめてください。共通の資料を何度も使う場合は、キャッシュが効く形になっているかも確認します。