Perplexity Decider v1.3は、文章生成ではなく、分類・採点・抽出・ルーティングの判断結果を確率つきで返すdecision modelです。2026年11月時点では、Decider v1.3と小型のDecider Flash v1.3がHugging Face、OpenRouter、Perplexity Decisions APIで提供されています。社内AIシステムの『LLMに判定させてJSONをパースする』処理を置き換える候補です。
この記事では、公式発表とDecisions APIドキュメントをもとに、導入担当者が見るべき変更点、費用、評価方法、セキュリティ用途、30日PoCの進め方を整理します。
Perplexity Decider v1.3とは？生成ではなく判断を返すモデル
Deciderは、入力内容を読んで自由文を作るモデルではありません。stateとして渡したテキスト、JSON、画像に対して、yes/no、選択肢、スコア、locate抽出の質問を並べ、回答の確率を返します。『この問い合わせは営業リードか』『この回答は根拠に忠実か』『個人情報は含まれるか』を、1回のリクエストでまとめて判定できます。
v1.3では、Decider v1.3とDecider Flash v1.3が公開されています。大きいモデルはQwen3.8-27B系、小さいFlashはQwen3.5-4B系をもとに蒸留され、どちらもApacheライセンスでHugging Faceに公開されています。
何が変わる？5項目で見る導入判断
1つ目は、LLM出力のパース依存を減らせる点です。従来はチャットモデルに『JSONで答えて』と頼み、失敗時の再試行やスキーマ修正が必要でした。Deciderは最初から確率、選択肢、スコア、span位置を返すため、しきい値や承認ルールをコード側で管理しやすくなります。
2つ目は、複数質問を同じstateにまとめられる点です。3つ目は、locate機能により、PII検出や契約書の当事者抽出のような『どこに書いてあるか』まで返せることです。4つ目は検索やRAGのreranking、5つ目はmoderation、phishing、prompt injection、tool outputs検査への応用です。
費用とAPI設計：1M入力トークン課金をどう見るか
Decisions APIのDocsでは、Decider v1.3とv1.2は100万入力トークンあたり0.02ドル、Flash v1.3とFlash v1.2は100万入力トークンあたり0.01ドルと説明されています。出力トークンは無料で、web groundingを使う場合は1,000回のWeb検索またはURL fetchあたり1ドルが追加されます。
この料金体系では、長い文書を何度も別々に判定する設計がコスト増の原因になります。まずはstateを短く整形し、1回のリクエストに複数質問をまとめ、Flashで十分なタスクと大きいDeciderが必要なタスクを分けるのが現実的です。
評価値の読み方：91.6%だけで採用を決めない
Perplexityは、社内の63分類タスクでDecider v1.3が平均91.6% accuracyとなり、本番classifierを6.54ポイント上回ったと説明しています。さらに、7領域のdomain-specific classification、19言語・46,484例のmultilingual benchmark、17件のlocate評価、5件のvision分類評価も示しています。
ただし、自社導入ではaccuracyだけで採用を決めないほうが安全です。営業リード判定ならfalse negativeを抑えたい一方、個人情報検出なら漏れを減らす必要があります。PoCではprecision、recall、しきい値別の人手確認件数、誤判定時の業務影響を一緒に記録します。
30日PoCの進め方：分類・抽出・監査を分けて検証
最初の1週間は、対象タスクを3つ以内に絞ります。おすすめは、問い合わせ分類、RAG回答の忠実性チェック、個人情報のlocate抽出です。各タスクで100〜300件の過去データを用意し、人間の正解ラベル、既存LLM判定、Decider判定を並べます。
2週目はAPI実装です。stateを全文投入するのではなく、判定に必要な項目だけをJSONに整理します。3週目はしきい値を決め、0.8以上は自動処理、0.5〜0.8は人手確認のように運用ルールへ落とします。4週目は監査ログ、費用、失敗例をレビューします。
導入前チェックリスト：管理者が見る5つの論点
確認すべき論点は5つです。1つ目は、判定対象データに個人情報や機密情報が含まれるか。2つ目は、APIへ送るstateを最小化できるか。3つ目は、しきい値を誰が変更できるか。4つ目は、誤判定時に人間が戻せる業務フローがあるか。5つ目は、モデルや価格が変わったときに再評価できるテストセットが残っているかです。
AIエージェントやMCPツールの前段に入れる場合、Deciderの判定は『実行してよい』という許可に近い意味を持ちます。確率が高いから即実行ではなく、重要操作では承認、低リスク操作では自動化、ログは後から追える形にするのが安全です。
FAQ：Perplexity Decider v1.3のよくある疑問
Q. ChatGPTやClaudeに分類させるのと何が違いますか？ A. 自由文ではなく確率つきの構造化された判断を返す点です。自然言語で理由を説明する用途には通常のLLMが向きますが、ソフトウェアが次の処理を選ぶ用途ではDeciderのほうが扱いやすい場面があります。
Q. 日本語でも使えますか？ A. 公式発表では、日本語を含む8言語の評価が紹介されています。ただし、日本語の業務文書で使う場合は、自社データで精度と誤判定傾向を必ず確認するべきです。
Q. すぐ本番導入してよいですか？ A. いいえ。まずは人手判定と並走させるのが安全です。問い合わせ振り分けやRAG回答チェックのように、失敗時の影響を限定できるところから始めると検証しやすくなります。
まとめ：判断モデルはAIワークフローの制御面になる
Perplexity Decider v1.3のポイントは、文章生成AIをもう1つ増やすことではなく、AIワークフローの制御面を作れることです。問い合わせをどの担当に回すか、どの検索結果を上位に置くか、どのツール実行を止めるかを、確率としきい値で管理できます。
