10月11日、nyosegawa.comが「How far can the OpenAI Decisions API go on image recognition tasks?」と題した記事を公開した。OpenAIが2025年10月6日にベータ公開したDecisions APIを、ファインチューン済み画像モデルや既存APIと5つの画像認識タスクで比較した実験レポートだ。結論を先に述べると、Decisions APIは学習データなしのゼロショット条件でSigLIP2ゼロショットを多くのタスクで上回り、ファインチューン済みモデルには届かないケースも多いが、速度とコストの優位性を加味すると十分に実用的な選択肢となっている。

Decisions APIとは何か

Decisions APIは、「この画像に傷はあるか？」「この書類の種類は何か？」といった質問に対して、テキストではなく確率値を返す新しいAPIだ。対応モデルは現時点でgpt-6-lunaのみ、エンドポイントはPOST /v1/decisions。

質問タイプは3種類ある。

同じ入力に対して複数の質問を1リクエストにまとめて投げられる点も特徴だ。

Responses APIとの最大の違いは出力トークンがゼロであること。Responses APIがトークンを逐次生成してJSONを返すのに対し、Decisions APIは候補全体の確率分布を一括で返す。そのためレイテンシが短く、OpenAIはResponses APIの約10倍速と主張している。

速度・コストの実測値

著者は5種類の画像認識タスクで両APIを比較した。レイテンシの中央値は以下の通り。

1画像タスクでは圧倒的に速いが、4画像タスクになると差が縮まる傾向が見られる。

コストについては「どちらが安いかはタスク設計による」というのが正直なところだ。

• HICO：20個のpredicateをまとめて送るため、入力トークン数がResponses APIの約4.7倍になりDecisions APIのほうが高くなった
• EPICとLOCO：Responses APIが推論トークンをoutputとして課金されるため、Responses APIが1.7〜4.9倍高くなった

5タスク×200アイテムを両API経由で実行した総コストは約**$0.59**。

5タスク×6手法の精度比較

実験の核心部分だ。比較対象は以下の6手法。

画像モデルにはgoogle/siglip2-base-patch16-256を使用している。SigLIP2はGoogleが公開したVision-Language Modelで、ゼロショット画像分類・検索において高い汎用性を持つベースラインとして広く使われている。patch16-256はパッチサイズ16・入力解像度256pxの標準的な構成だ。APIとAgentはgpt-6-lunaを使用し、学習データは与えず候補名とプロンプトのみで動作させている。

Codex Agentは、OpenAIのCodexをベースとしたコード実行エージェントだ。画像をcodex exec環境に渡し、クロップ・リサイズといった前処理を自律的に施しながら判断する。単純なAPI呼び出しではなく「エージェントが自ら処理ステップを組み立てる」アプローチとして比較対象に加えられており、上限コストや複雑さとのトレードオフを測る位置づけとなっている。

各タスクの精度について、元記事では95%信頼区間付きの数値が詳細に示されている。ここでは主要な傾向を抜粋する。

鳥200種分類（CUB-200-2011） では、細かい羽毛パターンの識別が求められる細粒度分類タスクだ。ファインチューンしたSigLIP2が最高精度を記録し、Decisions APIはSigLIP2ゼロショットを上回るもののファインチューン版には届かない結果となった。候補が200種と多いchoiceタイプの限界が出やすい領域でもある。

人物-物体インタラクション検出（HICO） では、20種のインタラクションをpredicateで一括送信する設計をとった。Decisions APIはSigLIP2ゼロショットと同等以上の精度を示し、速度・コストの優位性を加味するとAPI系手法の中では最も実用的な選択肢となった。

文書分類（RVL-CDIP） は16種類の文書タイプを識別するタスクで、Decisions APIが「分類・ルーティング向け」と位置づけられていることから最も得意とする領域に近い。ここでもSigLIP2ゼロショットを上回り、線形プローブに迫る精度を記録している。

行動認識（EPIC-Kitchens） は4枚の連続フレームから行動を予測するタスクだ。複数画像の時系列理解が必要なため、Decisions APIにとってはやや不利な条件となる。精度面ではResponses APIやCodex Agentに後れをとる結果となった。

異常検知（MVTec LOCO AD） はAUROC（Area Under the ROC Curve）で評価する。正常サンプルを参照しながら傷や配置の論理的異常を検出する構造的理解が必要なタスクであり、単純な分類とは性質が異なる。このタスクではCodex Agentが最も高いAUROCを記録しており、エージェント的なアプローチが有利な領域であることが示された。Decisions APIはpredicate形式で「傷があるか」を直接問う設計としたが、参照画像との比較が苦手な点が精度に影響している。

実装の要点

Python SDKではv3.26.0からclient.decisions.create(...)が使える。predicateで20アクションを一括送信するコード例（HICOタスク）：

questions = [
    {
        "type": "predicate",
        "name": f"label_{k}",
        "instructions": f"Does the image show {v}? Judge each interaction "
                        "independently. A person and object merely "
                        "co-occurring is insufficient.",
    }
    for k, v in classes.items()
]
result = client.post(
    "/decisions",
    cast_to=dict,
    body={"model": "gpt-6-luna", "input": messages, "questions": questions},
)
scores = [a["probability"] for a in result["answers"]]

200種の鳥分類では、200種名を候補として1つのchoice質問にまとめる。画像はbase64データURLでinput_imageに渡す形式で、1リクエストあたり最大128枚まで含められる。

どう使うべきか

Decisions APIが向いているのは「固定候補から答えを選ぶ」「速度が重要」「確率を後続処理で使いたい」の3条件が揃う場面だ。公式ガイドでは、Live APIで会話を処理しつつDecisions APIで「次のスライドへ」「何もしない」などのアクションを選択する音声制御アプリも例示されている。

一方、任意スキーマのJSONへの情報抽出、説明文の生成、引数付きのツール呼び出しが必要な場合はResponses APIのStructured Outputsやfunction callingが推奨される。

詳細はHow far can the OpenAI Decisions API go on image recognition tasks?を参照していただきたい。