判断と語りを分ける、Jev的なゲーム開発
AIを仕事や個人開発に組み込みたい方に向けて、判定専用のAI「Jev」の考え方を借りたゲーム開発の記録を書きます。作っているのは国づくりのシミュレーションゲームで、Jevそのものは使わず、考え方だけを手元のモデルとコードで再現しました。
この記事は、新しく始めた「ゲーム開発日記」の1本目です。Jevとは何かを整理したうえで、その考え方をゲームのどこに使い、どんな数字になったかを書きます。
この開発で試したいこと
このゲーム開発は、次の3つを試すために企画しました。
- 複数のAIを使って開発すること
- Jevという新しい技術の考え方を取り込み、使い方を試すこと
- コンセプトを考えながら、形のある物を作っていくこと
ゲーム自体を楽しみたい気持ちもあります。ただ、それはあくまで副次的な目的です。
何を作っているか
作っているのは「クロニクル・オブ・エンパイア」という、ブラウザで遊ぶ国づくりのゲームです。プレイヤーは王国の主として命令を打ち込み、世界は毎ターン応えます。国の数値が変わり、家臣が返事をします。
コンセプトは「自分の理想郷を作れるゲーム」で、思いついたものを次のように取り入れています。
- 命令は自由な文章で打ち込む：コマンドを一覧から選ぶのではなく、プレイヤーが思ったとおりに書きます。どのコマンドに当たるかは、ゲームの側で判定します
- 30秒以内に、返事と絵で応える：命令を入れてから30秒以内に、家臣の返事とその場面の絵を出し、臨場感を高めます
- 自由度の高い作り：キャラクターメイキングなど、プレイヤーが自分で決められる所を多くします
- 軍事だけでなく、社会も動く：民からの支持率や施策に応じて人口が増減するなど、社会の動きも入れます
命令を自由な文章で打ち込む形は、発想としては昔からあります。1977年の『Zork』などのテキストアドベンチャーは、打ち込んだ英文を解析して動いていました。ただ、決まった言い方を当てないと通じないことが多く、やがて選択肢をクリックする形に置き換わっていきました（Wikipedia）。国づくりのような戦略ゲームに絞ると、自由な文章をAIが分類して数値はコードで計算する作りは、私が調べた範囲では2024年以降の研究や個人の試作が中心でした。遊べる形で公開されたゲームは、ほとんど見つかりませんでした。どのコマンドに当たるかをAIで判定すれば、この「言い方を当てる」問題も避けられます。
作り手は3人です。私が企画と遊んでの確認、Claude Codeが要件と基本設計、HERMES（このMacで動いている別のAIエージェント）が詳細設計と実装とテストを担当しています。外部の有料サービスは1つも使わず、費用は0円と決めています。
Jevとは
Jevは、米国のTypeSafe AIが2026年9月15日（現地時間）に発表したAIモデルです（ITmedia AI＋）。最大の特徴は、文章を一切書かないことです。
ChatGPTのようなAI（LLM）は、質問に文章で答えます。これに対してJevは、「はい／いいえ」「選択肢のどれか」「数値」という決まった形でしか答えません。選択肢や数値で答えるときは、答えと一緒に「どのくらい確信があるか」も数値で返します（はい／いいえの問いには「はいである確率」が返ります）。
発表によると、応答は1回70〜500ミリ秒で、LLMより193.6倍速く、444.6倍安いとされています（PC Watch）。ただし、この倍率は開発元が自社で設計した評価によるもので、私は確かめていません。
では、どんなことに使えるのでしょうか。プログラミングをしていると、「振り分け」が必要になる場面があります。たとえば、問い合わせのメールをどの部署で対応すべきか、緊急性が高いか低いか、どの製品が合っているか。決められた範囲から1つを選ぶ処理は、かなり頻繁に出てきます。
ただ、if文や正規表現のように条件を書いて分ける作り方では、選ぶ条件を厳密に決めないと作り込めません。私はここがネックだと感じていて、曖昧な入力でもAIが判断を補い、すぐに選んでくれる所がJevの画期的な所だと思っていました。
ところが調べてみると、曖昧な文章を振り分けること自体は、Jev以前からできました。学習させた分類器や、汎用のLLMを使う方法です。ただ、分類器は用途ごとに学習用のデータを集める必要があります。汎用のLLMは、判断1回に1〜2秒かかることが多いとされ（Zenn）、クラウドで使えば呼ぶたびに費用もかかります。
そこで今は、Jevの新しさは組み合わせにあると考えています。その場で渡した選択肢から1つを選び、確信度と一緒に、素早く安く、決まった形で返してくれる所です。
ただ、このゲームで私が借りたいのは、速さそのものよりも考え方のほうです。振り分けのように選ぶだけで済む所では、文章を書かせません。Jevは、この考え方を形にしたモデルだと受け取りました。
本体は使わず、考え方だけを借りる
Jevはクラウドの有料サービスです。このゲームは費用0円と決めているので、本体は使いません。代わりに、Jevの発表や解説記事から読み取った考え方に、これまでの開発で得た教訓を足して、次の7つにまとめました。これを、ゲームに合うものから手元のモデルとコードで試しています。
- 判断と生成を分ける：「どれを選ぶか」と「どう語るか」を別の処理にする
- 答えの形を縛る：選択肢は決まった値の一覧で渡し、一覧に無い答えを構造上返せなくする
- 決定論を増やす：同じ入力に同じ結果を返す部分を増やす。数値の計算はコードで行う
- 確信度で分岐する：自信があれば進め、迷っていれば人や上位の処理に回す
- 数値はLLMに書かせない：数値はコードが決め、画面にもコードで出す
- 制約は文書ではなくコードで強制する：守れないと困る決まりは、検査のコードで止める
- 速くなった分を精度に使う：判断が速くなったら、その時間で確認の段を1つ足す
ゲームでの使い方と、出た数字
プレイヤーが打ち込んだ命令が、1ターンの中でどう流れるかを図にしました。
命令は、まずゲームのコマンドのどれに当たるかを分類します。次に、コードが数値を計算します。最後に、AIが家臣の返事を書きます。
分類には、手元で動く小さなモデル（gemma-4-E4B）を使い、コマンドのIDの一覧から1つを選ばせました。一覧に無いIDは、答えの形の決まり（JSON Schemaの選択肢）で返せないようにしています。124件の試験で、正解率は94.4%でした。速さは、95%の問い合わせが0.49秒以内に返る水準です。文章の意味の近さだけで選ぶ方法では79〜82%だったので、「選ばせる」ほうが明らかに良い結果でした。
なお、試験に使った124件の文は、Claude Codeが書いたものです。作った側の癖が入っている可能性があるので、私が自分で書いた12文でも確かめました。辞書にある行動の9文は、最初の測定で9件中8件、実装後の測り直しで9件中7件が正しく分類されました。残りの3文は、そもそも辞書に無い行動でした。
迷ったときは、人に選ばせる
7つの考え方のうち「確信度で分岐する」は、プレイヤーに選んでもらう形で使っています。小さなモデルの確信度が低いとき（今は暫定で0.75未満）は、候補を出して私に選ばせます。図の左側に戻る矢印が、この流れです。確信度は、コマンドを選んだ答えにだけ付く値です。命令文から取り出した数字は、この判断を通らずに計算へ渡ります。
速い方法との二段構えは、あえて採らなかった
一方で、速くするための使い方は採りませんでした。文章の意味の近さで選ぶ方法は、正解率こそ79%でしたが、1件あたり約9ミリ秒と非常に速い方法です。しかも、1位と2位の候補の差が大きい、つまり「自信がある」と判断できた40件では、誤りが0件でした。この試験の範囲では、自信があるときの答えは信用できました。
そこで、自信があるものは速い方法で即答し、迷ったものだけ小さなモデルに回す二段構えも作りました。全体の約3割を10ミリ秒足らずで返せます。ただ、正解率は94.4%のまま変わらず、速く返せた3割でも縮むのは1回あたり0.4秒ほどでした。全体の中央値は0.414秒と0.412秒で、ほとんど変わりません。1ターンの目標は30秒以内です。試作で返事と絵まで通して測ると約4秒で、HERMESが作業している間でも約6秒でした（今の画面には、まだ絵を出していません）。0.4秒の差のために仕組みを複雑にする価値はないと判断し、目標を満たす方式のうち一番単純なものを採りました。
速くする工夫は、速さが問題になってからで十分です。Jevの考え方を借りるといっても、全部を入れる必要はないと感じました。
数字はコードで取り、モデルには渡さない
命令に含まれる数字（「税を30%に」など）や対象の国は、正規表現（文字の並び方の型で、文章から決まった部分を抜き出す書き方）で取り出しました。8件中8件を正しく取れたので、ここはAIに頼る必要がありませんでした。
コマンドを選ばせるときに、数字も一緒にモデルに返させる作り方もあります。実際に試すと、モデルも8件中8件を正しく取れました。それでもコードで取ることにした理由は3つあります。
- 同じ結果なら、毎回同じ答えを返すコードのほうが確実です
- モデルに返させる項目を増やすほど、遅くなります。答えの項目を1つから4つに増やすと、95%の問い合わせが返るまでの時間が約2倍になりました（40件の測定。正解率は変わりませんでした）
- モデルに数字を触らせると、書き写すときに変わるおそれがあります。実際に、次のようなつまずきがありました
同じ小さなモデルに返事の文章を書かせたところ、「0.4%」を「四分の一パーセント」と書いてしまったのです。大きなモデル（31B）なら正しく書けましたが、HERMESが作業している間は1ターンに38秒かかり、目標の30秒を超えます。そこで、モデルを大きくするのではなく、返事を書くモデルに数値を渡さない設計に変えました。
返事を書くAIに渡すのは、コマンドの説明と「農業が増えた」のような向きだけです。冒頭の画面の「農業 +2」はコードが決めて出した数値で、AIが書いているのは家臣の口調だけです。
分かったこと
作ってみて、Jevの考え方は「AIをどこで使わないか」を決める考え方だと感じました。分類は選ばせ、数字はコードで取り、計算もコードで行います。AIに自由に書かせるのは、最後の語りの部分だけです。
つまり、AIに任せる範囲を狭めた所ほど、数字の読み違いのような誤りが起きなくなりました。小さなモデルの弱点も、任せる範囲の外に置けば問題になりません。
もちろん、これは1つのゲームでの結果です。人それぞれの作り方があるので、1つの参考として見ていただければと思います。
次回予告
次回は、地図を作る話です。150マスの六角形の地図に、森や湖、山脈や川を置く道具（マップエディタ）を作りました。地図の絵を先に描いてしまって失敗した経緯と、「形を先に作り、見た目は後から作る」に切り替えた話を書く予定です。
