OpenAI は、新しい Decisions API をパブリック ベータ版でリリースしました。これにより、開発者はフルテキスト生成ではなく入力された決定のための別のエンドポイントを利用できるようになります。ベータ版は GPT-6 Luna のサポートとともに 10 月 6 日にリリースされ、出力空間 (述語、選択肢、スコア) が事前にわかっているワークロード向けに位置付けられています。

それは狭いように思えますが、重要です。本番環境の AI トラフィックの大部分は、無制限の書き込みではありません。それは、分類、ルーティング、モデレーション隣接ポリシーのチェック、意図の検出、ツールの選択、およびガードレール ロジックです。これらの呼び出しでは、多くの場合、モデルに小さな構造化された応答を生成するよう要求し、アプリケーションにそれを解析または検証するよう強制します。 OpenAI は現在、そのパターンを独自の API サーフェスとして扱っています。

何が変わったのか

The Decisions API は、テキストと画像を入力された回答に変換します。 OpenAI は、サポートされている意思決定ワークロードの応答 API よりも最大 10 倍高速になる可能性があると述べています。パブリック ベータ版では、開発者は、モデルに任意のテキストの生成を促し、事後に結果を制約するのではなく、決定出力を述語、選択肢、またはスコアとして定義できます。

料金モデルも異なります。 OpenAI には、ディシジョン API に対する GPT-6 Luna の使用量が入力トークン 100 万あたり $0.10 でリストされており、キャッシュ読み取り、キャッシュ書き込み、または出力トークンの料金はかかりません。これにより、請求額は入力ボリュームのみに関連付けられるため、大容量の意思決定層のユニットエコノミクスのモデル化が容易になります。

このリリースは、チャット、応答、またはエージェント指向の API を置き換えるものではありません。アプリケーションが段落ではなく、信頼できる入力された回答を必要とする場合に、より特殊なパスを作成します。すでにワークロードをモデル サイズ、レイテンシー層、プロバイダー ルートに分割しているチームにとって、これにより、アーキテクチャに意思決定コールという別のカテゴリが追加されます。

開発者が注意すべき理由

多くの AI アプリケーションは、すでに内部制御ロジックとして小さなモデル呼び出しを使用しています。サポート アシスタントは、ワークフローを選択する前にチケットを分類できます。コーディング エージェントは、次にどのツールを呼び出すかを決定できます。文書処理システムは、レコードがポリシーのしきい値を満たしているかどうかをスコアリングできます。顧客向け製品は、より安価でより高機能なモデル間でリクエストをルーティングする場合があります。

これまで、これらのパターンは、厳密なプロンプト、JSON スキーマ、再試行、および検証レイヤーを備えた通常の生成呼び出しとして実装されることが多かった。このアプローチは機能しますが、オーバーヘッドが発生します。開発者は出力トークンの代金を支払い、解析の失敗を管理し、多くの場合、決定自体が必要とするよりも長い待ち時間を受け入れます。

型付き決定エンドポイントは、そのトレードオフを変更します。出力がブール値、限定された選択肢、またはスコアとして表現できる場合、チームは呼び出しを一般的な生成パスの外に移動できます。これにより、レイテンシが短縮され、アプリケーション コードが簡素化される可能性があります。また、呼び出しの目的が明示されているため、ログと分析のあいまいさが軽減される可能性もあります。

最も差し迫った使用例は、リクエストのルーティング、コンテンツ適格性ゲート、エスカレーション ルール、ツール選択手順、モデル選択ポリシーなどの高頻度の内部チェックである可能性があります。このような場所では、より大きなモデルのリクエストが発生する前に決定呼び出しが行われる可能性があるため、レイテンシとコストの小さな改善が重要になる可能性があります。

コストとガバナンスへの影響

入力のみの価格は、注目すべき商業的な詳細です。大量のエージェント ガードレールやルーティング決定を実行しているチームの場合、出力トークンの課金を排除すると、小規模なチャット モデル、ルール エンジン、プロバイダー固有の分類子エンドポイントとの比較が変わります。また、コスト予測が出力の冗長性やスキーマの再試行の影響を受けにくくなります。

これは、すべての分類子が決定 API に移行する必要があるという意味ではありません。ロジックが単純であれば、決定論的ルールの方がコストが安くなり、監査も簡単になります。一部のルーティングの問題には、既存の埋め込みフィルター、検索フィルター、またはデータベース フィルターの方が適切な場合があります。しかし、乱雑なテキストや画像を解釈して限定された答えを得るためにモデルがすでに使用されている場合、新しい API はチームによりクリーンな調達およびエンジニアリングのオプションを提供します。

プラットフォーム チームにとって、より大きな問題は分類です。すべての AI 呼び出しが社内ダッシュボードでチャットの完了または一般的な応答として扱われる場合、意思決定のワークロードを管理するのは困難になります。待ち時間、請求動作、障害モードはそれぞれ異なります。成熟した LLM コスト管理 プログラムを備えた組織は、ルーティング、予算、アラートがワークロードの実際の動作を反映するように、決定トラフィックを生成トラフィックから分離する必要があります。

同じことがゲートウェイにも当てはまります。プロバイダーが意思決定、ツール、バッチ、ライブ音声、エージェント用に特化したエンドポイントを構築し続ける場合、チャット スタイルの通話のみを正規化する マルチモデル AI API ゲートウェイ だけでは十分ではない可能性があります。 B2B LLM プラットフォームと内部 AI コントロール プレーンには、チャット抽象化を介してすべてを強制するのではなく、型付きの決定を行うためのファーストクラスのエンドポイント カテゴリが必要になる場合があります。

影響を受けるのは誰ですか

アプリケーション開発者は、プロンプトの多い分類またはルーティング コードを維持する場合に最も直接的なメリットを得ることができます。新しい API により、脆弱なプロンプトと解析のフローを、アプリケーションの内部ステート マシンによりよく一致する型指定された出力に置き換えることができる可能性があります。

AI プラットフォーム チームは、意思決定 API を別の承認済み機能として公開するかどうか、どのように記録するか、どのチームがそれを使用できるかを決定する必要があるため、影響を受けます。セキュリティおよびコンプライアンスの審査担当者は、意思決定結果がアクセス制御、ユーザー資格、医療ワークフロー、雇用、財務上の意思決定、またはその他の機密プロセスに使用されているかどうかを知りたいと考えます。

財務チームと運用チームも注意を払う必要があります。意思決定コールがより広範なモデルの使用法にまとめられている場合、エグゼクティブレポートでは意思決定コールが見えなくなる可能性があります。アプリケーションがユーザー向けの生成だけでなく、コントロール プレーン ロジックとしてモデル呼び出しを使用し始めたら、LLM APIコスト アトリビューションは、モデル名だけでなく呼び出しのビジネス機能をキャプチャする必要があります。

まだ不確実なことは何ですか

ベータ版の発表では API の基本的な形状が確立されていますが、製品の重要な詳細についてはまだ検証が必要です。 OpenAI は、実際のエンタープライズ ワークロード全体での「最大 10 倍高速」という主張に対する独立したベンチマークの証拠を提供していません。開発者は、独自の入力サイズ、画像ペイロード、リージョン、同時実行パターンを使用してレイテンシをテストする必要があります。

また、ベータ版インターフェースがどの程度安定するか、レート制限が他の OpenAI API サーフェスとどのように比較されるか、応答や将来のエージェント API とともに Decisions API がどのように進化するかについても不明です。この価格設定は大量の意思決定層にとって魅力的ですが、ベータ版の価格設定とエンドポイントの動作は、契約のレビューなしに永続的なものとして扱うべきではありません。

ただし、戦略的なシグナルは明らかです。OpenAI は、別の一般的な LLM アプリケーション パターンを汎用生成から切り離しています。これは企業にとって、AI アーキテクチャが 1 つのモデル エンドポイントを選択することよりも、各ワークロードを適切な API プリミティブに一致させることが重要になっていることを意味します。