ユースケース
Decisions API によるリクエストルーティング
ルーティングは有限の決定です：どのキューか、どの優先度か、人か自動化か。デシジョン呼び出しは選択結果に加えて全選択肢の確率を返すので、自信のあるケースは自動割当し、残りはトリアージへ回せます。
更新日
ルーティングが自然に合う理由
ルーティングが問うのは有限の質問——どのキューがこれを担当するか——であり、それはまさにデシジョンエンドポイントがネイティブに答えるものです。生成テキストからキュー名を解析する必要も、存在しない5番目のキューを発明させないプロンプト工夫も要りません。
1回の呼び出しで同じチケットに複数の質問を載せられるので、キュー、緊急度、要レビューフラグを1往復・1クレジットで解決できます。
- キュー割当：billing、platform、account、other
- 優先度：低からblockingまでの順序付きスコア
- エスカレーション：人が先に見るべきかの noul チェック
criteria はキューの説明として書く
choice 質問の各オプションには「何がここに入るか」の短い説明を付けます。新しいトリアージ担当へのブリーフのように書いてください——その説明がルーティングポリシーです。
必ず「other」や「unclear」オプションを入れてください。モデルに正直な逃げ道を与えることで、曖昧なチケットが自信ありげに誤振分けされるのを防げます。
1回の呼び出し：キューと緊急度
チケット本文を state として送り、2つの質問をします：担当チームを選ぶ choice と緊急度を測る score。応答には answers.team.choice、answers.urgency.score、そして両方の全選択肢の確率が入ります。
1リクエストで choice + score
// Route a ticket: ask for team + urgency in one call,
// then gate the automation on confidence.
const res = await fetch("https://decisions-api.net/api/v1/decisions", {
method: "POST",
headers: {
Authorization: "Bearer YOUR_KEY",
"Content-Type": "application/json",
},
body: JSON.stringify({
model: "decisions-1",
state: "Payments fail with a 500 since your last deploy. Enterprise plan customer.",
questions: {
team: {
type: "choice",
instructions: "Which queue should handle this request?",
criteria: {
payments: "Billing, charges, or payment failures.",
platform: "Deploys, infrastructure, or API errors.",
account: "Login, SSO, or permissions.",
other: "Unclear or out of scope.",
},
},
urgency: {
type: "score",
instructions: "How urgent is this for the customer?",
criteria: ["can wait", "normal queue", "needs attention today", "blocking revenue"],
},
},
}),
});
const { answers } = await res.json();
// Illustrative response: answers.team -> { choice: "payments", confidence: 0.84 }
// answers.urgency -> { score: 3, confidence: 0.79 } (0 = lowest level)
if (answers.team.confidence >= 0.8 && answers.team.choice !== "other") {
assignToQueue(answers.team.choice, { priority: answers.urgency.score });
} else {
assignToQueue("human_triage", { note: "low confidence" });
}confidence で自動割当をゲート
自動化して安全にできるのは確率分布があるおかげです。現実的な初期値：confidence が 0.8 以上なら自動で割当、それ未満は人のトリアージキューへ。
閾値は自分のチケット履歴で調整してください——誤振分けのコストと遅延のコストの比で決まります。
モデル間でリクエストをルーティングする
同じパターンで、どのモデルが答えるべきかも選べます。choice 質問の選択肢として fast_model（短い事実確認や整形のリクエスト）、strong_model（多段の推論、コード、長いコンテキスト）、human（法律、返金、モデルが単独で答えるべきでないもの）を設定します。どの選択肢にも確率が返るので、割り振りがどれほど接戦だったか分かります。
ゲートのかけ方も同じです：確信度が低いときは、トップの選択肢を信じる代わりに人や安全側の経路へ回します——次点の確率が、その判断の接戦具合を教えてくれます。
コストと量
成功した呼び出しは1回につき1クレジット——1問でも6問でも同じです。過去チケットのバックログには、ダッシュボードのバッチツールで同じリクエスト形状を CSV/JSONL に流せます。
よくある質問
何個のキューに振り分けられますか？
choice 質問は2〜8個のオプションを取れます。それ以上のキューには段階的に：最初の呼び出しで部門を選び、次の呼び出しで部門内のチームを選びます。
同じ呼び出しで緊急度も判定できますか？
はい——順序付きレベル説明の score 質問を追加します。1回に最大6問なので、キュー・緊急度・エスカレーションフラグをまとめて解決できます。
境界線上のチケットはどうなりますか？
回答には全選択肢の確率が入ります。上位2つが近いとき——例えば0.45対0.42——曖昧とみなして人のトリアージに回し、勝者を盲信しないのが安全です。
英語以外のチケットでも動きますか？
state とオプション説明はチケットの言語のまま書き、オプションのキーだけ ASCII にしておくとルーティングコードが読みやすくなります。
どの LLM がリクエストに答えるかを選べますか？
はい——choice 質問の選択肢にモデルを並べ、それぞれの得意分野を説明します。確信度が低いケースは強いモデルにルーティングしてください。
今すぐチケットをルーティング
新規訪問者は1回無料——実際のチケットをプレイグラウンドに貼って確率を読んでください。