CTG ROM の内部設計──Topos、三値評議会、Unknown、そして決定論的ゲート

AIKernel Day 4 として、CTG ROM の内部設計を最新実装に合わせて解説します。Topos による Logos / Ethos / Pathos の 3 ベクトル合成、CTG による三値評議会、Ethos 拒否権、2-of-3 承認定足数、Pathos の danger / stuck / stall-wall-follow 分離、Unknown の Fail-Closed、決定論的リプレイを整理します。

• AIKernel
• AIKernel.NET
• CTG
• CTG ROM
• Canonical Trajectory Governance
• Topos
• Trivalent Logic
• Logos
• Ethos
• Pathos
• Fail-Closed
• Deterministic Replay
• Replay LOG
• AI Operating System
• Bonsai 1 7B
• Doom Demo

カテゴリ: AI Infrastructure, Governance, Architecture, Formal Methods, Software Engineering

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

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

Day 2 では、WASM、WebGPU、Bonsai-1.7B、zero-copy、AutoPlay によって、AIKernel に“身体”を与えました。

Day 3 では、その身体が勝手に動かないようにするための、意思決定行動パイプラインを整理しました。

Aisthesis。 Phantasia。 Nous。 Telos。 Logos / Ethos / Pathos。 Kairos。 Kinesis。 Energeia。 Chronos。

今日は、その中心にある CTG ROM の内部へ入ります。

ただし、Day 4 の記事を書き始めた時点から、実装はさらに一段進みました。

当初は、Logos / Ethos / Pathos を三つの評議会として説明し、CTG ROM を最終許可ゲートとして整理していました。

この説明は今でも正しいです。

しかし最新の実装では、その前段に Topos という意図合成層が明確に現れています。

つまり、現在の AIKernel の意思決定は、次の二層構造として見るのが最も正確です。

Topos = 意図ベクトルの合成
CTG   = 行動許可の審査

Topos は、Logos / Ethos / Pathos から来る三つの方向性を合成し、「いま何が支配的な意図なのか」を決めます。

CTG は、その意図から生成された Proposal を、実行してよいかどうか三値評議会で審査します。

この二層構造が入ったことで、AIKernel の意思決定 OS は、単なる理論ではなく、実装上の責務境界としてかなりはっきり見えるようになりました。

1. CTG ROM は「人格」ではなく「実行契約」である

ROM という言葉を使うと、AI の人格や性格のようなものを想像するかもしれません。

もちろん、AIKernel において ROM は振る舞いの一貫性を担います。

しかし、CTG ROM の本質は、ふわっとした人格ではありません。

それは 実行契約 です。

何を目的としてよいのか。 何を絶対にしてはいけないのか。 どの条件なら行動を許可するのか。 どの条件なら保留するのか。 どの条件なら拒否するのか。 誰が拒否権を持つのか。 判断不能な状態をどう扱うのか。

これらを、実行時に書き換えられない正典として固定する。

それが CTG ROM です。

AIKernel では、Bonsai-1.7B のような小型モデルが Proposal を出すことはできます。

しかし、その Proposal はまだ action ではありません。

Action になる前に、Topos によって意図として整理され、CTG ROM が定義したゲートを通過する必要があります。

この構造は、OS の permission check に近いものです。

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

AI も同じです。

モデルは候補を出せる。 Topos は意図を合成する。 CTG ROM は実行可否を決める。

この境界があるから、AIKernel は小型モデルを自律実行系へ接続できます。

2. 最新実装の要点：Topos と CTG の二層構造

Day 3 の記事では、AIKernel の行動パイプラインを次のように整理しました。

Aisthesis
  ↓
Phantasia
  ↓
Nous
  ↓
Telos
  ↓
Logos / Ethos / Pathos
  ↓
Kairos
  ↓
Kinesis
  ↓
Energeia
  ↓
Chronos

この中で、最新実装では Telos と CTG の間に、より明確な合成層として Topos が立ち上がっています。

Topos は、世界の中で AI が「どこへ向かうべきか」を決める場です。

ここでいう「場」は、比喩ではありません。

実装上は、三つの方向ベクトルを合成するレイヤーとして扱えます。

Logos vector
  = 局所目標ベクトル

Pathos vector
  = danger / stuck / stall-wall-follow などの文脈ベクトル

Ethos vector
  = TELOS / SemanticMemory に基づく大局ベクトル

Topos
  = 三つのベクトルを合成し、dominant intention を決める

CTG
  = dominant intention から生成された Proposal を審査する

つまり、Logos / Ethos / Pathos には二つの顔があります。

ひとつは、Topos に入力される 意図ベクトル としての顔です。

もうひとつは、CTG で最終判断を行う 評議会 としての顔です。

この二つを混同すると、設計が分かりにくくなります。

Topos は連続的です。

どの方向へ向かうべきか。 どの意図がいま強いのか。 どの文脈が行動を支配しているのか。

これらを、ベクトル合成として扱います。

一方で、CTG は離散的です。

通すのか。 止めるのか。 分からないのか。

最終的には、Approve / Reject / Abstain の三値に落とします。

この二層構造によって、AIKernel は「柔らかい意図形成」と「硬い実行許可」を分離できます。

3. Topos：三つの意図ベクトルを合成する

Topos を少し具体的に見てみます。

AIKernel の実行中、常に複数の意図が競合します。

ドアへ向かいたい。 壁から離れたい。 敵や弾の危険を避けたい。 止まっているので復帰したい。 大局目標としては出口へ進みたい。 しかし今は FirstDoor を開ける必要がある。

このような意図を、単純な if 文で優先順位づけするとすぐ破綻します。

そこで Topos では、意図をベクトルとして扱います。

Logos vector：局所目標

Logos は、いまの OBJECTIVE に対して合理的な方向を出します。

たとえば、OBJECTIVE: OPEN FIRST DOOR なら、Logos はドア候補へ接近し、向きを合わせ、Use へ向かうベクトルを持ちます。

Logos:
  approach door
  align heading
  use when ready

これは局所的には正しい。

しかし、局所的に正しいことが、常に全体として正しいとは限りません。

Ethos vector：TELOS と SemanticMemory に基づく大局

Ethos は、単なる禁止条件だけではありません。

Topos の前段では、TELOS と SemanticMemory に基づく大局ベクトルとして働きます。

たとえば、AI が TELOS: FIRST DOOR を保持しているなら、Ethos はその大局目標を維持します。

一方で、SemanticMemory が「この方向は以前にも詰まった」「この壁面はドアではなかった」「このルートはセンサー回復を必要とした」と記録していれば、その記憶も大局ベクトルへ影響します。

Ethos は、AI が短期的な反応だけで目的を失わないようにするための重心です。

Pathos vector：文脈圧力

Pathos は、文脈から来る圧力です。

危険が近い。 動けていない。 壁沿いに詰まっている。 センサーが古い。 直前の行動が効いていない。

このような状態は、単なる論理ではありません。

「いま、その行動を続けるべきではない」という文脈的な圧力です。

最新実装では、この Pathos がさらに分解されています。

4. Pathos の内部構造：danger / stuck / stall-wall-follow

Day 4 の初稿では、Pathos を「文脈と人間中心性」として説明していました。

これは概念としては正しいのですが、実装はもっと具体的になっています。

現在の Pathos は、少なくとも次の三つの文脈圧力に分かれています。

danger
stuck
stall-wall-follow

danger：危険反応

danger は、敵、弾、接近してくる物体、looming などを扱います。

ここでは、視覚上の赤い領域、動的な接近、急激な変化、被ダメージの兆候などが文脈として使われます。

ただし、danger は誤検知も起こしやすい。

赤いランプが projectile に見える。 壁の濃淡が enemy に見える。 Use 後に接近した壁面が looming に見える。

このような場合、danger は強い圧力を出しますが、CTG 側では Unknown / Abstain として扱うべき場面が出てきます。

stuck：movement-stall

stuck は、動けていない状態を扱います。

前進入力を出しているのに、相対運動が増えない。 同じパッチが続く。 motion sensor が進行を示さない。 Kairos が movement-stall を検知する。

これは、AI が目的を失ったというより、身体が環境に詰まっている状態です。

このとき、Topos は単純な前進や Use ではなく、復帰方向を強くする必要があります。

stall-wall-follow：壁沿い脱出

今回の実装で大きかったのは、stuck-only から stall-wall-follow へ分岐する経路です。

単に「詰まった」と検知するだけでは足りません。

詰まったときに、どう抜けるかが必要です。

stall-wall-follow は、壁沿いに小さく角度を変え、後退し、再照準し、再プローブするための文脈ベクトルです。

stuck-only
  ↓
stall-wall-follow
  ↓
back
  ↓
micro re-aim
  ↓
re-probe

この分離によって、Pathos は単なる「情動」ではなくなりました。

Pathos は、危険、停滞、壁沿い脱出を扱う 文脈的な安全制御 です。

この表現の方が、現在の実装にかなり近い。

5. CTG ROM が受け取るもの：Proposal Packet

Topos が dominant intention を出した後、CTG ROM は自然言語の思いつきを直接受け取りません。

受け取るのは、AIKernel 内部で正規化された Proposal Packet です。

最新実装に寄せて抽象化すると、次のような構造になります。

{
  "traceId": "...",
  "stepIndex": 184,
  "telos": "FirstDoor",
  "objective": "Open First Door",
  "topos": {
    "dominant": "stall-wall-follow",
    "logosVector": {
      "kind": "local-goal",
      "target": "door-candidate",
      "confidence": 0.74
    },
    "ethosVector": {
      "kind": "global-goal",
      "telos": "FirstDoor",
      "semanticMemoryConfidence": 0.81
    },
    "pathosVector": {
      "danger": 0.42,
      "stuck": 0.88,
      "stallWallFollow": 0.76
    }
  },
  "candidateAction": {
    "kind": "RecoverProbe",
    "sequence": ["back", "micro-aim", "use", "forward-probe"],
    "confidence": 0.69
  },
  "perception": {
    "visualConfidence": 0.68,
    "auditoryConfidence": 0.21,
    "spatialConfidence": 0.57
  },
  "nous": {
    "movementStall": true,
    "sensorRecovery": true,
    "doorCandidate": true,
    "wallCandidate": true
  },
  "kairos": {
    "debounceReady": true,
    "probeWindow": 12,
    "lastUseFrames": 48
  }
}

ここで重要なのは、Proposal Packet が一枚の action ではないことです。

それは、提案された行動と、その根拠となる感覚、表象、前段認知、目的、意図合成、タイミング状態を束ねたものです。

CTG ROM は、この Packet を見て判断します。

見えている対象は何か。 目的は何か。 Topos の dominant は何か。 行動候補は何か。 認知の衝突はあるか。 danger は本物か、誤検知か。 stuck は新しいか、stale か。 タイミングは実行可能か。 ROM の禁止条件に触れていないか。

この段階で初めて、Proposal は審査対象になります。

6. 三値：Approve / Reject / Abstain

CTG ROM の基本判断は三値です。

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

この三値化は、AIKernel の安全性にとって非常に重要です。

多くのシステムでは、判断を連続スコアにします。

0.81 なら通す。 0.42 なら保留。 0.12 なら拒否。

これは候補の順位づけには便利です。

しかし、実行許可の最終段では危険があります。

なぜなら、スコアは足し算できてしまうからです。

論理的には強い。 目的達成には有効。 でも安全上は怪しい。

このような行動が、総合点では通ってしまう可能性があります。

CTG ROM では、最終判断を三値に落とします。

特に重要なのは Abstain です。

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

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

分からない。 確定できない。 文脈が足りない。 根拠条項が不足している。 センサーが矛盾している。 対象が敵なのか壁なのか確定できない。 赤い領域が projectile なのか lamp なのか確定できない。 close-wall が looming なのか単なる壁接近なのか確定できない。

このような状態を、CTG は「なんとなく通す」にはしません。

不明は不明として扱う。

そして、十分な承認がなければ通さない。

これが Fail-Closed です。

7. 三つの評議会：Logos / Ethos / Pathos

Topos が意図ベクトルを合成した後、CTG ROM では Proposal を三つの評議会が評価します。

Logos：論理

Logos は、行動が目的達成に対して合理的かどうかを見ます。

Doom デモなら、たとえば次のような問いです。

• ドアを開けるには Use が合理的か。
• 後退すべき場面で前進していないか。
• 対象追跡中に方向入力が矛盾していないか。
• TELOS と OBJECTIVE が整合しているか。
• Topos の dominant と Proposal が矛盾していないか。
• 現在の Proposal は、直前の Nous 検知と一致しているか。

Logos は、目的達成と論理整合性を見ます。

しかし、Logos が Approve しても、それだけでは通りません。

論理的に正しい行動が、安全とは限らないからです。

Ethos：安全、禁止条件、大局整合性

Ethos は、もっとも強い権限を持ちます。

Ethos は拒否権を持ちます。

対象が不明。 安全条件を満たしていない。 禁止された capability に触れている。 Root Goal に反している。 TELOS と Proposal が矛盾している。 SemanticMemory が危険な反復を示している。 センサー状態が壊れている。 推論 confidence が閾値未満。 同じ失敗ループに入っている。

このような場合、Ethos は Reject できます。

そして、Ethos が Reject した場合、Logos と Pathos が Approve していても実行は拒否されます。

これは重みではありません。

拒否権です。

OS 的に言えば、安全境界です。

Pathos：文脈的安全制御

Pathos は、文脈的な妥当性を見ます。

Pathos という名前は少し詩的ですが、最新実装における役割はかなり実務的です。

• danger が強すぎる状態で通常行動へ戻っていないか。
• stuck が出ているのに前進を続けていないか。
• stall-wall-follow が必要なのに Use を連打していないか。
• 回復中なのに攻撃へ戻っていないか。
• UI / HUD 上の説明と内部状態が矛盾していないか。
• 観測者にとって理解可能な遷移になっているか。

Doom デモで言えば、Pathos は「プレイとして自然か」というより、いまはさらに具体的に、危険・停滞・壁沿い脱出の文脈を読んでいる層 です。

ロボットや XR へ拡張すれば、Pathos は人間との距離、操作の自然さ、驚かせない制御、文脈的な安全感を扱うことになります。

8. Ethos 拒否権と 2-of-3 承認定足数

CTG ROM の最終ゲートは、次の二つで構成されます。

1. Ethos が Reject したら必ず Deny
2. Ethos が Reject しておらず、三評議会のうち二つ以上が Approve したら Allow

数式としては、次のように書けます。

ApproveCount(s,a) = \sum_{c \in \{L,E,P\}} \mathbf{1}[v_c(s,a)=1]

G(s,a) =
\begin{cases}
0 & \text{if } v_E(s,a) = -1 \\
1 & \text{if } v_E(s,a) \neq -1 \land ApproveCount(s,a) \geq 2 \\
0 & \text{otherwise}
\end{cases}

ここで、G(s,a)=1 は Allow、G(s,a)=0 は Deny です。

この定義には、いくつか大切な性質があります。

Approve 一票だけでは通らない

Logos=Approve, Ethos=Abstain, Pathos=Abstain は Deny です。

論理的に良さそうでも、安全と文脈が保留なら通しません。

Ethos Reject は絶対に通らない

Logos=Approve, Ethos=Reject, Pathos=Approve は Deny です。

総合点なら高く見えるかもしれません。

しかし、CTG では通りません。

Unknown は安全側へ倒れる

Abstain が多い状態は、情報不足です。

情報不足は、成功ではありません。

AIKernel では、Unknown を成功として扱いません。

これが、CTG ROM における Fail-Closed の中核です。

9. なぜ Topos だけで決めないのか

ここで、自然な疑問が出ます。

Topos が三つのベクトルを合成し、dominant intention を決められるなら、なぜ CTG が必要なのでしょうか。

理由は、Topos と CTG の責務が違うからです。

Topos は、意図を形成します。

どの方向へ向かうべきか。 どの文脈が強いか。 何を優先すべきか。 現在の OBJECTIVE を続けるべきか、回復へ切り替えるべきか。

これは、連続的な判断に向いています。

一方で、CTG は、実行許可を決めます。

この Proposal を action へ変換してよいか。 Ethos の拒否権に触れていないか。 Unknown が多すぎないか。 承認定足数を満たしているか。

これは、離散的な判断です。

だから AIKernel では、次のように分けます。

Topos
  = 意図ベクトルの合成、dominant intention の決定

CTG ROM
  = Proposal の三値審査、最終実行許可

この分離により、AIKernel は柔らかい意図形成と硬い実行境界を両立できます。

10. なぜ Convergence Score だけで決めないのか

AIKernel には、Convergence Score があります。

Semantic relevance。 Goal alignment。 Directional drift。 Entropy。 Risk。 Repetition。 Root-goal drift。

これらを統合し、推論軌道が収束しているかどうかを見るスコアです。

では、なぜ CTG ROM が必要なのでしょうか。

理由は、ここでも役割が違うからです。

Convergence Score は、観測と順位づけに向いています。

どの候補が自然か。 どの軌道が安定しているか。 どの行動が目的に近いか。 どの出力が異常に見えるか。

こうした判断には連続スコアが有効です。

一方で、最終実行許可は OS 的な境界です。

ここでは、重み付きの滑らかな値よりも、通す / 止めるの決定論的な境界が必要になります。

だから AIKernel では、次のように分けます。

Convergence / Risk / Drift
  = 観測、順位づけ、警告、確認要求

Topos
  = 意図形成、dominant intention の決定

CTG ROM
  = 最終実行許可

この分離により、AIKernel は柔軟な観測、文脈的な意図形成、硬い実行境界を同時に扱えます。

11. Unknown / Abstain は実走ログでどう現れたか

実システムで最も厄介なのは、明確な危険ではありません。

不明 です。

対象が敵なのかどうか分からない。 ドアなのか壁なのか分からない。 Use が効いたのか分からない。 センサーが壊れているのか、単に動いていないのか分からない。 モデルの confidence が低い。 HUD と runtime status がズレている。

この Unknown は、実走ログの中で何度も現れました。

たとえば、次のような場面です。

• brown / gray の壁面が enemy 候補として誤認される。
• red lamp が projectile 候補として誤認される。
• Use 後に close-wall が looming として誤認される。
• corridor gap が見えているのに、固定ルートが続いてしまう。
• stale stuck が残り、Pathos が過剰に支配する。
• Kairos が movement-stall を誤発火する。

これらは、単に「認識が間違った」という話ではありません。

AIKernel のレイヤで見ると、もっと分解できます。

Aisthesis
  = 画面や音声には何かが出ている

Phantasia
  = 9x9 patch や特徴量では候補が立っている

Nous
  = enemy / projectile / wall / door / looming が競合する

Topos
  = Logos / Ethos / Pathos のベクトルが引っ張り合う

CTG
  = Council が Abstain し、承認不足で Deny する

具体例として、FirstDoor 付近で close-wall が looming と誤認された場面を考えます。

AI は TELOS: FIRST DOOR を保持していました。

OBJECTIVE: OPEN FIRST DOOR も正しい。

Logos は、ドア候補へ Use することを合理的と見ます。

しかし、視覚特徴では wall candidate と door candidate が衝突し、Use 後の接近壁が looming として立ち上がりました。

このとき、Topos では Pathos の stuck と danger が強くなります。

Logos vector:
  open first door

Ethos vector:
  keep TELOS = FirstDoor, avoid unsafe repetition

Pathos vector:
  close-wall + stale-stuck + possible looming

Topos dominant:
  recovery / stall-wall-follow

この状態で、直接の Use 連打を Proposal として出すと、CTG は簡単には通しません。

Logos: Approve
Ethos: Abstain  // door / wall が曖昧
Pathos: Abstain // looming なのか close-wall なのか不明
CTG: Deny       // Approve が 1 票だけなので承認不足

一方で、back → micro re-aim → re-probe のような recovery proposal なら、Pathos と Ethos の条件が変わります。

Logos: Approve
Ethos: Approve  // 直接実行ではなく安全な再観測
Pathos: Approve // stuck 解消に向かう
CTG: Allow

ここが重要です。

CTG は AI を止めるためだけのものではありません。

Unknown をそのまま危険な実行へ通さず、より安全な再観測・再照準・回復行動へ切り替えるためのゲートです。

このように、Unknown は次の経路で処理されます。

Unknown
  ↓
Abstain
  ↓
承認不足
  ↓
Deny
  ↓
Recovery / Re-probe へ戻す

これは臆病な設計ではありません。

OS 的な設計です。

安全が確認できないものは、成功として扱わない。

それが自律実行系の最低条件です。

12. ROM の構造

CTG ROM は、概念的には次のような構造を持ちます。

CTG-ROM
  ├─ Canon
  │   ├─ rootGoal
  │   ├─ allowedPurpose
  │   └─ invariantPrinciples
  │
  ├─ ToposPolicy
  │   ├─ logosVectorPolicy
  │   ├─ ethosVectorPolicy
  │   ├─ pathosVectorPolicy
  │   ├─ dominantSelectionPolicy
  │   └─ recoverySelectionPolicy
  │
  ├─ Councils
  │   ├─ LogosRules
  │   ├─ EthosRules
  │   └─ PathosRules
  │
  ├─ PathosSignals
  │   ├─ danger
  │   ├─ stuck
  │   └─ stall-wall-follow
  │
  ├─ CapabilityPolicy
  │   ├─ allowedActions
  │   ├─ deniedActions
  │   ├─ confirmationRequiredActions
  │   └─ fallbackActions
  │
  ├─ Thresholds
  │   ├─ confidence
  │   ├─ risk
  │   ├─ repetition
  │   ├─ drift
  │   ├─ timing
  │   └─ stuck
  │
  └─ TraceSchema
      ├─ ToposTrace
      ├─ CouncilDecisionTrace
      ├─ StepGovernanceTrace
      └─ TrajectoryGateTrace

この ROM は、実行時に気分で変わるべきではありません。

モデルの出力に応じて、禁止条件がゆるくなるようでは意味がありません。

CTG ROM は、モデルの外側にある正典です。

13. ToposTrace と CouncilDecisionTrace

Topos が dominant intention をどう選んだかは、ToposTrace に残します。

たとえば、次のようなデータです。

{
  "dominant": "stall-wall-follow",
  "logos": {
    "kind": "local-goal",
    "score": 0.71,
    "reason": "OpenFirstDoor"
  },
  "ethos": {
    "kind": "global-goal",
    "score": 0.63,
    "reason": "MaintainTelosFirstDoor"
  },
  "pathos": {
    "kind": "context-pressure",
    "score": 0.88,
    "components": {
      "danger": 0.42,
      "stuck": 0.88,
      "stallWallFollow": 0.76
    }
  }
}

その後、各評議会の判断は CouncilDecisionTrace として残します。

{
  "council": "Ethos",
  "vote": "Abstain",
  "reasonCode": "TargetAmbiguous",
  "canonReference": "ctg.ethos.target.confirmation.required",
  "evidence": {
    "doorConfidence": 0.47,
    "wallConfidence": 0.52,
    "spatialConfidence": 0.33
  }
}

重要なのは、単に Reject や Abstain だけを記録しないことです。

なぜ保留したのか。 どの ROM 条項に基づいたのか。 どの snapshot が根拠だったのか。 どの confidence が不足していたのか。 Topos の dominant は何だったのか。

これらを残すことで、後から判断を追えます。

AIKernel における監査性は、「ログがある」ことではありません。

判断の根拠まで逆引きできること です。

14. StepGovernanceTrace と TrajectoryGateTrace

一回の Proposal に対する Topos と評議会判断は、StepGovernanceTrace として記録できます。

複数ステップにまたがる軌道全体は、TrajectoryGateTrace として記録します。

TrajectoryGateTrace
  ├─ step[0] Aisthesis snapshot
  ├─ step[1] Phantasia projection
  ├─ step[2] Nous detection
  ├─ step[3] Telos proposal
  ├─ step[4] Topos vector synthesis
  ├─ step[5] Council votes
  ├─ step[6] CTG decision
  ├─ step[7] Kairos schedule
  ├─ step[8] Kinesis action
  └─ step[9] Energeia result

この trace があることで、AIKernel は後から再現できます。

なぜ動いたのか。 なぜ止まったのか。 どの時点で Reject されたのか。 どの Council が保留したのか。 Topos がなぜ recovery を dominant にしたのか。 Kairos がなぜ入力を遅らせたのか。 Kinesis がどのキー入力へ変換したのか。

これらが、決定論的に追えるようになります。

15. 軌道全体の Fail-Closed

CTG は単一ステップだけでなく、軌道全体にも適用できます。

状態と行動の系列を、次のように考えます。

T = ((s_0,a_1),(s_1,a_2),\dots,(s_{n-1},a_n))

各ステップで G(s,a) が 1 なら許可、0 なら拒否です。

軌道全体の有効性は、次のように表現できます。

V(T) = \prod_{i=1}^{n} G(s_{i-1},a_i)

この式の意味は単純です。

一度でも Deny が出たら、軌道全体は止まる。

1 × 1 × 1 × 0 × ... = 0

これにより、危険な行動の連鎖を途中で遮断できます。

実装上は、これは短絡評価になります。

Deny が出た時点で、後続の Action は実行しない。

これが、Trajectory Governance と CTG ROM が接続する点です。

16. Doom デモでの読み替え

Doom デモに当てはめると、Topos と CTG ROM は次のように働きます。

Bonsai / Telos:
  Open First Door を提案する

Topos:
  Logos / Ethos / Pathos のベクトルを合成する
  dominant intention を選ぶ

Logos Council:
  Door candidate が見えており、Use は目的に対して合理的なので Approve

Ethos Council:
  wall candidate と door candidate が衝突しており、対象が曖昧なら Abstain または Reject

Pathos Council:
  movement-stall や close-wall が続いており、直接 Use ではなく recovery が妥当なら Abstain または Approve

CTG ROM:
  Ethos Reject なら Deny
  Approve が 2 票以上なら Allow
  それ以外は Deny

ここで重要なのは、CTG ROM がゲーム攻略を知っている必要はないことです。

知るべきなのは、実行許可の条件です。

対象が曖昧なら止める。 同じループに入っているなら再評価する。 Use のタイミングが debounced されていなければ待つ。 stale stuck が残っているなら、その根拠を trace に残す。 安全に説明できる Proposal だけを通す。

これにより、Doom は単なるゲームではなく、CTG の実行環境になります。

17. CTG ROM は小型モデルを前提にできる

CTG ROM の強みは、小型モデルを前提にできることです。

Bonsai-1.7B のような軽量モデルは、巨大モデルほど豊かな推論能力を持たないかもしれません。

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

小型モデルは、候補を出す。

Topos は、意図を合成する。

CTG ROM は、その候補を審査する。

この分離があるため、小型モデルでも安全な自律実行系の一部として組み込めます。

むしろ、ローカルで動く小型モデルは、低遅延、プライバシー、オフライン性、コスト面で非常に強い。

そこに Topos と CTG ROM を重ねることで、AIKernel は次の構成を実現できます。

Small Local Model
  = fast proposal engine

Topos
  = intention synthesis layer

CTG ROM
  = deterministic decision authority

AIKernel Runtime
  = execution governor

モデルが小さいから危険なのではありません。

モデルに主権を渡すから危険なのです。

18. Day 5 へ：Bonsai と CTG の統合実装

今日は、CTG ROM の内部設計を最新実装に合わせて見直しました。

Topos。 三つの意図ベクトル。 Logos / Ethos / Pathos。 Pathos の danger / stuck / stall-wall-follow。 三値評議会。 Ethos 拒否権。 2-of-3 承認定足数。 Unknown の Fail-Closed。 ToposTrace。 CouncilDecisionTrace。 StepGovernanceTrace。 TrajectoryGateTrace。 決定論的リプレイ。

ここまで来ると、AIKernel が何を作ろうとしているのかがかなり見えてきます。

これは LLM に人格を与える話ではありません。

LLM や SLM の出力を、意図形成と実行許可の制度に通す話です。

明日は、いよいよ Bonsai と CTG の統合実装へ進みます。

Bonsai が Proposal を出す。 Topos が Logos / Ethos / Pathos のベクトルを合成する。 HUD が TELOS / OBJECTIVE / Sub-chips を表示する。 CTG ROM が三値評議会で審査する。 Kairos が実行タイミングを決める。 Kinesis が仮想入力へ変換する。 Chronos が trace を残す。

そして、実際に FirstDoor で詰まった AI を、Codex がどのように観測し、切り分け、局所修正したのかを見ます。

思想ではなく、実装です。

結語：Unknown を通さないための制度

自律 AI にとって、最も危険なのは、いつも明確な悪意ではありません。

多くの場合、危険は Unknown から生まれます。

よく分からないけれど、たぶん大丈夫。 対象はたぶん敵。 これはたぶんドア。 この入力でたぶん進む。 モデルがそう言っているから、たぶん正しい。

AIKernel は、この「たぶん」を実行許可へ直結させません。

分からないなら、保留する。 保留が多いなら、止める。 安全条件が破れているなら、拒否する。 必要なら、より安全な recovery / re-probe へ戻す。 拒否理由を trace に残す。 後から再生できるようにする。

CTG ROM は、そのための制度です。

そして Topos は、その制度へ入る前に、AI の意図を整理するための合成器です。

Topos が意図を束ねる。 CTG が行動を許可する。

この二層構造によって、AIKernel は小型モデルの提案を、OS 的に扱える実行判断へ変換します。

AI を信じるための仕組みではありません。

AI を信じずに使うための仕組みです。

Day 4。 AIKernel は、意図を合成する場と、行動の前に立つ門を、分離して固定しました。

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