Decisions APIとは？OpenAIの高速な意思決定レイヤーを解説

what is decisions api と検索しているなら、短い答えはこうです。OpenAI Decisions APIは、ソフトウェアの中で小さく範囲の決まった判断を行うための限定プレビューAPIです。汎用モデルに文章を書かせてから解析するのではなく、開発者が質問を定義し、コンテキストを渡し、有限の回答候補から選ばせます。

そのため、コンテンツ分類、リクエストのルーティング、ツール呼び出しのゲート、AI Agentループの次のステップ選択に向いています。一般的なチャットモデルや推論モデルの代わりではありません。アプリケーションの状態と決定論的なコードの間に置く、より狭い意思決定レイヤーです。

OpenAIは2026年のDevDayでDecisions APIを紹介しました。公開されたローンチ報道では、GPT-6 Lunaの専用バージョン、テキストまたは画像コンテキスト、事前定義された回答、限定プレビューとしての提供が説明されています。また、約150ミリ秒の応答時間と、通常のGPT-6 Luna呼び出しに対して約10倍の高速化も報告されています。これらはローンチ時の報道値であり、SLAの保証ではありません。

この記事では、この概念を説明します。ただし、第三者によるローンチ報道を安定したAPIリファレンスとして扱いません。プレビューの契約、料金、制限、アクセス条件は変更される可能性があります。重要なワークフローに組み込む前に、最新のOpenAIドキュメントとアカウント画面を確認し、ここで示す設計と評価の原則を出発点にしてください。

目次

• Decisions APIを一文で説明すると
• 意思決定APIとChat APIの違い
• 意思決定ループはどのように動くか
• Decisions APIは何に使えるか
• 統合はどのような形になるか
• OpenAI Decisions APIとJevの違い
• AI Agentのどの層に置くべきか
• レイテンシ、コスト、信頼度
• 本番前に確認すべきこと
• よくある質問

Decisions APIを一文で説明すると

Decisions APIは、アプリケーションのコンテキストと範囲を限定した質問を受け取り、ソフトウェアが利用できる構造化された選択結果を返す、意思決定向けのモデルインターフェースです。

重要なのは「範囲を限定する」ことです。「この顧客に役立つ回答を書いてください」は自由生成のタスクです。一方、「このチケットをどの承認済みキューに送るか」は有限の回答空間を持ちます。「このツール呼び出しに人間の確認が必要か」も、「確認が必要」の意味をアプリケーションが定義していれば限定された質問になります。

基本的な抽象化は次の通りです。

decision = f(state, question, allowed_answers)

出力は読者向けの完成した文章ではなく、周囲のプログラムが利用するシグナルです。プログラムはレスポンスを検証し、権限を確認し、業務ルールを適用し、結果を記録し、アクションが許可されるかを判断し続けます。

公開されたローンチ情報では、このプレビューは高速な分類、ルーティング、Agentの次のアクション選択を対象とし、テキストまたは画像コンテキストと、開発者が定義した有限の回答を扱います。OpenAIが正式なリファレンスを更新するまでは、具体的なリクエストとレスポンスのスキーマを暫定的なものとして扱うべきです。

意思決定APIとChat APIの違い

多くのモデル統合はChat型です。メッセージを送り、自由形式のテキストを受け取ります。説明、下書き、要約、オープンな推論が必要なプロダクトでは、この柔軟性が役立ちます。しかし、1日に何千回も実行される制御ループの中では、Chat型は必ずしも便利ではありません。

サポートシステムが次のチケットを受け取ったとします。

顧客は二重請求され、支払いの失敗が3日間続いている。

汎用モデルは、請求、支払い、緊急度に触れた有用な段落を返すかもしれません。アプリケーションはそこからルートを抽出し、ラベルを検証し、余分な表現に対応し、形式が崩れたときの処理を決める必要があります。限定された質問なら、最初からソフトウェアの契約として定義できます。

質問：このチケットを担当する承認済みキューはどれか？
回答：billing、technical、account、none_of_the_above
コンテキスト：<チケットの状態>

違いは単なる「JSONとテキスト」ではありません。Structured Outputは、生成モデルに複数のフィールドをJSONで整形させる機能です。意思決定APIは意味のある選択そのものを中心に設計され、推論前に回答空間を定義し、結果を判断シグナルとして使うことを意図しています。

2つの経路は次のように整理できます。

チャットモデル：   prompt -> prose -> parser -> validation -> retry -> action
意思決定モデル：   state + bounded question -> decision -> policy -> action

後者は短くなりますが、リスクがなくなるわけではありません。形式が正しい回答でも間違う可能性があります。信頼度の数値が校正されているとも限りません。モデルが「安全」を選んだからといって、権限を与えてはいけません。メリットは境界が明確になることです。片側がモデルの判断、もう片側が決定論的な権限です。

実務上の設計ルール

呼び出し前に回答空間を書き出せるなら、意思決定APIを使います。モデルに文章を生成させたり、可能性を探索させたり、少数の承認済み結果に縮約できない計画を作らせたりするなら、汎用モデルを使います。

意思決定ループはどのように動くか

信頼できる統合は4つのステップに分けられます。

1. 1つの判断に必要な状態だけを集める

状態とは、判断に使える証拠です。チケット、メール、実行予定のツール呼び出し、スクリーンショット、複数サービスからまとめたオブジェクト、検索で取得した短い事実のリストなどが該当します。

状態は絞り込んでください。ルーティングにチケット、アカウント階層、直近のイベントだけが必要なのに、会話全体を送るとノイズ、遅延、プライバシーリスク、コストが増えます。人間のレビュアーがこの質問に答えるために必要な情報は何かを考えます。

2. 1つの限定された質問を書く

質問は1つの判断を表すべきです。「分類し、優先順位を付け、返金し、顧客に通知する」という指示には複数のポリシーが隠れています。別々の質問またはアプリケーションのステップに分けてください。

• 承認済みのどのチームが担当するか。
• 定義したスケールで、運用上の影響はどの程度か。
• 次のアクションに人間の承認が必要か。

各質問には、レビュアーが確認できる回答空間が必要です。現実がすべてのカテゴリに収まらない可能性があるなら、none_of_the_above のような明示的な出口を入れます。

3. 許可する回答を定義する

選択肢はアプリケーションが管理します。ルーティングなら billing、technical、account、manual_review、ツールゲートなら allow、confirm、block が考えられます。優先度スコアには、「低い」「高い」だけではなく、運用上の定義を持つルーブリックを使います。

質問の設計はプロダクトポリシーの一部です。選択肢を変えると過去の結果の意味も変わるため、質問、ルーブリック、ポリシーをモデル識別子とともにバージョン管理します。

4. コードが動く前にポリシーを適用する

返された判断はシグナルです。アプリケーションは権限、リソースの範囲、データの妥当性、サイドエフェクトのルールを検証する必要があります。モデルが refund_review を推薦しても、実際の返金を承認できるのは権限を持つサービスまたは人間だけです。

安全な式は次の通りです。

実行可能な経路 = モデルの判断 ∩ 決定論的なポリシー

重要なのはこの交差です。意思決定モデルは曖昧な意味判断を扱い、コードが権限を保持します。

Decisions APIは何に使えるか

最適なのは、周囲のシステムに次のアクションがすでに存在する、繰り返し発生する狭い判断です。

分類とルーティング

チケット、リード、文書、インシデント、モデレーションイベントを承認済みのキューに送ります。ルートは意図、プロダクト領域、重大度、顧客階層、または状態に含まれる複数の事実に基づけます。フォールバックを用意すると、未知のケースを誤解を招くカテゴリに無理に押し込まずに済みます。

Agentの次のステップを選ぶ

Agentは強いモデルで目的を理解し計画を作り、次に高速な意思決定レイヤーで、検索、オープン、入力、検証、再試行、ヘルプ要求、完了などの許可された次のステップを選べます。ホストアプリケーションは、アクションが利用可能か、引数が安全かを確認します。

ツール呼び出しと取引のゲート

メール送信、アカウント変更、データ削除、支払い、コンテンツ公開の前に、予定されたアクションについて限定的な質問をします。回答を許可リスト、ユーザー権限、確認要件、監査ログと組み合わせます。モデルは意図の解釈を助けますが、唯一の認可レイヤーにしてはいけません。

モデルルーティングとコスト管理

すべてのリクエストに最上位モデルが必要なわけではありません。意思決定レイヤーで、簡単な作業を高速分類器へ、難しい作業を強いモデルへ、不確実な作業を検索へ、機密性の高い作業を人間へ振り分けられます。ルート先は、入力形状、レイテンシ、コスト、フォールバックが分かっている能力として定義し、プロンプト内の任意のモデル名にしないでください。

トリアージと優先順位付け

キューシステムが必要とするのは、文章の要約ではなく一貫した優先度シグナルであることがよくあります。スコアは、各レベルの業務上の意味をルーブリックで定義した場合に有効です。「サービス停止」や「小さな影響」は、定義のない「緊急」よりテストしやすい表現です。

画像を使った判断

ローンチ報道では、画像コンテキストがプレビューの機能として説明されています。スクリーンショットの既知のUI状態を識別したり、画像の報告を適切なワークフローへ送ったりできる可能性があります。フォーマット、サイズ制限、プライバシー処理、実際のラベル付きデータでの精度を検証してから本番利用を判断してください。

統合はどのような形になるか

プレビューの契約は変わる可能性があるため、非公式のPayloadをそのまま本番にコピーしないでください。プロバイダーを小さなアダプターの背後に置きます。次は概念的な擬似コードです。

{
  "context": {
    "ticket": "The customer was charged twice.",
    "account_tier": "business",
    "recent_events": ["payment_succeeded", "payment_succeeded"]
  },
  "question": {
    "name": "route",
    "prompt": "Which approved workflow owns this case?",
    "answers": ["refund_review", "technical_support", "account_security"]
  }
}

アダプターはレスポンスを unknown として検証し、許可リストにない選択肢を拒否し、不確実性と通信障害を分ける必要があります。タイムアウトは自信のある「いいえ」ではありません。

const decision = await decisionsApi.evaluate(request);

if (!allowedRoutes.includes(decision.choice)) {
  return sendToManualReview('Unknown route');
}

if (decision.score < ROUTE_THRESHOLD || !policyAllows(decision.choice)) {
  return sendToManualReview('Uncertain or disallowed route');
}

return dispatch(decision.choice, { auditId, source: 'decisions-api' });

フィールド名は説明用です。score や confidence が校正済み確率だと仮定しないでください。生の結果、質問のバージョン、ポリシーのバージョン、モデル識別子、最終アクション、後の人間の結果を記録し、しきい値が機能しているか測定します。

OpenAI Decisions APIとJevの違い

OpenAIのプレビューとJevは、ソフトウェア内で高速かつ構造化された判断を行う同じカテゴリに見えますが、同じサービスではありません。公開情報からも、異なる契約が説明されています。

観点	OpenAI Decisions API	Jev AI
現在の報道上の状態	DevDay 2026時点で限定プレビュー	公開PlaygroundとAPIワークフロー
報道されたエンジン	GPT-6 Lunaの専用バージョン	Jev意思決定モデル
公開された入力	テキストまたは画像コンテキスト	公開サイト上のテキスト、JSONオブジェクト、テキスト配列
出力の考え方	開発者定義の回答から選択し、報道ではスコアにも言及	Choice、Score、Noul型の結果と確率・Confidence
代表的な用途	分類、ルーティング、Agentの次のステップ	分類、ルーティング、スコア、安全確認、人間レビューゲート
契約の成熟度	プレビューでエンドポイント、制限、料金、アクセスを確認	公開ドキュメントとインタラクティブなPlayground

大切なのは「どのブランドが優れているか」ではなく、「チームがどの契約を評価し、運用できるか」です。アカウント統合、画像コンテキスト、プレビューへのアクセスが重要ならOpenAIが候補になります。公開された型付き意思決定の形をすぐ試したい場合は、別の公開サービスが検討対象になります。どちらでも、回答空間を小さく定義し、ラベル付きサンプルを集め、最終的な権限をアプリケーションコードに残してください。

AI Agentのどの層に置くべきか

本番のAgentは通常、複数の層で構成されます。

1. オーケストレーター： タスク、コンテキスト、再試行、ループ状態を管理する。
2. 生成モデル： 意図を解釈し、計画し、文章を書き、証拠を要約する。
3. 意思決定レイヤー： ルート、リスク、優先度、完了に関する狭い質問に答える。
4. ポリシーと権限： ユーザー、Agent、ツールが実行できることを強制する。
5. アクションと監査： 承認された呼び出しを実行し、結果を記録する。

Decisions APIは第3層に置きます。第4層に暗黙的に変えてはいけません。モデルはツール呼び出しが低リスクに見えると言えても、ポリシーエンジンが認めていない権限を与えることはできません。

最初の実験では、可逆で低リスクな判断を1つ選びます。

過去のサンプル
        ↓
質問 + 許可された回答
        ↓
オフライン評価
        ↓
Shadowトラフィック
        ↓
人間が承認した自動化
        ↓
監視された本番経路

資金移動、アクセス制御、削除、安全、評判に関わる場合は、Shadowモードが特に重要です。実世界を変える前に、モデルの判断を人間のラベルや信頼できるルールと比較してください。

レイテンシ、コスト、信頼度

レイテンシ

ローンチ報道では、Decisions APIは約150ミリ秒で、通常のGPT-6 Luna呼び出しの約10倍速いとされています。高頻度のAgentループには有用ですが、アプリケーションはp50、p95、p99を自分で測るべきです。ネットワーク距離、コンテキストのサイズ、同時実行数、再試行、キューがモデル時間を上回ることがあります。

コスト

意思決定エンドポイントは長い説明を避け、簡単な処理を高価なモデルから外すことでコストを下げられる可能性があります。ただし、コンテキスト、再試行、可観測性、後続のモデル呼び出し、人間レビューまで含めて単位経済性を計算してください。プレビューの料金は現在のOpenAIアカウントで確認します。

信頼度とキャリブレーション

スコアは証拠であり、権限ではありません。0.92 の結果でも、特定の言語、顧客層、敵対的な入力では間違う可能性があります。少なくとも次を測定します。

• レビュー済みラベルとの一致率。
• コストの高いアクションごとの偽陽性と偽陰性。
• しきい値ごとの自動化カバレッジ。
• クラス、言語、入力タイプ、顧客層ごとの校正。
• 人間レビューの量と解決までの時間。
• モデル、質問、ポリシー、プロダクト変更後のドリフト。

最上位と2番目の確率が近い場合、トップラベルは不安定かもしれません。保留またはレビューの経路を残してください。影響の大きいアクションには、意思決定モデルが経路を推薦し、決定論的なポリシーまたは人間が承認する二重キー設計を使います。

本番前に確認すべきこと

公開情報ではDecisions APIは限定プレビューです。深く統合する前に、次を確認してください。

1. 公式エンドポイント、認証スコープ、現在のリクエストスキーマ。
2. 画像入力がアカウントとユースケースで有効か。
3. 回答セットの定義方法と複数質問のサポート。
4. 返されるスコアの意味と、校正されているかどうか。
5. 制限、レイテンシの期待値、レート制限、再試行、エラーコード。
6. データ保持、プライバシー管理、地域ごとの可用性。
7. 失敗、重複、バッチ呼び出しを含む課金単位。
8. モデルバージョンの固定方法とプレビュー変更の手順。

統合は狭いプロバイダーアダプターの背後に置きます。質問とポリシーをバージョン管理し、ログから機密状態を取り除き、ユーザー入力をポリシーではなくデータとして扱います。プロバイダーが利用できない場合は、推測せず、安全なキューまたは人間のレビューへ送ります。

よくある質問

Decisions APIはChatGPTや一般的なResponses APIの代わりですか？

いいえ。専用の意思決定レイヤーとして考えるべきです。生成、計画、ツールオーケストレーション、説明、ユーザー向け文章は汎用モデルを使います。承認済みの結果から狭い判断を選ぶときに、意思決定エンドポイントを使います。

Decisions APIはテキストを返しますか？

公開説明では、自由形式の段落を生成するのではなく、開発者が定義した回答から選ぶことが強調されています。転送形式がJSONでも、アプリケーションが必要とするのは読者向けの文章ではなく、判断値とメタデータです。

AI Agentの次のアクションを選べますか？

公開情報で説明されている代表的なユースケースです。アクション集合を限定し、実行前にツール、引数、権限、リソース範囲、確認要件を検証してください。

信頼度は正確さと同じですか？

いいえ。信頼度はランキングやルーティングに役立ちますが、実際の結果で評価する必要があります。高コストな判断には、しきい値、保留、人間レビュー、決定論的ルール、監視を追加します。

今すぐ使うべきですか？

アカウントにプレビューアクセスがあり、ワークフローが契約変更に耐えられるなら、管理された実験から始められます。不可逆な自動化ではなく、オフラインまたはShadow評価から始めてください。アダプターを設計する前に、型付き意思決定のパターンを理解しましょう。

最も重要なポイントは何ですか？

Decisions APIは、「モデルに何かを書かせる」から「モデルに小さく型付きの判断をさせる」への変化を示しています。分類、ルーティング、Agentループを高速化し、統合しやすくする可能性があります。信頼性を支えるのは、明確な回答空間、実データでの評価、コードを権威にする設計、そして信頼度を権限ではなく証拠として扱う姿勢です。

参考資料

• OpenAI DevDay 2026 公式発表
• The Decoder：OpenAI expands Codex and its API at DevDay。
• Pasquale Pillitteri：OpenAI launches Decisions API to take on Jev。