Fastbootで端末が認識されない：ケーブル、ドライバー、USB、モードの確認

fastboot devicesの出力が空になる原因は6つあり、ドライバーはそのうちのひとつにすぎません。現在のモード、ケーブル、ポート、platform-toolsのバージョン、ホストOSのデバイス割り当て、ドライバーが、コマンドとスマホの間に入っています。順番に切り分ければ、10分ほどで本当の原因が見つかります。

まず、実際に今どのモードにいるかを確認する

人が飛ばす確認ですが、最も分かりにくい不具合の原因になります。

ブートローダーのfastbootとfastbootdは別の環境です。Android Open Source Projectのドキュメントによると、fastbootdはユーザー空間のデーモン兼モードで、Android 10以降でサイズ変更可能なパーティションに対応するため、fastbootの実装をブートローダーからユーザー空間へ移したときに導入されました。どちらも画面には「fastboot」と表示され、パソコン側では同じfastbootツールを使います。ただし扱えるパーティションが異なり、同じパソコンでも動作が変わることがあります。

対応する端末では、次のコマンドでどちらか確認できます。

fastboot getvar is-userspace

結果がyesならfastbootd、noならブートローダーのfastbootです。まったく応答がない場合は接続の問題なので、この記事の残りの手順が当てはまります。

SamsungのDownloadモードはfastbootではありません。Samsung端末は通常、独自のプロトコルとツールを持つ別の書き込みインターフェースを使います。DownloadモードのSamsung端末をfastboot devicesは検出できず、これは不具合ではなく想定どおりの動作です。画面にDownloadモードが表示されているなら、fastbootは適切なツールではなく、ドライバーをいくら調整しても変わりません。

リカバリーもfastbootではありません。リカバリーにある端末はfastboot devicesではなくadb devicesに応答します。リカバリーのメニューが見えているなら、ADBを使ってください。この状態の意味はAndroidがリカバリーで起動し続けるときで説明しています。

切り分けの手順

上から順に進めてください。各段階でひとつのレイヤーを除外でき、それぞれ具体的なテストがあるので、推測に頼る必要はありません。

4段階目がすべてを決めます。USBでは認識されるのにfastboot devicesに表示されない端末は、パソコン側の問題で、直すことができます。そもそも認識されない端末は別の状況で、ソフトウェアの問題ではない可能性もあります。この段階は飛ばさないでください。

ケーブル

充電できるUSBケーブルが、データ通信もできるとは限りません。充電専用ケーブルがあり、エラーも原因の手がかりも出ないまま、今回の症状とまったく同じ状態になります。

テストは見た目ではなく動作で行います。外見では判別できません。そのパソコンで、どの機器とでもよいので、自分でファイル転送したことのあるケーブルを使ってください。データ通信を確認済みのケーブルがない場合は、それを用意するのが最優先です。ケーブルが不良だと、これ以降のどの段階も結果が信頼できなくなります。

ケーブルは劣化もします。昨年まで使えたケーブルでも、今は導線が切れていることがあり、不具合が断続的に出ることが多いため、スマホ側の問題に見えます。

ほかに知っておきたいケーブルの注意点が2つあります。スマホに付属していたケーブルが残っているなら、まず試すケーブルとして適しています。また、長いケーブルや細いケーブルは、充電はできてもデータ通信が不安定になることがあるため、長さは無関係ではありません。

ポートとハブ

USBハブ、モニターのポート、キーボードのパススルー、ドック、延長ケーブルはいずれも余計な層を増やし、モード切り替え時に接続が切れたり、認識を妨げたりすることがあります。

パソコン本体のポートに直接つなぎ、デスクトップなら前面パネルより背面のポートを選んでください。前面パネルは内部でケーブル接続されているため、接触が不安定になりやすい箇所です。

ポートの世代も試す価値があります。ブートローダーモードの端末は、USBコントローラーの世代によって動作が変わると報告されています。常に起きるわけでも、事前に予測できるわけでもないため、実際に試すしかありません。USB 2.0とUSB 3.xのポートがあるなら、両方を試してください。費用はかからず、ドライバーを何度入れ直しても解決しない種類の問題が解消することがあります。

Platform-toolsのバージョン

Googleのデベロッパーサイトで配布されている、最新の公式Android SDK Platform Toolsパッケージを使ってください。再パッケージされた「minimal ADB and fastboot」系のもの、書き込みツールに同梱されていたコピー、3年前にダウンロードしたものは避けます。

ここで問題は2つあります。

バージョンが端末に対して古すぎる。新しい端末や新しいパーティション構成には、新しいツールが必要です。古いリリースのfastbootバイナリは、最近の端末が返す情報を理解できないことがあります。

パソコンに複数のコピーがある。書き込みツールは独自のコピーを同梱してインストールします。それがPATHに入っていると、入力したコマンドが想定と違うバイナリを実行している場合があります。実際にどれが動いているか確認してください。

fastboot --version

Windowsではwhere fastboot、macOSまたはLinuxではwhich -a fastbootを実行します。複数のパスが表示された場合は、ほかのトラブルシューティングより先にそれを解消してください。

Windowsのドライバー状態

Windowsは、USB機器が自分をどう識別するかに基づいてドライバーを割り当てます。ブートローダーモードのスマホは、Androidが動作している同じスマホとは別の識別で現れます。そのため、同じパソコンと同じケーブルで、ファイル転送は問題なくできるのにfastbootからは見えない、ということが起こります。

Device Managerを開き、スマホをブートローダーモードで接続しながら表示を見てください。見えた内容によって対処が決まります。

• 正しい名前のAndroid bootloader interface。ドライバーは割り当て済みです。問題は別の場所にあるので、ツールの段階に戻ってください。
• 不明なデバイス、または警告マーク付きのデバイス。ドライバーが割り当てられていません。典型的なケースです。
• 接続しても何も現れず、何も消えない。認識されていません。ドライバーではなく、ケーブル、ポート、または端末自体に原因があると考えられます。
• 項目が現れてすぐ消える。端末が再起動しているか、電力を失っています。結論を出す前に、別のポートと別のケーブルを試してください。

ドライバーのインストールが必要な場合は、ブランドごとのメーカー純正USBドライバーパッケージを使います。PixelとNexusはGoogleのUSBドライバーを使います。どちらもメーカーの公式サイトから入手してください。ダウンロードサイトにあるサードパーティのドライバー詰め合わせは避けます。

ドライバー導入手順の中には、Windowsのドライバー署名の強制を無効にするよう勧めるものがあります。これは実際のシステムセキュリティ設定です。無効にする場合は、その意味を理解したうえで、終わったら必ず元に戻してください。

macOSとLinux

どちらのOSも、Windowsのような意味でのドライバーは必要ありません。失敗の原因は別のところにあります。

macOS。ドライバーのインストールは不要です。ブートローダーモードで接続した状態で、System InformationのUSBの項目に端末が表示されるか確認してください。そこに表示されるのにfastboot devicesの出力が空なら、問題はシステムではなくツールの段階にあります。最近のmacOSでは、ダウンロードしたバイナリの初回実行時の許可確認が妨げになることもあるため、ツールの実行が許可されているか確認してください。

Linux。端末は通常、設定なしで認識されますが、お使いのユーザーアカウントにアクセス権が付与されていない場合があります。接続の前後にlsusbで認識を確認してください。lsusbには表示されるのにfastboot devicesに出ない場合は、まず権限を疑います。多くのディストリビューションが配布している、またはandroid-udev-rulesプロジェクトが管理しているAndroid向けのudevルールで解決します。

簡単な診断方法があります。同じコマンドを通常ユーザーで実行すると見つからず、昇格した権限で実行すると見つかるなら、接続ではなく権限の問題だと確認できます。すべてを昇格した権限で実行するのではなく、適切なudevルールで直してください。

仮想マシンとWSL。仮想マシンやWSLへのUSBパススルーは追加のレイヤーで、独自の失敗パターンがあります。特にモード切り替え時は、ブートローダーモードに入る、または出るときに端末が別のUSB識別で切断と再接続を行うため、パススルーが追従しないことがあります。仮想マシン内で調べている場合は、結論を出す前にホストで直接テストしてください。

ADBは使えるのにfastbootが使えない場合

これは最もよくあるパターンで、スマホが明らかに接続されているのに使えないため、混乱しやすい状況です。

理由は、通常どおり動作しているAndroidと、ブートローダーモードの端末が、パソコンから見ると別々のUSB機器だからです。識別子もインターフェースも異なり、割り当てられるドライバーも違う可能性があります。ADBが動くことは、ケーブルとポートに問題がないことを示し、それ自体は有益です。ただし、ブートローダーモードでの接続については何も保証しません。

この状況になったら、その結果は記録しておいてください。ケーブルとポートは除外できます。5段階目と6段階目にそのまま進みます。Windowsではブートローダーインターフェースのドライバー割り当て、Linuxではudev、どのOSでもツールのバージョンです。

手順を踏んでも見つからない場合

その段階では、知りたいことが「なぜパソコンから見えないのか」から「端末はどういう状態なのか」に変わります。この2つは別の問題です。

4段階目で得た結果を、ソフトブリックとハードブリックの違いと照らして読んでください。不明なものとして認識される端末と、まったく認識されない端末は状況が大きく異なり、その違いによって、できることも費用も変わります。

端末が原因と結論づける前に、もうひとつ試してください。2台目のパソコン、できれば別のOSで試すことです。1回のテストで、パソコン側の問題をまとめて除外できます。最初のパソコンでトラブルシューティングを続けるよりも早く済みます。

よくある質問

なぜadb devicesは動くのにfastboot devicesは何も表示しないのですか？パソコンから見ると、別々のUSB機器だからです。Androidが動作している状態とブートローダーモードの状態では識別が異なり、別のドライバーが割り当てられることがあります。ADBが動くことで確認できるのはケーブルとポートだけです。

fastbootにはUSBデバッグを有効にする必要がありますか？いいえ。USBデバッグはAndroid内のADBの設定です。fastbootはOSより下のブートローダーで動作し、USBデバッグには依存しません。端末が起動しない場合はこの点が重要です。設定画面まで到達できないスマホでは、あとからUSBデバッグを有効にできないためです。

fastboot devicesに端末は表示されるのに、コマンドが失敗します。これは別の問題です。検出は成功しています。原因は、ブートローダーがロックされている、現在のモードでアクセスできないパーティションがある、ブートローダーのfastbootではなくfastbootdが必要なコマンドである、のいずれかと考えられます。エラーの全文を読んでください。通常、理由が書かれています。

USB-CからUSB-Cのケーブルでも使えますか？データ通信に対応していれば、基本的に使えます。コネクターの形状は関係ありません。重要なのは、ケーブルにデータ用の導線があるか、両端のポートがその接続に対応しているかです。

スマホは充電しておく必要がありますか？作業の間、電源が落ちない程度の充電が必要です。残量が非常に少ないと途中で接続が切れることがあり、書き込みが中断されるのは、書き込まないよりも悪い結果になります。始める前に充電してください。

リモートで直せますか？パソコン側のレイヤーは、通常リモートで対応できます。ドライバー、ツール、権限の作業はすべてパソコン上で行うためです。リモートセッションでの対応は日常的に行っており、作業内容と、こちらから見えるもの・見えないものはこちらで説明しています。どのパソコンでも、どのケーブルでも端末自体が認識されない場合は、パソコン側の問題ではないため、リモート作業では解決しません。

---

関連記事：ソフトブリックとハードブリック · データを失わずに起動ループを直す · Magiskの書き込み失敗 · Androidがリカバリーで起動し続けるとき · 起動画面の症状ごとの意味

出典：Android Open Source Project、ユーザー空間fastbootのドキュメント。Android SDK Platform Tools、公式リリース。

最終確認日：2026年8月28日。USBの動作、ドライバーの要件、利用できるモードは、メーカー、機種、ホストOSによって異なります。お使いの端末の公式ドキュメントでご確認ください。