droid.rooter
ハウツー上級10分で読めます

Android 17のワイヤレスADB:ペアリング、自動再接続、今も有効な対処法

ペアリングと接続は別の手順です。ADB Wi-Fi 2.0、2つのポート、現行のPlatform Tools、より安全なトラブルシューティングの順序を解説します。

Wireless ADB on Android 17: Pairing, Auto-Reconnect and the Fixes That Still Apply
目次
  1. 使っているワイヤレスADBの方式を確認する
  2. 実際に動いているADBを確認する
  3. 一部の広く使われていたmDNS対処法が古くなった理由
  4. スマホとパソコンをペアリングする
  5. ペアリング用ポートと接続用ポートは別物
  6. 「信頼するネットワーク」の意味を理解する
  7. ペアリング済みなのに接続できない場合の確認項目
  8. 1. 現在のアドレスと接続用ポートを確認する
  9. 2. 動作中のサーバーを確認する
  10. 3. サービス検出を調べる
  11. 4. ネットワークの安全性を下げずに確認する
  12. 「More than one device」は選択の問題
  13. ワイヤレスADBが動いても、Shizukuが常に動き続けるとは限らない
  14. 切断とアクセス権の取り消しは別
  15. 役に立つワイヤレスADBの不具合報告
  16. よくある質問
  17. Android 17でペアリングするのに、USBケーブルは必要ですか?
  18. デバイス一覧が空なのに、ADBがペアリング済みと表示するのはなぜですか?
  19. ADB Wi-Fi 2.0は、すべての古いAndroidスマホで使えますか?
  20. ADB_MDNS_OPENSCREEN=0は設定すべきですか?
  21. 解決のために5555番ポートを開けるべきですか?
  22. 診断は3つに分けて考える
  23. 情報源と対象範囲

「Successfully paired」と表示されれば、セットアップは完了したと思うはずです。ところがadb devicesを実行しても、何も表示されません。

この状況では、ペアリング画面に戻って別のコードを発行し、同じコマンドを繰り返し、同じ結果になる人が多くいます。見落とされているのは、ペアリングは信頼を確立するもので、接続は使えるデバッグ接続を作るものという違いです。

Android 17とADB 37.0.0では、ADB Wi-Fi 2.0が導入され、ペアリング済みの端末が信頼するワイヤレスデバッグ用ネットワークに参加したときの自動接続も含まれます。古いAndroidでもワイヤレスデバッグは使えますが、パソコンのADBを更新しただけでAndroid 17のすべての動作が使えるようになるわけではありません。出典1

以下の設定は、自分のスマホ、信頼できるパソコン、プライベートなネットワークを前提としています。所有者の許可なく端末を管理するための方法ではありません。

使っているワイヤレスADBの方式を確認する

「ワイヤレスADB」と呼ばれる状況は、実際には3種類あります。

方式見分け方覚えておくこと
現行のWireless debuggingAndroidのペアリングコードまたはQRコードによる手順パソコンをペアリングし、そのセッションの接続情報を使う
ADB Wi-Fi 2.0対応のAndroid 17対応するAndroid 17端末とADB 37以降信頼するネットワークの機能で、ペアリング済みの接続が自動的に復元される場合がある
従来のTCPモードadb tcpip 5555を使うチュートリアル現行のペアリングとTLSの手順ではない

Googleの実機向けガイドは、ミラーリングに使われる従来のadb tcpip接続が暗号化されていないと明確に警告しています。出典1 ルーターの5555番ポートを開けたり、ADBをインターネットに公開したりしないでください。

すべてを公開するファイアウォールのルールは、検出の問題の解決策として認められません。

実際に動いているADBを確認する

放置された「minimal ADB」系のものではなく、Googleから最新のSDK Platform Toolsをダウンロードしてください。そのうえで次を実行します。

adb version

見慣れたAndroid Debug Bridgeのプロトコルバージョンの行だけでなく、Versionの情報を読んでください。フォルダーを更新しても、シェルやIDEがそれを使っている証拠にはなりません。

Windowsの場合:

where.exe adb

macOSまたはLinuxの場合:

command -v adb

複数のコピーがある場合は、ツールがどのインストールを使うべきかを決めてください。無関係なSDKフォルダーを手当たり次第に削除してはいけません。意図したplatform-toolsディレクトリから直接実行して比較するのも有効です。

Googleのリリースノートによると、2026年7月にリリースされたPlatform Tools 37.0.1では、旧OpenScreenバックエンドが削除されました。このバージョンではADB_MDNS_OPENSCREENを設定しても効果はありません。現在有効な実装はlibadbmdnsです。出典3

すべての読者にその変数の切り替えを勧めるチュートリアルは、別のリリース向けに書かれた可能性があります。まずバージョンを確認してください。古い環境変数の回避策が今も存在するかを理解しないまま、新しいインストールに重ねてはいけません。

スマホとパソコンをペアリングする

信頼できるネットワークを使い、設定中はスマホのロックを解除したままにします。

Developer options > Wireless debuggingを開きます。ネットワーク上でのデバッグは、自分で管理し信頼できるネットワークでのみ許可してください。ペアリングコードによるペア設定を選び、そのダイアログは開いたままにします。

パソコンでは、そのダイアログに表示されたアドレスとペアリング用ポートを使います。

adb pair PHONE_IP:PAIRING_PORT

2つのプレースホルダーを実際の値に置き換え、求められたら表示されているコードを入力します。そのあと、次を確認します。

adb devices -l

これらは、Googleが文書化している、現行のADBペアリングと接続の確認方法です。出典2

有効なペアリングコードを、サポートフォーラムに投稿しないでください。ペアリングは単なる接続テストではなく、許可の判断です。

ペアリング用ポートと接続用ポートは別物

ペアリング後にスマホが表示されない場合は、ワイヤレスデバッグのメイン画面に戻ります。そこに表示されているアドレスと接続用ポートを使います。

adb connect PHONE_IP:CONNECTION_PORT
adb devices -l

最後にコピーした数字だからといって、ペアリングのダイアログのポートを使い回さないでください。Bugjaegerの開発者も、ワイヤレス接続のガイドでこの違いを説明しています。出典4

たとえば、同じスマホのIPアドレスでも、ペアリングのダイアログとメイン画面で表示されるポートが異なる場合があります。これらはそのセッションの情報であり、今後のすべてのコマンドに固定で書き込む恒久的な数字ではありません。

「信頼するネットワーク」の意味を理解する

判断は2つあります。パソコンを信頼するかどうかと、そのネットワークでワイヤレスデバッグを自動的に許可するかどうかです。

GoogleのAndroid 17向け手順によると、ネットワークの常に許可のオプションを選ぶと、そのネットワークが信頼するワイヤレスデバッグ用ネットワークになります。ペアリング済みのパソコンは、端末がそのネットワークに戻ったときに再接続できます。出典1

自分の机では便利です。ただし、ホテル、空港、共有の公共Wi-Fiを無期限に承認する理由にはなりません。

また、信頼するネットワークの設定は、Android 17で対象アプリに導入された、アプリ単位のローカルネットワーク権限とは別のものです。無関係なメディアアプリに権限を追加しても、ADBの設定は直りません。テレビ、プリンター、NASの検出はAndroid 17のローカルネットワークガイドで別に説明しています。

ペアリング済みなのに接続できない場合の確認項目

1. 現在のアドレスと接続用ポートを確認する

ワイヤレスデバッグのメイン画面で、もう一度読み取ってください。昨日のスクリーンショットや保存したコマンドに頼らないでください。そのうえで、現在のエンドポイントへ直接接続を試します。

直接接続できて自動検出だけできない場合は、問題がかなり絞り込めています。最初にやり直すべきなのは、おそらくペアリングではありません。

2. 動作中のサーバーを確認する

現行のADBで、次を確認します。

adb server-status

Googleのトラブルシューティング文書では、これでサーバーのバージョンとmDNSの状態を確認します。現行の実装では、mDNSが有効で、バックエンドがLIBADBMDNSであることを確認してください。出典2

クライアントのバイナリと、すでに動作中のサーバーは、別々に確認する必要があります。必要なら、意図したPlatform Toolsのインストールからサーバーを再起動します。

adb kill-server
adb start-server
adb server-status

そのパソコン上の、ほかのADB接続が中断されます。先に、作業中のデバッグを保存してください。

環境で明示的にmDNSを無効にしている場合は、その設定を削除するか、Googleが文書化しているシェル向けのADB_MDNS設定に従ってください。廃止されたOpenScreenの変数で代用してはいけません。出典2出典3

3. サービス検出を調べる

読み取り専用で確認できる便利な検出チェックは次のとおりです。

adb mdns services

その出力と、直接接続を試した結果を比べます。検出結果が空でも、それだけではスマホのペアリング認証情報が壊れているとは言えません。出典2

結果の組み合わせを記録します。

状況次に絞り込む手順
ペアリングと直接接続は成功するが、自動検出だけ失敗するmDNS、動作中のADBサーバー、ローカルネットワークのフィルタリングを確認する
ペアリングは成功するが、直接接続が失敗する現在の接続用ポート、ネットワーク経路、Wireless debuggingの状態を再確認する
自宅のLANやプライベートなテザリングでは動くが、会社のネットワークでは動かないクライアント分離と、許可された検出について管理者に確認する
1台のパソコンでは動くが、別のパソコンでは動かないPlatform Toolsのインストール、サーバーの状態、ホストのファイアウォール規則を比較する
ネットワークを切り替えるまでは動く恒久的にアクセスできると考えず、ネットワークの信頼設定と、新しいネットワークの接続性を見直す
同じ端末が2つ表示される使う接続経路を明示的に選ぶ

この表はトラブルシューティングの方法です。各状況で調査の範囲は絞れますが、どれも単独で通用する診断ではありません。

4. ネットワークの安全性を下げずに確認する

ゲストWi-Fi、クライアント分離、ホストのファイアウォール、VPNは、機器同士が検出や到達できるかどうかを変えることがあります。GoogleのADB文書も、制限の強いネットワーク環境をワイヤレスデバッグの問題の原因のひとつとして挙げています。出典2

自分で管理し信頼できるネットワークで試してください。同じスマホ、同じパソコン、同じADBのインストールで、条件を揃えます。そこで成功すれば、管理者に伝えるときの有用な証拠になります。

ファイアウォールの保護をすべて恒久的に無効にしてはいけません。OSとネットワークのポリシーで認められる、必要最小限の例外だけを作成してください。

「More than one device」は選択の問題

USB、Wi-Fi、エミュレーターの接続は共存できます。ADBの接続先の識別子が、スマホに印字されたハードウェアのシリアル番号と同じ形だとは限りません。

2022年のXDAの議論で、まさにこの混乱が説明されています。ユーザーはワイヤレスの識別子が変わることに気づき、1つの固定のシリアルで接続したいと考えていました。返信とテストは、ADBが実際に表示している接続経路を選ぶことを中心に進みました。出典6

現在の一覧を読み、使いたい接続の識別子をコピーします。

adb devices -l
adb -s "EXACT_IDENTIFIER_FROM_THE_LIST" shell getprop ro.product.model

2つ目のコマンドは、読み取り専用の識別チェックです。間違った接続先が表示された場合は、インストール、削除、書き込みのコマンドを使う前に止めてください。

mDNSベースの識別子の一部を、残りの文字列のほうが見慣れているからといって切り取らないでください。

ワイヤレスADBが動いても、Shizukuが常に動き続けるとは限らない

ADBのペアリングと、ADB経由で起動したアプリのライフサイクルは、関連はありますが別の問題です。

Shizukuは、独自の起動方法、再起動時の動作、機種ごとの制限を文書化しています。出典5 パソコンがADB Wi-Fi 2.0で自動再接続しても、Shizukuが自動的に再起動した証拠にはならず、Androidがアプリのサービスを停止しないことの保証にもなりません。

アプリ自体のステータス画面を確認してください。ADBは動くのに依存するツールが動かない場合は、成功したADBのペアリングをやり直すのではなく、そのツールの起動と認証を調べます。

スマホ自身でローカルのワイヤレスデバッグを使うヘルパーアプリにも、同じ区別が当てはまります。そのアプリが対応している手順に従ってください。パソコン向けの手順が、ループバック接続と同じだとは考えないでください。

切断とアクセス権の取り消しは別

作業が終わったら、不要ならWireless debuggingをオフにします。パソコンの信頼を取り消すには、Paired devices > the workstation > Forgetを使います。Googleのガイドには、以前ペアリングしたパソコンを削除するために、デバッグの許可を取り消す方法も説明されています。出典1

adb disconnectは、接続経路を閉じるだけです。信頼できないパソコンの削除や、自動のネットワーク信頼の解除の代わりにはなりません。

端末を貸し出したり売却したりする前に、引き渡しの一環として、許可したパソコンと開発者向け設定を見直してください。サポート用に一時的に使ったパソコンを、セッションが終わったからといってペアリングしたまま残さないでください。

役に立つワイヤレスADBの不具合報告

スマホの機種と正確なAndroidのビルド、adb versionとadb server-statusの出力、ペアリングが成功するか、直接接続が成功するか、別の信頼できるネットワークで同じ設定が動くか、を含めてください。

USBとWi-Fiが同時に接続されているかも明記してください。接続先の選択が問題の場合は、伏せ字にしたadb devices -lの結果も含めます。

ペアリングコード、ADBの秘密鍵、個人のアプリデータを含む完全なログは公開しないでください。検出、信頼、接続を分けて書いた報告は、全員の時間を節約します。

よくある質問

Android 17でペアリングするのに、USBケーブルは必要ですか?

対応している現行のWireless debuggingのペアリング手順では不要です。最初にUSB経由でTCPモードを有効にする古いチュートリアルと混同しないでください。出典1出典4

デバイス一覧が空なのに、ADBがペアリング済みと表示するのはなぜですか?

ペアリングと、有効な接続は別です。メイン画面の現在の接続用ポートを確認し、そのうえで検出とサーバーの状態を調べてください。

ADB Wi-Fi 2.0は、すべての古いAndroidスマホで使えますか?

文書化されている新しい組み合わせは、Android 17とADB 37.0.0以降です。それより前のバージョンでも従来のワイヤレス手順は使えますが、同じ自動動作が保証されるわけではありません。出典1

ADB_MDNS_OPENSCREEN=0は設定すべきですか?

Platform Tools 37.0.1の対処としては不要です。Googleによると、この変数はそのリリースではもう効果がありません。出典3

解決のために5555番ポートを開けるべきですか?

いいえ。公開ポートの転送は、現行のローカルペアリング手順には含まれません。デバッグは、許可された端末とネットワークに限定してください。

診断は3つに分けて考える

パソコンはスマホを検出できるか。パソコンは信頼されているか。現在の接続を確立できるか。

これらを別々に確認してください。コードを繰り返し発行して、うまくいくことを期待するのではなく、ネットワークを直すのか、正しいエンドポイントを選ぶのか、動作中のADBのインストールを更新するのか、実際のペアリングの問題を直すのかがわかります。

情報源と対象範囲

調査確認日:2026年9月28日。コマンドは、Googleが文書化しているADBインターフェースと、説明用のプレースホルダーを使っています。この記事のために、メーカーやネットワークをまたいで自動再接続を実機でテストしたとは主張していません。

  • 出典1:Android Developers、実機でのアプリの実行、Android 17のWi-Fi 2.0、信頼するネットワーク、ペアリングと取り消し。出典を開く
  • 出典2:Android Developers、Android Debug Bridgeとワイヤレスデバッグのトラブルシューティング。出典を開く
  • 出典3:Android Developers、SDK Platform Toolsのリリースノート、特に37.0.0と37.0.1。出典を開く
  • 出典4:Bugjaegerの開発者、Wi-Fi経由の接続、ペアリング用ポートと接続用ポートを含む。出典を開く
  • 出典5:Shizuku公式のセットアップガイド、起動方法と機種ごとの制限。出典を開く
  • 出典6:XDA、2022年8月のワイヤレスADBの識別子とポート割り当ての変化に関する議論。過去のユーザーによるトラブルシューティングで、Android 17のテストではありません。出典を開く