できること
型付きの回答を得る
テキスト・画像・JSON を評価し、条件が真である確率、固定の選択肢からの選択、ルーブリックに対するスコアのいずれかを型付きの回答として受け取れます。
複数の質問を一度に
同じ questions 配列に独立した質問を並べ、共有の入力をまとめて評価できます。質問ごとに異なる種類を使えます。
会話や JSON を評価
会話履歴を input に渡して文脈の中でリクエストを評価できます。input_json を使えば、構造化データを文字列に変換せずに渡せます。
機能解説
概要
回答の形は、条件が真である確率、固定の選択肢からの選択、ルーブリックに対するスコアの 3 つです。Responses API と比べて約 10 倍の速さで回答を返します。返された回答は、アプリケーションの中でコンテンツの分類、リクエストの振り分け、作業の優先順位付けに使えます。
リクエストと回答の仕組み
レスポンスには answers 配列が含まれます。各質問に一意の name を付けると、API はその名前をレスポンスに返すため、どの回答がどの質問に対応するかを識別できます。
Decisions が返すのは型付きの回答までです。回答に応じた処理は、アプリケーション側で実行します。入力としてファイル、音声、アイテム参照はサポートされていません。
コードを書く前に、Playground で質問と入力を試すこともできます。
質問の種類
- 条件の確率 (predicate): 条件が真である確率を返します。
- **
choice**: 指定した選択肢から 1 つの値を選びます。回答には、選ばれた値 (choice)、選択肢ごとのprobabilities配列、confidenceフィールドが含まれます。部署のような順序の無いカテゴリに使います。 - **
score**: 2〜10 段階の順序付きのlevelsに照らして入力を評価します。深刻度のような順序のあるレベルに使います。返されるscoreは、0 から始まるレベル番号を確率で重み付けした平均のため、レベルとレベルの間の値になる場合があります。
choice と score はどちらも、離散的な選択肢に対する確率を返します。
入力に使えるデータ
- 会話履歴: メッセージと、関数呼び出しやカスタムツールの呼び出し・出力を順に並べて
inputに渡します。各ツール出力はcall_idで対応する呼び出しと結び付けます。 - JSON:
input_jsonのコンテンツパートを使い、JSON のオブジェクトまたは配列をdataに入れます。ユーザーメッセージの中で、テキストや画像のパートと並べて使えます。メッセージ内のinput_jsonはuserロールでのみサポートされています。dataの中のroleやimage_urlといったキーは通常のデータとして扱われ、メッセージの作成や画像の取得は行われません。 - 画像: base64 のインライン data URL か、公開されている HTTP または HTTPS の URL で渡します。
file_idによる入力はサポートされていません。 - 質問ごとの画像: 質問の
instructionsを、input_textとinput_imageのパートからなる空でない配列にすると、質問ごとに別の画像を渡せます。predicate・choice・score のどの質問でも使えます。
プロンプトキャッシュと使用量の確認
プロンプトキャッシュを使うと、繰り返しのリクエストで共有の input のうち一致する先頭部分を再利用し、割引されたキャッシュ読み取り料金を受けられます。questions の中の内容は、再利用される先頭部分には含まれません。
既定では、共有の input の末尾に暗黙のキャッシュの区切り (breakpoint) が置かれます。再利用する先頭部分は 1,024 トークン以上が必要です。
キャッシュを細かく制御する設定は次のとおりです。
prompt_cache_key: 呼び出し側が指定したキーで、キャッシュの再利用を分けます。prompt_cache_breakpoint: {"mode": "explicit"}: 共有のinputのテキストや画像のパートに付けて、区切りの位置を指定します。prompt_cache_options.modeを"explicit"にすると、印を付けた区切りだけを使います。このモードで区切りの印が無いリクエストは、プロンプトキャッシュを使いません。質問の instructions の中では区切りはサポートされていません。
キャッシュの読み取りは usage.input_tokens_details.cached_tokens、書き込みは usage.input_tokens_details.cache_write_tokens で確認できます。
組織全体の Decisions のトークン使用量とリクエスト数は、GET /v1/organization/usage/decisions で取得できます。認証には admin API key と api.usage.read 権限を使います。期間と集計の単位 (bucket width) を選び、プロジェクト・API キー・モデルで絞り込みやグループ化ができます。
使い方
リクエストは model・input・questions の 3 つの部分で構成されます。
POST /v1/decisionsにリクエストを送ります。モデルには、現在サポートされている唯一のモデルであるgpt-6-lunaを指定します。inputに、質問に共通する材料を入れます。テキストの文字列か、メッセージ・ツール呼び出し・ツール出力を順に並べた配列を使います。questionsに評価したい内容を指定します。各質問の種類、指示 (instructions)、許可する選択肢やスコアのレベルを含めます。
利用シーン
問い合わせやコンテンツを、決めた部署やカテゴリに分類する場面に使えます。
受け付けたリクエストを、回答に応じて処理先へ振り分ける場面に向いています。
深刻度のような順序のある基準で作業を採点し、優先順位を付ける場面に使えます。
商品写真について、破損の有無の確認と商品カテゴリの分類を 1 回のリクエストで行う場面に向いています。
Claude・Anthropic の対応する機能
公式リリースノートでは、対応する発表を確認できていません (2026-11-03 時点)。 これは、対応する機能が存在しないことを示すものではありません。
これまでの変更
Decisions API が
gpt-6-lunaで一般提供になりました。あわせて、リクエスト間で共有する入力のキャッシュによるプロンプトキャッシュ割引、個々の質問の指示への画像の追加、input_jsonによる構造化データの直接の受け渡しが加わりました。1 リクエストあたりの質問数の上限は、パブリックベータ時の 200 から 400 に引き上げられました。GPT-Live に Decisions のネイティブ統合が追加されました。Live はネイティブ委任で Decisions を直接呼び出せるほか、入力・出力の文字起こしの差分が届いた時点で decisions をトリガーすることもできます。
Decisions API が
gpt-6-lunaとともにベータとして公開されました。テキストと画像を型付きの回答に変換し、Responses API より 10 倍速く動作します。