Semantic Fusion Layer──AIKernel の「意味論 OS」を支える中核層

Published: 2026-06-24 | Updated: 2026-06-24

AIKernel.Doom と Bonsai-1.7B の接続で重要になる Semantic Fusion Layer を、物理世界、意味論世界、三値判定世界をつなぐ翻訳層として整理します。Bonsai Provider / VFS / Control Plane ABI、WebGPU / VRAM resident path、CTG 論文との関係を踏まえ、AIKernel の意味論 OS を支える中核構造を解説します。

カテゴリ: AI Infrastructure, Semantic OS, AIKernel.Control, AIKernel.Doom, WebGPU, Software Engineering, Developer Experience

AIKernel の内部には、表からは見えにくいけれど、極めて重要な層があります。

それが Semantic Fusion Layer（意味論融合層） です。

ここ数日の記事では、AIKernel.Doom を題材に、WASM ランタイム、WebGPU、AutoPlay、Control Runtime VM、Fail-Operational、そして AIKernel.Control への抽出までを扱ってきました。

昨日の記事では、DOOM 固有の制御ロジックを JavaScript の実験層から C# の AIKernel.Control へ引き上げる話を書きました。

今日は、その一段内側にある話です。

AIKernel.Control が受け取る前段で、生データを意味論へ変換し、小型モデルとガバナンス層へ渡せる形に整える層。

それが Semantic Fusion Layer です。

DOOM のような実行環境から得られる情報は、最初はただの物理値です。

画面ピクセル。 HUD の数値。ステレオ音声。移動量。方位差。壁との距離。ルート候補。敵らしき色の塊。

これらを、そのまま小型モデルやガバナンス層へ渡すことはできません。

AIKernel が必要としているのは、生の数値ではありません。

必要なのは、AI が扱える 意味論 です。

「前方が開けている」「右壁に寄っている」「敵候補は見えるが、中央にはいない」「入口らしい隙間があるが、証拠は弱い」「移動しているつもりだが、実際には進んでいない」「現在の判断は安全に実行できるほど確かではない」

このように、物理世界の連続値を、AIKernel が扱える意味論の事実へ翻訳する層。

それが Semantic Fusion Layer です。

1. まず確認しておくべき Bonsai ABI の境界

今回の記事は Bonsai-1.7B と密接に関わるため、最初に ABI の境界を整理しておきます。

AIKernel.Control における Bonsai は、単に「どこかから呼び出すモデル」ではありません。

BonsaiBuiltInProvider という Control Plane Provider として扱われます。

リポジトリ上の仕様では、Bonsai-1.7B は CPU / WASM execution を想定した compact な 1-bit quantized model として整理され、model lifecycle は AIKernel.Control 内に閉じる設計になっています。

Bonsai の ROM asset は、直接 file I/O で読むのではなく、IVfsProvider 経由で読み込まれます。

必須 ROM file は次の二つです。

/sys/roms/bonsai-1.7b/config.json
/sys/roms/bonsai-1.7b/tokenizer.json

任意 ROM file として、次が定義されています。

/sys/roms/bonsai-1.7b/model.q1_0.bin

model.q1_0.bin が存在しない場合、Provider は初期化時に決定論的な bootstrap weights を生成できます。

ただし、これは contract validation、emulator smoke test、初期統合のための fallback です。

本番推論では、実際の ROM-bound Q1_0 weight payload を VFS 経由で提供する必要があります。

ここは重要です。

Bonsai は、DOOM のピクセルを直接読むモデルではありません。

Bonsai Provider の durable ABI は、あくまで次の要素で構成されます。

VFS 上の ROM layout
config.json
tokenizer.json
任意の model.q1_0.bin
Control Plane node operation
chat.local
text.tokenize
IBonsaiInferenceKernel.Forward(...)
token buffer / activation buffer / logits buffer

つまり、Semantic Fusion Layer が作る evidence は、Bonsai の低レイヤ ABI そのものではありません。

正確には、Semantic Fusion Layer は Bonsai に渡す前段の意味論 evidence を作る層 です。

その evidence は、現在の実装では scenario-local carrier、status、prompt / token stream、Control node metadata などを通じて Bonsai 側へ接続されます。

この区別を曖昧にすると、設計を誤ります。

Bonsai の ABI は Control Plane の契約です。 Semantic Fusion Layer は、そこへ渡す意味論世界を組み立てる変換層です。

2. Web で確認できる Bonsai-1.7B の性質

リポジトリだけを見ると、Bonsai Provider の ABI は分かります。

しかし、Bonsai-1.7B というモデルそのものの性質は、リポジトリだけでは十分には分かりません。

Web 上で確認できる範囲では、Bonsai-1.7B は on-device small language model として扱われ、1-bit Bonsai-1.7B や 1.58-bit Ternary-Bonsai-1.7B に言及する研究例があります。

その研究では、ナイーブな few-shot prompting では demonstration regurgitation、つまり例示出力の丸写しが起きることも報告されています。

これは、AIKernel にとって非常に重要な示唆です。

小型モデルに自由な推論を丸投げしてはいけません。

入力空間を絞る。意味論を安定化する。曖昧な状態を Unknown として残す。最終判断はガバナンス層で裁定する。

この構造があって初めて、Bonsai のような小型・低ビットモデルを OS 的に扱えます。

低ビット LLM 一般についても、BitNet b1.58 のように ternary weights {−1, 0, 1} を使い、メモリ、レイテンシ、エネルギー効率を高める研究が進んでいます。

AIKernel における Bonsai 利用も、この流れと思想的に近い位置にあります。

ただし、AIKernel が欲しいのは「何でも答える小型チャットモデル」ではありません。

欲しいのは、Semantic Fusion Layer が作った evidence を読み、限定された意味論空間で安定して判定する小型モデルです。

Bonsai を安全に使うためには、Bonsai の前に Semantic Fusion Layer が必要です。

3. Semantic Fusion Layer は「三つの世界」をつなぐ

Semantic Fusion Layer の役割は、三つの世界をつなぐことです。

物理世界
  ↓
意味論世界
  ↓
三値判定世界

物理世界には、連続値とノイズがあります。

depthSig
wallVector
enemyConfidence
routeConfidence
yawDiff
motionDelta
stereoBalance
healthValue

意味論世界には、人間にも AI にも読める事実があります。

frontOpen
frontBlocked
wallRight
enemyVisible
enemyCentered
lowHealth
doorLikely
routeCandidate
motionProgress
stuckLikely

三値判定世界には、Bonsai や CTG 接続層が扱いやすい離散値があります。

Yes
No
Unknown

この三段階を分ける理由は単純です。

生のセンサー値は、そのままでは揺れすぎます。

depthSig = 0.41 と depthSig = 0.43 の違いに、毎回別の意味を持たせてはいけません。

enemyConfidence = 0.19 と enemyConfidence = 0.21 の境界で、AI の行動が激しく反転してはいけません。

wallVector が少し揺れただけで、右壁沿い脱出と左旋回が交互に切り替わってはいけません。

だから AIKernel では、まず物理値を意味論へ翻訳し、さらに必要な場所では Yes / No / Unknown へ量子化します。

この変換を担うのが Semantic Fusion Layer です。

4. WebGPU / VRAM resident path：物理世界は GPU 側に置く

もう一つ、2026年6月24日時点の実装状況として明確にしておきたい点があります。

AIKernel.Doom のデモでは、視覚処理の主経路を WebGPU へ寄せています。

DOOM の framebuffer は、可能な限り GPUTexture として扱い、HUD や detector heatmap も WebGPU 側の buffer / shader path で合成します。

つまり、物理世界の一部は CPU に戻してから処理するのではなく、VRAM 上に展開されたまま扱います。

これは単なる高速化ではありません。

Semantic Fusion Layer の入口を安定させるための設計です。

DOOM framebuffer
  ↓
WebGPU texture / state buffer
  ↓
visual feature extraction
  ↓
semantic facts
  ↓
Bonsai-facing evidence

Bonsai 自体が VRAM 上の texture を直接読むわけではありません。

Bonsai が読むのは、Semantic Fusion Layer が翻訳した意味論 evidence です。

しかし、その evidence の元になる視覚特徴量は、できるだけ GPU resident な経路で抽出します。

この分離が重要です。

物理世界の高帯域データは VRAM に置く。意味論の低帯域データだけを Bonsai / CTG 接続層へ渡す。

これにより、AIKernel は「巨大な生データを小型モデルへ投げる」のではなく、GPU 上で圧縮された意味を小型モデルへ渡す 構造になります。

5. なぜ生データを Bonsai に直接渡してはいけないのか

小型モデルは強力です。

特に Bonsai-1.7B のような compact なローカルモデルは、WASM / CPU / 将来的な GPU backend との組み合わせで、AIKernel の実行基盤に非常に相性が良い。

しかし、小型モデルには小型モデルの作法があります。

生の連続値を大量に渡せば、モデルが賢くなるわけではありません。

むしろ逆です。

入力空間が広がりすぎる。判定境界が不安定になる。 ReplayLog の比較が難しくなる。 CTG ROM が受け取る意味が揺れる。同じ状態に見えるのに、毎回違う token / logits が出る。

これは OS 的にはかなり危険です。

AIKernel が必要としているのは、「大量の情報を渡すこと」ではありません。

必要なのは、決定に必要な意味だけを、安定した形で渡すこと です。

たとえば、Bonsai に次のような情報をそのまま渡すのではなく、

{
  "depthSig": 0.417,
  "wallVector": [-0.22, 0.81],
  "enemyConfidence": 0.184,
  "routeConfidence": 0.631,
  "yawDiff": -7.2
}

Semantic Fusion Layer は、まず意味論へ落とします。

{
  "frontOpen": "Unknown",
  "wallRight": "Yes",
  "enemyVisible": "No",
  "routeCandidate": "Yes",
  "headingAligned": "Unknown"
}

ここで初めて、Bonsai が扱いやすい「世界の事実」になります。

Bonsai は物理世界を知りません。

Bonsai が見るのは、Semantic Fusion Layer が作った意味論世界です。

6. Semantic Feature Extraction：物理値から意味を取り出す

Semantic Fusion Layer の第一の役割は、物理世界から意味の候補を取り出すことです。

これは、単なる特徴量抽出ではありません。

AIKernel.Doom では、画面や HUD から得られる情報が、Aisthesis / Phainesis / Nous という段階を通って意味へ近づいていきます。

Aisthesis  = 感覚入力
Phainesis  = 現象としての抽出
Nous       = 認知ラベル化

Aisthesis では、まだ入力は生に近い状態です。

visual
audio
motor
movement
compass
health
spatial

Doom 側の実装では、これらの sensor state は固定配列ではなく、拡張可能な sensorInputs map として扱われます。

これは重要です。

AIKernel の感覚器官は増える可能性があります。

視覚だけではありません。音もあります。移動もあります。方位もあります。体力もあります。空間モデルもあります。

新しいセンサーを追加しても、HUD toggle loop や status carrier の形を壊さない。

この拡張性が、Semantic Fusion Layer の入口を支えています。

7. Phainesis / Nous：意味論へ近づく中間表現

次に、Phainesis と Nous が働きます。

Phainesis は、現象を取り出します。

たとえば、画面内の色の塊、動き、ちらつき、接近感、明度差、音の帯域などです。

Nous は、それらを状況ラベルへ近づけます。

AIKernel.Doom の現在の実装では、scenario-local な NousCarrier が存在します。

この carrier は Gate result ではありません。

Council vote でもありません。

あくまで pre-governance cognition carrier です。

つまり、「まだ判断ではない認知」です。

NousCarrier には、正規化された sensor state、9x9 visual feature grid、movement / health ternary envelopes、Bonsai ternary pattern values、そして gateExecuted=false の CTG-ROM trace が含まれます。

ここで重要なのは、まだ行動は決めていないということです。

「見えた」「それらしく見える」「危険かもしれない」「詰まりかもしれない」

この段階では、すべては evidence です。

まだ命令ではありません。

8. Semantic Quantization：Yes / No / Unknown へ落とす

Semantic Fusion Layer の第二の役割は、意味論を量子化することです。

AIKernel では、すべてを連続値のまま運ぶのではなく、必要に応じて三値へ落とします。

Yes
No
Unknown

ここでの Unknown は、ただの中間値ではありません。

これは、Fail-Closed のための重要な状態です。

「分からないが、多分そうだろう」ではありません。

「分からないので、成功としては扱わない」です。

たとえば、次のような量子化が考えられます。

depthSig > 0.42
  -> frontOpen = Yes

depthSig < 0.25
  -> frontOpen = No

otherwise
  -> frontOpen = Unknown

enemyConfidence > 0.70
  -> enemyVisible = Yes

enemyConfidence < 0.20
  -> enemyVisible = No

otherwise
  -> enemyVisible = Unknown

health < 18
  -> criticalHealth = Yes

health >= 25
  -> criticalHealth = No

otherwise
  -> criticalHealth = Unknown

このように三値化すると、Bonsai や CTG 接続層は、曖昧な状態を曖昧なまま扱えます。

曖昧なものを無理に true / false へ潰さない。

ここが重要です。

二値化は速いですが、危険です。

三値化は少し面倒ですが、安全です。

AIKernel の Semantic Fusion Layer は、この Unknown を明示的に残すことで、後段の Fail-Closed と ReplayLog に接続します。

9. Evidence Assembly：Bonsai に渡せる形へ整える

第三の役割は、意味論 evidence を Bonsai 側へ渡せる形に整えることです。

ここで、もう一度 ABI の境界を確認します。

現在の BonsaiBuiltInProvider は、chat.local と text.tokenize を capability として持ちます。

ExecuteNodeAsync は node operation を評価し、ControlExecutionResult を返します。

物理推論は IBonsaiInferenceKernel へ委譲されるため、CPU backend と GPU backend は同じ provider contract を共有できます。

IBonsaiInferenceKernel.Forward(...) は、BonsaiModelState、入力 token ID、出力 logits buffer を受け取ります。

つまり、Bonsai の低レイヤ実行境界は token / logits の世界です。

そのため、Semantic Fusion Layer は、Doom 固有の数値をそのまま Bonsai ABI へ差し込むのではなく、意味論 evidence を Bonsai-facing な表現 へ整えます。

現在の Doom Demo では、これは scenario-local carrier や prompt / token stream、status carrier、debug trace を通じて行われます。

将来的に AIKernel.Control 側へ抽出するなら、ここは product-neutral な DTO / packet へ昇格させるべき領域です。

10. Semantic Fusion Layer が作る「世界の辞書」

Semantic Fusion Layer は、AIKernel にとっての世界の辞書です。

物理値に名前を与え、意味を与え、後段で扱える形へ整えます。

Semantic Fact	意味	由来する情報
`frontOpen`	前方が開けている	depth / gap / route evidence
`frontBlocked`	前方が塞がっている	close-wall / collision / motion stall
`wallRight`	右壁寄り	wallVector / route alignment
`enemyVisible`	敵候補が見える	color cluster / motion / combat evidence
`enemyCentered`	敵候補が照準付近にいる	yaw diff / center region score
`lowHealth`	体力が低い	HUD health / face quantization
`doorInRange`	Use 可能な距離に入口候補がある	close-wall / gap / use-contact evidence
`routeCandidate`	進むべき経路候補がある	landmark / corridor / entropy reduction
`motionProgress`	実際に進んでいる	frame delta / motor intent / movement sensor
`stuckLikely`	詰まり状態の可能性が高い	movement mismatch / repeated area / stall score

この辞書があるから、Bonsai は「画面」ではなく「状況」を扱えます。

CTG 接続層は「曖昧なピクセル」ではなく「裁定可能な evidence」を扱えます。

ReplayLog は「そのとき何が見えていたか」ではなく、「そのとき何を事実として扱ったか」を記録できます。

これは決定的に重要です。

AI の判断を監査するには、入力を意味の単位で残す必要があります。

ピクセルを全部保存するだけでは不十分です。

判断に使われた意味論が残っていなければ、なぜその行動に至ったのかを説明できません。

11. Bonsai は Semantic Fusion Layer の世界観を前提に動く

Bonsai は DOOM の物理世界を直接知りません。

Bonsai が知っているのは、Semantic Fusion Layer が作った意味論世界です。

これは制約であると同時に、強みでもあります。

制約としては、Semantic Fusion Layer の語彙が貧弱なら、Bonsai も貧弱な判断しかできません。

frontOpen と frontBlocked しかなければ、入口なのか、横道なのか、罠なのかは区別できません。

enemyVisible しかなければ、敵が中央にいるのか、遠いのか、遮蔽されているのかは分かりません。

一方で、強みとしては、Bonsai の判断空間を小さく保てます。

小型モデルに、物理世界すべてを背負わせない。

小型モデルには、意味論化された evidence の組み合わせだけを見せる。

これにより、Bonsai は巨大な視覚モデルではなく、意味論上の三値判定器として使えます。

ここが AIKernel らしい設計です。

モデルを大きくして解決するのではありません。

世界を適切な意味論へ翻訳し、小型モデルが扱える問題へ落とすのです。

12. ReplayLog と学習データの意味

Semantic Fusion Layer は、ReplayLog の意味も変えます。

ReplayLog に保存すべきなのは、単なる入力と出力ではありません。

保存すべきなのは、判断の途中にあった意味論です。

physical input
  ↓
semantic facts
  ↓
ternary envelopes
  ↓
Bonsai proposal
  ↓
CTG / gate evaluation
  ↓
action
  ↓
result

この流れが残ることで、あとから比較できます。

同じ物理状態に対して、Semantic Fusion Layer は同じ意味論を出したか。同じ evidence に対して、Bonsai は同じ proposal を出したか。同じ proposal に対して、CTG 接続層は同じ許可 / 拒否を出したか。同じ action に対して、環境はどう変化したか。

この比較ができると、改善の対象を切り分けられます。

認識が悪いのか。意味論化が悪いのか。量子化閾値が悪いのか。 Bonsai の判定が悪いのか。 CTG 側の裁定が厳しすぎるのか。 Kinesis の action mapping が悪いのか。

すべてを「AI がミスした」で片づけない。

これが AIKernel の開発体験です。

13. 入口問題で見えた Semantic Fusion Layer の重要性

20日の記事で、AI が入口の前で迷い続けた話を書きました。

あの問題は、Semantic Fusion Layer の重要性を強く示していました。

AI は入口を見ていました。

Gap も見えていました。壁も見えていました。ランドマークも見えていました。移動の失敗も観測されていました。

しかし、それらの意味論の裁定が弱かった。

「弱い通路候補」「壁沿いの誤った前進」「進んでいるつもりだが進んでいない状態」「入口方向への再収束が必要な状態」

これらを正しく意味論化し、三値化し、後段へ渡す必要がありました。

ここで分かったのは、センサーを増やせば解決するわけではないということです。

センサーが増えても、それらを意味論へ融合できなければ、AI は迷います。

むしろ情報量が増えたぶん、迷い方が複雑になります。

Semantic Fusion Layer は、情報を増やす層ではありません。

情報を 判断可能な意味へ圧縮する層 です。

14. 現在の実装上の注意：Doom は scenario-local、契約は product-neutral へ

ここで、実装上の注意も書いておきます。

AIKernel.Doom は、あくまで scenario です。

Doom 側の mapping は scenario-specific mapping であり、canonical interface definition ではありません。

Doom provider は、game state、sensor fusion、autoplay command を generic AIKernel DTO へ写像します。

一方で、WebGPU、WebAudio、WASM runtime、CTG Gate evaluation は、それぞれの所有パッケージが責務を持つべきです。

この分離が大切です。

Doom 側で見つけた語彙を、そのまま AIKernel 全体の正典にしてはいけません。

まず Doom の中で観測する。動くことを確認する。 ReplayLog で比較する。 VM でテストする。十分に中立化できる語彙だけを AIKernel.Control / AIKernel.Wasm へ昇格する。

この順序が必要です。

Semantic Fusion Layer も同じです。

今日の記事で使っている名前は、単一のクラス名というより、責務の名前です。

現在は Doom 側、WASM 側、Control 側、HUD 側にまたがっている実装責務を、意味論 OS の観点から束ねて Semantic Fusion Layer と呼んでいます。

将来的には、この責務のうち product-neutral な部分を、AIKernel.Control / AIKernel.Wasm の契約へ抽出していくことになります。

15. CTG 論文との接続

ここで、CTG との関係も整理しておきます。

正式な CTG は Canonical Trajectory Governance です。

これは、確率的な LLM / SLM 由来の候補行動を、決定論的な OS 制御へ入れてよいかを裁定するための軌道ガバナンス理論です。

CTG では、Logos / Ethos / Pathos の三評議会が候補行動を評価します。

ただし、CTG の本質は「三つのラベルを付けること」ではありません。

候補行動を一連の trajectory として扱い、その各ステップが許可されるかを Fail-Closed に評価することです。

Semantic Fusion Layer は、この CTG の前段にあります。

CTG は、意味のない raw pixel や raw depth を裁定するわけではありません。

CTG が裁定できるのは、意味論化された evidence と proposal です。

したがって、Semantic Fusion Layer が不安定であれば、CTG も安定しません。

逆に、Semantic Fusion Layer が物理世界を安定した三値 evidence へ変換できれば、CTG はその trajectory を監査可能な形で評価できます。

現在の Doom Demo は、正式な CTG の完全な trajectory 計算をすべて実装しているわけではありません。

しかし、物理世界を意味論へ変換し、Bonsai-facing evidence を作り、Topos / Kairos / Kinesis / CTG 接続層へ渡すという流れは、Canonical Trajectory Governance へ接続するための実装上の入口になっています。

16. 全体構造

整理すると、現在の AIKernel.Doom / Bonsai / CTG 接続は、次のように見ると分かりやすいです。

DOOM physical world
  - framebuffer
  - HUD values
  - stereo PCM
  - movement delta
  - wall / gap / route hints
        ↓
WebGPU / VRAM resident path
  - GPUTexture
  - detector heatmap buffer
  - shader HUD compositor
  - zero-copy capable visual path
        ↓
Semantic Fusion Layer
  - feature extraction
  - sensor fusion
  - semantic facts
  - ternary envelopes
  - scenario-local evidence carriers
        ↓
Bonsai-facing evidence
  - prompt / token stream
  - Control node metadata
  - status carrier
  - ternary pattern values
        ↓
Bonsai-1.7B Provider
  - VFS ROM assets
  - tokenizer
  - Q1_0 model state
  - inference kernel
  - logits
        ↓
Proposal / Pattern Result
        ↓
CTG connection layer
  - Topos / Kairos / Kinesis
  - three-council gateway
  - Fail-Closed
        ↓
Action
        ↓
ReplayLog / Telemetry

ここで重要なのは、Semantic Fusion Layer が「Bonsai の前」にあることです。

Bonsai は世界を直接見るのではありません。

Semantic Fusion Layer が翻訳した世界を見るのです。

そして CTG は、Bonsai の出力をそのまま信じるのではありません。

Semantic Fusion Layer によって整えられた evidence と、Bonsai の proposal と、Topos / Kairos / Kinesis の状態を踏まえて、実行してよいかを裁定します。

おわりに：AIKernel の意味論 OS は、この層を中心に回っている

Semantic Fusion Layer は、AIKernel の世界モデルの中で最も重要でありながら、これまであまり表に出てこなかった層です。

しかし、この層を理解すると、AIKernel の構造が一本の線でつながります。

Bonsai。 Evidence。 Semantic Quantization。 ReplayLog。 Provider。 CTG 接続層。 Kinesis。 WASM。 WebGPU。 VRAM resident visual path。

それぞれが別々の部品ではなく、ひとつの意味論 OS の中で役割を持ちます。

AIKernel が目指しているのは、生データを巨大モデルへ丸投げすることではありません。

物理世界を WebGPU / VRAM 上で効率よく扱い、意味論へ翻訳し、三値へ量子化し、小型モデルが扱える evidence へ整形し、その結果をガバナンス層で裁定することです。

AI は世界を見るだけでは足りません。

世界を、判断可能な意味へ変換する必要があります。

Semantic Fusion Layer は、そのための層です。

AIKernel の意味論 OS は、この層を中心に回っています。

そしてこの整理は、明日の v0.1.3 正典リリースへそのまま接続します。

DOOM の箱庭で見つけた制御ルールを AIKernel.Control へ戻すだけでは足りません。その手前にある「世界を意味へ翻訳する層」まで見えて初めて、AIKernel がなぜ OS 的な基盤である必要があるのかが分かります。

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