世界を動かす技術を、日本語で。

Decisions APIがパブリックベータ版に入ります

概要

  • Decisions API はテキストや画像を評価し、10倍速く型付き回答を返すAPI
  • gpt-6-luna のみ対応、/v1/decisionsエンドポイント使用
  • 条件確率、選択肢、スコア評価が可能で、分類や優先度付けに活用
  • 入力はテキスト・画像・複数質問を柔軟に組み合わせ可能
  • 入力コストのみ課金、ZDR・HIPAA・地域処理対応

Decisions APIの特徴

  • テキスト・画像 または両方を評価し、型付き回答を高速返却
  • Responses API より約10倍速い応答速度
  • 返却される回答タイプ
    • predicate (条件判定):条件が真である確率(0~1)
    • choice (選択):指定した選択肢から1つを選び、確率分布も返却
    • score (スコア):順序付きレベルで評価し、確率加重平均値を返却
  • 利用例
    • コンテンツ分類
    • リクエストのルーティング
    • アプリ内タスクの優先順位付け

利用方法と構成

  • モデル :現時点でgpt-6-lunaのみ対応
  • 入力 :テキストまたはユーザーメッセージ(テキスト+画像)
  • 質問 :評価内容・タイプ・指示・選択肢やスコアレベルを指定
  • 回答 :各質問に一意なnameを付け、answers配列で返却

質問タイプの使い分け

  • predicate :条件式の真偽確率(例:画像内の損傷有無)
  • choice :選択肢からカテゴリ選定(例:担当部署の振り分け)
  • score :順序付き評価(例:不具合の深刻度)

具体的なリクエスト例

  • 画像判定(predicate)
    • 画像をbase64でインライン指定
    • 指示例:「亀裂・破れ・へこみ等の目に見える損傷があるか」
    • 回答例:probability: 0.92(損傷ありの確率)
  • 選択肢判定(choice)
    • クレーム内容に対し、「billing」「technical」「shipping」「other」等から選択
    • 回答例:choice: "billing", probabilities: 各選択肢ごとの確率
  • スコア評価(score)
    • 不具合内容に対し、「Cosmetic」「Workaround available」「Fully blocked」等で評価
    • 回答例:score: 1.1(加重平均)、各レベルの確率とconfidence

実装・設計上のポイント

  • 質問ごとにtype・name・指示・選択肢/レベルを明示
  • 1リクエストで複数質問を同時評価可能(依存関係がある場合は分けて送信)
  • 観察可能な基準 に基づき質問設計
  • 選択肢やレベルは明確に区別 し、説明文を付与
  • 閾値設定 は実際のアプリ事例に基づき調整(誤検出コスト考慮)

料金・データ管理

  • 入力トークンのみ課金 ($0.10/1M tokens、出力課金なし)
  • ZDR(Zero Data Retention)・HIPAA 対応、米国・欧州地域処理可能
  • SDKバージョン要件 :Python 3.26.0、JavaScript 7.30.0、Go 3.73.0、Ruby 0.101.0、Java 4.78.0以降

Decisions APIと他APIとの使い分け

  • Decisions API :確率・選択・スコア等、明確な型付き回答が必要な場合
  • Responses API Structured Outputs :独自JSONスキーマや説明文生成が必要な場合
  • function calling :ツール呼び出しや引数生成が必要な場合

利用上の注意点

  • 画像はbase64インラインURLのみ対応 (外部URLやfile_idは不可)
  • 質問設計時はカテゴリ網羅性に注意 し、「other」等のフォールバックを用意
  • Live API連携 で音声リクエストのアクション選択にも応用可能

Hackerたちの意見

Jevへの反応は、AIビジネスがコモディティ市場かどうかの決定打になるはず。突然現れたJevは、価格戦争の次のラウンドを引き起こした。JevはSystem Oneモデルの価値を示したんだ。速いyes/no/信頼度スコアは安価なだけじゃなくて、ほとんどの人が求めているものでもある。オープンソース版がHugging Faceに溢れていて、今や大手も顧客を維持するために出力トークンの大きなドライバーを手放して、価格競争に突入している。もし私がOpenAIやAnthropicなら、できるだけ製品を魅力的にするために急いでると思う。そうしないと、みんな安い方に流れちゃうからね。

└

もし私がOpenAIやAnthropicなら、できるだけ製品を魅力的にするために急いでると思う。そうしないと、みんな安い方に流れちゃうからね。 できれば、みんながコモディティ化を目指して、置き換えやすい製品に流れてくれるといいな。もう一度、無料の入り口、100ドル/TBの出口のクラウドみたいな状況は避けたい。

└

モデルを切り替えるのに2回のキー入力だけで済む。もっと粘り気のない製品は知らないな。

└

でも、OpenAIとAntはビジネスのコモディティ部分だけじゃなくて、もっといろんなことができると思う。フロンティアモデルや、ネットワーク効果とかで競争が厳しくなるような粘着性のある製品も作れるはず。

curl https://api.openai.com/v1/decisions \ -H "Authorization: Bearer $(llm keys get openai)" \ -H "Content-Type: application/json" \ --data ' { "model": "gpt-6-luna", "input": [{ "role": "user", "content": [ {"type": "input_text", "text": "新しい製品機能に怒っている"} ] }], "questions": [{ "type": "predicate", "name": "complaint", "instructions": "これはクレームですか?" }, { "type": "predicate", "name": "compliment", "instructions": "これは褒め言葉ですか?" }] }' 返された内容: { "model": "gpt-6-luna", "answers": [ { "type": "predicate", "name": "complaint", "probability": 0.91 }, { "type": "predicate", "name": "compliment", "probability": 0.06 } ], "usage": { "input_tokens": 310, "input_tokens_details": { "cached_tokens": 0, "cache_write_tokens": 0 }, "output_tokens": 0, "output_tokens_details": { "reasoning_tokens": 0 }, "total_tokens": 310 } } この https://api.openai.com/v1/decisions エンドポイントは注目すべきだね。通常、OpenAIがこういうエンドポイントを定義すると、他のプロバイダーのデファクトスタンダードになることが多いから。(これを新しいllmプラグインにしたよ: https://github.com/simonw/llm-openai-decisions)

└

これってML時代の分類モデルと何が違うの?

└

他のプロバイダーのデファクトスタンダード。ちょっとしたタイプミスだけど、朝から笑っちゃった :)

Jevは本当に業界を揺さぶったね。振り返ると、これは明らかだ。

└

これらは非常にシンプルな決定のためのものだね。現実の問題はもっと複雑で、多くの出力属性やサブ構造をカバーする高度に構造化された出力が必要なんだ。そういう場合、文書化されたスキーマを使った従来の構造化出力の方が良いよ。もし代わりに、意思決定APIに20回独立して呼び出しをしたら、20の決定の間で一貫性を失うことになる。だから、意思決定に関する盛り上がりはすぐに忘れられると思うよ。

OpenRouterを使ってJevとMercury Decideに対して、私の決定評価を実行した(まだ初歩的で600回未満の呼び出し、UIコンポーネント選択、チャットチャート、タグ選択、PKM関連)。Jevはその手頃さで私のmt0の努力を置き換えたし(特に、MacBook Neoでの制限は語彙のプルーニングや量子化の狂気の後でもある)、Mercury DecideはdLLMの取り組みが好きだから使ってる。もちろん初期段階だけど、Jevより遅くて、Mercury Decideのレイテンシーに似てるけど、入力量に対して線形に増加するわけじゃない(p50で346ms、p95で860ms、Mercury Decideも極端な場合は1.3秒まであったけど、今日は800msくらいで、サイズに対してはもっと一貫してスケールしてた)。私のあいまいなUIコンポーネントやレスポンス形状特定タスクに関しては「信頼性」が低くて(これらのモデルには非常に特定のユースケースがあって、Lunaは0.6以下ではよく失敗する)、競合他社はどちらも持っていなかった失敗した呼び出しがいくつかあった(4対0)。さらに、Jevよりも平均して3.1倍高かった。Mercury Decideの価格はまだ不明だから、そこは数字がないけど。要するに、Jevより遅くて、高くて、能力が劣る。Mercury Decideと大体同じくらいだけど、私の狂ったユースケースと要件(PKMに特化したFirefoxのフォークで、複数の無限キャンバスを使って情報合成を改善するための意思決定モデルを使用)を考慮すると、全体的にちょっと未熟な感じ。フロンティアラボは、価格やパフォーマンスで競争力のあるものを提供できるまで、流行に乗るべきじゃないと思う。公平を期すために言うと、画像入力のテストはまだしてないから、もしかしたらそれが全てを変えるかも。あと、私のはみんなのユースケースを反映してるとは限らないから、他の人の結果も見てみたい。あの時はコメントしなかったけど、Devdayのことを後で読んでみると、そういうことがたくさんあったみたい。NotionやGDocs、Jev、Muse、ほとんどが既存の競合からクローンされた感じだし(無限で超高速、超コードトークンのunsandboxed Mega Astraもそれほどすごくないし)。発表は少なくて、集中して高品質であってほしい。ChatGPT Atlas(彼らのChromiumベースのブラウザ)とその異常に早い死を考えると、これらのどれかに多くを投資するのは懐疑的だね。もし何かの改善があったとしても。

└

こういうのをリリースするのは、たとえまだ未完成でも意味があると思う。まだすごく安いし、既存の企業向けOpenAIとの関係があれば、Jevの新しい契約を結ぶよりもずっと簡単にオンボードできるからね。これらのモデルがどうなるかはオープンな質問だけど、既存のプロバイダー契約や利用規約は企業にとって重要だよ。

└

Luna DecideがJevよりも一般的に能力が劣るとは思えない。Jevは私が与えた新しいドメインを理解できなかった。データがないよりは「いくらかのデータ」の方がいい時だけ使ってるって感じ。

Hacker Newsで議論の続きを見る