Jevの活用例: TypeSafeの意思決定モデルで人々がすでに構築している7つのもの

Jevは、何を言えるかではなく、ソフトウェアに何を判断させられるかを考えると、より理解しやすくなります。開発者はすでに、エージェントスタック、ブラウザー自動化、広告分析、リードスコアリング、ゲーム、コンテンツ評価、研究トリアージで、TypeSafeの判断モデルを活用しています。

個々のデモよりも、全体的なパターンのほうが重要です。Jevはコードや最先端のLLMに取って代わるものではありません。対象とするのは、単純なルールには主観的すぎ、人間が対応するには繰り返しが多く、毎回高価な生成モデルを使うほどでもない、曖昧な中間領域の判断です。基盤となるモデルのアーキテクチャと制約については、以前の記事「AIエージェント向け判断モデル」をご覧ください。

Jevの用途に適しているのは？

Jevの公開事例の中でも特に有力なものには、いくつかの共通点があります。推論の前に有効な出力が定まっていること、同じ判断を繰り返し行うこと、レイテンシが重要であること、自由形式のテキストにほとんど価値がないこと、そして不確かなケースを別の処理にエスカレーションできることです。

簡単な判断基準があります。モデルを実行する前に有効な回答の範囲を定義できるなら、判断モデルを評価する価値があるかもしれません。

この違いは、すでに人々が構築しているプロジェクトを見ると、より明確になります。

1. OpenClaw：エージェントスタックに組み込まれた専用判断モデル

OpenClawは、Jevが実験的なデモの域を超えつつあることを示す、最も有力な事例の一つです。現在の判断モデルのドキュメントでは、主要な対話モデルと専用の判断モデルの役割が区別されています。

同梱のTypeSafeプラグインを使うと、開発者はメインのLLMとは独立してJevを選択できます。より大規模なモデルで計画、コーディング、説明、ツールの使用を行いながら、Jevには、どのエージェントにタスクを割り当てるべきか、証拠が条件を満たしているか、ワークフローを続行すべきかといった、より限定的な問いを任せられます。

これは重要なアーキテクチャ上の転換です。曖昧な手順のたびにメインのLLMへプロンプトを追加するのではなく、エージェントは特定のモデルを範囲の限られた判断専用に使えます。

OpenClawは、判断と実行を明確に分けることも重視しています。Jevの結果から、あるアクションが適切と思われる根拠は得られますが、それだけでコンテンツの公開、メッセージの送信、永続的な状態の変更を自動的に許可すべきではありません。こうしたアクションには、引き続き別個のツール実行の信頼境界を通過させる必要があります。

その結果、判断モデルは小型チャットボットというより、主要なエージェントモデルと並ぶもう一つのインフラコンポーネントに近いものになります。

2. ブラウザーエージェント：ページを説明するのではなく、次のクリックを選ぶ

ブラウザーの自動化では、判断が自然と多くの割合を占めます。多くのステップで、エージェントは利用可能な要素をすでに把握しており、次のアクションを選ぶだけで済みます。

Gregor Zunicは、ブラウザーがDOMの状態を提示し、Jevが次のアクションを選び、実際にテキストが必要なケースではより小型の生成モデルが対応するBrowser Useの実験を公開しました。公開されているフライト検索デモでは、実行に約7秒、総費用は0.0039ドルだったと著者は報告しています。これは独立したベンチマークではなく、開発者による報告値です。Browser Use + Jevの事例をご覧ください。

この違いが重要なのは、ブラウザーループの多くがモデルに文章の作成を求めているわけではないからです。現在の目標に最も近づくアクションを繰り返し選ぶよう求めています。

これは、より効率的なブラウザーエージェント設計につながります。ブラウザーに新しいテキストの生成が本当に必要なときは生成モデルを使い、次のステップが既知のアクションから選べる場合は、選択肢を限定した判断を使います。

3. 広告分析：サンプリングせず、データセット全体をスコアリングする

Matthew Bermanは、Jevを使って37ブランドの配信中の広告724件を、フック、フォーマット、オファー、CTA、認知段階、ランディングページとのミスマッチなどの項目で分類したと報告しています。実行には約40秒かかり、費用はおよそ0.09ドルでした。これらの数値は著者による報告で、公開広告分析事例にまとめられています。

さらに興味深いのは、一次判断のコストが十分に下がったときに起こることです。

すべてのレコードを評価するには費用がかかりすぎるため、アナリストはしばしばサンプリングを行います。判断モデルですべての広告を同じ評価軸で低コストにスコアリングできれば、ワークフローは変わります。AIを小さなサンプルの確認だけに使うのではなく、人が興味深いクラスターを確認する前に、データセット全体を一次分類できます。

これは単に広告分析を安くする以上の変化です。サンプリングが必要だった問題の中には、全件スコアリングで解決できるものもあります。

4. リードスコアリング：高コストの生成の前に、低コストの判断を行う

リードスコアリングにも同様の傾向が見られます。Romànは、約0.09ドルで700件のリードをおよそ40秒で処理し、各レコードを詳しく確認すべきか判断する前に、適合度、確信度、ミスマッチをスコアリングしたと報告しています。公開されているリードスコアリング実験をご覧ください。

実用上の価値は、高コストの生成処理を行う場所を変えることで生まれます。すべてのレコードについて、高性能なLLMにパーソナライズした営業文面を詳しく分析・作成させるのではなく、まず価値がありそうなものや、判断に迷うものだけを絞り込めます。

そのため、ハイブリッドAIのコスト戦略では、リクエストの振り分けがますます重要になっています。コスト最適化とは、より安価なモデルを見つけることだけではありません。そもそも、どのリクエストに高価なモデルが必要なのかを判断することも重要です。

このアーキテクチャでは、Jevは最終的な知能レイヤーではなく、事前フィルターとして最も役立ちます。

5. リアルタイムゲーム：判断頻度がコスト構造を変える

リアルタイムゲームは目新しいデモのように見えますが、レイテンシが重要な理由を明らかにします。

Max Bladeは、50ゲームを同時に実行するSubway Surfersの実験を公開し、推論コストの合計は1セント未満だったと報告しています。数値は公開ゲームデモ内で投稿者が自己申告したものです。

行動の選択肢は限られています。左に移動、右に移動、ジャンプ、しゃがむ、またはそのまま進む、です。こうした行動を選ぶ前に、各フレームを自然言語で詳しく説明しても、ほとんど意味はありません。

ここで、判断モデルを評価する有用な指標として判断頻度が導入されます。

1日1回の判断で数百ミリ秒を節約しても、実用上の価値はほとんどありません。その遅延削減が毎秒多数の判断に及び、さらに数十の並列環境で繰り返されれば、応答時間と推論コストの両方が変わります。

このため、同じ限定的な判断がより高い頻度で繰り返されるほど、高速な判断モデルの価値が高まります。

6. コンテンツのスコアリング：同じ下書きに多くの質問をする

SuperXは、この問題の別の側面を示しています。同じ判断を非常に頻繁に繰り返すのではなく、同じ入力について多くの異なる質問をします。

公開実験では、ソーシャルメディアの投稿を61個の個別の質問で評価します。投稿者によると、過去の投稿を使ってパフォーマンス向上に関連するシグナルを特定する場合、1件あたり約1秒、0.0004ドルかかります。これらの結果は製品の開発者による主張であり、独立したベンチマークではありません。このプロジェクトはコンテンツとグロースの事例ディレクトリに掲載されています。

「これは良い投稿ですか？」のような漠然とした質問をする代わりに、アプリケーションでは下書きを、より具体的な観点に分けて評価できます。

• フックは具体的ですか？
• 好奇心を引き出す余地がありますか？
• 主張は具体的ですか？
• 宣伝色が強すぎませんか？
• CTAは強引すぎますか？

結果は、正体の分からない単一のAIスコアではありません。ソフトウェアが、どの項目を書き直す必要があるかの特定、2つの草稿の比較、人による確認が必要かどうかの判断に利用できる、構造化されたプロファイルです。

このことから、意思決定の次元数も重要な変数となります。同じ判断が頻繁に発生するだけでなく、範囲の定まった数十の判断を同じ状態に低コストで適用できる場合にも、モデルは役立ちます。

7. 研究の分類:すべてをトリアージし、重要なものを読む

1kpapersという公開プロジェクトでは、Jevを使ってAI研究論文1,018本を分類しました。公開されている数値によると、総コストは約0.08ドル、論文1本あたりのエンドツーエンドのレイテンシ中央値は約256ミリ秒です。このプロジェクトはJevで作成されたサイトのディレクトリに掲載されています。

多くの実際のワークフローは、論文、メール、サポートチケット、レビュー、ドキュメント、ログ、検索クエリなど、記録が多すぎる状態から始まるため、これは特に実用的な例の一つかもしれません。

多くの場合、コストがかかるのは個々の項目を理解することではありません。どの項目をより詳しく見るべきか判断することです。

元データが非公開の場合、特に役立ちます。プライベートAIアシスタントなら、検索と元のドキュメントライブラリをローカルに保ち、必要に応じて選別した証拠やそこから得た情報だけを外部サービスに送信できます。

モデルが深い読解に取って代わる必要はありません。その役割は、深く読む対象を選別することです。

本質的なパターン: 意思決定の密度

7つの例は一見無関係に見えますが、構造的にはよく似ています。いずれも雑然とした状態から始まり、答えの選択肢がすでに限られた問いを繰り返し投げかけます。

これを表すのに便利なのが意思決定の密度です。これは、システムが所定のワークロードに対して行う必要のある、範囲の定まった判断の数を指します。

最も重要なのは2つの要素です。

• 頻度:アプリケーションが判断を必要とする頻度。
• 次元数:各状態について必要な判断の数。

1つの二択判断だけでは、AIスタックを再設計する理由にはなりにくいでしょう。曖昧な判断が何千件もある場合や、入力ごとに数十の判定が必要な場合は、話が別です。

意思決定の密度が高いほど、特化した意思決定レイヤーの魅力が増します。

最も有力なアーキテクチャは、まずJev、次に大規模モデルかもしれません。

判断モデルがすべてのケースを解決する必要はありません。信頼度に応じて、より高性能なモデルに引き継ぐタイミングを決められます。

公開されている不正検出の実験は、このパターンを示しています。開発者はまず、100件のメールにJevを使用し、その後、信頼度が95%のしきい値を下回る予測を、より大規模なKimi K3モデルに回しました。報告によると、31件がエスカレーションされ、最終的な精度は96/100、総コストは約$0.07でした。これらの数値は実験的なもので、自己申告によるものです。この事例はJevエンジニアリングディレクトリに掲載されています。

このアーキテクチャは、Jev単体の精度を最大化しようとするよりも興味深いものです。安価なモデルで大半の簡単なケースを処理し、曖昧なケースだけを、より高価なモデルに任せられます。

それでも、信頼度がそのまま権限になるべきではありません。分類が最終的に現実世界での行動を引き起こす場合は、読み取り専用のエージェントツールと、範囲を限定した権限が引き続き重要です。

判断コストが安くても、悪いシグナルは良くならない

Jevをめぐる初期の議論は、すでに自動ラベリングや取引などの分野に広がっています。どちらも判断モデルのインターフェースに適していますが、だからといって、それに関するあらゆる主張の信頼性が同じになるわけではありません。

データのラベリングでは、目先の最善策は必ずしも人間のアノテーターを置き換えることではありません。信頼度の高い事例は自動でラベル付けし、中程度の信頼度の例は別のモデルで再確認し、判断が難しい記録は引き続き人間に回すことができます。

これにより、人間がワークフローからいなくなると決めつけるのではなく、人間が時間をかける事例が変わります。

取引には、さらに明確な限界があります。買い、売り、保留をすばやく出力することは、範囲を限定した判断として捉えやすいものです。難しいのは、入力データに実際の予測優位性が含まれているかどうかです。

Jevは市場判断のコストを下げられます。弱いシグナルを予測可能にすることはできません。

同じ区別は上記の例のほとんどにも当てはまります。レイテンシの低さと推論コストの低さは、判断レイヤーが効率的であることを示しています。しかし、それだけでは基盤となる判断がビジネス価値を生み出すとは証明できません。

ローカルAIエージェントにおけるJevの位置づけ

Jev自体は現在、公開されているセルフホスト可能なチェックポイントではなく、ホスト型サービスです。これはローカルAIにとって重要な境界となります。

ローカルエージェントは、ファイル、メモリ、検索機能、ツールをホームサーバーに保持できますが、分類のためにドキュメントの内容をJevに送信すれば、その情報はネットワーク境界を越えます。

同じ原則はローカルファイルを扱うクラウドツールを使う場合にも当てはまります。ランタイムがローカルでも、データが必ずローカル内で処理されるとは限りません。

より優れたハイブリッド設計では、プライベートな検索、前処理、データのマスキング、日常的なローカル処理をデータの近くに保ち、ホスト型の判断モデルまたは推論モデルに必要最小限の証拠だけを送ります。

Jevの初期ビルドから実際に分かること

Jevの初期実験から、規模の小さな判断モデルが最先端のAIに取って代われるとは分かりません。

さらに有用な点も明らかになります。多くのAIアプリケーションは、生成を必要としないタスクに生成モデルの計算リソースを費やしているのです。

ブラウザー、広告、見込み客、ゲーム、コンテンツ、研究、エージェントのオーケストレーションにわたって、同じ構造が繰り返し見られます。入力は雑然としていますが、出力の候補は限られています。判断は繰り返し行われ、不確かなケースはエスカレーションできます。

そのため、最も役立つJevのデモは、Jevが何でもできると証明しようとするものではありません。

汎用LLMをまったく使わなくてもよいことを示しているのは、まさにこうした事例です。

ソフトウェアに、曖昧ながらも範囲が限定された判断を何千回もさせる必要があり、言葉はほとんど必要ない場面で、Jevは最も役立ちます。