私たちはすでに、TypeSafeの新しい意思決定モデルを、Mavenのあらゆる会話に組み込まれている判断処理で検証しています。チケット分類、Intelligent Fields、品質チェックもその対象です。初期の社内テストでは、分類処理において現行の手法より約12倍高速に動作し、同じリクエストに分類項目を追加しても処理が遅くなることはありませんでした。
1つの問い合わせには複数の判断が含まれる
たとえば、顧客から次のような問い合わせが届いたとします。「請求額が2倍になり、チームの半数がログインできません。明日の契約更新までに解決してほしい。」
この問い合わせを解決するには、いくつもの作業が必要です。エージェントは請求とアクセスの問題を認識し、緊急度を把握し、顧客のアカウントを確認し、適切なポリシーに従わなければなりません。人が対応する必要がある場合は、引き継いで対応を続けられるだけのコンテキストとともに、適切なチームへ会話を届ける必要があります。
こうした作業の中には、推論や説明が必要なものもあれば、直接の照会で済むものもあります。また、焦点を絞った判断に帰着するものもあります。どのような問題が含まれているのか、どの程度緊急なのか、顧客が担当者との対応を求めているかどうか、といった判断です。
Jevが注目に値するのは、この最後のカテゴリーです。
Jevが早期アクセスを終えた時点で、私たちは音声モデル向けに構築したのと同じ評価プロセスでJevの検証を始めました。このような主張は、ベンダーのベンチマークだけでなく、顧客の実際のワークフローでどう機能するかに照らして確かめる価値があるからです。
Jevは分類器に似ていますが、ひと味違います。コンテキストと範囲の限定された質問を与えると、選択肢、スコア、確率を返します。TypeSafe AIの新しいモデルは、ソフトウェアがそのまま利用できる構造化された判断を返すよう設計されています。Mavenのようなエンタープライズプラットフォームにとっては、顧客の問い合わせから解決に至るまでの間にある数多くの判断を改善する機会となります。
JevはLLMと何が違うのか
TypeSafeはJevを「System One」モデルと呼んでいます。開発者はコンテキスト、質問、そして回答の候補を指定します。Jevは選択肢、スコア、確率を返します。同じコンテキストに対する複数の独立した質問を並列で評価できます。LLMのように自由形式のテキストを生成することはありません。
先ほどの問い合わせであれば、請求に関する問題が含まれているか、アクセスがブロックされているか、顧客が期限を示しているかをシステムが質問できます。それぞれの回答が、ワークフローの次のステップへの入力になります。
従来のLLMでも、スキーマに沿った出力を生成することはすでに可能です。Jevの特徴は、この用途に特化して構築されたモデルであることです。並列での出力生成に加え、TypeSafeが「Reinforcement Learning for Calibrated Decisions」と呼ぶトレーニングを採用しています。その狙いは、低レイテンシーと低コストを実現しつつ、不確実性をソフトウェアにとって有用なものにすることです。
早期ユーザーからも、特定のタスクで大幅な高速化が報告されています。私たちのテストでは、Jevは現行の手法より約12倍速く結果を返しました。ただし、これは初期のプロトタイプ段階の結果でありベンチマークではありません。また、顧客向けの本番環境では稼働していません。ほかの企業も、それぞれのタスクで同様の数値を報告しています。VercelのGuillermo Rauch氏は、自社のエージェントが実行するコマンドの安全性レビューにおいて、95パーセンタイルで最大18倍の高速化を計測しました。精度も、置き換え前のGPT-5.6-Lunaによるレビューを上回っています。
Intelligent Fieldsは評価に最適な領域
Mavenは2026年春にIntelligent Fieldsをリリースしました。チームは、製品領域、感情、返金の意向、エスカレーションの兆候など、会話から把握したい項目を定義します。生成されたフィールドは、レポート、ルーティング、エージェントの設定に活用されます。
現在のIntelligent Fieldsの強みは、ユーザーの負担がほとんどないことです。知りたい内容を平易な言葉で定義するだけで、Mavenがすべての会話をその定義に照らして評価します。ラベル付きのトレーニングデータは不要で、ラベルごとにモデルを保守する必要もなく、アナリストが1週間後に手作業でチケットにタグ付けすることもありません。各値には信頼度スコアとその根拠が付与され、APIや分析ビューから確認できます。そのため、ラベルを鵜呑みにするのではなく、なぜその会話が解約リスクと判定されたのかを人が監査できます。
各フィールドは、設計上それぞれ独立して評価されます。この分離によって、会話全体について誰も監査できない1つの総合的な判定を下すのではなく、各値に個別の信頼度スコアと根拠を付与できるのです。
Jevのような意思決定モデルは、この構造にすっきりと適合します。同じコンテキストに対する独立した質問は並列で評価されるため、複数のフィールド評価を1つのリクエストにまとめても、それぞれ個別にスコア付けされた回答として返されます。出力の形式は変わりません。変わるのは、同時に処理できる質問の数です。
そのため、Jevを導入してもIntelligent Fieldsの動作が変わるとは考えていません。一方で、効率の向上とコストの削減は期待しています。
| 会話に関する質問 | 意思決定モデルによる処理 | 実現できること |
|---|---|---|
| どの製品領域に関する内容か | 定義済みのカテゴリーから選択 | 需要を分類し、関連するガイダンスを選択 |
| 報告された問題の深刻度はどの程度か | 明確な評価基準に基づいてスコア付け | 実際の影響度に応じて作業の優先順位を決定 |
| 顧客が担当者との対応を求めているか | その記述が正しいかどうかを推定 | エスカレーション対応の判断材料にする |
| この問い合わせにはどのような問題が含まれているか | 候補となる問題をそれぞれ個別に評価 | 1つの会話に含まれる複数の意図を漏れなく把握 |
これらは評価対象となる候補の対応付けです。Jevには、各フィールドの意味と、それに依存するワークフローの動作を維持することが求められます。出力の範囲が限定的である点も重要です。自由形式の要約や文章による説明には、引き続き生成モデルなど別の手段が必要になります。
この機会が特に大きな意味を持つのは、チームが各インタラクションからより詳細な情報を得たい場合です。評価1件あたりのコストが下がれば、新しいフィールドを追加するたびに高コストなモデル呼び出しが増えることなく、製品の問題、解約理由、エスカレーションの兆候を追加で追跡しやすくなります。
リリースから間もないモデルをエンタープライズ顧客に提供することはありません
ここまでの内容はすべて、検証と設計上の検討です。Jevはどの顧客のワークフローでも稼働していません。数日前にリリースされたばかりのモデルは、新しいモデルすべてに適用しているのと同じ評価プロセスを経るまで、顧客のワークフローに組み込むことはありません。GPT-Live-1をはじめとする音声モデルの検証方法もご覧いただけます。私たちは、あいまいなケースや判断に必要なコンテキストが欠けているケースを含む代表的な事例で、現行の手法と判断の質を比較します。そのうえで、実際のルーティングに適用する前に、レイテンシー、採用された結果1件あたりのコスト、顧客への成果を比較します。
エンタープライズ業務におけるモデル選択肢の拡大
Jevは、エンタープライズ向けAIエージェントを構築する際の選択肢を広げます。会話、推論、分類、検証では、それぞれ求められるモデルの要件が異なる場合があります。
Mavenにとっての機会は、顧客の問い合わせを解決するために必要なコンテキストと制御を維持しながら、Intelligent Fieldsなどの機能をより効率化できる領域でJevを評価することです。
判断の繰り返しが体験を遅くしているワークフローがあれば、ぜひMavenにご相談ください。キューを何度も移動するチケット、評価コストの高いフィールド、実行が遅すぎる品質チェックなどです。新しいモデルが真価を発揮するのは、まさにそうした場面です。
これを迅速に実現できるのは、Charters、Segments、Intelligent Fieldsによって、重要な判断がすでに定義されているからです。その下でより高速な判断レイヤーに切り替えることは、数日で検証できる設定変更にすぎず、数四半期をかけた再構築は必要ありません。
自社の会話でお試しください。
無料の個別デモをお申し込みください。
