jevで五目並べを実装：LLMの構造化エージェントが変える開発現場の未来

• jevモデル同士を五目並べで対戦させ、構造化されたエージェントの応答速度と精度を実測検証した。
• チャット型LLMとは異なり、Noul/Choice/Scoreといった制約付き出力により、決定的なワークフローを実現。
• 既存のLLMを置き換えるものではなく、高速な推論が必要な自動化パイプラインの補完技術として活用すべき。

我々エンジニアが日々LLMと向き合う中で、最も頭を悩ませるのは「非決定性」という壁です。プロンプトを工夫し、System Messageを磨き上げても、確率的に揺らぐ出力に一喜一憂し、結局は正規表現やバリデーションコードでガチガチに固めるという、本末転倒な実装を強いられることは珍しくありません。そんな中、Typesafe AIが提唱する「jev」というアプローチは、まさに我々が求めていた「構造化されたエージェント」の雛形と言えます。

jevの最大の特徴は、汎用的なチャットモデルとは異なり、出力を「Noul（YES/NO）」「Choice（選択肢）」「Score（点数）」という3つの型に限定している点です。これは単なる機能制限ではなく、LLMの推論プロセスを「決定的なパイプライン」へと昇華させるための強力な制約です。例えば、五目並べのようなルールベースのゲームにおいて、チャットAIに「次の一手を打て」と指示すれば、余計な解説やメタな会話が混入し、パースエラーの温床となります。しかし、jevであれば、現在の盤面状態（state）と取り得る選択肢（criteria）をJSONで渡すだけで、純粋な「手」の選択のみを高速に返却させることが可能です。

今回、mizchi氏が実装した五目並べの検証コードを見ると、その設計思想が極めてエンジニアフレンドリーであることが分かります。リクエストには盤面サイズ、ルール、現在の石の配置、そして「どのセルに打つべきか」という選択肢が明確に定義されています。これは、LLMを「対話相手」としてではなく、システムの一部を構成する「推論エンジン」として扱うという、極めて現代的なアーキテクチャへの転換を意味しています。我々が深夜の障害対応でデッドロックを解消する際に、曖昧な指示ではなく「このロックを解除せよ」という具体的なコマンドを求めるのと同様に、jevはAIに対して「曖昧さ」を排除した明確なインターフェースを提供しているのです。

実際にjev同士を対戦させたログを分析すると、その挙動には非常に興味深い傾向が見て取れます。対戦は合計25手で決着し、総所要時間は13,913ms。1手あたりの平均処理時間は約500ms前後で推移しています。Typesafe AIの公称スペックである50〜500msという数値に対し、この実測値はネットワーク遅延（アメリカ西海岸サーバーへの往復）を考慮すれば、極めて優秀なパフォーマンスと言えるでしょう。特に注目すべきは、終盤にかけて「confidence（自信度）」が上昇していく挙動です。これは、選択肢が絞られるにつれて推論の精度が安定し、モデルが自身の判断に対して確信を深めていることを示唆しています。

以下に、検証で得られた主要な推論ステップの抜粋を整理します。

このデータから読み取れるのは、jevが単に速いだけでなく、状況に応じて推論の質をコントロールできているという事実です。しかし、ここで冷静に考えるべきは「この技術をどこに適用するか」という点です。jevは汎用的なチャットボットを置き換えるものではありません。むしろ、自動運転や複雑なワークフローの意思決定など、専用モデルと汎用LLMの間に位置する「高速な推論レイヤー」として機能するはずです。現状のLLMが「スパゲッティコード」のような複雑な文脈を読み解くのが得意だとすれば、jevは「関数呼び出し」のように、特定の入力に対して特定の出力を保証する「クリーンなモジュール」として設計されています。

ただし、この技術的優位性は永続的なものではないと私は考えます。OpenAIやAnthropicといった巨大プレイヤーが、同様の構造化推論機能をAPIレベルで標準搭載するのは時間の問題でしょう。1〜2ヶ月もあれば、同様の最適化手法が市場に溢れるはずです。我々エンジニアが今すぐ取るべき対策は、jevそのものに依存することではなく、「LLMの出力をいかに構造化し、決定的なパイプラインに組み込むか」という設計パターンを習得することです。jevの登場は、AIを「魔法の箱」として扱う時代が終わり、AIを「信頼できるコンポーネント」としてシステムに統合する時代が到来したことを告げる狼煙なのです。