APK Cloud Runner — アーキテクチャ図

案C：redroid in per-session microVM ★ 公開サービスの推奨構成

redroid の密度・起動速度と、KVM仮想マシンによる隔離強度を両取りする構成。敵対的APKからホストを守る境界は Layer 2（VM）。

映像・制御ストリーム（H.264 / scrcpy プロトコル）ユーザトラフィック（HTTPS / WSS）内部制御（gRPC / adb） egress（既定DENY・全監視）

なぜこの構成か： redroid は --privileged が必須で、コンテナ隔離が実質無効になります。VMを1枚挟むことで --privileged は「ゲストカーネルに対する特権」に留まり、ホストは守られます。redroid の起動速度・密度はそのまま享受できます。

必須要件： KVM が使えるホスト（ベアメタル or 入れ子仮想化対応クラウド）。通常の管理系VPSやアプライアンスOS（TrueNAS等）では動きません。

案B：redroid 直接（Docker on VPS） PoC / MVP 向け公開サービスには不可

KVM不要・普通のVPSで動く・最も早く形になる。ただし --privileged + ホストカーネル共有のため、信頼できないAPKには耐えられない。

使い方： Phase 0〜2 と、信頼できる開発者だけがAPKを上げるクローズドβまで。不特定多数に開放する前に案Cへ移行することをロードマップの Gate として固定してください。

redroid 公式 README の免責（原文）： "Should NOT expose adb port on public network, otherwise, redroid container (even host OS) may get compromised."

案D：AOSP Emulator / Cuttlefish + 公式 WebRTC 配信を自作したくない場合の最速解

Google が公式に「エミュレータをブラウザに映す」実装を提供している。映像配信を自前で書く必要がない代わりに、密度とコストが悪い。

利点： 映像配信・入力中継を Google 公式実装に任せられる。GMS 入りイメージを正規ルートで使える（redroid + Open GApps のような法的グレーが無い）。元々VMなので隔離も強い。

欠点： 密度が低い（Cuttlefish は数GB〜16GB/インスタンス）ため、同時100セッションではコストが案Cの2〜3倍。TURN サーバの運用と帯域課金も発生。Cuttlefish の Web UI は Chrome/Chromium 限定。

ハイブリッド案： MVP は案D で「配信部分を自作せずに」立ち上げ、ユーザが付いてから案C（redroid + microVM + 自前 WebCodecs 配信）へ移行してコストを下げる、という経路も合理的です。

案A：完全クライアントサイド（v86 / container2wasm）不採用

サーバ不要で隔離も完璧。しかし性能が3桁足りず、現代のAPKは起動しない。

不採用の理由： 要件「任意のAPKが動く」を満たせません。将来 WebGPU + WASM SIMD + スレッド化 + JIT が進んだ際の再評価対象として記録に留めます。

それでも価値がある場面： 「ブラウザの中で Android が動く」という技術デモ・話題作り・OSS としての発信。サーバコストがゼロなので、サイドプロジェクトとしては成立します。

構成比較

評価軸	案A client (v86)	案B redroid 直接	案C ★ redroid + microVM	案D Emulator/Cuttlefish	案E SaaS (Anbox等)
現代APKが動く	✕	○	○	○	○
敵対的APK（マルウェア）に耐える	○	✕ 致命的	○ VM境界	○ VM境界	○
KVM 不要（普通VPSで動く）	○	○	✕	✕	○
密度（セッション / 64GBホスト）	n/a	20〜40	10〜20	3〜8	〜100（公称）
コールドスタート	数分〜	10〜20秒	20〜40秒	60〜120秒	数秒
映像配信の自前実装	不要	必要	必要	不要（公式）	不要
TURN サーバ	不要	不要	不要	必要	提供側
32bit ARM (armeabi-v7a)	✕	○ x86_64+翻訳	○ x86_64+翻訳	○ x86_64+翻訳	プラン次第
GMS（Play / ログイン / FCM）	✕	✕（法的に不可）	✕（法的に不可）	△ 公式イメージ	△ 契約次第
月額目安（同時10・東京）	¥0	¥25,000	¥210,000〜	¥350,000〜	¥150,000〜（従量）
MVP までの工数	1〜2週	6〜8週	12〜16週	6〜8週	2〜4週
法務リスク	低	高	中	低〜中	低（ベンダ負担）
公開サービス適性	✕	✕	◎	○	◎

推奨する経路： 案B で Phase 0〜2（PoC/MVP）→ 案C で Phase 4（公開）。並行して案E（Anbox Cloud / Corellium / Appetize）の法人見積を取得し、自前構築の総コスト（人件費約¥10M + 6ヶ月）と比較して最終判断する。

もう一つの合理的な経路： 映像配信の自前実装を避けるため、MVPは案D（Google公式WebRTC流用）で立ち上げ、トラフィックが増えた段階で案Cに移してコストを下げる。

隔離レイヤ（案C）

Layer	実体	敵対的APKからの距離
5	ユーザの APK	—
4	redroid（Android ユーザ空間）	同一プロセス空間
3	最小ゲスト Linux（binder / ashmem のみ）	ゲストカーネル（使い捨て）
2	QEMU/KVM microVM	★ VM境界＝公開サービスの最低ライン
1	ホスト OS（最小構成）	保護対象
0	物理 / ハイパーバイザ	保護対象

案B が公開に不適な理由： --privileged は全ケーパビリティ付与・全 /dev アクセス・seccomp/AppArmor 無効化・ホストFSマウント可能を意味します。コンテナ脱出が「脆弱性」ではなく「機能」です。加えて binder はホストカーネルのモジュールなので、敵対的コードがホストカーネルの攻撃面に直接触れます。