結論：SwitchBotは「完成品」より「体験を試す道具」として面白い
SwitchBotは、映像や音と厳密に同期するリアルタイム制御装置の代替ではありません。一方で、光・風・物理動作などを短時間で試し、「この体験は本当に面白いか」を確認するプロトタイピングには使いやすい道具です。
PHYSICAL I/O — 既製品で扱える4つの現象
カラーバルブ・照明
色・明るさ・ON/OFFで状態を可視化
スマートプラグ＋扇風機
映像や状態の変化を肌へ直接届ける
Bot等による物理操作
既存機器の物理ボタンを直接押す
人感・開閉・環境センサー
人の接近や空間変化をトリガーに
メディアアートやインタラクティブな展示をつくろうとすると、どうしても専用の機材が必要だと思いがちだ。
ArduinoやESP32を使う。
DMXやArt-Netで照明を制御する。
センサーから値を取得し、モーターやリレーを動かす。
もちろん、本番の展示や精密な制御では、こうした技術が必要になる。
ただ、作品のアイデアを試す段階から、すべてを本番仕様でつくる必要があるのだろうか。
そこで意外と使いやすいのが、SwitchBotだ。
カラーバルブなら、光。
スマートプラグに扇風機をつなげれば、風。
Botを使えば、物理スイッチ。
センサーを使えば、人の存在や環境の変化を入力にできる。
SwitchBotは本来、家電をスマートフォンなどから操作するためのスマートホーム製品である。
けれど見方を変えると、
PCの中で起きていることを、光や風、動きとして現実空間へ出すための簡易I/O
として使うことができる。
重要なのは、SwitchBotが高性能な制御装置だからではない。
むしろ逆だ。
できることには制限がある。
制御経路によっては、反応にも遅れが生まれる。
だからこそ、面白い。
技術の制約を知り、その制約を前提に体験を設計する。
SwitchBotは、その考え方を試すための道具としてかなり使いやすい。
SwitchBotは、リアルタイム制御装置とは少し性格が違う
まず押さえておきたいのは、SwitchBotをDMXやArt-Net、OSC、MIDIなどと同じ感覚で扱わない方がよいということだ。
例えばTouchDesignerの映像に合わせて、毎フレーム照明を変化させたい。
音楽のキックにぴったり合わせてライトを点滅させたい。
このような厳密な同期が必要な表現では、SwitchBotは第一候補にはなりにくい。
クラウドAPIやネットワークを経由する構成では、通信状況や制御経路によって遅延が生じる可能性がある。
つまり、
「プログラムから動かせる」ことと、「リアルタイムに同期できる」ことは同じではない。
ここを分けて考えることが重要になる。
技術は「時間解像度」から選ぶ
インタラクティブ表現では、
「その技術で何ができるか」
だけでなく、
「どのくらいの速さで反応する必要があるのか」
を考えると、技術を選びやすくなる。
例えば、人が部屋に入ったら照明が変わる。
ボタンを押したら、少しして扇風機が回る。
言葉を入力すると、光で返事が返ってくる。
こうした体験なら、必ずしもミリ秒単位の反応は必要ない。
一方で、音楽のビートや映像のフレームに同期させるなら、もっと高い時間精度が必要になる。
ざっくり整理すると、こんな違いがある。
| 必要な反応 | 体験例 | 技術の考え方 |
|---|---|---|
| 数秒程度でも成立 | 人が来たら光が変わる、風が吹く | SwitchBotなどでも試しやすい |
| 数百ms程度 | 操作に対して自然に反応する | ローカル通信やOSCなどを検討 |
| 厳密な音・映像同期 | ビート同期、フレーム同期 | MIDI / OSC / DMX / Art-Netなどを検討 |
どの技術が一番速いかではなく、その体験に必要な時間解像度はどのくらいなのかから考える。
もちろん実際には、システム構成やネットワークによって条件は変わる。
重要なのは、最高性能を選ぶのではなく、目的から必要な性能を逆算することだ。
これはGPUやCPUを選ぶときと少し似ている。
インタラクティブ表現でも同じである。
ラグは、必ずしも欠点ではない
そして、遅延があるから作品に使えない、ということでもない。
例えば、鑑賞者が言葉を入力する。
少し間がある。
その後、遠くに置かれた照明が点滅して返事をする。
この場合、反応が少し遅れることは、必ずしも体験を壊さない。
むしろ、
- 「何かが考えている」
- 「遠くへ信号を送っている」
- 「返事を待っている」
といった感覚につながることもある。
技術的にはレイテンシーでしかなかったものが、体験の中では「間」になる。
ラグをなくすことだけが技術ではない。
ラグがあるなら、その時間まで含めて体験を設計すればいい。
技術の制約を消すのではなく、制約を演出へ変換する。
メディアアートでは、そういう考え方もできる。
コンセントを制御すると、「風」も扱える
SwitchBotで面白いのは、スマート電球のような専用デバイスだけではない。
個人的に使いやすいと感じるのが、ON/OFFできるスマートプラグだ。
例えば、電源を供給するとそのまま動作するタイプの扇風機を接続する。
すると、以下のような制御の流れをつくることができる。
FLOW — ソフトウェアから身体感覚への変換
画面を変えるのではない。空気を動かす。
ここまで来ると、体験の質が一気に身体側へ移っていく。
光は目に届く。
音は耳に届く。
風は皮膚に届く。
PCの中にあったデータが、身体で感じられる現象へ変わる。
これはかなり面白い。
しかも扇風機そのものが、スマートデバイスである必要はない。
電源のON/OFFで動く既製品なら、作品の出力装置として転用できる可能性がある。
つまりスマートプラグは、
「電気で動くものを、作品の出力へ変換する」
非常にシンプルなインターフェースとして考えることができる。
- 定格容量の確認： SwitchBotプラグミニ等の定格電力（最大1500W・15A等）を必ず確認し、ヒーターや大電力機器など熱を持つ機器の制御は行わないでください。
- 機器の起動挙動： 電源プラグ通電でそのまま動く「メカニカルスイッチ式」機器と、通電後に電子ボタン押し下げが必要な機器では挙動が異なります。事前の通電テストが必要です。
- 適合性： すべての電化製品が急な通電・遮断に適しているわけではありません。精密機器や故障リスクのある機器は接続しないでください。
- 本番・無人展示の設計： ギャラリーでの無人運転や長期間の展示運用を行う場合は、過熱・漏電・通信途絶時のフェイルセーフを含む専用の安全設計を行ってください。
光、風、動き。既製品を作品のI/Oとして読み替える
SwitchBotをメディアアートで考えるとき、重要なのは製品カテゴリーではない。
「何を出力できるか」で考えた方が面白い。
例えば、
光
カラーバルブや照明。
色や明るさ、ON/OFFの変化を、作品の状態に結びつける。
風
スマートプラグと扇風機。
鑑賞者の操作や映像の状態に応じて、身体へ風を届ける。
動き
SwitchBot Botなどによる物理スイッチ操作。
既存の機器を、直接改造せず作品の一部にできる可能性がある。
センサー入力
人の存在や環境の変化を受け取る。
鑑賞者が近づいたら何かが起きる、といった入口になる。
こう考えると、SwitchBotはスマートホーム機器というより、
既製品をフィジカルコンピューティングへ持ち込むための接着剤
のようにも見えてくる。
「風が吹いたら面白いか」を、先に試す
SwitchBotが特に便利なのは、プロトタイピングだ。
例えば、
「映像が変化した瞬間に、鑑賞者へ風が届く作品をつくりたい」
と思ったとする。
本番システムなら、マイコン、リレー、電源、モーター制御、安全設計などを含めて、きちんと構築する必要があるかもしれない。
でも企画初期で最初に確認したいのは、
そのシステムが技術的に美しいか
ではない。
風が吹いたとき、その体験が本当に面白いか
である。
それならまず、SwitchBotと市販の扇風機で試せばいい。
作品の状態が変わる。
少しして扇風機が回る。
実際に身体へ風が届く。
そこで初めて、
- 風量は十分か。
- モーター音は邪魔ではないか。
- 風が届くまでの時間をどう感じるか。
- 突然吹く方がよいのか。
- 長く吹く方がよいのか。
といったことが分かる。
画面の中だけでは確認できないことが、物理世界へ出した瞬間に見えてくる。
つまり、
技術検証より先に、体験仮説を検証できる。
ここにSwitchBotを使う大きな価値がある。
プロトタイプと本番は、同じ技術でなくていい
プロトタイプでSwitchBotを使ったからといって、本番展示でも使い続ける必要はない。
試した結果、
「もっと反応速度が必要だ」
と分かれば、ArduinoやESP32などへ移行すればいい。
より精密な照明制御が必要なら、DMXやArt-Netを使う。
音や映像と低遅延で連携したいなら、OSCやMIDIなども検討する。
ROADMAP — 要求精度に応じた技術の置き換え
※右へ進むほど上位互換という意味ではありません。要求される時間精度や安定性に応じて技術を選び直します。
最初から最後まで、同じ技術を使う必要はない。
プロトタイプに必要なのは、
本番品質ではなく、仮説を確認できる最低限の解像度
だからだ。
この考え方を持っていると、作品開発はかなり速くなる。
「何ができないか」を知ることも、技術力である
生成AIがコードを書き、APIの使い方まで教えてくれるようになった。
「どう実装するか」のハードルは、以前よりかなり下がっている。
だからこそ、これからより重要になるのは、
どの技術を、どの体験に使うか
という判断だと思う。
SwitchBotは即時性に限界がある。
DMXは照明制御に強い。
OSCは柔軟に値を送れる。
MIDIは音楽機器との連携に強い。
マイコンを使えば、より低いレイヤーまで制御できる。
それぞれに得意なことと、不得意なことがある。
技術について知るというのは、APIの書き方を暗記することだけではない。
- どのくらい速いのか。
- どこまで制御できるのか。
- どこで不安定になるのか。
- 何を任せるべきではないのか。
そうした境界を知ることでもある。
そして、その境界が分かっているからこそ、体験から逆算して技術を選べる。
制約を消すのではなく、制約から設計する
メディアアートでは、新しい技術そのものが作品のアイデアになることがある。
でも、技術の性能を最大限に引き出すことだけが表現ではない。
遅れる。
動作が単純である。
細かな制御ができない。
そんな制約があったとしても、その条件の中でしか生まれない体験がある。
SwitchBotは、本格的なリアルタイム制御装置の代わりではない。
しかし、
PCの中にあるアイデアを、簡単に物理世界へ出してみる
という用途では、とても便利だ。
光をつける。
風を起こす。
何かを動かす。
人の存在を受け取る。
まず試してみる。
そして体験として可能性が見えたら、必要に応じて技術を置き換えていく。
それでいい。
良い体験づくりに必要なのは、
「何ができるか」をたくさん知っていることだけではない。
「何ができないか」を理解し、その制約まで含めて設計できること。
その意味でSwitchBotは、単なるスマートホーム製品ではなく、
技術と体験の境界を考えるための、かなり面白いプロトタイピングツール
なのだと思う。