Jevは実際に何ができるのか？コミュニティの10事例から用途を理解する

Webサイトの操作、Agentのコンテキスト整理、UIの組み立て、広告の除去、ゲームの操作、メール分類、YouTubeのスポンサー区間スキップ。これらのJev事例を並べると、このモデルは何でもできるように見えます。

しかし、それぞれのワークフローを分解すると、Jevが担当しているのは通常ごく狭い一工程です。つまり、現在の状態に基づいて構造化された判断を一度返すことです。ページ解析、音声の文字起こし、注文の送信、動画のシークは、依然として通常のコード、専用サービス、または別のモデルが行います。

この違いがJevを理解する鍵です。価値はチャットモデルの代わりにタスク全体をこなすことではありません。本来なら言語モデルが「考え、文章を書き、その結果を再びパースされる」必要がある工程を、ソフトウェアが直接扱える選択、スコア、確率に置き換えることにあります。

Jevは通常のチャットモデルと何が違うのか？

TypeSafeはJevを最初のSystem Oneモデルと説明しています。開発者は、現在の状況を表すstateと、型が定義されたtyped questionsを渡します。長文の回答ではなく、Jevは次の3種類の構造化判断を返します。

種類	適した質問	典型的な結果
Choice	どのカテゴリ、アクション、ツールを選ぶべきか？	1つの選択肢と各選択肢の確率
Score	重大度、関連性、品質はどの段階か？	スコアと各段階の確率
Noul	ある命題は成立するか？	0から1までの確率

たとえばブラウザーAgentは、現在のページDOM、ユーザーの目的、実行可能なアクションをstateにまとめ、「次にどの要素をクリックすべきか？」とJevに尋ねられます。結果を受け取ったプログラムがクリックを実行します。入力欄に文章を書く必要がある場合、その部分は引き続き生成モデルが担当します。

したがって、正確なワークフローは「Jevがタスクを完了する」ではなく、次の形です。

現在の状態またはイベント
      ↓
Jev：選択、採点、判定
      ↓
通常のコード：実行、並べ替え、絞り込み、停止、または人への引き継ぎ

以下の10事例は成熟度ランキングではありません。ソフトウェア内でJevが担う役割に沿って、アクション層、情報層、ワークフロー層の3つに分けて見る方が理解しやすくなります。

1. アクション層：Jevが次の手を選び、プログラムが実行する

1. Browser Use：Web操作を候補アクションからの選択に変える

Browser Useのjev-ultrafast実装では、プログラムがまずページのDOMを読み、ボタンをクリックする、選択肢を選ぶ、次のページに進むといった、現在実行可能なアクションを生成します。Jevは「どのように閲覧すべきか」を自由文で説明するのではなく、その候補から次の一手を選びます。

この設計がJevに向くのは、各判断に3つの条件がそろっているからです。状態はプログラムによって整理済みで、アクションの集合は有限であり、選ばれたアクションをどう実行するかをコードが知っています。出発地や目的地などの文字列を入力する必要がある場合は、引き続き小型の生成モデルを呼び出し、Jev自身はその入力文を生成しません。

作者の報告では、1回のフライト検索に約7秒、費用は約$0.0039で、デモ動画は等速再生でした。ただし、この数字は固定されたそのワークフローの実装結果を示すものであり、あらゆるWebサイトやタスクで同じ速度と成功率が得られることを意味しません。このMVPはshadow DOM、iframe、canvas、ファイルアップロードなどにもまだ対応していません。

この事例の本質は「JevがWebを閲覧できる」ことではなく、まずコードでアクション空間を狭め、その後にモデルへ制約された選択をさせることです。

2. 音声ブラウザー：音声認識とブラウザー実行の間にJevを置く

音声操作ブラウザーの流れは、役割分担をさらに明確に示します。マイクが音声を取得し、音声サービスが文字に変換し、システムが現在のページを読み取って実行可能なアクションを用意し、Jevが1つを選び、最後にブラウザーが実行します。

作者は、Jevによる1回の判断が約300ミリ秒、費用が約$0.0002だったと報告しています。ただし、これは判断工程だけの数字です。録音、音声認識、ページ内の対象特定、ネットワーク転送、ブラウザー実行は含まれません。そのため、「Jevの判断が速い」ことと「音声操作全体が300ミリ秒で終わる」ことは同じではありません。

この方式は、「このタブを開く」「送信をクリックする」「下へスクロールする」のように、有限のアクション集合へ対応付けられる命令に向いています。文章の作成、要約、説明が必要な依頼では、依然として汎用モデルが必要です。

3. DoomとMario：ゲーム画面ではなく構造化された状態を読む

ゲームのデモは特に注目を集めます。公開されたDoomの事例では、位置、敵、武器などの情報を構造化テキストの状態に変換し、Jevが移動、攻撃、その他のアクションを選び、プログラムがその選択をゲームへ返します。

作者は約10 calls/秒、費用は約$7/時と報告しています。ただし、「Jevが画面を直接理解して自律的にゲームをプレイしている」と表現することはできません。TypeSafeの発表資料は、Doomデモが生のピクセルではなく構造化テキストの状態を使用していると明記しています。Marioなどのコミュニティプロジェクトも、状態を意思決定ループへ渡してモデルがアクションを選ぶ実験に近いものです。

これらが示すのは、高速な判断をリアルタイムループに組み込めることです。Jevが汎用的な視覚理解や長期的なゲーム計画能力を持つことを示しているわけではありません。

4. リアルタイム取引：選択が速くても、戦略の収益性は証明されない

取引デモも似た構造を使います。価格、資産、市場状態を整理してJevへ送り、モデルがbuyまたはsellを選び、プログラムが注文を送信します。別のコミュニティ事例では、約300ミリ秒のブロック周期に追従できたとされています。

しかし、公開資料には収益、ドローダウン、スリッページ、手数料の影響、完全なリスク管理結果がありません。そのため、この事例が示すのは、Jevを低遅延の取引判断プロトタイプへ組み込めるという点までです。戦略が利益を出すことは示しておらず、実行速度を投資成績とみなすこともできません。

実システムでは、ポジション上限、ストップロス、権限、注文検証、例外処理を決定論的なコードが管理すべきです。高リスク注文を、モデルの一度の選択だけで自動実行するべきでもありません。

2. 情報層：Jevが分類、採点、境界検出を行う

5. メールとサポートチケットの分類：「どのカテゴリか」だけでは足りない

メール分類はJevの用途を最も直感的に理解できる例の1つです。システムはメール本文をstateに入れ、Jevに営業、請求、技術サポート、その他から選ばせ、その後プログラムが集約、振り分け、または人による確認キューへの投入を行います。

代表的な事例の作者は、500通のメールを数秒、約$0.035で処理したと報告しています。ただし、元の投稿ではメールデータの構成、カテゴリ定義、精度、混同行列が公開されていません。そのため、一般的なメール分類ベンチマークとして扱うことはできません。

実用的な設計では、大きな質問を1つだけ行うべきでもありません。1件のチケットに技術障害、返金要求、強い不満が同時に含まれることがあります。次のように独立した判断へ分解できます。

• Choice：主にどのチームへ送るべきか？
• Score：緊急度はどの段階か？
• Noul：返金、チャージバック、法的リスク、または人へのエスカレーションが含まれるか？

周辺コードは結果を組み合わせて処理経路を決めます。これにより、主カテゴリが正しくても、返金要求やエスカレーション信号を見落として自動処理することを避けられます。

6. セマンティック広告ブロック：ルール一致から内容判断へ

従来の広告ブロッカーは、ドメイン、セレクター、管理されたフィルターリストに依存することが一般的です。コミュニティデモでは、拡張機能がDOM要素とそのclassを1つずつ確認し、Jevに広告らしいか通常のページ内容らしいかを判断させ、広告とされた要素を削除します。

この発想は、セマンティックな判断がルールシステムを補えることを示します。既知のフィルターに一致しない要素でも、テキストやページ構造から広告の意図を推定できる可能性があります。

ただし、公開資料にはバージョン固定されたコード、誤削除率、見逃し率、サイト対応範囲、長期テストの結果がありません。そのため、「誤判定せず回避も不可能な本番システム」ではなく「セマンティック広告ブロックのプロトタイプ」と呼ぶ方が正確です。ナビゲーション、商品レコメンド、サイト内キャンペーンのような境界的要素を誤って消すと、ページ機能が直接壊れる可能性があります。

7. 意図駆動型スプレッドシート：自然言語の列名をセマンティック採点タスクに変える

予測型スプレッドシートの事例では、列名そのものを質問として扱います。Urgencyという列を追加すると、システムが各行のテキストを読み、Jevに緊急度を判断させ、その結果をシートへ書き戻します。

ここでJevがExcel数式を生成しているわけではありません。データ列を繰り返しの分類または採点タスクへ変換しています。同じ方法は、リードの優先度、顧客感情、コンテンツリスク、固定式では表しにくいフィードバックのテーマにも使えます。

作者の動画では約100ミリ秒の処理性能が報告されていますが、行数、計測範囲、キャッシュ方法、スコアの安定性は公開されていません。したがって、任意の列名が自動的に信頼できる「スマート数式」になるとは言えません。本番投入前には、質問の意味を固定し、境界ケースを確認し、どの結果を人がレビューすべきか決める必要があります。

8. YouTubeのスポンサー区間スキップ：モデルが境界を見つけ、コードが再生位置を動かす

YouTube Sponsor Detectionは、動画の字幕を番号付きのテキスト行に分割します。Jevがスポンサー内容に当たる行と、その区間の開始・終了位置を判断します。その後、プログラムが行番号をタイムスタンプへ対応付け、プレーヤーのシークを制御します。

利用可能な字幕がない場合、音声モードではまずDeepgramなどのサービスで文字起こしを行います。つまり、Jevが音声を直接聞いたり、プレーヤーを直接操作したりするわけではありません。役割は字幕内容のセマンティック判断と境界検出です。

作者は、1動画あたり約$0.005のオープンソースBYOKプロトタイプと報告しています。この数字は字幕の長さ、音声モード、文字起こしサービスによって変わり、公開資料には独立した精度テストもありません。自動スキップには、字幕を取得できないことと、通常の発話をスポンサー区間と誤判定することの2つの実務上のリスクがあります。

この事例は典型的な役割分担を示します。モデルがセマンティックな境界を判断し、決定論的なコードが時間変換と再生制御を行います。

3. ワークフロー層：Jevを中間の判断コンポーネントとして使う

9. Agentのコンテキスト圧縮：要約を書き直すのではなく、残す情報を決める

Agentがツールを呼び続けると、ターミナルログ、検索結果、ファイル内容がコンテキストウィンドウを急速に埋めます。一般的な方法は、生成モデルに履歴を要約として書き直させることです。fast-jev-compactionは別の方法を採ります。まずツール呼び出しとその結果を対応付け、Jevに完全に残す、切り詰める、削除する内容を判断させ、コードが実際の刈り込みを行います。

この方法は自由な書き換えを減らし、何が削除されたかを追跡しやすくします。ただし、「高速に削れる」ことは「その後のすべてのタスクが改善する」ことを意味しません。Hermesへの移植評価では、圧縮時間が約1.4秒、保持量が約115K token、再現スコアが75.5%と報告され、検索による復元baselineも用意されていました。結果はテストサンプル、Token予算、移植方法、削除情報を再検索できるかどうかに左右されます。すべてのAgentが長期的にコストを削減できるという結論には一般化できません。

評価すべきなのはタスク全体です。削除後にAgentは検索を繰り返すのか、ユーザー制約を忘れるのか、過去の失敗情報が消えたため同じ間違いを繰り返すのか。後の復元コストが高ければ、単発の圧縮が速くても総コストは下がらない可能性があります。

したがって、コンテキスト圧縮には復元経路と重要情報のallowlistが必要です。ユーザー要件、未完了タスク、権限制約、不可逆操作の記録を、一度の低確率な結果だけで恒久的に削除すべきではありません。

10. json-render：画面全体を自由生成せず、コンポーネントと関係を選ぶ

json-renderのJev実装ノートでは、UI生成を2段階に分けています。第1段階で必要なコンポーネントと個数を判断し、第2段階で親子関係と順序を決めます。その後、コードがJSONを生成・検証し、rendererへ渡して画面を組み立てます。

これは汎用モデルにページ全体のHTMLやJSONを一度に書かせる方法とは明確に異なります。コンポーネント、binding、actionはいずれも制約された集合から選ばれます。Jevは主に構造を選び、コードは出力がレンダリングプロトコルを満たすことを保証します。

自由文がパースできない問題を減らせますが、「構造が正しい」ことは「画面が正しい」ことと同じではありません。コンポーネント選択を誤る、階層がユーザー意図に合わない、文章生成には別のモデルが必要、最終デザインが美しくも使いやすくもない、といった可能性があります。実装ノートは、1バッチで追加する要素数、評価回数、最大深度も制限しています。そのため、任意のプロダクトページを無制限に設計するより、有限のコンポーネントライブラリから画面を組み立てる用途に向いています。

10の事例から何が読み取れるか？

ブラウザー、動画、メール、スプレッドシート、ゲーム、UIと分野は異なりますが、基礎構造はよく似ています。

1. 状態を整理できる。 ページDOM、字幕、メール、ゲーム状態、ツールログをテキスト、JSON、配列として表現できます。
2. 答えを制約できる。 次のアクション、カテゴリ、リスク段階、保持するかどうかを、有限の選択肢、採点基準、確率判断として書けます。
3. コードが結果の使い方を知っている。 クリック、削除、シーク、並べ替え、スプレッドシートへの書き戻し、人への引き継ぎには、明確な実行ロジックがあります。
4. エラーにフォールバック経路がある。 モデルが不確実、APIが失敗、またはリスクが高すぎる場合、停止、再試行、汎用モデルの呼び出し、人への引き継ぎができます。

これはJevと汎用LLMの最も適切な役割分担でもあります。Jevは、頻度が高く、境界が明確な一段階のセマンティック判断を担当します。汎用モデルは引き続き文章生成、新しい計画の提案、複雑な推論、結果の説明を担います。

型付き出力が保証するのは、返り値がインターフェースに合うことだけであり、業務上の判断が正しいことではありません。第三者評価でも、Jevの精度と確率校正はデータセットによって変わることが示されています。高品質なラベル付きデータが数百件たまれば、小型の分類器やencoderの方が高精度、高速で、オフライン実行にも向く可能性があります。したがってJevは、コールドスタートやロングテールのタスクに使う汎用判断コンポーネントとして見るのが適切で、すべての分類タスクの恒久的な終着点ではありません。

本番投入前に省いてはいけない5項目

第一に、質問文をコードと同じようにレビューすること。 Jevの出力は質問と判定基準に強く左右されます。曖昧、矛盾している、または複数の判断を1つに詰め込んだ質問は、型としては正しくても業務上は誤った結果を返す可能性があります。

第二に、自社データでしきい値を校正すること。 デモの確率やしきい値をそのまま本番へコピーすることはできません。言語、コンテンツ種別、リスク段階ごとに別々にテストする必要があります。

第三に、遅延と失敗へのフォールバックを設計すること。 ネットワークリクエストはタイムアウトや失敗が起こり得ます。APIエラーを「いいえ」と扱うのではなく、失敗時に許可、拒否、再試行、人への引き継ぎのどれを選ぶかを事前に定義すべきです。

第四に、高リスク操作を一度のモデル判断だけで実行しないこと。 取引、データ削除、アカウント凍結、コンプライアンスに敏感な内容の公開など不可逆な操作には、決定論的ルール、二次確認、監査記録を残すべきです。

第五に、誤り事例を継続的に記録すること。 入力の版、質問の版、各選択肢の確率、最終操作、人による修正を保存します。そうして初めて、問題が状態構築、質問文、しきい値、モデル本体のどこにあるか判断できます。

まとめ

Jevが最も役立つのは、チャットモデルの代替としてではなく、従来if/elseで書きにくく、毎回大型生成モデルへ送るには高価だったソフトウェア上の判断点に組み込む場合です。

Browser Useでは次のWebアクションを選び、メールシステムではルーティングとエスカレーション信号を判断し、YouTubeのプロトタイプではスポンサー区間の境界を検出します。json-renderではコンポーネント関係を選び、コンテキスト圧縮ではどの履歴情報をウィンドウに残すかを決めます。これらが成立するのは、Jevが単独でタスク全体を完了するからではありません。開発者が状態、候補、実行ロジック、しきい値、フォールバック経路を合わせて設計するからです。

判断境界が明確で、出力を制約でき、コードが結果を確実に処理できるとき、Jevは最も価値を発揮します。長文生成、多段階推論、自由度の高い計画、説明可能な結論が必要なタスクでは、汎用LLMが引き続き不可欠です。