WebUI依存のキオスク運用は本当に辛いのか？メモリ8GB機で戦う現場のリアル（要検証）

プリダンのキオスク端末は、イベント会場のブース内に持ち込んで朝から夕方までノンストップで来場者をさばく**「物理展示機」**です。

現在はフロントエンドを Web 技術（TypeScript + Bun + Vite + Chromium/WebView）で構築していますが、現場運用を重ねるうちに、開発陣の間で深刻な議論が巻き起こっています。

「WebUIに依存してるの、現場のハードウェア的にめちゃくちゃ重荷になってない……？」 「そもそも展示機PCのメモリ、8GBしかないんだけど！！」

今回は、自作キオスク端末における「WebUIの功罪」と、メモリ8GBという過酷な現場のリアルについて整理してみます。

現場の制約：展示機ミニPCは「メモリ8GB」の戦場

木工ブース内に収めるため、PCは小型の省スペース・ミニPCを採用しています。 しかし、予算と調達の都合上、マシンの搭載メモリはわずか8GB。

この「8GB」という限られたメモリ空間の中で、以下のプロセスがひしめき合って同時稼働しています。

1. Rust コントローラー (Axum + Tokio): メモリ消費数十MB。非常に優秀で省エネ。
2. Python AI エンジン (FastAPI + MediaPipe): 顔検出・美化モデル。起動だけで数百MB〜1GB以上を確保。
3. Frontend (タブレット操作画面): Chromium / WebView インスタンス。
4. Monitor UI (外側モニターLIVE画面): もうひとつの Chromium / WebView インスタンス。

恐怖：WebUI（Chromium）がメモリを溶かしていく

Web技術の表現力は最高です。CSSアニメーションも綺麗だし、SVGスタンプの拡大縮小も一瞬。 しかし、その代償として**「ブラウザエンジン（Chromium）がメモリをガッツリ持っていく」**という現実が牙を剥きます。

1. タブレット画面＋外側モニターの「ダブルChromium」

画面が2枚あるため、ブラウザの描画プロセスやGPUプロセスが複数立ち上がります。これだけで平気で1GB〜2GB近くのメモリを消費。

2. 写真撮影とCanvas落書きの履歴（Undo/Redo）

撮影した高解像度写真（数MB）をCanvasに展開し、来場者が落書きしたストロークやスタンプの履歴を保持。 何十組もの撮影を連続でこなしていると、JavaScriptのヒープやブラウザのグラフィックスキャッシュが膨らみ、「いまメモリ何GB残ってる……？」と常に冷や汗をかくことになります。

3. メモリ不足（OOM）で真っ先に死ぬのは誰か？

メモリが枯渇したとき、OS（Windows）が問答無用でプロセスをKillします。 もしPythonのAIエンジンやRust本体がOOMで強制終了されたら、ブースの目の前に並んでいるお客さんの前で**「画面が突然真っ暗になり、システム全体が死亡する」**という最大の悪夢が現実になります。

さらに立ちはだかる「キオスク化」の泥臭い壁

メモリだけでなく、「ブラウザをキオスク専用機として振る舞わせる」ためのハックも山積みです。

• 予期せぬジェスチャー: 画面端をスワイプすると「戻る/進む」が暴発する
• ピンチズーム: 2本指で触ると画面全体が拡大されて戻せなくなる
• 右クリック（長押し）メニュー: コンテキストメニューが出てきてデスクトップが露出する
• エラー画面の恐怖: 万が一クラッシュしたときに「Aw, Snap!（エラー画面）」やWindowsのタスクバーが見えてしまう

これらを防ぐため、起動オプション（--kiosk --disable-pinch --noerrdialogs）やCSSの touch-action: none、レジストリ設定などを総動員して「ブラウザ感を消す」戦いを繰り広げています。

まとめ：ネイティブUIへの移行か、メモリ最適化か？

「WebUIは手軽で開発が速い」というのは、PCのメモリが潤沢にある環境での話でした。 リソースが限られたハードウェアキオスクという現場では、WebUIのフットプリントの重さは無視できないリスクです。

• メモリ解放を徹底してWebUIの延命を図るか？
• それとも将来、超軽量なネイティブGUI（Rustや軽量C++ランタイム）への移行を再検討するべきか？

自作キオスク端末ならではの挑戦は、まだまだ続きそうです。