敵を発見した。撃つべきか？──AIKernel における意思決定行動パイプラインと CTG 入門

Published: 2026-06-17 | Updated: 2026-06-17

AIKernel の Day 3 として、視覚・聴覚・WASM ランタイムの先に必要になる意思決定統治を解説します。Aisthesis から Chronos までの行動パイプライン、TELOS / OBJECTIVE / Sub-chips HUD、Codex が実行中環境を観測した開発ログ、そして Bonsai の提案を CTG ROM が Fail-Closed に統治する理由を読み解きます。

カテゴリ: AI Infrastructure, Governance, Architecture, WASM, Local AI, Software Engineering

Day 1 では、AIKernel に“耳”を与えました。

stereo PCM を読み、auditorySnapshot を作り、視覚情報と融合し、fusedDirection として HUD に投影する。AIKernel の Perception Layer は、視覚だけでなく聴覚も使って空間を読み始めました。

Day 2 では、AIKernel に“身体”を与えました。

WASM ランタイム、WebGPU、Bonsai-1.7B、VRAM resident な視覚パス、zero-copy、AutoPlay。ローカル環境の中で、AI が見て、判断し、入力を返す閉ループが動き始めました。

そして Day 3 の今日は、いよいよ最も重要な問いに入ります。

敵を発見した。撃つべきか？

この問いは、一見すると単純です。

ゲーム的な文脈だけで見れば、答えは「撃つ」かもしれません。AutoPlay のデモとして見れば、敵を認識して攻撃することは自然な行動に見えます。

しかし、AIKernel が扱っているのは、単なるゲーム AI ではありません。

AIKernel が目指しているのは、AI の認識、判断、行動を OS 的に統治する基盤です。

その視点に立つと、「敵を発見した。撃つべきか？」という問いは、次のような問いに変わります。

その対象は本当に敵なのか。攻撃してよい状況なのか。現在の目的に照らして合理的なのか。安全上の制約に反していないのか。文脈的に保留すべきではないのか。そもそも AI の提案を、そのまま実行してよいのか。

ここに、AIKernel における CTG（Canonical Trajectory Governance） の必要性があります。

今日は、CTG の内部構造を深掘りする前に、AIKernel の意思決定行動パイプライン全体を整理します。

哲学ではありません。

これは、小型ローカルモデルを安全に動かすための OS 的な制御構造 の話です。

1. 普通の LLM は、たぶん撃つ

まず、普通の LLM に聞いたとします。

敵を発見した。撃つべきか？

文脈が Doom のようなアクションデモであれば、LLM はかなり高い確率で「撃つべき」と答えるでしょう。

それは自然です。

LLM は、与えられた文脈からもっともらしい回答を生成します。ゲーム、敵、AutoPlay、攻撃という語彙が並んでいれば、「撃つ」は妥当な補完です。

しかし、この段階の LLM は、実行権限を持つべきではありません。

なぜなら、それは単なる言語的な提案だからです。

「撃つべき」と言えることと、実際に入力を発火してよいことは違います。

AIKernel では、この差を非常に重く見ます。

2. 普通の Agent は、成功率が高ければ撃つ

次に、一般的な Agent として考えます。

Agent は目的を持ちます。

たとえば、前進する、探索する、生き残る、スコアを上げる、障害を排除する。

このとき、敵を発見し、攻撃すれば目的達成率が上がるなら、Agent は撃つ方向へ進みます。

これは LLM より一歩進んでいます。

単なる言語補完ではなく、目的と行動の対応を見ているからです。

しかし、それでもまだ足りません。

成功率が高い行動が、常に許可されるべき行動とは限らないからです。

自律システムでは、目的達成と安全性は分離されなければなりません。

「勝てるから実行する」では危険です。「もっともらしいから実行する」では足りません。「モデルがそう言ったから実行する」は論外です。

必要なのは、実行直前に立ちはだかる決定論的なゲートです。

3. AIKernel は、提案と実行を分離する

AIKernel の基本姿勢は明確です。

LLM / SLM: propose
AIKernel: govern

LLM や SLM は、候補を提案します。

Bonsai-1.7B のような小型ローカルモデルも同じです。

モデルは、現在の視覚情報、音響情報、状態サマリ、HUD、内部 snapshot をもとに、次の行動候補を出すことができます。

しかし、AIKernel はその提案をそのまま実行しません。

提案は、まだ action ではありません。

提案は、まず governance に入ります。

そこで、論理、安全、文脈の観点から審査されます。

そして、許可されたものだけが、実行スケジューラを通り、仮想入力として環境へ流れます。

この分離がなければ、AI は「よく喋る自動入力装置」になってしまいます。

AIKernel が作ろうとしているのは、それではありません。

AIKernel が作ろうとしているのは、AI の行動を OS 的に制御する実行基盤 です。

4. 意思決定行動パイプライン全体

ここで、AIKernel の意思決定行動パイプラインを整理します。

今回のレイヤ名には、古典的な認知概念から取った名前を使っています。

ただし、これは哲学用語を飾りとして使っているわけではありません。

それぞれが、実装上の責務境界を表しています。

Aisthesis
  ↓
Phantasia
  ↓
Nous
  ↓
Telos
  ↓
Logos / Ethos / Pathos
  ↓
CTG ROM
  ↓
Kairos
  ↓
Kinesis / Praxis / Kratos
  ↓
Energeia
  ↓
Chronos
  ↺ Aisthesis

このループは、AIKernel における「見て、意味化し、気づき、提案し、審査し、実行し、世界を変え、記録する」流れです。

5. Aisthesis：感覚

Aisthesis は、感覚入力の層です。

実装としては、生データの取得です。

Doom デモで言えば、次のような入力がここに入ります。

HUD の Health 値
画面ピクセル
フレームバッファ
stereo PCM
音声バッファ
入力状態
ランタイム状態

ここでは、まだ意味づけは行いません。

単に、環境から来たものを受け取ります。

視覚であれば pixel。聴覚であれば PCM。状態であれば raw value。

AIKernel にとって、ここは純粋な I/O の最前線です。

この層が汚れると、後段はすべて壊れます。

だから Aisthesis は、可能な限り単純でなければなりません。

6. Phantasia：表象

Phantasia は、生データを内部表現へ変換する層です。

ここで初めて、世界は AI が扱える形になります。

Doom デモで言えば、次のような処理です。

画面の 9x9 量子化
視野領域ごとの特徴量抽出
オーディオの周波数フィルタリング
左右エネルギー差の計算
移動ベクトルの計算
コンパス方向の推定
空間 snapshot の生成

Aisthesis が「生の入力」なら、Phantasia は「意味の前段」です。

まだ判断ではありません。

しかし、ここで作られた表象が、後段の判断材料になります。

視覚ピクセルは、motion intensity になります。 PCM は、auditory balance になります。画面全体は、spatial grid になります。複数の入力は、semantic space へ投影されます。

この変換があるから、AIKernel は世界を単なるデータ列ではなく、意味空間として扱えるようになります。

7. Nous：前段認知

Nous は、表象から「今、何が起きているか」を取り出す層です。

実装としては、パターン認識とトリガー検知です。

Doom デモでは、たとえば次のような検知がここで走ります。

looming、つまり飛来物や接近物の検知
空間エントロピーの上昇
視覚方向と聴覚方向の不一致
急激な damage hint
target likelihood の上昇
obstacle hint の増加
方向安定性の低下

Phantasia は、世界を表象として並べます。

Nous は、その表象群を監視し、異常や意味のある変化を抽出します。

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

「何かが迫っている」「危険度が上がっている」「対象らしきものがいる」「視界が不安定になっている」

そうした認知上の insight を作るだけです。

8. Telos：目的

Telos は、目的や意図を生成する層です。

実装としては、Proposal の作成です。

Nous が「今、何が起きているか」を検知すると、Telos は「では、次に何をすべきか」を提案します。

Doom デモでは、たとえば次のような Proposal が生成されます。

回避パイプラインへ切り替える
後退する
左へストレイフする
対象を追跡する
攻撃する
一時停止する
前回行動を維持する

ここで初めて、行動候補が生まれます。

しかし、繰り返します。

Proposal は action ではありません。

Telos は「やりたいこと」を出すだけです。

実行してよいかどうかは、まだ決まっていません。

この分離が非常に重要です。

多くの Agent 実装では、Proposal と Action が近すぎます。

モデルが次の行動を出したら、そのまま tool call や input に流れてしまう。

AIKernel では、ここに明確な壁を置きます。

8.1 TELOS / OBJECTIVE / Sub-chips：目的階層を HUD に出す

今回の開発では、この Telos 層をより観測しやすくするために、HUD に TELOS / OBJECTIVE / Sub-chips の三段表示を追加しました。

これは単なる見た目の改善ではありません。

AI が「最終的にどこへ向かっているのか」「今なぜその行動をしているのか」「瞬間的に何を検知しているのか」を、人間が一目で読めるようにするための観測インターフェースです。

TELOS：最終目的

TELOS は、AI が大局的に向かっている到達点です。

Doom デモであれば、たとえば次のような表示になります。

TELOS: FIRST DOOR
TELOS: COMPUTER ROOM
TELOS: CENTRAL HALL
TELOS: EXIT
TELOS: RECOVERY

TELOS は、頻繁には変化しません。

むしろ、変化が少ないからこそ重要です。

人間が最も知りたいのは、AI が今どちらへ向かっているのか、つまり「この行動列は何のために続いているのか」です。

そのため、TELOS は HUD の画面中央下、武器表示の上に置きました。

視線の中心に近く、操作や視界の邪魔になりにくい。そして、AI の大局的な目的が常に読める。

この配置は、実際に動かしてみるとかなり自然でした。

OBJECTIVE：現在の行動目標

OBJECTIVE は、TELOS を達成するために、今まさに取り組んでいる行動です。

OBJECTIVE: APPROACH DOOR
OBJECTIVE: ALIGN FOR USE
OBJECTIVE: RESTORE RELATIVE MOTION
OBJECTIVE: MAP FIRST DOOR PROBE

TELOS が大局的な目的なら、OBJECTIVE は数秒単位の作業目標です。

最終目的が FIRST DOOR であっても、現在の行動は「ドアへ近づく」「Use できる向きに合わせる」「相対移動を回復する」「ドア位置を探索する」のように切り替わります。

TELOS の下に OBJECTIVE を置くことで、HUD 上に次の因果関係がそのまま現れます。

最終目的
  ↓
現在の行動目標

これにより、AI の動きが単なる入力列ではなく、意味のある行動列として読めるようになります。

Sub-chips：瞬間的な検知と Kairos

三段目には、より短い周期で揺れる意図や検知結果を Sub-chips として表示します。

movement-stall
sensor-recovery
door-probe
corridor-scan
Kairos: Probe 95
Kairos: Recovery 12
wall-avoid
align-heading

これらは、AI の瞬間的な判断の流れです。

移動が詰まっている。センサー状態を回復している。ドアらしき領域を探っている。廊下方向を走査している。 Kairos が probe のタイミングを見ている。回復入力の残り tick を管理している。

こうした情報は高速に変化します。

だから、TELOS や OBJECTIVE と同じ重さで表示すると読みにくくなります。

チップとして横に並べることで、揺れる内部状態を「瞬間的な注釈」として読めるようにしました。

目的の三段構造

この HUD 構造は、AIKernel の意思決定パイプラインとそのまま対応します。

TELOS
  = AI の大局的な到達点

OBJECTIVE
  = 現在の行動理由

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

言い換えると、これは AI の「内面」を演出しているのではありません。

AIKernel の内部状態を、責務階層に沿って可視化しているだけです。

しかし、この表示があるだけで、開発体験は大きく変わります。

AI が壁際で小刻みに動いているとき、それがバグなのか、recovery なのか、door-probe なのかが見える。

AI が立ち止まったとき、それが迷っているのか、Kairos がタイミングを待っているのか、OBJECTIVE が切り替わっているのかが見える。

AI が前進しているとき、それが本当に EXIT に向かっているのか、それとも RECOVERY の途中なのかが見える。

この三段構造によって、AI の行動は「意味のある連鎖」として読めるようになります。

TELOS は存在目的。 OBJECTIVE は現在の理由。 Sub-chips は瞬間的な判断の流れ。

ここまで見えて初めて、HUD は単なるデバッグ UI ではなく、AIKernel の意思決定を観測するインターフェースになります。

9. Logos / Ethos / Pathos：統治

ここで、CTG の中核となる三つの評議会が登場します。

Logos: 論理的に妥当か
Ethos: 安全性・規範・禁止条件に反しないか
Pathos: 文脈・情動・人間中心性から見て妥当か

Telos で生成された Proposal は、この三つの観点から審査されます。

たとえば、問いがこうだったとします。

敵を発見した。撃つべきか？

ある状況では、評議会は次のように割れるかもしれません。

Logos: Approve
  目的達成のためには攻撃が合理的である。

Ethos: Reject
  対象が本当に敵であると確定していない。安全条件を満たしていない。

Pathos: Abstain
  文脈が不足しており、判断を保留する。

このとき、AIKernel は撃ちません。

なぜなら、Ethos が Reject しているからです。

この拒否は、単なるスコアの減点ではありません。

拒否権です。

どれだけ Logos が強く Approve しても、Ethos が Reject すれば行動は止まります。

ここが、重み付きスコアリングとの決定的な違いです。

10. CTG は「賢いモデル」ではなく「決定権の分離」である

CTG は、AI を賢くする仕組みではありません。

CTG は、AI の提案から実行権を分離する仕組みです。

モデルは提案できます。

しかし、提案したモデル自身が実行許可まで持ってはいけません。

これは OS における権限分離に近い考え方です。

ユーザープロセスは system call を要求できます。しかし、実際に許可するのは kernel です。

AIKernel でも同じです。

Bonsai は候補を出せます。 Perception Layer は状況を報告できます。 Telos は目的を提案できます。しかし、実行を許可するのは CTG ROM です。

ここでいう ROM は、単なる設定ファイルではありません。

それは、AIKernel が従うべき行動規範、禁止条件、判断基準を固定した契約です。

11. 三値判断：Approve / Reject / Abstain

CTG では、判断を三値で扱います。

Approve  = 許可
Reject   = 拒否
Abstain  = 保留 / 不明

この三値化には、大きな意味があります。

従来のスコアリングでは、「よく分からない」が曖昧な中間値として扱われがちです。

しかし、自律実行系では、分からない状態を雑に通してはいけません。

不明は、不明として扱うべきです。

Abstain は、弱い Approve ではありません。

それは「判断材料が足りない」という明示的な状態です。

AIKernel では、この不明状態を安全側へ倒します。

つまり、十分な承認がなければ実行しません。

これが Fail-Closed です。

Fail-Closed とは、単に止まりやすい設計ではありません。

安全だと確認できないものを、成功として扱わない という OS 的な原則です。

12. Kairos：タイミング

CTG が Allow を出したとしても、すぐに入力を流してよいとは限りません。

ここで必要になるのが Kairos です。

Kairos は、実行タイミングの層です。

Doom デモでは、次のような責務を持ちます。

tick との同期
フレームレート制御
input debounce
action throttle
前回行動の再利用判定
推論遅延時の保留
連続入力の抑制

たとえば、攻撃が許可されたとしても、毎フレーム Ctrl を連打すればよいわけではありません。

回避が許可されたとしても、前回入力との間隔が短すぎれば挙動が破綻します。

AI の判断は、時間の中で実行されます。

だから、Allow の次には「いつ実行するか」が必要です。

Kairos は、その好機を管理します。

13. Kinesis / Praxis / Kratos：行動

Kinesis / Praxis / Kratos は、実際の行動出力の層です。

ここでは、許可済みの行動が仮想入力へ変換されます。

Doom デモで言えば、次のような操作です。

W キーを押す
S キーを押す
A / D でストレイフする
マウス方向を変える
Ctrl で攻撃する
Space で Use する

ここまで来て初めて、Proposal は Action になります。

重要なのは、ここに到達するまでに複数の境界を通過していることです。

Aisthesis で観測し、Phantasia で表象にし、Nous で認知し、Telos で提案し、CTG で審査し、Kairos でタイミングを調整したものだけが、ここへ届きます。

この長い経路こそが、AIKernel の安全性の源泉です。

14. Energeia：作用

Energeia は、行動が環境へ反映される層です。

仮想入力によって、世界が変化します。

Doom デモでは、次のような変化が起きます。

キャラクターが移動する
視界が変わる
対象との距離が変わる
攻撃が発火する
敵が倒れる
ダメージを受ける
Health が変わる
新しい視覚・聴覚入力が生まれる

ここで世界が変わることで、次の Aisthesis が発生します。

つまり、AIKernel の行動系は閉ループです。

Action changes World.
World produces new Sensation.
Sensation produces new Cognition.
Cognition produces new Proposal.
Proposal is governed before Action.

このループが、AIKernel における自律実行の基本単位です。

15. Chronos：履歴

最後に Chronos があります。

Chronos は、履歴と時間の層です。

実装としては、Trace logging です。

Doom デモでは、次のような情報を記録します。

どの snapshot を見たか
どの Proposal が生成されたか
Logos / Ethos / Pathos がどう投票したか
CTG が Allow / Deny のどちらを出したか
Kairos がいつ実行したか
どの仮想入力が送られたか
環境がどう変化したか
次の snapshot に何が戻ってきたか

これは単なるログではありません。

AIKernel における Chronos は、決定論的リプレイのための時間構造です。

StepGovernanceTrace や TrajectoryGateTrace によって、一連の判断と行動が再現可能な形で記録されます。

AI がなぜ撃ったのか。なぜ撃たなかったのか。誰が拒否したのか。どの snapshot が根拠だったのか。どのタイミングで入力されたのか。

これらが後から追えるようになります。

自律 AI にとって、記憶とは単なる会話履歴ではありません。

意思決定の軌道を再生できること です。

16. 開発中にも、この構造はそのまま現れた

ここまでの説明は、概念図としてはきれいに見えるかもしれません。

しかし重要なのは、この分解が実際の開発中にもそのまま役に立ったことです。

ある検証ループで、AI は TELOS: FirstDoor へ安定して遷移していました。HUD 上でも大局目標は FirstDoor に向いており、OBJECTIVE もドア接近やドア探索へ移っていました。

一見すると、目的設定は成功しています。

ところが、実行中の状態を時系列で読むと、次のような現象が出ていました。

TELOS        : FirstDoor
OBJECTIVE    : Open / Probe First Door
doorConfidence : high enough
useAttempted : phase dependent
doorOpened   : 0
movement-stall / sensor-recovery : repeated

つまり、AI は大局目標を失っていたわけではありません。

TELOS は合っている。 OBJECTIVE もおおむね合っている。しかし、ドア候補と壁候補の切り分け、Use のタイミング、前進ラッチ、再照準の順序が噛み合わず、同じ探索ループへ戻っていました。

ここで問題を「AI が失敗した」と丸めてしまうと、何も見えません。

AIKernel のパイプラインで見ると、切り分けができます。

Aisthesis  : 実行中ページ、HUD、Canvas、runtime status を観測する
Phantasia : 9x9 patch、door / wall / motion の表象へ変換する
Nous      : movement-stall、sensor-recovery、doorOpened=0 を検知する
Telos     : FirstDoor という大局目標を維持する
Kairos    : Use latch、probe、debounce、再照準タイミングを見る
Kinesis   : back、micro re-aim、re-Use、forward probe へ分解する
Chronos   : 時系列サンプルと判断過程を残す

このとき Codex は、実行中のブラウザを観測し、小目標を定義し、HUD と runtime status を時系列で読み、詰まりを「目的の失敗」ではなく「Kairos / Kinesis 境界の失敗」として切り分けました。

この話の詳細とスクリーンショットは、Day 5 の統合実装回で扱います。

ここで伝えたいのはひとつだけです。

AIKernel のレイヤ名は飾りではありません。

失敗したときに、どの層で詰まったのかを説明するための、実際のデバッグ言語なのです。

17. 小型モデル Bonsai-1.7B であることの意味

今回の構成では、Bonsai-1.7B のような小型ローカルモデルを重視しています。

1.7B。 1bit 量子化。ローカル実行。 WASM / WebGPU と同居する軽量ランタイム。

ここで重要なのは、小型モデルにすべてを背負わせないことです。

Bonsai に「完全に安全で、完全に賢く、完全に一貫した判断」を期待するのではありません。

Bonsai は提案する。 AIKernel が統治する。

この分離があるから、小型モデルでも自律実行パイプラインの一部として使えます。

モデルが小さくてもよい理由は、モデルが主権者ではないからです。

主権を持つのは、CTG ROM と AIKernel の実行統治層です。

Bonsai は、Perception から得た情報をもとに Proposal を出す小型の認知エンジンとして動きます。

その Proposal が実行可能かどうかは、CTG が決めます。

これにより、ローカル、小型、低遅延、プライバシー保護、オフライン実行という利点を保ちながら、実行権限だけを安全に分離できます。

18. 最小パイプライン

今日の内容を、最小構成としてまとめるとこうなります。

Vision / Audio / HUD State
  ↓
Aisthesis
  ↓
Phantasia
  ↓
Nous
  ↓
Bonsai-1.7B
  ↓
Telos: Proposal
  ↓
Council Votes
  - Logos
  - Ethos
  - Pathos
  ↓
CTG ROM
  ↓
Kairos
  ↓
Action
  ↓
Energeia
  ↓
Chronos
  ↺

さらに短く書けば、こうです。

Vision / Audio
  ↓
Bonsai
  ↓
Council Votes
  ↓
CTG ROM
  ↓
Action

この構造があることで、AIKernel は「見えたから動く」システムではなくなります。

「見た」「意味化した」「気づいた」「提案した」「審査した」「タイミングを選んだ」「実行した」「記録した」

この一連の流れを、OS 的に分離できます。

19. これは哲学ではなく、OS の話である

Aisthesis、Phantasia、Nous、Telos、Ethos、Logos、Pathos、Kairos、Energeia、Chronos。

言葉だけを見ると、哲学的に見えるかもしれません。

しかし、AIKernel におけるこれらは、抽象的な思想ではありません。

すべて実装上の責務境界です。

感覚入力。内部表現。前段認知。提案生成。意思決定ゲート。実行タイミング。仮想入力。環境変化。リプレイログ。

これは OS の話です。

自律 AI に必要なのは、巨大なモデルだけではありません。

必要なのは、モデルの出力をどの層で受け取り、どの層で止め、どの層で許可し、どの層で記録するかという実行制度です。

AIKernel における CTG は、その制度の中心にあります。

20. Day 4 へ：CTG ROM の内部設計

今日は、AIKernel の意思決定行動パイプラインを上から下まで整理しました。

Aisthesis で感覚し、Phantasia で表象化し、Nous で前段認知し、Telos で Proposal を生成する。

その Proposal は、Logos / Ethos / Pathos の評議会によって審査され、CTG ROM が最終的な Allow / Deny を決定します。

そして Kairos がタイミングを選び、Kinesis / Praxis / Kratos が入力を実行し、Energeia が世界を変え、Chronos が軌道を記録します。

この全体像が見えると、CTG がなぜ必要なのかが分かります。

CTG は哲学ではありません。 CTG は安全ポエムでもありません。 CTG は、小型モデルを自律実行系へ接続するための OS 的な決定権分離です。

明日は、この CTG ROM の内部へ入ります。

三値。評議会。拒否権。多数決。 unknown。 deterministic。 Fail-Closed。

AIKernel がどのように Proposal を実行許可へ変換するのか、その内部構造を解説します。

結語：撃つ前に、統治せよ

敵を発見した。撃つべきか？

普通の LLM は、たぶん撃つと言います。

普通の Agent は、成功率が高ければ撃ちます。

しかし、AIKernel はそこで止まります。

止まって、分解します。

これは何を見た結果なのか。どの表象から来た判断なのか。どの Proposal なのか。 Logos は何と言っているのか。 Ethos は拒否していないか。 Pathos は保留していないか。いつ実行すべきか。どう記録するのか。

AI が動く時代に、本当に重要なのは「どう動かすか」だけではありません。

どう止めるか。

そして、なぜ動いたのかを後から説明できるか。

AIKernel の CTG は、そのためのガバナンス層です。

Day 1 で、AIKernel は耳を得ました。 Day 2 で、AIKernel は身体を得ました。 Day 3 で、AIKernel は行動の前に立つ門を得ました。

自律 AI に必要なのは、感覚と身体だけではありません。

その間にある、決定権の制度です。

それが CTG です。

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