OpenAI Decisions APIとは？限定プレビュー中にLunaで同じ判定を作る

OpenAIのDecisions APIは、文章や画像を渡すと、開発者が事前に定義した有限の選択肢から答えを1つ返す判定専用のAPIです。問い合わせの振り分け、コンテンツの分類、エージェントの次の行動選択に使う想定で、中身はGPT-6 Lunaです。ただし2026年10月6日時点では限定プレビューで、使えるのはOpenAIが選んだ一部のAPI顧客だけです。開発者ドキュメントにはリクエスト形式も料金もレート制限も載っていません。

自分のキーで呼んで403が返るなら、それはコードの誤りではなく、アカウントで機能が有効になっていないという意味です。いま実装が必要なら、一般提供中のgpt-6-lunaとStructured Outputsの列挙型（enum）スキーマで、同じ「選択肢から1つ選ぶ」処理を作れます。1回を入力400・出力15トークンと仮定すると、Standard料金で100万回あたり$47.50です。速度の要件が数百ミリ秒以下でなければ、待つ理由はあまりありません。

Decisions APIでできること：有限の選択肢から1つ選ぶ判定

OpenAIはDevDay 2026（2026年9月29日）でDecisions APIを発表しました。OpenAI Developer Communityの告知では、Lunaの能力を「ユーザーが定義した質問と、事前に決めた有限の回答」に集中させてリアルタイムの判断を行うもので、入力の分類、リクエストの振り分け、事前に定義した回答からの行動選択に使うと説明されています。

入力として渡せるのはテキストと画像です。たとえば問い合わせ本文と添付のスクリーンショットを渡し、「どのチームが担当するか」という質問と「請求・配送・技術・その他」という回答候補を指定すると、候補のどれかが返ってくる、という使い方です。具体的な用途は次のようなものです。

• 問い合わせの振り分け：請求、配送、技術サポートなど、どのキューに入れるか
• コンテンツ分類・モデレーション：投稿や画像を「公開可・要確認・削除」などに分ける
• エージェントの次の行動：注文を調べる、確認の質問をする、返信する、人に引き継ぐ、のどれを選ぶか

どれも文章を生成する必要はなく、決まった選択肢から1つ選べば足りる処理です。汎用モデルでもこなせますが、OpenAIはこの種の判定を専用の窓口に切り出し、速く返すことを狙っています。

Decisions APIの公開情報と未公開情報（2026年10月6日時点）

実装の判断に関わる項目を、公開済みかどうかで分けると次のとおりです。

開発者ドキュメントの変更履歴や料金ページにも、2026年10月6日時点でDecisions APIの項目はありません。DevDayの紹介文には「数日内に広く公開予定」とありましたが、その後1週間たっても一般公開は始まっていません。公式のスキーマがない以上、「Decisions APIのリクエスト例」とされるJSONはどれも推測です。

速度については、OpenAIのThibault Sottiaux氏がXで「エンドツーエンドで数百ミリ秒未満の判断ができるよう調整した」と投稿しています（eeselの解説が引用）。よく見かける「約150ms」「Lunaの約10倍速い」という数字は、報道やSNS、基調講演のスライドを紹介した記事に出てくるもので、OpenAIのドキュメントにはありません。どちらも測定条件が示されていない公称値です。

信頼度スコアについては、The New Stackは「返る」と報じていますが、FirecrawlやeeselはOpenAIのページや投稿にその記述を見つけていません。ドキュメントが出るまでは、信頼度の値でしきい値を設計しないほうが安全です。

APIキーで使える？403「Decision API is not enabled」の意味

プレビューに選ばれていない通常のキーでは使えません。eeselは2026年10月1日と2日に、通常のAPIキーでPOST https://api.openai.com/v1/decisionsを呼び、どちらの 日もHTTP 403と次のエラーを受け取ったと報告しています。

{
  "error": {
    "message": "Decision API is not enabled for this user.",
    "type": "invalid_request_error",
    "param": null,
    "code": null
  }
}

同じ報告では、/v1/decisions/createのような近くのパスは404でした。存在しないパスなら404、存在するが自分には開放されていない機能なら403という区別になり、403は機能の利用許可がないことを示すと読めます。空のリクエストでも403になるため、エラー内容からリクエスト形式を推測することもできません。

このエラーが返ったときの対応は単純です。

• リトライやパラメータの調整では解決しません。リクエストを直しても403のままです。
• 公開の申し込み手順は、2026年10月6日時点で開発者ドキュメントに載っていません。
• 日本はOpenAI APIの対応国に含まれているので、日本のアカウントでGPT-6 Lunaを使うこと自体は問題ありません。ただし対応国の一覧は、Decisions APIのプレビュー対象かどうかとは関係しません。

エンドポイントのパスやエラーメッセージは一般公開のときに変わる可能性があります。上のパスとメッセージは、あくまで2026年10月初旬の第三者の観測です。

待つか今つくるか：速度の要件で決める

Structured Outputsを使えば、出力を選択肢の中の値に限定することは今でもできます。Decisions APIで新しく得られるのは、OpenAIが公称する速度と、Lunaを判定に「集中」させたことによる精度の上積みがあるかどうか、の2点です。後者はまだ誰も検証できていません。そこで、判断の分かれ目はほぼ速度になります。

参考になる公開データとして、eeselはLunaとStructured Outputsで問い合わせ20件を振り分けるテストを公開しています（ノートPCからのエンドツーエンド計測、計160回の呼び出し）。reasoning.effortをnoneにした場合の中央値は1.46秒、mediumでは2.33秒でした。1社による小さなサンプルですが、「今の代替手段で1〜2秒程度」という目安にはなります。

TypeSafe社のJevのように、確率値を返す判定専用モデルは他社にもあります。ただ、OpenAIのAPIだけで完結させたい場合や画像を扱う場合は、Lunaで組むのが現実的です。

GPT-6 LunaとStructured Outputsで同じ判定を実装する

GPT-6 Lunaは、OpenAIが「集中した大量処理向けの最も効率的なモデル」と位置づけるモデルで、テキストと画像の入力、Structured Outputs、Responses API・Chat Completions・Batchに対応しています。reasoning.effortはnoneからmaxまで選べます（既定はmedium）。判定だけならnoneから始め、精度が足りない質問だけ上げるのが順当です。

スキーマ：選択肢を列挙型（enum）に入れ「判断できない」を必ず含める

Structured Outputsのガイドに従い、strict: trueのJSON Schemaで答えのフィールドを列挙型にします。こうすると、モデルはリストにない値を返せなくなります。ガイドの制約のうち、判定で関係するのは次の点です。

• オブジェクトには必ずadditionalProperties: falseを付け、フィールドはrequiredにすべて入れる
• スキーマ全体の列挙値は合計1,000個まで（250個を超える場合は文字数の制限も加わる）

ここで注意したいのは、厳格なスキーマが保証するのは「答えがリストの中の値であること」までで、答えが正しいことではない点です。eeselのテストでは、振り分け先のキューは40回中40回正しかった一方、「この問い合わせに自動返信してよいか」という判断は推論なしで40回中33回でした。キューを間違えても数分の遅れで済みますが、誤った自動返信はそのまま顧客に届きます。

そのため、メッセージ送信、課金、データ変更につながる判定には、選択肢に「判断できない（unsure）」を加え、それが選ばれたら人の確認に回す経路を最初から作っておきます。信頼度スコアがない以上、「動かない」という選択肢を明示的に用意するのがいちばん確実な歯止めです。

Pythonの実装例（Responses API）

下のコードは、公式ガイドに記載されたパラメータに沿って組んだ例です。本番に入れる前に、自分のデータで動作と精度を確かめてください。OPENAI_API_KEYは環境変数に設定されている前提です。

import json
from dataclasses import dataclass, field

from openai import OpenAI

client = OpenAI()  # 環境変数 OPENAI_API_KEY を使う
UNSURE = "unsure"


@dataclass
class Decision:
    answer: str                      # options のいずれか、または UNSURE
    detail: dict = field(default_factory=dict)


def decide(context, question: str, options: list[str],
           model: str = "gpt-6-luna", effort: str = "none") -> Decision:
    """context は文字列、または Responses API の content 配列（画像入り）"""
    schema = {
        "type": "object",
        "properties": {
            "answer": {"type": "string", "enum": options + [UNSURE]},
        },
        "required": ["answer"],
        "additionalProperties": False,
    }
    response = client.responses.create(
        model=model,
        reasoning={"effort": effort},
        input=[
            {
                "role": "system",
                "content": f"{question}\n選択肢から1つだけ選ぶ。"
                           f"判断材料が足りなければ {UNSURE} を選ぶ。",
            },
            {"role": "user", "content": context},
        ],
        text={
            "format": {
                "type": "json_schema",
                "name": "decision",
                "strict": True,
                "schema": schema,
            }
        },
        max_output_tokens=50,
    )

    if response.status == "incomplete":
        return Decision(UNSURE, {"reason": "incomplete"})

    message = next((o for o in response.output if o.type == "message"), None)
    part = message.content[0] if message and message.content else None
    if part is None or part.type == "refusal":
        return Decision(UNSURE, {"reason": "refusal"})

    data = json.loads(part.text)
    return Decision(data["answer"], {"usage": response.usage})


result = decide(
    "注文 #4471 の代金が二重に引き落とされています。",
    "この問い合わせを担当するキューはどれか。",
    ["billing", "shipping", "technical", "other"],
)
print(result.answer)  # options のいずれか、または unsure
if result.answer == UNSURE:
    pass  # 人の確認キューへ回す

応答が途中で切れた場合（incomplete）と安全上の拒否（refusal）は、ガイドが例外処理として挙げているケースです。どちらもunsureに寄せておくと、呼び出し側は「選択肢のどれか」か「人に回す」かの2通りだけを扱えば済みます。

Chat Completionsを使う場合は、text.formatの代わりにresponse_format: {"type": "json_schema", ...}で同じスキーマを渡します。

画像を含む入力

問い合わせにスクリーンショットが付いている場合は、contextに文字列ではなく、テキストと画像を並べた配列を渡します。

context = [
    {"type": "input_text", "text": "アプリが起動しません。画面を添付します。"},
    {"type": "input_image", "image_url": "https://example.com/screenshot.png"},
]
result = decide(context, "担当キューはどれか。",
                ["billing", "shipping", "technical", "other"])

画像は大きさに応じて入力トークンが増えるため、後述のコスト計算は画像の分だけ高くなります。

後でDecisions APIに差し替えやすくする境界

Decisions APIの形式は未公開なので、今から形式を合わせることはできません。できるのは、差し替える範囲を1か所に閉じ込めておくことです。

• アプリ側はdecide(context, question, options)だけを呼び、answerだけを受け取る。プロンプトやスキーマを呼び出し元に書かない
• 質問と選択肢の一覧は設定ファイルなどにまとめ、コードの各所に散らさない
• 判定ごとに答え、所要時間、トークン数を記録する。切り替え時の比較材料になる
• 正解ラベル付きのサンプル（数十〜数百件）を用意しておく。Decisions APIが使えるようになったら、同じセットで両方を走らせて比べられる

こうしておけば、切り替えるときに書き換えるのはdecide()の中身だけで済みます。

1,000回・100万回あたりのコスト：入力400・出力15トークンで$47.50

Decisions APIの料金は2026年10月6日時点で未公開で、トークン課金か、1回ごとか、質問ごとかもわかりません。いま計算できるのは、代わりに使うGPT-6 Lunaの費用です。LunaのStandard料金は、100万トークンあたり入力$0.10、出力$0.50です。BatchとFlexはその50%です。

1回あたりの費用は次の式で出ます。

入力トークン数 × $0.10 ÷ 1,000,000 ＋ 出力トークン数 × $0.50 ÷ 1,000,000

入力400トークン（指示文と問い合わせ本文）、出力15トークン（{"answer":"billing"}程度）と仮定し、reasoning.effortをnoneにした場合の結果です。

内訳は、入力400×$0.10÷100万＝$0.00004、出力15×$0.50÷100万＝$0.0000075、合計$0.0000475です。トークン数は仮定の値なので、自分の指示文と典型的な入力でトークン数を数え、式に入れ直してください。計算に影響する条件は次のとおりです。

• 画像を渡すと、その分の入力トークンが加わる
• reasoning.effortを上げると推論の分だけ費用が増える。eeselのテストでは、推論なしで1,000件あたり約$0.047、mediumで約$0.089だった
• 指示文が長く毎回同じなら、キャッシュされた入力（100万トークンあたり$0.01）が適用される場合がある
• Batchは結果がすぐ返らないため、リアルタイムの振り分けには使えない

処理量の面では、Lunaの最下位のTier 1でも毎分500リクエストまで送れます。月100万回は平均すると毎分約23回なので、ピークが極端でなければ収まります。

GPT-6 Solで判定する場合との料金差は、GPT-6 SolとLunaの料金比較：APIとCodexでどう違う？で同じトークン量の計算をしています。

Decisions APIへの切り替えを検討するシグナル

Lunaで作った判定をDecisions APIに移すかどうかは、次のどれかが起きた時点で見直します。

• developers.openai.comにDecisions APIのガイドかAPIリファレンスが公開された
• 料金ページにDecisions APIの行が載り、課金単位がわかった
• 自分のキーで呼んだときの403が解消した、または一般公開が告知された
• 信頼度や確率を返すフィールドがドキュメントに記載された。「自信がなければ動かない」をしきい値で制御できるようになる
• 自分のサービスで、判定待ちの時間がユーザー体験やエージェント全体の処理時間の問題になっている

切り替えるかどうかは、用意しておいた正解ラベル付きのサンプルで両方を比べてから決めます。比べるのは正解率、所要時間の中央値と遅い側の値、そして100万回あたりの費用です。Decisions APIが速くても、自分のデータで正解率が下がるなら、速度が必要な判定だけを移す選択もあります。

Decisions APIの料金・公開時期・Jevとの違い

OpenAI Decisions APIの料金はいくら？

2026年10月6日時点で未公開です。トークン単位で課金されるのかどうかもわかっていません。目安にできるのは土台のGPT-6 Lunaの料金（100万トークンあたり入力$0.10、出力$0.50）だけで、Decisions API自体の価格はこれと違う可能性があります。

Decisions APIの一般公開はいつ？

日付は発表されていません。DevDayの紹介文には「数日内に広く公開予定」とありましたが、2026年10月6日時点ではまだ限定プレビューのままです。

Decisions APIとJevの違いは？

TypeSafe社のJevは2026年9月15日に登場した判定専用モデルで、誰でも使え、テキストのみに対応し、選択肢ごとの確率を返します。Decisions APIは画像も扱えますが、限定プレビュー中で、確率や信頼度を返すかどうかは公式に示されていません。

Decisions APIはChatGPTで使える？

DevDayの告知ではAPIの項目として発表されており、ChatGPTの画面から使う機能としては説明されていません。使うにはOpenAI APIのアカウントと、プレビューへの参加が必要です。