こんにちは、Jin Chenma です。
まずは質問から始めましょう。私たちが普段目にする AI 大規模モデルは、処理するコンテンツの種類において、一般的にどのようなタイプがありますか？
多くの人はテキスト、画像、音声、動画に慣れ親しんでいるでしょう。過去数年間、各ベンダーがこれらの分野で絶えず競い合い、進化を続けてきました。その結果、性能は向上し、競争は激化しています。
数々のアップデートを見てきた中で、私はずっと疑問を抱いていました。「既存のモデルを強化するだけでなく、新しい形態のモデルは生まれるのだろうか？」と。
最近、「Jev」というモデルが話題になっています。最初は「また別の会社が新しい LLM をリリースしたのか」と思いました。
しかし、深く調べてみると、このモデルは本当に印象的でした。
開発元の TypeSafe AI は、「System One Models（システムワンモデル）」というクラスのモデルを提唱しています。これはソフトウェアにおける判断タスク専用に設計されたものであり、Jev は彼らが公開した最初のモデルです。
従来のカテゴリー（テキスト、画像、音声、動画）はコンテンツの種類によって分類されていましたが、今回は視点を変えています。「判断を下すこと」自体を独立したタスクとして捉え、それ専用にモデルを設計したのです。
この方向性は、AI モデルの今後の発展や分業体制に深い影響を与える可能性があると私は考えています。
本記事では、Jev が何なのか、標準的な LLM とどう異なるのか、どこで活用できるのか、そしてどのように始めるのかを明確に解説します。
QR コードのアナロジーから始める
Jev をどのように理解すればよいでしょうか？ QR コードを生成したい場合を想像してみてください。
通常なら、QR コード生成ツールを使いますよね。しかし仮に、何でも描けるアーティストを雇って、ピクセル単位で QR コードを描かせるとしたらどうでしょう。
もちろん、熟練したアーティストなら可能です。でも、QR コードには専用のツールがあるはずです。必要なのは機能する QR コードであって、風景画付きの芸術作品ではありません。
同様に、Jev と大規模言語モデル（LLM）を比較してみましょう。
LLM は記事を書き、コードを書き、複雑な問題について議論できます。もし LLM にコメントを読ませてユーザーの感情を判定させれば、それは確かに可能です。
しかし、タスクが単なる選択肢の選び出しやスコアリングだけで済む場合、こう考えられますか？ 「そのようなタスク専用に、より高速で安価、かつプログラムからアクセスしやすいモデルを作れないだろうか？」
まさにこれが Jev の役割です。
Jev は自由形式のテキスト生成を捨て、回答範囲が明確な「判断」に特化しています。 例えば、「満足」「不満」「混在」「不明確」という 4 つの選択肢を提供すると、そのうち一つを選択し、各選択肢に対する確率も提示します。
QR コードに専用ツールがあるように、選択やスコアリングのみを必要とするタスクは、専門的なモデルで処理すべきなのです。公式の説明によると、Jev はこうした判断タスク向けに最適化されており、レスポンスタイムとコールコストを削減します。
例えば、膨大な EC コメントを毎日フィルタリングする場合、感情、緊急性、対応方法を判断する必要があります。判断が速く安価であれば、全体の待ち時間とコストを削減できます。プログラムは結果を受け取り、分類作業や人間への引き継ぎへと進みます。
Jev の起源
Jev は誰が作ったのでしょうか？ なぜ判断専用のモデルを作る必要があるのでしょうか？
Jev は TypeSafe AI によるものです。創業者の Diogo Almeida 氏は、以前 OpenAI でチャットモデルの研究に従事していました。
彼は次のような課題に注目しました。「AI は会話上手だが、なぜこれらの機能をソフトウェアに統合して自動化タスクに組み込むのは難しいのか？」
ソフトウェアは明示的なルールの実行に優れています。「条件 A が満たされれば、アクション B を行う」といった具合です。しかし、現実世界の多くの判断はルールで事前に定義するのが困難です。
コメントを読むことを例にとりましょう。どの表現が苦情なのか？ どれがジョークなのか？ 一見ポジティブだが隠れた批判を含んでいるものは？ いくつかのルールだけでユーザーのあらゆる言い回しをカバーするのは至難の技です。
TypeSafe は、意味論的な判断を呼び出し可能なコンポーネントにしようとしています。プログラムがテキストを理解したり、次のステップを選択したりする必要が生じた際、この小さなタスクをモデルに委譲し、結果を得て、そのまま実行を継続するという仕組みです。
彼らはこれを System One（システムワン）と呼んでいます。『ファスト&スロー』で知られる概念を借用しており、素早く直感的な判断を行う部分と捉えてください。
Jev という名前は、経済学者のジェボンズ（Jevons）に由来します。チームの期待はシンプルです。「インテリジェントな呼び出しのコストが下がれば下がるほど、人々はそれをより多くの場所で使うようになる」というもの。
以前は、単一の AI 呼び出しとしては高すぎると感じられていたステップも、判断が十分に速く安くなれば、再検討する価値が出てきます。
Jev は LLM とどう違うのか？
ソフトウェアからの AI 判断呼び出しをより安く、簡単にすることは良い出発点です。しかし、既存の LLM も判断を行い、構造化された結果を返すことができます。なぜわざわざ Jev を作るのでしょうか？
まず、LLM がプログラムに判断結果をどのように渡すかを見てみましょう。
LLM は構造化出力をサポートしており、答えを事前に定義されたスロットに収めることができます。例えば、感情用のスロット、緊急性用のスロット、対応方法用のスロットなどです。プログラムはそれぞれの位置が何を表しているかを把握しています。
JSON についてはご存知かもしれません。構造化データの一般的なフォーマットです。開発者は LLM の出力が特定のフォーマットに従うよう制約を加えることができます。
つまり、最終的な出力がテキストか JSON かだけを見ても、Jev と LLM の主な違いはわかりません。
違いは、モデルが結果を「どのように生成するか」にあります。
標準的な生成型 LLM は、通常、トークンごとに答えを生み出します。トークンはモデルが処理するテキストの小さな断片です。固定フォーマットのデータを要求しても、通常は一歩ずつ段階的に結果を生成します。
Jev は判断タスク用に特殊な出力方式を採用しており、複数の判断と確率を並列で提供します。同じコメントに対して複数の質問をし、1 回のリクエストで全ての結果を得ることができます。
この出力の違いは、前述した速度とコストに関係しています。大量のデータを毎日処理するソフトウェアでは、小さなステップであっても大きなコストがかかります。ツールを呼び出し連続的なタスクを実行するエージェントは、次のステップを繰り返し決定する必要があります。レスポンス速度とコールコストは、ソフトウェア設計、運用経費、ユーザー体験に直接影響を与えます。 以前は遅さや高コストのためにスキップされていたステップにも、今後は AI 判断を組み込めるようになります。
さらに、出力の安定性もあります。選択肢のセットを定義すると、その範囲内で結果を返すため、ダウンストリームのプログラム処理が容易になります。
Jev の 3 つの新機能
Jev の核となるのは、3 つの新機能です。その設計思想は興味深く、注目に値します。
簡潔に言えば、Choice は与えられた選択肢から選定し、Score は基準に基づいて評価を割り当て、Noul はステートメントが真である確率を判断します。
ここでは、公式 Playground を使用して、実用的な例を通じてこれらの機能を実演します。
EC コメント処理を例にとりましょう。オンラインショップを運営していて、毎日顧客レビューが届くとします。満足度を測り、フォローアップが必要な問題を特定し、対応方法を決定し、緊急案件を優先順位付けする必要があります。
以下のコメントを Jev に送信してみます。
「製品はいいけど、配送に 10 日かかって、カスタマーサービスからも返信がない。」
3 つの機能を使ってこのコメントを判断し、結果を確認しましょう。
Choice: 選択を行う
まず、次のように尋ねます。「全体的な感情は何か？」
提供される選択肢：満足、不満、混在、不明確。
結果：「混在」。
これは理解しやすいですね。ユーザーは製品を褒めていますが、物流とサービスには文句を言っています。「満足」か「不満」のどちらか一方だけを選ぶと、意味の一部が失われてしまいます。
同様に、次のようにも尋ねられます。「このコメントには今後どう対応すべきか？」
選択肢：「人間へ引き継ぐ」、「自動返信」、「返信不要」。ルールを追加：未解決のサービスに関する苦情は人間のフォローアップが必要。
結果：「人間へ引き継ぐ」。
注目すべきは、多肢選択式の質問内容は様々だということです。感情、部署、次のアクション——すべてこの形で構成できます。選択肢は私たちが提供し、Jev は素材と要件に基づいて判断を行います。
Score: 評価を割り当てる
次に、次のように尋ねます。「このコメントの緊急性はどの程度か？ どれくらいの速さでフォローアップしなければならないか？」
スコアリングの前に、基準を定義します。ここでは 3 レベルを設定します。
- 0: 一般的なレビューや単純な問い合わせで、未解決の苦情はない。
- 1: 未解決の物流またはサービスの苦情があるが、安全性の問題、重大な損失、締切逼迫はない。
- 2: 明らかな安全性の問題、重大な損失、または締切の逼迫がある。
Jev は 1 を返し、この基準によれば中程度の緊急性であることを示します。
スコアはあなたが提供する基準に大きく依存します。 返信の質や関連性を評価するように切り替えることもできますが、何が良くて何が悪いのかを定義する必要があります。
整数だけでなく、レベル間の小数点付きスコアを返すことも可能です。
Noul: ステートメントの真偽を判断する
最後に、次のステートメントを与えます。
「ユーザーはコメント内で明確に返金を要求している。」
このタイプは 0 から 1 の間の確率を返し、ステートメントが真である可能性を表します。
結果：0.03（3%）。
ユーザーは不満ですが、明確に返金を求めたわけではありません。したがって、モデルは「明確な返金要求」に対して低い確率を与えます。
すべての返却結果をまとめて見ると、状況が明確になります。
これら 4 つの質問は一緒に送信され、一度にすべての結果が得られました。API はモデル評価時間が約 85 ミリ秒であると報告しました。
これで、プログラムは利用可能な情報を手に入れました。感情カテゴリ、ルーティング先、優先度レベル、返金意図。これらの結果に基づいて処理を継続できます。
Jev は何に使えるのか？
私たちは一つのコメントを処理しました。膨大なボリュームがある EC プラットフォームでは、この使い方はさらに拡張されます。
第一に、統計です。
どのユーザーが満足しているか？ 誰が物流について苦情を言っているか？ どの問題がカスタマーサービスを必要としているか？ モデルは意味を判断し、プログラムはカウントを集計してカテゴリを表示します。
第二に、より深い処理が必要なものを決めるための初期フィルタリングです。
一般的なレビューは統計へ。返信不要な項目は個別返信をスキップ。未解決の問題は人間へ。LLM 生成に適した自動返信は、コンテキスト付きでより大きなモデルへパスします。
以前は、高価な汎用 LLM で最初にすべてをスクリーニングしていたため、初期コストが高くなりました。今は、Jev がフロントエンドのスクリーニングを担当し、深い処理は LLM に残します。
キーワードフィルタリングではダメなのでしょうか？
部分的には可能ですが、キーワードは文脈を見逃します。
例：
「品質は最高！一日でバラバラになった。」
「品質は最高」にマッチすると、これはポジティブと誤分類されます。文全体を読むと皮肉であることがわかります。
Jev は依然として自然言語入力を受け取り、完全な意味を理解します。その専門性はタスクタイプと出力フォーマットにあり、単なるキーワードマッチングではありません。
結果をアクションに変換するには外部プログラムが必要です。
「人間へ引き継ぐ」が返れば、プログラムは手動レビューのためのキューに登録します。「自動返信」が返れば、プログラムは LLM を呼び出して応答を生成します。アクションはワークフロールールとツールによって実行されます。
エージェントにおいて、モデル呼び出し、ツール、ワークフローを整理するこの外部システムは、しばしば Harness（ハーネス）と呼ばれます。Jev は Harness 内の判断ポジションに適合し、次のステップを選択するのに役立ちます。
したがって、私は Jev と LLM は補完関係であり、相互排他的なものではないと考えています。
具体的には、分類やスコアリングには LLM の代わりに Jev を使います。その後、コピー作成、コード記述、複雑なマルチステップ推論には LLM に頼ります。
これにより、システムは異なるステージで異なるモデルを使い分け、能力を有機的に組み合わせることができます。
Jev を体験するには？
最も直接的な方法は、TypeSafe Playground を開くことです。
ログインし、分析対象のテキストを State（判断のための素材）に入力します。Questions で質問を設定し、判断タイプを選択、選択肢や採点基準を入力して Run をクリックすると結果が表示されます。
先ほどのコメントを試したり、ポジティブなレビューに差し替えて変化を観察したりしてみてください。
自分のソフトウェアに統合するには、API を使用します。
API はあるソフトウェアが別のソフトウェアに機能を提供することを可能にします。コンソールから API Key を取得してください。あなたのプログラムはこの認証情報とともに素材と質問を送信し、結果を受け取って後続ロジックを実行します。
公式 SDK も提供されており、開発者の利便性のために一般的なインターフェース関数をラップしています。
価格設定：入力トークン百万あたり $0.042、出力は無料。入力には素材、質問、基準が含まれます。大量のコメントフィルタリングは、既存のフローでこの従量課金モデルを利用できます。
専門的な判断モデルの未来
Jev を調査した後、私は感銘を受けました。「もっと早く誰かがやるべきだったのに、誰もやらなかった」ということです。
私はこのアプローチが正しいと思います。皆が大規模モデルのパフォーマンス向上に必死になっている中、TypeSafe AI は新しいトラックを開拓し、構造化データ、確率的判断、選択、意思決定シナリオ向けのカスタマイズされたモデルを作成しました。
コストと速度のメリットはエージェントにとって友好的です。大規模モデルがゆっくりとデータを返すのを待つのはいくつかのコンテキストでは非効率だからです。
他のベンダーもこのトレンドに追随し、エージェントの判断ステージ用に専門的なモデルを構築する可能性が高いと私は考えます。
エージェントは、迅速な判断用のモデル、複雑な思考・執筆・コード用のモデル、さらに画像・音声・動画モデルを持ち、それらが連携して動作するようになります。
判断が十分に速く安くなれば、以前は「呼び出す価値がない」と思われていた場所にも AI を配置できるようになります。 私にとって、Jev の方向性の最もエキサイティングな点はここです。
