Android試験端末 ブートローダーアンロックと、Root化の作法 2025

はじめに
前回の機種選定を経て、手元には試験用端末が用意されました。
https://zenn.dev/ayamoke/articles/cf9290fda0639e
今回は、試験端末構築の最初のステップである 「ブートローダーアンロック(BLU)」 から 「Root権限の奪取(Magisk導入)」 までを解説します。
かつての手法(TWRP導入など)とは異なり、Android 13以降、特にGKI(Generic Kernel Image)やA/Bパーティションが標準化した現在、Root化の作法は大きく変化しています。
また、Root化の手法にはKernelSUやAPatchといった新しい選択肢も登場していますが、本記事ではモジュールによる拡張エコシステムが成熟しており、検知回避のナレッジも豊富な「Magisk」を採用します。
今回私が実施した中で、メーカーごとのBLU要件の違いと、比較的新しい環境特有の技術的な注意点(ハマりどころ)を中心に整理します。
0. 現代AndroidにおけるRoot化の共通フロー
個別の機種ごとの解説に入る前に、現在のAndroid(Android 15/16世代)におけるRoot化の全体像を整理しておきます。
機種が違っても、大まかな流れは以下の4ステップに集約されます。
-
ブートローダーアンロック (BLU)
- メーカーの鍵を開ける工程。ここが最もメーカーごとの差異(難易度)が出ます。
- ※これを行うと端末は強制初期化されます。
-
純正イメージの抽出
- その端末で現在動いているOSの「起動パーティション(
boot.imgまたはinit_boot.img)」を取り出します。 - Payload Dumper などのツールを使うのが正攻法です。
- その端末で現在動いているOSの「起動パーティション(
-
Magiskパッチの適用
- 抽出したファイルをAndroid端末に転送し、Magiskアプリを使ってパッチ処理(Root権限管理機能の埋め込み)を行います。
-
焼く (Flash)
- パッチ済みのファイルをPCから
fastbootコマンドで書き込み、再起動します。
- パッチ済みのファイルをPCから
この流れを頭に入れた上で、まずは作業環境の準備における「意外な落とし穴」から見ていきましょう。
1. 実は最大の難関? PCとの接続環境(ドライバとケーブル)
具体的な手順の前に、意外と時間を溶かすのが 「PCとスマホの接続」 です。
「USBで繋げば認識するでしょ?」と思っていると痛い目を見ます。
Google USB Driver とデバイスマネージャー
特にWindows環境では、適切なドライバが当たっていないと adb は通っても fastboot コマンドでデバイスが見えなくなることが多々あります。
Google公式の Google USB Driver をインストールし、デバイスマネージャーで「Android ADB Interface」等が正しく認識されているか、何度も確認させられました。
「古いケーブル」の方が安定する説
今回、最新のUSB-Cケーブルでは認識が不安定で、データ転送が途切れる現象に遭遇しました。
解決策は、手元にあった「無印良品のアロマディフューザーに付いていた、USB-A to USB-Cケーブル」を使うことでした。
USB 3.x系のポートやケーブルよりも、枯れたUSB 2.0環境の方がFastbootモードでの安定性が高いというのは、この界隈ではよくある話です。認識しない時は、ケーブルやポートを変えてみることを強く推奨します。

2. メーカー別ブートローダーアンロック(BLU)を試す
前回で選定した3機種(Pixel, Motorola, Xiaomi)について、実際に解除に要した手間とハマりポイントを比較します。
なお、具体的なコマンドやツール(バージョン等)は、機種やOSのビルド番号によって細かく異なります。
本記事のコマンドを鵜呑みにせず、必ずお手元の端末に合わせた最新の手順を調べてから実行してください。
推奨される一次情報源:
- XDA Forums: 世界最大のAndroid開発者コミュニティ。「(機種名) Guides」カテゴリが最も詳しいです。
- LineageOS Wiki: カスタムROMのWikiですが、機種ごとの「Installation」ページにあるBLU手順は非常に正確で参考になります。
- メーカー公式サイト: PixelやMotorolaは公式ドキュメントが正解です。
ケース1:Google Pixel 7a(標準的かつ迅速)
最もスムーズです。「OEMロック解除」を有効化し、Fastbootコマンドを叩くだけで完了します。
- 開発者オプション: 「OEMロック解除」と「USBデバッグ」を有効化。
-
Fastbootモード:
adb reboot bootloader -
コマンド:
fastboot flashing unlock -
端末操作: 音量キーで「Unlock the bootloader」を選択し電源ボタンで決定。
- 所要時間: 約5分(データは強制消去されるため、セットアップ直後に実施するのが鉄則です)

ケース2:Motorola Edge 50 Pro(正規の手続き)
メーカー公式サイトを経由する必要がありますが、手順は明確であり、エンジニアにとって納得感のあるフローです。
-
データ取得:
fastboot oem get_unlock_dataでデバイス固有の文字列を取得。 -
申請: Motorola公式サイトで文字列を入力し、「Unlock Key」をメールで受信。
- ※Webでの申請後、数分もしないうちにコードが届きました。自動化されているようで非常にスムーズです。
-
解除:
fastboot oem unlock [UNIQUE_KEY]を実行。- 所感: 独自の怪しいツールなどを要求されず、標準コマンドで完結するため、心理的なストレスが少ないです。
ケース3:POCO X7 Pro / Xiaomi HyperOS(最大の障壁)
ここが最大のハマりどころです。
Xiaomi(HyperOS搭載機)の場合、セキュリティ要件が厳格化されており、即時の解除は不可能です。
- アカウントの制約: Miアカウント作成直後は申請ができず、「作成から30日間」のアクティブ期間が必要です。
- 申請フロー: 「Xiaomi Community」アプリからの申請が必要ですが、1日の受付数に上限があります。
- 深夜1時の申請バトル: 受付リセットは中国時間の0時、つまり日本時間の深夜1時です。私はコツを掴んで申請を通すまでに数日かかりました。
- 待機時間: 申請が受理された後、解除ツール(Mi Unlock Tool)上でさらに 72時間(3日間)〜168時間(1週間) の待機時間を課される場合があります。

3. 現代Root化の技術的要点(ハマりどころ)
BLUが完了した後、Magiskを導入してRoot化を行いますが、ここで古い知識のままだと躓くポイントが2つあります。
ポイント①:A/Bパーティション(Seamless Updates)
現在のAndroid端末の多くは、システム領域を二重化した「A/Bパーティション」を採用しています。
fastboot flash コマンドを実行する際、現在のActive Slot(稼働中のスロット)に対して書き込む必要があります。基本的には自動判別されますが、手動指定が必要な場合は fastboot getvar current-slot での確認が必須です。
ポイント②:boot.img ではなく init_boot.img
これがAndroid 13以降(GKI導入機種)の最大の変更点であり、私が実際にやらかした失敗ポイントです。
-
以前: カーネルとRamdisk(Magiskが常駐する場所)は共に
boot.imgに含まれていました。 -
現在: Pixel 7以降や最新のXiaomi端末などでは、Ramdiskが
init_boot.imgという独立したパーティションに移動しています。 -
失敗談: 私は何も考えずに
boot.imgにパッチを当てて書き込んでしまい、起動しなくなって焦りました。幸い、純正のイメージファイルを手元に残していたため、すぐに正規のboot.imgを焼き直して復旧できましたが、もしバックアップがなければ冷や汗ものでした。-
対策: 対象機種のファクトリーイメージを確認し、
init_boot.imgが存在する場合は、そちらをパッチ対象とする必要があります。
-
対策: 対象機種のファクトリーイメージを確認し、
4. 実践:イメージ抽出と「Payload Dumper」の正攻法
パッチを当てるための元ファイル(init_boot.img等)を入手する工程です。
実録:私の失敗と反省
今回、私は手っ取り早く済ませるために、ネット上のフォーラムやアップローダーサイトから、有志が抽出したイメージファイル単体を拾ってきて作業しました。
しかし、これは「マルウェア混入」や「バージョン不一致による文鎮化」のリスクがあるバッドノウハウです。
個人の趣味ならまだしも、業務用の試験端末であれば避けるべきです。
正攻法:Payload Dumperの利用
本来であれば、以下の手順が最も安全で確実です。
- 公式ROMの入手: メーカー公式サイトや信頼できる配信元から、自分の端末と同じバージョンの「リカバリROM(zipファイル)」をダウンロードします。
-
Payload Dumperの使用:
- 最近のROMは中身が
payload.binという一つのファイルに固められています。 - Pythonツールの 「Payload Dumper」 を使用することで、この中から
init_boot.imgだけをきれいに抽出できます。
- 最近のROMは中身が
# Payload Dumperの使用イメージ
python payload_dumper.py payload.bin
# -> outputフォルダに init_boot.img が生成される
Pixel以外の端末(XiaomiやMotorolaなど)では、この手順を踏むのがエンジニアとしての正解です。
5. パッチ適用とFlash
正しいファイルを入手したら、あとはMagiskの標準手順です。
-
パッチ作成:
- 抽出した
.imgファイルを端末に転送。 - Magiskアプリの「インストール」→「パッチするファイルの選択」でファイルを選択。
- 生成された
magisk_patched_[random].imgをPCに引き上げる。
- 抽出した
-
書き込み (Flash):
- PC側から
fastbootコマンドで書き込みます。
- PC側から
# 現在のスロットを確認(念のため)
fastboot getvar current-slot
# init_boot パーティションへの書き込み
# ※機種によっては boot の場合もあるので事前確認必須
fastboot flash init_boot magisk_patched.img
# 再起動
fastboot reboot
-
確認:
- 再起動後、Magiskアプリを開き、「インストール済み」のバージョンが表示されていれば成功です。
- PCから adb shell に入り、su コマンドを実行して
#プロンプトが返ってくることを確認します。

まとめ
今回は、試験端末構築の最難関である「ブートローダーアンロック」と、GKI/init_boot環境における「Magisk導入」のハマりどころを解説しました。
今回のポイント:
- PC接続環境を見直す: ドライバとケーブル(USB 2.0推奨)は最初に疑うべき箇所。
- Xiaomiは計画的に: 解除まで「30日+α」の期間を見込んでおく。
-
init_bootを疑う: Android 13以降の端末では、パッチ対象がboot.imgではない可能性が高い。 -
正規の手順で抽出する:
Payload Dumperを使い、公式ROMから正しいイメージを抜くのが鉄則。
これでRoot化は完了ですが、セキュリティ診断やデバッグを行うには、まだ準備が整っていない状態です。次回は、診断の基本である「通信の可視化」について解説します。
Android 16時代における証明書の扱いや、私が日本語ローカライズに参加している OWASP ZAP を使った解析手法など、より実戦的な内容に入っていきます。
Discussion