OpenAI Decisions API：型付きAI判断がソフトウェアを変える理由

要点：AIソフトウェアに専用の判断エンドポイントが加わる

OpenAIは2026年10月6日、Decisions APIをベータとして発表しました。これは汎用的な文章生成APIより用途を絞り、テキスト、画像、または両方を評価して、ソフトウェアが扱える型付きの答えを返します。公式ガイドでは、条件の成立確率を返すpredicate、固定集合から選ぶchoice、順序付きレベルで評価するscoreの3種類を説明しています。OpenAIは、この種の処理がResponses APIより最大10倍速くなるとしています。

これは生成APIを置き換える機能ではありません。ルーティング、トリアージ、モデレーション、優先順位付け、画像検査など、文章ではなく限定された結果が必要な処理に向きます。まずは 公式Decisions APIガイドを確認し、関連ソフトウェアは BTTCソフトウェアディレクトリで比較できます。

発表された内容

エンドポイントは POST /v1/decisions です。リクエストにはモデル、共通入力、名前付きの質問を含めます。現在の公開ベータでは gpt-6-luna が唯一の利用可能モデルです。質問ごとに評価内容を指定し、必要なら選択肢や順序付きのスコアレベルを定義します。応答にはanswers配列が返り、質問名で結果を識別できます。

重要なのは、証拠と出力形式を分離している点です。顧客の苦情を請求、技術、配送などに振り分けたり、商品画像の損傷を判定したり、文書を重大度で評価したりできます。これらは長い文章ではなく、キュー、ルール、ダッシュボード、ワークフローが消費できる値を必要とします。

条件の真偽にはpredicate、順序のないカテゴリにはchoice、順序のあるレベルにはscoreを使います。独立した質問は同じリクエストにまとめられますが、前の答えで次の質問が変わる場合は別のリクエストにします。

アプリケーション設計への影響

多くのAI製品は今もすべてをチャットとして扱います。試作では便利ですが、本番ではテキストの解析、欠落フィールド、フォールバック、業務アクションへの安全な変換が問題になります。

型付きの結果なら境界を明確にできます。確率をしきい値と比較し、選択肢をキューに対応させ、スコアで人による確認を起動できます。不確実性が消えるのではなく、測定と管理ができる値になります。

説明文、独自JSON、ツール呼び出し、長文が必要なら、Structured Outputsやfunction callingを使うResponses APIが適しています。限定的な分類や順位信号だけが必要なら、専用エンドポイントで遅延と下流コードを減らせる可能性があります。

本番前の四つの確認

1. 観測可能な質問を作る

「良い顧客で優先すべきか」は複数の判断を混ぜています。「請求問題を説明しているか」「期限が書かれているか」に分けましょう。画像でも曖昧な全体評価ではなく、見える基準を指定します。

2. ラベル付き例からしきい値を決める

確率はそのまま業務ルールにはなりません。代表的な例で偽陽性と偽陰性を測り、エラーのコストに合わせてしきい値を決めます。トラフィック、言語、商品、悪用パターンが変わったら再評価します。

3. 根拠とレビュー経路を残す

入力、質問定義、モデル、しきい値、人による上書きを追跡できるようにします。OpenAIの データ管理文書には、/v1/decisionsの保持と地域処理、対象顧客向けのZero Data Retentionが説明されています。機密データを送る前に契約条件を確認してください。

4. 失敗時の経路を決める

レート制限、タイムアウト、壊れた入力、曖昧なケースは通常の問題です。APIが使えない、信頼度が低い、スコアが境界にある場合の処理を決めます。人の確認や不可逆操作を避けるキューが安全な初期値になります。

高速でも自動的に安くなるわけではない

公式ガイドは gpt-6-luna の入力料金を100万トークンあたり0.10ドルと説明していますが、地域処理や長いコンテキストの追加料金が適用されることがあります。再試行、監視、ラベル付け、レビュー、保存、統合、誤ルーティングの費用も計算してください。速いが間違ったチームに送り続けるモデルは、レビューゲートのある遅いフローより高くつく可能性があります。

周辺ソフトウェアも同じです。ログ、再実行、しきい値管理、エクスポート、権限、モデルの提供状況を確認しましょう。デモだけでなく、根拠を示し、部分失敗から復旧し、将来の乗り換えを可能にする製品が必要です。

小さく導入する方法

最初の実験には、返品画像の分類、サポートチケットの振り分け、社内文書の優先順位付けのように、人が正解を確認できる仕事を選びます。入力例と期待する答えを保存し、既存のルールや担当者の判断と比較してください。自動返信、アカウント停止、支払い変更のような戻せない処理へ、いきなり接続してはいけません。

運用後は言語や地域ごとの精度も確認します。短い問い合わせ、長い説明、画像付きの依頼では入力分布が違うため、全体平均だけでは問題を見落とします。回答の分布、低信頼ケース、手動上書き、APIエラー、遅延をダッシュボードに記録し、しきい値を変更した履歴も残しましょう。

データ設計と移行性も評価する

判断だけを保存すると、後から品質を調べることが難しくなります。入力の種類、質問のバージョン、モデル、返された値、適用したしきい値、最終的な人の判断を、組織の保持ポリシーに合わせて関連付けてください。個人情報を必要以上に複製せず、レビュー担当者が確認できる最小限の証拠を残す設計が重要です。

また、ベータ機能の仕様やモデルが変わる可能性を前提にします。質問定義をコードや設定ファイルで管理し、固定したテストセットを定期的に再実行しましょう。結果の形式が変わったときに、静かに誤ルーティングが始まらないよう、スキーマ検証、監視、段階的なロールアウトを用意します。

本番では、変更前後の結果を比較できる評価レポートも用意します。

よくある質問

ベータの挙動と対応モデルは 公式ドキュメントを確認してください。

まとめ

Decisions APIは、言語豊かな仕事を生成APIに、限定的なアプリケーションロジックを型付き判断に分ける流れを示します。ルーティングやトリアージを簡素化できますが、観測可能な質問、測定済みのしきい値、追跡可能な入力、プライバシー確認、安全なフォールバックが必要です。