OpenAI Decisions API を日本語テキストと画像で試してみた

はじめに

OpenAI の Decisions API を使って、テキストや画像を含む 9 種類の課題について計 900 件の判定を行い、その精度と応答時間を評価してみました。

LLM を使った業務システムでは、文章生成ではなく「問い合わせの分類」「フラグ判定」「スコアリング」といった分岐処理を高速かつ低コストに行いたい場面が多くあります。2026 年 10 月にパブリックベータとして公開された Decisions API は、まさにそうしたプログラム向けの型付き判定に特化した API です。

今回は、テキスト・画像・テキスト＋画像の 3 種類の入力に対し、条件判定（predicate）・選択分類（choice）・採点（score）の 3 形式を組み合わせ、それぞれ 100 件ずつ検証しました。

実際に返ってきた判定結果の精度や応答速度、実装時に注意すべきポイントを詳しくレポートします。LLM による判定処理の高速化や自動化を検討している方の参考になれば幸いです。

OpenAI Decisions API とは

Decisions API は、事前に定義した質問に対してプログラムで扱いやすい固定型の回答を返す API です。問い合わせの担当部署の振り分けや、不具合の深刻度評価といった用途に適しています。

2026 年 10 月 8 日時点ではパブリックベータとして提供されています。対応モデルは gpt-6-luna で、エンドポイントは POST /v1/decisions です。公式ガイドによると、Responses API よりも約 10 倍高速とされています。^[1]

リクエストには、利用モデル（model）、判定対象データ（input）、質問一覧を定義する questions を指定します。判定結果は answers 配列に格納され、質問ごとに設定した name で各回答を取得できます。^[2]

3 種類の質問形式

判定要件に合わせて、次の 3 種類から質問の型を選択します。^[2:1]
それぞれの特徴は次のとおりです。

• predicate: 真偽値（true / false）ではなく、条件に合致する確率（0.0〜1.0）を返します。この確率をもとに、自動処理に進めるか有人確認に回すかを、アプリケーション側でしきい値を設けて制御できます。
• choice: 定義した選択肢から最適なものを 1 つ選択します。判定結果（choice）に加え、各選択肢の確率分布（probabilities）と確信度（confidence）が返されます。
• score: 定義した各評価レベルの数値を確率で重み付けした平均値を返します。たとえば「見た目のみ」を 0、「回避策あり」を 1、「業務停止」を 2 と定義した場合、回答は 0〜2 の範囲の連続値（1.1 など）として算出されます。^[1:1]

前提条件・検証環境

今回の検証では、入力形式 3 種類 × 質問形式 3 種類を組み合わせた計 9 区分について、それぞれ 100 件（合計 900 件）のリクエストを実行しました。

• 検証日: 2026 年 10 月 8 日
• 利用モデル: gpt-6-luna
• エンドポイント: POST /v1/decisions
• 検証規模: 計 9 区分 × 各 100 件 ＝ 合計 900 件

各区分で試した検証課題は次のとおりです。

やってみた

それでは、実際の検証手順と結果を見ていきましょう。

手順1: リクエストの送信と判定ルール

API の呼び出しは Node.js から逐次実行しました。入力テキストや画像（base64 形式）とともに質問を送信し、返ってきた回答をあらかじめ用意した正解ラベルと比較します。

たとえば、日本語文の分類リクエストでは次のようなデータを送信しました。

{
  "model": "gpt-6-luna",
  "input": [
    {
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "文章A: オレンジ色の救助ボートは水の上を突進している\n文章B: 救助ボートはオレンジ色で、水の上を突進している"
        }
      ]
    }
  ],
  "questions": [
    {
      "type": "choice",
      "name": "relation",
      "instructions": "文章Aを前提とした文章Bの関係を分類してください。",
      "choices": [
        {
          "value": "entailment",
          "description": "含意。Aが正しければBは必ず成り立つ。"
        },
        {
          "value": "contradiction",
          "description": "矛盾。AとBは同時に成り立たない。"
        },
        {
          "value": "neutral",
          "description": "中立。AだけではBが成り立つか決まらない。"
        }
      ]
    }
  ]
}

返ってきた回答部分は次のとおりです。

{
  "type": "choice",
  "name": "relation",
  "choice": "entailment",
  "probabilities": [
    { "value": "entailment", "probability": 0.95 },
    { "value": "contradiction", "probability": 0.01 },
    { "value": "neutral", "probability": 0.04 }
  ],
  "confidence": 0.93
}

この回答は正解ラベルの entailment と一致しました。

画像を使う区分では、同じ content 配列に input_image を入れ、画像を base64 の data URL で渡しています。Decisions API の画像入力は、この形式に対応しています。^[1:2]

判定の基準は次のとおり設定しました。

• predicate: 返された probability が 0.5 以上なら真として、正解ラベルと比較
• choice: 返された choice と正解ラベルの完全一致を判定
• score: 正解との差の絶対値を平均した 平均絶対誤差（MAE） と、誤差が 0.5 以内に収まった割合を算出（MAE は小さいほど正解に近い）

手順2: 日本語テキストの検証結果（300 件）

日本語文ペアを対象とした 300 件の検証結果です。

含意の有無（predicate）は 93.0%、3 分類（choice）は 84.0% と高い一致率を示しました。一方で、意味の類似度（score）では人手評価とのズレが目立ちました。

含意判定では、含意に当たる 50 件のうち 44 件を真と判定し、含意に当たらない 50 件のうち 49 件を偽と判定しました。3 分類では、正解が中立の文ペアを含意や矛盾と判定するケースも見られました。

類似度の採点では、人手評価と大きく離れた例がありました。たとえば、次の文ペアです。

文章A: 男性が電子レンジのボタンを押している
文章B: 電子レンジのボタンを押している男性は一人もいない

元の類似度評点は 4.0、0〜4 に変換した正解は 3.0 でしたが、API のスコアは 1.18 でした。この文ペアは否定の有無によって論理的には内容が矛盾していますが、単語の重複が多く、人手による類似度評点も高い例です。

「論理的に含意するか」と「意味がどの程度似ているか」では評価の観点が異なります。類似度を採点させる際には、人手評価とのズレを事前に検証し、質問文（instructions）や採点基準を細かく調整する必要がありそうです。

手順3: 合成画像の検証結果（300 件）

シンプルな図形画像を対象とした 300 件の検証結果です。

赤い球の有無判定（predicate）は 100% 一致し、球の個数採点（score）も MAE 0.104 と、合成画像に対しては非常に高い精度を発揮しました。

赤い球の有無は、今回の 100 件すべてで正解と一致しました。形分類で外れた 2 件は、立方体と円柱をそれぞれ球と誤認したものでした。

球の個数は「0 個」「1 個」「2 個」「3 個以上」の 4 段階で採点しました。score は各段階の確率加重平均なので、球が 2 個の画像に対して 1.97 のような連続値が返ります。

手順4: 実画像とテキストの検証結果（300 件）

実写真に対する質問と、画像説明文の正確性を評価した 300 件の結果です。

合成画像に比べて難易度が上がり、一致率は 67〜70% 程度となりました。また、確信度（confidence）が高くても人手評価から離れる例が確認されました。

Yes / No 質問では、正解が Yes の 50 件中 15 件を No と判定し、正解が No の 50 件中 15 件を Yes と判定しました。

色分類では、「What color do the trousers have?（ズボンは何色ですか？）」という質問に対し、正解の green と回答の gray が一致しないケースがありました。確率分布を見ると green と gray がともに 0.48 で、確信度（confidence）は 0.42 でした。

また、確信度が高くても人手評価から離れる例がありました。画像に対する「A tray of food on a table in a restaurant.」という説明文では、人手評価は 2.0（変換後は 1.0）でしたが、API は 3.84、confidence は 0.87 を返しました。確信度が高いからといって、必ずしも人手評価と一致するとは限らない点に注意が必要です。

手順5: 応答速度とコストの計測結果

有効な判定が返ったリクエストについて、区分ごとの応答時間を集計しました。

計測範囲は Node.js の fetch 呼び出し直前からレスポンス本文の受信完了までで、通信時間を含みます。画像の取得や base64 形式への変換にかかる時間は含めていません。

表中の時間の単位はすべて ms で、平均と中央値は整数に四捨五入しています。

P95（95 パーセンタイル） は、約 95% のリクエストがその時間以下で完了したことを表します。今回は応答時間を昇順に並べ、件数の 95% を切り上げた順位の値を使いました。

テキスト入力は平均 260〜310 ms、中央値約 210 ms と軽快です。一方、画像を含む入力では平均 350〜470 ms とやや増加し、P95 では 1 秒を超えるケースも見られました。

トークン数とコストの試算

回答拒否を含む全 900 回の合計入力トークン数は 302,146、出力トークン数は 0 でした。100 万入力トークンあたり 0.10 米ドルを当てはめると、次の概算になります。^[1:3]

302,146 ÷ 1,000,000 × 0.10 = 0.0302146 米ドル

約 0.0302 米ドルはログのトークン数に基づく試算で、実際の請求額を確認した値ではありません。地域別処理の割増や長いコンテキストに対する倍率は含んでいません。

注意点：HTTP 200 でも「回答拒否（refusal）」が発生する

今回の検証で最も注意が必要だと感じたのは、HTTP ステータスが 200 OK であっても、回答が拒否される場合がある という点です。

全 900 回のリクエストの HTTP ステータスコードはすべて 200 でした。しかし、実画像の色分類（choice）のうち 2 件で回答の型が refusal となり、分類結果が得られませんでした。

未判定: text_image_choice:13928055 | Error: refusal
未判定: text_image_choice:02340304 | Error: refusal
完了: 898/900判定 | API呼び出し 900回 | 入力トークン 302146

上記はログから時刻を省いて抜粋したものです。ログにある Error: refusal は HTTP エラーではなく、API レスポンスに含まれる回答拒否（type: "refusal"）を検証スクリプト側で検知・出力したメッセージです。なお、保存したレスポンスの記録からは、拒否された具体的な理由は判別できませんでした。

Decisions API は、質問単位の回答拒否を type: "refusal" として仕様に明記しています。ちなみに質問への回答が拒否されても、同じリクエスト内のほかの質問には回答が返ってきました。^[2:2]

先行する Jev、Clef との違い

高速に型付きの判定値を返す仕組みとしては、先行する TypeSafe AI の Jev ^[3] や Cloudflare の Clef（Clef-flash）^[4] が知られています。いずれも文章生成を行わずに判定結果や確信度を返すアプローチをとっており、プログラムの分岐処理に組み込むという目的も Decisions API と重なります。^[5]

2026 年 10 月 7 日に確認した各社の公開資料に基づく主な違いは以下のとおりです。^[2:3][6][7]

まとめ

今回は、OpenAI Decisions API を使ってテキストや画像を含む 9 種類の課題について計 900 件の判定を行い、その精度や応答速度、コストを検証しました。

実際に検証してみて感じた個人的な所感と判断基準は次の 4 点です。

• レイテンシとばらつき: 一般的な LLM のテキスト生成に比べれば十分高速です。ただ、エッジ推論や超低遅延を強みとする特化型 API と比べると、平均 300〜400 ms 台はやや遅く感じられます。中央値と平均値の開きからもレイテンシのばらつきがあるため、リアルタイム性がシビアに求められる処理では注意が必要です。
• コスト感とトークナイザー: 100 万入力トークンあたりのカタログ単価は Jev や Clef-flash のほうが安価ですが、モデルによってトークナイザーが異なります。特に日本語テキストではトークン消費効率が良く、カタログ単価の差ほど実コストは高くならず、想定より安く抑えられる印象を受けました。一方で、画像を判定材料に含めるとトークン消費が一気に跳ね上がるため、画像入力の頻度が高い用途では事前のコスト試算が重要です。
• 質問単位の回答拒否とフォールバック: Decisions API は、質問単位の回答拒否を type: "refusal" として仕様に明記しています^[2:4]。今回の検証でも HTTP 200 でありながら回答拒否が返るケースがありました。実務システムへ組み込む際は、refusal 発生時に別モデルへ切り替える、あるいは有人対応へ回すといったフォールバック処理の設計が不可欠です。
• 入力形式と画像対応: Decisions API と Clef は画像を判定材料に含められますが、Clef（Workers AI）には 1 リクエストあたり最大 4 枚という制限があります^[8]。一方で Jev は現時点でテキスト入力のみに対応しており、画像を扱うには OCR などの前処理が必要です^[9]。

Decisions API は、トークン消費が入力のみで済み、プログラムから扱いやすい分岐処理エンジンとして強力な選択肢です。実務へ導入する際は、他の API とのレイテンシやコストの特性差を考慮しつつ、HTTP 200 で返る refusal へのフォールバック設計をあらかじめ組み込んでおくことをおすすめします。

本ブログが OpenAI Decisions API の活用を検討している方の参考になれば幸いです。

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。

運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。

当社は様々な職種でメンバーを募集しています。

「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました