CodexにChromeからXServer VPSを操作させ、Android実機調査の司令塔を構築してみた【Qwen3-VL・実測】

結論からいうと、XServer VPSは「AIがスマートフォンを直接操作する場所」ではなく、調査ジョブの司令塔と証拠保管庫として使えました。

今回、CodexにChromeからXServer VPSの管理画面を確認・操作させ、XServer VPS、自宅Windows PC、所有Androidを連携する「AIによる実機スマホ調査・一次情報収集システム」の中核を実際に構築しました。

• XServer VPS：調査ジョブ、進行状況、操作履歴、発見事項、スクリーンショットなどを管理
• 自宅Windows PC：ローカルAIによる画面判断とAndroid操作
• 所有Android：USBで自宅PCへ接続する調査対象
• 通信：自宅PCからVPSへの外向きHTTPSのみ

VPSと自宅PCの往復通信、証跡保存、ローカルAIの画像認識、安全制御までは動作確認できました。ただし、2026年8月28日の検証時点ではAndroid実機をUSB接続しておらず、adb devices -lの結果は0台です。「AIが実際のスマートフォンをタップして調査を完了した」ところまでは未検証です。

実体験記事として誤解が出ないように、ここからは確認済みの事実と未確認の部分を分けて紹介します。

今回どこまで実際に検証できたのか

検証日は2026年8月28日です。ソフトウェアのバージョンやサービス仕様は今後変わる可能性があります。

XServer VPSで何を作ったのか

今回作ったのは、AIによる実機スマホ調査システムの「コントロールプレーン」です。

XServer VPS
  ジョブ管理・リース・操作履歴・証跡保管
             ↑
       外向きHTTPS通信
             ↓
自宅Windows PC
  Qwen3-VL・Ollama・ADB・uiautomator2
             ↕ USB
所有Androidスマートフォン

VPSから自宅PCやAndroidへ直接接続する構成ではありません。自宅PC側のワーカーがVPSへ問い合わせ、仕事があれば受け取ります。自宅ルーターのポート開放は行わず、ADBもインターネットへ公開しません。

調査後は、スクリーンショット、AndroidのUI構造、操作の順番、操作ごとの所要時間、表示された料金、エラー、発見した特徴、取得時刻、証跡ファイルのSHA-256をVPSへ返す設計です。

XServer VPS契約後、Chromeに最初に何が表示されたのか

Chromeでは、ログイン済みの「XServer VPS VPSパネル」の詳細画面が開いていました。最初に確認できた仕様は次のとおりです。サービスの最新仕様はXServer VPS公式サイトも確認してください。

「リソース情報」ではCPU、ディスク読み書き、受信・送信転送量のグラフを確認できました。RAMのグラフは管理画面に見当たらなかったため、メモリ使用量はUbuntu側のfreeやdocker statsで測定しました。

ChromeからXServer VPSの何を操作したのか

• VPSの基本情報と稼働状態の確認
• CPU・ディスク・通信量グラフの確認
• パケットフィルター設定
• SSH鍵の登録状態確認
• シリアルコンソールの起動
• VNCコンソールの存在確認
• イメージ保存機能の条件確認
• 電源、OS再インストール、プラン変更などの管理導線確認

シリアルコンソールはChrome上で開き、Enterキーを押すとLinuxのログインプロンプトが表示されました。SSH設定を失敗して接続不能になった場合でも、ブラウザから復旧できる経路があるのは安心材料です。

一方、イメージ保存はVPS稼働中には実行できませんでした。先にシャットダウンする必要があると表示されます。

最初にSSH接続できなかった原因は何だったのか

初回のSSH接続はTCP/22でタイムアウトしました。原因はXServer側のパケットフィルターです。フィルター自体はONでしたが、接続許可ルールが0件でした。

Chromeからプリセットの「SSH / TCP 22 / 全て許可」を追加すると、VPSまで到達できるようになりました。「パケットフィルターがONならSSHも使える」とは限らず、許可ルールがなければ通信は通りません。

今回は初期構築時の暫定設定として全接続元から22番を許可しました。長期運用では送信元IP制限やVPNへ寄せる予定です。

WindowsでSSH秘密鍵を拒否された原因は何だったのか

VPSへ到達した後は、WindowsのSSHクライアントからUNPROTECTED PRIVATE KEY FILEで秘密鍵を拒否されました。

ダウンロードしたPEMファイルが親フォルダーのアクセス権を継承し、所有ユーザー以外のローカルグループにも読み取り権限があったためです。PEMファイル1件だけ継承を解除し、所有ユーザーだけが読めるACLへ変更すると鍵認証に成功しました。

鍵の本文、VPSのIPアドレス、認証トークンは、記事用記録やプロジェクト内へ保存していません。

VPSにはどのDocker構成を採用したのか

Docker Engine 29.7.2とCompose 5.5.0を公式リポジトリから導入しました。スクリーンショットなどの原本はDockerボリューム上の内容アドレス方式ストレージへ保存します。

ファイルのSHA-256を保存先のキーとして使うため、同じ内容を再送しても同じ実体を参照できます。検索や記事化に必要なメタデータはPostgreSQLへ記録します。

PostgreSQLの5432番とFastAPIの8000番はホスト側へ公開していません。外部公開したのはSSHの22番、HTTPの80番、HTTPSの443番だけです。Dockerがホストのファイアウォール規則へ与える影響は、Docker公式ドキュメントも確認しました。

RedisやMinIOを使わなかった理由

4GB RAMのVPSなので、初期構成では常駐サービスを増やしすぎないことを優先しました。ジョブの取得と期限管理はPostgreSQLのFOR UPDATE SKIP LOCKEDで実装できるため、Redis、RabbitMQ、Temporalは入れていません。

証跡保存についても、MVPではVPS内のDockerボリュームを使いました。同じVPSの同じディスク内へ別のS3互換サーバーを立てても、障害時のバックアップにはなりません。将来はストレージ処理のインターフェースを通じて、外部S3互換サービスへ切り替えられる設計にしています。

構築後のCPU・RAM・ストレージ使用量はどのくらいか

最終構成でVPSを再起動し、各サービスが自動復旧した後の実測値です。

PostgreSQLには1GiB、FastAPIには512MiB、Caddyには256MiBのメモリ上限を設定しています。これは予約量ではなく、使いすぎを防ぐ上限です。今回のようにAIモデルを自宅PC側へ置くなら、4GBプランでもコントロールプレーンには余裕がありました。

自宅PCにはどのローカルAI環境を入れたのか

導入したのは、Android SDK Platform Tools／ADB 37.0.1、scrcpy 4.1、Ollama 0.33.1、Qwen3-VL 2B、uiautomator2 3.7.0、adbutils 2.12.0、Pillow 12.3.0です。

Qwen3-VLはApache-2.0で公開された重みをローカル実行するopen-weightモデルです。この記事では、学習工程全体まで完全に再現可能という意味の「完全オープンソースAI」とは区別します。

モデルはVPSではなく、自宅PCのOllamaで動かします。4GB VPSへ画像認識モデルまで同居させると、APIやデータベースの安定運用を圧迫するためです。

Qwen3-VL 2Bは8GB・CPUのみのPCでどのくらい速かったのか

47,983バイトのグラフ画像を判定させると、グラフが含まれていること自体は正しく認識しました。しかし、1枚に77.83秒かかりました。

このPCではリアルタイム操作より、「1画面を撮る→待つ→次の1操作を判断する」という低速な直列調査が現実的です。証跡用の原寸画像は保持し、AIへ渡す派生画像だけ長辺720ピクセルへ縮小しました。複数の画像推論を同時に走らせないロックも追加しています。

Ollamaで起きた予想外の挙動

Ollama 0.33.1とQwen3-VL 2Bの組み合わせでは、think=falseと厳格なJSON Schemaを指定しても、生成JSONがmessage.contentではなくmessage.thinkingへ入ることがありました。

そこで、contentが空の場合だけthinkingを候補にするアダプターを追加しました。thinking側に出た内容も無条件には信用せず、通常の出力と同じ厳格なJSONパーサーと、AIとは独立したローカルポリシーへ通します。未知フィールド、重複キー、任意コマンド、文字入力などは拒否します。

AIにスマートフォンの何を許可したのか

AIが出力できる操作は、screenshot、dump_ui、tap、swipe、back、home、wait、finishの8種類だけに固定しました。

任意のシェルコマンド、任意ADB、URLアクセス、コード実行、文字入力、アプリ起動はAIへ与えていません。さらに次の条件を追加しました。

• USB接続した許可済み端末だけを対象にする
• IPアドレス形式の無線ADBやエミュレーターを拒否する
• 許可したアプリのパッケージだけを操作する
• 前面アプリが切り替わったら停止する
• 購入、支払い、契約、ログイン、権限付与、インストール、削除を拒否する
• tapはラベルがあり、clickableかつenabledなUI要素だけに限定する
• swipeは同じscrollable要素内で完結する場合だけ許可する
• 実行前に画面とUI構造を再取得し、提案時と一致しなければ停止する
• 変更操作ごとに人間の承認コードを要求する
• 無監督実行はCLI自体で無効にする

キーワードとUIラベルによる拒否だけで、悪意あるアプリの挙動まで完全に保証できるわけではありません。そのため、本アカウントや決済手段を入れた端末では実行しない方針です。

dry-runでもAndroidへ一切書き込まないのか

いいえ。ここは注意が必要です。

uiautomator2 3.7.0のソースを確認すると、初回接続時にu2.jarをAndroidの/data/local/tmp/u2.jarへ転送し、app_processベースの補助プロセスを起動します。

今回のdry-runは「対象アプリへtap、swipe、back、homeを送らない」という意味で、端末へ一切書き込まないゼロライト動作ではありません。補助ファイルを端末へ置きたくない場合は、ワーカーを起動せず、scrcpy --no-controlなどによる手動観察に留めます。

一次情報はどのように保存するのか

調査ID/
  run.json
  events.ndjson
  manifest.ndjson
  0001-screenshot.png
  0001-ui.xml
  0002-screenshot.png
  0002-ui.xml

manifest.ndjsonには、ファイル名、種類、MIMEタイプ、バイト数、取得時刻、SHA-256を記録します。events.ndjsonには、AIの提案、ポリシー判定、人間の承認、実行結果、所要時間、エラーを追記します。

同じ情報をVPSにもHTTPSで送ります。Androidのシリアル番号は平文でVPSへ送らず、ハッシュ化します。VPSでは1ファイル100MiB、1ジョブ500件、論理累計2GiBを既定上限とし、ディスクの空きを最低20GiB残す設定にしました。

VPSと自宅PCの通信は実際に成功したのか

はい。Androidを使わないダミーワーカーでは、一連の往復に成功しました。

1. 管理側から調査ジョブを登録
2. 自宅PCがジョブを取得
3. リースを延長
4. 操作イベントを送信
5. JSON証跡をアップロード
6. 根拠付きの発見事項を登録
7. ジョブを完了
8. 管理側から証跡を再取得
9. SHA-256が一致することを確認

自宅PC側に待受ポートを作らず、外向きHTTPSだけで往復できています。ワーカートークンで管理者用データを読もうとした場合は403、認証なしで証跡をアップロードした場合は本文解析前に401になることも確認しました。

構築中に発生した問題と、どう解決したのか

公開証明書を取得した数秒後には、無関係な外部クローラーが/console/や/server-statusなどへアクセスしていました。すべて404でしたが、「公開した直後だから誰も来ない」という前提が成立しないことを実体験できました。

XServer VPSで便利だった点

• SSHとWeb用のパケットフィルタープリセットがある
• ChromeからシリアルコンソールとVNCコンソールを開ける
• 標準ホスト名をHTTPS証明書取得に利用できた
• CPU、ディスク、送受信量をグラフで確認できる
• 電源、OS再インストール、SSH鍵、DNS、プラン変更が同じ管理画面にまとまっている
• VPS再起動後もDocker構成が自動復旧した

最終再起動後は、SSH、Docker、fail2ban、自動更新、PostgreSQL、FastAPI、Caddyが起動し、保存済み証跡もSHA-256一致で再取得できました。

XServer VPSで分かりにくかった点・初心者が迷いそうな点

• パケットフィルターがONでも許可ルール0件ならSSHできない
• XServerのフィルター、Ubuntuのファイアウォール、Dockerの公開ポートは別々に考える必要がある
• 管理画面にRAMグラフがない
• イメージ保存にはVPSの停止が必要
• VPSパネルの二段階認証が初期状態では未設定だった
• WindowsのPEMファイルはLinuxのchmod 600とは異なるACL設定が必要
• 秘密値の初回生成と、運用中のローテーションを分ける必要がある
• Dockerボリュームだけではバックアップにならない
• Ollamaはモデル本体以外のプログラム容量も大きい

Ollamaのプログラムディレクトリは約2.74GiB、モデルストアは約1.76GiB、Android用Python環境は約53.4MiBでした。Cドライブの空き容量は139.3GiBから134.6GiBへ減りました。

現時点で「AndroidをAIに操作させた」と言えるのか

まだ言えません。

検証済みなのは、ローカルAIのテキスト・画像推論、ADBやscrcpyなどの導入、安全制御、VPSとの通信コード、ダミーワーカーによる証跡往復です。Android実機は未接続で、adb devices -lは0台でした。

次の実機検証では、購入手段や本アカウントを入れていない所有テスト端末を用意し、USBデバッグとRSA承認、観察、dry-run、監督付き1回のtapという順序で進めます。本アカウント、決済手段入り端末、無監督運転は現時点ではNO-GOです。

今後どのように拡張できるのか

• XServer管理画面の二段階認証
• SSHの送信元IP制限またはTailscale
• VPSのレート制限
• ワーカートークンの端末・キュー単位の権限制限
• 暗号化した外部バックアップと実際のリストア試験
• 未参照証跡を安全に整理するGC
• ネットワーク切断時のPC側オフライン保存
• スクリーンショットの個人情報マスキング
• Android OS・端末・アプリ版の自動記録
• 操作動画とテキスト要約
• 16GB以上またはGPU搭載PCへのAI推論分離

実機検証に成功すれば、料金画面、機能一覧、所要時間、エラー、画面遷移、意外な挙動を、取得時刻と証拠画像付きで記事へ反映できます。

XServer VPSとAndroid実機調査AIに関するよくある質問

XServer VPSだけでAndroid実機を操作できますか？

いいえ。今回の構成では、XServer VPSはジョブ管理と証跡保管を担当し、Android操作とAI推論は自宅Windows PCが担当します。

AndroidはVPSへ直接接続するのですか？

直接接続しません。AndroidはUSBで自宅PCへ接続し、自宅PCのワーカーがVPSへ外向きHTTPSで接続します。

自宅ルーターのポート開放は必要ですか？

必要ありません。家庭側に待受ポートを作らず、自宅PCからVPSへの外向き通信だけを使います。

AIモデルはXServer VPS上で動いていますか？

いいえ。Qwen3-VL 2Bは自宅Windows PC上のOllamaで動かし、4GB VPSは司令塔に専念させています。

Qwen3-VLは完全なオープンソースAIですか？

この記事では、Apache-2.0で公開された重みをローカル実行するopen-weightモデルと表現しています。画面データをクラウドAIへ送らない構成です。

4GBのXServer VPSで足りますか？

今回のコントロールプレーンには足りました。最終実測はホスト全体でRAM約618MiB使用、3コンテナ合計で約241MiBです。ただし、VPS上で大規模な画像認識モデルを動かさないことが前提です。

Android実機での操作は検証済みですか？

未検証です。ソフトウェアと安全制御の準備はできていますが、USB接続、RSA承認、実機タップ・スワイプは次の段階です。

dry-runならスマートフォンへ何も書き込まれませんか？

いいえ。uiautomator2は初回に補助JARを端末へ配置します。今回のdry-runは、対象アプリへ変更操作を送らないという意味です。

AIへ無人でアプリ調査を任せられますか？

現状は任せない設計です。変更操作ごとに人間の承認が必要で、無監督モードはCLIから実行できません。

スクリーンショットや操作履歴はどこへ保存されますか？

PC側へcreate-only／append-onlyで保存し、同じ証跡をVPSへHTTPSで送ります。ファイルには取得時刻、種類、容量、SHA-256を記録します。

まとめ：VPSの司令塔は完成、Android実機E2Eは次の検証

関連情報として、XServer VPSの無料プランと注意点もまとめています。今回使ったのは、継続運用を前提にした有料4GB構成です。

CodexにChromeからXServer VPSを操作させることで、AI実機調査システムの司令塔はかなり自律的に構築できました。

完成したのは、ChromeからのVPS設定確認、Dockerによる軽量なコントロールプレーン、自宅PCからの外向きHTTPS通信、操作履歴と証跡のSHA-256付き保存、Qwen3-VLによるローカル画像認識、Android操作を限定する安全ポリシーです。VPS側21件、Androidワーカー側53件のテストも通過し、VPS再起動後の自動復旧まで確認しました。

一方、Android実機での操作はまだ完了していません。現時点の正確な結論は、「XServer VPSを司令塔にし、自宅PC上のopen-weight AIが所有Androidを調査するための基盤と安全装置までは構築できた。実機USB E2Eは次の検証段階」です。

次は所有テスト端末で、観察、dry-run、監督付き1タップの順に検証し、本当にレビュー記事へ使える一次情報をどこまで自動収集できるか確かめます。