Decisions APIが公開ベータに。料金と3つの判断形式、結果を検収する手順

10月6日付の公式更新履歴は、GPT-6 Lunaを使うDecisions APIのベータ公開を案内しています。前回の記事で扱った限定プレビューから進み、専用の料金と呼び出し形式が公開されました。一般提供の完成版ではなく、公開ベータです。

今回は新仕様を整理し、返ってきた結果を仕事に渡す前の確認方法まで扱います。製品へのAPI呼び出しは実施していません。後半の教材は編集部が作った架空データを検算するもので、日本語の分類精度や速度の実測ではありません。仕様の確認日は2026年10月7日です。

Decisions APIでは、判断材料となる入力と質問を渡します。質問ごとに使う型を選び、条件に当てはまる度合い、分類先、段階評価を受け取ります。現在の対象モデルはGPT-6 Luna、送信先は専用のPOST /v1/decisionsです。公式ガイド

たとえば「請求担当へ回す」と「業務が止まっている」を一つの分類へ押し込めると、担当と緊急度が混ざります。担当はchoice、影響はscoreとして別々に定義すると、それぞれの誤りを追いやすくなります。独立した質問は同じ入力にまとめられますが、最初の答えを見て次の質問を決める処理は別の要求にします。

一方、「お客様へ送る丁寧な返信文も書いてほしい」まで求めるなら、判断結果を別の文章生成工程へ渡す設計が必要です。自由な項目を持つJSONや説明文が必要な場面は、Responses APIと構造化出力の用途として分けて考えると整理できます。

専用ガイドの料金欄では、入力100万トークン当たり0.10米ドルです。出力、キャッシュの読み取り・書き込みには課金しないと説明されています。ただし、長文入力と地域処理の割増条件は適用されます。通常のLunaの料金表を、そのままこの専用窓口の総費用として使わないようにします。

費用の目安は、課金対象の入力が1件1,000トークンなら、1万件で計1,000万トークン、基本単価では1米ドルです。これは料金式に仮の件数を入れた計算で、教材を送った実際の消費量ではありません。質問文や画像を含む使用量は、実行時のusageと請求を確かめてください。

公式の対応国一覧には日本があります。ただし、日本から接続できることは、日本国内で処理・保存されることを意味しません。社内データを扱う際は、地域設定や契約条件を先に確かめます。

ここでは架空の社内システムを想定します。入力は「全員がCSVを出せないが、別形式のダウンロードは使える」という問い合わせ。担当はシステム側、影響は「代替手段あり」と、人が理由を説明できるものを選びます。

次はrequest.jsonとして保存する例です。担当には、情報不足を無理に分類しないためのreviewを設けました。これは利用側が作った選択肢で、API固有の自動保留機能ではありません。

利用権限と課金条件を確認し、APIキーを環境変数に設定した環境では、次の形で送信できます。記事ではこの送信は実行していません。教材には自動送信するプログラムを含めていません。

質問名は後で返答を照合するための目印です。同じ資料を読ませても、担当と影響を取り違えて記録すると、モデルの問題なのか実装の問題なのか判別しづらくなります。APIリファレンスに沿って、質問と答えを対応付けて扱います。

choiceには候補別の確率とconfidenceが付きます。ここで「confidenceが0.9だから、90%の確率で正しい担当だ」と決めるのは早計です。自社の正解付きデータで実際の一致率を調べる確率の校正が必要です。今回確認した公式資料には、このconfidenceを他社製品と同じ数式で算出するという説明はありません。

scoreも、最も確率の高い段階をそのまま返すものではありません。教材用に作った分布が「支障なし0.2、代替手段あり0.7、作業停止0.1」なら、0×0.2＋1×0.7＋2×0.1＝0.9です。「影響が90%ある」という意味ではなく、0〜2の段階番号上の平均です。段階の定義を変えれば、その数値の読み方も変わります。

また、APIは質問ごとにrefusalを返す場合があります。これを「支障なし」の0として埋めると、答えが得られなかった状態を正常な判定へ変えてしまいます。拒否、欠落、形式の不整合は、人が確認する経路へ分けて残します。返却型の公式仕様

オフライン検収教材をダウンロードできます。要求例、編集部作成の応答抜粋、検収用Python、答えと空の記録表を同梱しました。Pythonの標準機能だけを使い、ネット接続・APIキー・追加課金は不要です。

展開したフォルダでpython3 verify.pyを実行すると、各例が「形式不整合」「人が確認」「担当候補として整理」のどれになるかを表示します。これは受け取る側の確認ロジックの試験です。人工的な応答に実測のラベルを付けたり、モデルの正解率へ換算したりしないでください。

教材では便宜上、選んだ候補の確率が0.8未満、または次点との差が0.2未満なら人へ戻します。reviewとrefusalも人へ戻します。この数値は練習用で、OpenAIの推奨値でも、本番で安全と検証された値でもありません。誤送付による手戻りと、人が読む件数を記録し、未使用の評価データで調整する必要があります。

最も大事なのは、高い確率で間違える例も残すことです。形式検査だけでは、その文が本当に請求の相談なのかを判断できません。教材の答えをモデルへ渡さず、人が決めた期待結果と後から照合する工程を別に持たせます。「APIから成功応答が来た」と「正しい仕事ができた」を分けるためです。

画像を使う場合、現行仕様はbase64を含むdata URLを要求します。外部画像URLやfile_idを、そのまま渡すことはできません。前回の画面付き問い合わせ教材を使うなら、対応する画像形式への変換と読み取り内容の確認から始めます。画像が付くというだけで、細かな日本語表示を正しく読めるとは限りません。

公式の「Responses APIより約10倍速い」は開発元が示す説明です。自分の処理で見るべきレイテンシは、画像の準備、送信、結果の検収を含む待ち時間。さらに人が修正する時間も掛かります。同じ入力・質問・計測区間をそろえずに、Jevや別の判断モデルへの速度優位として読み替えることはできません。

今回明らかになった仕様を使うと、まず「答えを受け取った後に何を確かめるか」を具体化できます。少量の架空入力から始め、正解付きの未使用データを増やす。自動処理を増やす判断は、分類の一致だけでなく、人へ戻した件数と見逃した件数を確かめてから行います。判断モデル全体の違いは比較記事も参照してください。