AIOS の視覚認知モジュールを作る──Perception Layer の設計・実装・最適化・可視化・デバッグ研究ログ
AIOS における Perception Layer の役割を、Trainer Runtime / Profile Optimizer / Inference Runtime の三層構造、Telemetry、Profile 駆動最適化、リアルタイム HUD、Perception Filter、Hybrid Control Mode の実装体験を通じて解説します。
カテゴリ: Architecture, AI Infrastructure, Robotics, AR HUD, Developer Experience, Software Engineering
AIOS（AI Operating System）を作っていると、ある瞬間から「AI に何を考えさせるか」よりも、AI が何を見ているのかを、どう観測するか の方が重要になります。
認識できていないものは判断できません。 判断できていないものは行動できません。 そして、観測できない認識はデバッグできません。
今日のテーマは、AIOS における 視覚認知モジュール（Perception Layer） です。
この記事では、AIOS の三層構造を前提に、Perception Layer の設計、実装、最適化、HUD 可視化、そして開発中に実際に踏んだ落とし穴を、研究ログとしてまとめます。
ここで扱う内容は、特定のアプリケーションやドメインに閉じた話ではありません。
ロボティクス、AR HUD、遠隔操作 UI、サイバネティック UI、Web / WASM / GPU ベースの推論ランタイムなど、AI が外界を認識し、意図を形成し、行動へ接続するシステム 全般に通じる設計の話です。
1. AIOS の三層構造
まず、読者が迷わないように、AIOS の前提を整理しておきます。
AIOS は大きく見ると、次の三層で構成されます。
Trainer Runtime
→ Telemetry
→ Profile Optimizer
→ JSON Profile
→ Inference Runtimeこの構造の本質は、実行、観測、最適化、推論を分離すること です。
行動ロジックを毎回書き換えるのではありません。 まず実行し、失敗を観測し、その失敗から profile を更新し、推論ランタイムへ戻す。
AIOS は、このループによって成長します。
Trainer Runtime：失敗を記録するネイティブ環境
Trainer Runtime は、高速実行と Telemetry 収集を担当するネイティブ環境です。
ここでは、AI の行動を何度も走らせます。
成功したか。 失敗したか。 どこで詰まったか。 どの方向合わせがズレたか。 どのタイミングで回避が遅れたか。 なぜ同じ行動を繰り返したのか。
こうした情報を Telemetry として記録します。
開発初期、私は何度も「行動そのものは書けているはずなのに、なぜか安定しない」という状態に遭遇しました。
障害物の近くで引っかかる。 方向合わせが数度だけズレる。 目的地に向かっているように見えて、実際には小さな旋回ループに入っている。 安全側に倒したつもりの回避が、逆に別の不安定性を生む。
最初は、目視で直せると思っていました。
しかし、目視だけでは無理でした。
失敗は一瞬で起きます。 しかも、同じ失敗に見えても原因が違うことがあります。
方向合わせの問題なのか。 障害物検知の問題なのか。 目標選択の問題なのか。 緊急回避の閾値が低すぎるのか。 それとも、単に状態遷移の同期がズレているのか。
この段階で、Telemetry の重要性が骨身に染みました。
失敗をログに残すというより、失敗に名前を与える ために Telemetry が必要だったのです。
Profile Optimizer：コードではなく profile を進化させる外部学習器
Profile Optimizer は、Trainer Runtime から得られた Telemetry を解析し、外部 JSON profile を更新します。
ここで重要なのは、最適化対象がコードではないことです。
行動ロジックの骨格は固定します。 そのうえで、調整可能なパラメータだけを profile として外に出します。
たとえば、次のような値です。
{
"alignment": {
"yawToleranceDeg": 8.0,
"stabilityFrames": 5
},
"avoidance": {
"nearObstacleWeight": 1.35,
"emergencyEscapeThreshold": 0.84
},
"priority": {
"targetTracking": 0.72,
"safeNavigation": 0.91
}
}これはあくまで抽象化した例ですが、思想は同じです。
コードは「何をするか」を定義する。 profile は「どの程度そうするか」を定義する。
最初は、最適化しても改善が見えませんでした。
パラメータを変えているのに、挙動がふらつく。 少し良くなったと思ったら、別の場面で悪化する。 Fitness の数字だけを見ると改善しているように見えるのに、実際の行動は信用できない。
かなり苦戦しました。
ところが、ある閾値を超えた瞬間に、急に行動が安定し始めました。
方向合わせが静かになる。 障害物に対する反応が早くなる。 無駄なループが減る。 同じコードなのに、動きの質が変わる。
このときの衝撃は大きかったです。
コードを触らずに、行動だけが変わる。
これは単なる設定ファイルの便利さではありません。
AIOS において profile は、学習済みの行動規範です。
Inference Runtime：学習済み profile を読み込む Web / WASM / GPU 実行層
Inference Runtime は、最適化済み profile を読み込んで実行する層です。
想定する環境は、Web、WASM、GPU、Worker ベースの非同期実行環境です。
この層では、基本的に再ビルドは不要です。
コードは固定されたまま、profile を差し替えるだけで行動が変わります。
もちろん、現実はきれいな話だけではありません。
Worker 間の同期がズレる。 GPU の初期化タイミングと UI 更新の順序が噛み合わない。 profile は読み込まれているのに、古い状態が一部に残る。 視覚認知の更新周期と HUD の描画周期が微妙にズレる。
このあたりではかなりハマりました。
それでも、profile だけを差し替えて Web 側の挙動が変わった瞬間は、かなり気持ちがいい。
ネイティブ環境で訓練し、外部 Optimizer が profile を磨き、Web / WASM / GPU 側がそれを読み込んで推論する。
この流れがつながった瞬間、AIOS が単なる実験ではなく、最適化パイプラインを持った実行基盤 になった感覚がありました。
2. Perception Layer の目的
AIOS の行動系は、大きく見ると次の三段階に分けられます。
Perception → Decision → ActionPerception Layer は、この最初の層です。
つまり、AIOS にとっての「目」であり、「前庭感覚」であり、「環境を意味ある特徴量へ変換する膜」です。
ただ画面やセンサー入力を受け取るだけではありません。
Perception Layer は、外界を AI が扱える特徴へ変換します。
- どこに動きがあるのか。
- どこに構造物があるのか。
- どこが進行を妨げる障害物なのか。
- どこに対象候補があるのか。
- どの領域の saliency が高いのか。
- 足場や接地面は安定しているのか。
- HUD や情報パネルとして扱うべき領域はどこか。
この層の品質が低いと、その後の Decision Layer は簡単に崩れます。
認識が揺れていれば、判断も揺れます。 判断が揺れれば、Action は不安定になります。 Action が不安定になれば、Telemetry はノイズだらけになります。 Telemetry が汚れれば、Profile Optimizer も間違った方向へ進みます。
つまり、Perception Layer は単なる入力処理ではありません。
AIOS 全体の最適化ループの入口です。
3. なぜ可視化が必要なのか
Perception Layer を作っていて、最も強く感じたことがあります。
AI の認識は、見えなければ直せない。
ログだけでも足りません。 数値だけでも足りません。 最終的な行動結果だけでも足りません。
たとえば、AI が障害物を避けなかったとします。
その原因は、少なくとも複数あります。
- そもそも障害物として認識していなかった。
- 認識はしていたが、危険度が低く評価されていた。
- 危険度は高かったが、別の目的関数が優先された。
- 回避判断は出ていたが、Action Layer へ伝播していなかった。
- HUD には表示されていたが、内部状態は別の値だった。
これらは、行動結果だけを見ても分かりません。
だから HUD が必要になります。
リアルタイム HUD は、単なる見た目の演出ではありません。
それは、AI の内部状態を人間が読める形へ投影する 認知デバッガ です。
Perception Overlay、Spatial Partition Grid、Target Tracking Indicator、Objective Function Panel、Perception Filters。
これらはすべて、AIOS の脳内で起きていることを外部化するための観測面です。
少し SF 的に言えば、これはサイバネティック認知 HUD です。
ただし、目的はロマンではありません。
目的は、デバッグできる AI を作ることです。
4. 今日の実装内容
今回の実装では、Perception Layer を中心に、AIOS の可視化・制御・デバッグのための機能をまとめて強化しました。
大きな変更点は次の七つです。
4.1 AI–Human ハイブリッド制御（Hybrid Control Mode）
まず実装したのは、AI–Human ハイブリッド制御 です。
これは、AI と人間の入力責務をランタイムで分解する制御モードです。
AI が担当するのは、認識、判断、対象へのアクション発火、インタラクションです。
人間が担当するのは、移動、旋回、横移動などの身体的なナビゲーションです。
AI
- perceive
- decide
- target-directed action
- interact
Human
- locomotion
- orientation
- lateral controlこの分解は、見た目より難しいものでした。
入力を分けるだけなら簡単に見えます。
しかし実際には、入力アクションが互いに影響し合います。
AI が対象に向けてアクションを発火したい。 人間はその瞬間に向きを変えている。 Worker は前フレームの状態をまだ持っている。 UI は切替済みと表示しているが、内部の制御ループはまだ古いモードで動いている。
一度、入力分解で制御が壊れかけました。
AI 側の制御を切ったつもりなのに、一部のアクションだけ残る。 UI では Hybrid Mode が有効に見えるのに、Worker 側では反映されていない。 CLI から切り替えると動くが、UI から切り替えると反応しない。
原因は、Worker との同期漏れでした。
状態をひとつの UI フラグとして扱っていたのが甘かった。
実際には、Hybrid Control Mode は UI 状態ではなく、ランタイム制御契約 として扱う必要がありました。
CLI と UI の両方から切り替えられるようにし、Worker 側にも明示的に状態を伝播させることで、ようやく安定しました。
動いた瞬間はかなり強烈でした。
人間が移動と旋回を担い、AI が認識と判断とアクションを担う。
その分担が破綻せずに成立したとき、単なる自動化ではなく、AI と人間が同じ制御面を共有している 感覚がありました。
4.2 Perception Overlay をデフォルト ON にする
次に、視覚認知オーバーレイを起動直後から ON にしました。
これは小さな変更に見えます。
しかし、デバッグ効率への効果は非常に大きいものでした。
以前は、毎回手動で overlay を有効化してから確認していました。
起動する。 ボタンを押す。 状態を見る。 調整する。 再読み込みする。 またボタンを押す。
この手間は、一回だけなら小さい。
しかし、Perception Layer の調整では、このループを何十回、何百回も回します。
デフォルト ON にしただけで、調整のリズムが変わりました。
起動した瞬間から認知情報が見える。 失敗した瞬間の状態を見逃さない。 再現確認のたびに余計な操作を挟まない。
これだけで、思考が途切れなくなります。
開発体験としては地味ですが、効果は大きい。
認知系のデバッグでは、観測面は最初から開いているべき です。
4.3 Spatial Partition Grid と動的特徴量の可視化
Perception Layer の中核として、視野を 3×3 の Spatial Partition Grid に分割しました。
+-----+-----+-----+
| NW | N | NE |
+-----+-----+-----+
| W | C | E |
+-----+-----+-----+
| SW | S | SE |
+-----+-----+-----+各セルには、複数の動的特徴量を表示します。
- motion intensity
- dynamic score
- saliency
- obstacle hint
- structure response
- target likelihood
この実装で一度、HUD が崩壊しかけました。
情報量が多すぎたのです。
数値を出したい。 カテゴリも出したい。 セルごとの状態も見たい。 重要領域は強調したい。 障害物は別色にしたい。 ターゲット候補も残したい。
全部を一気に表示すると、視認性が死にます。
Perception Layer の可視化で難しいのは、情報を出すことではありません。
見える情報量に圧縮すること です。
最終的には、色分け、行間、ラベルの短縮、セル内レイアウトの調整によって、なんとか読める HUD に戻しました。
このとき、少し鳥肌が立つ瞬間がありました。
3×3 の各領域に motion intensity と saliency が流れ、動的スコアが変化し、AI がどの領域を強く見ているのかが分かる。
まるで AI の脳内テンソルが、HUD 上に投影されているように見えました。
もちろん、実際にはテンソルそのものを見ているわけではありません。
しかし、Perception Layer が抽出した特徴場を、人間が直感的に読める形にした瞬間、認知システムは急に「触れるもの」になります。
4.4 Target Tracking Indicator
対象追跡インジケータも追加しました。
対象物を検知したとき、HUD 上にカードを表示し、対象位置に円形のロックリングを出します。
ロック強度に応じて、リングの表示を変化させます。
- 低信頼: 弱いリング
- 中信頼: 安定したリング
- 高信頼: 強調されたロック表示
- ロスト: フェードアウト
この表示は、想像以上に有効でした。
AI が何を対象として見ているのかが、一目で分かるからです。
一方で、非同期バグも出ました。
対象はすでに失われているのに、リングだけが残る。
いわゆる「幽霊リング」です。
原因は race condition でした。
検知状態の更新、HUD の描画、Worker からの状態反映が、わずかにズレていました。
あるフレームでは対象が存在する。 次のフレームでは対象が消える。 しかし HUD は前の状態を参照してリングを描画する。
これが幽霊リングの正体でした。
修正後は、没入感が一気に上がりました。
対象が現れる。 ロックが強まる。 失われると自然に消える。
この連続性が出るだけで、HUD は単なるデバッグ表示ではなく、AIOS の認知面そのものに見えてきます。
4.5 Objective Function の可視化
Perception Layer の表示に加えて、AI の目的関数も中央パネルへ表示しました。
これは、AI の「意図」を読むための表示です。
Perception が「何を見ているか」なら、Objective Function は「何を優先しているか」を示します。
- 探索しているのか。
- 対象を追跡しているのか。
- 障害物回避を優先しているのか。
- 安全な位置取りを維持しているのか。
- 緊急回避に入っているのか。
この表示があると、状態遷移が非常に理解しやすくなります。
ただし、ここでも一度混乱しました。
ログでは目的関数が切り替わっている。 しかし HUD では前の目的が表示されている。
このズレがあると、開発者は一気に信用を失います。
AI が間違っているのか。 ログが間違っているのか。 HUD が遅延しているのか。
原因を追っていくと、ログと HUD が別々の更新タイミングを見ていました。
そこで、Objective Function の状態を、Telemetry と HUD で同じソースから参照するように整理しました。
同期させた瞬間、一気に理解しやすくなりました。
この経験から、ひとつの原則がはっきりしました。
デバッグ HUD は、ログと同じ真実を見ていなければならない。
見た目が美しくても、内部状態とズレていれば、それは観測ではなく幻影です。
4.6 Perception Filters
認知フィルタも導入しました。
カテゴリごとに表示を ON / OFF できる仕組みです。
- Motion
- Structure
- Obstacle
- Target
- InfoPanel
- Footing
- HUD
この機能は、問題の切り分けに非常に効きました。
以前は、Motion と Structure と Obstacle の反応が混ざって見えていました。
動きに反応しているのか。 構造物に反応しているのか。 障害物として誤検知しているのか。
見た目だけでは判断しづらい場面がありました。
特に、Motion と境界面検出が混ざると厄介です。
動的な対象だと思って追っているのか。 静的な構造物を障害物として見ているのか。 それとも、その両方が同じ領域で重なっているのか。
フィルタを入れたことで、原因が一発で分かる場面が増えました。
Motion だけを見る。 Obstacle だけを見る。 Target だけを見る。 Footing だけを見る。
カテゴリごとに認知を分解できると、Perception Layer のデバッグは急に楽になります。
AI の視覚認知は一枚絵ではありません。
複数の意味レイヤーが重なった合成像です。
Perception Filters は、その合成像を分解するためのレンズです。
4.7 CSS / UI 調整とキャッシュバスター
最後に、CSS と UI も調整しました。
壁回避、より一般化して言えば 障害物・境界面回避 に専用色を割り当てました。
認知強調表現も追加し、重要な領域が視線に入りやすいようにしました。
ここでも地味な罠がありました。
CSS を変えたのに、色が反映されない。
コードを見ても正しい。 クラス名も合っている。 DOM にも反映されている。 なのに、表示だけが古い。
原因はキャッシュでした。
古い CSS が残っていたのです。
キャッシュバスターを更新したら、即座に直りました。
こういう問題は技術的には小さいのですが、認知 HUD の開発ではかなり痛い。
色が変わらないだけで、Perception の出力が間違っているように見えてしまうからです。
UI は単なる飾りではありません。
AIOS において UI は観測装置です。
観測装置が古い状態を表示していると、開発者は間違った仮説を立てます。
だから、CSS のキャッシュひとつでも、認知系ではデバッグ対象になります。
5. Profile 駆動の最適化
今回の開発で改めて確信したのは、行動ロジックと行動パラメータは分けるべきだ ということです。
行動ロジックはコードとして固定します。
- 認識する。
- 判断する。
- 優先度を計算する。
- 危険度を評価する。
- 回避する。
- 対象を追跡する。
- アクションを発火する。
この構造そのものを、毎回変更してはいけません。
一方で、次のような値は profile として外部化します。
- 方向合わせの許容角度
- 近接時の回避強度
- 行動優先度
- 緊急回避の閾値
- saliency の重み
- target lock の最低信頼度
- motion intensity の平滑化係数
- obstacle 判定の持続フレーム数
これらは、環境や目的によって最適値が変わります。
だからコードに埋め込むべきではありません。
開発中、パラメータを外に出した瞬間から、改善速度が一気に上がりました。
コードを編集する。 ビルドする。 デプロイする。 確認する。
このサイクルでは遅すぎます。
profile を編集する。 読み込ませる。 挙動を見る。
このサイクルになると、試行回数が増えます。
試行回数が増えると、Telemetry が増えます。
Telemetry が増えると、Optimizer が改善しやすくなります。
ここで初めて、AIOS の開発は「実装」から「訓練」に近づきます。
もちろん、何でも profile に出せばよいわけではありません。
構造的な責務まで profile 化すると、逆に意味論が崩れます。
profile に出すべきなのは、方針の形ではなく、方針の強度 です。
この境界を守ることが重要です。
6. 最適化ループの流れ
AIOS の最適化ループは、抽象化すると次のようになります。
1. Native Trainer Runtime で episode を実行
2. 行動結果と内部状態を Telemetry として収集
3. Fitness を計算
4. Profile Optimizer が JSON profile を更新
5. profile を Inference Runtime へデプロイ
6. Web / WASM / GPU 側は profile を読み込むだけで推論
7. 挙動を観測し、再び Telemetry へ戻すこのループの美しさは、各層の責務が分かれている点にあります。
Trainer Runtime は、失敗を集める。 Profile Optimizer は、失敗からパラメータを更新する。 Inference Runtime は、学習済み profile を実行する。 Perception Layer は、外界を特徴量へ変換する。 HUD は、その認知状態を人間に見える形へ投影する。
ある時点で、このループが本当に回り始めました。
ネイティブ環境で得た Telemetry から profile が更新される。 その profile を Web 側へ渡す。 再ビルドせずに挙動が変わる。 HUD で Perception の状態が見える。 Objective Function の遷移も追える。 失敗したらまた Telemetry に戻せる。
この瞬間、かなりはっきりと感じました。
AIOS の最適化パイプラインが完成した。
もちろん、完成といっても最終形ではありません。
むしろ、ようやく本格的に回せる段階に入った、という意味です。
しかし、基盤としてのループはつながりました。
ここから先は、勘ではなく、Telemetry と profile と HUD によって改善できます。
7. デバッグで得た設計原則
今回の実装から得た原則を整理すると、次のようになります。
7.1 観測はデフォルト ON にする
認知系の overlay は、必要になってから開くものではありません。
最初から開いておくべきです。
失敗は突然起きます。
その瞬間に overlay が OFF なら、最も重要な情報を逃します。
7.2 HUD と Telemetry は同じ真実を見る
HUD とログが別の状態を参照していると、デバッグは破綻します。
人間は HUD を信じます。 Optimizer は Telemetry を信じます。 AIOS は内部状態を信じます。
この三つがズレると、改善は進みません。
だから、表示、ログ、内部状態の参照元を揃える必要があります。
7.3 認知はカテゴリごとに分解できるようにする
Perception Layer は、複数の意味レイヤーを重ねたものです。
Motion、Structure、Obstacle、Target、InfoPanel、Footing、HUD。
これらを一枚に合成した表示だけでは、原因の切り分けが難しくなります。
カテゴリごとの ON / OFF は、単なる便利機能ではありません。
それは、認知デバッグのための分解能です。
7.4 profile に出すのは「構造」ではなく「強度」
コードは構造を定義します。
profile は強度を定義します。
この境界を守ると、最適化は安定します。
逆に、構造そのものを profile 側へ逃がしすぎると、何が正しい行動ロジックなのか分からなくなります。
Profile Optimizer は、コードの代替ではありません。
設計済みの行動規範を、環境へ適応させるための外部学習器です。
7.5 非同期境界は、常に疑う
Worker、GPU、WASM、UI、Telemetry、HUD。
これらが絡むと、状態は簡単にズレます。
表示は新しい。 内部状態は古い。 Worker は前フレームを見ている。 GPU 側の処理はまだ戻っていない。 profile は更新済みだが、一部のキャッシュが古い。
こうしたズレは、認知系では致命的です。
Perception Layer のデバッグでは、アルゴリズムだけでなく、同期境界そのもの を観測対象にする必要があります。
8. Perception Layer は AIOS の「目」ではなく「観測契約」である
Perception Layer を単なる視覚入力処理として見ると、本質を見誤ります。
これは、AIOS にとっての観測契約です。
外界から何を取り出すのか。 どの特徴量を信頼するのか。 どの状態を HUD に表示するのか。 どの値を Telemetry として残すのか。 どの情報を Decision Layer へ渡すのか。 どの不確実性を profile 最適化へ戻すのか。
この契約が曖昧だと、AIOS は自分が何を見ているのか分からなくなります。
逆に、この契約が明確だと、認識、判断、行動、Telemetry、profile 最適化が一本の線でつながります。
今回実装した HUD は、その契約を可視化するための装置でした。
3×3 の Spatial Partition Grid。 対象追跡リング。 Objective Function Panel。 Perception Filters。 障害物回避の強調色。 Hybrid Control Mode の状態表示。
これらはすべて、AIOS が外界をどう意味づけているかを、人間が読める形へ変換するためのものです。
まとめ：見える AI は、直せる AI である
今回の実装で、AIOS の Perception Layer は大きく前進しました。
AI–Human ハイブリッド制御によって、人間と AI の入力責務を分離できました。
Perception Overlay をデフォルト ON にしたことで、調整ループが高速化しました。
Spatial Partition Grid によって、視野内の動的特徴量を領域ごとに読めるようになりました。
Target Tracking Indicator によって、AI が何を対象として見ているかを直感的に把握できるようになりました。
Objective Function の可視化によって、AI の意図と状態遷移を追えるようになりました。
Perception Filters によって、誤検知の原因をカテゴリ単位で切り分けられるようになりました。
そして、CSS / UI / キャッシュバスターの調整を通じて、観測装置としての HUD の信頼性も上がりました。
結局のところ、Perception Layer の実装で一番大切なのは、華やかな認識アルゴリズムだけではありません。
大切なのは、AI が何を見ているのかを、人間が検証できることです。
見えない AI は、直せません。
見える AI は、直せます。
Telemetry が失敗を記録し、Profile Optimizer が行動規範を磨き、Inference Runtime が profile を読み込み、HUD が認知を可視化する。
このループが回り始めたとき、AIOS はただの推論ランタイムではなくなります。
それは、自分の認知を観測し、自分の行動を修正し、人間と同じ制御面で協調するための OS 的基盤になります。
Perception Layer は、その入口です。
AIOS の目であり、神経であり、そして開発者が AI の内部世界へ触れるための最初の窓です。
AIKernel.NET は Bing Webmaster Tools / IndexNow に対応しています。
記事更新は検索エンジンへ即時通知され、最新情報が迅速にインデックスされます。