ソフトウェアの実作業を減らすJevの7つの活用例

ある人が当社のウェブサイトに、連携の数を尋ねました。サイトは登録フォームに必要な入力欄の数について助言しました。

回答はすぐ届きました。役には立ちませんでした。

どちらの質問にも「いくつ」という言葉がありました。検索コードは採用されたFAQの一致に最低0.86点を与え、弱い一致を確かなものに見せていました。速さが判断の誤りを隠していたのです。

Ship with Jevを見るときは、こうした失敗を考える価値があります。2026年9月26日時点で、ディレクトリにはコミュニティが作った551件が掲載されていました。ゲームの隣に検索コンポーネント、ブラウザーエージェント、調査ツール、振り分けの実験があります。性能値は各作者によるもので、独立したベンチマークではなく、作品を見つけるためのディレクトリです。

興味深いのは、この中のどのパターンが実際の製品の作業を減らすかです。

連携や業務ソフトウェアを作るチームなら、私はまず次の7つを評価します。順番は有用性と検証しやすさについての編集上の判断です。以下のワークフロー例は、リンク先の実装を明記した場合を除き、提案する設計です。

Jevがアプリケーションに加えるもの

TypeSafeはJevを型付き判断のモデルと説明しています。関連する状態と質問を渡すと、コードが利用できる選択、確率、スコアが返ります。同社の活用例マップには、振り分け、検索、検証、抽出が含まれます。

この区別には、取り込んだYouTube資料に役立つ先例があります。AI EngineerでのDiogo Almeidaの講演で、TypeSafeの共同創業者は、基礎部品そのものがより高度な知能を表現できるソフトウェアを提唱しています。既存のソフトウェアにアシスタントを後付けする方法と対比しています。これはAIの方向性についての本人の主張であり、Jevの現在の性能を示すベンチマークではありません。

線路の分岐点を考えてください。必要な出力は、列車が利用可能な線路のどれへ進むかです。線路を説明する文章は、転轍機に何も加えません。

「普通のLLMでもJSONを返せる」という反論はもっともです。その通りです。別の部品を採用する根拠は、その判断で測定した品質、費用、遅延にあります。型付きの応答だけでは、どれも証明できません。

まずCLMからの挑戦を検討する

9月23日、Jacky Kwok、Hangoo Kang、Tarun Suresh、Jon Saad-Falcon、Marco Pavone、Christopher Ré、Azalia MirhoseiniがContrastive Language Modelsを公開しました。この研究は、速い意味判断を実現する実用的な方法がJevだけだという想定に疑問を投げかけます。

著者らは、コンピューター操作、ゲーム、ツール呼び出しのタスクで、事前例を与えない条件の結果がJevと同程度であり、遅延は最大9倍小さいと報告しています。別の結果として、保留していたDeepSWEの38タスクで81.6%、Terminal-Bench 2.1の30タスクで87.6%を報告しています。これらのコーディング結果では、他モデルが生成した解決策から選ぶため、追加学習したCLM検証器を使用しています。また、この検証器の条件ではJevがランダム選択の基準を下回ったとも報告しています。遅延はH100で測定しました。これらは著者らの結果であり、当社は独自に再現していません。元の評価と方法をご覧ください。

この比較は、何を試すべきかを変えます。サポート窓口の選択、検索結果の一節の選択、長いコーディング過程の評価は別々のタスクです。一つで良い結果が出ても、ほかの結果は決まりません。

CLMは状態と候補行動を別々に符号化するため、再利用できる行動の埋め込みをキャッシュできます。リポジトリには、TypeSafe互換のインターフェースと、状態について既定の2,048トークン上限が記載されています。設定を変えなければ、長い状態は切り詰められます。APIの境界で互換でも、同じ判断になるとは限りません。

公開モデルカードにはQwen3-8Bの埋め込みが指定され、検証器の高い成績には追加学習したヘッドが必要と注意されています。CLMは与えられた候補を採点し、解決策自体は生成しないことも明記しています。重みの公開によって評価の選択肢は増えますが、ハードウェア、提供体制、保守には費用がかかります。

Tajoにとっての教訓は具体的です。同じ事例で判断モデルを比較し、初回と再実行時の遅延を別々に記録し、もっともらしい誤候補を試します。モデルとエンコーダーや射影ヘッドの版を固定します。対応しないプロバイダー設定は、別のプロバイダーを黙って選ぶ代わりに拒否します。モデルや候補集合が変わったら、確率の較正を再確認します。

以下の7つのワークフローは、引き続き評価に値します。その価値はJevがすべての比較で勝つことには依存しません。

1. 結果が質問に答えているか確かめる検索

失敗が目に見え、結果の正誤を付けやすいため、私はこれを最初に選びます。返された文章は、訪問者の質問に答えていたでしょうか。

キーワード検索、埋め込み、または両方で候補を少数取り出します。次に各文章が必要な事実を示すかJevに尋ねます。TypeSafeの再順位付けの手引きはこの二段階の構造を示します。同時に限界も示します。最初の検索で漏れた文書を、再順位付けで選ぶことはできません。

1. 検索

   キーワード、埋め込み

   少数の候補

   漏れた文書は追加できない
2. Jev

   型付きの判断

   この文章は

   事実を示しているか
3. 回答

   または回答なし

   正しい回答か未回答

   全体の遅延を測定

当社の連携数の例なら、もっと簡単な最短経路があります。正式なカタログの項目を数え、その数が何を表すか説明します。文書化されたコネクターと、顧客が設定した接続は異なります。

意味の解釈が必要な質問に意味判断を使います。たとえば「昨日から変更された顧客だけを移せますか」。関連する同期の文書を取得し、差分更新について答えているか確認します。

Kyle McLarenのjevsearch実装では、この順序が具体的に見られます。まずキーワードの結果が届き、その後Jevの順位が加わります。公開ベンチマークは、自身の文書群と正解を付けた質問を使っています。そのテストの証拠にはなりますが、別のサイトや言語での成果を保証しません。

正しい回答、根拠のない回答、答えられなかった質問、全体の遅延を測ります。誤字や翻訳した質問も入れます。無関係な結果は速くても無関係です。

2. 依頼を正しいページ、窓口、エージェントに振り分ける

利用者が「アカウントを変更したら連絡先が届かなくなった」と書いたとします。アプリケーションは、接続の不具合、請求、フィールドの対応付け、新しい同期の作成依頼を区別する必要があります。

現在の画面、直近の会話、その利用者が使える行き先を渡します。「該当なし」を明示的に含めて、最適な行き先を尋ねます。行き先の識別子はアプリケーション側で管理します。

意図、行き先、緊急度、実行可能な依頼を含むかどうかなど、複数の判断が同時に役立つ場合があります。TypeSafeのfan-outパターンでは、独立した質問が一つのリクエストを共有できます。その後、コードが必要な回答を使用します。

害のない画面移動の提案と、作業実行の許可は別の判断です。正しい請求ページを見つけても返金は許可されません。正しいエージェントを見つけても認証情報は付与されません。

実務上の利点は、引き継ぎや確認の往復が減ることです。利用者が最初の試みで正しい行き先に到達する割合を測ります。「はい」「新しい依頼」「それは終わりましたか」のような続きの発言を含む再実行用の事例集を保管します。こうした発言は文脈があって初めて意味を持ちます。

3. 乱れたデータを信頼できる連携に変える

次は提案する連携ワークフローです。ソースのエクスポートにcustomer_email、billing_email、account_owner_emailがあります。送信先は連絡先のメールアドレスを求めています。

文字列の似かよりだけでは本当の曖昧さが残ります。フィールドの説明、値の例、業務上の目的が解決を助けます。Jevが実在するソースフィールドから選び、コードが型、必須値、送信先の制約を検査できます。

関連する事前解析した値の抽出手引きには特に有用な設計があります。コードが候補値を探し、モデルが一つを選び、コードが元の値をコピーします。別のアドレスや金額を生成しないためです。

1. コード

   候補を探す

   customer_email

   billing_email

   account_owner_email
2. Jev

   一つを選ぶ

   フィールドの説明

   値の例、目的
3. コード

   元の値をコピー

   型、必須値

   送信先の制約

CRMとメールの連携では、ソースフィールドと対応付けの判断を一緒に残します。影響するレコードのプレビューを示し、不確かな対応付けはレビューまで未確定にします。

経済的な利点もあります。承認済みのスキーマ対応付けは再利用できます。フィールドの意味が同じなら、すべての行でモデルを呼ぶ必要はありません。

レビュー済みのサンプルに照らして、拒否されたレコードと誤った対応付けを測ります。APIリクエストの成功が証明するのは、送信データが受理されたことだけです。正しいメールが正しい連絡先に届いた証明にはなりません。

4. タスクを完了できる最小のモデルを選ぶ

アプリケーションがすべてを最も高価なモデルに送っているなら、モデルの振り分けには魅力があります。ラベルの変更、検索に関する判断、難しい設計調査では必要な能力が異なります。

まず、設定済みで、そのタスクのデータを受け取ってよいモデルを定めます。使えるツールと観測した性能を記録します。その集合から、範囲を限定した判断で適切な候補を勧められます。TypeSafeはモデル振り分けの例にこのパターンを含めています。

OpenRouterのJev Routerは、チャットAPIでモデルIDtypesafe/jev-routerとしてこのパターンを提供します。掲載情報によると、会話の変化に合わせてモデルと推論量の両方を選びます。採用前に、選ばれ得るモデル、実際の料金、データの扱い、ツール呼び出し中の動作を評価してください。掲載情報は確認しましたが、このルーターの性能は測っていません。

提案する方針では、厳密な規則と事実には通常のコードを最初に使います。範囲を絞った意味の質問には判断モデル、執筆や実装には適した生成モデルを使い、根拠が必要性を示したときに上位へ切り替えます。

タスクに必要なものは何か

1. 厳密な規則と事実

   通常のコード

2. 範囲を絞った意味の質問

   判断モデル

3. 執筆や実装

   適した生成モデル

4. 根拠がそれ以上を求める

   上位へ切り替える

ルーター自体にも時間と費用がかかります。明白で繰り返せるタスクなら固定規則の方がよい場合があります。曖昧なタスクでは、完了した成果について固定モデルを使う基準と比較します。

受け入れられた成果あたりの費用、再試行、上位への切り替え率、後から見つかった失敗を追跡します。最初の呼び出しが安くても、誰かが出力を直すなら高価なワークフローになります。

5. 顧客向けの回答になる前に主張を確かめる

引用が存在しても、その横の文を支えていないことがあります。資料が計画中の機能を説明しているのに、回答が「現在利用可能」と言う場合もあります。

TypeSafeの引用確認の手引きは二つの確認を分けています。通常の文字列照合で引用の欠落を見つけます。意味判断では、周囲の資料が主張を支えるかを評価します。

同じ設計をサポートの返信、生成した連携ガイド、エージェントが提案する完了報告にも適用します。主張、根拠となる文章、判定をレビューできるよう残します。

完了には直接的な証拠も必要です。テストはテストした動作を示します。デプロイ記録はデプロイを示します。意味判断は報告と証拠の食い違いを指摘できますが、欠けた証拠を作れません。

この用途は既存の公開手順の直前に置けるため有望です。すり抜けた根拠のない主張、不要に止められた根拠のある主張、増えたレビュー作業を測ります。システムがすでに犯している明白な誤りから始めます。

6. 文字起こしと顧客の声から役立つ候補を絞る

文字起こしの保管庫は、重要な一節を見つけられて初めて役立ちます。「連携という語を含む」は「顧客が設定をやめた理由を説明する」を探すには弱い条件です。

候補の文章を取得し、具体的な性質を少数判断する方法があります。設定上の障害を説明するか、具体例があるか、失われた文脈なしに単独で理解できるかを見ます。

選んだ各文章にソースURLと時刻を付けて保管します。時刻は文字起こしから取得します。モデルが判断するのは関連性です。

動画編集者なら、レビューするクリップの候補を絞れます。製品チームなら、繰り返し出る反対意見を整理できます。マーケターなら、顧客の証拠と根拠のないキャンペーンの主張を分けられます。

TypeSafeの複合採点パターンでは、採点の軸を分けて、コードが重みを変更できるようにします。チュートリアルに向くクリップと短い製品デモに向くクリップは違うかもしれません。根拠と基準が変わらない間は判断を再利用します。

関連するコミュニティ実装にJevQLがあります。PostgreSQLの行に対する意味条件を、データベース外で評価します。その文書は、通常のフィルターが費用に影響することを示しています。意味判断を依頼する前に対象行を減らします。

レビュー担当者の採用率と、使える素材を見つけるまでに節約できた時間を測ります。冒頭の強さのスコアは、視聴数の予測ではありません。

7. 次の有用な操作を選ぶ画面

設定画面に「この同期を明日まで止めて」と入力されるかもしれません。ブラウザーエージェントは、現在のページに見える操作から選ぶ必要があるかもしれません。

提案する画面設計では、アプリケーションが許可された操作と現在の状態を渡します。Jevはその中から選び、画面は対応する操作部品や確認可能な提案を示します。

Ship with JevにはGregor Zunicによるブラウザーでの航空便検索デモがあります。報告された実行時間と費用は、そのデモ固有の値です。持ち帰れる考え方は、各段階で利用可能な操作から選ぶことです。別のブラウザー作業には独自の検証が必要です。

状態が新しいことも重要です。判断中に選択中のアカウントやページが変わったら、古い結果を捨てます。操作をレビューしたアカウントと状態に結び付けます。

型付きのUIカタログも役立てられます。モデルが既知の画面と限定されたデータを選び、通常の描画コードが画面を作ります。タスクの成功と誤操作を測り、操作部品が理解しやすいままか特に確認します。

私ならどこから始めるか

すでに目に見える無駄を生んでいる反復的な判断を選びます。実際の失敗例から評価用の事例集を作ります。

現在の問題	最初の実験	集めるべき証拠
検索が違う質問に答える	取得した少数候補を判定する	正答、判断保留、遅延
依頼がチーム間を行き来する	許可された窓口から選ぶ	初回振り分けの正確さ、引き継ぎ
インポートで手作業の対応付けが必要	実在するソースフィールドを選ぶ	対応付けの誤り、レビュー時間
すべてのタスクが最大モデルを使う	対象タスクを振り分ける	受け入れられた成果あたりの費用
生成回答が言い過ぎる	資料に照らして主張を調べる	すり抜けた根拠のない主張
誰も文字起こし保管庫を使わない	時刻付きの文章を返す	レビューでの採用率、証拠を探す時間
利用者が操作部品を見つけられない	利用可能な操作を提案する	完了率、誤選択

デモの信頼度しきい値をそのまま使わないでください。TypeSafeの信頼度に関する文書によると、ChoiceとScoreの信頼度は分布の要約です。入力がすべて揃っていることや、選ばれた操作が許可されていることの証明にはなりません。

どの候補も合わない事例を入れます。利用できないサービスも入れます。対応予定の各言語を入れます。後の変更を公平に比べられるよう、モデルの版と質問の定義を結果と一緒に残します。

連携製品なら、私は検索の関連性とフィールドの対応付けから始めます。どちらも動作する同期までの道のりを短くします。どちらも誤りが顧客の問題になる前に調べられます。

現在のソフトウェアが出す誤答を一つ選んでください。次の正しい一歩を確実に選べるようにしましょう。