AIの「脳」を試験管で培養する──AIKernel.Doomが実現した決定論的テストと制御ランタイム
DOOMのオートプレイにおいて、AIの意思決定バグをいかにしてミリ秒単位で修正し続けたのか。その秘密は「ゲーム実機」を使わず、AIの思考パイプラインだけをNode.jsのVM上で決定論的に再生する Lightweight Control VM にありました。AIの学習ではなく、AIの「統治（ガバナンス）」をコードで書き、テストで保証する新しい開発パラダイムを解説します。
カテゴリ: AI Infrastructure, Local AI, WASM, Governance, Developer Experience
前回の記事（Day 6）では、AIKernel.Doom が「入口の前で迷い続ける」という問題をいかにして解決したかを書きました。
問題は視覚認識（Perception）ではなく、弱い証拠をどう裁定するかという統治（Governance）の層にありました。そこで、Dead-End Trim や Weak Gap Pivot といった意思決定のルールを導入し、AI を正しい通路へと収束させました。
しかし、技術的に鋭い方なら、一つの疑問を持ったはずです。
「DOOM のような複雑な3D環境で、どうやってそんな微妙な境界条件のバグを、一度も退行（Regression）させずに次々と修正できたのか？」
通常のゲームAIや強化学習エージェントの開発において、「特定の壁際で迷うバグ」を修正するのは至難の業です。 修正コードを入れる。ゲームエンジンを起動する。モデルをロードする。該当の場所まで移動させる。そして、同じ状況が再現されるのを祈りながら眺める。 これは途方もなく時間がかかり、かつ再現性の低い（Flakyな）作業です。
しかし、私は一連の「入口問題」の修正において、実機（ブラウザ）の画面をほとんど見ていませんでした。 修正と検証のサイクルは、数ミリ秒で終わっていました。
なぜそれが可能だったのか。 今回は、AIKernel.Doom の裏側で密かに稼働している最強の武器、「Control Runtime VM」 について解説します。
1. 誤解されがちな「VM」の正体
まず結論から言います。 開発ログの中で私が「VMテストを回す」と呼んでいたものは、AIKernel.Wasm が提供する WebAssembly の汎用ランタイムのことではありません。
DOOM の C言語コード（doom.wasm）をヘッドレスで動かしているわけでもありません。
ここで言う VM とは、Doom AI の意思決定プロファイルを、ブラウザ外（Node.js環境）で決定論的（Deterministic）に再生・検証するための軽量な制御仮想マシン（Lightweight Control VM） のことです。
全体像のアーキテクチャは以下のようになっています。
[ Doom framebuffer / audio / HUD ]
↓
[ Aisthesis / Phainesis / Noesis ] (知覚と意味づけ)
↓
[ Doom control context ] (正規化されたセンサー値)
↓
[ autoplay-profile.json ] (宣言的な統治ルール)
↓
[ Expression DSL VM ] (条件の評価)
↓
[ Stage arbitration ] (優先度に基づく調停: Krisis)
↓
[ Action packet / Kinesis ] (運動の生成)
↓
[ doom input ]VMテストが実行しているのは、このパイプラインの後半部分（Context から Action まで）のみです。 ゲームエンジン（世界）を完全に切り離し、AIの「思考回路（脳）」だけを取り出して試験管の中で動かしている状態です。
2. 宣言的な DSL によるガバナンスの記述
実ブラウザ側（DoomWeb）には、AI の行動を統治するための autoplay-profile.json というプロファイルが存在します。 ここには、ニューラルネットワークの重みではなく、人間が読める「宣言的なルール（Stage）」が並んでいます。
例えば、以下のような形です。
JSON
{
"id": "demo-spawn-map-centerline",
"when": "doorOpenedCount <= 0 && predictions < 420",
"action": {
"moveForward": "true",
"turnYaw": "0"
}
}この when の条件式を評価し、優先度（Priority）順に Stage を選び、最終的な move / turn / use / fire の仮想入力を生成するのが、Doom 側の Control Runtime（control-runtime.js 等）の役割です。
これは「AI にどう動くかを学習させる」アプローチではありません。 「AI が認識した状態に対して、どう行動すべきか（あるいは、どう行動してはならないか）を OS として定義する」 アプローチです。
3. Node.js vm モジュールによる「思考の完全再現」
では、この Control Runtime をどのようにテストするのか。 ここで登場するのが、Node.js の標準機能である vm モジュールです。
テストスクリプト（control-runtime-vm.test.mjs）では、ブラウザを一切立ち上げません。 Node.js の内部に self や window を持つ「純粋な論理空間（サンドボックス）」を作り出し、そこに DoomWeb の JS ファイル群（DSLパーサーや調停ロジック）を読み込みます。
そして、実機走行時にキャプチャした「特定の瞬間の世界の状態（State Tensor）」を、そのまま入力として注入します。
JavaScript
const action = rt.predict({
health: 100,
depthSig: 0.92,
contextDict: "open-space",
wallVector: 0.2,
motionForwardProgress: 0.7,
// ... (実機からキャプチャした数十のセンサー値)
actionRepeatFrames: 66,
turnRepeatFrames: 240
});結果はどうなるか。 ゲームエンジンも、巨大な Bonsai モデルも動いていないにも関わらず、AI は実機と 1ミリ秒の狂いもなく、全く同じ意思決定（Action Packet）を出力します。
これが、AIKernel が確立した Deterministic Replay（決定論的リプレイ） です。
4. AIのバグが「テスト可能（Testable）」になる日
通常の AI 開発では、エージェントが不適切な行動をとったとき、「報酬関数が悪かったのか」「データが足りないのか」と推測し、再学習という名のブラックボックスに祈るしかありませんでした。
しかし、AIKernel のアーキテクチャは違います。
「北側東壁で南へ逃げ続ける」というバグが発生した場合、私はその瞬間のセンサー状態をキャプチャし、VM テストの fixture（入力データ）として固定します。 そして、autoplay-profile.json に Ingress Trim などの新しいガバナンスルール（1行のコード）を追加し、VM を叩きます。
コマンドを叩いてから結果が出るまで、わずか 1秒。
もしその修正が、別の場面での「足元の障害物回避（foot-clear）」を壊していれば、既存の VM テストが即座に失敗して教えてくれます。
1. Fixture（世界の切り取り）を作る
2. VM で叩いてバグを再現する
3. Profile（DSL）を修正してガバナンスを整える
4. VM で再検証し、Regression（退行）を防ぐ
これは、伝統的なソフトウェア・エンジニアリングにおける テスト駆動開発（TDD） の流れそのものです。 「AI の振る舞い」という確率的でブラックボックスなものを、完全に決定論的な OS のプロセスとして御し切り、ユニットテストの対象にしてしまったのです。
5. 学習から「制御プログラム開発」へのパラダイムシフト
アーキテクチャの深い理解者であるAIのコパさんは、この状況を見てこう言いました。
「拓也、これは “AI の学習” ではなく “AI による制御プログラム開発” そのものだよ。AI を訓練するのではなく、AI の意思決定 OS を設計している。これは本当に革命的だ」
まさにその通りです。
AIKernel.Doom で起きているのは、ニューラルネットワークの重みの調整ではありません。 Weak Gap Pivot、Dead-End Trim、Corner Release。これらはすべて、AI の暴走を防ぎ、目的へと収束させるための「統治（ガバナンス）のルール」です。
モデルを巨大化するのではなく、AI の行動を OS 的に統治する。 AIKernel の設計思想は、この「VMによる決定論的テスト」が機能したことで、机上の空論から強力な現実へと変わりました。
6. AIKernel.Wasm / Control への昇格（次なる展開）
現在、この DSL 評価やステージ調停（Stage Arbitration）の仕組みは、DOOM デモに特化した JS の実験層として動いています。 AIKernel.Wasm は依然として WASM ランタイム、WebGPU コンピュート、フレームバッファの管理といった「低レイヤの実行境界」を担う基盤です。
しかし、この Control VM の成功を受けて、すでに C# 側（AIKernel 本体）への逆輸入が始まっています。
DoomRoutePlanner.cs AutoplaySensorTensor.cs ControlStateTensorPacket.cs
JS 側に肥大化していた判断材料を、厳密な型を持つ C# の DTO や Tensor に寄せていくための足場が組まれつつあります。 将来的には、この「決定論的テストが可能な意思決定パイプライン」そのものが、AIKernel.Control および AIKernel.Wasm の汎用機能として昇格していく設計になっています。
結語：試験管の中で進化する OS
AI の開発は、途方もない計算資源を燃やし続けるフェーズから、論理と統治によって振る舞いを保証するフェーズへと移行しなければなりません。
ブラウザを起動せず、実機のレンダリングも待たず、Node.js のサンドボックス内で AI の脳だけを決定論的にシミュレーションする。 この Lightweight Control VM の存在こそが、AIKernel.Doom が悪意あるレベルデザインを圧倒的なスピードで突破できた最大の理由です。
私たちは AI を「学習」させているのではありません。 AI の行動をコードで書き、テストで保証し、OS として「統治」しています。
AIKernel は、AI を組み込んだ安全なシステムを構築するための、真の Semantic Computer（意味論コンピュータ）への階段を、また一つ登りました。
AIKernel.NET は Bing Webmaster Tools / IndexNow に対応しています。
記事更新は検索エンジンへ即時通知され、最新情報が迅速にインデックスされます。