AndroidでADBをインターネット越しに使う：rootあり・なしの安全な設定

別の国からスマホのADBに接続するのに、rootは必要ありません。必要なのは、ADBをTCPで有効にする手段と、パソコンとスマホの間の非公開の経路です。rootが関わるのは前者だけで、ケーブルなしでスマホ自身にADBを有効にさせ、再起動後も維持できるようになります。このガイドの残りの内容は、root化していない純正の状態のスマホでも同じように使えます。

失敗する原因は、rootの有無にかかわらず同じです。自宅のルーターでポート5555を転送するチュートリアルに従ってしまうか、Wi-Fiでは動くのにモバイルデータでは気づかないうちに失敗する接続を信用してしまうかのどちらかです。

このガイドの対象は、自分が所有するスマホです。たとえば、テストに使う予備機、旅行中に接続したい自宅のスマホ、小規模な端末ファームなどです。他人の端末への接続は対象外です。リモートADBの仕組み、rootありとなしでの有効化の方法、ADBを公開インターネットに出さない3つの接続方法を解説します。rootが必要な手順にはroot専用と表示しています。

要点：スマホでTCP ADBを有効にし、暗号化された非公開の経路でのみ接続できるようにして、その経路をパソコンから使います。最も手軽なのはTailscaleです。自分用の小さなサーバーを経由するSSHリバーストンネルは、最も汎用性があります。ポート5555の単純な転送だけは、避けるべき設定です。

rootあり・なしで何が変わるか

実用上の違いは、できることではなく安定性です。root化していないスマホでも、再起動するまではリモートで問題なく使えます。しかし再起動後は、スマホとパソコンを持つ誰かが復旧するまで接続できません。別の都市にあるスマホなら、これがroot化する理由です。手元で操作できるスマホや短期間のテストなら、rootは不要です。

ADBを実際に守るもの、守らないもの

リモートADBに関する多くの解説は、ネットワーク越しのADBには「暗号化も認証もない」と書いています。これは半分だけ正しく、間違っている半分が設定方法に影響します。

従来のネットワークADB、つまりadb tcpip 5555モードは、暗号化されていません。AndroidのADB設計ノートでは、従来のトランスポートは平文のパケットで、Android 11で導入されたWi-FiモードはセッションをTLSで保護すると説明されています。出典 2 あなたとスマホの間の経路を監視できる人は、送信内容を読み取れます。

認証は別の話です。通常の製品ビルドでは、ADBは引き続き、パソコンのRSAキーをスマホ側で承認するよう求めます。初めて接続すると、adb devicesにunauthorizedと表示され、スマホには鍵のフィンガープリントとともに「Allow USB debugging?」というダイアログが出ます。Androidのドキュメントによると、端末のロックを解除してこのダイアログを承認するまで、adbコマンドは実行できません。出典 1 承認したキーはスマホに保存され、「Always allow from this computer」にチェックを入れると、以降の接続は確認なしで行われます。

ここから実用上の結論が2つ出てきます。1つ目。純正のスマホでは、公開されたポートが見知らぬ人に開いたドアになるわけではありませんが、スマホがすでに信頼しているキーを入手した人には開いたドアになります。認証が無効な端末では、完全に開いたドアです。ポート5555を通じて広がったマルウェアが狙ったのは、主にそうした端末でした。TVボックス、プロジェクター、開発者向けビルド、誰かがセキュアフラグをオフにしたスマホなどです。2つ目。新しいパソコンからの最初の接続には、画面の操作が必要です。USBケーブルか自宅のWi-Fiを使い、スマホのそばにいるときにキーを承認し、記憶するチェックボックスにチェックを入れておいてください。

無人のリモート接続にワイヤレスデバッグが向かない理由

ワイヤレスデバッグは安全な選択肢に見えますし、自宅のWi-Fiにつないだノートパソコンならその通りです。しかしリモート接続には向きません。接続ポートはランダムで、機能をオフにして再びオンにすると変わります。検出にはmDNSを使いますが、これはVPNを越えられません。さらに、新しいAndroidでは自動的にオフになります。ADB 37を搭載するAndroid 17では「ADB Wi-Fi 2.0」が加わり、信頼済みに設定していないネットワークではワイヤレスデバッグをオフにし、設定したネットワークでは自動的に再接続します。出典 4 開発者のデスクでは理想的な動作ですが、別の国から接続したいスマホには全く向きません。

この機能の詳細は、ペアリング、信頼済みネットワーク、ペアリング済みなのにオフラインになる問題を扱ったAndroid 17のワイヤレスADBのガイドをご覧ください。リモート利用に向いているのは、固定のTCPポートです。rootの有無にかかわらず有効にでき、ポート自体よりも強力な仕組みで保護できます。

手順1：TCP ADBを有効にする

お使いのスマホに合う方を選んでください。どちらも最終的な状態は同じで、スマホのADBデーモンがポート5555で待ち受け、手順2でそれを保護します。

rootなし

どのAndroidスマホでも、開発者向けオプションとUSBデバッグを有効にし、ケーブルでパソコンに接続し、スマホの確認でキーを承認してから、次を実行します。

adb tcpip 5555

ケーブルを抜きます。スマホは再起動するまで、ポート5555でネットワーク越しのADB接続を受け付けます。USBデバッグを切り替えるとこの設定がリセットされるビルドもあるため、ポートが応答しなくなったらコマンドを再実行してください。この設定は再起動で失われるので、root化していないスマホでは、再起動のたびにケーブルを持つ人が必要になります。手元で管理できるスマホなら問題ありませんが、手が届かないスマホには向きません。

Android 11以降には、パソコンをまったく使わずに同じ手順を行う方法があります。コミュニティで広く使われていますが、すべての端末では検証していません。ワイヤレスデバッグを有効にし、TermuxとそのAndroidツールのパッケージをインストールして、ペアリングコードでTermuxをスマホ自身とペアリングし、スマホ自身のアドレスに接続して、そこからadb tcpip 5555を実行します。その時点でスマホがWi-Fiに接続されている必要があります。ケーブルを忘れた日の代替手段と考えてください。コマンドはパッケージやAndroidのバージョンで変わるため、正確な内容は最新のTermuxのガイドで確認してください。

rootありの場合（root専用）

root化したスマホで、Termuxなどのターミナルアプリを開き、rootシェルを取得します。ポートを制御するプロパティはADBデーモン自身が読み取り、デーモンのソースコードではservice.adb.listen_addrs、service.adb.tcp.port、persist.adb.tcp.portの順に確認しています。出典 3

su
setprop service.adb.tcp.port 5555
stop adbd
start adbd

デーモンを再起動すると、開いているUSBデバッグのセッションは切断されます。ケーブルで接続したPCではなく、スマホ上から実行してください。待ち受けているか確認します。

getprop service.adb.tcp.port
ss -ltn | grep 5555

ssが入っていないAndroidビルドもあります。その場合はnetstat -ltnが使える機種もあります。どちらもない場合は、手順2で行うパソコンからの接続テストが確実な確認方法です。

service.プロパティは、スマホの再起動で失われます。停電のあとで接続できないスマホは、リモートで使えるスマホとは言えないため、設定を永続化します。方法は2つあり、組み合わせて使うと効果的です。1つ目は永続プロパティです。

setprop persist.adb.tcp.port 5555

2つ目はブートスクリプトです。Magiskでは、/data/adb/service.d/に保存して実行権限を付けたシェルスクリプトが、起動の終盤に実行されます。KernelSUとAPatchでは、代わりにservice.shファイルを含む小さなモジュールを使います。正確な保存場所はツールやバージョンで変わるため、お使いのroot管理アプリのドキュメントで確認してください。

#!/system/bin/sh
until [ "$(getprop sys.boot_completed)" = "1" ]; do sleep 5; done
setprop service.adb.tcp.port 5555
stop adbd
start adbd

一度再起動してテストしてください。これらのプロパティの扱いはベンダーによって異なり、無視したりリセットしたりするROMもあります。Android 11以降では、一部のビルドでSELinuxのルールがADBによるポートプロパティの設定を妨げ、その後に緩和されたことがあります。出典 5 お使いのスマホで再起動後に設定が残らない場合は、ブートスクリプトで解決できます。デーモンがまったく待ち受けない場合は、ROMがプロパティをブロックしている可能性があります。その場合は、起動のたびにUSB接続でadb tcpip 5555を1回実行するのが代替手段で、上のrootなしの方法と同じです。

rootありで再びオフにするには、次を実行します。

setprop service.adb.tcp.port -1
setprop persist.adb.tcp.port ""
stop adbd
start adbd

rootなしの場合は、開発者向けオプションでUSBデバッグをオフにするか、スマホを再起動すれば同じ結果になります。

この時点で、スマホは持っているすべてのネットワークインターフェースで待ち受けています。それらにアクセスできるのが、あなた自身と信頼できるネットワークだけであれば問題ありません。それを実現するのが次の手順です。

手順2：スマホへの非公開の経路を選ぶ

以下の方法はいずれも、rootの有無にかかわらず使えます。目的はどれも同じで、パソコンからスマホのポート5555へ、暗号化・認証された経路を用意し、しかもオープンなインターネットからの受信接続を受け付けないことです。後者は見た目以上に重要です。モバイルデータ回線のスマホの多くはキャリアグレードNATの内側にあるため、ルーターで転送を設定してもスマホには届きません。

方法A：Tailscale

Tailscaleは、お使いの端末同士の非公開ネットワークを構築し、NATの越え方も自動で処理します。そのため、モバイルデータ回線のスマホからでも動作します。スマホとパソコンの両方にインストールし、同じアカウントでサインインします。各端末には100.で始まる固定のアドレスが割り当てられ、スマホのアドレスはアプリと管理コンソールで確認できます。

パソコンから、次を実行します。

adb connect 100.x.y.z:5555
adb devices

初回は、スマホがキーの承認を求めます。この1回をスマホを手元に置いて行うのはそのためです。Tailscaleアプリにrootは不要です。以降はadb shell、adb push、adb logcat、scrcpyのすべてが、スマホがデスクの上にあるかのように動作します。

次の3つの設定で、便利なだけの状態から頼れる状態に変わります。1つ目。Tailscaleはデフォルトでは、ネットワーク上のすべての端末が他のすべての端末にアクセスできます。それを絞り込むのがポリシーファイルです。自分のアカウントだけがタグ付けしたスマホのポート5555にアクセスできるようにするルールは、アクセスポリシーでは次のようになります。出典 6

{ "action": "accept", "src": ["you@example.com"], "dst": ["tag:phone:5555"] }

2つ目。管理コンソールで、スマホのキーの有効期限をオフにします。そうしないと、期限が来ると自動的にネットワークから外れ、遠く離れた場所からは戻せなくなります。3つ目。Androidの設定で、Tailscaleアプリのバッテリー使用を制限なしにします。厳しい電力管理の下でアプリが停止したり、数分おきに切断されたりするという報告があり、転送の途中で切れるのが典型的な症状です。出典 8

知っておきたい制限が2つあります。TailscaleのビルトインSSHサーバーはAndroidでは動作しません。この機能についてはAndroidはクライアントのみに対応しているためです。ADBなしでシェルが必要な場合は、ADBポートに直接接続するか、下記のSSHトンネルを使ってください。出典 7 また、この用途にTailscale Funnelは使わないでください。Funnelはウェブサービスを公開インターネットに公開する機能で、ここで目指していることの正反対です。

方法B：自分のサーバー経由のSSHリバーストンネル

この方法は第三者のサービスを一切必要としません。最小の仮想サーバーを借り、スマホからそのサーバーへ接続して、その接続を維持します。パソコンも同じサーバーに接続し、サーバー経由でスマホに到達します。スマホ側から接続するため、CGNATの内側でもホテルのWi-Fiでも動作します。

スマホで、rootが不要なTermuxを使い、SSHクライアントをインストールしてキーを作成します。

pkg install openssh autossh
ssh-keygen -t ed25519

サーバーで専用ユーザーを作成し、スマホの公開鍵をそのユーザーのauthorized_keysファイルに追加します。ループバックインターフェースで待ち受けるポート1つを開く以外は何もできないように、キーに制限を付けます。

restrict,port-forwarding,permitlisten="127.0.0.1:15555" ssh-ed25519 AAAA... phone

次に、スマホでトンネルを維持します。以下のオプションは、ポートをバインドできないときに接続を明確に失敗させ、ネットワークが切れても無言で固まらないようにします。

ssh -N -R 127.0.0.1:15555:127.0.0.1:5555 \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3 \
  -o ExitOnForwardFailure=yes tunnel@your-server.example

autosshでそのコマンドを監視して再起動でき、Termux:Bootアドオンで再起動後に起動できます。トンネルの稼働中にCPUをスリープさせないためにtermux-wake-lockも使います。Termuxのバッテリー設定も制限なしにしてください。これらはAndroidのバージョンや、ベンダーがバックグラウンドアプリをどれだけ強く停止させるかで変わります。頼る前に、画面をオフにして1時間テストしてください。

パソコンから、ローカルポートをトンネルに転送して、それ経由で接続します。

ssh -N -L 5556:127.0.0.1:15555 you@your-server.example
adb connect 127.0.0.1:5556

ローカルポートが5556である点に注意してください。ご自身のADBサーバーがすでに5555を使っていることが多く、衝突すると分かりにくいエラーが出ます。リモート転送はサーバーのループバックアドレスにバインドされるため、インターネット上の誰も直接アクセスできません。また、OpenSSHのリモート転送のデフォルトでは、GatewayPortsを変更していない限り、公開インターフェースへのバインドは拒否されます。

サーバーでは鍵認証のみのログインにし、そのユーザーのパスワードは無効にしておいてください。インターネットに公開されたSSHサーバーでパスワードログインを許可したリバーストンネルは、置き換えたはずのポート転送とほとんど変わらない安全性しかありません。

方法C：自分のサーバーのWireGuard

WireGuardはTailscaleと同じ効果を、すべての要素を自分の管理下に置いて実現します。公開アドレスを持つサーバーでWireGuardのエンドポイントを動かし、スマホとパソコンをピアとして追加して、スマホ側にPersistentKeepalive = 25を設定すると、モバイル回線でもNATのマッピングが維持されます。rootが不要なAndroid版のWireGuardアプリは、Wi-FiとLTEの間をローミングでき、常時接続VPNとしても動作します。パソコンからは、Tailscaleと同じように、スマホのWireGuardアドレスのポート5555に接続します。固定で恒久的な構成が欲しく、サーバーの保守が苦にならない場合に適した選択です。

よく挙がる代替手段について補足します。Cloudflare TunnelはSSHについてはドキュメントがありますが、生のADB通信をきちんと動かせることは確認できていないため、ここではおすすめしません。

避けるべき設定：ルーターでポート5555を転送する

外部のポート5555、あるいは「工夫した」独自のポートをスマホに転送して終わりにしたくなりますが、やめてください。暗号化されていないADBを公開インターネットに流し、守りはキーの確認1つだけで、まさにこれを探すスキャナーに自分の存在を知らせることになります。

これは理屈の話ではありません。2020年、KeysightのリサーチャーがTrinityボットネットを分析し、Shodanで約4万台の公開ADB端末が見つかり、その約4分の1がスマホで、マルウェアはadb connect自体を使ってそれらに接続していたと報告しました。出典 9 競合するボットネットFbotは感染した端末からTrinityを削除しましたが、数時間でTrinityが戻りました。2021年2月には、Miraiのコードを基にしたMatryoshボットネットが同じポートで拡散しました。出典 10 外部ポート番号を変えても意味はありません。スキャナーはすべてのポートを調べるからです。

妥協案として、代わりにTermuxサーバーのSSHポートを転送するガイドもあります。ADBを転送するよりは良いですが、それでも自宅のIPでSSHサービスを公開することになり、パスワード認証のTermuxログインをインターネット上に置くのは好ましくありません。リバーストンネルやオーバーレイネットワークなら、受信ポートをまったく開かずに同じ結果が得られます。

セキュリティ強化チェックリスト

実際に使うパソコンだけを承認し、古いものは取り消します。開発者向けオプションの「Revoke USB debugging authorizations」は、保存されているキーをすべて消去します。他の人にスマホを渡す前にやっておくと良い習慣です。ADBデバッグが不要なスマホでは、ADBデバッグをオフにしておき、手順1で開いたポートも同じ判断の一部として扱ってください。共有パソコンや公共のパソコンでは「Always allow」にチェックを入れないでください。

承認されたADBセッションは、shellユーザーが見られるものをすべて見ることができ、それだけでもかなり広範です。インストール済みのアプリ、読み取れるファイル、画面、入力です。root専用：root化したスマホでは、root管理アプリがshellに許可していれば、adb shell suでさらに多くのことができます。そのため、黙って許可せず、shellにはプロンプトを表示するよう設定してください。

root専用：スマホにファイアウォールのルールを追加して、ポート5555がVPNインターフェースでのみ応答するようにする人もいます。考え方は妥当ですが、Androidで確実に動作するかは確認できませんでした。システムのネットワークデーモンが、ネットワークの変化時にルールの順序を変えたり消去したりすることがあり、また、純正のTailscaleアプリは、照合に使えるtailscale0インターフェースを作成しません。試す場合は、ブートスクリプトからルールを再適用し、VPNに接続していない端末からテストしてください。

低速な回線で使う場合

トンネル越しのスマホは、デスクの上のスマホより遅く感じられます。対処法は、たいてい要求を減らすことです。scrcpyで画面をミラーリングするなら、解像度とビットレートを下げます。たとえばscrcpy -s 100.x.y.z:5555 -m 1280 -b 4Mのようにします。フラグ名はバージョンによって少し異なるため、scrcpy --helpで確認してください。scrcpyは--tcpipでTCPモードを有効にすることもでき、ドキュメントでは使い終わったら切断することを推奨しています。出典 11 Tailscaleの直接経路は、ベンダーのサーバーを中継する経路より高速で、アプリの接続状況でどちらを使っているか分かります。

複数の端末が接続されているときは、adb -s 100.x.y.z:5555 ...でどの端末を指すかをADBに伝えるか、USB端末には-d、エミュレーターには-eを使います。ファイル転送とadb logcatは、遅延に最も強い作業です。

トラブルシューティング

rootありなら、rootシェルでgetprop service.adb.tcp.portとgetprop persist.adb.tcp.portを実行して、スマホが実際に使っているポートを確認できます。rootなしの場合は、パソコンからのadb connectが確認方法です。スマホでワイヤレスデバッグも使っている場合、そのランダムなTLSポートは別に保存されている点に注意してください。ワイヤレス接続が動いていても、固定ポートが使えるとは限りません。

よくある質問

rootは必要ですか？ いいえ。rootなしでも、USB経由で一度TCP ADBを有効にすれば、説明したとおりにTailscale、リバーストンネル、WireGuardを使えます。デメリットは、再起動のたびに設定が失われ、誰かがケーブルを接続し直す必要があることです。rootを使えばその手間がなくなり、ファイアウォールとsuのオプションが加わります。このガイドの他の部分はrootに依存しません。

モバイルデータでも使えますか？ はい。Tailscale、WireGuard、リバーストンネルは、いずれもスマホから外向きに接続するためです。ルーターのポート転送だけが、この条件で失敗する方法です。

常時オンにしても安全ですか？ 守っている経路と同じ程度の安全性です。アクセスポリシーを設定したオーバーレイネットワークの内側であれば、リスクは小さくなります。実際に使うときだけオンにし、使わないときはオフにしてください。

キーの確認なしで悪用される可能性はありますか？ 通常のビルドでは、新しいパソコンはスマホで承認する必要があります。デバッグの認証が無効なビルドでは、承認なしで接続されます。そのため、ビルドにかかわらず、そのポートをインターネットに公開してはいけません。

リモートデスクトップアプリではだめですか？ 画面操作だけならそれで十分で、画面共有アプリはrootがまったく不要です。シェルコマンド、インストール、ファイル転送、ログを遠隔から扱いたい場合は、ADBが適しています。

本格的に使う前に

スマホをモバイルデータにし、パソコンを別のネットワークにした状態で、すべてをテストしてください。スマホを再起動して、自動で復帰するものを確認します。root化したスマホなら復帰するはずで、root化していないスマホなら、何をやり直す必要があるかを正確に把握しておきます。画面をオフにしたまましばらく試してください。これらのテストのどれかで接続できなくなった場合は、直すコストが安いうちに問題を見つけられたということです。

こうしたプロジェクト用にスマホを選んでいて、rootできる機種が欲しい場合は、root化できるスマホの一覧でクリーンにアンロックできる機種を確認できます。root専用のブートスクリプトのモジュール側については、Magiskモジュールのガイドで解説しています。rootに依存しないLinuxシェルについては、AndroidのLinux TerminalとTermuxの違いをご覧ください。

情報源と対象範囲

このガイドは2026年10月に、Android公式のドキュメントとソースコード、およびベンダーとセキュリティ研究の公開資料に基づいて調査しました。すべてのAndroidバージョンとROMでテストしたわけではありません。プロパティの挙動、ブートスクリプト、スマホ上だけで有効にする方法、ファイアウォールの方法、Termuxのバッテリー挙動は端末によって異なるため、頼る前にお使いのスマホで一つずつ確認してください。

• 出典 1： Android Developers、Android Debug Bridge（adb） 出典を開く
• 出典 2： Android Open Source Project、ADB Wi-Fiの設計ノート：従来のTCPは暗号化なし、Wi-FiモードはTLSを使用 出典を開く
• 出典 3： Android Open Source Project、adbd main.cpp、プロパティからのポート選択 出典を開く
• 出典 4： Android Developers Blog、ワイヤレスデバッグとADB Wi-Fi 2.0 出典を開く
• 出典 5： OmniROM、adbdプロパティに関するSELinuxポリシーの変更 出典を開く
• 出典 6： Tailscale、アクセス制御リスト 出典を開く
• 出典 7： Tailscale、Tailscale SSHの対応プラットフォーム 出典を開く
• 出典 8： Tailscaleコミュニティフォーラム、Androidでの切断とバッテリー使用 出典を開く
• 出典 9： Keysight、ADB経由のTrinityP2Pマルウェア 出典を開く
• 出典 10： The Hacker News、Matryosh DDoSボットネット（2021年2月） 出典を開く
• 出典 11： scrcpyのドキュメント、接続 出典を開く