JEV プロジェクト

公開から一週間のうちに、Jev プロジェクトの生態系はゼロから数百件まで増えた。しかもかなり独特な形で増えた。Jev そのものを製品にした人はほとんどいない。みんなが作ったのは層だ。API を一つの言語向けに包む Jev プロジェクト、Jev の判断を MCP のツールとして露出する Jev プロジェクト、すでに存在していたエージェントのループに Jev の呼び出しを一つ落とし込む Jev プロジェクト。

単体では何もできないモデルなら、そうなるのが当たり前だ。Jev プロジェクトはほぼ常に、Jev と何か別のものとのあいだの配管になっている —— ブラウザエージェント、コーディングのハーネス、RAG のパイプライン、取引戦略、ゲームのループ。どの Jev プロジェクトについても面白い問いは「それが何か」ではなく、「他人のシステムのどこに判断を置くことにしたのか」だ。

JEV プロジェクトの偏りが語っていること

群を抜いて大きいのはインフラだ。SDK ラッパー、ゲートウェイのアダプタ、MCP サーバー、評価用の足場。これは「新しいシステムを組み直すのではなく、いまあるシステムで試したい」と思われているモデルの典型的な兆候になる。始めるならまずここを見るといい。自分のスタック向けのアダプタは、たぶんもう誰かが書いている。

二番目はエージェントの判断で、Jev がこれほど速く採用された理由をいちばんよく説明してくれるのがこの群だ。クリックのたびにフロンティアモデルを呼ぶブラウザエージェントは遅くて高い。一手ごとの判断を Jev に移し、文字を打つ必要があるときだけ大きいモデルを呼ぶ Jev プロジェクトは、その両方で一桁取れる。同じ置き換えは、コーディングエージェント、デスクトップ自動化、ロボティクスにも現れている。

次に検証とガードレール。較正が実際に元を取っているのはここだ。この群の Jev プロジェクトはたいてい門番になる。このツール呼び出しは破壊的か、この完了宣言は正直か、引いてきた段落は主張を支えているか、生成された答えは言っているとおりの出典を引いているか。どれもしきい値つきの Noul で、すでに動いているシステムに Jev を入れる方法としては最もリスクが低い。

そしてロングテール —— 金融、ゲーム、モデレーション、データのラベリング、コンプライアンス —— は件数こそ少ないが面白い。どの一件も、自分の領域が実は有界な判断だらけだったことに気づいた人の記録で、1 回あたりのコストが見合わなかったせいで、これまで誰も自動化していなかっただけなのだ。

出発点にする JEV プロジェクトを選ぶ

Jev を直接呼びたいなら、ラッパーを飛ばして公式 SDK から始める。Python は typesafe-sdk、JavaScript は @typesafe-ai/sdk。どちらも薄い。この索引にあるラッパー系の Jev プロジェクトの大半は、それらを改良するためではなく、特定のフレームワークに橋渡しするために存在している。

すでにエージェントを動かしているなら、MCP サーバーを探す。Choice・Score・Noul を、Claude Code や Codex のようなハーネスが直接呼べるツールとして露出する Jev プロジェクトが複数ある。つまり、危ない動作の手前に Jev の判断を挟むのに、連携コードを一行も書かなくていい。

決める前に形だけ見ておきたいなら、小さいものを一つ端から端まで読む。ガードレール系やコンテキスト剪定系の Jev プロジェクトは数百行で収まることが多い。面白い部分が配管ではなく質問の設計だからだ。良い Jev の質問がどんな見た目をしているのかを掴むには、これが最短になる。

そもそも Jev が合うかを評価している段階なら、個々の Jev プロジェクトより判断パターンのページのほうが出発点として向いている。繰り返し現れる 11 個の形について、state と質問とルーティング方針が、他人のコードベースの雑音なしに書き出してある。

この JEV プロジェクトのデータの出どころ

この索引にあるどの Jev プロジェクトも、コミュニティの awesome-jev 一覧から引いている。MIT ライセンスで、維持しているのはこちらではない。あちらのカテゴリファイルを解析し、URL で重複を除き、各件をコードか実践記録かに分け、説明から判断型が推定できるものには型を付け、そのうえで出典に直接リンクしている。

こちらの説明文は足していない。各 Jev プロジェクトの行にある 1 行は上流の維持者が書いたものだ。他人の要約を自分の言葉に書き直して自作のように見せるのは、不誠実であるうえに出来も悪くなる。