adbコマンド入門｜導入から基本一覧、logcatまで使い方を体系化

Android端末の検証や開発で「adbを使えば早い」と分かっていても、最初につまずきやすいポイントがいくつかあります。例えば、adbコマンドが見つからない、adb devicesに端末が表示されない、unauthorizedになる、logcatが大量で追えないなどです。これらは知識不足というより、手順の抜け漏れや前提条件の見落としが原因になりやすい領域です。

本記事では、adbコマンドの導入から、用途別の代表コマンド、トラブルシューティング、ワイヤレスデバッグまでを、初学者でも再現できるように体系立てて解説いたします。なお、端末や組織のセキュリティポリシー（MDM管理等）によってはUSBデバッグやワイヤレスデバッグが制限される場合があります。まずは「安全に試せる範囲」を明確にしながら進めてください。

※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。

adbコマンドでできることと安全に使う前提

adbの役割と仕組み

adb（Android Debug Bridge）は、PC側からAndroid端末に対して操作命令を送るためのブリッジ（橋渡し）です。体感としては「PCから端末を操作するコマンド」ですが、内部的には概ね次の要素で成り立っています。

• adbクライアント：PC側で実行するadbコマンド本体です。

• adbサーバー：PC側で常駐し、接続中の端末を管理する役割を持ちます。

• adbd（デバイス側デーモン）：端末側で動作し、PCからの命令を受け取って処理します。

この構造を押さえると、トラブル時の切り分けが容易になります。例えば、adbが見つからない場合は「クライアントがない／PATHが通っていない」可能性が高く、adb devicesで認識されない場合は「接続／権限／ドライバ／サーバー状態」の問題が疑われます。

また、adbは単体で完結するというより、adb shellの中で利用できる各種コマンド（pm、am、dumpsys、getprop、inputなど）と組み合わせて効果を発揮します。したがって、「adbの基本操作」と「adb shell配下の道具」の二段構えで理解すると、学習が短距離で済みます。

USBデバッグとRSA承認の注意点

USBで実機をつないでadbを利用する場合、端末側で開発者向けオプションを有効化し、その中でUSBデバッグをオンにする必要があります。さらに、初回接続時には端末側に「このPCを許可するか」という確認（RSA承認）が表示されることが一般的です。ここで許可しない限り、PC側は端末を操作できません。

特に重要なのは、USBデバッグが単なる便利機能ではなく、端末の操作権限に関わる設定である点です。紛失や第三者アクセスのリスクを増やさないためにも、以下の運用を推奨いたします。

安全に使うためのチェックリスト

• USBデバッグは必要な時間だけオンにし、作業後はオフへ戻す

• 初回接続時の許可ダイアログは、PCの持ち主・接続意図を確認してから許可する

• 共有PCや不特定多数が触れるPCでは接続しない

• 業務端末・管理端末では規定（セキュリティポリシー）を優先する

• 端末をロック解除したまま放置しない

「unauthorized」が出る場合は、多くがRSA承認周りの問題です。後述のトラブルシューティングで具体策を示します。

ワイヤレス接続の種類と使い分け

adbをワイヤレスで扱う方法は、考え方として次の2系統に分けると整理が楽になります。

1. Android 11以降のワイヤレスデバッグ（ペアリング方式）
   端末側でワイヤレスデバッグを有効化し、QRコードやペア設定コードでPCとペアリングして利用する方式です。USBケーブルなしでもデバッグやデプロイが可能になり、日常の開発では扱いやすい方式です。端末メニューの導線はメーカー差があるため、実行時は設定画面の表記に従ってください。

2. 旧来のadb tcpip/connect方式
   端末をTCP接続モードに切り替え、PCからadb connect <IP:PORT>で接続する方式です。環境依存が強く、ネットワーク上にデバッグ口を開ける形になりやすいため、取り扱いには注意が必要です（詳細は後述します）。

使い分けの目安

• まずはUSB接続（安定性が高く、切り分けが容易です）

• ケーブルが困難で、Android 11以降ならペアリング方式を優先

• 旧来方式は限定的な検証・閉域ネットワーク・短時間利用にとどめる

adbコマンドを使えるようにする導入手順

Platform-Toolsの入手と配置

adbは一般に「Android SDK Platform-Tools」に含まれています。Android Studioを導入している場合は、SDKマネージャ経由でPlatform-Toolsを入れるのが基本です。一方、adbだけを使いたい場合やCI環境で利用する場合は、Platform-Toolsのみを入手して配置する運用もよく行われます。

配置のポイントは「どこに置いたか」を自分で把握できることです。以下のいずれかに統一すると混乱が減ります。

• 方針A：PATHを通してどこからでもadbを呼ぶ

  • メリット：毎回フォルダ移動が不要

  • デメリット：複数バージョンを入れると混在しやすい

• 方針B：platform-toolsフォルダでのみ実行する

  • メリット：バージョンの混在が起きにくい

  • デメリット：都度フォルダ移動が必要

初学者の方は、まず方針B（フォルダ固定）から始め、慣れたらPATHへ移行すると失敗が少ないです。

PATH設定と動作確認

導入の最初のゴールは「adb versionが通る」ことです。これが通れば、少なくともPC側の準備は完了に近づきます。

動作確認手順（共通）

1. ターミナル（WindowsならPowerShell／コマンドプロンプト、Mac/LinuxならTerminal）を起動する

2. 次を実行する

   • adb version

失敗パターンと対処

• adb: command not found / 「’adb’ は認識されません」

  • platform-toolsが入っていない、またはPATH未設定です。

  • 方針Bの場合：platform-toolsフォルダへ移動してから実行してください。

  • 方針Aの場合：環境変数PATHにplatform-toolsのパスを追加し、ターミナルを再起動してください。

• adb server is out of date 等のメッセージ

  • 古いadbサーバーが残っている可能性があります。後述のadb kill-server→adb start-serverを試してください。

PATH設定はOSごとに操作が異なるため、組織の標準手順や社内ドキュメントがある場合はそれに従ってください。重要なのは「コマンドが通る状態」を作り、次に端末接続へ進むことです。

端末側の設定と接続確認

次に、端末をPCにつないで認識できるか確認します。最初に行うべきコマンドは非常にシンプルです。

• adb devices

この出力に、端末のシリアルとステータスが表示されれば接続は成功です。表示例のイメージは次のとおりです。

• <serial> device（正常に利用可能）

• <serial> unauthorized（端末側承認が必要）

• 何も表示されない（接続／ドライバ／権限／ケーブル等の問題）

接続確認の際は、端末の通知領域にUSB接続のモードが出る場合があります。「ファイル転送」「テザリング」などの選択肢が見える機種もあるため、表示される選択肢の中でPCとの通信が可能なモードへ切り替えてください。

よく使うadbコマンド一覧を用途別に整理

ここでは「最初に覚えるべき頻出コマンド」を用途別に整理し、実行例と注意点を併記いたします。まず全体像を掴むために早見表を提示し、その後に各カテゴリを詳しく説明します。

用途別コマンド早見表

この表をベースに、「どの目的で、どのコマンドを使うか」を機械的に選べる状態が理想です。

接続と複数端末指定

複数端末（実機＋エミュレータ、あるいは複数実機）が接続されている状態で、端末指定をしないままコマンドを実行すると、意図しない端末に操作が入るリスクがあります。特にuninstallや設定変更系コマンドは事故につながりやすいため、次をルール化してください。

推奨ルール

1. まず必ず一覧取得：adb devices

2. 以降は必ず端末指定：adb -s <serial> ...

例：

• adb -s <serial> shell

• adb -s <serial> install app.apk

• adb -s <serial> logcat

端末指定は、慣れるほどに「ミスを減らす投資」になります。チームで共有する手順書にも必ず盛り込むとよいでしょう。

アプリのインストールと削除

APKの導入・削除は最頻出です。基本形は次のとおりです。

• インストール：adb install <apk>

• アンインストール：adb uninstall <package>

よくある注意点

• 既に同じパッケージが入っている場合、署名違いなどで失敗することがあります。

• ダウングレード（バージョンを下げる）できない設定の端末では、上書きが失敗します。

• 端末の空き容量が不足していると導入できません。

アプリの操作ではadb shell配下のam（Activity Manager）もよく使います。起動や停止ができるため、再現手順の自動化や検証の短縮に役立ちます。

例（起動のイメージ）：

• adb shell am start -a android.intent.action.VIEW

例（強制停止）：

• adb shell am force-stop <package>

特に強制停止は「再現性のある検証」を作る際に便利ですが、端末状態を変える操作でもあるため、検証目的とセットで記録に残す運用を推奨いたします。

ファイル転送とバックアップの考え方

ファイル転送は「端末で取得した成果物（ログ、スクショ、録画、設定ファイル等）をPCへ持ち帰る」用途で非常に重要です。基本は以下の2つです。

• PC → 端末：adb push <local> <remote>

• 端末 → PC：adb pull <remote> <local>

例：

• adb push ./test.txt /sdcard/Download/test.txt

• adb pull /sdcard/Download/test.txt .

運用上のコツ

• 端末側の保存先は、まず/sdcard/Download/など分かりやすい場所に寄せると整理しやすいです。

• 取得物は「日時」「端末名」「案件名」などのフォルダ規則を決めて保存すると、後で探す時間が減ります。

• バックアップは端末・OS・ポリシーで制約が大きいため、「必要ファイルをpullする」「必要ログを保存する」という小さな単位に分解すると安全です。

ログ取得とlogcatの絞り込み

adb logcatはAndroidのログを取得する中心手段です。基本コマンドは次のとおりです。

• adb logcat

しかし、そのまま実行すると大量のログが流れて読み切れないことが多いです。そこで、初学者がまず押さえるべき「絞り込みの基本」を3つにまとめます。

1）タグ指定で絞る

• adb logcat -s <Tag>
  例：

• adb logcat -s MyTag

アプリ側でログタグが統一されている場合、効果が大きい方法です。

2）一度クリアしてから再現する

• adb logcat -c（ログをクリア）

• 再現操作を行う

• adb logcatで直近のログを見る

原因調査では「再現前のノイズを消す」だけでも大きく読みやすくなります。

3）ファイルへ保存して検索可能にする

• adb logcat > log.txt

画面で追うより、保存してから検索（キーワード、例外、パッケージ名、タイムスタンプ等）するほうが早いケースが多いです。特に長時間の再現や断続的な不具合では必須に近い方法です。

補足：ログ取得の基本姿勢

• まず「再現条件」を固定し、ログ取得の開始タイミングを明確にする

• 取得したログに「端末」「OSバージョン」「アプリバージョン」「再現手順」を紐付ける

• 調査対象がUIならスクショ・録画も合わせて残す（後述のscreencap/screenrecordを併用）

画面操作と入力

画面証跡の取得は、チーム内共有・不具合報告・再現確認で大きな価値があります。代表はスクリーンショットと画面録画です。

スクリーンショット（端末に保存 → PCへ取り出し）

1. 端末に保存

   • adb shell screencap -p /sdcard/Download/screen.png

2. PCへ取り出し

   • adb pull /sdcard/Download/screen.png .

画面録画（端末に保存 → PCへ取り出し）

1. 端末に保存

   • adb shell screenrecord /sdcard/Download/record.mp4

2. PCへ取り出し

   • adb pull /sdcard/Download/record.mp4 .

次に、入力操作です。自動操作の最初の一歩として使われます。

例：

• テキスト入力：adb shell input text hello

• キーイベント：adb shell input keyevent 3（ホーム）

入力は端末のフォーカス状態やIME設定の影響を受けるため、失敗する場合があります。対策として「スクショで現在画面を確認 → 必要なら画面遷移 → 入力」という順序を徹底すると安定しやすいです。

端末情報の取得

不具合調査で重要なのは「端末がどういう状態だったか」を説明できることです。そこで、端末情報を取得するコマンドを覚えておくと、切り分けが大きく前進します。

• プロパティ確認：adb shell getprop

  • 端末の各種プロパティ（ビルド情報等）を一覧できます。

• システム状態の取得：adb shell dumpsys

  • 情報量が非常に多いため、目的に応じて対象を絞ります。

dumpsysは全量だと読み切れないため、まずは「調べたいものを一つに決める」ことが重要です。例えばバッテリー状態であれば以下のように対象を絞ります。

• adb shell dumpsys battery

他にも、ネットワーク、アクティビティ、ウィンドウ状態など、調べたい領域に応じて対象が変わります。初学者の段階では「getpropで基礎情報」「dumpsysで状況証拠」と理解し、必要になったら対象を拡張していくのがよいでしょう。

adbコマンドのトラブルシューティング

adbコマンドが見つからない

症状

• adb: command not found

• 「’adb’ は認識されません」

主な原因

• Platform-Toolsが導入されていない

• PATHが通っていない

• ターミナルを開き直していない（PATH反映前のセッションを継続している）

対処手順

1. platform-toolsが存在するか確認する

2. 方針Bなら、platform-toolsフォルダへ移動してadb version

3. 方針Aなら、PATHにplatform-toolsを追加し、ターミナルを再起動してadb version

4. まだ解消しない場合、同名の別ツールや古いadbが混在していないか確認する

「どのadbを実行しているか」を確認できる環境では、その表示（例：パス表示）で混在を疑うのが効果的です。

adb devicesに表示されない

症状

• adb devicesを実行しても何も出ない

• 端末が一覧に出ない

主な原因

• USBケーブルがデータ転送に対応していない（充電専用）

• 端末側のUSBモードが不適切

• USBデバッグが無効

• Windowsの場合、ドライバが適切でない

• adbサーバーが不調

対処（上から順に確認）

1. ケーブルを交換：データ転送対応ケーブルを使用する

2. 端末側設定：USBデバッグをオン、必要ならUSB接続モードを見直す

3. サーバー再起動：

   • adb kill-server

   • adb start-server

   • adb devices

4. 別ポート／別PCで検証：物理的な相性やポート不良を切り分ける

5. Windowsのドライバ確認：デバイスマネージャ等で認識状態を確認する

ここで大切なのは、原因が「PC側」「ケーブル」「端末側」のどこにあるかを切り分けることです。別ケーブル・別ポート・別PCは非常に強い切り分け手段です。

unauthorizedと表示される

症状

• adb devicesでunauthorizedとなる

• 端末操作ができない

主な原因

• 端末側でRSA承認をしていない

• 端末がロック中で承認ダイアログが見えていない

• 許可済みPCの情報が不整合になっている

対処手順

1. 端末のロックを解除し、画面に承認ダイアログが出ていないか確認する

2. 「このPCを許可」を許可する（必要なら「常に許可」も検討）

3. それでも改善しない場合、端末側で「USBデバッグの許可を取り消し」を実行し、再接続する

4. adb kill-server→adb start-serverでPC側もリセットする

「unauthorized」は焦りやすい表示ですが、ほとんどは承認手順の見落としで解消します。

installが失敗する

症状

• adb installで失敗する

• 既存アプリの上書きができない

主な原因

• 同一パッケージで署名が異なる

• ダウングレード不可（バージョンコードの関係）

• 端末のストレージ不足

• 端末ポリシーによりインストール制限がある

対処の考え方

• 既存アプリを残したまま上書きしたいのか、入れ直してよいのかをまず決めます。

• 入れ直しが許容される場合：adb uninstall <package>→adb install <apk>の流れが単純です。

• 入れ直しが難しい場合：署名やバージョン整合（ビルド設定・配布経路）を見直す必要があります。

また、失敗時はadb logcatでインストール前後のログを採取しておくと、原因特定が早くなります。特に端末ポリシーや権限起因の制限は、UIでは分かりにくい場合があります。

logcatが多すぎて追えない

症状

• adb logcatのログが流れ続け、目的の行を見失う

対処の優先順位

1. タグ指定で絞る：adb logcat -s <Tag>

2. クリアしてから再現：adb logcat -c→再現→adb logcat

3. ファイルに保存し検索：adb logcat > log.txt

補助テクニック（運用面）

• 取得開始時刻と再現開始時刻をメモしておく

• 「再現のトリガー操作」を短くし、ログの量を減らす

• 画面録画とセットで保管し、ログと映像を突合できるようにする

「ログを読む」より前に、「ログを読みやすい状態にする」が重要です。ここが整うだけで調査効率が大きく変わります。

adbコマンドの応用例と運用のコツ

Android 11以降のワイヤレスデバッグ手順

Android 11以降では、端末設定からワイヤレスデバッグを有効化し、PCとペアリングして利用できます。端末によってメニューの場所は異なりますが、基本は以下の流れです。

実施の流れ（概要）

1. 端末の開発者向けオプションを有効化する

2. ワイヤレスデバッグをオンにする

3. 「ペア設定コード」または「QRコード」でPC側とペアリングする

4. ペアリング完了後、PC側から対象デバイスへ接続し、通常のadb操作を行う

運用上の注意

• 同一ネットワークであること、ネットワークが安全であることを確認する

• ペアリング情報の扱いに注意し、不要になったら解除する

• 共有Wi-Fiや来客用ネットワークでは避ける

ワイヤレスは便利ですが、安定性はUSBに劣ることがあります。重要な検証では、まずUSBで再現性を確保してからワイヤレスへ移行する流れが堅実です。

旧来のadb tcpip connectの注意点

旧来方式は、端末をTCP接続モードに切り替えることで、IPアドレス指定で接続します。技術的には簡単に見えますが、ネットワーク上でデバッグ経路を開く形になるため、次のリスクがあります。

• 誤って想定外のネットワークに露出する

• 他者が同一ネットワーク上にいる場合のリスクが増える

• 端末や環境により接続が不安定・再現性が低い

推奨する使い方

• 閉域環境で短時間のみ実施する

• 目的を「ケーブルが使えない一時対応」に限定する

• 作業後は設定を戻し、不要な状態を残さない

テスト自動化での定番レシピ

adbは単発操作だけでなく、「繰り返し」を前提とした検証にも向いています。例えば次のような「型」を作ると、再現・検証の速度が上がります。

定番レシピ例

1. 端末認識：adb devices（必要なら-sで対象固定）

2. 状態整備：必要に応じてadb reboot

3. アプリ入れ替え：adb uninstall <package>→adb install <apk>

4. ログ採取開始：adb logcat -c→adb logcat > log.txt

5. 再現操作：手動またはadb shell input ...で支援

6. 証跡取得：screencap/screenrecord→pull

7. 成果物整理：端末情報（getprop等）とセットで保存

ここで重要なのは、成果物（ログ・映像・端末情報）を同じフォルダにまとめ、後で第三者が追跡できる状態にすることです。属人化を防ぐうえで、ファイル名規則（日時、端末名、ビルド番号、案件名）を決めるだけでも効果があります。

セキュリティとコンプライアンス注意点

adbは強力なため、運用ルールが曖昧だとリスクが上がります。特に業務端末・顧客データを扱う環境では、以下を守ってください。

安全運用チェックリスト

• USBデバッグは必要時のみオン、作業後は必ずオフ

• 端末の承認ダイアログは、PCの管理者・利用目的を確認してから許可

• 共有PCや不特定多数が触れる環境では接続しない

• ワイヤレスデバッグは安全なネットワークでのみ実施

• ログやスクショには個人情報が含まれる可能性があるため、保管・共有先を制限する

• 組織の規定（MDM、情報管理規程、持ち出し規程）を優先する

「便利だから常時オン」は避けるべきです。必要なときに安全にオンにし、終わったら戻す、この一往復が最も重要です。

adbコマンドのFAQ

パッケージ名の調べ方は

アンインストールや強制停止にはパッケージ名が必要です。代表的な方法は次のとおりです。

• adb shell pm list packages

これにより、端末にインストールされているパッケージの一覧を取得できます。数が多い場合は、まず一覧を取得してから、目的のアプリ名に近いものを探します。運用上は、アプリ配布時に「パッケージ名」を記録しておくと、現場で探す時間が削減できます。

また、特定アプリだけを探したい場合は、ターミナル側の検索機能（フィルタ）を併用すると効率的です（OSによって手段が異なるため、環境に合わせて実施してください）。

pmとamは何が違うか

両者は役割が異なります。

• pm（Package Manager）：パッケージ（アプリ）そのものを対象にします。

  • 例：パッケージ一覧、アプリ情報、権限周り、無効化・有効化など

• am（Activity Manager）：アプリの起動や画面遷移、ブロードキャストなど、実行中の挙動に近い領域を対象にします。

  • 例：アクティビティ起動、強制停止、インテント送信など

「アプリという箱を扱うのがpm」「アプリの動きを扱うのがam」と捉えると理解しやすいです。

端末を初期化せずに状態を戻す方法は

初期化せずに状態を戻す場合は、「何を戻したいか」を先に定義すると適切な手段を選べます。

• アプリの挙動をリセットしたい：adb shell am force-stop <package>→再起動（必要なら）

• 端末全体をリフレッシュしたい：adb reboot

• ログのノイズを消したい：adb logcat -c

• 証跡の取得をやり直したい：スクショ／録画ファイルを削除して取り直す

また、検証端末であれば「再現のための状態」を毎回作り直すのが理想です。状態がぶれると、同じ不具合に見えても原因が変わってしまい、調査が長期化します。

端末が複数ある場合のベストプラクティスは

複数端末運用は、誤操作防止が最優先です。次の3点をベストプラクティスとして推奨いたします。

1. 必ずadb devicesで現状を確認（接続端末の全体像を把握）

2. 以降はadb -s <serial>を常用（対象端末を固定して操作）

3. 操作ログを残す（実行コマンド、端末、結果、取得物の保存先）

特にチーム作業では「どの端末に、何をしたか」が後で追えないと復旧が難しくなります。単純なテキストログでもよいので、作業記録を残す運用を推奨いたします。

最後に、本記事の要点を整理いたします。

• adbは「PCから端末を操作する」仕組みであり、導入ではまずadb version、接続確認ではadb devicesが基準になります。

• つまずきやすいのは「PATH」「ケーブル」「USBデバッグ」「RSA承認（unauthorized）」「logcatのノイズ」です。

• よく使う操作は「インストール／削除」「ファイル転送」「ログ」「証跡（スクショ・録画）」「端末情報（getprop/dumpsys）」に集約できます。

• ワイヤレスは便利ですが、安定性と安全性を優先し、USB→ペアリング方式→旧来方式の順で検討するのが堅実です。