docker-android：KVM加速のAndroidエミュレータをコンテナ化し、MCPとローカルLLMエージェントに対応

概要

budtmo/docker-android は、Androidに関するあらゆる作業のためのDockerイメージ群です。プロジェクト自身の説明では、ネイティブ、Web、ハイブリッドのアプリ開発とテストに使えるとされています。1つのコンテナに、機種プロファイル付きのAndroidエミュレータ、ブラウザで画面を確認できるVNCサービス、ログ用のWeb画面、adb接続口がまとまっています。起動に必要なのは docker run コマンド1行です。

イメージはAndroid 9から14、つまりAPIレベル28から34までをカバーし、各バージョンに「最新リリース」と「特定リリース」のタグがあります。ほかにGenymotion Cloudへつなぐ genymotion イメージと、今回注目すべき mcp イメージがあります。機種はSamsung Galaxy S6からS10系列、Nexus 4、Nexus 5、Nexus One、Nexus S、タブレットのNexus 7とPixel Cなどが選べます。

アーキテクチャ

構造は3層で捉えられます。最下層はホストのKVMです。中間層はコンテナ内のAndroid SDKとエミュレータのプロセスで、指定したAPIレベルのシステムイメージと機種設定を読み込みます。最上層は利用者向けの入口です。noVNCによるWebデスクトップ（既定で6080番ポート）、ログ共有のWebページ、ホストから adb connect で接続できるデバッグポートがあります。

入口が一本化されているのが利点です。開発者はブラウザでエミュレータの様子を直接見られます。AppiumやEspressoなどのテストフレームワークは、adbやサービスポート経由で端末を操作できます。ビルド、単体テスト、UIテストが同じイメージを共有するため、マシンごとにSDKやシステムイメージを入れ直す必要がありません。

動作原理

Androidエミュレータは、QEMUをもとにしたマシン全体の仮想化です。コンテナ内で実用的な速度を得るには、x86のシステムイメージがKVM経由でCPUのハードウェア仮想化命令を使う必要があります。コンテナ自体は仮想化を提供せず、ホストのカーネルを共有するだけです。そのため、実行時に --device /dev/kvm を付けてデバイスを渡すことが求められます。クイックスタートでも、まず kvm-ok でホストの対応を確かめる手順になっています。

これは、Ubuntuでしか動かないという条件の理由でもあります。READMEは、macOSとWindowsの利用者は、仮想化に対応したUbuntu仮想マシンを使う必要があると述べています。Windows 11のWSL2向けには専用の手順があります。ユーザーをkvmグループに追加し、/etc/wsl.conf の起動コマンドで /dev/kvm の所有者と権限を変え、.wslconfig で nestedVirtualization を有効にします。

実行時の挙動は環境変数で決まります。EMULATOR_DEVICE で機種を選び、WEB_VNC=true でWebデスクトップを有効にします。既定ではコンテナを再起動するとエミュレートされた端末は破棄されます。/home/androidusr にボリュームをマウントすれば、アプリや設定を残せます。「既定は使い捨て、必要なときだけ永続化」という設計は、継続的インテグレーションが求めるクリーンな環境と合っています。

MCPとAIエージェント

最新の変化は、MCPサーバーとAIエージェントです。READMEはどちらもベータ版と記し、図も載せています。MCPは、AIクライアントが外部ツールを標準的な方法で呼び出すためのプロトコルです。AndroidエミュレータをMCPサーバーとして包めば、コーディングアシスタントは端末の起動、画面の確認、タップ、入力、結果の取得を依頼できます。アシスタントごとに専用の接続コードを書く必要がありません。

AIエージェント機能はさらに一歩進みます。READMEによれば、OllamaとvLLMの2種類のローカルモデルサーバーに対応しています。ローカルモデルには明確な意味があります。スクリーンショットや被テストアプリのデータが社内ネットワークの外に出ず、呼び出し回数に応じたクラウドAPIの料金もかかりません。代わりにGPUメモリと推論性能が必要で、小さなモデルは複雑な画面の判断が苦手です。

コストとトレードオフ

READMEには起動時間、メモリ使用量、テストのスループットといったベンチマーク値がありません。そのため性能の数値を引用すべきではありません。構造上のトレードオフははっきりしています。第一に、ハードウェア加速でエミュレータは実用になりますが、コンテナごとにメモリとCPUをかなり使い、並列数はホストの資源で決まります。

第二に、イメージがAndroidバージョンごとに分かれるため、1つずつが大きく、取得とキャッシュを事前に計画する必要があります。第三に、エミュレータは実機ではありません。センサー、ベンダー独自のOS、ハードウェア依存の挙動は実機やクラウド実機での補完が要ります。Genymotion Cloudとの連携があるのはそのためです。

開発者と企業への影響

個人の開発者にとっての価値は、使い捨てできる環境です。手元のマシンを汚さず、SDKのバージョン衝突に悩まなくて済みます。チームでは、イメージのタグでバージョンを固定でき、ローカル、CI、クラウドで同じ環境を動かせます。手元では動くという議論が減ります。プロジェクトにはJenkins、クラウド展開（Azure、AWS、GCP）、SMSシミュレーション、Appiumの利用例も用意されており、導入の道筋が揃っています。

より大きな意味はAIツールチェーンにあります。これまでAIコーディングアシスタントにモバイルの変更を検証させるには、人が端末を用意する必要がありました。エミュレータがMCPサービスとして現れれば、アシスタントは呼び出せる実環境を得て、コード変更、ビルド、実行、観察、再修正という循環を閉じられます。

制約と今後

主な制約は4つあります。第一にKVMが必須で、入れ子の仮想化がない一般的なクラウドホストや、Appleシリコン上のコンテナ環境では直接動きません。第二に、MCPとエージェントはまだベータ版で、仕様や挙動が変わる可能性があります。モデルの非決定性もあり、当面は唯一の回帰判定基準には向きません。第三に、機種一覧は古めの端末が中心で、新しい画面仕様は自分で設定する必要があります。第四に、エミュレータは実機を完全には代表できません。

今後は、対応するAndroidバージョンと機種の拡大、MCPツール定義の安定化、マルチモーダルなローカルモデルへの対応強化、クラウドのデバイスファームとの連携深化が期待されます。モバイル自動化を検討するチームは、まずビルドと通常のUIテストに使い、AIエージェントは切り離した環境で試し、確定的な検証は従来のスクリプトに残すのが現実的です。