ActionCable の相手は、いつもブラウザとは限りません。センサーを積んだ Raspberry Pi をコンシューマにすると、Rails はデバイス群にコマンドを配り、結果を受け取る「制御プレーン」になります。
本発表では、その設計を実機の Raspberry Pi を繋いだ動くシステムで紹介します。物理デバイスを Device モデルと状態機械で扱い、heartbeat と定期照合で生死を追いかける。ActionCable を双方向の transport にして、結果は冪等に取り込む。ActiveJob で「実行先が物理デバイス」なジョブを組み、落ちる前提でリトライとバックプレッシャを設計する——おなじみの道具だけで、ここまで作れます。
山場は「リアルタイムで Turbo Streams と生 ActionCable をどう使い分けるか」。毎秒届くスペクトルを HTML で撒くと転送量は約26倍、毎フレーム257個の DOM ノードが生まれます。実測ベンチから、低頻度の状態変化は Turbo Streams、高頻度の数値ストリームは生 ActionCable + canvas という判断基準を導きます。通知やダッシュボードなど、ふつうの Rails 開発にそのまま効く勘所です。
ライブデモとともに、見慣れた Rails の意外な射程をお見せします。
株式会社スタジアム（スタメングループ）で Rails による Web サービス開発をしているエンジニアです。RubyKaigi 2026 では LT「The Joy of Talking to Hardware in Ruby」に登壇しました。個人では GPU まわりの効率化やエッジ端末でのプログラミングにも取り組み、mruby から GPU(Vulkan) を扱う gem「mruby-gpu-narray」を開発しています。最近は Raspberry Pi を ActionCable でつなぎ、Rails を分散システムの制御プレーンとして使う実験に取り組んでいます。Hotwire・ActionCable・mruby・GPU が好きです。