Bonsai と CTG をつなぐ──AIKernel Doom Demo 統合実装と FirstDoor デバッグログ

AIKernel Day 5 として、Bonsai-1.7B、TELOS / OBJECTIVE / Sub-chips HUD、CTG ROM、Kairos、Kinesis、Chronos を統合した実装を解説します。FirstDoor で詰まった AI を、Codex が実行中ブラウザ、runtime status、Canvas、HUD overlay を使って観測・診断・修正した開発ログを紹介します。

• AIKernel
• AIKernel.NET
• Bonsai
• Bonsai 1 7B
• CTG
• CTG ROM
• Doom Demo
• WASM
• Webgpu
• Autoplay
• HUD Overlay
• Telos
• Objective
• Codex
• Browser Debug
• Replay LOG
• AI Operating System

) カテゴリ: AI Infrastructure, Local AI, WASM, WebGPU, Governance, Developer Experience

2026/06/20：追記
本記事の内容は2026/06/16公開のDoomデモ（プロトタイプ）に関する内容で、最新のデモ版とは内容が一致しない表現があります。理由は2026/06/20公開のブログ内でも一部触れていますが、意思決定モデルの見直しを行い、大幅なリファクタリングを行い、HUDやパイプラインの可視化を含めたUIも大幅に見直しています。

Day 1 で、AIKernel は耳を得ました。

Day 2 で、WASM Runtime、WebGPU、Bonsai-1.7B、zero-copy、AutoPlay によって身体を得ました。

Day 3 で、Aisthesis から Chronos までの意思決定行動パイプラインを整理しました。

Day 4 で、CTG ROM の内部、つまり三値評議会、Ethos 拒否権、2-of-3 承認定足数、Unknown の Fail-Closed を見ました。

Day 5 の今日は、統合実装です。

Bonsai は何をするのか。 CTG ROM はどこで止めるのか。 TELOS / OBJECTIVE / Sub-chips HUD は何を可視化するのか。 Kairos はいつ入力を流すのか。 Kinesis はどの仮想入力を出すのか。 Chronos はどう trace に残すのか。

そして何より、実際に AI が詰まったとき、それをどう観測し、どう切り分け、どう直したのか。

今日は、FirstDoor で詰まったデバッグログを中心に、AIKernel の統合実装を見ていきます。

1. 統合後の最小構成

まず、AIKernel Doom Demo における統合構成を整理します。

WASM Doom Runtime
  ↓ frame / hud / state
Aisthesis
  ↓ raw visual / audio / status
Phantasia
  ↓ 9x9 patch / spatial / auditory / semantic snapshot
Nous
  ↓ motion-stall / door-candidate / wall-candidate / sensor-recovery
Bonsai-1.7B
  ↓ proposal / candidate action
Telos
  ↓ TELOS / OBJECTIVE / sub-intents
CTG ROM
  ↓ Logos / Ethos / Pathos votes
Kairos
  ↓ timing / debounce / latch / probe window
Kinesis
  ↓ virtual input
WASM Doom Runtime
  ↓ world mutation
Chronos
  ↓ trace / replay / debug log

この構成で重要なのは、Bonsai が主権者ではないことです。

Bonsai は Proposal を出します。

しかし、それはまだ Action ではありません。

AIKernel では、Proposal が CTG ROM を通り、Kairos でタイミング調整され、Kinesis で仮想入力へ変換されて初めて Action になります。

つまり、Bonsai は小型の認知エンジンです。

CTG ROM は決定権者です。

AIKernel は実行統治 OS です。

Doom は、その構造を目に見える形で試す scenario です。

2. Bonsai の役割：三値判定器ではなく Proposal Engine

今回の構成では、Bonsai-1.7B をローカルで使います。

1.7B。 1bit 量子化。 ローカル実行。 WASM / WebGPU と同居。 クラウド不要。

この軽さは大きな利点です。

しかし、小型モデルに全権を渡してはいけません。

Bonsai に期待するのは、世界の全責任を背負うことではありません。

期待するのは、現在の Snapshot を読み、次に何を試すべきかを提案することです。

Bonsai:
  - current snapshot を読む
  - candidate action を出す
  - confidence を添える
  - objective の候補を出す

その Proposal は、AIKernel の Telos 層へ渡ります。

ここで TELOS と OBJECTIVE が整理されます。

TELOS     : FirstDoor
OBJECTIVE : Open First Door
Sub-chips : door-probe, align-heading, Kairos: Probe 95

しかし、ここでもまだ実行しません。

Proposal は CTG ROM によって審査されます。

3. CTG ROM の役割：行動の直前に立つゲート

CTG ROM は、Bonsai の提案を三つの評議会へ通します。

Logos : 目的達成に対して合理的か
Ethos : 安全条件・禁止条件に反しないか
Pathos: 文脈上、自然で説明可能か

たとえば、Open First Door という Objective が出たとします。

Logos はこう見ます。

ドア候補があり、Use は目的に対して合理的である。

Ethos はこう見ます。

door と wall の認知が衝突していないか。
対象が曖昧なら、安易に Use / forward を通してよいか。

Pathos はこう見ます。

同じ失敗ループに戻っていないか。
人間から見て行動理由が読めるか。

CTG ROM は、この三つを三値で受け取ります。

Approve / Reject / Abstain

Ethos が Reject すれば止まります。

Ethos が Reject していなくても、Approve が二票未満なら止まります。

これにより、Bonsai の提案は、実行権限を持つ前に必ず OS 的なゲートを通ります。

4. HUD は AI の内面ではなく、責務階層の投影である

今回の開発で大きかったのは、HUD に TELOS / OBJECTIVE / Sub-chips を出したことです。

これは単なるデバッグ UI ではありません。

AIKernel の内部状態を、責務階層に沿って投影したものです。

TELOS
  = 大局的な到達点

OBJECTIVE
  = 今取り組んでいる行動目標

Sub-chips
  = 瞬間的な検知、補正、Kairos 状態

この三段表示があると、AI の行動が意味の連鎖として読めます。

なぜ前進しているのか。 なぜ止まっているのか。 なぜ後退したのか。 なぜ Use を出したのか。 なぜ同じ場所で小刻みに動いているのか。

以前なら、これらは「なんか挙動が変」という感想で終わっていました。

しかし HUD に出すと、どの層で何が起きているかが読めるようになります。

そしてそれは、Codex にとっても読める情報になります。

5. 実装ログ：FirstDoor で詰まった AI を、Codex はどう診断したか

ここからが本題です。

実際の開発中、AI は FirstDoor 周辺で詰まりました。

TELOS は FirstDoor に向いています。

OBJECTIVE も Open First Door や Find And Open First Door へ進んでいます。

しかし、ドアが開きません。

AI は何かを見ています。 何かに向かっています。 しかし、正しくドアを開ける行動へ収束していない。

この状態を、まず HUD で観測しました。

図 1: 実行中の AIKernel Doom デモ。TELOS は FirstDoor、OBJECTIVE は Open First Door へ向いているが、HUD 上では door / wall / motion / foot など複数の認知チップが同時に出ており、ドア候補と壁候補の切り分けが不安定になっている。重要なのは、失敗がブラックボックス化していないことだ。AI が何を見て、何を目的とし、どこで詰まっているかが HUD 上に露出している。

この画面で重要なのは、AI が完全に迷子になっているわけではないことです。

TELOS は合っています。

OBJECTIVE も大きくは合っています。

問題は、認知と実行の境界にあります。

ドア候補が見えている。 壁候補も見えている。 9x9 patch は中心付近に反応を出している。 しかし、Use すべき対象として確定しきれていない。 あるいは、Use 後の前進ラッチが残り、再照準や再Useへ戻れていない。

これは、単なる「AI がバカだった」ではありません。

層に分解できる失敗です。

6. Codex はコードだけでなく、実行中環境を見た

ここで Codex に Browser / CDP 経由で実行中環境を観測させました。

Codex は、まず小目標を定義しました。

ゲーム開始後、TELOS=FirstDoor で安定し、
OpeningHome から FirstDoor 接近へ遷移すること。

そのうえで、実行中のタブへ問い合わせ、runtime status を読み、必要に応じて Canvas 画像を取得しました。

図 2: Codex によるオフライン解析の様子。実行中ブラウザの状態を CDP 経由で読み取り、TELOS=FirstDoor、useAttempted=false、探索バックや旋回ループの状態を確認したうえで、Canvas 画像を取得し、そこが本当にドアなのか壁なのかを切り分けている。これは単なるコード生成ではなく、実行中環境を観測しながら小目標に分解して修正する開発ループである。

このデバッグで重要だったのは、Codex が単にコードを生成したことではありません。

Codex は、実行中のブラウザを観測しました。

HUD を読みました。 runtime status を読みました。 Canvas 画像を取得しました。 時系列サンプルを取りました。 どの小目標で止まっているかを見ました。

そして、問題を大きく作り直すのではなく、小さく切り分けました。

7. 失敗は二段階あった

FirstDoor の詰まりは、単一のバグではありませんでした。

大きく分けると、二つのフェーズがありました。

7.1 useAttempted=false の探索ループ

第一段階では、AI は FirstDoor 周辺に入っているにもかかわらず、useAttempted=false のまま探索バックや旋回ループに張り付いていました。

つまり、対象に近づいてはいる。

しかし、Use を試す段階まで進んでいない。

この場合、問題は CTG ではありません。

Proposal が危険だから止められているのではなく、Telos / Kairos / Kinesis の境界で、Use を出す前の探索状態に戻っていました。

TELOS      : FirstDoor
OBJECTIVE  : Find And Open First Door
Nous       : door candidate / wall candidate conflict
Kairos     : probe timing not finalized
Kinesis    : back / turn loop

この段階では、まずドア候補と壁候補の切り分けを安定させる必要がありました。

7.2 useAttempted=true だが doorOpened=0 のラッチループ

別の検証では、firstDoorUseAttempted=true になっているにもかかわらず、doorOpened=0 のまま止まっていました。

つまり、Use は試みた。

しかし、ドアは開いていない。

その後、前進ラッチだけが残り、同じ正面前進を繰り返す周期へ入っていました。

TELOS              : FirstDoor
OBJECTIVE          : first-door-locked-use
doorConfidence     : high enough
firstDoorUseAttempted : true
doorOpened         : 0
movement-stall     : true
sensor-recovery    : repeated

ここでは、目的も認知も完全には外れていません。

問題は Kairos と Kinesis です。

Use 後の前進ラッチが残り、再照準や再Useへ戻れていない。

つまり、判断はかなり近い。

しかし、実行タイミングと入力プローブが足りない。

8. 層に分解すると、修正点が小さくなる

このデバッグで最も重要だったのは、失敗を層に分解したことです。

Aisthesis
  実行中ページ、Canvas、HUD、runtime status を観測する。

Phantasia
  9x9 patch、door / wall / motion / foot の表象へ変換する。

Nous
  movement-stall、sensor-recovery、doorOpened=0、door/wall conflict を検知する。

Telos
  FirstDoor という大局目的を維持する。

CTG
  Proposal が危険なら止める。ただし今回の主問題は CTG ではない。

Kairos
  Use latch、probe window、debounce、再照準のタイミングを見る。

Kinesis
  back、micro re-aim、re-Use、forward probe に分解する。

Chronos
  時系列サンプル、trace、判断過程を残す。

この分解により、修正方針が明確になりました。

CTG ROM を緩める必要はない。

Bonsai を巨大化する必要もない。

Perception 全体を作り直す必要もない。

必要だったのは、FirstDoor locked-use の失敗サイクルを検知したとき、単純な前進だけを繰り返さず、再プローブへ戻すことでした。

back
  ↓
micro re-aim
  ↓
re-Use
  ↓
forward probe

小さな修正です。

しかし、AIKernel の設計上は非常に大きな意味があります。

失敗を全体の失敗として扱わない。

どの層で詰まったかを見つけ、必要な境界だけを直す。

これが OS 的なデバッグです。

9. CTG は何を止め、何を止めないのか

今回の FirstDoor 問題は、CTG の重要性を逆に分かりやすくしてくれました。

CTG は、すべての失敗を直す魔法ではありません。

CTG は、行動の最終許可ゲートです。

対象が曖昧すぎる。 安全条件を満たしていない。 Root Goal から外れている。 モデル出力が不正。 同じ危険ループに入っている。 Ethos が拒否している。

こうした場合、CTG は止めます。

一方で、Use のタイミングが悪い、ラッチが残る、再照準が足りない、プローブ順序が悪いといった問題は、主に Kairos / Kinesis の責務です。

ここを混ぜると、設計が壊れます。

CTG に何でもやらせると、CTG は巨大な if 文になります。

Bonsai に何でもやらせると、Bonsai が主権を持ってしまいます。

Kairos に認知まで持たせると、タイミング制御が判断層に侵食します。

AIKernel では、責務を分けます。

この分離があるから、失敗したときに小さく直せます。

10. Codex は実装エージェントになった

今回のログを見ていて、強く感じたことがあります。

Codex は、単なるコード生成器ではありませんでした。

もちろん、コードは書きます。

しかし今回のループでは、Codex はそれ以上のことをしていました。

実行中ページを観測する。 現在の TELOS を読む。 OBJECTIVE を読む。 HUD の overlay を見る。 runtime status を取る。 時系列サンプルを作る。 Canvas を画像として確認する。 小目標に分解する。 詰まっている層を特定する。 必要な範囲だけを修正する。

これは、AIKernel の開発ループにおける 実装エージェント です。

ただし、ここでも Codex に主権があるわけではありません。

Codex が動けたのは、観測面があったからです。

TELOS が HUD に出ている。 OBJECTIVE が出ている。 Sub-chips が出ている。 runtime status が読める。 Canvas が取得できる。 trace が残る。 責務境界が決まっている。

これらの契約があったから、Codex は失敗を意味ある形で読めました。

AI に AI をデバッグさせるには、AI に自由を与えるだけでは足りません。

観測面と責務境界を与える必要があります。

11. AIKernel は AutoPlay スクリプトではない

ここまで来ると、AIKernel Doom Demo が単なる AutoPlay スクリプトではないことが分かります。

単なる AutoPlay なら、こうなります。

画面を見る
  ↓
行動を決める
  ↓
キーを押す

AIKernel では、こうです。

画面と音と状態を見る
  ↓
Aisthesis として受け取る
  ↓
Phantasia で表象化する
  ↓
Nous で検知する
  ↓
Bonsai が Proposal を出す
  ↓
Telos が目的階層を整理する
  ↓
CTG ROM が三値評議会で審査する
  ↓
Kairos がタイミングを決める
  ↓
Kinesis が仮想入力へ変換する
  ↓
Energeia で世界が変わる
  ↓
Chronos が trace に残す

この違いは大きい。

上はスクリプトです。

下は OS 的な実行制度です。

12. 開発中に得た実装原則

今回の統合実装で、いくつかの原則がはっきりしました。

12.1 TELOS は安定して見える場所に置く

TELOS は頻繁に変わるべきではありません。

だから HUD の中央下、視線に入りやすい場所に置くのが正しい。

人間が最も知りたいのは、AI が今どこへ向かっているかです。

12.2 OBJECTIVE は TELOS の直下に置く

OBJECTIVE は数秒単位で変わります。

TELOS の下に OBJECTIVE を置くことで、最終目的と現在の行動理由の因果関係が読みやすくなります。

12.3 Sub-chips は揺れてよい

movement-stall、sensor-recovery、door-probe、Kairos: Probe 95。

これらは高速に変化します。

だから、固定ラベルではなくチップとして並べるのが合っています。

12.4 失敗は層で読む

「ドアが開かない」は、原因ではありません。

それは結果です。

原因は、Perception かもしれない。 Nous かもしれない。 Telos かもしれない。 Kairos かもしれない。 Kinesis かもしれない。 CTG が正しく止めた結果かもしれない。

層に分解しない限り、正しい修正はできません。

12.5 AI にデバッグさせるなら、観測契約を作る

Codex が実行中環境を読めたのは、偶然ではありません。

runtime status、HUD overlay、Canvas capture、trace、TELOS / OBJECTIVE / Sub-chips があったからです。

AI にデバッグさせたいなら、AI が読める観測面を作る必要があります。

13. 15〜19日で見えた全体像

ここまでの連続投稿を振り返ると、AIKernel の全体像が見えてきます。

15日: 感覚
  Auditory Context / Spatial Awareness
  AIKernel に耳を与える。

16日: 身体
  WASM / WebGPU / Bonsai / zero-copy / AutoPlay
  AIKernel がローカルで動く身体を得る。

17日: 統治
  Aisthesis → Chronos の意思決定行動パイプライン
  提案と実行を分離する必要性を示す。

18日: 制度
  CTG ROM / 三値評議会 / 拒否権 / Fail-Closed
  実行許可の内部構造を固定する。

19日: 統合
  Bonsai + CTG + HUD + Codex Debug
  実際の失敗を観測し、層に分解し、局所修正する。

この順序は、AIKernel の認知発達そのものです。

感覚を得る。 身体を得る。 統治を得る。 制度を得る。 統合される。

ここまで来て、AIKernel は単なるローカル AI デモではなくなりました。

それは、AI の認識、判断、行動、監査を OS 的に接続する基盤になり始めています。

結語：AI が AI をデバッグする時代に必要なもの

今回の FirstDoor デバッグは、象徴的でした。

AI が動く。 AI が詰まる。 HUD に内部状態が出る。 Codex が実行中環境を読む。 時系列で状態を取り、画像を確認する。 TELOS、OBJECTIVE、Nous、Kairos、Kinesis に分解する。 必要な境界だけを小さく直す。

これは、AI が AI をデバッグしているようにも見えます。

しかし、本質はそこではありません。

AI が自由に AI を直しているのではありません。

AIKernel が観測面を与え、責務境界を与え、trace を与え、ROM を与えたから、AI は意味のある診断ができたのです。

AI に必要なのは、無制限の自由ではありません。

観測可能性。 責務分離。 決定論的ゲート。 Fail-Closed。 Replay。 そして、主権を持つ正典。

Bonsai は提案する。 CTG ROM は審査する。 AIKernel は実行を統治する。 Codex は観測された失敗を読み、必要な修正を行う。 Chronos はその軌道を記録する。

これが、AIKernel の統合実装で見えた姿です。

AIKernel は、AI を動かすためのライブラリではありません。

AI が世界を見て、考え、動き、失敗し、記録され、また直されるための、OS 的な基盤です。

Day 5。 AIKernel は、感覚、身体、統治、制度、そして実装ループをひとつにつなぎました。

AIKernel.NET は Bing Webmaster Tools / IndexNow に対応しています。
記事更新は検索エンジンへ即時通知され、最新情報が迅速にインデックスされます。