Decisions APIとは｜現行維持・比較・導入保留の判断

Decisions APIとは何か

OpenAIのDecisions APIは、テキストや画像を文脈として、開発者が定義した質問と有限の回答候補を使う判断用APIです。分類やリクエストの振り分け、エージェントの次の行動の選択が、公式発表で示された用途です。Decisions APIの公式説明

APIとGPT-6 Lunaの違い

Decisions APIは判断用途のAPIで、GPT-6 Lunaは関連する基盤モデルの名前です。APIとは、ソフトウェアからサービスの機能を呼び出すための窓口です。公式発表と上記の投稿は、Decisions APIがGPT-6 Lunaの知能を使うと説明しています。OpenAI公式発表

入力・質問・回答候補と出力の範囲

文脈、質問、回答候補を用意し、得られた回答を業務上の判断に使う、という範囲が公式説明から確認できます。返却フィールドや例外の形式まで、今回確認した公開資料で確定したわけではありません（2026年10月1日確認）。公式発表の入力と用途／公式APIリファレンス

たとえば問い合わせ文を文脈にして、担当部署の候補から振り分け先を判断する業務を検討できます。これは本記事が考えた業務例です。候補にない内容や複数部署にまたがる問い合わせをどう扱うかは、利用側で先に決める必要があります。

分類・振り分けは、どの方式を選ぶか

OpenAIのDecisions APIを分類業務で検討するときは、入力、回答候補、誤りの影響、既存方式の不足をそろえ、維持・比較・保留を判断します。以下の選択基準は、公式仕様を業務条件へ当てはめた筆者の判断です。

現行方式と比べる条件

方式を比べる前に、何を入力し、どの候補へ分け、誤りが起きると何に影響するかを決めます。問い合わせの担当候補を選ぶだけの業務と、その回答で返金まで実行する業務では、必要な確認が変わります。まず現行方式の困り事を1つ具体化してください。

Structured Outputsとは、モデルの出力を指定したJSONの構造へ合わせる機能です。JSONは、項目名と値などでデータを表す形式です。回答候補を列挙する指定もできますが、形式が合っていても内容の誤りは起こり得ます。Structured Outputs公式ガイド

JevはTypeSafeが提供する判断用途のモデルで、公式ドキュメントではSystem Oneの位置づけや、回答の確率・信頼度に関する出力を説明しています。画像の扱いを含む対応範囲は、Decisions APIと同一ではありません（2026年10月1日確認）。TypeSafe公式のJev紹介／Jev公式モデル仕様

維持・比較・本番保留の優先順

複数の行に該当する場合は、①Decisions APIの利用資格・専用料金・上限・データ条件が未確認なら同APIの本番導入を保留、②誤りが送信・返金・権限変更へつながるなら人の確認を含む工程を優先、③残る業務を現行方式の不足に応じて維持または比較、の順で判断します。比較候補の整理は、Decisions APIの本番導入を保留したまま進められます。

入力・候補・誤りの影響をそろえ、最後の列まで確認してください。スマホでは表を横へスクロールできます。

根拠：Decisions API公式発表、構造化出力の公式仕様、Jev公式モデル仕様。専用料金・上限・返却仕様の確認範囲は公式料金表とAPIリファレンスです（2026年10月1日確認）。

各方式を同じ入力と判定基準で評価し、費用と誤りの影響も比べてから採用を決めてください。

料金・上限・利用資格は何を確認するか

OpenAIのDecisions APIは、2026年9月29日に限定プレビューとして発表されましたが、専用料金と一般提供の完了は今回の確認では未確認です。発表時の予定と、自分のアカウントで使える条件を分けて確認します。提供予定を示した公式発表／発表時の限定プレビューを案内する公式X投稿（2026年10月1日確認）

提供予定と自分の利用資格

「近日中に広く提供する」という発表だけで、全アカウントの利用開始を判断することはできません。今回確認した発表と変更履歴からは、一般提供の完了や個別の参加資格を確定できませんでした（2026年10月1日確認）。発表時点の提供状況／OpenAI公式変更履歴

検討を進めるときは、自分のAPIアカウントへ届いた提供案内や参加条件を確認します。ChatGPTの契約があることだけで、Decisions APIの利用資格があるとは扱いません。

専用条件と通常のLuna仕様の違い

Decisions APIの費用判断には、専用の料金と課金単位が必要です。今回確認した公式料金表とAPIリファレンスでは、専用単価、無料・試用枠、質問数・候補数・利用回数などの上限を確定できませんでした（2026年10月1日確認）。OpenAI公式API料金表／公式APIリファレンス

通常のGPT-6 Lunaの料金、入力・出力上限、モデルの選択条件は、Decisions APIの専用条件と同じだとは確認できていません（2026年10月1日確認）。コンテキスト上限は一度に扱える情報量で、出力上限とは別です。通常モデルの全体像は、通常のSol・Lunaの利用場所と料金の考え方で補えます。通常のLunaの公式仕様

試用を検討する前に何を確認するか

OpenAIのDecisions APIの試用を検討する開発者は、利用資格と契約条件を確認し、入力、質問、回答候補、誤りの扱いを整理してから評価方法を決めます。着手前の確認順で、試用へ進める条件を整理します。

利用資格・契約・データの扱い

最初に確認するのは、自分が使える提供条件と、投入するデータの扱いです。日本は一般のOpenAI API対応地域に含まれますが、Decisions APIのプレビュー参加資格まで同じ条件だとは確認できていません（2026年10月1日確認）。OpenAI APIの公式対応地域

1. 利用資格と契約を確認する。提供案内、参加条件、本番利用の制限を確認します。一般のサービス契約とプレビュー固有の条件を分けて読んでください。OpenAIサービス契約／OpenAIサービス利用条件
2. 入力データの扱いを確認する。学習利用、保存、削除、必要な管理条件を確認します。専用条件が不明な間は、実データの投入を保留する判断も必要です。OpenAI公式データ管理ガイド

一般APIでは、明示的な参加をしない限り入出力を学習に使わないと説明されています。通常の不正利用監視ログは原則として最長30日で、例外やエンドポイントごとの保存条件もあります。Decisions API固有の保存・削除・Zero Data Retentionの適用は、今回の公開資料では未確認です（2026年10月1日確認）。Zero Data Retentionとは、承認や対象条件を伴うデータ保持の管理設定です。一般APIの学習利用と保持条件

質問・回答候補と誤りの評価条件

評価を始める前に、正しい振り分けの条件と、判断できない入力の扱いを決めます。候補から1つ選べる形にするだけでは、業務上の正しさを測れません。問い合わせなら、候補外・複数部署・情報不足の例も評価対象へ入れます。

3. 入力・質問・候補を整理する。担当部署を分けるのか、処理種別を分けるのかを1つ決めます。候補が重なる場合や、必要な情報がない場合の運用も書き出します。
4. 評価条件をそろえる。同じ入力と正解の扱いで現行方式と比較します。誤りが後工程へ与える影響と、人へ戻す条件を含めて判断してください。

この確認順は筆者の業務設計案です。Decisions APIが「保留」や人への確認を自動で返す仕様を示しているわけではありません。

回答をどこまで自動処理に使うか

OpenAIのDecisions APIが返す回答は分類や次の行動の選択に利用できますが、業務処理の実行権限まで与えるものと解釈しないのが本記事の設計方針です。回答後の処理を組み込む場合は、形式・正しさ・実行許可を別々に確認します。公式が示す判断用途

出力形式・正しさ・実行許可の違い

形式に合う回答、業務上正しい回答、実行してよい処理は、それぞれ確認する対象が違います。Structured Outputsも内容の誤りまで防ぐものではなく、拒否や未完了の扱いが必要です。候補内の担当名が返っても、その担当が適切かは別に評価します。構造化出力の制約と注意

Function callingとは、モデルが返す関数呼び出しをアプリ側のコード実行につなぐ仕組みです。OpenAIの公式ガイドでも、モデルの応答を受けた後にアプリ側でコードを実行する工程を示しています。この一般的な工程の区別を、分類後の自動化にも当てはめて考えます。Function calling公式ガイド

誤りが起きたときに止める条件

取り消しにくい処理は、回答の形式だけを根拠に自動実行しない、という基準を置きます。たとえば送信・返金・権限変更は、許可範囲と確認者を決めてから接続します。回答候補を選ぶAPIの採用と、実行権限を広げる判断を同時に進めないようにします。

候補外の入力、必要情報の欠落、既存の業務ルールとの衝突がある場合は、人へ戻す条件を利用側で設計します。専用の返却仕様や例外処理が確認できるまでは、信頼度の閾値や自動保留の機能を前提にしません。