Jevは、何を言えるかではなく、ソフトウェアに何を判断させられるかを考えると、より理解しやすくなります。開発者はすでに、TypeSafeの意思決定モデルをエージェントスタック、ブラウザー自動化、広告分析、リードスコアリング、ゲーム、コンテンツ評価、研究のトリアージなどで活用しています。
個々のデモよりも、このパターンのほうが重要です。Jevはコードや最先端のLLMを置き換えるものではありません。単純なルールには主観的すぎ、人間には反復的すぎ、毎回高コストな生成を行うほどではない判断、つまり曖昧な中間層を対象としています。基盤となるモデルのアーキテクチャと制約については、以前に公開したAIエージェント向け意思決定モデルの解説をご覧ください。
Jevに適したユースケースとは?
Jevを使った公開事例の中でも特に優れたものには、いくつかの共通点があります。推論の前に有効な出力が分かっていること、同じ判断を繰り返し行うこと、レイテンシーが重要であること、自由形式のテキストの価値がほとんどないこと、そして不確実なケースを別の場所にエスカレーションできることです。
簡単なテストがあります。モデルの実行前に有効な回答の範囲を定義できるなら、意思決定モデルを評価する価値があるかもしれません。
| ワークロード | より適したモデル |
|---|---|
| どのエージェントがこれを処理すべきか? | 意思決定モデル |
| ブラウザーでどのボタンをクリックすべきか? | 意思決定モデル |
| 最終的な顧客向けメールを書く | 生成モデル |
| 複雑な研究論文を説明する | 生成 / 推論モデル |
この違いは、すでに人々が構築しているプロジェクトを見ると、より明確になります。
1. OpenClaw: エージェントスタック内の専用意思決定モデル
OpenClawは、Jevが実験的なデモを超えて進化していることを示す最も強力な兆候の1つです。現在の意思決定モデルのドキュメントでは、主要な会話モデルと専用の意思決定モデルの役割が分けられています。
バンドルされているTypeSafeプラグインを使えば、開発者はメインLLMとは独立してJevを選択できます。より大規模なモデルは、計画、コーディング、説明、ツールの利用を引き続き担い、Jevはどのエージェントにタスクを割り当てるべきか、証拠が条件を満たしているか、ワークフローを続行すべきかといった、より限定的な質問を処理できます。
これは重要なアーキテクチャ上の転換です。曖昧なステップをすべてメインLLMへの追加プロンプトとして扱う代わりに、エージェントは限定された判断専用に1つのモデルを割り当てられます。
OpenClawは、意思決定と実行を分離するという重要な考え方も維持しています。Jevの結果は、あるアクションが適切であるように見えることの根拠にはなりますが、コンテンツの公開、メッセージの送信、永続的な状態の変更を自動的に許可するものではありません。こうしたアクションは、別個のツール実行の信頼境界を引き続き通過する必要があります。
そのため、意思決定モデルは小型のチャットボットというより、主要なエージェントモデルの隣に置かれる別のインフラコンポーネントに近いものになります。
2. ブラウザエージェント: ページを説明するのではなく、次のクリックを選ぶ
ブラウザ自動化は本質的に意思決定が中心です。多くのステップでは、エージェントは利用可能な要素をすでに把握しており、次のアクションを選ぶだけで済みます。
Gregor Zunicは、ブラウザがDOMの状態を提供し、Jevが次のアクションを選択し、実際にテキストが必要なケースはより小型の生成モデルが処理する、Browser Useの実験を公開しました。公開されているフライト検索デモでは、実行時間は約7秒、合計費用は0.0039ドルだったと著者が報告しています。これらは独立したベンチマークではなく、開発者による報告値です。Browser Use + Jevの例をご覧ください。
| ブラウザ操作 | 最適な役割 |
|---|---|
| 次にクリックする要素を選択する | Jev |
| 目標が達成されたか判断する | Jev |
| 自由記述形式の回答を書く | 生成モデル |
この違いが重要なのは、ブラウザループの多くがモデルに言語の作成を求めているわけではないからです。現在の目標を最もよく前進させるアクションはどれかを、繰り返し尋ねているのです。
これは、より効率的なブラウザエージェント設計を示唆しています。ブラウザが実際に新しいテキストを必要とするときは生成を使い、次のステップが既知のアクション集合から選べる場合は、範囲を限定した意思決定を使います。
3. 広告分析: サンプリングではなくデータセット全体をスコアリングする
Matthew Bermanは、Jevを使って37ブランドの配信中の広告724件を、フック、フォーマット、オファー、CTA、認知段階、ランディングページとの不一致などの観点で分類したと報告しています。報告された実行時間は約40秒で、費用はおよそ0.09ドルでした。これらの数値は著者による報告であり、公開されている広告分析事例で収集されたものです。
より興味深いのは、最初の判断が十分に低コストになったときに何が起こるかです。
| 高コストな分析 | 低コストな意思決定レイヤー |
|---|---|
| 1,000件の広告を収集 | 1,000件の広告を収集 |
| 50件をサンプリング | 1,000件すべてをスコアリング |
| サンプルからパターンを推測 | 構造化されたシグナルでフィルタリング |
| 専門家の時間を広範囲に使う | 異常または高価値のクラスターを調べる |
分析担当者がサンプリングを行うことが多いのは、すべてのレコードを評価するにはコストがかかりすぎるからです。意思決定モデルですべての広告を同じ指標に基づいて低コストでスコアリングできるなら、ワークフローは変わります。AIを少数のサンプルの確認だけに使うのではなく、人間が最も興味深いクラスターを調べる前に、データセット全体に一次分類を適用できます。
これは、広告分析を単に低コスト化するよりも大きな変化です: 一部のサンプリング問題は、全件スコアリング問題に変えられます。
4. リードスコアリング: 高コストな生成の前に低コストな判断を置く
リードスコアリングにも同様のパターンが見られます。Romànは、約40秒で700件のリードを処理し、約$0.09で適合度、信頼度、不一致をスコアリングしてから、どのレコードをさらに詳しく調べる価値があるかを判断したと報告しています。詳しくは、公開されたリードスコアリング実験をご覧ください。
| レイヤー | 処理 |
|---|---|
| Jev | フィルタリング、スコアリング、分類 |
| 信頼度ルール | エスカレーションが必要なものを判断 |
| 大規模LLM | 高価値でパーソナライズされた出力を生成 |
実用的な価値は、高コストな生成を行う場所を変えることから生まれます。高性能なLLMにすべてのレコードを詳細に分析させ、個別最適化したアプローチ文を作成させる代わりに、まず価値がありそうなものや不確実なものだけを少数特定できます。
これは、ハイブリッドAIのコスト戦略がますますルーティングに依存する理由の1つです。コスト最適化は、単に安価なモデルを探すことだけではありません。どのリクエストに高価なモデルが本当に必要なのかを判断することも重要です。
そのアーキテクチャでは、Jevは最終的なインテリジェンス層というより、事前フィルターとして最も有効です。
5. リアルタイムゲーム: 意思決定の頻度が経済性を変える
リアルタイムゲームは目新しいデモに見えますが、レイテンシーが重要な理由を浮き彫りにします。
Max Bladeは、Jevを50ゲーム同時に実行するSubway Surfersの実験を公開しました。著者によると、推論コストの合計は1セント未満でした。この数値は、公開ゲームデモで報告された自己申告値です。
行動の選択肢は少なく、左に移動、右に移動、ジャンプ、しゃがむ、またはそのまま進むだけです。これらの行動のいずれかを選ぶ前に、各フレームを詳細な自然言語で説明しても、ほとんどメリットはありません。
これにより、意思決定モデルを評価する有用な方法として、意思決定の頻度が導入されます。
1日1回の判断で数百ミリ秒を節約しても、実用的な価値はほとんどありません。しかし、毎秒多数の判断にわたってそのレイテンシーを削減し、さらに数十の並列環境に適用すれば、応答時間と推論コストの両方が変わります。
このため、同じ範囲を限定した判断がより頻繁に繰り返されるほど、高速な意思決定モデルは興味深いものになります。
6. コンテンツスコアリング: 同じ草稿について多くの質問をする
SuperXは、この問題の別の側面を示しています。同じ判断を非常に頻繁に行うのではなく、同じ入力について多くの異なる質問をします。
この公開実験では、ソーシャル投稿を61個の個別の質問で評価します。著者によると、過去の投稿を使ってパフォーマンス向上に関連するシグナルを特定する場合、草稿1件あたり約1秒、0.0004ドルです。これらの結果は、独立したベンチマークではなく、製品の著者による主張です。このプロジェクトは、コンテンツと成長の事例ディレクトリに掲載されています。
「これは良い投稿か?」のような曖昧な質問をする代わりに、アプリケーションは草稿を、より明確な判断に分解できます。
- フックが具体的か?
- 好奇心を喚起する余白があるか?
- 主張が具体的か?
- 文章が宣伝色の強いものになっていないか?
- CTAが強引すぎないか?
その結果は、1つの不透明なAIスコアではありません。ソフトウェアが、どの次元を書き直す必要があるかを特定したり、2つの草稿を比較したり、人による確認が必要かどうかを判断したりできる、構造化されたプロファイルです。
このことから、意思決定の次元数も重要な変数になります。同じ判断が頻繁に行われるからだけでなく、数十個の範囲を限定した判断を、同じ状態に対して低コストで適用できるからこそ、モデルは有用になります。
7. 研究分類: すべてをトリアージしてから、重要なものを読む
1kpapersという公開プロジェクトでは、Jevを使って1,018本のAI研究論文を分類しました。公開された数値によると、総コストは約0.08ドル、論文1本あたりのエンドツーエンドのレイテンシー中央値は約256msです。このプロジェクトは、Made with Jevのサイトディレクトリに掲載されています。
これは、実際のワークフローの多くが、論文、メール、サポートチケット、レビュー、ドキュメント、ログ、検索クエリなど、大量のレコードから始まるため、より実用的な例の一つと言えるでしょう。
多くの場合、コストがかかるのは1件を理解することではありません。どの項目により深い注意を向ける価値があるかを判断することです。
| 第1パス | 第2パス |
|---|---|
| トピックを分類 | 選択した文書を深く読む |
| 関連性をスコアリング | 価値の高い記録を大規模モデルに送信 |
| 明らかな不一致を検出 | 曖昧なケースを人間が確認 |
| 信頼度を推定 | 不確かな記録をエスカレーション |
これは、元データがプライベートな場合に特に役立ちます。プライベートAIアシスタントは、検索と元のドキュメントライブラリをローカルに保持し、必要な場合に限って、選択された証拠やそこから導出された証拠だけを外部サービスに送信できます。
モデルは、深く読み込む作業を置き換える必要はありません。その役割は、深く読む対象を選別することです。
本当のパターン: 意思決定密度
7つの例は無関係に見えますが、構造的には非常によく似ています。どれも、複雑な状態から始まり、答えの範囲がすでに限定された質問を繰り返し行います。
これを表す便利な方法が意思決定密度です。これは、システムが一定のワークロードに対して行う必要がある、範囲の定められた判断の数を指します。
最も重要な要素は2つあります。
- 頻度:アプリケーションが判断を必要とする頻度。
- 次元数:各状態について必要となる判断の数。
| ワークロード | 意思決定密度 | Jev適合性 |
|---|---|---|
| 1日に1回のはい/いいえチェック | 低い | 優位性が低い |
| 分類するメール1,000件 | 頻度が高い | 高い |
| 1つの下書きにつき61個の質問 | 次元数が多い | 高い |
| 各ステップでブラウザー操作 | 頻度が高い | 高い |
| 多数の並行ゲーム | 頻度が非常に高い | 構造的な適合性が非常に高い |
| 詳細なレポートを書く | 生成中心 | 適合性が低い |
単一の二値判断だけでは、AIスタックを再設計する理由にはなりにくいでしょう。曖昧な判断が何千件もある場合や、入力ごとに数十の判断を行う場合は、別の問題です。
意思決定密度が高いほど、特化した意思決定レイヤーの魅力が増します。
最も強力なアーキテクチャは、Jevを先に使い、その後に大規模モデルを使う構成かもしれない
意思決定モデルは、すべてのケースを解決する必要もありません。信頼度によって、より高性能なモデルに引き継ぐタイミングを判断できます。
公開されている不正検出実験は、このパターンを示しています。構築者はまず100件のメールにJevを使用し、その後、信頼度95%未満の予測を、より大規模なKimi K3モデルに振り分けました。著者の報告によると、エスカレーションは31件、最終的な正解率は96/100、総コストは約0.07ドルでした。これらの数値は実験的なもので、自己申告によるものです。この事例はJevエンジニアリングディレクトリに掲載されています。
| 段階 | 目的 |
|---|---|
| 低コストの意思決定モデル | 明らかなケースを処理 |
| 信頼度のしきい値 | 不確実性を検出 |
| 大規模推論モデル | 難しいケースを処理する |
| ポリシー / 人間のレイヤー | エラーが重要な領域では権限を保持する |
このアーキテクチャは、Jev単体の精度を最大化しようとするよりも興味深いものです。より安価なモデルが大半の簡単なケースを処理し、より高価なモデルには曖昧なケースだけを渡せます。
それでも、信頼度を自動的に権限と見なすべきではありません。読み取り専用エージェントツールと限定的な権限は、分類が最終的に現実世界のアクションを引き起こす可能性がある場合にも重要です。
安価な判定で悪いシグナルが良くなるわけではない
Jevに関する初期の議論は、すでに自動ラベリングや取引などの分野にも広がっています。どちらも判定モデルのインターフェースに適合しますが、それによって関連するすべての主張の信頼性が同等になるわけではありません。
データラベリングでは、短期的に最も有力な設計が、必ずしも人間のアノテーターを置き換えることとは限りません。信頼度の高いケースは自動でラベル付けし、中程度の信頼度の例は第2モデルによるレビューを受け、曖昧な記録は引き続き人間に回すことができます。
これにより、人間がワークフローからいなくなると決めつけるのではなく、人間が時間を費やす例を変えられます。
取引には、さらに明確な限界があります。生成する 購入, 売却、または 保持 迅速に処理することは、範囲を限定した判定として捉えやすいものです。難しいのは、入力データに本当の予測優位性が含まれているかどうかです。
Jevは市場の判定を低コストにできます。弱いシグナルを予測可能なものにすることはできません。
同じ区別は、上記の例のほとんどにも当てはまります。低レイテンシーと低い推論コストは、判定レイヤーが効率的であることを示します。しかし、それだけで、その基盤となる判断がビジネス価値を生み出すことを証明するわけではありません。
ローカルAIエージェントにおけるJevの位置付け
Jev自体は現在、公開セルフホスト型チェックポイントではなく、ホスト型サービスです。これはローカルAIにとって重要な境界を生み出します。
ローカルエージェントは、ファイル、メモリー、検索、ツールをホームサーバー上に保持できます。しかし、分類のためにドキュメントの内容がJevに送信されると、その証拠はネットワーク境界を越えています。
| ローカルに保持 | ホスト型判定入力の候補 |
|---|---|
| 非公開ドキュメントライブラリ全体 | 選択または抽出された証拠 |
| 元のソースファイル | 最小限のタスク状態 |
| 個人のメモリー | 機密性のない分類コンテキスト |
| 認証情報とシークレット | 通常の分類には必要ありません |
ローカルファイルを使うクラウドツールを利用する場合も、同じ原則が当てはまります。ローカルランタイムだからといって、ローカルなデータ経路が自動的に保証されるわけではありません。
より強力なハイブリッド設計では、プライベートな検索、前処理、匿名化、日常的なローカル操作をデータの近くに置き、そのうえで、ホスト型の意思決定モデルまたは推論モデルに必要最小限の証拠だけを送信します。
最初のJevビルドが実際に示していること
Jevの最初の実験群は、小型の意思決定モデルが最先端AIに取って代われることを示しているわけではありません。
これは、より有用な点を示しています。多くのAIアプリケーションが、生成を必要としないタスクに生成モデルの計算リソースを費やしているのです。
ブラウザー、広告、リード、ゲーム、コンテンツ、研究、エージェントオーケストレーションにわたって、同じ構造が繰り返し現れます。入力は整理されていませんが、可能な出力は限定されています。判断は繰り返し行われ、不確実なケースはエスカレーションできます。
| レイヤー | 最適な役割 |
|---|---|
| ルール / コード | 決定論的な判断 |
| 意思決定モデル | 曖昧だが範囲の限定された判断 |
| 推論モデル | 難しく曖昧な問題 |
| 生成モデル | 言語、コード、またはメディアを生成する |
| ポリシーレイヤー | 実行を実際に許可する内容を決定する |
したがって、最も有用なJevのデモは、Jevが何でもできることを証明しようとするものではありません。
そこでは、汎用LLMをまったく関与させる必要がないことが示されています。
Jevは、ソフトウェアが大量の曖昧だが範囲の限定された判断を、ほとんど言葉を使わずに行う必要がある場面で、最も有用になります。
Jevのユースケースに関するよくある質問
JevはOpenClawと連携できますか?
はい。OpenClawは専用の意思決定モデルの役割と、プライマリの会話モデルとは別にJevを使用できるTypeSafeプラグインをサポートしています。
Jevはブラウザーエージェントを制御できますか?
はい。公開されているBrowser Useの実験では、限定されたDOMアクション空間から次のアクションを選択するためにJevが使用されています。必要に応じて、生成モデルが自由形式のテキストを処理します。
Jevは広告、投稿、大規模なデータセットを分析できますか?
はい。公開ビルドでは、広告分類、コンテンツスコアリング、メールの振り分け、研究論文の分類、その他の大量の構造化判断にJevが使用されています。現在公開されている速度やコストの数値の多くは、独立したベンチマークではなく、ビルダーによる報告です。
Jevは人間によるデータラベリングに取って代われますか?
自信度の高い、範囲が限定されたラベル付けを自動化できる可能性はありますが、人間のアノテーターの何パーセントを置き換えられるかについて、現在の証拠から正確な主張をすることはできません。自信度に基づくエスカレーションのほうが、より現実的な設計です。
Jevはローカルで実行できますか?
TypeSafeは、セルフホスティング向けのJevの公開ウェイトをリリースしていません。現在のJev連携ではホスト型推論が使用されるため、プライベートエージェントの設計では、ローカル環境の外部に送信する証拠を正確に制御する必要があります。
テック&AIハブ
もっと読む

2026年版オープンソースAIコーディングアシスタント トップ10
IDE、ターミナル、ローカルモデル、セルフホスティング、Gitワークフロー、自律開発に対応するオープンソースのAIコーディングアシスタント10種類を比較します。

Layaモデルを解説:ローカルで実行できるオープンソースの意思決定モデル
Layaは、迅速なローカルルーティングとスコアリングに対応したパラメーター数4.21億のオープンな意思決定モデルで、クラウドベースの意思決定APIに代わるセルフホスト型の選択肢を提供します。

2026年、家庭用NVRのAIはなぜフレーム検出からイベント理解へと移行しているのか?
トラックがどのようにイベントになり、時間的なコンテキストによって反復的なアラートが減る理由、そしてイベント認識型ビデオAIが依然として対応できない領域を理解します。

