フィジカルAIとNode-RED

メタワーク

ここ数年、名古屋大学と一緒にメタワークというプロジェクトをやってます。詳細は実証実験の取材動画や記事をご覧ください。

数年、ロボティクスとAIについて考えてきた中で、私見ですがフィジカルAIにおけるNode-REDの立ち位置が見えてきた気がしたので整理してみました。

フィジカルAI＝ロボット制御ではない

フィジカルAIというと

• ロボットをどう動かすか
• どう学習させるか
• リアルタイム性はどうするか

といった話になりがちですが、実際に社会実装を考えると、もっと手前で悩むことが多いです。

例えば、

• オペレータが交代した
• 危険区域に人が入った（人感センサーが反応した）
• AIが「こう動かしたい」と提案してきた

こうした状態の変化に対して、「今、このロボットは動いていいんだっけ？」をどう判断するか、という部分です。

Node-REDの担当レイヤー

結論から書くと、Node-REDはロボットを「制御する」のではなく、Go/No-Go を決めるレイヤーを担当するのが最もしっくり来ると感じています。

• トルク制御 → ROS / DDS
• リアルタイム制御 → 専用ミドルウェア
• 状態・文脈・ルールの集約 → Node-RED

という役割分担です。

「人かAIか」を見るのではなく「状態変化」のみを見る

フィジカルAIの文脈では、

• 人が操作する
• AIが提案する
• センサーが割り込む

といった事象が混在します。

ここで「これは人の操作」「これはAIの判断」と分け始めると、設計が複雑になりがちなので「状態変化」しか見ない設計にするのがオススメです。

• オペレータ（人）が交代 → 状態変化
• 人感センサー反応 → 状態変化
• AIが提案 → 状態変化
• 日が暮れる → 状態変化
• バッテリーが減る → 状態変化

全て、状態変化イベントと捉えます。

制御判断に必要なのは「誰が言ったか」ではなく「どの状態に遷移したか」。
（もちろん、非常停止や安全規格上の制約は別レイヤーで担保される前提です）

幸いNode-REDには、その名もContextという機能があります。Persistent context（file / redis / db）で再起動時の記憶の保持を工夫しながらも状態管理に適してます。

ただし、監査ログには責任の所在が必要ですし、ロボット操作の履歴をティーチングデータとして再利用する際に状態変化を起こした主体の情報は重要ですので記録として捨てて良いとまでは言えません。

Go/No-Go は SpiceDB に任せる

SpiceDBは、ものすごくザックリいうと認可基盤を外出しできるOSSです。

ユーザーの権限制御するようなアプリケーションを開発したことがある方なら誰もが感じたことがあると思いますが、自前のDBなどで権限管理をした場合に独自ルールや設計で複雑になり過ぎてしまうような悩みに対する解決したアーキテクチャを、Googleが Zanzibarとして実装し、論文も発表しているようです。

SpiceDBはZanzibarにインスパイアされたプロダクトだそうです（他にもOpenFGAもあります）

そして、このSpiceDBは「ユーザーの権限管理」という前提さえもなくなっています。主体は「人」「AI」「ロボット（デバイス）」である必要はなく、設計次第では「状態」や「文脈（コンテキスト）」をエンティティとして扱うこともできます。

以下はSpiceDBの基本のデータ構造です。シンプルに言うと「ある主体」の「ある対象」の権限状態を管理しているだけです。

entity（主体: 人・AI・状態などを同列に扱う判断単位） → resource（対象） → permission（振る舞い可否）

※ SpiceDBの公式ドキュメントでは「subject」という用語が使われますが、
本記事では 人・AI・デバイス・状態・文脈を等価に扱うため「エンティティ」と呼んでいます

つまり、以下のように解釈可能です。

• ユーザーAがファイル1を閲覧可能（最もオーソドックスな例）
• AI1がサービスAへアクセス可能（主体は人じゃなくても良い）
• 状態Aの時にデバイス1は停止（状態をエンティティとして表現した結果）

この前提に立つと構成はかなりシンプルになります。

• Node-RED
  • イベントを受ける
  • イベントから状態を定義する
• SpiceDB
  • 定義した状態での対象の特定の振る舞いについての Go/No-Go を返す
• ロボット
  • Goなら動く
  • No-Goなら止まる

やはり、人かAIかは、認可判断には不要ですね。必要なのは状態と文脈だけ。主体（人 / AI / デバイス）はログや学習用に記録しておけば充分だと思います。

ちなみに、Node-REDからSpiceDBはRESTかgRPCで扱えますので、HTTP / gRPC ノードを使えば良いです。

全体像

ざっくりした構成は以下のようになります。

イベント
  - 人の操作
  - AIの提案
  - センサー反応
        ↓
Node-RED
  状態・文脈の正規化
   HTTP / gRPC ノードなど
        ↓
SpiceDB
  Go / No-Go 判定
        ↓
ロボット
  HTTP / MQTT / debug ノードなど

Node-REDから先はROS2でもPLCでも差し替え可能です。

なぜこの構成が良さそうか

個人的に良いと思っている点は以下です。

• 制御ループに意味論を持ち込まない
• 「なぜ止めたか」を後から説明できる
• Go/No-Go の履歴がそのまま学習データになる

特に最後の点は、冒頭のメタワークに寄った話ではありますが、メタワークによって蓄積された遠隔操作データを、ロボットの完全自律化のためのティーチングデータとして再利用する際、非常に重要だと思いました。

• 判断ログが溜まり
• 文脈付きのデータが溜まり
• 自動化できる範囲が広がる

という構図ですかね。

まとめ

• Node-REDは状態と文脈を扱うのが得意
• Go/No-Go を状態遷移で判断する
• 人・AI・センサーなど主体を意識した設計は複雑化する

まあ、率直に言うと「フィジカルAI」分野でもNode-REDが活躍できる余地は充分にあるな〜と思ってます。