AI に手足を付ける：Jev が 120 ミリ秒でリアルタイムに Doom を遊ぶ仕組み

中国語ナレーション · 720p · 字幕トラック（中国語） · MP4

記事：AIは画面を見ずにDoomを遊ぶ――Jevが1秒に10回答える選択問題

TypeSafe のチームが公開したデモ動画では、AI が往年のシューティングゲーム Doom をリアルタイムで遊んでいます。敵を避け、アイテムを拾い、道を探す姿は「AI が画面を見てゲームをしている」ように見えます。ところが、この AI は画面を見ていません。ピクセルも一切読んでいません。受け取っているのは、プログラムが文章で書いた状態レポートだけです。

判断を担当しているのは Jev というモデルで、TypeSafe が 2026 年 9 月に発表しました。公式は Jev を「システム1モデル」と呼んでいます。人間の頭の中にある、考え込まずに働く速い直感のことです。使い方は ChatGPT のように文章を書く大規模言語モデルとは大きく違います。プログラムはまず状態の説明を渡し、続けていくつかの選択問題を出します。選択肢はあらかじめプログラムが用意したものです。Jev は文章を生成せず、それぞれの選択肢に確率、つまり「それが正解である見込み」を付けて返します。試験のマークシートのように、決められた枠の中でしか答えないので、選択肢の外のものは出力しません。一文字ずつ生成しないぶん、速くて安いのが特長です。

AI を業務システムや自動化に組み込む人にとって、このデモの見どころは「AI がゲームをできる」ことではありません。1 秒に何度も小さな判断をする仕組みを、どう分割して作るかの実例になっている点です。この記事では動画の流れに沿って、状態レポートに何が書かれているのか、Jev にどんな問題が出されるのか、どこまでをモデルに任せ、どこからを普通のコードが受け持つのか、そしてこのデモで言えないことは何かを見ていきます。

デモに出てくる数字

まず速度とコストです。ここでは、公式の紹介記事に書かれた数字と、デモ画面から読み取れる数字を分けて扱います。

公式の紹介記事によると、このシステムはゲーム中に 1 秒あたり約 10 回 Jev に問い合わせます。動かし続けた場合のコストは、公式の見積もりで 1 時間あたり約 7 ドルです。一方、デモ画面の上部には、1 回の判断にかかった時間が平均約 118 ミリ秒、つまりおよそ 120 ミリ秒と表示されています。同じプレイ中の呼び出し回数は 2700 回あまりで、画面下部の累計コストは 0.64 ドルでした。

ここまで速く安くできる大きな理由は、重い画像認識モデルを動かさないことです。画面を認識するには大量のピクセルを処理する必要がありますが、文章のレポートを読むほうがはるかに軽く済みます。この設計の出発点になっているレポートから見ていきます。

状態レポート：3D の戦場を文章にする

デモ録画の 30 秒から 44 秒あたりでは、画面に長い JSON のテキストが流れています。JSON はプログラム同士でデータをやり取りするときによく使われる構造化データの形式です。これが、プログラムが Jev に渡している状態レポートです。

レポートの冒頭には、モデル向けのルール説明があります。距離は Doom のマップ単位で測り、プレイヤーの体の幅は約 32 単位です。距離は 4 段階に分かれていて、密着（contact）が 64 以内、近距離（close）が 64〜256、中距離（medium）が 256〜768、遠距離（far）が 768 以上です。角度はプレイヤーの視線を基準に、正の数が左、負の数が右で、プラスマイナス 180 度が真後ろになります。ゲーム内の時間の最小単位は tick と呼ばれ、1 tick は 35 分の 1 秒です。ルールには、4 tick ごと、つまり約 0.1 秒ごとに判断し、判断と判断の間はキーを押したままにすると書かれています。武器にまで短い説明が付いていて、たとえばショットガンには「近距離では威力が大きく、離れると弾が散る」とあります。

ルールの後には、その瞬間のプレイヤーの状態が続きます。体力は 55 で、最大値は 100 なので、すでにダメージを受けています。アーマーは 39 で、上限は 200 です。手に持っているのはショットガンですが弾切れで、ほかに弾が 60 発残ったピストルを持っています。

その次が敵のリストで、敵 1 体につき 1 件の記録があります。imp F という小悪魔は距離 57 で密着の段階、角度はマイナス 92 度なので、プレイヤーの真右にいます。もう 1 体の imp G は距離 293 の中距離で、角度はプラス 49 度、つまり左斜め前です。状態は out of view で、近くにはいても今は見えていないことを示しています。床のアイテムにも距離と方向が記録されていて、たとえば弾薬クリップは 814 の遠距離にあります。

プログラムは立体の戦場を、モデルが読める文章の情報に翻訳しています。Jev はこの情報だけをもとに判断します。

段階的な選択問題：先に目標を決め、次に動き方を問う

体力 55 の同じ瞬間、デモ画面の右側には Jev が答えている 4 つの問題が並んでいます。問題文はどれも英語です。各回答の横には確信度が表示されていて、これは Jev が選んだ答えにどれだけ自信があるかを表します。

1 つ目は射撃の問題で、今トリガーを引くかどうかを問います。選択肢は撃つ（fire）と撃たない（hold fire）の 2 つだけです。Jev は撃たないを選び、確信度は 0.99 でした。撃つ確率が低いのは迷っているからではなく、今は撃つべきでないとほぼ確信しているということです。

2 つ目は目標の問題で、プレイヤー・敵・アイテムの状況から、今いちばん優先すべきことを問います。この瞬間の選択肢は 6 つで、武器の強化、偵察（scout）、敵を倒す、弾薬の補充、アーマーの補充、回復（restore health）です。Jev は回復を選び、確信度は 0.95 でした。

3 つ目は回避の問題です。問題文には前の問題の答えがそのまま書き込まれていて、「プレイヤーは今、救急キットで回復することを最優先している。この瞬間どうするか」という趣旨になっています。選択肢はそのまま続ける（carry on）、左へ避ける、右へ避ける、後ろへ下がるです。Jev はそのまま続けるを選びましたが、確信度は 0.54 にとどまり、この判断には迷いがありました。4 つ目は移動の問題で、ここでも回復という目標を含めたうえで、どう動くかを問います。

つまり問題は段階的に出されています。まず大きな目標を選び、その後の問題は目標を前提にして具体的な動きを問う形です。

選択肢そのものも固定ではありません。録画の 81 秒の時点ではプレイヤーは体力満タンで、目標の問題の選択肢は 5 つに減り、回復は出てきません。どの選択肢を出すかは、プログラムが状況に応じて決めているわけです。同じ瞬間、人間がコマンド欄に「撃つな、回避だけしろ」と入力していて、射撃の問題の答えは撃たない、確信度は 0.97 でした。画面にはさらに、マップに敵を送り込み続ける「ディレクター」のプログラムも表示されています。

司令官と手足：モデルにどの層を決めさせるか

デモ画面の下部には、同じ 81 秒の時点を描いたフローチャートがあります。左側には把握している敵、救急キット、弾薬、武器、アーマーが並びます。中央ではまず目標を選び、このとき Jev が選んだのは偵察でした。続いて、どの敵に向かうかといった具体的な対象を選びます。最後に 4 つの出力になり、向き（FACE）は 76 度、移動（MOVE）は目的地の座標、トリガー（TRIGGER）は撃たない、武器（WEAPON）は持ち替えなし、となっています。

私の理解では、角度や座標は状態レポートをもとにコードが計算し、Jev は選択肢から選ぶことだけを担当しています。この分担は司令官と手足にたとえられます。Jev は司令官として「今は回復しに行く」と決めます。コントローラーのコードは手足として、救急キットまで一歩ずつ歩いていく部分、つまり経路の計算、視点の回転、キー入力を受け持ちます。キーを約 0.1 秒押し続けたら、次の判断に移ります。

なぜこう分けるのでしょうか。モデルが何を決められるかは、プログラムがどんな選択肢を渡すかで決まるからです。選択肢が前後左右だけなら、Jev は前後左右しか選べません。回復や偵察といった目標を選択肢に入れて初めて、本当の判断をモデルに任せたことになります。ただし、目標は抽象的であるほどよいわけではありません。目標をモデルに任せるなら、コントローラーがその目標を確実に実行できる必要があります。モデルには判断を、従来のコードには実行を任せる。このデモのうまさはそこにあります。

全体の流れをまとめると 4 段階です。下のコードがゲーム内部のデータを読み、文章の状態レポートにまとめます。段階に沿って Jev に問題を出し、各選択肢の確率を受け取ります。コントローラーが選ばれた選択肢を、方向転換・前進・射撃・ドアを開けるといった実際のキー入力に変えます。次の判断までキーを押し続け、また最初に戻ります。

コミュニティ版：4 問のマークシートを 1 回で渡す

公式デモのコードは公開されていませんが、GitHub にはコミュニティによる再現版 jev-doom-agent があります。作成日は 2026 年 9 月 17 日です。本物の Doom エンジンを WebAssembly（ブラウザ上で動かせるプログラムの形式）にコンパイルし、エンジンから体力、アーマー、弾薬、座標、撃破数、見えている敵とアイテムを取り出しています。説明文にも、Jev が受け取るのはピクセルではなく構造化されたゲーム状態だと書かれています。

コミュニティ版は Jev に 1 回リクエストを送るたびに、4 問が載ったマークシートを渡します。1 問目は移動で、その場にとどまる、探索する、敵に近づく、後退するなど 6 つの選択肢があります。2 問目は視点で選択肢は 3 つ、3 問目はトリガー、4 問目はドアやスイッチの使用で、それぞれ選択肢は 2 つです。4 問の答えは同時に実行され、全体の確信度は 4 問のうち最も低い値を取ります。リクエストが失敗したり確信度が低すぎたりすると、画面に FALLBACK と明示され、その回は Jev の答えを使わず控えめな代替動作をとります。

公式版とコミュニティ版は細部が違いますが、手間がかかる場所は共通しています。状態をどう書くか、選択肢をどう設計するか、コントローラーが信頼できるかの 3 つです。モデルはその中の一部分にすぎません。

このデモで言えないこと

1 つ目に、デモで Jev に渡しているのはゲーム画面ではなく文章の状態です。文章を使う方法が速く安くできることは示していますが、画面を見る方法がうまくいかないことを示しているわけではありません。

2 つ目に、Jev が回復や偵察を選べるからといって、長期的な計画を立てる力があるとは言えません。選択肢は状況に応じてプログラムが渡したもので、経路はコントローラーが計算しています。探索済みのマップの範囲も周辺のコードが記録し、入力としてモデルに渡しています。

3 つ目に、公式のコードは公開されていないため、1 回のリクエストで何問を尋ねているのかは分かりません。コミュニティ版は 1 回で 4 問ですが、公式も同じとは限りません。

4 つ目に、1 秒 10 回、1 時間 7 ドル、平均 118 ミリ秒といった数字は、このデモに限ったものです。ゲームや状態の書き方が変われば、結果も変わる可能性があります。

まとめ

このデモの仕組みは、状態を文章にし、判断を選択問題にし、信頼できるコントローラーを手足として付ける、という型にまとめられます。モデルの速さも大事ですが、それ以上に重要なのは、どの層の判断をモデルに任せるかという設計です。どんな選択肢を渡すかでモデルが決められることが決まり、コントローラーの能力で、その判断が実際の動きになるかどうかが決まります。

この型はゲームに限らず、UI の自動操作やロボットの制御など、1 秒に何度も小さな判断をする場面で試せます。ただし、この記事の分析は公式デモの画面とコミュニティ版のコードにもとづくもので、公式実装の内部は分かっていません。別の用途に移すときは、速度、コスト、判断の精度を改めて測る必要があります。元のデモ投稿は X の公式デモで見られます。

シリーズ：Jev01 · Jev02 · Jev03。