Magisk・KernelSU・APatch比較 — 2026年のroot環境選び
Magisk、KernelSU、APatchの仕組みと選び方を比較。Zygisk、モジュール、カーネル要件、アプリ互換性、OTA、移行と純正バックアップを解説します。
目次
- TL;DR — which one should you actually choose?
- Feature comparison at a glance
- Magisk — still the default choice
- 最初の候補
- 初めてroot化し、対応情報を重視
- 対応機種のMagisk
- 対応カーネルがあり、カーネル側の権限制御が必要
- Strengths
- KernelSUまたは適合するフォーク
- APatchの対応条件に合い、カーネルパッチの方式が目的に合う
- APatch
- Strengths
- Weaknesses
- 広いモジュール情報とトラブル事例が必要
- Magisk
- How to choose between them — a 30-second decision tree
- 特定のSUSFS・KPM構成を使いたい
- その機能に対応するカーネル・フォークを先に確認
- 広告ブロックや簡単な自動化だけ
- rootなしの方法で足りるかを確認
最初に決めるのは「最強のツール」ではなく、必要な機能
Magisk、KernelSU、APatchは、いずれもAndroidで高い権限を扱うための仕組みですが、導入方法、権限を制御する層、モジュール、カーネルの条件が異なります。
どれがよいかは、端末、ビルド、カーネル、必要なモジュール、更新方法、復旧の知識によって変わります。銀行アプリのスクリーンショットや一時的な人気だけで選ばないでください。
迷ったときの選び方
| 条件 | 最初の候補 |
|---|---|
| 初めてroot化し、対応情報を重視 | 対応機種のMagisk |
| 対応カーネルがあり、カーネル側の権限制御が必要 | KernelSUまたは適合するフォーク |
| APatchの対応条件に合い、カーネルパッチの方式が目的に合う | APatch |
| 広いモジュール情報とトラブル事例が必要 | Magisk |
| 特定のSUSFS・KPM構成を使いたい | その機能に対応するカーネル・フォークを先に確認 |
| 広告ブロックや簡単な自動化だけ | rootなしの方法で足りるかを確認 |
基本比較
| 項目 | Magisk | KernelSU系 | APatch |
|---|---|---|---|
| 基本方式 | 起動経路のパッチとシステムレス構成 | カーネル側の権限管理 | 起動イメージ内のカーネルをパッチ |
| カーネル条件 | 多くの端末で機種別のboot/init_boot等を使用 | GKI、LKM、組み込みなど対応モードが重要 | 対応アーキテクチャとカーネル条件が必要 |
| Zygisk | 内蔵。別実装を選ぶ構成もある | 必要なら対応する別実装 | 必要なら対応する別実装 |
| モジュール情報 | 広く蓄積されている | 拡大中だが仕様を確認 | APModule/KPModuleなど仕様を確認 |
| 初心者向け情報 | 比較的多い | カーネル知識が必要になりやすい | より技術的な判断が必要 |
| アプリ互換性 | アプリと構成次第 | 同左 | 同左 |
| 復旧の準備 | 純正イメージが重要 | 元のカーネル/起動イメージが重要 | 純正起動イメージが重要 |
3つとも、通常の導入では変更した起動構成を端末が受け入れられることが必要です。ブートローダーがメーカーによって閉じられている問題を、管理アプリの交換だけで解決できるわけではありません。
Magisk:情報量と対応例を重視する選択
Magiskは、system領域を直接大量に変更する古いroot手法と異なり、起動経路を修正してシステムレスな変更を行う構成で普及しました。
多くのFastboot端末では、純正のbootまたはinit_bootを取り出し、Magiskでパッチして戻します。SamsungはAPパッケージとOdinを使うなど、機種固有の流れがあります。
強み
モジュール、トラブルシューティング、機種別手順の情報が多くあります。Zygiskを内蔵しているため、その機能が必要な基本構成を組みやすい点も利点です。
問題が起きたときに、似た端末・ビルドの事例を探しやすいことは、特に初めての利用で重要です。
注意点
導入がしやすいからといって、多数のモジュールを入れてよいわけではありません。UI、hosts、フック、整合性、性能調整を重ねると、競合と検証項目が増えます。
ユーザー空間で扱う構成には、その層に由来する検出や競合もあります。新しいAndroidやアプリの検査が変われば、以前の構成が動かなくなる可能性があります。
KernelSU:カーネル側で権限を扱う
KernelSUは、rootの権限管理をLinuxカーネル側で行う考え方です。対応するGKI、LKM、カーネルへの組み込みなど、導入モードと端末条件を確認します。
強み
アプリ別の権限管理や、対応カーネルと組み合わせる機能が目的に合う場合があります。普段からカスタムカーネルを扱う利用者にとっては、環境をカーネル側へまとめることが利点になる場合があります。
注意点
最大の条件は端末に合うカーネルがあるかです。同じAndroidのバージョンでも、カーネル構成やvendorの違いで導入できない場合があります。
カーネル自体が起動しないと、通常のアプリ操作で直せません。元のboot/カーネルイメージ、Fastbootやメーカー復旧の手順を準備します。
KernelSU Next・SukiSU Ultraなどのフォーク
フォークは、名前だけが違う同一製品ではありません。対応カーネル、マネージャー、LKM、KPM、SUSFSなどの機能や導入条件が異なります。
「KernelSU対応」と書かれたモジュールでも、特定のフォークや版を要求していないか確認してください。カーネルと管理アプリを別の系統へ勝手に入れ替えないことが重要です。
APatch:別のカーネルパッチ方式
APatchは、純正の起動イメージ内のカーネルをパッチする方式を使います。KernelSUの対応カーネルをそのまま必要とする方式とは異なりますが、無条件にすべての端末で使えるわけではありません。
強み
KernelSUの既存ビルドが合わない場合でも、APatchの条件に合う端末であれば別の選択肢になる可能性があります。APModuleやKPModuleなど、機能を追加する仕組みもあります。
注意点
アーキテクチャ、カーネル、イメージの構成などの対応条件を確認します。Magiskに比べて同じ端末の情報が少ない場合は、問題の切り分けにより深い知識が必要になります。
パッチできたという表示だけで、実機の起動と機能が保証されたわけではありません。純正復旧の準備を省略しないでください。
Zygiskの扱い
MagiskにはZygiskが内蔵されています。KernelSUやAPatchでZygiskモジュールを使う場合は、Zygisk Next、ReZygisk、NeoZygiskなどの対応する別実装を検討します。
実装は1つに絞ります。 内蔵と別実装を二重に動かしたり、異なる実装のファイルを残したまま切り替えたりすると、起動不良や検出の原因になります。
利用するモジュールと、Zygisk実装の版の組み合わせも確認します。ある実装で動くモジュールが、別実装で同じように動くとは限りません。
モジュールの数だけで比較しない
Magiskは幅広い情報がある一方、古い一覧には保守終了したツールも残ります。KernelSUやAPatchでは通常のシステムレスモジュールが動く場合がありますが、すべてをそのまま流用できるわけではありません。
| モジュールの種類 | 確認すること |
|---|---|
| hosts、ファイル配置など | 管理ツールのモジュール仕様と重複 |
| Zygisk系 | Zygisk実装と対象Android |
| UI変更 | メーカーROM、SystemUI、ビルド |
| カーネル機能 | 対応カーネル、KPM等の実装 |
| SUSFS関連 | パッチを組み込んだカーネルと対応フォーク |
Magiskモジュールの選び方で、アプリとモジュールの区別、配布元、削除手順を整理しています。
Play Integrity・銀行アプリに絶対の勝者はない
英語版の記録ではMagiskのコミュニティ情報の多さが利点として挙げられています。KernelSU系やAPatchでは、異なる層での動作が特徴になります。
ただし、どの方式もすべての銀行、Wallet、DRM、ゲームを永久に使える保証にはなりません。Googleやアプリ側のサーバー設定、端末のハードウェア認証、アプリの版が変わります。
一つの整合性テストのスクリーンショットでroot管理ツールを選ばず、実際に必要なアプリと、純正状態を失うリスクを比較してください。重要な決済は、メーカーとアプリが対応する未変更の端末へ分ける判断もあります。
KernelSUはMagiskより安全か
カーネル側で権限を管理する構成には、設計上の利点があります。しかし、深い権限を持つこと自体が、安全性を保証するわけではありません。
安全性に関わるのは、カーネルの提供元、追加パッチ、モジュール、rootを許可するアプリ、ソース公開、更新状況、ブートローダーの状態などです。
公式Magiskに必要最小限のモジュールを入れた端末と、出所不明のカーネルに多数の変更を加えた端末を比べれば、ツール名だけで後者が安全とは判断できません。
ゲーム性能と電池持ち
root管理ツールを変えただけで、大きくFPSが上がるとは考えないでください。カーネル、ガバナー、温度、背景処理、モジュールの設定の影響が大きいからです。
電池の差も、root方式だけでなく、Zygisk実装、常駐モジュール、wakelock、カーネルの動作を調べます。変更前後を同じ条件で測定してください。
OTAと更新
Magisk、KernelSU、APatchで更新の手順は異なります。さらに同じ管理ツールでも、A/B、LKM、組み込みカーネル、SamsungのAPなど、端末によって違います。
どの方式でも、現在の純正イメージを保存し、次のビルドへ更新するときは次のビルドのファイルを使用します。古いpatched imageを、新しいOSへそのまま書き込まないでください。
端末別の見方
Pixel: 解除可能な版ならMagiskの情報を確認しやすい候補です。KernelSU・APatchも、カーネルとビルドの条件を調べて検討します。
OnePlus: カスタムカーネルが豊富な世代でも、Global・中国・通信会社版と現在の保守を確認します。
Xiaomi・POCO: root方式以前に、メーカー側の解除承認が大きな条件です。
Samsung: まずOne UI、ブートローダー、Knoxを確認します。root管理ツールを交換しても、メーカーの解除制限は自動的に解決しません。
Motorola: 公式対象判定を通るRetail版ではMagiskを検討しやすく、別の方式は対応カーネルを確認してから選びます。
Vivo・OPPO・Realmeなど: 対象端末のブートローダーが解除できなければ、通常のroot管理ツール比較だけでは作業を進められません。
切り替えるときの基本手順
- 現在のroot方式と、変更したパーティション・イメージを確認します。
- 同じ純正ビルドの復旧ファイルを端末外へ保存します。
- 現在の管理ツールの公式削除・復元手順を使います。
- 純正の起動イメージやカーネルへ戻し、正常起動を確認します。
- 新しい方式を、その端末の手順で導入します。
- 互換性が確認できるモジュールだけを再導入します。
ROM全体の再インストールが不要な場合もありますが、古いroot方式の変更を残したまま重ねる「上書き移行」は避けます。原因を追えない混在状態になりやすいためです。
失敗を減らすための記録
純正boot/init_boot/カーネル、ビルド番号、現在のスロット、管理ツールの版、Zygisk実装、モジュール一覧、重要なアプリを記録します。
root化直後に大量のモジュールを導入しない、別端末のファイルを使わない、変更済みのまま再ロックしない、OTAを計画なしで適用しない、という基本が重要です。
相談する場合
「どれが最強か」ではなく、端末の型番、ビルド、現在のカーネル、必要な機能、使いたいモジュール、重要なアプリをお知らせください。その条件で、無理のない構成を検討します。
よくある質問
2026年はどのroot方式が一番よいですか?
初めてで情報量を重視するなら、対応端末のMagiskが候補になります。KernelSUは対応カーネルがある場合、APatchはその方式と端末条件が合う場合に検討します。
Magiskなら銀行アプリが使えますか?
情報は多くありますが、継続的な互換性の保証ではありません。アプリ、端末、バージョンごとに判断します。
KernelSUのほうが安全ですか?
設計上の違いはありますが、提供元、カーネル、モジュール、許可するアプリを含めた構成全体で判断します。
ROM全体を書き直さずに移行できますか?
機種によっては可能ですが、元の方式が変えたイメージを正しく純正へ戻す必要があります。単にアプリを削除するだけでは足りない場合があります。
KernelSU非対応でもAPatchなら使えますか?
候補になる端末はありますが、必ず使えるとは限りません。APatch側のアーキテクチャ・カーネル・イメージ条件を確認します。
複数を同時に使えますか?
通常は1つに絞ります。別方式の修正を残して重ねないでください。
ゲーム向けにはどれがよいですか?
root管理ツールの名前より、カーネル、温度、ガバナー、ゲーム固有の設定が重要です。同じ条件で測定して判断します。
端末別の見方
Pixel:
OnePlus: カスタムカーネルが豊富な世代でも、Global・中国・通信会社版と現在の保守を確認します。
Xiaomi・POCO:
Samsung: まずOne UI、ブートローダー、Knoxを確認します。root管理ツールを交換しても、メーカーの解除制限は自動的に解決しません。
Motorola:
Vivo・OPPO・Realmeなど: 対象端末のブートローダーが解除できなければ、通常のroot管理ツール比較だけでは作業を進められません。
現在のroot方式と、変更したパーティション・イメージを確認します。
同じ純正ビルドの復旧ファイルを端末外へ保存します。
現在の管理ツールの公式削除・復元手順を使います。
純正の起動イメージやカーネルへ戻し、正常起動を確認します。