Magiskの書き込みに失敗？ 初期化する前にブートイメージを診断する

Magiskをフラッシュしたあとに端末が起動しない場合、必要なのはリセットではなく診断です。原因として多いのは6つで、見られた症状から1つか2つに絞れることがほとんどです。いずれもデータの消去では解決しません。データを消すなど取り返しのつかない操作を考える前に、下の切り分け表を順に確認してください。

考えられる6つの原因

これらは確定した原因ではなく候補です。複数が同時に当てはまることもあり、どれが原因かは端末、ファームウェアのビルド、フラッシュした内容によって変わります。

1. 別のビルドのブートイメージ。 端末にインストールされているファームウェアと一致しないものから取り出したイメージです。セキュリティパッチレベルが1つ違うだけでも該当します。
2. パッチを当てるパーティションの間違い。 ramdiskがbootにある端末とinit_bootにある端末があります。間違った方にパッチを当てると、端末は起動しなくなります。
3. 検証付きブートまたはvbmetaの要件を満たしていない。 端末の検証チェーンが改変されたイメージを拒否したか、vbmetaの状態がフラッシュした内容と合っていません。
4. ブートローダーがロックされている、または再ロックされた。 ロックされたブートローダーは改変されたブートイメージを読み込まず、その状態でフラッシュすると別のエラーが出ます。
5. スロットの間違い。 A/B端末で、イメージが非アクティブスロットに書き込まれたか、操作の途中でアクティブスロットが切り替わっています。
6. モジュールまたは起動後の競合。 パッチは成功して端末も起動しましたが、起動後に動いている何かが原因で落ちています。

この一覧に入っていないものにも注目してください。それはユーザーデータです。6つの原因はどれもdataパーティションが発端ではなく、データを消去しても解決しません。

原因の切り分け表

実際に見られた症状に合う行を探してください。

この表は、番号付きの対処リストにはできない役割を果たします。間違った原因に1時間を費やす前に、症状から候補を絞り込めます。

ビルドの完全一致

最も時間をかけるべき原因です。合っているつもりで間違えやすいためです。

パッチ済みのブートイメージは、特定のファームウェアビルドから作られます。正しい入手元は、機種番号とビルド番号(セキュリティパッチレベルを含む)が完全に一致するファームウェアです。地域が違う同じ機種のものや、1か月前の同じバージョン番号のものは使えません。端末に現在インストールされているビルドそのものが必要です。

間違えやすい点：

• 機種のバリエーション。 同じ製品名でも、ファームウェアが異なる複数のハードウェアが存在することがよくあります。同じ機種のSnapdragon版とExynos版は、この作業では別の端末です。キャリア版もまた別です。
• 地域。 同じ機種でも地域ごとにファームウェアが異なり、イメージに互換性はありません。
• ビルドのずれ。 ファームウェアをダウンロードした前後に、端末がアップデートされた場合です。重要なのは端末上のビルド番号です。
• 再パッケージされた配布ファイル。 ファイル共有サイトのイメージは中身が不明です。メーカー公式の配布物を使い、チェックサムが公開されていれば確認してください。

何かをダウンロードする前に、「設定」の「端末情報」でインストール済みのビルドを確認してください。端末が起動しない場合は、ブートローダーやダウンロードモードの画面にビルド番号が表示されていることがあります。写真を撮っておきましょう。

root化できる端末の一覧では、どの機種のどのバリエーションでroot化の手順が確立しているか、バリエーションの落とし穴がどこにあるかをまとめています。

boot.imgとinit_boot.imgは互換性がありません

これは、以前にroot化に成功した人も引っかかります。Androidの歴史の途中でルールが変わったためです。

Android Open Source Projectのドキュメントは、この変更を直接説明しています。Android 13で発売された端末には、汎用ramdiskを含む新しいinit_bootイメージがあります。一方、Android 12から13にアップグレードした端末は、Android 12のときと同じ構成のままです。

実際のルールは次のとおりです。

落とし穴は、今Android 14で動いている端末でも、発売時の状態によってどちらの行にもなり得ることです。現在のAndroidバージョンからは、どちらに当たるか分かりません。重要なのは、端末が発売されたときのバージョンです。

Magiskの公式インストール手順には、お使いの端末がどちらに当たるかを調べる方法と、一部のハードウェアには例外があることが書かれています。箱に書かれたAndroidのバージョンから決めつけず、お使いの機種について確認してください。

これを間違えると、フラッシュは問題なく終わったように見えて、端末は起動しません。切り分けの上位に置いている理由はそこにあります。

vbmetaの扱い

Android Verified Bootは、ブートローダーがこれから読み込むものの完全性を検証します。改変されたブートイメージは想定されるハッシュと一致せず、そのときの端末の挙動はメーカーの実装によって異なります。

改変したイメージを起動するために検証状態の変更が必要な端末もあれば、不要な端末もあります。端末によっては、その状態を変更すると、セキュリティ対策として次回起動時にデータが消去されます。こうした挙動は端末ごとに異なり、メーカー間はもちろん、同じメーカーの機種間でも一貫していません。

この記事でvbmetaのコマンドを示さないのはそのためです。不要な端末で誤った検証フラグを付けて実行するとデータを失うおそれがあり、必要な端末で実行しないと、今まさに直そうとしている起動ループになります。操作する前に、メーカーのドキュメントや機種別の情報源で、お使いの機種の要件を確認してください。

データ消去の警告：端末によっては、検証を無効にしてvbmetaをフラッシュすると、次回起動時にユーザーデータがすべて消去されます。元に戻せません。実行する前に、お使いの端末の挙動を確認してください。

起動できる状態に戻す

端末がfastbootに入り、インストール済みビルドに合う元のブートイメージがあれば、それを書き戻すことで変更を元に戻せます。この操作が書き込むのはbootパーティションだけで、ユーザーデータには触れません。

必要な条件を順に挙げます。

1. 端末がfastbootに入り、パソコンが認識できる。認識できない場合はこちらから。
2. メーカー公式の配布物から入手した、インストール済みビルドに完全に一致する、パッチ前の元のイメージがある。
3. 上の表に従って、どのパーティションに書き込むかが分かっている。
4. A/B端末の場合、どちらのスロットがアクティブか分かっている。

どれか1つでも欠けていたら、自己流で進めず、足りないものを揃えてください。ほぼ合っているイメージをほぼ合っているパーティションに書き込むと、復旧できた状態が悪化します。

モジュールが原因の場合

root化は成功して通常どおり動いていたのに、モジュールを入れてからループし始めた場合、診断は単純で、ブートイメージには関係のない方法で直せます。

root化の仕組みには、モジュールを無効にして起動し、問題のモジュールを削除する方法が用意されています。Magiskのドキュメントには、起動中に特定のキー操作をすると、モジュールを無効にしてシステムが起動する方法が書かれています。KernelSUにも独自の復旧手順があり、リカバリーのシェルからコマンドラインツールを実行して、モジュールの一覧表示、無効化、アンインストールができます。

どちらもモジュールのディレクトリが対象で、ユーザーデータには触れません。この挙動はバージョンによって変わってきたため、古いフォーラムの手順は今は存在しない仕組みを説明している場合があります。実際に導入しているroot化の方法の最新のドキュメントを使ってください。

起動の早い段階でフックするモジュール、システムコンポーネントを置き換えるモジュール、端末のプロパティを変更するモジュールは、そうでないモジュールよりリスクが高くなります。Magiskモジュールのガイドでは、起動トラブルが報告されているカテゴリと、導入前に確認すべき点を説明しています。

すべての失敗が復旧できるわけではありません

この記事の他の部分は前向きな内容なので、限界についてははっきり書いておきます。限界は実際にあります。

• 改変したブートイメージをフラッシュ済みの状態でブートローダーをロックすると、端末は何も読み込まなくなり、新しいフラッシュも受け付けないことがあります。この状態は、メーカー専用のツールがないと解決が難しいか、不可能な場合があります。
• パーティションへの書き込みが途中で中断された場合、結果はどのパーティションで、どこまで進んだかによって変わります。
• 端末がfastbootに入らず、どのモードでも認識されない場合は、この記事の対象外です。状態を判断するには、ソフトブリックとハードブリックをお読みください。
• お使いのビルドの元のファームウェアがメーカーから配布されなくなっている場合、完全に同じイメージには戻せないことがあり、代わりの方法は多くの場合データの消去を伴います。

Magiskのフラッシュ失敗がすべて復旧できるとは言いません。復旧できないものもあり、費用をかけて確かめる前に、どちらかを正直にお伝えします。

よくある質問

純正のブートイメージをフラッシュすると、データは消えますか？ bootパーティションへのフラッシュは、ユーザーデータのパーティションには触れません。データが消えるのは、リセット、フォーマット、消去フラグ、または検証状態の変更で消去が強制される端末での変更です。安心できる言葉ではなく、操作の中身で判断してください。

パッチ済みのイメージをもう一度フラッシュして試してもいいですか？ 同じイメージをフラッシュすれば、同じ結果になります。イメージが原因なら、繰り返しても解決しません。切り分け表に基づいて具体的に何かを変えてから、再試行してください。

端末は起動するのに、Magiskに「未インストール」と表示されます。 多くの場合、非アクティブスロットにフラッシュしたか、端末がもう一方のスロットから起動しています。アクティブスロットを確認してください。間違ったパーティションにパッチを当てた可能性もあります。その場合は、bootとinit_bootの項目を参照してください。

TWRPやカスタムリカバリは必要ですか？ ブートイメージの復元はfastbootの操作なので、必要ありません。カスタムリカバリはモジュールの削除に役立つ場面がありますが、最近のパーティション構成では互換性の問題が出ます。どこで使えてどこで使えないかは、TWRPのインストールガイドで説明しています。

Magisk特有の問題ですか？ いいえ。ビルドの不一致、パーティションの取り違え、検証の要件、スロットの不一致は、どのブートイメージの改変にも当てはまります。KernelSUやAPatchでも同じ種類の失敗が起き、診断の考え方も同じです。選ぶ前に、3つの方法の違いを理解しておくと役立ちます。

とりあえず初期化してやり直すべきですか？ 最初の手段としてはおすすめしません。6つの原因はどれもdataパーティションが発端ではないため、初期化では解決しにくいからです。初期化は元に戻せず、ファイルベース暗号化を使う端末では、データとともに鍵も失われます。まず切り分け表を順に確認してください。

---

関連記事： データを消さずに起動ループを直す · 起動画面の症状ごとの意味 · ソフトブリックとハードブリック · fastbootで端末が認識されない · 必須のMagiskモジュール

出典： Android Open Source Project、汎用bootパーティションのドキュメント。Magisk公式のインストールドキュメント。KernelSU公式の復旧ドキュメント。

最終確認日：2026年8月24日。パーティション構成、検証付きブートの要件、フラッシュ手順は、メーカー、機種、ビルドによって異なります。コマンドを実行する前に、お使いの端末の公式ドキュメントで確認してください。