OPENAI SEARCH INSIGHT

2026.10.23 / OpenAI最新情報

OpenAI、gpt-6-luna対応Decisions APIを一般提供開始

この記事で分かること: OpenAIが一般提供を開始したgpt-6-luna対応Decisions APIの変更点と、日本の開発チームが検証・移行時に確認すべき実務項目を知りたい。

OpenAIは2026年10月22日、gpt-6-luna対応のDecisions APIを一般提供した。公開ベータからの主な変更として、リクエスト間で共有する入力のキャッシュ、個別設問の指示への画像追加、inputjsonによる構造化データの直接受け渡しが示された。

運用面で最も分かりやすい変更は、1リクエストで扱える設問数が公開ベータ時の200件から最大400件へ拡大された点である。大量の判定・分類・設問処理を行う開発チームは、単純に上限を増やすのではなく、キャッシュ効率、画像を含む入力、構造化データの受け渡しを含めて処理設計を見直す必要がある。

OpenAIがDecisions APIを一般提供

OpenAIの公式Updateによると、Decisions APIはgpt-6-lunaとともに一般提供となった。今回確認できる一次情報は、APIの一般提供開始、共有入力のキャッシュ、設問単位の画像指示、inputjson、設問数上限の引き上げである。

一般提供は、公開ベータとして案内されていた段階から提供状態が変わったことを意味する。ただし、公式に示された情報の範囲では、価格、利用対象、地域別の提供状況、既存実装からの移行期限、従来仕様の終了時期は確認できない。これらを前提にした導入判断は避けるべきだ。

カテゴリはUpdate、対象モデルはgpt-6-luna、API識別子はv1/decisionsとして案内されている。実装担当者は、社内で利用中のAPIバージョン、呼び出し経路、入力生成基盤を棚卸しし、今回の機能が自社の利用経路にどう関係するかを個別に確認したい。

公開ベータから変わった上限と入力機能

公式発表で数値として明示された変更は、各リクエストの設問数上限である。公開ベータの200件に対し、現在は1リクエスト当たり最大400問をサポートする。バッチ単位を大きくできるため、多数の候補を一度に評価するワークロードではリクエスト分割の回数を減らせる可能性がある。

ただし、400問は「必ず400問をまとめるべき」という推奨ではない。設問ごとの入力量、回答に求める形式、失敗時の再試行範囲、処理完了を待てる時間はシステムごとに異なる。上限値と、業務にとって扱いやすいバッチサイズは区別して評価することが重要だ。

また、個別のquestion instructionsに画像を含められるようになった。これは、すべての設問に共通する画像を一括で渡す機能として公式に説明されているわけではなく、個別設問の指示に画像を含められるという変更として理解する必要がある。

共有入力のキャッシュをどう評価するか

OpenAIは、リクエストをまたいで共有する入力をキャッシュし、prompt-cache discountsを利用できると説明している。共通のポリシー文、評価基準、長い商品仕様、定型の業務ルールなどを複数リクエストで繰り返す設計では、キャッシュ対象となる共有部分を意識する価値がある。

公式発表で確認できるのは、共有入力のキャッシュとプロンプトキャッシュ割引の案内までである。割引率、キャッシュの保持期間、適用判定、入力変更時の扱いは、今回提示された本文には記載されていない。したがって、費用削減額を事前に断定せず、実際の利用条件を別途確認する運用が必要になる。

実務では、毎回変わる設問本文やユーザー固有データと、共通の評価規約を分けて管理する設計が候補となる。編集部の考察としては、共有部分を安定化させるほどキャッシュの評価をしやすくなる一方、規約更新時の版管理や、古い共通文を参照しないための変更管理も重要になる。

inputjsonと画像入力が変える実装設計

Decisions APIでは、構造化データをinputjsonで直接渡せるようになった。JSONを文章へ埋め込んで説明させる方式と比べ、アプリケーション側で持つ項目構造を入力として明示しやすくなる。選択肢、属性、識別子、評価対象のフィールドを構造のまま扱いたい用途で検討対象となる。

もっとも、inputjsonが入力値の自動検証、業務スキーマの保証、出力の完全な正規化まで担保するとは、公式本文からは読み取れない。利用側は、必須項目、型、欠損値、配列の順序、文字コード、個人情報を含むフィールドの扱いを、従来どおりアプリケーションとテストで管理すべきである。

画像を含む設問では、画像とテキストの対応関係が評価品質に影響する。編集部の考察として、画像ファイル名や内部IDだけに依存せず、設問本文に判定対象や観点を明記し、画像なし・画像あり・画像差し替えのケースを分けて回帰試験を作る方法が有効だろう。

日本の開発チームが先に確認する項目

第一に、現行の公開ベータ実装で1回当たりの設問数を200件以下に固定している箇所を確認したい。上限が400件になったからといって、キュー、タイムアウト、ログ、再試行、結果保存まで自動的に400件向けになるわけではない。上限拡大と運用上の最適値は別問題である。

第二に、共通プロンプトと案件ごとに変動するデータを分離する。キャッシュ割引を評価するなら、どの入力が複数リクエストで共通なのかを可視化しなければならない。規約文や採点ルーブリックを頻繁に差し替える場合は、変更前後の結果比較と版番号の記録も必要になる。

第三に、inputjsonへ渡すデータの境界を定める。業務データを構造化して渡す際は、不要なフィールドを含めない最小化、監査ログでのマスキング、テストデータと本番データの分離を検討したい。これは今回のAPI固有の要件として公式に示されたものではなく、構造化データ連携を安全に運用するための一般的な実務上の観点である。

第四に、画像を使う設問は、テキストのみの設問と同じ品質基準で一括評価しない方がよい。画像取得の失敗、向きや解像度の違い、設問と画像の取り違えを検知できるテストを設ける。特に大量バッチでは、一部の画像不備が全体の確認作業を増やす可能性がある。

Agent Memories編集部の考察

今回の更新は、単に設問数が倍増したという話ではない。共有入力のキャッシュ、設問ごとの画像、inputjson、400問上限は、いずれも大量かつ定型的な意思決定支援ワークフローを組み立てやすくする方向の変更と読める。ただし、これは公式発表の機能列挙に基づく編集部の解釈である。

たとえば、商品情報を共通ルールで審査する、複数候補を定めた基準で仕分ける、画像と属性を併用して設問を評価するといった処理では、共通文と個別データを分ける設計が考えられる。一方で、設問数を増やすほど、個別の失敗原因を追跡するログ設計と再実行単位の設計が重要になる。

導入評価では、400問を一度に投入した場合だけでなく、100問、200問、400問など複数のバッチサイズで比較することを勧める。比較対象は処理時間だけでなく、失敗時の復旧負荷、結果の追跡性、共通入力変更時の影響範囲、画像付き設問の検証コストまで含めるとよい。

また、キャッシュ割引を費用試算へ反映する前に、共通入力の割合を測定するべきだ。案件ごとに入力が大きく異なるなら効果を見込みにくく、共通ルールが長く固定されるなら評価余地がある。割引の具体的な条件や水準は今回の公式本文では未公表であり、推定値を確定値として扱わないことが肝要である。

よくある質問

Decisions APIはいつ一般提供になったのか

OpenAIの公式Updateの公開日は2026年10月22日で、Decisions APIはgpt-6-lunaとともに一般提供になったと案内されている。今回の確認済み情報では、それ以前の公開ベータから一般提供へ移行したことが示されている。

1リクエストで何問まで処理できるのか

最大400問である。公開ベータ時は200問だったため、上限は2倍になった。ただし、最適な設問数は入力サイズ、処理の待ち時間、失敗時の再試行方針などに左右されるため、上限まで詰め込むこと自体が目的ではない。

画像はどのように使えるのか

公式発表では、個別のquestion instructionsに画像を含められると説明されている。画像形式、容量、対応する詳細な入力仕様、品質上の推奨設定については、提供された公式本文には記載がないため、ここでは補完しない。

inputjsonを使えばJSONを文章化しなくてよいのか

構造化データをinputjsonで直接渡せることは公式に示されている。一方、どのようなスキーマ設計が最適か、全てのJSON表現をどう扱うか、入力検証がどこまで自動化されるかは今回の本文だけでは確認できない。利用側でデータ品質を検証する設計は引き続き必要である。

まとめ

OpenAIはgpt-6-luna向けDecisions APIを一般提供し、共有入力のキャッシュ、個別設問への画像追加、inputjson、最大400問の処理を案内した。公開ベータからの変更を確認する際は、200問から400問への上限変更だけでなく、入力の分割方法とデータ管理方法を合わせて見直したい。

日本の開発チームは、まず既存のバッチ制御、共通プロンプト、構造化データ変換、画像付き設問のテストを点検するのが現実的だ。価格や具体的な割引条件、利用範囲など、公式本文にない情報を前提にせず、確認済みの仕様と自社検証を分けて評価することが、安全な移行判断につながる。

本カテゴリはMiraigent / Agent Memoriesによる非公式編集記事です。OpenAIとの提携・承認・後援を示すものではありません。