IV.3 物理世界

本章の位置づけ

画面の向こうだけでなく、車輪や腕が動く側でも、同じ分け方が使えるかを見る。センサーのドライバの書き方は扱わない。BitNet などの量子化は、エッジで推論する手段の例である。万能だとは書かない。

3.1 同じ分け方で足りるか

ロボットは、見たものを判断し、動かす。文を書く AI と別世界に見えやすい。担当で切ると、並びは同じである。

層	クラウド側	現場の機械側
Doctrine	目的と禁止	衝突したら止まる、人を先にする、など、聞けなくても守る線
Agent	Claude など	機械のそばで動く、小さめのモデル
Skills	Markdown の決まり	安全の基準、動きの範囲、物理の目安
Memory	前回の案件	さっき通った経路、故障の履歴
MCP	Web API や DB	センサーの入力、アクチュエータの出力

判断する、知識を持つ、外とつなぐ、物差しを持つ、関係を残す。つなぎ先が API でもセンサーでも、この分け方は変わらない。変わるのは実装である。

学術の側では Embodied AI と呼ぶことが多い。身体を持ち、環境とやりとりしながら学ぶ、という捉え方である。本書では、五層を現場の機械へ伸ばす話として、物理世界と呼ぶ。

クラウドと話せるときは、厚いモデルに聞いてよい。電波が切れると、その場で決めなければならない。失敗が、文の誤りでは済まない。

そのとき効くのが Doctrine である。第III部で書いた、「聞けないときにバラバラに動くと失敗する」が、ここでは身体を持つ。衝突回避を最優先にする、分からない障害物では止まる、は、手順の列ではなく、共有した線である。

Skills には、重力や摩擦の目安など、動きの知識を置く。ワールドモデルと呼ぶこともある。本書では、Skills に置く知識の一種として扱う。細部の制御理論は、対象外である。序章で切った。

現場の機械は、電池で動くことが多い。大きなモデルを、いつもクラウドに聞きに行くとは限らない。重みを小さくして、CPU のそばで動かす手段がある。BitNet のような量子化は、その例である。学習は別として、推論を手元で実用にする、が要点である。

テキストのニュアンスには、まだ厚いモデルの方が向くことが多い。右へ何度、正常か異常か、のように選択肢が限られた判断には、小さいモデルで足りることがある。エンジンが何であれ、五層の分け方は変わらない。

クラウドと現場を組むときは、厚い判断は遠く、速い判断はそば、と分けてよい。デジタルツインは、現場の状態を MCP で取る相手になり得る。複数台が組むときは、第III部の A2A と同じ問いが出る。誰が、誰の代理として、動くかである。

新しい層を発明する話ではない。いまの五層の、つなぎ先がセンサーになった形である。安全の線は Doctrine と Skills に先に書く。動かすコードより先に、越えてはならない線を決めるのがよい（SHOULD / するのがよい）。

五層は、現場の機械でも担当は同じである。変わるのは実装である。聞けないときほど、Doctrine が要る。量子化は手段の例であり、層の代わりではない。