Doom デモの調整に入りました──手元の Codex 監視と手書き注釈で進める正典 0.1.3 の実動確認
AIKernel 正典 0.1.3 の整理作業にあわせて、Doom デモ側の実動確認と調整を開始しました。64GB メモリ、2TB SSD、既存ディスプレイ4枚に液晶タブレットを加えた環境で、手元に Codex の解析画面を表示しながら、スクリーンショットへの手書き注釈を使って支援 AI へ意図を伝える開発スタイルを整えています。
カテゴリ: Development Log, AI Infrastructure, Testing, WASM, Developer Experience
正典 0.1.3 の整理作業を進める中で、今日は Doom デモ側の調整 にも着手しました。
ここ数日は、リリース前の確認、公開契約としての正典の整理、開発環境の増強、そして内部構造の見直しを進めてきました。
その流れを受けて、今日はコア側の整理だけでなく、実際に動くデモ環境へも目を戻しています。
正典として扱う以上、コアの変更はデモ環境にも影響します。
型の境界を整理すれば、デモ側の接続点も変わります。 Provider の責務を見直せば、ランタイム側の呼び出し方も変わります。 Control や WASM 周辺の構造を整えれば、実動確認の観点も変わります。
そのため、机上の整理だけでは不十分です。
実際に動かしながら、境界の整理や表現の調整を進めています。
デモは、正典の確認面でもある
Doom デモは、単なる見せ場ではありません。
AIKernel にとって、Doom デモはかなり厳しい実動確認の場です。
WASM ランタイム。 入力制御。 状態観測。 ログ。 HUD。 Control 層。 Provider 境界。 失敗時の復帰。 テレメトリの読み取り。
これらが同時に動きます。
そのため、コア側で行った整理が本当に意味を持つかどうかを確認するには、デモ環境での検証が非常に重要になります。
正典として公開する API や責務境界は、ドキュメント上で綺麗に見えるだけでは足りません。
実際のランタイムで破綻しないこと。 ログとして追えること。 問題が起きたときに切り分けられること。 実験層と正典層の境界が曖昧にならないこと。
そこまで確認して初めて、正典として扱える状態に近づきます。
新しい開発環境の効果
今回の調整は、新しい開発環境へ移行したことで、かなり進めやすくなりました。
先日、開発マシンのメモリを 16GB から 64GB へ増設し、さらに 2TB SSD を追加しました。
この効果は、Doom デモの調整でもはっきり出ています。
以前は、WASM ビルド、ログ解析、テスト環境、複数のエディタや検証プロセスを同時に動かすと、どうしても余裕がなくなる場面がありました。
特に、Doom 系の実行ログや telemetry を見ながら、正典層と実験層の差分を追う作業では、メモリとストレージの余裕がそのまま作業安定性に影響します。
今回の環境増強によって、次のような作業がかなり安定しました。
- ログ解析をしながらビルドを走らせる
- Doom デモを動かしながらコードを確認する
- 正典層と実験層の差分を並行して追う
- WASM / Control / Provider 周辺のテストを切り替えながら確認する
- snapshot や telemetry を残したまま再現確認する
地味ですが、この安定性はかなり大きいです。
検証環境が不安定だと、問題がコードにあるのか、環境にあるのか、判断しづらくなります。
逆に、開発環境が安定していると、観測した現象に対して落ち着いて向き合えます。
液晶タブレットを、手元の Codex 監視面にする
さらに今回は、既存のディスプレイ 4 枚に加えて、液晶タブレットを開発環境へ組み込みました。
ただし、これは単に「画面を 1 枚増やした」という話ではありません。
実際の使い方としては、液晶タブレットを拡張ディスプレイとして手元に置き、そこへ Codex の画面 を表示しています。
Doom デモを動かしながら、Codex がどのログを読み、どの仮説を立て、どのテストを走らせ、どこで詰まっているのかを、手元で常時モニタリングできるようにしました。
これがかなり効いています。
メイン画面ではコードや実行中のデモを見ます。 別画面ではログや telemetry を追います。 そして手元の液晶タブレットでは、Codex の解析状態を確認します。
AI が支援している内容を、横目ではなく、手元の作業面として見られるようになったことで、開発のリズムがかなり変わりました。
Codex が何を根拠に判断しているのか。 どのテストを通したのか。 どこを再確認しようとしているのか。 いまは実装中なのか、観測中なのか、検証中なのか。
こうした状態を、常に見える場所に置けるようになったのは大きいです。
AI 支援開発では、AI の出力だけを見るのでは足りません。
AI がいま何を見て、何を考え、どの段階にいるのかを観測できること が重要になります。
液晶タブレットは、そのための手元の観測面になっています。
ペンタブレットとしての役割
液晶タブレットは、表示面としてだけでなく、ペンタブレットとしても使っています。
ただし、ペン入力は液晶タブレット上の画面だけに閉じず、メイン画面へマッピングしています。
これにより、メイン画面上のスクリーンショットや図に対して、高解像度で細かく書き込めるようになりました。
主な用途は、支援 AI へ意図を伝えるためのラフ画作成です。
たとえば、Doom デモの HUD スクリーンショットに直接書き込みます。
「ここで door と wall の判定が混ざっている」 「この方向へ回り込み続けているのが問題」 「この gap は通路として扱うべきではない」 「このタイミングで Use probe に戻すべきではないか」 「このロジックなら stuck-only から wall-follow へ逃がせるのではないか」
このようなメモを、スクリーンショット上へ直接描き込みます。
文章だけで説明すると長くなる違和感も、画像に矢印や丸を描くだけで一気に伝わることがあります。
特に Doom デモのように、視覚、HUD、ログ、入力、行動結果が同時に絡む場合、問題の位置を言葉だけで説明するのは難しい。
そこで、画面キャプチャに直接手書きし、支援 AI に「何がどうおかしいのか」「このロジックを試すべきではないか」を伝えるための中間表現として使っています。
これは、単なるメモではありません。
AI と人間の間に置く、視覚的な仕様伝達レイヤです。
5画面体制ではなく、観測と注釈のワークベンチ
実際のデスクトップ構成を、NVIDIA RTX Desktop Manager の NVIEW 上の画面ですが、次のようになります。 なお、実際のNVIEWでは、デスクトップ１の他に３枚～５枚を用いて、各コンソールの監視系等も含め、大画面に１枚にまとめて統合表示として運用しています。
図 1: NVIDIA RTX Desktop Manager 上で表示した開発環境の俯瞰。 Doom デモ、Codex の解析画面、コード、支援AI画面、ログ、ブラウザなどが横並びで配置されている。 実際の並び順は本文の説明と異なるが、5画面体制での観測・注釈の運用イメージを示している。
結果として、作業環境は既存ディスプレイ 4 枚と液晶タブレットを合わせた構成になりました。
ただ、今回重要なのは「5画面ある」ことや「複数コンソールの監視」そのものではありません。
重要なのは、役割が分かれていることです。
Display 1: 正典層 / C# Core / AIKernel.Control
Display 2: 実験層 / Doom runtime / WASM integration
Display 3: 実行中の Doom デモ / HUD overlay
Display 4: ログビューア / telemetry / replay-oriented logs
Pen Display: Codex 解析画面 / 手元モニタリング / 手書き注釈
Pen Mapping: メイン画面への高精度入力 / スクリーンショット注釈この構成により、正典層、実験層、デモ環境、ログ、支援 AI の解析状態を同時に観測できます。
さらに、必要なときはスクリーンショットへ直接書き込み、支援 AI へ視覚的に指示を出せます。
以前は、ログを見ている間にデモ画面が隠れる。 デモ画面を見ている間にテスト結果が流れる。 Codex の解析を確認しようとすると、コード画面やログ画面を切り替える必要がある。 問題箇所を説明するために、長い文章で状況を書き起こす必要がある。
そうした小さな切り替えが、地味に思考を分断していました。
今は、実行中の Doom、ログ、コード、テスト、Codex の解析状態、そして手書き注釈を、かなり自然に行き来できます。
画面が増えたことで単に情報量が増えたのではありません。
観測と注釈の往復が速くなった のです。
これは、AIKernel のようなシステムを調整するうえでかなり重要です。
AIKernel の開発では、観測できることが修正可能性につながります。
そして、うまく観測した内容を支援 AI に正しく伝えられることが、修正速度に直結します。
いま確認していること
現時点では、まだ細かい変更点をまとめる段階ではありません。
ただ、Doom デモ側では主に次のような観点で確認を進めています。
AIKernel.Core / Control / Wasm
↓
Provider boundary
↓
Doom runtime integration
↓
Telemetry / HUD / replay-oriented logs
↓
actual behavior
↓
human annotation / AI-assisted diagnosis特に意識しているのは、コア側の整理がデモ側に与える影響です。
たとえば、Control 層の責務を整理したとき、デモ側の入力制御が不自然に密結合していないか。
Provider の境界を見直したとき、WASM ランタイムやデモ固有の実装が正典側へ漏れ出していないか。
ログや telemetry の扱いを整理したとき、後から現象を追えるだけの情報が残っているか。
HUD の表示と runtime status がズレていないか。
Codex の解析が、実際の画面上の違和感と一致しているか。
そして、人間がスクリーンショットに注釈した問題意識を、支援 AI が正しく修正方針へ変換できるか。
こうした点を、実際の動作を見ながら確認しています。
新機能追加ではなく、整える作業
今日の作業は、派手な新機能追加ではありません。
むしろ、すでに動いているものを、正典 0.1.3 に向けて整える作業です。
動くことと、正典として公開できることは違います。
実験層では、速く試すために多少の荒さを許容できます。
しかし、正典層では、その荒さをそのまま外へ出すわけにはいきません。
責務の境界。 型の意味。 Provider の位置づけ。 WASM ランタイムとの接続。 Control 層の公開範囲。 デモ固有の便宜と、コアへ戻すべき構造の切り分け。
これらを、Doom デモの実動確認と照らし合わせながら見直しています。
そして今回からは、そこにもう一つの観点が加わりました。
AI と人間の共同デバッグを、どう観測し、どう伝達するか。
Codex の解析画面を手元に置くこと。 スクリーンショットに直接手書きで問題を示すこと。 支援 AI に対して、文章だけでなく図として意図を渡すこと。
これらは一見すると開発環境の工夫に見えます。
しかし実際には、AIKernel の開発プロセスそのものを安定させるための重要な仕組みになりつつあります。
0.1.3 に向けて
正典 0.1.3 の公開に向けて、デモ環境も含めて丁寧に確認を進めています。
まだ、具体的な変更点を一つずつ紹介する段階ではありません。
いまは、内部構造、デモ環境、ログ、テスト、ドキュメント表現、そして支援 AI との共同デバッグ環境を合わせながら、正典として出せる形へ整えているところです。
明日以降、形が整ってきたところから順に、変更点や方向性をまとめていく予定です。
急がず、止まらず。
AIKernel 正典 0.1.3 に向けて、今日も一歩ずつ確認を進めています。
AIKernel.NET は Bing Webmaster Tools / IndexNow に対応しています。
記事更新は検索エンジンへ即時通知され、最新情報が迅速にインデックスされます。