2026年に試せるオープンソースのJevプロジェクト20選：MCP、コーディングエージェント、ブラウザー自動化など

Jevが公開されてからまだ短い期間しか経っていませんが、開発者たちはすでにコーディングエージェント、ブラウザループ、MCPツール、データセットパイプライン、ゲーム、ロボティクス実験、トレーディングシステムにJevを組み込んでいます。

これは、理論上のJevのユースケースをまた列挙するものではありません。以下のプロジェクトが示すのは、より有用なことです。開発者が実際のソフトウェアの中に意思決定モデルを配置する場所、Jevに何を決定させるのか、そしてどの部分を決定論的なコードや、より大規模な生成モデルの下に残すのか。

モデル自体について初めて知る方は、Jevの意思決定モデルの仕組みを解説した記事から始めてください。個々のリポジトリではなく、より広いアプリケーションパターンを探している方には、実際のJevのユースケースを紹介した先行ガイドで、エージェントのオーケストレーション、調査のトリアージ、ブラウザ自動化など、さまざまなワークロードの種類を取り上げています。

ただし、注意点が1つあります。このエコシステムはまだ非常に新しいものです。多くのリポジトリは実験、デモ、または個人開発者によるプロジェクトです。これらを本番ソフトウェアとして扱う前に、現在のリポジトリ、ライセンス、APIの動作、安全境界を確認してください。

20のJevプロジェクトが実際に検証していること

表面的にはプロジェクトごとに大きく異なりますが、その多くは同じアーキテクチャに従っています。

構造化された状態 ↓ 制約された判断 ↓ 通常のソフトウェアポリシー ↓ ツール、モデル、またはアクション

重要なのは、Jevがワークフロー全体を担うことはほとんどないという点です。通常は、別のLLM呼び出しや増え続けるヒューリスティックの集まりが必要になる、狭い範囲の曖昧な判断を1つ置き換えます。

コーディングエージェントはJevにとって最も興味深いテストベッドになりつつある

Coding agents generate huge amounts of intermediate state: file contents, command output, stack traces, diffs, test logs and repeated routing decisions. Much of that work does not need another paragraph from a frontier model. It needs selection.

コーディングエージェントは、ファイルの内容、コマンド出力、スタックトレース、差分、テストログ、繰り返される振り分け判断など、大量の中間状態を生成します。その多くは、フロンティアモデルによる新たな段落を必要としません。必要なのは選択です。

1. fast-jev-compaction — 書き換えずにコンテキストを圧縮する

fast-jev-compactionは、通常の要約中心のコンパクション処理を、過去のツール呼び出しと結果に対する関連性判断に置き換えます。

価値は、Jevがより優れた要約を書くことではありません。要約を書くこと自体を避ける点にあります。価値の低い履歴は削除または短縮できますが、保持するコマンド、パス、エラー、出力は逐語的に残ります。これにより、コンテキスト圧縮は書き換えではなく選択の問題になります。

2. Winnow — 無関係なツール出力がコンテキストに入る前に止める

Winnowは、パイプラインのより早い段階で同じ問題に対処します。大量の Read, Bash または Grep 結果はブロックに分割され、追加のコンテキストを消費する前に、タスクとの関連性が評価されます。

コンパクションとの違いは重要です:

• Winnow:作業コンテキストに入る途中で情報をフィルタリングします。
• fast-jev-compaction:会話履歴にすでにある古い情報を削除します。

両者を合わせると、コーディングエージェントが、トークンを大量に消費する要約を、限定的な関連性判断に置き換えられる2つの異なる箇所が示されます。

3. Jev Codex Router — タスクに本当に必要なモデルの規模を判断する

Jev Codex Routerは、判断をさらに一段上に移します。Codexがタスクを処理する前に、Jevがモデルの階層と推論の強度を選択します。

これにより、Jevはコーディングモデルではなく、トラフィックコントローラーになります。簡単な作業はより安価な経路にとどめ、難しいターンは上位の経路へエスカレーションできます。

リポジトリでは、テストしたすべてのターンを以前の最も高コストな経路に振り分けた場合と比べて、大幅な節約が見込まれるという過去のシミュレーション結果が報告されています。ただし、この数値はバックテストの結果であり、現在のCodexクォータの実測上の節約額として扱うべきではありません。

このアーキテクチャは、以前にも検討したより広い問いともつながります。つまり、小規模なモデルが大規模モデルにリクエストを振り分けられるか、そしてそれ自体が最終的な推論エンジンにならずに済むか、という問いです。

4. Jev Review — 重要な箇所にレビューの注意を向ける

Jev Reviewは、コードレビューを、注目すべきファイル、関連する証拠、疑わしい問題の深刻度など、より限定された判断に分解します。

興味深いのは優先順位付けです。Jevは最終レビューを生成しなくてもワークフローを改善できます。まず大規模な差分を、より深い推論や人によるレビューに時間を費やす価値のある箇所へ絞り込めるのです。

5. Blink - コードベースを一度に1つの意味的な選択でナビゲート

Blink は、リポジトリ検索をパス選択として扱います。

各ディレクトリレベルで、表示可能なファイルとフォルダーが候補になります。Jevは現在の質問に対して最も有望な次の分岐を選択し、検索を再帰的に続けます。

すべてのクエリの前にリポジトリ全体を埋め込む代わりに、システムはより範囲の狭い質問を繰り返し尋ねます。次にどこを調べるべきか？

6. Canny - 「完了したと思う」と作業が完了したことを示す証拠を分離

Canny は、エージェントによる完了の主張を対象とします。

決定論的な記録は、実際に起きたことを追跡します。変更されたファイル、実行されたコマンド、完了したテスト、生成された出力などです。Jevはこの証拠に対する意味的な判断を加えられますが、モデルが最終的な権限レイヤーになるわけではありません。

この分離は、実際のシステムを変更できるローカルエージェントにとって重要です。ツール実行の信頼境界に関するガイドでは、より広いエージェントアーキテクチャのレベルで同じ原則を説明しています。つまり、あるアクションが適切に見えると判断することと、その実行を許可することは同じではありません。

MCPとCLIのプロジェクトがJevをインフラストラクチャに変える

次のグループは、アプリケーションへの依存がやや少ないものです。これらのプロジェクトは、既存のツール内で再利用可能な意思決定プリミティブとしてJevを利用できるようにします。

7. typesafe-mcp - 既存のエージェントにJevへの直接アクセスを提供

typesafe-mcp は、Model Context Protocolを通じてJevを公開します。

Claude、Codex、またはMCP互換エージェントは、新しいワークフローごとにJev統合を実装しなくても、構造化されたChoice、Score、またはNoulの判断を要求できます。エージェントは引き続き、ツールを呼び出すタイミングと結果をどう扱うかを決定します。

8. jev-mcp - 共通の意思決定をエージェントツールとしてパッケージ化

jev-mcp は、分類、スコアリング、スクリーニング、マッチングなどの使い慣れた操作を公開することで、抽象化レベルを引き上げます。

同じ判断のためにエージェントがそれぞれ新しいプロンプトを考案する代わりに、共通する意思決定パターンを、構造化された出力を備えた再利用可能なインターフェースにできます。

9. SemDecide - Unixパイプラインに意味的ロジックを組み込む

SemDecideは、さらに小さな統合面、つまりコマンドラインを探求しています。

grep → jq → 意味的判断 → シェルアクション

これは、正規表現では表現しにくいものの、自律エージェントを使うほど複雑ではない質問に役立ちます。たとえば、変更がセキュリティ上の懸念を含むように見えるか、あるいはレコードが意味的なカテゴリに属するかどうか、といった質問です。

重要な境界は依然として決定論的です。権限、破壊的なコマンド、本番環境の安全性チェックは、通常のコードに残すべきです。

ブラウザーとデスクトップのエージェント：生成するのではなくアクションを選択する

ブラウザー自動化は、制限された意思決定レイヤーに非常によく適合します。ページを候補要素に変換すると、ループの大部分は言語生成ではなくアクション選択になります。

10. jev-ultrafast - ブラウザーが実際に語句を必要とするときだけ生成する

jev-ultrafastは、現在のページからインデックス化されたアクション空間を構築し、Jevが操作と対象要素を選択できるようにします。

選択したアクションでフォームフィールドへの入力など新しいテキストが必要な場合にのみ、生成モデルが必要になります。

このプロジェクトのGoogle Flightsデモでは、生成とページ待機を含む1つのタスク例に約7秒かかると報告されています。これは、ブラウザーエージェントの普遍的なベンチマークとして扱うべきではありません。より重要な成果はアーキテクチャにあります。クリックの選択とテキスト生成に同じモデルを使う必要はありません。

11. agent-desktop - 同じパターンをネイティブUIに適用する

agent-desktopは、アクセシビリティデータと安定した要素参照を通じてmacOSのインターフェースを公開します。

毎回スクリーンショットからデスクトップを再構築する代わりに、システムはJevに制限された一連のコントロールとアクションを渡せます。実際のクリック、フォーカス、キーボード操作は、引き続きネイティブツールが実行します。

これは、より大きなモデルよりも、より良い観測のほうが重要な場合が多いことを思い出させてくれます。

12. json-render + Jev - 任意のUI生成を行わない生成UI

json-renderは、アプリケーションが所有するコンポーネントカタログからインターフェースを構成するためにJevを使う実験を行っています。

アプリケーションは、使用可能なコンポーネント、プロパティ、アクションを定義します。Jevはそれらの候補から選択し、通常のコードが結果のツリーを組み立てて検証します。

Jevの構成パスはまだ実験的ですが、制約のないUI JSON生成に代わる有用な方法を示しています。アプリケーションが語彙を定義し、その中からモデルに選ばせるのです。

ゲームとロボティクスは、Jevを制御に使うべきでない領域を示す

リアルタイムシステムでは、設計上の境界が明確になります。物理演算、衝突処理、安全制御、高速制御ループは、不確実なモデルの応答を待つことができません。

13. typesafe-mario — 構造化されたゲーム状態を入力し、実行可能なコントローラーアクションを出力

TypeSafe Marioは、スクリーンショットをJevに送るのではなく、エミュレーターのテレメトリとRAMをコンパクトな構造化状態に変換します。

その後Jevは、右へ移動、ジャンプ、走りながらジャンプするといった、コントローラーで実行可能なアクションから選択します。タイミング計算、エミュレーター制御、ゲーム状態の抽出は通常のソフトウェアに任せます。

このデモは意思決定の問題を明確に切り分けています。モデルは、動作のたびに画素情報からゲーム世界を再発見する必要がありません。

14. jev-drone — モデルは安全ループより上位に置く

jev-droneは、MuJoCoシミュレーション内で自律型クアッドローターを飛行させます。

高速な幾何学的制御、誘導、安全制御は決定論的なまま維持されます。Jevはより低速な助言的戦術レイヤーとして動作し、現在の状況を解釈します。

500 Hzの飛行制御 50 Hzの誘導 + 安全制御 15 Hzのカメラ → シンボリックシーン 約2.5 HzのJev戦術判断

このプロジェクトはシミュレーションであり、Jevが実際の航空機を制御すべきだという証拠ではありません。その設計上の教訓は、その主張よりも重要です。確率的な判断は、ハードリアルタイムの安全ロジックより上位に置くべきです。

15. OneVOneJev — ゲームループの大半は選択の反復

OneVOneJevは、ブラウザベースの1対1シューティングゲームにJevを適用します。

サーバーが物理演算、ネットワーク、ゲームの法的状態を管理します。Jevはその制約された世界の中で、移動または戦闘のアクションを選択します。

そのため、このプロジェクトはゲーム製品としてよりも、自然言語による説明を加えてもほとんど意味がない、制約付きの反復的な意思決定に対するストレステストとして有用です。

取引実験：意思決定モデルにウォレットを管理させない

金融デモは、より厳密に解釈する必要があります。素早い市場判断は、収益性の高い取引の証拠ではありません。また、実験的なボットを検証済みの戦略と混同すべきでもありません。

16. jev-trader — Monadの各ブロックで1回だけ方向を決定

jev-traderはMonad上のKuru MON-USDCの注文板を監視し、1ブロックごとにJevへ買いまたは売りの方向を選ばせます。

周辺システムが市場データ、指値注文の作成、ポジション制約、執行を処理します。秘密鍵なしのドライラン運用にも対応しています。

その境界こそが有用な部分です。Jevは市場判断を担い、通常のソフトウェアが取引の仕組みを担います。

17. Prism - Jevを戦略ではなくシグナルとして扱う

Prismは、より助言的なアプローチを取ります。Jevは、フロー品質、プレッシャー、平均回帰シグナルなどの市場状況を評価し、戦略層と執行層は分離されたままです。

これは、影響の大きいワークフローに適した、より優れた一般的パターンです。モデルは確率的な証拠を提供できますが、取り消し不能なアクションに対する権限まで引き継ぐ必要はありません。

検索とデータパイプラインが示す、Jevにエージェントは不要

最も優れたプロジェクトの中には、自律エージェントを完全に排除するものもあります。Jevは従来型アルゴリズム内の1つの意味的操作になります。

18. neo4jev - グラフ検索に意味的判断を追加

neo4jevは、Neo4jのナレッジグラフを探索する際にJevを使用します。

各ノードでは、候補となる関係が限定された選択肢になります。Jevは現在の質問に対して最も有望なエッジを推定し、古典的な検索コードが探索、訪問済みノード、ビーム幅、停止条件を処理します。

これはグラフ以外にも応用できる便利なパターンです。アプリケーション全体をAI中心に再構築するのではなく、既存のアルゴリズム内にある脆弱なヒューリスティックを1つ置き換えます。

19. jev-curate - さらに計算資源を投入する前にデータをスコアリング

jev-curateは、JSONLまたはParquetのレコードに対して繰り返し意味判断を適用し、よりコストの高いトレーニング、分析、レビューの段階に入る前に処理します。

データキュレーションは、意思決定が中心となる自然なワークロードです。数百万行に対して関連性、品質、リスクの判断が必要になる場合がありますが、生成された文章が必要になることはほとんどありません。

モデルは曖昧な評価を担当し、パイプラインはバッチ処理、しきい値、ストレージ、最終的な採用ポリシーを引き続き管理します。

20. killmyidea - アーキテクチャを明確に示す小さなデモ

killmyideaは、複数の構造化された質問を通じてスタートアップのアイデアを評価するようJevに依頼します。

次にアプリケーションが通常の重み、ゲート、しきい値を適用し、それらのスコアを最終的なKILL、FIX、またはSHIPの判定に変換します。

アイデア ↓ Jevによるスコアリング ↓ 決定論的な重み付け ↓ KILL / FIX / SHIP

小規模なプロジェクトですが、AIは最終的な成果物の出力を生成する責任を負わずに、有用な判断を加えられるという重要な設計原則を示しています。

最初に試すべきJevプロジェクトは？

これらのJevプロジェクトはローカルで実行できますか？

多くの場合、周辺のプロジェクトはローカルで実行できます。ただし、それはJev自体がローカルで実行されていることを意味しません。

2026年9月現在、Jevは一般公開されたダウンロード可能なモデル重みではなく、ホスト型のTypeSafeサービスとして利用します。そのため、ローカルのコーディングエージェント、MCPサーバー、またはブラウザーコントローラーを自分のマシン上で実行しながら、選択した判断状態をJev APIに送信できます。

ローカルファイル / ブラウザー / エージェント ↓ ローカルハーネスまたはMCPサーバー ↓ 選択された構造化状態 ↓ Jev API ↓ 型付き判断 ↓ ローカルソフトウェアが実行

判断モデル自体を自分のハードウェア上に置くことが重要なら、そこでアーキテクチャが変わります。オープンソースのローカル判断モデルLayaに関するガイドでは、ダウンロード可能な重みを備え、ローカルハードウェアで実行できる代替手段を紹介しています。

この区別は、ホームラボやプライベートAIの導入に役立ちます。

この違いは、GitHubのREADMEに「ローカル」と書かれているかどうかより重要です。ワークフロー全体をローカルでホストしていても、1つの判断ステップが外部の推論サービスに依存している場合があります。

本当のJevパターンはエージェントより小さい

これら20のプロジェクトで最も重要なのは、開発者がすでに構築したアプリケーションの数ではありません。Jevがループ内の1つの狭いポイントに、一貫して現れることです。

ブラウザーは、どの要素が存在するかをすでに把握しています。Jevは1つを選びます。

コーディングエージェントは、すでに何千行ものツール出力を生成しました。Jevは、なお重要なものを判断します。

ルーターは、どのモデルが利用可能かをすでに把握しています。Jevは経路を選びます。

グラフには、すでにエッジが含まれています。Jevは、どれが有用そうかを選びます。

ドローンには、すでにフライトコントローラーがあります。Jevは、より低頻度の戦術的判断を提供します。

取引システムには、すでに注文ロジックとリスク制約があります。Jevは方向性のシグナルを提供します。

だからこそ、Jevプロジェクトの第一波は、また別のチャットボットデモ集よりも興味深いのです。開発者たちは、現在のAIスタックの一部を、そもそも生成型であり続けるべきなのかを検証しています。

したがって、役に立つ問いは、Jevが最先端のLLMを置き換えられるかどうかではありません。

今日のソフトウェア内にある高価で自由度の高いLLM呼び出しのうち、実際には小さなインターフェースを待つ、範囲の限定された判断にすぎなかったものがどれほど多いか、ということです。