■ 1. 実験結果
- 一晩の実測:
- Jev を一晩叩いた感想をまとめる
- 実験ログは jev-playground リポジトリに置いてある
- 公式クックブックの追試:
- skill_suggestion の条件を変えて追試した
- チェス対戦:
- 5戦やって Claude 5 Sonnet には全勝
- MOBA ゲームのリアルタイム操作:
- LoL をミニマルにしたようなゲームを操作させた
- スプリットプッシュのマクロ戦術やタワーダイブのようなミクロ戦術が観察された
- 集団戦で誰がタンクするかの判断で協調できないことがあった
- eslint のエミュレーション:
- 実装抜きにルール名とコードだけで Lint 結果を答えさせ、正答率 86%
- 自然言語による確率的な Lint ルールは比較的現実的
- Playwright によるブラウザ自動操作:
- フォーム作成、商品をカートに入れる、購入する、という一連の画面操作をやらせた
- 判断自体は高速だが、単独ではエラーから復旧できないことが観測された
- Claude にログを監視させ補助させることで 96% 以上の精度になった
■ 2. わかったこと
- 本当に安い:
- MOBA 風のゲームを 1 戦やらせて $0.0001、出力は無料
- モデル性能自体は突出していない:
- 1 リクエスト/レスポンスは 500ms 程度
- 真価は並列度にあり、256 個の質問を同時に投げて同時にスコアが得られる
- confidence 値が便利:
- 0.96 以上のときはほぼ確信している
- 0.4 以下は間違っている可能性が高い
- 0.4 以下では別のモデルにフォールバックするとよい
■ 3. Jev の前提: Tool Call
- Tool Call 以前の手法:
- 与えられた jsonschema を満たす json を markdown の json コードブロックで出力させる指示を与えていた
- Tool Call と MCP:
- 上記を一般化したものが LLM によるツール呼び出しである Tool Call や MCP
- これにより AI は外界と接続でき、IDE と接続したのが Cline や Claude Code のようなコーディングエージェント
- Tool Call は事後トレーニングで得られる能力:
- 世界知識ではなく Tool Call 専用の事後トレーニングによる
- jsonschema の解釈能力が必要
- それを満たす範囲で自分がやりたいことを json の構造で表現する能力が必要
- 呼び出し結果が自分の意図に沿ったものかを確認する能力が必要
■ 4. Jev が達成したこと
- 自然言語の生成を介さない構造出力:
- 自然言語の延長で JSON を出力するのではなく、最初から JSON のような構造を出力するように作る
- アーキテクチャ:
- モデルの詳細は明かされていない
- 文章を解釈する能力は既存の LLM と同じものを使っている
- 出力部分であるデコーディング層を構造化データにしている
- そのニュアンスで TypeSafe AI を名乗っているのだろう
■ 5. 「250倍以上高速」の正体
- 実体は同時 Choice 数:
- おそらく Choice を 256 まで同時に投げられることを意味している
- この用途なら逐次処理のリクエストに比べて 250 倍速いのは嘘ではない
- 有利な面で勝負しすぎな印象がある
- 選択肢を絞る設計が重要:
- 256 の選択肢は多く見えるが、19x19 = 361 の囲碁の盤面は枝刈りしないと投げられない
■ 6. 「400倍以上安い」
- ある程度本当:
- 深い推論に向かず既存と同じユースケースに乗らないという前提はつく
- 特に出力が無料なのが嬉しい
■ 7. 「ハルシネーションが起きない」
- 選択肢外は選ばれない:
- 事前に用意したものにスコアを付ける形式なので、用意していない選択肢が選ばれることはない
- 誤った選択肢への高スコアはあり得る:
- 人間が用意した間違った選択肢に高いスコアをつけることはある
- Playwright の実験では押せないボタンを押し続けた
- ハーネスの Claude がそれに気づき、選択肢自体を削除することで処理を続行できた
- チェスでの比較:
- 合法手のみを渡したのでそれに制約された
- Sonnet は一局あたり 2 回ほどルール違反の手を選ぼうとした
■ 8. 速度と地理的な限界
- 実測レイテンシ:
- 1 リクエストあたり 500〜600ms、一番遅いときは 1200ms 程度
- 到達できる判断頻度:
- 500ms と仮定すればおよそ 2fps の判断ができる
- 60FPS のアクションゲームには足りないが、RPG やシミュレーションなら現実的
- Embedding でない限り自動運転は厳しい
- リージョンによる差:
- Claude Code Web から試すとおよそ 350ms で返る
- これはアメリカ西海岸同士で通信しているためと思われる
- 日本からの通信では 120ms ほどの遅延が乗る
- 日本リージョンができるまで解決できない遅延
■ 9. ゲームチェンジャーとしての位置づけ
- 既存 LLM の置き換えではなく補助:
- 今ある LLM を置き換えるものではない
- ガードレール用途:
- 危険なコマンドを止める用途がわかりやすい適用例
- シェル実行前の YES/NO 判断を安価かつ高速にできる
- 偽陽性の許される Bloomfilter のように扱うのがコスパがよい
- 大量の skill からの選択:
- デモでは Hermes Agent が 186 個のツールを持つ
- どれを使うとよいかをバッチ一つでスコアリングし、高いものを選べる
- 深い解釈は苦手:
- そもそもそのように作られていない
- 事前条件の State に自身の実行ログを追加することで擬似的な Reasoning はできなくはなかった
- 現時点では最適化されておらず、それによって判断が変わることはあまりなかった
- オーダーが変わることによる質的変化:
- ストレージが安価になり回線品質が良くなって YouTube が普及したのと同じ構図
- Web API で許容される 500ms のバジェットで同時に 256 個の判断ができるようになった
■ 10. Jev で何ができるようになるか
- 現時点では未知:
- 既存の発想で考えていると足をすくわれる
- 前提とすべき条件:
- 500ms の 1 リクエストで 256 個の LLM の回答を得られる
- LLM をチャットアシスタントではなくリアルタイムな計算機として使える
- 新しい発想が必要:
- こういうものは今まで存在せず、新しい発想が要る
- 500ms の遅延は違和感はありつつも人間とのリアルタイム対話に使えるレベル
- 画像入力は未対応:
- 公式ロードマップにはあるがまだ画像入力はできない
- 動画ストリーミングをリアルタイム処理できるようになれば世界が一つ変わる
■ 11. Jev で何が変わるか
- プログラマにとって意味が大きい:
- プログラマ、またはプログラマのようにワークフローを考えられる人に大きな意味がある
- 今までの LLM プログラミングは自然言語で投げた回答を自然言語として無理矢理運用していた
- Jev は最初から構造化して考える必要があり、プログラミングとの親和性が高い
- 設計の重みが増す要素:
- 事前条件の設計
- 出力構造の設計
- その並列化の設計が新たに加わる
- 500ms で 256 並列できるという条件について深く考える必要がある
- CPU と GPU の比喩:
- 今までの LLM が CPU だとすれば、Jev は精度が落ちるが遥かに高速な GPU のようなもの
- 追随の予測:
- 仕組みが簡単なので大手プレーヤーはすぐに模倣してくる
- TypeSafe AI の最適化の程度は現時点で予測できない
- OpenAI/Anthropic でも 2 か月後には似たものがローンチされていると思われる
- Embedding モデルへの適用は不明:
- アーキテクチャ的には Embedding Model に向いている
- 自動運転では自然言語を介さずもっと決め打ちで最適化されたものを使う
- LLM の学習された重みを使うため、デコーディング層が小さくなってもどれぐらい小型化できるかは予想できない
- ここからの調査を待ちたい