こちらが立っている位置 — どこから始まり、何を提案するのか

十三編を通ってきた。まとめる。

二つの軸

「それと何が違うのか」は二つの問いだった。

端末の中でアプリを動かすプラットフォームには — ビジネスの持ち主は誰か。 あちらは端末を持つ側ひとつが事業をつくり、拡大が台数で決まる。ここではドメインを持つ人たちがそれぞれつくり、拡大がドメインの数で決まる。そしてその二つは戦う席ではない — アプリ一つとして入れば、その画面が外の装置を扱う場所になる。

モデルが開く窓には — その窓の持ち主は誰か。 MCP Appsはモデルが人に見せる窓であり、こちらは人が機械を直接扱う窓だ。前者はモデルを外せば消え、後者はモデルがなくても回る。そして二つは同じ画面に一緒にいられる。

層が違うので二つの答えが互いを削らない。この巻はどちらも削らないためにこの順序で書いた。

どこから始まったか

この作業はMCPを見て始めたものではない。

宣言だけでアプリが回るランタイムをその前からつくってきた。自前のサンドボックス、状態の隔離、リソース管理、実行エンジンを備えた構造だった。MCPが公開されたあと、その上に接続層を載せた。

公開記録はこうだ。

現在のUIランタイムは1.4仕様を実装する。158のウィジェット、Material 3のテーマ、デザイントークンの往復、複数サーバーのオーケストレーション。フォームファクタは六つで、そのひとつが embedded だ — ホストが固定して使う、キオスクと産業設備と車載コンソールのためのものである。

日付を前に出すつもりはない。 この巻の前の十三編が一度も日付を出さなかったことがその意味だ。違いを先に言い、訊かれたら日付を出す。

この表が言うことはひとつ — 別の側から同じ問題を解いていた。 あちらはウェブホストから出発し、こちらは装置から出発した。互いを知らなかっただけだ。

ここから先はドメインがやる

構造が開く場所と、その場所を埋める側は別だ。

チャネルごとに等級の違う画面。 一つのサーバーがつないだ場所に応じて違う画面を渡すことは、この巻で画面上に確認した。等級をいくつに分け、どの席に何を開くかは、その装置を知っている側が決める — その決定が外に出ないことがこの構造の要点だ。

現場の通信規格。 産業バスであれ船級規格であれ、それを受ける場所は装置の側だ。装置が自分の機能を差し出せば画面はそのまま付いてくる — 規格が変わっても画面を書き直さない。

ドメインの検証体系。 検証される主体は装備をつくった側にそのまま残る。画面が機能を複製しないからだ。この巻の軸のひとつがそれだった。

三つの席はいずれも装備をつくった側が埋める。この構造はその三つを代行せず、それぞれが入る場所を決めておく。

提案

MCPは拡張の道を開いており、ワーキンググループの委任モデルへ向かっている。いまある席は、トランスポート、認可、レジストリ、セキュリティ、マルチモダリティ、コンプライアンスだ。

制約環境と物理装置を扱う席はまだない。

その議論を始めることを提案する。仕様を新しくつくろうという話ではなく、組込みで何ができて何ができないのかを 動く実装を持って整理しようという話だ。実際に載せてみないと分からないことがある — この巻の十三編がそのリストの一部である。

同じ問題を別の側から解いている方々と話したい。

最後に

この巻は「こちらのほうが優れている」を一度も書かなかった。書く必要がなかったからだ。

持ち主が違えば、できることとできないことがひとりでに分かれる。その分かれ目を十三回書き、確認できるものは画面で確認した。

そしてこの構造は文書の上に立っている。宣言が何を保証するのかがそこに書かれており、画面は書かれたとおりに出る。この巻の根拠はすべてそこから出ている。

---

makemind.dev 「探索」— この巻の実測はすべて、一緒に載せたサンプルとプローブから出たものだ。