どうも、マイクです。おはようございます。
九月二十四日、木曜日の朝七時を回りました。ここからは「zenncast」、Zennで今トレンドになっている記事を、ゆるっと楽しく紹介していきます。通勤・通学中の方も、おうちで支度中の方も、よければ最後までお付き合いください。

今日はお便り紹介はお休みで、そのぶんガッツリ記事を紹介していきます。
本日は、ぜんぶで五本の記事をご紹介します。エージェントやIDEの話から、フロントエンドフレームワーク、ポケモンスリープのハックまで、かなり振れ幅広めでいきますよ。

まず一つ目。
「Jev」というモデルを使って、LLMエージェントの“外側の制御ロジック”、いわゆるハーネスの精度を上げていこう、という話です。
Jevは、質問と現在の状態を入力すると、型付きの結果と、その結果ごとの確率を返してくれる、「超高速な判断API」として動くモデルなんですね。

用途はけっこう限定的なんですが、そのぶん、GPTみたいな大規模言語モデルと比べると、かなり安くて速く動きます。
イメージとしては、「ここでこのツールを実行するか」「このコードは危険か安全か」みたいな、if文で書きそうな条件分岐を、まるごとAPIとして外出しできる感じ。これを汎用の分類器として、いろんな場面で使えるよ、という提案です。

筆者は、このJevを、LLMエージェントのハーネスの中に組み込んでいます。
たとえば、コードを自動実行するかどうかを判断する「Auto Mode」で、いままでは確率的にふわっと判断していたところを、Jevに一回かませることで、より決定論に近づける試みをしています。
また、「仕様 grilling」と呼んでいるツール──仕様に対して質問を投げて抜け漏れを洗い出すようなツールですね──そこでもまずJevに一次評価をさせることで、「これは人間がちゃんと見るべきか」「これは自動で流していいか」を自動化して、人がチェックする回数や対話時間を短くしている、という具体例も出てきます。

こういう高速な分類器が安価に使えるようになると、たとえば「ツール実行結果をJevで要約して妥当か判定する」とか、「ざっくりした静的解析、いわゆるリンターの代わりに使う」といった、自動判断パターンをLLMの周辺にどんどん増やしていける。
その結果として、エージェントの設計自由度がかなり広がるんじゃないか、というのが筆者のまとめになっています。エージェントを本番運用している人ほど、こういう“判断の外出し”は刺さりそうですね。

。。。。

続いて二つ目。
こちらもエージェント寄りの話題で、「VS Code」と「Cursor」という二つのIDEを比べて、エージェントと人間が並列開発するとき、どっちのほうが“安心して放置できるか”という視点で語った記事です。

筆者いわく、最近は人間とエージェントが同時に作業する、いわゆる並列開発が増えているけれど、そのときに決定的に違うのが、「エージェントをどれだけ安心して放置できるか」だと。
まず VS Code 側から見ると、Copilot Chat を使っていると、開いているファイルが勝手にコンテキストに入ってきたり、行番号を指定したはずなのに、ちょっとズレた場所が編集されたり。
さらに、ターミナルでなにか操作したことをきっかけに、過去のチャットがいきなり再開してしまう、みたいな動きがあると指摘しています。

つまり、「会話」「コンテキスト」「実行環境」「イベント」「コードの変更」が、きれいに分離されていない状態なんですね。
そのせいで、人間のほうが一回手を止めて、「今エージェント何やってる？」「ここ触って大丈夫？」と、衝突を避けるための管理コストがかなりかかってしまうというわけです。

一方で Cursor のほうは、チャットごとに仕事の単位をきれいに分けやすくなっていて、選択範囲やファイル参照を、プロンプト文の中にインラインで埋め込めます。
これによって、「この選択範囲をこういう意味で扱ってね」とか、「このファイルを参照しながら、この部分を書き換えてね」といった境界線を明示しやすい。
その結果、人間がやっている作業と、エージェントに任せた作業を、同じIDEの中で並列に進めやすい構造になっていると評価しています。

筆者は、「もはや、どれだけコード補完が賢いか、だけではIDEを選ばなくなった」とまで言っています。
今は、「人間と複数のエージェントが、ぶつからずに同時進行できる設計になっているかどうか」で選ぶようになった、と。
その観点で見ると、自分の現状の開発スタイルでは、VS Code ではなく Cursor を選ぶ、という結論に至っている記事でした。
AI時代の“IDEの評価軸”がガラッと変わりつつある、というのが伝わってくる内容です。

。。。。

三つ目の記事は、フロントエンド界隈のホットトピック。
Next.js と TanStack Start を、設計思想からデプロイまで、十項目でじっくり比較した記事です。

まず Next.js は、React Server Components を軸にした「サーバー側主導のフレームワーク」です。
サーバー側レンダリングの考え方がベースにあって、内蔵キャッシュだったり、画像の最適化だったり、パフォーマンスに関する機能が最初からかなり厚めに用意されています。
「とりあえずNext入れとけばパフォーマンス周りは一通り揃うよね」という安心感があるスタックですね。

一方で TanStack Start は、TanStack Router と Vite を土台にした「クライアント主導の設計」になっています。
特徴的なのは、ルーティングやURLパラメータ、データ取得といった部分を、TypeScriptで一貫して型安全に扱えるところ。
「ルート定義からパラメータ、取得したデータの型まで、全部TypeScriptで通す」という世界観が強みになっています。

バンドラーの面でも違いがあります。
Next.js が独自の Turbopack を採用しているのに対して、TanStack Start は Vite を使っています。
そのため TanStack Start 側は、Vite のプラグイン資産を、そのまま活かしやすいというメリットがありますね。

データ取得やサーバー処理、API、キャッシュの扱いも、アプローチがかなり違います。
Next.js は、フレームワークの中にそれらを統合していて、ひとまとまりの体験として提供するスタイル。
対して TanStack Start は、Router や TanStack Query などの周辺ライブラリに役割を振って、組み合わせで構成していくアーキテクチャになっています。

記事の結論としては、「エコシステムの成熟度と、運用の安定感を重視するなら Next.js を選ぶのが無難」。
逆に、「型の一貫性を追求したい」「デプロイ先を自由に選びたい」といったニーズが強いなら、TanStack Start を選ぶとよい、と整理しています。
「どっちが強いか」ではなく、「なにを重視するプロジェクトなのか」で選び分けよう、という視点がわかりやすくまとまった比較でした。

。。。。

四つ目は、また「Jev」が登場しますが、今度は TypeSafe AI の Jev を、既存のLLMと比較しながら検証していく記事です。
テーマは、「確率付きの判断を高速に返す専用モデルって、本当にどのくらい効いてるの？」というところですね。

筆者はまず、「そもそもLLM側でも工夫すれば、かなり高速化できるよ」という話から入ります。
たとえば、「最初の一トークン分の logit だけを見る」とか、「共通のプロンプトをKV Cacheで共有する」とか、「JSONはモデルに作らせず、コード側で組み立てる」といった工夫をすると、自己回帰的に全文をダラダラ生成するより、かなり速くできると。
実際に小型モデルで試してみると、JSONをフルで生成させる場合と比べて、およそ七十七倍も高速化できた、という結果が出たそうです。

ゲーム操作の検証としては、マリオの自動プレイを題材にしています。
ここでは、Jev がもっとも良いスコアを出したものの、Llama や Gemma といったモデルもけっこう近いスコアに迫っていて、「Jevだけが圧倒的に強い」というほどの差ではなかったと。
さらに、そもそもAPIから logit を直接取れない最新モデルも多くて、そのあたりも比較検証の難しさになっていると指摘しています。

一方で、Jev の良さとしては、「確率そのものを返すインターフェースを、最初からAPIとして提供している」点を評価しています。
しかもレイテンシが百ミリ秒前後と、リアルタイム制御にも十分使える水準にあるので、実用的な価値はたしかにある、と。

ただし、開発元が推している「正しい確率、キャリブレーテッド・プロバビリティですよ」という主張については、慎重な立場です。
LLMには、選択肢の位置によるバイアスや、トークナイズの影響、やたらと自信を持ちすぎる傾向など、いろんなクセがあります。
Jev はそこを補正したからこそ「正しい確率」と言っているのですが、実際の検証記事を細かく見ると、「現実の確率と完全に一対一で対応している」とまでは言い切れない、というのが筆者の結論です。

なので、「この確率を完全に信じ切って、その前提でプロダクト設計をガチガチに組んでしまう」のは、まだちょっと危ないかもね、と。
うまく使えば強力なツールだけど、確率を“真理”として扱うのではなく、あくまで参考指標として、慎重に使っていこう、というスタンスで締めくくられています。

。。。。

そして最後、五つ目はガラッと雰囲気が変わって、「ポケモンスリープ」を徹底的にハックしてみた記事です。
テーマは、「毎日満点の睡眠スコアを取りたいけど、八時間半もちゃんと寝るのは無理だし、そもそも狙った睡眠タイプを人工的に作りたい！」という、ゲーマーの執念から始まったお話です。

筆者がまずやったのは、「Pokémon GO Plus +」、通称ゴプラを分解すること。
本体を開けて、ボタンにつながっている二つのポイントを特定し、その部分を外部から電気的にオンオフできるように改造します。
そこにマイコンをつないで、「この時間になったら計測開始ボタンを押す」「この時間で終了ボタンを押す」という操作を、自動でやってくれる装置を作り上げています。

さらに一歩進んで、振動モーターも組み合わせます。
一定の周期で揺れを与えることで、ポケモンスリープの中で出てくる「うとうと」「すやすや」「ぐっすり」の三つの割合を、狙ったとおりの比率に近づける、という発想です。
その結果、睡眠時間が八時間五十五分、スコア百点、しかも各状態の割合の誤差が一パーセント程度という、「人間ではちょっと再現できないんじゃない？」というレベルのグラフを作ることに成功しています。

とはいえ、まだ「睡眠タイプそのものを完全にコントロールできる」とまではいっていません。
今後は、「出したい睡眠タイプ」を選ぶだけで、自動的に最適な揺らし方を決めてくれる仕組みを目指しているそうです。
ゲーム側の仕様を逆手に取って、「睡眠計測ロジックをハックする遊び」として、これからも発展させていこうとしている、という締めになっていました。
技術力のベクトルの使いどころが最高に楽しいやつですね。

。。。。

というわけで、きょうの「zenncast」は、
一つ目に、Jev を使ってエージェントのハーネス側の判断を外出しして設計自由度を高める話。
二つ目に、VS Code と Cursor を、「エージェントをどれだけ安心して放置できるか」という視点で比較したIDE論。
三つ目に、Next.js と TanStack Start を十項目で比較して、「エコシステム重視ならNext、型と自由度重視ならTanStack」という選び方を整理した記事。
四つ目に、TypeSafe AI の Jev を、既存LLMと細かく検証して、「確率は便利だけど、まだ過信は禁物」とした評価。
そして五つ目に、ポケモンスリープの睡眠計測を、ゴプラ改造とマイコンと振動モーターで徹底的にハックした、遊び心満載の記事をお届けしました。

気になる記事があった方は、このあとショーノートから元の記事もぜひチェックしてみてください。技術的なディテールや具体的な実装の話は、そちらにたっぷり載っています。

「zenncast」では、番組の感想や「こういうテーマ取り上げてほしい」なんてリクエストも、いつでもお待ちしています。
それでは、きょうも良い一日をお過ごしください。お相手はマイクでした。
また次回お会いしましょう。