2026/09/20AIjev-game-multistage

JevをゲームAIで多段利用する設計

Jevは複数回呼べば自動的に「深く考える」モデルになるわけではない。多段利用で重要なのは、各段が前段とは異なる情報を追加できるか、そしてモデルの判断をコードがどう合成するかである。

まず「並列Question」と「多段request」を分ける

TypeSafe公式ドキュメントでは、同じstateへ複数Questionを投げる場合は1 requestへまとめることを推奨している。各Questionは独立に評価され、追加Questionによるlatency増加は小さい。

ゲームなら同じ局面に対して、

攻撃的に行くべきか
自玉/自機は危険か
相手の脅威は高いか
この手は将来性があるか
いま撤退すべきか

などを並列に問える。

これらを「順番に5 request」する必要はない。

一方、前段の結果を使わないと次のstateや候補が作れない場合だけ、2段目requestに意味がある。公式例でも、182 skillをまずrankし、上位3件の全文を取得してから再評価する方式や、Choiceの結果で次階層の候補を決めるhierarchical classificationが紹介されている。

ゲーム向けの代表的な多段パターン

1. Candidate narrowing → re-rank

最初に合法手全部をChoiceし、上位K手だけについて詳しい特徴を計算し、再度Choice/Scoreする。

候補が多いゲームや、詳細特徴の計算コストが高い場合に向く。

2. Parallel factor judgments → code composition

「攻撃力」「安全性」「将来性」などを別Questionにし、コード側で重み付けしてactionを決める。

これは公式が推奨するcomposite scoringに近い。重みをコードへ置けば、プロンプトを変えずに戦略を変更できる。

3. Jev policy → deterministic search

Jevの上位候補をalpha-beta/MCTS/DFSへ渡し、探索自体は通常アルゴリズムに任せる。

Jevが得意そうな「候補順位づけ」と、コードが得意な「正確な展開」を分離できる。

4. deterministic rollout → Jev leaf evaluation

数手先までゲームエンジンで正確に展開し、葉局面の「良さ」だけをJev Scoreへ聞く。

ただし対戦相手の行動をどう展開するかは別問題である。

将棋で多段化が成功しなかった理由

公開将棋実験では、上位6手へ絞った後にJev自身で相手の応手を予測し、さらに局面評価する方式が試された。しかし中以上のFairy-Stockfishには勝てず、予測した相手の応手と実際の手の一致は68手中10手、別方式で70手中12手だった。

つまり

自分の候補 → Jevが相手手を予測 → Jevがその先を評価

と連ねても、前段の相手予測が外れれば後段は存在しない未来を評価してしまう。

多段化は「reasoning tokenの代替」ではない。

ポーカーでは分解が一部改善した

150スポットのTexasSolver比較では、

1 question: 全体63%、contested 38%
6 judgments + code: 全体57%、contested 44%
regret per action: 全体57%、contested 36%
6 binary facts + code: 全体59%、contested 33%

だった。

難しい55スポットでは6 judgments + codeが38%→44%へ改善したが、全体では低下している。さらに「checkできるならcheck」という無モデルruleが全体72%になるほどデータがcheckに偏っていた。

これは、分解すれば必ず改善するわけではないことを示す。分解したQuestionが正しい因子を測り、コードの合成式も妥当でなければならない。

ゲームで推奨しやすい境界

多段Jevを使う前に、各段を次のどれかへ分類するとよい。

deterministic: ルール、合法性、算術、役判定、距離、衝突
model judgment: 状況の意味、危険性、自然な方針、相手意図の曖昧な推定
search: 将来stateの列挙、minimax、MCTS、backtracking
composition: 複数判断をどう重み付けするか

Jevは主に2番へ置き、1・3・4をコードで保持する方が挙動を検証しやすい。