インディーゲーム展示の試遊PCを1画面から監視・リセットする仕組みを考える
目次
昨日インディーゲームの即売イベントに出展してきた。
展示したのは 十秒奪取! で、ありがたいことに試遊が盛況で、途中で家まで戻って試遊PCを増やすくらいの対応をした。
そこで運営してて困ったことが2つあって、今すぐ作る気はないけど次に同じ規模の出展をするときの案として頭の中を整理しておく。
作るとしたらリセットシステムを先に組んで、映像監視は方式を決めてから機材を調達する順番になりそう。
困ったこと
会場の通路は広く取られているので、ブース前に立ちっぱなしだとPVや実プレイ画面が後ろの通行人から見えなくなる。
基本的には試遊台の反対側、つまり展示スペースの出展者側に引いて立っているべきだ。
ところが出展者側に立つと、2つの問題が出る。
1つ目はPC初期化。
このゲームはタイトル画面でセーブデータが残ってしまう作りなので、放置すると次のお客さんが前の人の続きから入ってしまう。
毎回試遊台側に回り込んで、ゲームを落として、セーブを消して、再起動して、を繰り返す必要がある。

裏側のこの感じを見てると、まあリセットしたいよなという気持ちになる。回り込まずに済む手段が欲しい。
2つ目は画面の確認。
出展者側からだと試遊モニターが角度的に見えない。
お客さんがどこで詰まってるか見て声をかけたいし、クリアの瞬間に一緒に盛り上がりたい。
要するに、出展者側に立ったまま試遊PC群をリモートで初期化したいし、各PCのプレイ画面も手元で確認したい。
ほしいもの
整理するとこう。
- 出展者側の1画面で全試遊PCの映像をリアルタイムに見られる
- プレイ終了後にその台だけ強制リセット(プロセスkill → セーブ削除 → ゲーム再起動)をかけられる
- PC自体が不調になった場合は手動で再起動するが、再起動後は自動で監視に再接続される
- 会場のLAN・Wi-Fiは使えない前提。自前ルータで閉じたLANを組む
- ブースに置けるモニターは1台までなので、映像も状態表示もここに集約する
- 操作系は誰が触っても事故らない物理コンソールにする(自分以外のサークルメンバーが店番に入る前提)
試遊PCは自分で用意できるのが3台までで、ブースのスペース的にも普通の同人即売やゲームショウだと4台は置けない。
3台前提で全機材選定する。
リセットシステム
中央管理サーバを1台立てて、各試遊PCに常駐エージェントを入れる。
操作系はサーバに繋いだ物理コンソール(Stream Deck)に集約し、状態は「物理コンソールのキーLCD」と「マルチビューモニターの中の管理UIタイル」の2系統で見られるようにする。
こうすると店番交代時に「画面のここを触る」みたいな口頭引き継ぎが要らない。
graph TD
Router[自前Wi-Fiルータ<br/>閉じたLAN]
PiServer[Raspberry Pi 5<br/>管理サーバ + Companion<br/>+ Chromium kiosk]
Console[Stream Deck<br/>操作・状態表示<br/>USB接続]
MV[マルチビューワー<br/>4入力1出力]
Monitor[出展者側モニター<br/>4分割表示]
PC1[試遊PC 1<br/>Windows + 常駐エージェント]
PC2[試遊PC 2<br/>Windows + 常駐エージェント]
PC3[試遊PC 3<br/>Windows + 常駐エージェント]
Router --- PiServer
Router --- PC1
Router --- PC2
Router --- PC3
PiServer -- USB --> Console
PiServer -- HDMI --> MV
PC1 -- HDMI --> MV
PC2 -- HDMI --> MV
PC3 -- HDMI --> MV
MV -- HDMI --> Monitor
PiServer -.WS.-> PC1
PiServer -.WS.-> PC2
PiServer -.WS.-> PC3
試遊PCのHDMIは試遊用モニターと共有したいので、実際にはPC側にHDMIスプリッターを噛ませて1出力をマルチビューワーに、もう1出力を試遊モニターに送る。配線詳細は後述。
サーバはRaspberry Pi 5で十分。
試遊PCが10台あってもWebSocket接続を捌くだけなのでCPU負荷は無い。
有線LANポートが付いてるのでルータ直結にしておくと安定する(試遊PC側もWi-Fiより有線にしたいが、現実的には台数とケーブル取り回しを見て判断)。
リセットの流れ
ボタンを押してからゲームが立ち上がり直すまでのシーケンス。
sequenceDiagram
participant Me as 出展者
participant Deck as Stream Deck
participant Server as 管理サーバ<br/>(Pi + Companion)
participant Agent as エージェント<br/>(試遊PC)
participant Game as ゲーム本体
participant UI as 管理UIタイル<br/>(Pi → マルチビューワー)
Me->>Deck: PC1リセットキー押下
Deck->>Server: POST /reset {pc: "pc1"}
Server->>Agent: WS: {cmd: "reset"}
Agent->>Game: taskkill /f /im 10secondsdash.exe
Agent->>Agent: セーブデータディレクトリ削除
Agent->>Game: ゲーム再起動
Agent->>Server: WS: {state: "running"}
Server-->>Deck: キーの色を「待機中」に更新
Server-->>UI: 該当タイルを「準備完了」に更新
管理UIをマルチビューの1タイルに乗せる
Pi本体のHDMI出力にChromium kioskで管理画面を全画面表示しておき、それをそのままマルチビューワーの空き入力に挿す。
試遊PC×3 + Pi UI×1 = 計4入力で、4分割マルチビューにそれぞれが収まる。
管理UI側に置く情報はこれだけ。
- 試遊PCごとに1行(PC名、接続状態、ゲーム状態、最後のリセットからの経過時間)
- 操作ボタンは置かない(モニターは触らない前提なので)
- 文字は遠目で読める太さ・サイズ、色は待機中=緑、プレイ中=黄、オフライン/異常=赤で塗り分け
物理操作はStream Deckだけ、モニターは「映像 + 状態を一望する」だけ、と役割が明確になる。
セットアップ時やトラブル時に管理UIを直接いじりたいときは、別端末(手元のスマホやノートPC)からPiのIPに直接ブラウザでアクセスする。
試遊PC側エージェント
Windowsのスタートアップに登録しておく常駐スクリプト。
Pythonでも.NETでもいいが、依存を減らすならPowerShell + WebSocketライブラリが軽い。
最低限の責務はこれだけ。
- 起動時に管理サーバへWebSocket接続
- ハートビート送信(数秒おき)
resetコマンドを受け取ったら:taskkill /f /im <ゲーム名>.exeRemove-Itemでセーブデータフォルダを削除- ゲームのexeを再起動
- ゲームプロセスの生存をポーリングしてサーバに状態を送る
ゲーム再起動後の「タイトル画面に戻ったかどうか」までは検知できないが、プロセスが起動してれば実用上は問題ない。
心配ならゲーム側にIPCを仕込んで「タイトルに戻った」イベントを送らせるのが理想だが、すでにリリース済みのゲームに手を入れるかどうかの判断になる。
自動再接続
PC再起動後はこう動く。
- Windowsログオン時にスタートアップでエージェントが起動
- WebSocket接続が切れていたら指数バックオフで再接続を試みる
- 管理サーバ側はそのPCを「オフライン」表示しておき、接続が戻ったら自動で「オンライン」に戻す
ログオン自動化のために、試遊用Windowsアカウントは自動ログオン設定にしておく(netplwiz または Autologon ツール)。
これ自体は今までもやってる運用なので追加コストは無い。
モニターに乗せる4入力
試遊PC×3 と 管理UI×1 の合計4ソースを、1枚の出展者モニターに集約する。
方法はネットワーク経由のストリーミングか、HDMIで物理集約するかの2択。
NDI案を一旦考える
最初に思いつくのはNDI(Network Device Interface)。リセット通信用に閉じたLANを組んでいるので、その上に映像を乗せるのが自然に見える。
各PCにOBSとDistroAVプラグイン(旧obs-ndi。OBS公式・NDI公式どちらでもないコミュニティ製、最新版はOBS 31+ / NDI 6 Runtime必須)を入れてNDI出力すれば、受け側のNDI Studio Monitorで全台の映像を見られる。Studio Monitor単体の「Move to Quadrant」機能で4分割表示まではいける。
ただし今回の構成だと相性が悪い。
| 問題 | 中身 |
|---|---|
| 管理UIがNDIに乗せにくい | NDI Studio MonitorはNDIストリームしか映せない。Pi上のWeb UIをタイルとして並べるには、受信側にブラウザを開けるPCを別途置く必要があり、「管理用PC」を増やしたくない前提に反する |
| ゲームPC側の負荷 | OBS+DistroAVで1080p60のフルNDIを送ると1台あたり約100〜150Mbps。ギガビットLAN必須で、CPU/GPUもそれなりに食われる。ゲーム本体のフレームレートに影響しかねない |
| ディスカバリの脆さ | mDNS依存なので自前スイッチ/ルータでマルチキャストやIGMPスヌーピングを切る設定にしてないか毎回確認しないといけない |
NDIは「PC側に何か仕込みたくない」「ゲーム性能を1mmも削りたくない」「機材を増やしたくない」のどれにも逆行するので、HDMI物理集約に振るのが今回の答え。
HDMIで4入力を1モニターに
各試遊PCのHDMI出力をスプリッターで分岐し、1本は試遊モニターへ、もう1本をマルチビューワーに送る。
マルチビューワーの空き入力にPi 5のHDMI出力(Chromium kioskの管理UI)を挿せば、4分割の1タイルが管理UIになる。
graph TD
PC1[試遊PC 1] --> S1[HDMIスプリッター]
PC2[試遊PC 2] --> S2[HDMIスプリッター]
PC3[試遊PC 3] --> S3[HDMIスプリッター]
Pi[Raspberry Pi 5<br/>Chromium kiosk]
S1 --> M1[試遊モニター 1]
S2 --> M2[試遊モニター 2]
S3 --> M3[試遊モニター 3]
S1 --> MV[マルチビューワー<br/>4入力1出力]
S2 --> MV
S3 --> MV
Pi --> MV
MV --> EM[出展者モニター<br/>4分割表示]
ソフトウェアの仕込みがゼロで、ゲーム側にもPC側にも何も入れなくていい。
遅延もほぼゼロ、映像が来ないときの原因切り分けがケーブルの抜き差しだけで済む。
試遊PCをノートにすればスプリッターがいらない
試遊PCを15インチクラスのノートにする手もある。
ノートの内蔵モニターをそのままお客さんの試遊画面として使い、HDMI出力をミラー設定にして直接マルチビューワーに刺せば、HDMIスプリッター×3も外付け試遊モニター×3も要らない。
ノート(内蔵画面) ← お客さんの試遊視点
└─ HDMI out(ミラー) → マルチビューワー入力
メリットは大きく3つ。
- HDMIスプリッター×3が不要(約¥9,540節約)
- 外付け試遊モニターを買い足さなくていい
- ケーブル本数が半分になって搬入・撤収が早い
デメリットは2つ。
- 画面15インチはデスクトップ+大型モニター展示と比べるとやや小さい
- ゲーム性能を出すノートを揃えるコストは別途(ただし手持ち資産で賄えることが多い)
同人即売など机の専有面積が限られるブースでは、ノート構成のほうが現実的。十秒奪取みたいな短時間プレイのゲームなら15インチでも体験面の不利は小さい。
マルチビュー機材の選択肢を整理
「4入力を1モニターにマルチビュー表示する」を満たす機材はこの2つ。
| 機材 | マルチビュー出力 | 配信機能 | 価格 |
|---|---|---|---|
| ELEVIEW EHD-707N(単体マルチビューワー) | ◯ | ✕ | ¥4,795 |
| ATEM Mini Pro(ビデオスイッチャー+マルチビュー) | ◯(10ビュー) | ◯(RTMP/SRT+USB録画) | ¥48,029 |
「ATEM Mini無印が安いんじゃないか」と思いがちだが、これは罠。
ATEM Mini無印は4入力1出力のスイッチャーであって、マルチビュー出力機能自体がない(4入力のうち1つを選んで1出力に流すだけ)。マルチビュー機能はPro以上にしか付かない。
つまりATEM系を「安いから」で選ぶと無印では今回の用途を満たせない。
配信は今回の議題からは外す
ATEM Mini Proを入れれば、マルチビュー機材としての役割に加えて、イベント中にTwitch/YouTubeに試遊風景をライブ配信する運用も同じ機材1台で組める。
最初はそれも込みで考えたが、整理した結果、配信運用は今回のスコープから外す結論にした。
理由はこのあたり。
- 試遊は常時走らない。お客さんがプレイしてる時間は意外と短く、空き時間は試遊モニターでOPやPVを流してるだけになる。配信に出す絵をどう構成するか(プレイ中はそのPCの映像、空きのときはPVを流す、みたいな切替設計)を別に詰める必要があり、今のリセット系設計とは話が分かれる
- 同人即売・インディー系イベントで勝手に配信していいかが不透明。会場規約・隣接ブースへの配慮・お客さんの映り込み許諾など、運営側に確認しないと判断できない論点が多い
- ゲームショウ規模なら別。プレスやストリーマー受け入れが前提のイベントなら、ブース全景+プレイ画面の切替運用は意味がある。同人ベースの今の規模感ではオーバー
ということで今回はマルチビュー機材として ELEVIEW に振る。
将来配信運用まで含めるフェーズが来たらATEM Mini Proに乗り換える、という順送りで考えておく。
十秒奪取の場合
十秒奪取は1面が文字通り十秒で終わるので、映像のリアルタイム性が効いてくる。
ハードウェアマルチビューなら遅延がほぼゼロで、10秒のプレイ中も画面の色味とレイアウトから状態が分かる。
数秒おきのスクリーンショットだと1プレイが丸ごとスナップショットの隙間に収まってしまうので、軽量化として「キャプチャを送る」方向は今回ボツ。
操作コンソールはStream Deck
最初はタブレットを操作端末にする案も考えたが、自分以外の人が店番に入る時間帯がある前提で考え直すと物理コンソール一択になる。
タブレットだと操作ミスのリスクが多い。
- 違うタイルを誤タップして他のPCをリセットしてしまう
- スワイプでブラウザを閉じる、別タブに移動する
- 通知バナーが出てそっちを触ってしまう
- 画面ロックがかかって解除手順が分からない
物理ボタンなら「このキー = このアクション」で固定で、店番の人に「ここ押すだけ」で引き継げる。
触っていいのはコンソールだけ、状態はモニターを見るだけ、と役割が明確になる。
Stream Deck の何が向いているか
- キーごとにLCDが付いていて任意のラベル・アイコンを表示できる。「PC1 リセット」「全台リセット」みたいな表示が物理ボタンに直接出る
- Pi側から各キーに任意の画像を書き込める。状態が変わったタイミングでPiが「このキーは今プレイ中なので黄色+プレイ中ラベル」「このキーはオフラインなので赤」と画像をUSB経由でpushする。コンソール自身が状態を判断するわけではなく、Piが押下イベントを受けて、Piが画像を返す、の単純な往復。これはElgato公式SDKと
python-elgato-streamdeckで標準的にサポートされた使い方で、MK.2もコードレベルで対応済み - Bitfocus Companion という橋渡しソフトがLinux/ARM64で動く。Companion経由でPi上から制御でき、内部で
python-elgato-streamdeckを使うのでLinux公式非対応のElgatoでもCompanionレベルで動作実績は豊富
15キーのMK.2で3台構成は余裕。「PC1〜PC3のリセット」「全台リセット」「ページ切替・状態表示用キー」を割り振っても半分以上空く。
6キーのStream Deck Miniでもギリギリ収まるが、ラベル領域とキー間隔を考えるとMK.2のほうが店番に渡したときのミスタッチが減る。
手持ちのMX Creative Consoleで済ませる場合
自分の手元にはLogicool MX Creative Consoleもあるので、Stream Deckを買わずにこっちで組む選択肢もある。
この用途で要るのは「キーを押したら入力イベントが上がる」「Pi側からキーごとに画像を1枚書き込める」の2点。Keypadの9キーは個別LCDなので、ハードウェア的には可能。
ただしここが重要な差で、MX Creative Consoleの公式ソフト(Logi Options+)には外部から動的にキー画像を書き換える機能はない。Logi Options+はあくまで「静的にプロファイルを組んで設定する」ツール。
動的書き込みを成立させているのはサードパーティのOSS実装で、HIDを直叩きしてキーに画像をpushする @julusian/node-logitech-mx-creative-console があり、Bitfocus Companion v4.1(2025-09)はこのOSSをラップして公式機能に取り込んでいる。
つまり「機能としては成立する」が、ベースになっているのはリバースエンジニアリング由来のOSS。Stream DeckのElgato公式SDKと比べると安定度・情報量に差が出る。
これを踏まえてのPi+Companion運用比較。
| 項目 | Stream Deck | MX Creative Console |
|---|---|---|
| Companionサポート | 古くから対応、Linux/Pi含めて実績豊富 | v4.1.0(2025-09)で対応追加。新しいので動作報告がまだ薄く、Issueも残る |
| Linux/Pi上の制御ライブラリ | python-elgato-streamdeck、実績豊富 | @julusian/node-logitech-mx-creative-console、コミュニティ実装 |
| 公式Linuxサポート | なし(コミュニティ実装が成熟) | なし。Logi Options+はWin/Mac限定 |
| 詰まったとき検索で出る情報量 | 多い | 少ない |
事故りたくないなら素直にStream Deckを買ったほうが楽。
既にMX Creative Consoleを持っているなら、CompanionをMacかWindowsに移してそこからネットワーク越しにPi上のサーバを叩く構成にする逃げ道もある。Pi側はクリーンに保てる代わりに、コンソール用のホストPCを1台確保することになる。
Bitfocus Companion でつなぐ
Stream Deck自体はElgato純正のソフトがWindows/Mac前提なので、PiにつなぐにはBitfocus Companionを経由させる。
CompanionはStream Deckを認識して、各キーに「HTTP GET/POST」「WebSocket送信」「カスタムスクリプト実行」などのアクションを設定できる。
設定の流れはこう。
- Pi 5に Companion の ARM64版をインストール
- Stream Deck をUSB接続
- CompanionのWeb UIにブラウザでアクセス(Pi上 or 別PCから)
- キーごとに「Generic HTTP」アクションを作って
POST http://localhost:3000/reset?pc=pc1を割り当て - キーラベルに「PC1 RESET」、押下時の色を黄色などに設定
- 状態フィードバック用に、サーバ側からCompanionの内部APIに向けて変数を更新する仕組みを作る
ここの「状態フィードバック」だけは少し凝る必要があるが、最初は押下機能だけ実装して、フィードバックはあとから付け足すで十分。
作るとしたらどれくらいの規模感か
| コンポーネント | 内容 |
|---|---|
| Pi側サーバ | Express + ws ライブラリ。100行未満で動くレベル |
| Windowsエージェント | PowerShellで150行くらい。プロセス監視とWebSocket再接続の実装が主 |
| 状態表示Web UI | Vanilla JSかAstroで小さく作って静的配信。WebSocketで状態購読、Chromium kioskで全画面表示 |
| Stream Deck設定 | Bitfocus Companion上でキーごとのHTTPアクションを定義。設定はGUIで完結 |
運用するときに想定しておくリスク
| リスク | 対策 |
|---|---|
| ルータが落ちる | 予備ルータを持参。USB給電対応の小型ルータならモバイルバッテリーで動く |
| エージェントがハング | 管理画面側からハートビート途絶を検知してアラート表示。最終手段として試遊台側の物理キーボードでAlt+F4 |
| Pi自体が落ちる | Pi復旧中も試遊PCは単独で動作する設計にしておく。エージェント側は接続が切れてもゲームは触らない |
サーバが落ちても試遊そのものは止めない、が鉄則。
管理機能はあくまで運営側の都合で、お客さんから見た試遊体験を巻き込んではいけない。
ざっくり総額(2026-05時点・Amazon JP)
実際に作るとしたら腹を決める材料として、新規購入で揃える前提の値段感も書き残しておく。
記事に出てる機材本体
| 機材 | 単価 | 必要数 | 小計 |
|---|---|---|---|
| Raspberry Pi 5 8GB | ¥16,800 | 1 | ¥16,800 |
| UGREEN HDMIスプリッター | ¥3,180 | 3(試遊PC×3分) | ¥9,540 |
| ELEVIEW マルチビューワー | ¥4,795 | 1 | ¥4,795 |
| ATEM Mini Pro(マルチビューワー代替) | ¥48,029 | 1 | ¥48,029 |
| Elgato Stream Deck MK.2 | ¥22,980 | 1 | ¥22,980 |
周辺で要るもの(記事に出てないけど買う、または手持ちで済ませる)
| 機材 | ざっくり |
|---|---|
| microSD 64GB(Pi用) | 約¥1,500 |
| Pi 5公式PSU | 約¥2,200 |
| Pi 5ケース+ヒートシンク | 約¥1,500 |
| HDMIケーブル ×6本(試遊PC→スプリッター×3、スプリッター→試遊モニター×3、スプリッター→MV×3、Pi→MV、MV→出展者モニター。短長混在) | 約¥3,600 |
| Wi-Fiルータ(小型・自前LAN用) | 約¥6,000 |
| 出展者用モニター 15〜22インチ | ¥15,000〜25,000 |
| 周辺小計 | 約¥30,000〜40,000 |
パターン別の総額
| パターン | 内訳 | 合計レンジ |
|---|---|---|
| A. Stream Deck新規+ELEVIEW(今回の本命構成) | 本体¥54,115 + 周辺¥30〜40k | ¥84,000〜94,000 |
| B. 手持ちMX Creative Console利用+ELEVIEW(最安) | 本体¥31,135 + 周辺¥30〜40k | ¥61,000〜71,000 |
| C. 将来配信フェーズに乗り換え(Stream Deck+ATEM Mini Pro) | 本体¥97,349 + 周辺¥30〜40k | ¥127,000〜137,000 |
C案は前述の通り、配信を含めるフェーズになったらELEVIEWからATEM Mini Proに差し替えるイメージで、今回のスコープではない。
削れる箇所はこのあたり。
| 対象 | 内容 |
|---|---|
| 試遊PCをノート構成にする | HDMIスプリッター×3(¥9,540)と外付け試遊モニター×3が丸ごと不要 |
| 出展者モニター | 余ってるPCモニター持ち込みで¥0 |
| Wi-Fiルータ | 自宅予備の転用で¥0 |
| HDMIケーブル | 既に何本か持ってる前提なら半分くらい削れる |
ノート構成+手持ちMX Creative Console+ELEVIEW、で攻めれば4万円台まで落とせる。
本命ラインで9万コース、これで作るかどうか判断する数字。
十秒奪取!Nintendo Switchでも出る予定なので、買ってね。