Jev対応OSSが、モデル公開から4日で一気に揃った。文章を返さず型つきの判定だけを返すこのモデルを「どこに差し込むか」を、11本のリポジトリがそれぞれ別の場所で答えている。本記事は、ブラウザ操作の jev-ultrafast、MCP接続の typesafe-mcp と jev-mcp、Unixパイプラインの SemDecide、Codexのモデル選択、Claude Codeの文脈選別、コードレビュー、コードベース探索、知識グラフ探索、デスクトップ操作、実験CLIの11本を全件 clone して star・ライセンス・最終コミットを実測し、Linux 上で7本をインストールから起動確認まで通した結果をまとめる。Jev本体の仕組みはJevとは|文章を返さないSystem Oneモデルの正体を公式SDKのコードで実測し、Claude Codeで試すで扱ったので、ここでは「その上で何が作られたか」に絞る。
- ・正体:TypeSafe AI の System Oneモデル Jev(判定と確率だけを返すAPI)を呼ぶ、有志と企業のオープンソース11本。Jev本体は非公開のホスト型API。
- ・何ができる:MCP経由で Claude Code/Codex から判定を取る、シェルパイプラインで意味判定する、ブラウザ・デスクトップの次の操作を決める、重いモデルの前段でモデル選択・文脈選別・事前レビューを済ませる。
- ・実測できたこと:11本すべての clone・LICENSE・最終コミット、star。7本は起動確認まで到達(typesafe-mcp v0.4.1、jev-mcp 0.4.0、SemDecide 0.2.1、blink、jev-ultrafast のローカルUI、neo4jev の単体テスト161件、typesafe-ai-playground のビルド)。
- ・届かなかったこと:検証環境から
api.typesafe.aiへの通信が遮断されており、Jevの実応答を含む挙動は未検証。macOS専用の jev-desktop と jev-codex-router も未検証。 - ・注意:9本がMIT、agent-desktop は Apache-2.0、blink はライセンス未記載。全員が「early」「MVP」「experiment」のいずれかを自己申告している。
LLMそのものの仕組みと主要モデルの比較はLLMとは?仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版にまとめてある。Jevは「LLMの構造化出力に投げていた判定処理」を置き換える位置にあるので、そちらで LLM 側の常識を押さえてから読むと、11本が何を省いているかが見えやすい。
Jev対応OSSが4日で11本——何が起きているかを表で見る
まず全体像を1枚の表にする。star は GitHub のリポジトリページを 2026-09-19 に読んだ値、最終コミットは git clone --depth 1 で取った既定ブランチの最新コミット日、ライセンスはバッジではなく実体ファイルを読んだ結果である。「当記事の到達点」は Linux x86_64 の検証環境で何をどこまで確認できたかを示す。
| # | リポジトリ | 層 | 言語 | star | ライセンス | 最終コミット | 当記事の到達点 |
|---|---|---|---|---|---|---|---|
| 1 | browser-use/jev-ultrafast | 操作 | Python | 5.4k | MIT | 09-18 | uv sync → ローカルUI起動(HTTP 200) |
| 2 | itsmostafa/typesafe-mcp | 接続 | Go | 67 | MIT | 09-18 | go install → v0.4.1 起動・tools/list 応答 |
| 3 | jkudish/jev-mcp | 接続 | TypeScript | 72 | MIT | 09-18 | npx → 0.4.0 起動・tools/list で4ツール確認 |
| 4 | sharziki/semdecide | CLI | Python | 5 | MIT | 09-16 | uv tool install → 0.2.1・終了コード4を確認 |
| 5 | 0xNatoshi/jev-codex-router | コーディング | Python | 41 | MIT | 09-17 | macOS+Codex Router 前提のため未検証 |
| 6 | GhalebDweikat/winnow | コーディング | Python | 17 | MIT | 09-17 | hooks.json と sidecar の構成を読んだのみ |
| 7 | devagrawal09/jev-review | コーディング | TypeScript | 264 | MIT | 09-17 | npm install 成功・Node 24 要件で実行は未検証 |
| 8 | ellipsis-dev/blink | コーディング | TypeScript | 17 | 未記載 | 09-16 | bun install → 起動・API遮断で403を確認 |
| 9 | jexp/neo4jev | 探索 | Python | 17 | MIT | 09-18 | uv sync → 単体テスト161件パス(11件スキップ) |
| 10 | lahfir/agent-desktop(jev-desktop) | 操作 | Rust+Node | 1.3k | Apache-2.0 | 09-17 | macOS 専用のため未検証 |
| 11 | markjaquith/typesafe-ai-playground | CLI | Rust | 1 | MIT | 09-18 | cargo build --release → 0.1.0 のヘルプ表示 |
表から読めることは3つある。
・star の分布が極端:5.4k の jev-ultrafast と 1.3k の agent-desktop は既存プロダクト(Browser Use と Agent Desktop)の名を借りており、純粋に Jev のために生まれた9本は最大でも264(jev-review)で、5本は20未満。当サイトの通常の題材ゲート(star 200)を満たすのは3本だけで、本記事は「エコシステムの現状を1枚で見る」目的で例外的に全件を扱っている
・11本中10本が過去3日以内に更新されている。公開直後の熱量であり、来月も同じ状態とは限らない
・ライセンスは1本だけ要注意:blink には LICENSE ファイルが無く、package.json は "private": true で license 項目も無い。OSSとして再利用する前提では扱えない
接続層:typesafe-mcp と jev-mcp——Claude Code から Jev を呼ぶ2つの流儀
Claude Code や Codex からJevを呼ぶ最短経路は MCP サーバである。同じ目的の2本が、設計思想で真逆に分かれているのが面白い。
typesafe-mcp(itsmostafa) は Go の単一バイナリで、公開するツールは evaluate の1つだけ。state(判断材料)と questions(choice/noul/score の型つき質問)をそのまま Jev に渡し、確率つきの答えを返す。v0.4.0 でバイナリ名を jev から evaluate に改名しており、READMEには「バイナリ名がモデル名と同じで、コマンドが何をするか伝わらなかった」という理由が書かれている。エージェント側が質問を自分で組み立てる前提なので、薄いが自由度は高い。
jev-mcp(jkudish) は逆に、用途ごとにツールを切っている。jev_verify(主張が根拠に支持されるか・矛盾するか・何も言っていないかの Choice)、jev_screen、jev_find、jev_classify が公開版のツールで、READMEにはさらに jev_decide・jev_rerank・jev_compare・jev_extract の4本が載っている。ここで実測と公称がずれた。
実測メモ:jev-mcp の公開ツール数:npx -y @jkudish/jev-mcp(npm 0.4.0)を stdio で起動し、tools/list を送ると返ってくるのは jev_verify・jev_screen・jev_find・jev_classify の4本。main の src/index.ts には registerTool が8回あり、CHANGELOG では jev_decide と jev_rerank が「Unreleased」節に置かれている。READMEは main の姿を書いているので、npm 経由で入れた読者は4本しか使えない。
導入コマンドは次の2行で足りる。typesafe-mcp の公式手順は install.sh を curl | sh する形だが、検証環境では GitHub Releases への通信が遮断されていたため go install で入れた(Go 1.24.7 で成功、evaluate --version は v0.4.1)。jev-mcp は npx で起動し、[jev-mcp] ready — model jev-latest と出ることを確認した。下の2行も検証環境(Claude Code 2.1.277)で実行し、evaluate setup mcp は Claude Code を検出して登録(Codex と Claude Desktop は未検出でスキップ)、claude mcp list で両サーバとも Connected になった。
# typesafe-mcp:Go があれば go install、無ければ README の install.sh
go install github.com/itsmostafa/typesafe-mcp/cmd/evaluate@latest
TYPESAFE_API_KEY=your-key evaluate setup mcp # Claude Code / Claude Desktop / Codex に一括登録
# jev-mcp:Node 20+ があれば npx だけ
claude mcp add jev -- npx -y @jkudish/jev-mcp
どちらも TYPESAFE_API_KEY の代わりに OPENROUTER_API_KEY を受け付け、jev-mcp はさらに Cloudflare AI Gateway と Vercel AI Gateway の鍵にも対応する。ウェイトリスト待ちの間に OpenRouter 経由で試せる、という逃げ道が両方に用意されている。
エージェントから見た呼び出しの形は共通で、次の流れになる。
Claude Code/Codex"] --> B["MCPツール
evaluate または jev_verify"] B --> C["Jev API
state+型つき質問"] C --> D["確率つきの判定
choice/noul/score"] D --> E{"確信度が閾値以上?"} E -->|yes| F["コード側で分岐して実行"] E -->|no| G["重いモデルか人に回す"]
jev-mcp のREADMEが「型つき出力が保証するのはインターフェースであって真実ではない」と明記している点は、11本すべてに当てはまる。閾値(jev-mcp では auto_accept と block_at)はあくまで初期値で、自分のデータで調整することが前提だ。
操作層:jev-ultrafast と jev-desktop——1往復2判断でブラウザとデスクトップを動かす
11本の中で最も話題になったのが jev-ultrafast(Browser Use) だ。READMEの1行目は「Zürich → London を Google Flights で 7.1 秒」。この数字の中身を docs/performance.md まで読むと、次のことが分かる。
・比較は6回の交互実行・1タスク・既存Chromeプロファイルで、旧ランタイムと新ランタイムを3組ずつ走らせたもの
・中央値は 9.450秒 → 7.092秒(25.0%短縮)、Jevへのリクエスト数は 22 → 17、ブラウザプロトコル呼び出しは 1,092 → 101
・作者自身が「3組は統計的主張には少なすぎる(符号検定 p = 0.25)」「小さな制御実験であって広いエージェントベンチマークではない」と書いている
・収録動画では Jev リクエスト17回・操作10回+明示的WAIT1回・テキスト生成の補助モデル呼び出し2回、Jev のレイテンシ中央値は178ms
仕組みは「観測→Jevに2問→実行→再観測」のループで、operation(CLICK/TYPE_TEXT/SELECT/SCROLL/WAIT/DONE/BLOCKED)と、その operation に対応する target を同じ1リクエストで聞くのが要点だ。READMEの言葉では「Two decisions, one network round trip」。同じ設計を macOS のアクセシビリティツリーに移したのが agent-desktop の jev-desktop スキルで、こちらは run.mjs(ゴールを渡して完了まで回す)と act.mjs(1手だけ解決して計画は呼び出し側に返す)の2つの入口を持つ。SKILL.md には「target は operation ごとに1回だけ聞く。選ばれた動詞に対応する候補しか読まないので、動詞と対象が食い違うことはない」とある。
検証環境では jev-ultrafast を次の手順で入れ、uv run jev でローカルUI(http://127.0.0.1:8766、タイトル「Jev Ultrafast · Browser Use」)が HTTP 200 で立ち上がるところまで確認した。
# jev-ultrafast:Python 3.12 と uv が前提。.env に TYPESAFE_API_KEY と TEXT_MODEL_API_KEY を書く
git clone --depth 1 https://github.com/browser-use/jev-ultrafast.git && cd jev-ultrafast
uv sync && cp .env.example .env
uv run jev # http://127.0.0.1:8766 を開き Start demo → Run automatically
Jev への通信が遮断されているため、デモの実行は未検証である。READMEの制限事項も引いておく。shadow DOM・iframe・canvas・ファイルアップロード・ポップアップタブ・入れ子スクロール・任意のキーボードウィジェットは MVP の対象外で、DOMリーダーはアクセシブルネームの仕様を完全には実装していない。jev-desktop は macOS 13 以上専用で、Windows と Linux は「計画中」の段階だ。
コーディング層:Codex Router・Winnow・Jev Review・Blink——重いモデルの前段に置く
4本とも「重いモデルを呼ぶ前に、安い判定で仕事を減らす」という同じ狙いを、別の場所で実装している。
Jev Codex Router(0xNatoshi) は Codex のターンごとに Jev で難易度を判定し、機械的な作業は最安モデル、標準は中位、難問だけ最上位に回す。READMEの看板は「7日分・237ターンのリプレイで、全ターン最上位モデルの基準に対して約60%削減」。BACKTEST.md を読むと、基準 871ドル → 採用方針 349ドル(−59.9%)で、階層の内訳は最安61ターン・中位165ターン・最上位11ターン。興味深いのは校正の失敗談で、最初の方針は「迷ったら最上位へ」だったところ、実際のターンは短く文脈依存で約3分の2が「迷い」に該当し、削減は−11.9%止まりだった。「迷ったら中位へ」に変えて初めて−59.9%になっている。
前提が重い点は注意したい。macOS・Codex デスクトップ・ローカルの Codex Router(ポート4202)が必要で、ルーティング先のモデル名(gpt-5.6-luna/gpt-5.6-sol/gpt-6-astra)は作者の環境に合わせて書かれている。Claude Code 側で同じことをしたい場合は、Jevとはで扱った jev-router が対応する。
Winnow(GhalebDweikat) は Claude Code のプラグインで、Read・Bash・Grep の長い出力を約25行のブロックに割り、「このブロックは今のタスクに必要か」を Jev に一括で聞いてから文脈に入れる。確信をもって「不要」と判定されたブロックは3行のスタブに置き換え、鍵を残して後から winnow_recall で呼び戻せる。hooks.json を読むと、PostToolUse の matcher が Read|Bash|Grep、SessionStart で uv 経由のサイドカーを起動する構成になっており、READMEはフック経由のオーバーヘッドを コマンドフックで381ms・サイドカーで16ms(作者環境)としている。Jev がアーリーアクセスであることを前提に、同じリクエストを Claude Haiku 4.5 に送るアダプタが同梱されているのも実用的だ。閾値の既定は WINNOW_DROP 0.1、WINNOW_KEEP 0.5。
Jev Review(devagrawal09) は Git の差分かコードベース全体を対象に、Noul のリスク行列 → Choice と Score のファイルプロファイル → 証拠の選択 → 深刻度 → 重いレビュアーへの条件付きルーティング、と段階的に Jev を呼ぶ。correctness・security・reliability・compatibility・test coverage の5観点を見て、結果はローカルのダッシュボード(http://127.0.0.1:4317)に出る。READMEは「発見はレビューの手がかりであって欠陥の証明ではない」「コンパイラ診断・静的解析・リポジトリ索引は未統合」と率直だ。
Blink(ellipsis-dev) は自然言語の質問とディレクトリを渡すと、複数の「walker」がファイルシステムを降りていく。各階層で Jev がファイル名・フォルダ名をスコアリングし、確率の高い経路に多くの walker を割り当てる。--n_walkers 100 なら100本のトレースが残り、それぞれの選択と確率が記録される。Bun 1.3.14 以上が前提で、検証環境では bun install の後に ./blink "where is the http client" ../jev-mcp を実行し、Jev API への接続で 403(検証環境のプロキシ遮断)が返るところまで確認した。動作自体は未検証だが、起動とエラー経路は確認できた。前述の通りライセンスが無い点だけは、参考実装として読む以外の用途を止める。
CLI・探索層:SemDecide・typesafe-ai-playground・neo4jev——パイプラインと知識グラフ
SemDecide(sharziki) は Jev を Unix コマンドに仕立てたもので、READMEの自己紹介は「意味の grep、判定の jq」。is(Noul の述語)、choose(Choice のルーティング)、score(Score の段階評価)、filter(JSONL の意味フィルタ)、guard(エージェント操作の可否)の5コマンドがあり、終了コードが定義されているのが CI 向けの決定的な差だ。
| 終了コード | 意味 |
|---|---|
| 0 | 真・選択済み・スコア済み・フィルタに1件以上の確定一致 |
| 1 | 偽、またはフィルタ一致なし |
| 2 | ローカル入力かコマンドの使い方が不正 |
| 3 | 設定したマージンや確信度の下限を満たさない「不確実」 |
| 4 | プロバイダ・認証・タイムアウト・不正応答の失敗 |
「不確実(3)」と「失敗(4)」を分けているので、if 文で「迷ったら人へ」「落ちたら再試行」を書き分けられる。検証環境では uv tool install で 0.2.1 を入れ、ダミーの鍵で次のコマンドを流したところ、semdecide: provider error: semantic provider request failed と出て終了コードは 4 だった。表どおりの挙動である。
# SemDecide:述語を1つ聞いて、終了コードで分岐する(検証環境では API 遮断のため 4 が返る)
echo "Thanks, see you tomorrow" | TYPESAFE_API_KEY=your-key semdecide is "a farewell message"
echo "exit=$?"
READMEには「SemDecide は認可システムでもサンドボックスでも安全性の証明でもない。金銭・資格情報・本番基盤・私的データ・不可逆な操作の周りには決定論的な権限チェックを残せ」とある。guard を使う人ほど読んでおきたい一文だ。
typesafe-ai-playground(markjaquith) は Rust の実験用CLIで、phi(HIPAA の PHI 検知を4つの Noul で独立判定)、code-comments(JS/TS コメントの正確さと有用性を2つの Score で採点)、load-bearing(各行の重要度をスコアリングしてヒートマップ表示)、be-nice(入力中の文のトーンを50msデバウンスで採点)、business/job(IRS の業種コードと O*NET の職業コードを最大253択の Choice を再帰的に辿って特定)を持つ。cargo build --release は通り、typesafe-ai 0.1.0 のヘルプで6つのサブコマンドを確認した。PHI 検知については「法的な結論を出すものではなく、スクリーニング信号として扱え」と明記されている。star は1で、作者個人の実験場という位置づけを超えていないが、Choice の上限255択を再帰で回避する書き方は他のツールでも使える。
neo4jev(jexp) は Neo4j のグラフを1ホップずつ辿るデモで、各ノードで出ていく関係を Choice の選択肢として Jev に見せ、返ってきた確率分布をビームサーチで積み上げて最有力の経路を探す。「ゴールに着いたか」を問う Noul を同じ system_one 呼び出しに相乗りさせるので、質問が何個でも1ホップ1往復で済む。スーパーノード対策として1ホップの候補を関係タイプごとに10本・合計60本に制限し、READMEは Apple Inc.(出エッジ1,354本)の例で「17の関係タイプすべてに予算が行き渡る」と説明する。検証環境では uv sync の後 uv run pytest で 161件パス・11件スキップ(スキップは API とライブDBを要する結合テスト)を確認した。知識グラフを探索の対象にする発想はLightRAG とは|知識グラフ×デュアルレベル検索の仕組みとストレージ選定の系譜に近く、LLM に経路を生成させる代わりに Jev に「次の1歩」だけ選ばせるのが違いだ。
実測:Linux で7本を起動確認した結果と、届かなかったところ
検証環境:Linux x86_64/Python 3.12(uv)/Node 22.22.2/Bun 1.3.14/Go 1.24.7/Rust stable/2026-09-19。11本を git clone --depth 1 し、LICENSE の実体ファイル・既定ブランチの最終コミット日・タグ(git ls-remote --tags)を確認。api.typesafe.ai と console.typesafe.ai は環境のプロキシで遮断されており、Jev の実応答を伴う挙動はすべて未検証。macOS 前提の jev-desktop と jev-codex-router、Claude Code プラグインとしての Winnow の実動作、Node 24 を要する jev-review の実行も未検証。
起動確認の要点を、ツールごとに1行で残す。
・typesafe-mcp:go install で v0.4.1。stdio で initialize → tools/list を送ると evaluate ツールと「Jev は typed judgments と probabilities を返す」という instructions が返る
・jev-mcp:npm 0.4.0 を npx 起動。tools/list の応答は4ツール(README の8本と差がある)
・SemDecide:0.2.1。ダミー鍵で終了コード4(プロバイダ失敗)を確認
・blink:bun install 成功。実行すると Jev への接続で 403(環境の遮断)を表示して終了
・jev-ultrafast:uv sync で browser-harness==0.1.13 を含めて解決。uv run jev でローカルUIが立つ。同じポートで2度目を起動すると Address already in use で落ちる(ポート変更オプションは README に無い)
・neo4jev:uv run pytest で 161 passed・11 skipped
・typesafe-ai-playground:cargo build --release 成功。--help で6サブコマンド
・jev-review:npm install 成功。engines が node >=24 で、手元の Node 22 では実行せず
タグの有無も見ておくと、タグを切っているのは typesafe-mcp(v0.4.1)・jev-mcp(v0.4.0)・semdecide(v0.2.1)・agent-desktop(v0.9.2)の4本だけで、残り7本は main の最新コミットが「バージョン」である。記事や依存関係で固定したいなら、コミットハッシュで留めるしかない。
使いどころの判断——LLMに全部投げる構成と何が変わるか
11本を通して見えるのは、「LLM に判定させていた場所を Jev に置き換える」のではなく、「LLM を呼ぶかどうかを Jev に決めさせる」構成が多いことだ。Codex Router はモデルの階層を、Winnow は文脈に入れるブロックを、Jev Review は重いレビュアーに回す差分を、jev-ultrafast はテキスト生成を呼ぶ瞬間を、それぞれ Jev で絞っている。従来の構成との違いを表にする。
| 観点 | LLM の構造化出力に判定を投げる | Jev+コード(11本の共通パターン) |
|---|---|---|
| 返ってくるもの | JSON文字列(壊れれば再試行) | 型に閉じた選択肢と確率 |
| 不確実さの扱い | プロンプトで「自信度も出せ」と頼む | 確率が一次出力。閾値はコード側 |
| 1判断のコスト | モデル次第。出力トークンにも課金 | 公称 入力100万トークン0.042ドル・出力無料 |
| レイテンシ | 数百ms〜数秒 | 作者計測で178ms(jev-ultrafast)〜0.6秒(Codex Router) |
| 質問数と往復 | 質問を増やすと出力が伸びる | 質問を束ねても1往復(neo4jev・jev-ultrafast) |
| 向く仕事 | 要約・生成・説明 | 分類・ルーティング・スコア・可否・次の1手 |
| 向かない仕事 | 高頻度の小さな判定 | 文章を書く仕事すべて |
| いま試せるか | すぐ | ウェイトリスト、または OpenRouter 経由 |
LLM を評価器として組み込む構成そのものは、OctoBotのAI機能徹底解説|LLM(ChatGPT/Ollama)を“評価器”として組み込む仕組み【OSS】で扱ったように以前からある。Jev 系が違うのは、評価器の出力が最初から確率で、閾値をどこに置くかがコードの責任として明示される点だ。逆に言えば、閾値を決める根拠になるデータ(ラベル付きの過去ログ)が無いと、11本のどれも「初期値のまま」で運用することになる。Winnow と jev-mcp が閾値を「出発点」と呼び、Codex Router が校正の失敗を BACKTEST.md に残しているのは、そこが本当の作業だからだ。
採用判断としては、次の順で考えるのが現実的だと判断した。
・接続だけ先に済ませたい:typesafe-mcp(1ツール・Goバイナリ)か jev-mcp(用途別4ツール・npx)。Claude Code なら後者のほうが手数が少ない
・CI やスクリプトに入れたい:SemDecide。終了コードの契約があるので、Jev の応答が変わっても呼び出し側の分岐が壊れにくい
・Claude Code のトークンを減らしたい:Winnow。ただし Claude Code 2.1.121 以上、Jev が使えない間は Haiku 4.5 アダプタで動かす前提
・ブラウザ・デスクトップの操作:jev-ultrafast は MVP、jev-desktop は macOS 専用。動画の速さを自分の対象サイトで再現できるかは別問題で、shadow DOM や iframe を含むサイトはまず動かない
・参考実装として読む:neo4jev のビームサーチ、playground の再帰 Choice、Jev Review の段階的ルーティング。コードは短く、設計の型を学ぶには十分
Jev 自体がアーリーアクセスである以上、11本の全部が来月も同じ形で残っている保証はない。それでも、公開4日で「接続・CLI・コーディング・操作・探索」の5層が埋まったという事実は、判定専用モデルという分類が開発者側で受け入れられつつあることを示している。当サイトでは Jev の実応答を含む検証ができ次第、この記事の到達点の列を更新する。
参照ソース
・browser-use/jev-ultrafast(README・docs/performance.md、MIT)
・itsmostafa/typesafe-mcp(README・v0.4.0 リリースノート、MIT)
・jkudish/jev-mcp(README・CHANGELOG・src/index.ts、MIT)
・sharziki/semdecide(README「Exit codes」、MIT)
・0xNatoshi/jev-codex-router(README・BACKTEST.md、MIT)
・GhalebDweikat/winnow(README・hooks/hooks.json、MIT)
・devagrawal09/jev-review(README・package.json、MIT)
・ellipsis-dev/blink(README・package.json、ライセンス未記載)
・jexp/neo4jev(README、MIT)
・lahfir/agent-desktop(README・skills/jev-desktop/SKILL.md、Apache-2.0)
・markjaquith/typesafe-ai-playground(README、MIT)
・Introducing System One Models and Jev(TypeSafe AI 公式ブログ)