OpenAI Decisions API入門：AIの分類とスコアを業務フローにつなぐ方法

AIアプリは文章、コード、説明を生成する能力を高めています。一方、本番システムが必要とするのは、もっと限定された判断であることが多いでしょう。たとえば、この問い合わせは請求担当か技術サポートか、画像に破損があるか、問題の重大度はどの段階か、といった質問です。OpenAIのDecisions APIは一般提供になり、このような境界のある判断を対象にしています。

違いは重要です。汎用的な回答は魅力的でも検証しにくい場合があります。決定用のエンドポイントは、型のある回答、確率分布、次の処理を決めるスコアが必要なときに役立ちます。公式のDecisionsガイドと決定作成APIリファレンスでは、テキスト、画像、JSONを述語・選択・スコアの質問で評価する方法が説明されています。

本質的な変化は型付き判断レイヤー

多くのチームはすでに「この依頼を分類してください」というプロンプトを持っています。弱点は必ずしもモデルではなく、その周囲の契約です。自由な段落を返せるプロンプトでは、後続コードが文章を解析し、信頼度を推測し、例外を処理しなければなりません。

Decisions APIでは質問を明示します。述語は条件が真かどうかを尋ね、確率を返します。選択は、billing、technical、otherのように定義した値から一つを選びます。スコアは「外観上の問題」「回避策あり」「完全に停止」のような順序付きレベルで評価します。結果は確率的ですが、アプリケーションは実行前にその形を検査できます。

これにより、AIは単独のモデル呼び出しから、小さなポリシー境界へ変わります。許可する結果、カテゴリを分ける説明、そして人間のレビューへ送る条件をアプリ側で定義できます。

どんな判断に使えるのか

最も分かりやすい用途はルーティングです。サポートメッセージを選択質問とともに送り、対応キューへ振り分けつつ、分類外のためにotherを残せます。モデレーションや信頼性の処理では、述語で目に見える属性を確認できます。運用チームはスコアで障害の深刻度を評価し、危険度の高いものを優先できます。

画像にも意味があります。共有入力に基準画像を置き、質問ごとに候補画像を比較できます。商品検査、カタログ整理、文書レビュー、目視品質管理などに向いています。JSON入力も使えるため、構造化されたレコードを長い文字列へ変換する必要がありません。

現在のガイドでは、共有入力のキャッシュ、1リクエストあたり最大400問、公開HTTP/HTTPS画像URLとインラインのデータURLも紹介されています。これらは評価を不要にしませんが、バッチ型の判断サービスを設計しやすくします。

本番アーキテクチャでの役割

Decisions APIはすべてのモデル呼び出しを置き換えるものではありません。述語、固定選択、順序付きスコアならDecisionsを使います。独自のJSON Schemaに従う複雑なオブジェクトなら、Responses APIのStructured Outputsが向いています。モデルに引数付きツールを要求させるならfunction callingを使います。

実装の流れは、証拠を収集して正規化する、重ならない狭い質問を作る、アプリケーションコードで閾値を適用する、不確かな例を人間または広い推論処理へ送る、質問の版・確率・最終行動を保存する、という形です。

レビュー経路は安全弁です。信頼度は保証ではなく、分類体系が不完全だったり証拠が曖昧だったりすれば高い確率でも誤る可能性があります。APIの役割は、曖昧さを隠すことではなく、扱える形にすることです。

開発者が始める実践手順

まず実際の業務から小さなラベル付きデータを集め、偽陽性と偽陰性のコストを書き出します。質問は曖昧な意図ではなく、観察できる基準に合わせて定義します。カテゴリが重なるなら、モデルを複雑にする前に説明を改善します。

サポート振り分けは4〜5個のキューと明確なフォールバックから始められます。画像検査では、破損、カテゴリ、重大度を一つの巨大な質問に混ぜず、独立した条件ごとに述語を作ります。優先度付けでは2〜10段階の順序を定義し、隣り合う段階の違いを具体化します。

データの変化も監視してください。製品名、サポート方針、画像の分布は変わります。レビュー用サンプルを残し、人間のラベルと比較し、誤りのコストが変わったら閾値を調整します。関連するソフトウェアを探す場合はBTTCのソフトウェアカタログやBTTCテクノロジーブログも利用できます。

実装では、質問を増やす前に観測可能な入力を整理することも大切です。たとえば画像検査なら、照明条件、画像サイズ、対象物の向きを記録し、モデルの判断と一緒に保存します。サポート分類なら、過去の担当者による変更履歴を残して、カテゴリの定義が変わった時期を追跡できるようにします。こうした運用データがあると、単に精度を一つの数字で見るのではなく、どのケースでモデルが迷うのかを確認できます。

また、最初から完全自動化を目指す必要はありません。高い確率のケースだけを自動処理し、境界付近のケースをレビューへ送る段階的な導入なら、業務への影響を抑えながら価値を測れます。質問やスコアの定義をバージョン管理し、変更後に同じ評価セットを再実行することで、改善と回帰を区別しやすくなります。

評価用データには、簡単な成功例だけでなく、似たカテゴリ、画質の悪い画像、情報が欠けたJSON、そして分類外の入力も含めます。こうした難しい例を先に決めておくと、リリース後に予想外の入力でルールが崩れるリスクを減らせます。結果を定期的に人間が確認し、質問文の変更と実際の業務結果を同じ記録で追えるようにすることも重要です。小さな評価表でも継続すれば、改善の根拠をチームで共有できます。

限界と安全対策

型付きの回答は検証済みの事実ではありません。確率だけで取り消せない操作を許可しないでください。認証情報はサーバー側で管理し、返却値を検証し、モデルと質問の版を記録し、画像や顧客情報をプライバシー要件に従って保護します。

モデルに送る説明も、業務責任者がレビューできる形にします。なぜその入力がカテゴリに入るのか説明できないなら、モデルが自動的にポリシーを明確にすることはありません。

よくある質問と回答

Decisions APIはStructured Outputsと同じですか？

いいえ。Decisionsは述語、固定選択、順序付きスコア向けで、Structured Outputsは独自スキーマに従う複雑なオブジェクト向けです。

画像を分析できますか？

はい。共有入力または個別の質問指示に画像を含められます。

すべての回答を自動実行してよいですか？

いいえ。ラベル付きデータで閾値を調整し、フォールバックや人間のレビューを残してください。

小規模チームには何が便利ですか？

モデルの判断を予測可能な分岐へ変換する接着コードを減らせます。小さく始め、測定し、根拠が得られた範囲だけ広げられます。

まとめ

Decisions APIはマルチモーダルAIと通常のアプリケーションロジックを近づけます。開発者は型付きの質問を定義し、不確実性を見える状態で扱えます。サポートのルーティング、画像検査、トリアージなど、次の行動が文章の美しさより重要な処理に適した実用パターンです。