2023年9月に、
「箱庭アセット間の通信を実現するPDU（Protocol Data Unit）とは何か？」
において、箱庭のPDUについてその概念と複数プロトコル対応を紹介しました。

当時は、

• なぜPDUという仕組みが必要なのか
• UDP / TCP / SHM / ROS など、異なる通信方式をどのように扱うのか

といった 「何ができるのか」 を中心に説明していました。

2026年1月を迎え、
デモを通したユースケース・課題、それらを対応する設計と実装を積み重ねる中で、
ようやく 箱庭PDUの具体的なアーキテクチャ が見えてきました。

その過程で、箱庭PDUとは、
単に通信データ/通信方式を抽象化する
という考え方だけでは、
どうしてもおさまりが効かない概念なんだと気付かされました。

具体的には、以下のような課題が浮き彫りになりました。

• PDUのアクセス権の問題
• PDUの転送方式の問題
• PDUを使ったRPCの扱いの問題
• PDUの設定と一貫性の問題
• PDUの実装のばらつき問題

つまり、
これらの点を曖昧にしたまま、
デモを優先して PDUデータの書式だけを先に定め、
そのアクセス方法や運用は
その場その場で実装判断を行う という状態になっていました。

このままでは、
PDUの役割や責務が拡張されるたびに実装が揺れ、
システム全体としての一貫性を保つことが難しくなります。

そこで必要になったのが、
PDUを中心に据えた明確な境界設計 でした。

箱庭PDUアーキテクチャ解説シリーズを始めます

このシリーズでは、箱庭PDUを

• API仕様としてではなく
• 実装テクニックとしてでもなく

「どのような責務分離と思想で設計されているのか」
という視点から整理していきます。

なお、本記事はチュートリアルではありません。
コードの使い方を説明するものでもありません。

箱庭PDUを設計する過程で、

• 何に悩み
• どこで割り切り
• どの境界だけは壊さないと決めたのか

その記録として書いていこうと思います。

箱庭PDUの全体アーキテクチャ

これが全体アーキテクチャです。

箱庭PDUは、先に挙げた課題感
（アクセス権、転送方式、RPC、設定の一貫性、実装のばらつき）を
まとめて俯瞰して考えると、少なくとも3つの層に分けて扱わない限り、実装が破綻する という結論に至りました。

1つの層で

• データの意味
• PDUの流し方
• 通信方式の実装

を同時に扱おうとすると、
デモが増えるたびに判断が場当たり的になり、
結果として 実装がぐちゃぐちゃになります。

そこで箱庭PDUでは、

• 意味と実行権を扱う層
• PDUの転送を抽象化する層
• 実際の通信方式を実装する層

を、最初から明確に分離する設計を採用することにしました。

「では、最初からユースケースを決めて設計すればよかったのでは？」
と思われるかもしれません。

でも、箱庭では ユースケースを固定しない ことを、最初から前提にしています。
箱庭は、特定の用途に最適化するための仕組みではなく、
まだ見えていない未来のユースケースに対して開いていること を重視しているからです。

そのため、

• ユースケースが変わる
• 要求が揺れる
• 想定外の使われ方をする

ことを前提に、
何度でも設計を見直し、構造を整え直す という方針を取っています。

……はい、正直に言うと、
その結果として遠回りした部分もあります。
言い訳です。ごめんなさい。

ただ、その揺れの中でしか見えてこなかった境界があり、
それが今回整理する 箱庭PDUアーキテクチャ なのです。

次回に向けた自分へのメモ

一気に書くこともできるのですが、
それをやってしまうと、ブログの連載としては成り立たなくなってしまいます。

なので。
少しずつ思いを書き連ねていく、という形を取ろうと思います。

そして次回は、たぶんですが、
今回紹介した 3層構造 が、

• それぞれ 何を責務として持ち
• 何を持たないのか

について、整理して説明することになると思います。

次回をお楽しみに。