実装

店にすでにある決済端末の横にサーバーをひとつ立て、タブレット・PC・厨房の画面を繋いだ。三台のどれにもアプリを作っていないのに、それぞれキオスク・POS・厨房ディスプレイになった。カード承認の経路は一行も触っていない。コード全体と実行ログ、実際にレンダーされた三画面をそのまま載せる。

STM32H723 は USB シリアルで、ESP32 は mDNS で見つけて Wi-Fi TCP で繋いだ。二台のボードがそれぞれ画面定義を差し出し、ボタンを押せば実際の LED が点く。クライアントのコードは二つの場合で一文字も違わない。シミュレータ無し — この記事だけは、ハードウェアが無ければ検証が失敗する。

このシリーズの画面はすべて問うて知った。手に持つ画面はそれでいいが、壁に打ち付けた厨房の画面は違う — 問い続けるか遅れるかのどちらかになる。購読してから三件が届く間、画面が呼んだ道具は0個だ。

リトライの記事はたいてい、かける側から書かれている。この編は受ける側から数える。700ミリ秒の障害を四人が二つの方法で越え、どちらも最終的には通った。違うのは、その間にゲートウェイが叩かれた回数だ — 64回と25回。

同じ時間を二人が同時に取る。言葉で説明すると二つの処理は全く同じことをする — 空いているか見て、空いていれば取る。一方は二人ともに確定を送り、もう一方は送らない。違いは途中にある await ひとつだ。

画面ひとつを二人が開く。取消ボタンは二人ともに見える。アルバイトが押すとサーバーが拒否し、拒否が帳簿に残る。画面ファイルは同じファイルであり、そのハッシュをログに焼いた。

このシリーズのサンプルはこれまでずっと、画面ファイルをアプリの隣に置いてきた。今回のクライアントには画面が一枚もない。何を描くかをサーバーに尋ねて描き、サーバーが変わったと言えばまた尋ねる。再インストールも再起動もビルドもない。

Claude Desktop に「ノートに保存して」と書けば、自分のノートPCで回る数十行のサーバーが実行される。ストアも配備も無く、設定一行だ。その往復を最初から最後まで作り、dart test に自分で検査させた。

画面講座 最終回。conditional で画面が分かれ、list が数を知らないまま行を作る。そして三トラック十六編が一つに繋がる。

2月にチップ、3月に計測器、4月にドライブレコーダー、5月に温室を作った。それぞれ自分のアプリを持ち、互いを知らない。ところが画面を描くコードは二十七部すべてバイトが同じだった。同じバージョンではなく、同じファイルだ。

画面講座 第4回。onTap にコードは無く、ツール名しかない。その名前が本当にホストまで届いたかは絵では確かめられないので、ハーネスが押して書き取る。

画面講座 第3回。`{{now}}` ひとつで画面と値が分かれる。そして本当に分かれたかは、一つのファイルを違う状態で二度レンダーして確かめる。

画面講座 第2回。複数を置くには座標が要りそうだが、linear は方向と間隔しか受け取らない。座標を使わないのが趣味ではなく条件である理由。

温室に付くセンサーはまちまちだ。摂氏で測るもの、華氏で測るもの、ppm で測るもの。ノードが自分を宣言し、規則が型番ではなく種類で語るようにしたら、センサーを交換して二つ増設してもサーバーコードも規則も一文字も変わらなかった。

画面講座 第1回。クライアント講座4回目でサーバーから届いたあの塊が、正確には何なのか。四行のJSON一つと、その中を決して覗かないホスト一つから始める。

MCP クライアント講座の最終編。購読し、通知を受け、そのとき読む。ポーリングが資源を食うのは副次的だ — 本当の問題は、二度問う間に値が二度変われば真ん中を永遠に見られないことである。

MCP クライアント講座 4 編目。サーバーから画面定義を読んでランタイムに渡す。このファイルにはデスクがどんな形かというコードが一行も無い — そしてそれが検査される。

車両管理者がドラレコから見たいものは映像だけではない。運行記録、カードの残り、衝撃感度。だから普通は全部返す API を作り、映像の前だけに権限検査を立てる。その検査を消せば終わりだ。このアプリは映像の道具に鍵をかけず、そもそも作らなかった。

MCP クライアント講座 3 編目。道具を呼んで答えを読む。結果が値ではなくコンテンツの一覧であること、そしてサーバーが拒んだときそれが throw で来ないこと — だから捕まえるのではなく読まねばならない。

MCP クライアント講座 2 編目。道具とリソースの一覧を問う。二行で終わるのだが、この二行があるかどうかが「そのサーバー専用のクライアント」と「どのサーバーの前にも立てるクライアント」を分ける。

MCP クライアント講座の一編目。サーバーに繋ぐ。ここで見るべきは接続のコードではなく伝送の正体だ — 開くソケットではなく起動するコマンドであり、だから後で伝送を替える作業がコマンド一行を替える作業になる。

MCP サーバー講座の最終編。画面が一秒ごとに問うのをやめさせる。サーバーが知らせるのだが、通知には uri だけを載せて値は載せない。そして購読していないクライアントには何も行かない。

計測器はすでに話せる。問題は三社が三通りで答えることだ — 指数表記、キャリッジリターン、単位の付いた値。その三つをひとつの形にして一枚の画面に立てた。そして画面はつまみの値ではなく、計器が言った数字を出す。

MCP サーバー講座 5 編目。待ち人数が変数にあればプロセスと一緒に消える。ファイルに書くのだが、毎回すべてを書き直す。部分更新より遅い代わりに、書きかけの記録が残らない。

MCP サーバー講座 4 編目。画面をサーバーがファイルとして持ち、差し出す。ファイルを直せば再ビルドも再インストールも無しに次の接続で変わる — ただし毎リクエスト読んでこそ、その言葉が真になる。

MCP サーバー講座 3 編目。入力スキーマを付け、そのスキーマを信じないハンドラを書く。0 人を入れよという要求と 99 人を入れよという要求が、それぞれ違う理由で拒まれるところまで。

評価ボードに画面を付けるには普通、グラフィックススタックを載せてファームウェアを焼き直す。その代わりにボードが自分の能力を道具として、自分の画面をリソースとして差し出すようにした。机の上の STM32H723 に繋いで LED を点け、ボードが渡してきた 656 バイトの画面をそのままレンダーした。

MCP サーバー講座 2 編目。道具をひとつ登録する。名前・説明・入力スキーマ・ハンドラの四つだが、そのうち三つは我々ではなく呼ぶ側が読む。だから説明文をうまく書くことがハンドラをうまく書くことより値が大きい。

二週間前の番号板にボタンを付けた。押せば数字が動く。ところがその数字を誰が持っているかが問題だ。画面が持っていれば二台目のパネルが違う数字を出す。カウンターが持っていれば、パネルを抜き差ししても同じ数字だ。

パネルの能力を道具として、画面を定義として、ランタイムをレンダラとして。その連鎖が実際に最初から最後まで走るサンプルを並べ、パッケージがどう噛み合うかを見せる。画面は描いたものではなく、本当にレンダーして撮ったものだ。

待合室の番号板を作る。画面定義は九行で、その九行はクライアントの中に無い。サーバーがファイルとして持っていて、接続してきた側に手渡す。ビルドもインストールも無いというのはそういう意味だ。

MCP サーバー講座の一編目。道具もリソースも無く、サーバーだけを立てる。ここで確かめるのはひとつ — クライアントが繋がって initialize に答えを受け取るか。そしてこの段階で打っておかないと最後まで壊れ続ける規則ひとつ。