判断特化AI「Jev」は何が違う？ LLM+AIエージェントと冷静に比較

TypeSafe AIは2026年9月15日、同社が「System One Model」と呼ぶAIモデル群の最初の公開モデルとしてJevを発表した。発表後には、Jevが従来のLLMや周辺のAIエージェント技術を置き換えるかのような盛り上がりも見られた。TIS株式会社のnasuvitz(Kiminori Yokoi)氏は9月17日にQiitaへ記事を投稿し、Jevと従来技術は何が違うのかを冷静に紐解こうとしている。従来技術の例として取り上げられているのは、AWSのAmazon Bedrock AgentCoreだ。本稿ではこの記事の論点を順に整理する。

名称の由来から見ておきたい。System Oneは、ダニエル・カーネマンが説明した、素早く直感的に判断する「システム1」に由来する。Jevの名は、効率改善に伴って資源の利用がかえって拡大する現象で知られる経済学者ウィリアム・スタンレー・ジェヴォンズにちなむという。Jevがすることは明快で、文章や業務データを読み取り、分類・採点・条件判定の結果を確率付きで返す。返る結果は型付きの値で、アプリケーションが処理を分岐させる場面でそのまま使える。TypeSafe AIは発表にあたり、アプリケーションが利用しやすいAIの出力を重視したと説明している。業務システムには、問い合わせを分類する、文書が条件を満たすか確かめる、次の処理を選ぶ、といった判断が数多くある。

記事では、顧客から届いた一通のメールを例にしている。先ほどの注文が二重に請求されているので重複分を返金してほしい、先週も問い合わせたがまだ返事がない、という内容だ。まず「従来のLLM+AIエージェント」の構成を考える。Amazon Bedrock AgentCoreなどでエージェントを実装した場合、エージェントはメール、対応履歴、利用可能なツール、返金規程をLLMに渡す。LLMはそれを読み、注文情報と請求履歴を取得するツールを選ぶ、結果を読んで二重請求かどうかを判断する、返金規程を確認して返金か承認依頼のツールを選ぶ、結果を踏まえて返信文を作る、といった進め方を指示文に相当する文章として返す。開発者はツールを接続し、権限や承認条件を設定しておき、その範囲でLLMが次のツールや処理の順序を選ぶ。筆者はこの判断ロジックを「非常にブラックボックス」だと評している。

次に「Jev+非AIエージェント」の構成だ。開発者は事前に「問い合わせの種類」の選択肢を定義し、「返金要求があるか」「再問い合わせか」といった質問も定義しておく。同じメールを評価させると、質問ごとの選択結果と確率が返ることが期待される。記事にはJSON形式のレスポンス例が載っているが、筆者はこれを、公式ドキュメントを参考に理解しやすくするため便宜上模式化したものだと断っている。公式の出力そのものではないので、仕様として読むべきではない。筆者によれば、ここでJevに期待される役割は「処理のルーティング役」にすぎない。プログラムは返された数値を従来の比較演算で評価し、該当する処理を実行すればよい。Jevが返す値は当然毎回変わるが、プログラムのすることは変わらない。レスポンスは確率で決まっても、判断ロジックはプログラムコードで明快に定義できる。

この記事が誠実なのは、そこで話を終えていない点だ。筆者は、LLMにも確率を含む同じ形式で出力させることはできるため、生成できる情報だけを見れば両者に決定的な違いはない、と明記している。Jevが主張する違いは、モデルが分類と確率の出力に特化して学習・設計されており、高速・低コストで実行できるという点にある。分類結果に従って分岐するだけなら、プログラムがJevを呼び出して条件分岐できればよく、Amazon Bedrock AgentCoreのようなエージェント基盤は不要になる。ただし「高速・低コスト」はJev側の主張であり、記事には裏付けとなる計測値や価格は示されていない。評価の際は検証すべき前提として扱うのが妥当だろう。

続いて筆者は両者を並べて比較する。Jevを組み込んだ業務アプリケーションでは、AIに任せるのは分類、条件の該当判定、スコアリングで、プログラムは判定結果に対応する処理とその実行条件・順序を定義し、次の処理はコードに書いた条件分岐で決まる。顧客対応なら、返金要求と判定された時点で定義済みの請求確認・承認フローへ進み、アプリケーションコード側にエージェンティックな処理はない。LLMを中心としたエージェントでは、AIに任せるのは状況の解釈と次の行動やツールの選択で、プログラムは利用可能なツール、権限、承認条件、実行上の制約を定義し、次の処理は指示や会話履歴、ツールの実行結果を基にLLMが選ぶ。同じ顧客対応でも、請求確認、追加の質問、担当者への引き継ぎなどを状況に応じて選ぶことになる。筆者の言葉を借りれば、処理の進め方を決める責任をプログラムとAIのどちらに持たせるかの違いである。

結論は、どちらかがどちらかを置き換えるという話ではない。Jevを業務に組み込むには、プログラムで実行する処理が明確になっていることが前提で、判定ロジックをコードに持ち、請求確認や承認の手続きも事前に定義しておく必要がある。その上で、繰り返し発生する判断と処理を、必要な品質を保ちながらアプリケーション側で低遅延・低コストに実行することが期待できる。一方、LLM中心のエージェントは次に何を確認しどのツールを使うかをAIに委ねられ、非常に柔軟だが、同じ処理でも毎回の思考時間やコンテキストの消費量が異なり、コストに影響しうる。それぞれの特徴を知って使い分けることが大切だ、というのが筆者のまとめである。記事末尾には、TypeSafe AIの「Introducing System One Models & Jev」「Introduction」「Primitives (Questions)」「AI primer」「Confidence」「Workflow evals」が参考文献として挙げられている。