はじめに

これは Jev を触って調べる全4回の最終回です。第1回では文章ではなく型付きの判断を返すAPIを見ました。第2回では、型に収まることと意味として正しいことは別であり、taxonomyと質問の設計が重要だと確認しました。
第3回では、Jevを通常コードの途中へ置き、意味的な観測値とアプリケーションの判定ルールを分ける設計を見ました。ここで残る問いは、その分担を一回で終わらせず、操作によってstateが変わるたびに繰り返したら何が起きるかです。本稿は新しい性能評価ではありません。公開されたばかりのJevについて、公式資料と既存の実測を出発点に、考えられる設計を整理する最終回です。

DOOM demoは何を示しているか

TypeSafeの発表記事には、JevをDOOMのデモに使ったという説明があります。公式記事が述べる範囲では、担当エンジニアは毎秒10 queryを送る場合の費用を懸念していました。公式記事は、その費用が約7米ドル/時になると説明し、チームは想定より低いと受け止めた、と記しています。また、ゲーム画面の画像ではなくテキストを含む構造化された状態を入力したこと、AIを使わないDOOM botの方が上手にプレイできること、デモの狙いは異なる状態表現に反応し指示に従えることの確認だった、とされています。公式発表

これは、Jevが毎秒10回の閉ループ制御を実現したという証拠ではありません。記事は各queryが操作にどう接続され、いつ次の状態を読んだかまでは説明していません。したがって「10 QPSだから10 Hzの制御が可能」とは書けません。

それでも、この例が興味深いのは、判断対象を一度きりの文章ではなく、変化し続ける状態として置いている点です。抽象化すると、次のような流れになります。

状態(t)
  -> Jevによる小さな意味の観測
  -> 通常コードによる判定ルール
  -> 操作
  -> 変化した状態(t + 1)
  -> 次の意味の観測
  -> ...

第3回のIssue triage PoCも、1回だけ切り出せば同じ構造でした。問い合わせ文からissue typeやurgencyを観測し、Pythonの規則が振り分け先を決めます。上の流れでは、操作の結果や追加情報を次の状態として、同じ分離を何度も適用する設計が考えられます。

ゲーム以外にも、似た構造を試す公開実装があります。browser-use/jev-ultrafastは、画面から得た候補表で操作と対象を選び、executorが状態の新しさや対象の妥当性を再確認してから実行します。これは性能benchmarkではなく、観測、選択、検証、操作、次の観測という反復の構造を示す補助例として扱います。

「より速いLLM」とだけ見ると見落とすこと

低いlatencyやcostは、それ自体では機能ではありません。一回の大きな回答を少し早く返すだけなら、設計は従来のLLM利用とあまり変わりません。

変わり得るのは、状態の小さな変化ごとに「いま何が起きているか」という限定した意味判断を置く時間粒度です。TypeSafeによれば、記事執筆時点の公開価格はinput $0.042 / 1M tokens、output freeです。公式発表 同じ記事のDOOM demoは毎秒10 queries、約$7/hourと説明しています。これはTypeSafeの公式説明であり、今回の測定ではありません。

今回、16個の独立質問を一requestにまとめたp50は約230 ms、16回を逐次に送った合計p50は約3.65秒でした。これは今回の実行環境・質問での観測値です。TypeSafeの公開する速度比較は同社のbenchmarkであり、本調査は一般LLMとの同条件比較をしていません。公式価格・DOOM demoとこの観測値を並べると、一度呼んで終わりではない使い方を検討したくなります。ただし、それだけでフィードバックループの有効性を示すものではありません。

この考え方では、Jevは文章を返す相談相手というより、変化した状態を次のコードへ渡す小さな意味のセンサーとして置く見方ができます。ただし、アプリケーションが期待した扱いや安全性を保証するセンサーではありません。これは以下の設計案に共通する前提です。

繰り返す価値がある条件

高頻度に判断を呼ぶこと自体には価値がありません。たとえば、一度届いた問い合わせを担当部署へ振り分けるだけなら、数秒ごとに同じ本文を分類しても状態は変わりません。

繰り返す設計が意味を持ちそうなのは、少なくとも次の条件がそろうときです。

  • 操作によって対象または利用者の状態が変わる。
  • その変化が次の判断にとって意味を持つ。
  • 次の操作を決めるために、限定した意味の解釈がまた必要になる。
  • 判断ミスのときに、通常コード、確認、停止、人への引き継ぎで影響を抑えられる。

最後の条件は特に重要です。第2回で見たように、Choiceのtaxonomyがアプリケーションの必要な観測軸と一致しなければ、型として正しい答えでも必要な人手確認の条件を取り出せません。繰り返し呼ぶほど、その設計不足が繰り返し操作へ接続される可能性も増えます。

設計案を状態遷移として書く

以下は実装・性能・有効性を検証した提案ではありません。第1回から第3回までの「意味的な観測値と判定ルールの分離」という見方を、それぞれの状態遷移に当てはめた設計上の思考実験です。

ゲームのディレクターなら、プレイヤーの行動履歴をstateにし、「援助を求めているか」を観測する設計が考えられます。コードが難易度や台詞の許容範囲を確認してヒントを出し、その後の行動を次のstateにします。

AI agentの監視役なら、直近のplan、tool呼び出し、失敗履歴をstateにします。「次の操作は目的から逸脱しているか」を観測し、コードが許可済みtoolか、確認が必要かを判定する設計が考えられます。実行結果とログが次のstateになります。

運用監視なら、metric、alert、deploy履歴をstateにします。「利用者影響を示すか」を観測し、コードがpaging条件やrunbookを適用する設計が考えられます。対応結果と新しいmetricを次に読みます。

同じ構造は、適応的UI、対話シミュレーション、モデレーション支援、適応学習にも考えられます。いずれも有効性を検証した提案ではなく、stateの変化が次の限定判断に意味を持つ場合の設計案です。

ここで挙げた案では、Jevに最終的な操作を選ばせません。「助けを求めている」「確認が必要」「利用者影響がありそう」といった観測を返し、許可範囲、閾値、監査、不可逆な操作を止める規則は通常コードに持たせます。第3回のsecurity relevanceを追加したPoCは、この分離の小さな例です。issue typeからsecurityを推測せず、security weaknessを独立した観測対象に加え、Pythonの判定ルールが専門家による確認へ送るようにしました。

ループでは、観測設計の不足が増幅される

繰り返し設計では、質問の粒度とtaxonomyの境界を一度決めて終わりにはできないようです。新しい状態が現れるたびに、必要な情報が状態にあるか、既存のchoiceやcriteriaでその状態を表せるか、操作に必要な観測を取れているかを確認する必要がありそうです。

たとえば運用監視で「利用者影響あり」というNoulだけを置いても、security incident、部分障害、計画済みメンテナンスを区別しなければ異なる操作を同じqueueへ流すかもしれません。逆に選択肢を細かくしすぎると、criteriaの境界が曖昧になります。第2回の実験は、otherや高confidenceだけでcoverage不足を自動的に補えるとは確認できなかったことを示しました。

そのため、loopごとに少なくとも次を設計対象にします。

  • 状態に何を含め、何を含めないか。
  • 各質問が観測したい意味と、選択肢・criteriaの境界。
  • confidenceが低いときだけでなく、未知の状態や高リスク操作をどう止めるか。
  • 操作後にどの結果を保存し、taxonomyと判定ルールをどの証拠で見直すか。

境界付近の確率を閾値だけで即時に操作へつなぐと、いわゆるflappingも起こり得ます。たとえば0.52 → 0.48 → 0.53のような値に対し0.5だけで実行・解除を切り替えると、同じ操作が行ったり来たりします。これはJevで確認した現象ではなく、確率的な観測値をフィードバックループへ入れるときの設計上の注意です。状況に応じて、hysteresis、cooldown、debounce、idempotencyのような通常の仕組みも、アプリケーション側の判定ルールで検討が必要になりそうです。

これはJev固有の保証ではなく、型付き出力を操作へつなぐアプリケーション側の責任です。公式ドキュメントも、狭く明示した質問、独立質問の同時評価、confidenceを用いた人手確認や引き継ぎ、副作用をコードに残す設計を案内しています。How to build with System One

フィードバック制御との似ている点と、言い過ぎない線

状態、判断、操作、新しい状態という並びは、フィードバック制御を連想させます。この比喩は、時間と状態変化を設計の中心に置くためには役立ちます。

ただし、Jevを制御器だと呼ぶことや、安全重要なモーター制御にそのまま適用できることを意味しません。本稿には安定性、遅延の上限、誤差の分布、フェイルセーフを検証した結果がありません。ここで扱っているのは、ソフトウェア上の意味判断を状態遷移の途中へ置くための概念的な類似です。

最終回の結論

JevがLLMを置き換える、と結論づける材料はここまでにありません。一方で、非構造化inputを読み、限定した意味判断を型付きで返し、通常コードが判定ルールと操作を決めるという分担は、状態が変化するソフトウェアにも延長して考えられます。

TypeSafeは、Jevという名称を経済学者William Stanley Jevonsにちなむものと説明し、cost低下が利用量やuse caseの増加に結び付くというJevons paradoxにも触れています。公式発表 これは将来の利用量を予測する根拠ではありません。ただ、単発の大きな回答だけでなく、通常コードの途中で小さな意味判断を使う発想へ目を向ける背景としては読めます。

そのとき重要なのは、AIを何回呼ぶかではありません。操作が状態をどう変え、次にどの意味を観測し、どこで止めて人や規則へ渡すかを設計できることです。将来、意味判断を使うcostと時間がさらに下がるなら、「一回の賢い回答」だけでなく、「状態の変化に応じて小さな意味判断を使う」ことが、ソフトウェア設計の変数になるかもしれません。この可能性は、実運用の検証と安全設計を伴って初めて評価できます。

検証条件: 保存済みAPI応答の取得日は2026年9月17日JSTです。Python 3.13.14、typesafe-sdk 0.6.0、requested modelはjev-latest、returned modelはjev-1.13.0でした。Early Access中のため、後日のmodel aliasやAPIの挙動が同じであることは保証されません。

前回: Jevをアプリに組み込んでみる。AIの意味判断と業務ルールを分ける