メインコンテンツへスキップ
見出し画像

OpenAI Decisions API、とは?

    Jevの記事、割と読んでいただけてるみたいで有難い。のですが、やっぱ一過性かな、みたいな潮が引いてく感じもしていて。モデルひとつひとつを追っかけることにはあまり意味がないと理解しつつも、つぎのモデルを追っかけちゃうのもひとの性でしょうか・・・。きょうは、Decisions APIです。

    あ、いつも勉強させていただいている人気YouTuber海外Yパパさんの解説動画もリンクしておきますね。


    1. Decisions API の概要と設計思想

    OpenAI Decisions APIは、テキストや画像の生成を行わず「条件に対する型のついた判断(決定)」に特化したAPIです。

    • 従来の Responses API との根本的違い:

      • Responses API: テキスト生成、理由の解説、ツール呼び出し、システムプロンプト等に対応し自由度の高い出力を生成。

      • Decisions API: 自由テキストを一切出力せず、定義された選択肢や数値(確率・選択・スコア)のみを高速かつ型安全に返却。

    • パフォーマンスとコスト構造:

      • 処理速度はResponses APIと比較して約6〜10倍高速(ミリ秒単位の応答)。

      • 課金体系は入力トークン(Input tokens)のみであり、出力トークン費用やキャッシュ読み取り費用は発生しません(0.10ドル / 100万トークン)。


    2. 3つの基本質問タイプ(Question Types)

    Decisions APIでは、用途に合わせて3種類の質問タイプを選択・組み合わせます。

    1. Predicate(述語型):

      • 出力: 条件が真である確率(0.0 〜 1.0の確率値)。

      • 用途: 「バグ報告か」「顧客が怒っているか」「個人情報が含まれるか」等の単一条件の判定。

    2. Choice(選択型):

      • 出力: 定義した固定の選択肢(2〜255個)から最適解1つと、その信頼度(Confidence)。

      • 用途: 担当部署の自動振り分け(Billing, Technical, Account, Otherなど)。

    3. Score(スコア型):

      • 出力: 順序付けられたレベル(Low, Medium, Highなど)に対する確率加重平均値。

      • 用途: 障害・影響度(Severity)の連続的な数値評価。

    ※ 判定が拒絶された場合(Refusal)は個別の質問単位で返されるため、プログラム側で必ず返却値の型チェックを行う安全設計が必要です。


    3. 実践モデル「TriageDesk」の2段階ルーティング設計

    問い合わせサポートシステム「TriageDesk」では、効率性と精度を両立する2段階構成を適用しています。

    第1段階: 判定と一次評価(1リクエストで並列処理)

    1回のAPI呼び出しで、以下の4つの質問を同時評価します(約650トークン/件)。

    • 部署分類(Choice): Billing / Technical / Account / Other

    • 深刻度評価(Score): 顧客の損失(データ損失・金銭損失・システムブロック)基準でのスコアリング

    • フラグ検出(Predicate): 感情分析(Angry)および個人情報(Personal Data)の検出

    • 画像・画面解析(Vision): Base64エンコード画像(スクリーンショット)を直接入力。detail: low に設定することで、認識精度を保ちながらトークン消費を半減可能です。

    第2段階: アクション決定とReasoning連携

    1回目の結果要約と元テキストをコンテキスト(Evidence)として入力し、最適なネクストアクションを選択します。

    • 自動回答(reply_from_kb): ナレッジベースで解決可能な定型問い合わせ。

    • 詳細確認(ask_for_details): 情報不足(パスワードリセットの不着等)に対するヒアリング。

    • 人間へエスカレーション(escalate_human): 高リスク・怒り・データ損失・法的事項。

    • 思考モデルへ引き継ぎ(reason): 複雑かつ落ち着いた問い合わせに対し、Responses API(GPT-6.1 Soul等)を呼び出して担当者用の丁寧な対応案(下書き)を作成。


    4. 本番運用における信頼性・テスト・コスト・プライバシー

    • 確率値の取り扱いと選択肢の順序効果:

      • Predicateの出力確率は数学的に正しく較正(キャリブレーション)されています。

      • ChoiceのConfidenceは選択肢の「並び順」によって数値が変動するため、絶対的なリスク指標ではなく比較・順位付けとして扱い、選択肢の順序は固定して運用します。

    • 閾値設定と継続的テスト(Regression Test):

      • 実際の運用データ(ラベル付きチケット30件等)を用いて、偽陽性・偽陰性のコストを考慮した閾値(例: 感情判定0.9以上でエスカレーション)を設定します。

      • プロンプト文言の微修正やモデルの変更による判定崩れを防ぐため、pytestを用いた精度・閾値の回帰テストを実施します。

    • 運用コスト目安:

      • 10,000件のチケット分類で約0.64ドル(テキストのみ)〜1.32ドル(画像付き)と極めて安価です。

    • プライバシー・データ保護:

      • Zero Data Retention(ZDR)、米国・欧州でのデータレジデンシー、HIPAAコンプライアンスに対応しており、入力データがモデル学習に使用されることはありません。


    画像
    画像
    画像
    画像
    画像
    画像
    画像
    画像
    画像
    画像
    画像
    画像
    画像
    画像
    画像
     
     

    meat

     
     
    日英バイリンガルの日々の所感です。取り上げて欲しいテーマなどございましたら、コメントいただけたら嬉しいです。

    あなたへのおすすめ