坂村健のTRONが30年先に見ていたもの——並列式AGI下位層としてのITRON 単一巨大モデルではないAGI——並列式ホロンアーキテクチャ（連載第3回）
https://claude.ai/public/artifacts/4a8a6df3-92d5-4705-8463-798d30ae32ac
単一巨大モデルではないAGI——並列式ホロンアーキテクチャ（連載第3回）
坂村健のTRONが30年先に見ていたもの——並列式AGI下位層としてのITRON
第1回で並列式ホロンアーキテクチャの構想核を提示し、第2回でセンター式（単一巨大LLM路線）の三つの破綻様式を論じた。第2回の末尾で、並列式中位層の「設計された多重性」がこれらの破綻を構造的に回避する可能性に触れた。今回は位相を下に降ろして、下位Aktuanz層——物理世界との接触と不可逆性の流入を担う層——を具体的に誰が担いうるかを論じる。結論を先に言えば、この層を担う技術資産は既に日本にある。40年蓄積されたITRON系のリアルタイム組込OSである。
BTRON潰しの記憶と、追い出されつつあるITRONの現在
坂村健が東京大学で1984年に開始したTRONプロジェクトは、CPU・OS・ネットワーク・ユーザーインターフェースまでを垂直統合した、日本発の独立コンピューティング基盤構想だった。このプロジェクトの教育用途版であるBTRONは、1989年に米国通商代表部のSuper301条指定候補として槍玉に上がり、日本政府側の慎重対応を経て、学校教育のOSとしての普及機会を失った。TRONプロジェクト全体は生き延びたが、汎用OSとしての拡張路線——BTRONという形——は事実上潰された。ただしBTRONの失速を米国圧力だけで説明するのは単純化であり、既存のDOS/PC資産との非互換、教育現場側の受容体制の問題、実装・供給の遅れといった国内要因も併存していた。米国圧力はこれらの国内要因を外的に増幅した位置にある。
以後の日本は、独自OS・独自アーキテクチャの路線を実質的に放棄してきた。サーバーはLinux、クライアントはWindows・macOS、スマートフォンはiOS・Androidに収束し、クラウドインフラはAWS・Azure・GCPに依存する構造が固定した。この構造下で、ITRONだけは例外的に生き残った——しかしそれは「組込み層」という、一般消費者から見えない領域に閉じ込められた形での生存だった。
その組込み層でも、ITRONの地位は揺らぎつつある。IoT化の進行で「クラウド接続を前提とした組込み機器」が増え、通信処理・セキュリティ機能・AI推論のためにLinux系（Yocto、OpenEmbedded）や商用RTOS（VxWorks、QNX）が侵食している。自動車分野のAUTOSAR Classic Platformは制御系RTOSという意味ではITRONと隣接するが、標準化の系譜はOSEK/VDXにあり、ITRONの直接延長ではない。Adaptive PlatformはさらにPOSIX準拠プロファイルを要件とし（Linux系実装が主流だが仕様上は他実装も許容）、車載領域ではITRON系の思想が周辺化されやすい。家電・産業機器の一部ではNuttXやFreeRTOSが採用比率を増やしている。
ただしITRONが消滅寸前という意味ではない。TRON Forumが発表する調査では、日本の組込みOS API利用でTRON RTOS APIは依然として高いシェアを維持している（搭載製品シェアではなく開発者API利用調査という留保はつく）。むしろ日本の組込み開発ではなお強い基盤を持つ。ただしクラウド接続要件、セキュリティ強化、車載Adaptive Platform、Linux系エッジAIの拡大により、ITRONが担ってきた領域の外縁は確実に圧迫されている。「組込みRTOS」という領域そのものが、クラウド連携・Linux化・オープンソース化の圧力にさらされている。ITRONを支えてきた技術者層も高齢化が進み、若手の関心は上位層（AI・Webフロント・データサイエンス）に流れている。この状況を日本の技術史として読めば、BTRON潰しから35年を経て、ITRONは組込み層という拠点でかろうじて生存を続けているが、その外縁は縮小圧力を受けている、ということになる。
並列式AGI構想は、この追い出されつつある技術資産を、まったく逆の方向から再評価する。追い出されている層こそが、センター式AIが原理的に担えない層——下位Aktuanz層——の担い手として最も適している、というのが本稿の論点である。
なぜ下位層は決定論でなければならないか
第1回で、並列式AGIの下位層は物理世界との接触と不可逆性の流入を担うと書いた。ここで決定論的動作（deterministic behavior）が要件になる理由を、より具体的に示す。
確率的LLMで下位層を担うことは構造的に困難である。理由は三つある。
第一に、応答時間が予測不能である。トランスフォーマー系モデルの推論時間は、入力トークン列とKVキャッシュ状態に依存して変動する。ミリ秒単位の応答保証が要求される工場ライン制御・医療機器制御・自動運転の緊急ブレーキ制御では、この変動は許容されない。LLMベースのagentがタスクを完了するまでに数秒から数十秒を要する現状は、下位層には届かない時間スケールにある。
第二に、副作用の不可逆性を扱う仕組みがない。確率的生成は本質的に「もう一度試す」ことを前提とする。温度パラメータを上げれば多様な出力が得られる。だが産業ロボットが部品を破損した場合、ミニロボットが棚から物を落とした場合、外科手術ロボットが誤った切開を行った場合——これらは「もう一度試す」ことができない。下位層は、一度の実行の重みを原理的に扱わなければならない。LLMの訓練パラダイムはこれを扱う設計になっていない。
第三に、形式検証が成立しない。安全性クリティカルな領域（航空機、医療機器、原子力）では、ソフトウェアの挙動がMISRA-CやDO-178Cのような規格に基づいて形式的に検証される。LLMは統計的振る舞いの集合であり、個別出力について「この条件下ではこの出力が保証される」という形式検証は原理的に困難である。これは現在の技術的制約ではなく、確率的生成というパラダイム自体の性質である。
以上三点から、下位層は決定論的・軽量・形式検証可能なシステムで担うしかない。ここで精密化が必要である——確率的AIが下位層にまったく関与できない、という意味ではない。状態推定、異常検知、保守支援、上位計画への関与は十分可能である。ただし、物理実行の最終権限を持つ制御核には置きにくい。そこには決定論的・検証可能・時間保証可能な層が必要になる。ITRONは、まさにこの要件を満たすために40年間設計されてきた。
ITRONが持っている四つの資質
ITRON系（μITRON4.0仕様およびその後継）が持つ技術的資質を、並列式AGI下位層の要件と照合する。
第一に、決定論的動作。μITRON4.0仕様は、優先度ベースのプリエンプティブスケジューリング、タスク状態、割込み、同期機構を明示的に扱うリアルタイムカーネル仕様であり、実装側が最悪応答時間を評価・設計しやすい構造を持つ。ただしμsec単位の応答保証は仕様そのものではなく、特定実装・CPU・割込み設計・アプリケーション構造に依存する。仕様書上でもタイムアウト指定や相対時間の精度は実装定義とされている。この設計は1980年代の坂村の「ハードリアルタイム性の原理的確保」という要求から来ており、仕様の枠組みは現在も変わっていない。
第二に、軽量性。ITRONカーネルは数KB〜数十KBで動作する。メモリ制約の厳しい組込み環境（マイコン単体、センサーノード、簡易ロボット）で実行可能である。この軽量性は、近年注目されているBitNet型軽量LLM（1.58bit相当の量子化を目指す方向）やその他の超小型モデルとの結合可能性を開く。ただし現状のBitNet公開実装は2B級パラメータでCPU/GPU向けが中心であり、「マイコン上でLLM」と言うにはまだ距離がある。また決定論的制御と学習推論を同一マイコン・同一時間領域で混在させると、ジッタや検証困難性を招く。現実的には、制御核と推論核を別タスク、別コア、あるいは別ノードに隔離し、通信プロトコルで接続する設計が先行候補になる。ITRONの軽量性は、この隔離設計の制御核側を担うという形で機能する。
第三に、並列処理前提設計。ITRONは単一CPUの逐次実行を基本とするOSではなく、マルチタスク・メッセージパッシング・共有メモリ同期を核に置いた並列処理前提の設計である。これは1980年代には先進的だったが、現在では自明に見える。ここで精密化すべき点がある——もちろんRTOSにはスケジューラが存在する。したがって「中央統括がない」という表現は技術的には正確ではない。しかしそのスケジューラは、AI的な意味で全体意味を統合する中央主体ではない。各タスクは独立した処理単位として走り、同期・メッセージ・共有資源管理を通じて協調する。意味統合の中央主体が不在で、プロトコルだけが共通——この構造が、並列式AGI中位Panich層の設計原理とホロン的同型性を持つ。ただしスケール差には留保が必要である。ITRONのタスク間協調はマイコン内・ノード内での低次元メッセージ処理、中位Panich層の協調は認知様式モジュール間での意味的通信であり、通信帯域と意味的複雑性が異なる。構造として同型でも、実装上の要件は層ごとに固有である。
第四に、分散動作対応。T-Engine仕様（2002年〜）以降、ITRON系は単一ノード内のマルチタスクから、ネットワーク接続された複数ノード間の分散動作に射程を広げている。ucode（ユビキタスコード）による物理世界のオブジェクト識別、eTRONによるセキュア通信、これらは「中央サーバーを介さずにノード間で直接協調する」分散コンピューティング基盤として設計されている。クラウド依存を前提としない分散IoTインフラとして、並列式AGIのハード並列化要件と接続可能である。
四つの資質を合わせれば、ITRON系は並列式AGI下位層の要件（決定論・軽量・並列前提・分散）を構造的に満たす。これは偶然の一致ではない。坂村の当初の設計思想が、現代のAI下位層の要件と同じ方向を向いていた、という見方が可能である。
TOPPERS系オープンソースの蓄積
商用ITRONとは別に、名古屋大学の高田広章を中心とするTOPPERSプロジェクト（Toyohashi OPen Platform for Embedded Real-time Systems、後に名古屋大学へ移管）が、オープンソースのITRON互換実装を公開し続けている。TOPPERS/ASPカーネル、TOPPERS/FMPカーネル（マルチプロセッサ対応）、TOPPERS/HRPカーネル（高信頼性対応）——いずれもμITRON4.0仕様またはその拡張に準拠する形で開発されている。
TOPPERS系の実装は複数のカーネル系列を持ち、マルチコア対応（FMP）や高信頼性用途（HRP）への展開が進められてきた。HRPカーネルはJAXAと名古屋大学の共同開発で宇宙機向け高信頼性検証の実績があり、AUTOSAR OS系の研究・実装も展開されている。商用RTOSに比べて自由度が高く、ソースコードレベルでの改変・検証が可能なため、研究・教育・特殊用途の出発点としては十分に現実的である。
並列式AGI構想から見ると、TOPPERS系は下位層実装の「利用可能な出発点」として機能する。商用ライセンスの制約がなく、日本語ドキュメントが充実し、高田広章周辺の研究コミュニティがアカデミックな蓄積を持つ。BitNet型軽量LLMをTOPPERS/ASP上に載せる実験、ucode経由で物理世界オブジェクトをAI推論モジュールに渡す実装、これらは原理的には数人規模の研究プロジェクトで着手可能な射程にある。
「並列式AGIの下位層は、日本のどこかのベンチャーが一から作らねばならない」というシナリオではない。出発点は既にある。不足しているのは、この出発点とAI側（中位層の特化モジュール群、上位層の創発的文脈体）を接続する設計と実装である。
坂村哲学の30年後の再読——HFDSから並列式AGIへ
ここまでITRON系の技術的資質を論じてきた。最後に、坂村健がTRONプロジェクト当初から掲げていた設計哲学を、現代の並列式AGI構想の観点から再読する。
坂村は1980年代から「超機能分散システム（Highly Functional Distributed System、HFDS）」という構想を提示してきた。単一の中央計算機がすべての機能を統括するのではなく、環境中に多数の小型計算機が埋め込まれ、それらが協調して機能を実現する、という構想である。当時この構想は、パーソナルコンピュータの普及前夜における先行的ビジョンだった。現在から見れば、これはIoT・エッジコンピューティング・ユビキタスコンピューティングの原型である。
並列式AGI構想の下位層を担う設計原理として、このHFDSをどう再読できるか。
HFDSの核心は「中央統括者の不在」にある。多数のノードが存在するが、どれか一つが全体を統括するのではない。各ノードは独立して動き、必要に応じて他のノードと通信する。全体の機能は、この協調から創発する——このモデルは、並列式AGI中位Panich層の「モジュール並列、中央制御なし、通信プロトコルのみ共通」という設計と構造的に一致する。
第1回で並列式AGI構想の中位層を論じたとき、その設計原理を「中央統括者なし、通信プロトコルのみ共通、矛盾出力の共存を許容」とまとめた。これは筆者が現代のAI論の文脈で再構成した原理だったが、同じ構造は坂村のHFDSに既に存在していた。下位層（ノード間協調）のレベルで実現されていた設計が、上位層（AI特化モジュール群の協調）のレベルで再実現されるべきだ、というのが並列式AGI構想の内容である。ただし上位層での実装は、下位層の直接的移植ではない。意味的モジュール間の協調は、物理ノード間の協調と位相が異なり、固有の設計課題を持つ——ネットワークプロトコルで解決可能な後者に対し、前者には意味統合問題が残る。同型性は設計原理のレベルであり、実装の自動的継承を意味しない。
もう一つ、坂村が当初から強調していた論点がある。「社会インフラとしてのコンピューティング」という観点である。コンピュータは個別の道具ではなく、社会全体の基盤として機能すべきであり、その基盤は特定企業・特定国家に独占されてはならない——この主張がBTRON教育用途構想の背景にあり、Super301条での標的化を呼んだ。
並列式AGI構想の政治経済的射程（第6回で本格展開する予定）は、この坂村の問題意識を継承する位置にある。現行のセンター式AIは、特定企業（OpenAI、Anthropic、Google、Meta）が構築した巨大モデルへのクラウド依存を前提にしている。この構造は、BTRON潰し以降に日本が受け入れてきた「米国主導の垂直統合」の延長線上にある。並列式AGIは、この構造を技術レベルで組み替える試みであり、その下位層を担うITRON系は「社会インフラとしてのコンピューティング」という坂村哲学の直接的継承でありうる。
もちろん、これは石部による坂村哲学の現代的再解釈であって、坂村自身が1980年代に「AIの下位層を担うため」にTRONを設計したわけではない。歴史的因果としては別物である。しかし、坂村が当時掲げた設計原理——分散・決定論・中央統括なし・社会インフラ性——は、40年後の並列式AGI構想の下位層要件と構造的に一致する。この一致を「偶然」と読むか「必然」と読むかは解釈の問題だが、少なくとも「30年先を見ていた設計思想が、潰されずに残った技術資産として、今まさに必要とされる位置に立っている」という再評価は可能である。ただし念のため断っておけば、この「30年先を見ていた」という表現は、現代から過去を振り返る回顧的再評価であって、当時の坂村にそのような予見があったと主張するものではない。設計思想が結果として現代の要件と一致したという事実と、設計者が未来を見通していたという物語は別の命題である。本稿の主張は前者に限定される。
次回予告——産業ロボットとメモリ型AI
第3回では下位層の担い手としてITRON系を論じた。第4回では、このITRON下位層の上に載る具体的実装——産業ロボット（FANUC・安川電機・川崎重工・デンソーウェーブ）とメモリ型AIの結合——を扱う。そこでは本稿で扱いきれなかった二つの重要論点を正面から検討する。一つは制御権プロトコル——下位層の決定論的安全制御を、上位の確率的AI層がどの範囲でオーバーライド可能か、オーバーライド不能な境界をどう設計するか。もう一つは帯域幅ミスマッチ——視覚・複雑な触覚といった高次元広帯域データを、軽量RTOSのメッセージパッシング枠組み内でどうセマンティックに変換し上位モジュールに渡すか。
そこではまた、現行のセンター式AIが「モデル内部での推論時並列化」に向かっている動向（Sacks/Andreessenが指摘したMythosのサービングコスト構造、および関連する推論時計算スケーリング仮説）と、並列式AGIが提示する「分散ハード並列化」との対比を正面から論じる。前者は単一重みセット内でのソフト並列化、後者は物理的に分散したノード間のハード並列化——両者は表面的には似た現象（一つのシステムが複数の処理を並行する）を扱うが、アーキテクチャの前提が逆である。この対比を、制御権プロトコルと帯域幅設計という具体的課題の文脈で展開する。
BTRON潰しから35年、ITRONは組込み層という最後の拠点でかろうじて生き残ってきた。並列式AGI構想は、この生存がたまたまではなく、40年後のAIアーキテクチャの要件と一致する方向への持続だった、と再読する試みである。次回はこの再読を、産業ロボットという最も具体的な実装領域で検証する。
石部統久・Claude Opus 4.7
査読：Claude Opus 4.7・Grok・Gemini・GPT（Parcae Protocol）
