のように、用意した選択肢から答えを選ぶAIが増えています。OpenAIが発表したも、その流れにある開発者向けの機能です。今回注目したいのは、文章に加えて画像を判断材料にできること。たとえば、問い合わせ文とエラー画面を一緒に渡し、最初に確認する担当を選ぶ用途が考えられます。
ただし「Jevの競合が登場した」と「自社の仕事でJevより優れている」は別の話です。この記事では、話題になったXの紹介投稿を公式発表に照らし、確認できたことと比較実験が必要なことを分けます。後半には、一般公開後の試用に使える架空の問い合わせ6件を用意しました。
確認日：2026年9月30日。公式発表と開発側の投稿を調査した解説です。Decisions APIの実リクエストは送っていません。後半の教材は編集部が設計した検証課題であり、製品の出力例や性能測定結果ではありません。
発表で確認できたこと
OpenAIのDevDay 2026公式まとめは、Decisions APIを、有限の回答候補がある特定の質問にLunaを集中させる仕組みと説明しています。開発者がテキストや画像を渡し、分類、振り分け、エージェントの次の行動を選ぶための答えを受け取ります。公式ページの日付は9月29日、日本時間9月30日午前3時34分のOpenAI Developersの投稿でも、を使うことと限定プレビューであることを確認できます。
| 紹介されている内容 | 裏取りの結果 | 読み方 |
|---|---|---|
| OpenAIがDecisions APIを発表 | 公式発表で確認 | 新しい判断用のAPIとして紹介されている |
| 画像も判断材料にできる | 公式発表で確認 | 日本語の画面や細かな文字を正確に読めるかは別途検証 |
| 限定プレビューから始まる | 公式発表で確認 | すべてのAPI利用者が今すぐ呼び出せるとは限らない |
| 数日以内に広く公開予定 | 公式発表にある予定 | 一般公開が完了したという意味ではない |
| Jevより速い・正確 | 今回は比較実測なし | 同じ課題と環境で測るまで勝敗をつけない |
開発側のTibo氏の投稿には、画像入力を扱い、端から端までの判断を数百ミリ秒未満で行えるよう調整しているとの説明があります。これは開発側が示す設計上の狙いです。入力の長さ、画像の大きさ、通信、同時実行数などの条件をそろえた日本での測定結果として読むことはできません。
DotsとDecisions APIは、任せる仕事が違う
同じ時期に発表されたと混同しやすいものの、使う場面が違います。Dotsは、調査や資料作りなどを継続して任せるです。公式ガイドは、専用のクラウド環境を持ち、接続した道具や文脈を使って仕事を進める仕組みと説明しています。一方、Decisions APIは、自分のアプリケーションに判断の一工程を組み込むためのものです。Dotsの公式ガイド
たとえば「来週の会議までに、資料の変更を拾って確認事項をまとめて」はDotsに頼む仕事として考えられます。「この問い合わせを操作案内・障害調査・人による確認のどこへ回すか」は、Decisions APIで検証する問いの候補です。どちらもAIですが、前者では成果物と進行管理、後者では選択肢と判定条件を設計します。Dotsが内部でDecisions APIを使っているとは、今回確認した資料からは断定できません。
| Dots | Decisions API | |
|---|---|---|
| 頼み方 | 会話で目的と作業範囲を伝える | 開発したアプリから質問と候補を渡す |
| 主な役割 | 継続する仕事を進め、成果物を返す | 判断工程で使う答えを選ぶ |
| 最初に決めること | 読んでよい資料、期限、成果物、連絡先 | 候補の意味、不明時の扱い、評価方法 |
| この記事での確認範囲 | 公式ガイドの仕様 | 公式発表段階の仕様 |
Dotsの実務例は、会議前メモの作り方とスマホ・クラウド・自分のPCの使い分けで扱います。を使った開発が目的でなければ、まずそれらのように、完成させたい仕事から考える方が始めやすいでしょう。
Jevとの比較は「同じ入力」と「画像を使う仕事」を分ける
Jev系の比較をするときは、一枚の順位表だけでは判断しづらくなります。文章だけを読む分類問題と、画面を見なければ答えられない問題では、そもそも入力が違うからです。Jevなどの言語・実行条件は判断モデルの比較記事にまとめています。ここでは、画像が増えたことで何を測り直すかに絞ります。
まず、同一の日本語文、質問、回答候補を使う文章のみの試験を作ります。次に、文章だけでは決められない画面付きの試験を別に用意します。画像を直接扱わない構成では、画像から文字を読み取ってから判断する工程も含めて評価します。その場合、文字を読み取る段階の誤りと、分類段階の誤りを分けて記録しなければ、どの部分を直すべきか分かりません。
回答が候補の一つに収まっていても、正しい担当を選んだ保証にはなりません。製品の操作案内なのか、障害調査なのか判断しづらい入力を、どちらかへ無理に押し込むと、後工程の負担が増えます。評価用の候補には、利用側が定義する「人による確認」も用意します。これはDecisions APIに特別な保留機能があるという説明ではなく、質問と選択肢の設計案です。
画面付き問い合わせ6件で、導入前の問いを作る
教材は、架空の社内予約ツールの問い合わせです。画面の状態と文章を合わせ、最初にどの担当が確認するかを決めます。実際の製品画面や顧客情報は使いません。正答は一般常識から自動的に決まるものではなく、次の業務ルールで定義します。読者の会社では、担当の分け方そのものから変更してください。
【検証課題の業務ルール：実際のAPIリクエスト形式ではありません】質問：この問い合わせを最初に確認する担当を選んでください。候補：操作案内 / 障害調査 / 人による確認
操作案内：指定された画面に、入力不足・操作不足の説明が明瞭にある。障害調査：指定された画面に、サービス側エラーの表示が明瞭にある。人による確認：画像がない、読めない、本文と矛盾する、対象画面か不明。依頼の対象日時と画面の記録日時が一致しない場合も、人による確認にする。
本文と画像だけを根拠にし、見えない部分を推測しない。担当を選ぶことと、返信・設定変更を実行することは別の工程とする。| 課題 | 入力の特徴 | 教材で定める期待結果 | 確認する点 |
|---|---|---|---|
| C01 | 「保存できない」＋必須項目の未入力表示 | 操作案内 | 本文の困りごとだけで障害と決めない |
| C02 | 同じ本文＋サービス側エラー表示 | 障害調査 | 画像で判断が変わるか |
| C03 | 同じ本文＋判読できない画面 | 人による確認 | 読めない文字を補わない |
| C04 | 「登録できた」＋失敗表示の画面 | 人による確認 | 本文と画像の矛盾を扱えるか |
| C05 | 「保存できない」＋画像なし | 人による確認 | 情報不足を成功した判定として扱えるか |
| C06 | 「今回も同じ」＋別の日付の画面 | 人による確認 | 古い証拠を現在の状態と混同しない |
検証では、入力用の文章と画像を渡し、期待結果の表はモデルに見せずに手元へ残します。C01とC02の文章を同じにするのは、画像が判定に影響したかを確かめるためです。C06は画面の日付と対象日時を明示し、単に古いという印象で判断しないようにします。こうして、何を間違えたら不合格なのかを、実行前に決めておきます。
架空の画面・問い合わせ・空の記録表をダウンロードできます。画像原稿は自作のSVGです。実サービスへ渡す際の対応形式・画像サイズは、公開された最新の仕様を確認し、必要なら対応形式へ書き出してください。教材の形式を、そのままAPIが受け付けると保証するものではありません。
速さだけでなく「間違えたときの仕事量」を記録する
試験の記録には、実行日時、実際のモデル識別子、質問・候補の版、入力画像の版、返った答え、かかった時間を残します。を比較するなら、アプリが送信を始めてから答えを受け取るまでなど、計測区間をそろえます。画像の前処理や文字の読み取りを追加した構成では、その時間も別に記録すると、実務で待つ時間が見えます。
次は記録項目の例です。Decisions APIの応答仕様ではありません。数値を空欄にしているのは、未実行の結果を成功例として見せないためです。候補を一つ選べたかだけでなく、不要な障害調査へ回した件数、人が確認すべき問い合わせを見逃した件数も数えると、導入後の手戻りを比較できます。
{ "case_id": "C01", "run_at": null, "actual_model_id": null, "question_version": "routing-ja-v1", "image_version": "C01-v1", "observed_choice": null, "elapsed_ms": null, "matches_expected": null, "notes": "未実行。APIの返却形式ではなく検証記録の例"}6件は、試験の組み立て方を確認するための少量の教材です。これだけで日本語全体の精度や業務適性を評価することはできません。最初の試験で問いの曖昧さを直したら、学習や調整に使っていない別の入力を用意し、画像の解像度、文の言い換え、候補の順序を変えても扱いが安定するかを調べます。期待結果を見ながら調整した入力と、最終評価の入力は分けてください。
料金・公開範囲・confidenceは、まだ埋めない
確認時点で読めた公式発表は、限定プレビューと今後の公開予定を示すものです。今回の調査では、Decisions API専用の確定した料金表、呼び出し先と項目の完全な仕様、候補数の上限、日本語の保証範囲までは確認できませんでした。通常のLunaの料金を、そのままDecisions APIの料金として転載しないようにします。ChatGPTの契約に含まれるかどうかも、この発表だけでは決められません。
同じ理由で、Jevで扱うconfidenceがDecisions APIにも同じ形式・意味で返るとは書けません。候補ごとの確率や確信度を使う設計は、実際の返却項目と定義が公開されてから確かめます。項目の名前が同じでも、正解率や業務上の成功確率を直接意味するとは限りません。まずは取得できる実際の答えを、人が決めた期待結果と照合するところから始めます。
Decisions APIを検討する価値があるのは、すでに決まった少数の候補へ、文章や画面を基に振り分けたい仕事です。導入判断を急ぐなら、いま完成させられるのは質問・候補・期待結果の準備です。利用できるようになった段階で、その同じ課題を試し、必要な手戻りと費用を確認する。画像対応という新しさを、仕事の改善につなげるには、この順番が役立ちます。