AI は電気羊の夢を見るのか？──AIKernel に“耳”を与える日

AIKernel の Perception Layer に Auditory Context を統合し、stereo PCM、GPU resident buffer、auditorySnapshot、spatialSnapshot、fusedDirection、HUD overlay によって、視覚と聴覚を融合したリアルタイム空間認知を実装した Day 1 の開発ログです。

• AIKernel
• AIKernel.NET
• Aios
• Perception Layer
• Auditory Context
• Spatial Awareness
• Webgpu
• WASM
• PCM
• Zero Copy
• GPU Resident
• HUD Overlay
• Multimodal AI
• Spatial Cognition
• Doom Demo
• Developer Experience

カテゴリ: AI Infrastructure, Multimodal AI, WebGPU, WASM, Spatial Computing, Developer Experience

今日から数日間、AIKernel の現在地を段階的に公開していきます。

初日は 感覚 です。

AI に「目」を与える実装は、これまで Perception Layer として少しずつ積み上げてきました。視野を分割し、動的特徴量を読み、対象を追跡し、HUD 上に認知状態を表示する。そこまでは、すでに AIKernel の空間認知基盤として形になり始めていました。

しかし、現実の空間認知は視覚だけでは成立しません。

人間は、視界に入っていないものを音で察知します。 背後の気配、左側で起きた変化、遠くの反応、近づいてくる何か。

視覚が「そこに何があるか」を教えるなら、聴覚は「どちらで何かが起きたか」を教えてくれます。

今日の実装で、AIKernel の Perception Layer は初めて 音を空間情報として扱う 段階に入りました。

言い換えれば、AIKernel に“耳”を与えた日です。

この記事では、思想や統治理論には踏み込みません。今日はただ、低レイヤで何が動き始めたのかだけを記録します。

stereo PCM。 GPU resident buffer。 zero-copy。 auditorySnapshot。 spatialSnapshot。 fusedDirection。 HUD overlay。

AIKernel が音と視覚を使って、リアルタイムに空間を読むための技術ログです。

なお、明日 2026 年 6 月 16 日に予定している Doom デモンストレーションは、現時点では予定通り公開できる見込みです。今日はその前日として、まず「耳」の実装に焦点を当てます。

1. AI にとっての“耳”は Audio API ではない

AI に音を渡すだけなら、Audio API を叩けば済みます。

PCM を取得する。 波形を読む。 音量を計算する。 周波数を出す。

それだけなら、単なる音声処理です。

しかし、AIKernel が欲しかったのは「音声ファイルを解析する機能」ではありません。

欲しかったのは、音を空間認知へ接続するための感覚器官 です。

つまり、音を次のような情報へ変換することです。

• 左右どちらから強く聞こえるのか。
• どれくらい急激に変化したのか。
• 環境音なのか、イベント音なのか。
• その音は視覚側の変化と一致しているのか。
• 視覚が不確かなとき、音が方向推定を補正できるのか。

この瞬間、音は単なる波形ではなくなります。

音は、AI が世界の方向性を理解するための入力になります。

AIKernel では、この音響認知の単位を Auditory Context として扱います。

2. Auditory Context：stereo PCM から auditorySnapshot へ

今回の実装では、音声入力を stereo PCM として受け取り、それを固定 shape の auditorySnapshot へ変換します。

処理の流れは、おおまかに次のようになります。

Stereo PCM
  ↓
JS normalize layer
  ↓
WASM auditory analysis
  ↓
GPU resident buffer
  ↓
auditorySnapshot

ここで重要なのは、JS 側に重い計算を持たせないことです。

JS 側の責務は、入力の正規化とランタイム境界の橋渡しに絞ります。

• サンプルレートの正規化
• stereo channel の整列
• 入力バッファの受け渡し
• HUD への描画指示

一方で、左右エネルギー、balance、dominant frequency、transient score、event hint などの計算は Wasm 側へ寄せます。

これは、速度のためだけではありません。

JS 側に認知ロジックを散らすと、Perception Layer の意味論が崩れます。

入力の整形は JS。 認知特徴量の計算は Wasm。 可視化は HUD。 バッファは可能な限り GPU resident。

この責務分離によって、音響認知の処理経路を安定させます。

3. auditorySnapshot の固定 shape

auditorySnapshot は、音の状態を AIKernel が扱いやすい形へ圧縮した固定 shape のデータです。

抽象化すると、次のような構造になります。

{
  "timestamp": 1718424000000,
  "sampleRate": 48000,
  "leftEnergy": 0.42,
  "rightEnergy": 0.18,
  "balance": -0.40,
  "dominantFrequencyHz": 1320.0,
  "motionIntensity": 0.67,
  "transientScore": 0.73,
  "eventConfidence": 0.81
}

ここでのポイントは、auditorySnapshot が「音そのもの」ではないことです。

これは、音から抽出された 認知用の中間表現 です。

PCM をそのまま Decision Layer に渡しても、扱いづらすぎます。波形は情報量が大きく、フレームごとの揺れも激しい。そこで、AIKernel では波形を一段抽象化し、方向性や変化量として扱える形に圧縮します。

特に重要なのは balance です。

左右チャンネルのエネルギー差を使うことで、音の偏りを推定できます。

balance < 0  → left dominant
balance ≈ 0  → center / ambiguous
balance > 0  → right dominant

最初の実装では、この符号の扱いで一度ハマりました。

左から聞こえているはずなのに、HUD 上では右に補正が出る。 視覚方向と聴覚方向が噛み合わない。 fusedDirection が妙に揺れる。

原因は単純で、左右チャンネルの解釈と UI 座標系の向きが一致していませんでした。

音響処理ではよくある小さなズレですが、空間認知では致命的です。

なぜなら、左右が反転した“耳”は、AI に間違った世界を教えるからです。

この修正後、HUD 上の音響方向と視覚方向が自然に一致し始めました。

4. 視覚と聴覚の融合：Spatial Awareness Architecture

音が auditorySnapshot になっただけでは、まだ空間認知にはなりません。

AIKernel が目指しているのは、視覚と聴覚を別々に表示することではなく、両者を統合して 空間方向 として扱うことです。

そのために、今回の実装では spatialSnapshot と fusedDirection を導入しました。

処理の流れは次のようになります。

Visual Perception
  ↓
visualDirection

Auditory Context
  ↓
auditoryDirection

WasmSpatialCognitionProvider
  ↓
spatialSnapshot
  ↓
fusedDirection
  ↓
HUD overlay

視覚側は、WebGPU resident frame buffer から動的特徴量を読みます。

• motion intensity
• saliency
• target likelihood
• obstacle hint
• region confidence

聴覚側は、stereo PCM から方向補正を出します。

• left / right energy
• balance
• transient score
• event confidence
• auditory direction hint

WasmSpatialCognitionProvider は、この二つを融合し、最終的な fusedDirection を生成します。

抽象化すると、考え方は非常に単純です。

fusedDirection = normalize(
  visualDirection * visualConfidence
  + auditoryDirection * auditoryConfidence
)

もちろん、実際にはノイズ除去、時間平滑化、confidence の下限、HUD 表示用の丸めなどが入ります。

しかし本質は、視覚と聴覚の双方を 方向ベクトル として扱い、信頼度に応じて合成することです。

視覚が強ければ視覚が勝つ。 音が強く、視覚が曖昧なら音が補正する。 両方が弱ければ、方向推定は保留される。

この構造にしたことで、AIKernel の Perception Layer は「画面を見ている」だけの層から、「空間を読んでいる」層へ進みました。

生物学的に喩えるなら、これは視覚と聴覚を統合して定位を行う中枢、たとえば superior colliculus 的な役割に近いものです。

ただし、AIKernel ではそれを OS レイヤの Provider と Snapshot として扱います。

5. HUD overlay：AI の空間認知を外へ出す

認知は、見えなければデバッグできません。

今回の HUD overlay では、auditorySnapshot と spatialSnapshot をリアルタイムに表示します。

表示するのは、たとえば次のような情報です。

• 左右エネルギー
• balance
• dominant frequency
• auditory confidence
• visual direction
• auditory correction
• fusedDirection
• timestamp
• spatial confidence

HUD の役割は、派手な演出ではありません。

これは認知デバッガです。

音が左から来ているのに balance が右を示すなら、チャンネル解釈が間違っている。 視覚では右を見ているのに fusedDirection が中央へ戻るなら、confidence の設計が強すぎる。 音響イベントが出ているのに HUD に反映されないなら、Worker か Wasm 境界の同期が怪しい。

このように、HUD は「AI が何を感じているか」を人間が読むための窓になります。

今回も、HUD を見ていなければ気づかなかった問題がありました。

ログでは音響イベントが出ている。 しかし HUD 上では補正方向が更新されていない。 逆に、HUD だけが古い値を掴んでいるように見える。

原因は、Worker 側の更新タイミングと描画フレームの同期ズレでした。

音声処理は連続的に走ります。 描画はフレーム単位で走ります。 Wasm 側の Snapshot 更新も別タイミングで走ります。

この三つを雑につなぐと、HUD が「現在」を表示しているつもりで、実は一つ前の状態を表示していることがあります。

そこで、timestamp を Snapshot に含め、HUD 側でも更新順序を追えるようにしました。

これだけで、デバッグの見通しがかなり良くなりました。

6. GPU resident と zero-copy：音を“感じる”ための低レイヤ最適化

聴覚認知をリアルタイムに扱うには、処理が軽くなければなりません。

音は止まりません。

視覚フレームも止まりません。

HUD も止まりません。

そのうえで AI が次の行動へ進むなら、Perception Layer は常に低遅延である必要があります。

今回の実装では、特に次の最適化を意識しました。

• stereo PCM のコピー回数削減
• GPU resident buffer の維持
• zero-copy 経路の確保
• Span<T> / stackalloc による小規模バッファ処理
• Snapshot の固定 shape 化
• JS object shape の安定化
• DOM ノード再利用
• HUD 更新の差分化
• GC 発生頻度の抑制

このあたりは地味ですが、かなり効きます。

特に、固定 shape の Snapshot は重要でした。

毎フレーム違う形のオブジェクトを作ると、JS 側の hidden class が安定せず、パフォーマンスが読みにくくなります。

また、HUD 用の DOM を毎回作り直すと、描画負荷と GC が増えます。

そこで、データ構造はなるべく固定し、表示も既存ノードの値を書き換える方式に寄せました。

これは見た目の話ではなく、リアルタイム Perception の基礎です。

AI が世界を感じるためには、感覚器官そのものが遅延してはいけません。

7. AIKernel が到達しつつある“空間認知エンジン”

今回の実装で見えてきたのは、AIKernel の Perception Layer が単なる機能追加ではなく、空間認知エンジン として分離できるということです。

レイヤとして見ると、構造はこうなります。

AIKernel.NET
  - contracts
  - provider interfaces
  - snapshot definitions

WASM Runtime
  - auditory analysis
  - spatial fusion
  - low-level execution

WebGPU Runtime
  - frame buffer
  - GPU resident resources
  - visual feature extraction

Control Layer
  - orchestration
  - runtime switching
  - worker coordination

Scenario Layer
  - demonstration runtime
  - interaction environment

HUD Layer
  - overlay
  - debug visualization
  - perception monitoring

ここで大事なのは、シナリオ層が一番上にあることです。

デモは重要です。 実際に動いていることを示すには、強いシナリオが必要です。

しかし、AIKernel の本体はシナリオそのものではありません。

本体は、視覚、聴覚、Wasm、WebGPU、HUD、Snapshot、Provider を接続する空間認知エンジンです。

この構造は、特定のデモに閉じません。

ロボティクス。 XR。 サイバネティック UI。 遠隔操作。 自律エージェント。 マルチモーダル AI ランタイム。

どの領域でも、「視覚と聴覚から空間を読む」必要があります。

AIKernel の Perception Layer は、その共通部分を OS 的な契約として取り出し始めています。

8. 開発中にハマったこと

今回の実装は、きれいな一本道ではありませんでした。

特にハマったのは、次の三つです。

8.1 左右チャンネルと座標系のズレ

音響側の left / right と、HUD 側の x 軸が一致していないと、補正方向が反転します。

これはログだけでは分かりにくい問題でした。

HUD 上で balance と fusedDirection を同時に見せたことで、ようやく違和感を確認できました。

8.2 Worker と HUD の同期ズレ

Worker からは新しい Snapshot が来ているのに、HUD 側が古い値を描画している瞬間がありました。

この問題は、timestamp を明示し、更新順序を追跡できるようにして解消しました。

非同期境界が複数あるシステムでは、値そのものだけでなく、「いつの値か」を必ず持たせるべきです。

8.3 情報量が多すぎる HUD

音響、視覚、方向、confidence、周波数、イベント、timestamp。

全部を表示すると、HUD はすぐ読めなくなります。

最初は、技術的に出せる値を全部出したくなりました。

しかし、それでは認知デバッガになりません。

人間が瞬時に読める量へ圧縮する必要があります。

最終的には、主指標を大きく、補助指標を小さく、方向系は中央に寄せる形で、ある程度読みやすくなりました。

ここで学んだのは、HUD 設計も Perception Layer の一部だということです。

見えない値は直せません。 しかし、見えすぎる値も読めません。

9. Day 1：AIKernel に耳を与える

今日の成果を一言でまとめるなら、こうです。

AIKernel に耳が生えました。

もちろん、これは比喩です。

実際に作ったのは、stereo PCM を解析し、Wasm で音響特徴量を取り出し、GPU resident な視覚情報と融合し、auditorySnapshot と spatialSnapshot を HUD に投影する仕組みです。

しかし、開発者としては、単なる機能追加以上の手応えがありました。

音が左で鳴る。 HUD の balance が左へ振れる。 視覚側の方向と合成される。 fusedDirection が滑らかに補正される。 AIKernel が、世界の向きを少しだけ理解したように見える。

この瞬間は、かなり強いものがありました。

AI に目を与えるだけでは足りません。

耳が加わることで、Perception Layer は「画面解析」から「空間認知」へ進みます。

今日の実装は、その最初の一歩です。

10. Day 2 へ：目と耳で世界を読み、自律的に動く

明日は、いよいよ実行ランタイム側へ進みます。

WASM。 WebGPU。 Bonsai 1.7B。 VRAM resident。 zero-copy。 AutoPlay。 ローカル実行。 そして、明日公開予定の Doom デモンストレーション。

今日の記事では、あえてそこには深く踏み込みませんでした。

今日見せたかったのは、AIKernel が音と視覚を使って空間を読み始めたという事実です。

明日は、その空間認知が実際の行動へ接続されるところを見せます。

スペシャルサプライズとして準備しているデモも、現時点では予定通り公開できそうです。

結語：AI は世界をどう感じるのか

「AI は電気羊の夢を見るのか？」という問いは、少し古典的で、少し詩的です。

しかし、AIKernel を作っていると、問いの形が変わってきます。

AI は夢を見るのか。 その前に、AI は世界をどう感じるのか。

今日、AIKernel は音を単なる波形ではなく、空間の手がかりとして扱い始めました。

視覚だけではなく、聴覚も使う。 波形ではなく、方向として読む。 ログではなく、HUD に投影する。 機能ではなく、Perception Layer として統合する。

これは単なる音声解析の追加ではありません。

AI が世界を理解し、次の行動へ進むための、最初の感覚器官です。

Day 1。 AIKernel に耳を与える日。

ここから、AIKernel のマルチモーダル空間認知が始まります。

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