2026年のおすすめMagiskモジュール：検証済みの配布元と、終了したプロジェクト

現在も多くの一覧に載っているモジュールの中には、すでに存在しないものがあります。Play Integrity Fixは作者自身がGitHubから削除しました。Universal SafetyNet Fixの最終リリースは2023年1月です。そして、多くのガイドが説明する「Magiskアプリのオンラインリポジトリからインストールする」という手順は、Magiskから何年も前に削除された機能です。以下のプロジェクトはすべて、掲載前に各リポジトリ自身で状態を確認しており、すべてにリンクを付けています。

最終技術確認日：2026年10月30日
Magiskの基準バージョン：v31.1（2026年10月25日リリース）
対応範囲：KernelSU、KernelSU Next、SukiSU Ultra、APatch
Android対応範囲：12〜17。それ以降のバージョンは、各プロジェクトが明示的に対応を表明している場合のみ記載
2026年10月30日更新：Magisk 31.0および31.1（新しいアプリ、root許可のポップアップ廃止、アプリ隠蔽機能の削除）、各root管理ツールとZygisk実装の最新版、オープンソースのTricky Store代替、保守終了・放置状態になったモジュール
情報源の方針：開発者公式のリンクのみを使用します。モジュールのZIPを当サイトでミラー配布することはありません

はじめに：結論だけ早く知りたい方へ

多くの人が求めているのは、次の4つのうちどれかです。全リストを読む必要はありません。

以下はこの4つの詳細と、避けるべきものです。

何が変わったか、何を削除すべきか

古いガイドに従っている場合、すでに存在しないものをインストールしようとしている可能性があります。

最後の行が最も混乱を招きます。古いガイドが説明する「モジュールのダウンロードタブ」をMagiskアプリ内で探しても見つからず、インストールが壊れていると思い込む人がいますが、壊れていません。発見とインストールは別の手順に分かれました。GitHubでモジュールを見つけ、ZIPをダウンロードし、ストレージからインストールします。

よく「モジュール」として紹介されるが、実はモジュールではないもの

これは重要です。入手先と、不具合が起きたときの対処方法が変わるからです。

これらはいずれも有用ですが、フラッシュして入れるものではありません。AdAwayをZygiskモジュールの間に並べて紹介するガイドは分類を誤っており、それを信じて「AdAwayのZIP」を探したユーザーは、この記事が避けるよう勧めている類の配布サイトに行き着くことになります。

Magisk 31.0と31.1での変更点

Magisk 31.1は現行の安定版リリース（2026年10月25日）で、Magiskの日常的な挙動を変えました。このガイドの旧版を含め、多くの古いガイドは旧来の流れを説明しています。公式リリースノートに基づく内容は次のとおりです。

root要求のポップアップはもう表示されません。 スーパーユーザー権限は、Magiskアプリの「Superuser」タブからあらかじめアプリに付与する方式になりました。ターミナルアプリやバックアップツール、モジュールがrootを必要としているのに画面に何も表示されない場合は、先にSuperuserを開いて権限を付与してください。これは画面を表示できる前面アプリが存在しないadb shellでも同様です。Magiskチームは、旧来の対話型プロンプトはHSUM端末では動作しえないと説明しています。

Magiskアプリの隠蔽機能はなくなりました。 マネージャーをランダムなパッケージ名に変更する再パッケージ機能は削除され、アプリが見当たらなくなってもMagiskはもう自動で再インストールしません。開発者自身の見解は率直です。インストール済みのパッケージを本当に隠すことはAndroidではほぼ不可能なので、Superuserのポリシーとモジュールを設定し終えたら、Magiskアプリを隠す最も効果的な方法はアンインストールすることだ、としています。マネージャーを探すアプリへの対策としても、アプリ名に頼るよりDenyListと後述の隠蔽手順を活用する理由がもう一つ増えたことになります。

稼働中の端末をアップデートする前に、現在のバージョンを記録し、Superuserの一覧をスクリーンショットし、使っているビルドの純正ブートイメージを保存しておいてください。Android 6.0の端末は30.7のままにとどまります。

どのroot管理ツールを使っていますか？

Magiskはもはや唯一の選択肢ではなく、どれを使うかによってインストールできるものが決まります。モジュールはおおむね移植可能ですが、完全にではありません。

ここで多くの人が間違える点が2つあります。

2つを同時には使えません。 一方を完全に削除し、対応する純正イメージを復元してから、もう一方をインストールしてください。両方を同時に有効にすると競合します。

KernelSU系のフォークは互換ではありません。 KernelSU、KernelSU Next、SukiSU Ultraは考え方を共有していますが、マネージャーとカーネルの変更点は異なります。実際にインストールしたフォーク向けに作られたビルドを使ってください。

Magisk Alphaについて一言。これは主にTelegramで配布されている非公式ビルドです。支持者はいますが、公開ソースとリリース履歴は公式Magiskより弱く、root権限で動くものとしては重要な違いです。公式の安定版の方が検証しやすいといえます。例えばReZygiskは、v1.0.0でMagisk Alphaのサポートを打ち切りました。

何がどこで動くか

最も判断を左右する行はSUSFSです。これはユーザー空間ではなくカーネル内部で隠蔽を行うため、ユーザー空間のモジュールでは構造的に太刀打ちできません。そしてMagiskでは動作しません。Magiskはカーネルに一切手を加えないためです。これが2026年にMagiskから移行する主な技術的理由ですが、対応するカーネルを持つ端末が必要で、すべての端末が対応しているわけではありません。Magisk・KernelSU・APatchの比較でこのトレードオフを詳しく扱っています。

この記事に載っているものはすべてMagiskで動作します。特定の系統に限定される場合はその旨を明記します。

インストールする前に

現在のモジュール一覧をスクリーンショットしてください。 root管理ツールを開き、Modulesタブへ行き、一覧をスクリーンショットします。何かが壊れたときに、何が変わったかの記録になります。5秒で終わり、ターミナルも不要です。

そのついでにMagiskのバージョンと、Androidのビルドを記録してください。Magiskのバージョンはホーム画面に表示されます。Androidのバージョンとセキュリティパッチは「設定」の「端末情報」にあります。

1つずつ導入し、再起動して、動作確認をしてください。 5つを一気に入れて1回だけ再起動すると、どれが原因で壊れたのか分からなくなります。

必要になる前に復旧方法を知っておいてください。 この記事の最後に載っています。先に読んでおきましょう。

ステップ1：Zygisk実装を1つ選ぶ

Zygiskは、隠蔽系モジュールやXposedフレームワークが依存する注入レイヤーです。Magiskには1つ内蔵されています。KernelSUとAPatchには内蔵されていないため、単体の実装が必要です。Magiskユーザーも、内蔵の代わりに単体実装を選べます。

次の3つのルールを守るだけで、多くの不具合報告を未然に防げます。

必ず1つだけ動かしてください。 Magisk上で単体実装を導入する場合は、先に内蔵Zygiskをオフにしてください。両方を動かすことは、よくある避けられる失敗です。

ShamikoはReZygiskでは動作しません。 Shamikoは内蔵ZygiskとZygisk Nextを対象としています。ReZygiskを選ぶ場合は別の隠蔽モジュールが必要です。これらを混在させることが、「昨日まで隠蔽が効いていたのに今日は効かない」の典型的な原因です。Zygisk Assistantも同様です。

切り替える前に古い方をアンインストールしてください。 以前のモジュールを削除せずに移行すると、特にモジュールIDが変わった場合にブートループを引き起こしてきました。

Zygisk Nextのライセンス変更は、デフォルトのままにせず、意識して判断すべき点です。これはroot権限を持つモジュールでありながら、近年のリリースは独立した監査ができません。これがReZygiskが存在する理由として挙げられています。これが自分にとって重要かどうかは、技術的な欠陥の問題ではなく判断の問題です。

ステップ2：整合性と隠蔽を決定木として考える

この記事の旧版に対する最も重要な訂正は次の点です。

Play Integrityを通すことと、アプリからrootを隠すことは、別の問題です。

すべての整合性判定を通過していても、Google Walletや特定の銀行アプリが端末を拒否することは珍しくありません。個々のアプリがPlay Integrity API以外の情報も見ているためです。あるガイドが「必須」と書いていたからという理由でフルスタックを導入すると、2つで済むところに6個のモジュールを入れる結果になります。

決定木として進めてください。各ステップの後にテストします。

まずDenyListから。 Magiskに内蔵されており、ダウンロードは不要です。rootを隠したいアプリを追加します。多くのアプリはここで文句を言わなくなり、それで完了です。Magisk 31.0ではwebview_zygoteもDenyListのアンマウント対象に追加されました。

それでも検出される場合は、隠蔽モジュールを追加します。 ShamikoはLSPosedのリリース配布から入手できます。2025年6月時点のv1.2.5がAndroid 16と16Kページの修正を含んでおり、2026年10月30日時点でそれより新しいリリースはありません。直感に反する要件に注意してください。Shamikoは、DenyListのリストそのものは維持したまま、強制適用（enforcement）をオフにする必要があります。強制適用をオンのままにするとShamikoが無効になります。これはこの記事全体で最もよくある設定ミスです。SUSFSパッチ済みカーネルを使うKernelSUでは、カーネル自体がすでにその役割を果たしているため、Shamikoが不要な場合が多くあります。

整合性の判定で具体的に落ちる場合は、Play Integrityモジュールを追加します。 osm0sis/PlayIntegrityFork（2026年8月時点でv18）は、終了したオリジナルの直接の後継であり、作者自身が案内した後継プロジェクトです。KOWX712/PlayIntegrityFixも同系統の保守されているフォークで、2026年10月時点でv4.9です。PIF系のフォークを2つ同時に入れないでください。

具体的な鍵の証明（key attestation）要件がある場合に限り、Tricky Storeを検討します。 5ec1cff/TrickyStore、Android 10以降対応。beakthovenとqwq233によるフォークも流通しており、いくつかのツール群は現在こちらを対象にしています。

対象アプリを管理するには、KOWX712/Tricky-Addon-Update-Target-Listが、Tricky Storeの対象リスト、keybox、セキュリティパッチの扱いに対するまともなインターフェースを提供します。別プロジェクトであり、作者は本家へのissue報告を控えるよう求めています。

Tricky Storeのオープンソース版代替も登場しています。 beakthoven/TrickyStoreOSSはGPL-3.0で書き直された版（v3.1.0、2026年8月）です。JingMatrix/TEESimulatorは、keystoreデーモン内で動作するGPL-3.0のソフトウェアKeyMintです（v4.0、2026年8月、Android 10以降、64ビット端末のみ）。qwq233/OhMyKeymintは、純正AOSPに近い動作を目指すkeystoreの全面的な再実装です（Android 12以降、プレビュービルド）。これらは必ず1つだけ動かしてください。いずれも実際に使えるkeyboxを同梱しておらず、当サイトもkeyboxを紹介していません。

他のガイドが教えてくれない3つのこと

Tricky Storeはv1.1.0以降クローズドソースです。 保守担当者は悪用への懸念からソースを非公開にしました。Zygisk Nextのライセンス変更と合わせ、このカテゴリーで最も強力な2つのツールは、いずれもroot権限で動く監査不能なバイナリになりました。最終リリースは2025年11月の1.4.1です。導入後ではなく、導入前に知っておく価値のある事実です。オープンソースでの書き直し版は上で紹介したとおり存在しますが、まだ新しく実績も十分ではありません。

Tricky Storeは動作するkeyboxを同梱していません。 同梱されているのは証明に使えないAOSPのkeyboxです。「Tricky Storeを入れれば強い整合性が手に入る」というガイドは、この点をまるごと省いています。keyboxは失効することもあり、その時点で設定は何の前触れもなく動かなくなります。当サイトはkeyboxを配布しておらず、配布するところには注意が必要だと考えています。

ソフトウェアベースの端末整合性は2026年に大きく難しくなりました。 年の前半に大量の端末フィンガープリントがブロックされ、それを維持していた主要なコミュニティリポジトリは所有者自身によってアーカイブされ、最も一般的なアーキテクチャの組み合わせ向けには動作するフィンガープリントが残っていないと説明されました。フィンガープリント方式自体が機能しなくなったわけではありませんが、供給は以前ほどではありません。

率直に言うと、基本的な判定は概ね達成可能で、端末整合性は以前より手間がかかるようになり、ロック解除済みブートローダーでの強い整合性は本当に難しくなっています。それでも一部のアプリは状況に関係なく拒否します。当サイトは通過率を公表していません。数週間で陳腐化する数字になるからです。

1週間かけて組み合わせを試すより、一度で正しく設定したい方へ。 端末、Androidバージョン、root方式、動かしたいアプリを教えてください。リモートで設定し、どのアプリが現実的に通せるかを事前にお伝えします。root化サービスの無料診断

助けを求める前に

整合性まわりの挙動は常に変化するため、「このスタックで銀行アプリは動きますか」は詳細なしでは答えようがありません。誰かに（当サイトを含め）質問する際は、次の情報を添えてください。

端末と正確な型番：
Androidのバージョンとビルド：
セキュリティパッチレベル：
root管理ツールとバージョン：
Zygisk実装：
導入済みモジュールとバージョン：
Play Integrityの判定結果：
失敗しているアプリとバージョン：
正確に表示されている内容：

これにより、誰にも答えようのない質問が、誰かが答えられる質問に変わります。当サイトは旧版のガイドから匿名のアプリ互換性の体験談を削除しました。理由は同じで、こうした詳細がまったくなく、再現性がなかったためです。

ステップ3：Xposedレイヤー

オリジナルのLSPosedプロジェクトは2023年10月以降リリースがなく、2024年1月以降masterへのコミットもなく、そのリリースはAndroid 8.1〜14を対象としていました。現代の端末にとっては出発点を誤っています。

JingMatrix/LSPosedが、多くの人が使っている保守されているフォークで、現在はJingMatrix/Vectorリポジトリに移っています（旧URLはそちらへリダイレクトされます）。Vectorは内部を書き直しながらオリジナルのXposedとのAPI互換性を保っており、Android 16・17と16Kページ端末まで対応しています。そのリリースは現在タグ付けされた安定版ではなく、canaryのプレリリースビルド（2026年10月26日時点でcanary-3114）として公開されているため、更新前にリリースノートを確認してください。

JingMatrix/LSPatchはrootless（非root）向けの選択肢です（Vectorと同様にcanaryビルド）。対象アプリのAPKにパッチを当てることで、フレームワークをそのアプリ1つに組み込みます。rootもZygiskも不要です。1つのXposedモジュールの機能だけが欲しく、それ以外は何も必要ない場合に知っておく価値があります。

流通していたもう一つのフォークReLSPosedは、2026年2月に所有者によってアーカイブされました。フォークを信頼する前に、日付を確認してください。

Hide My Applist（Dr-TSNG/Hide-My-Applist）は、一部のアプリがroot管理ツールを見つけるために使うアプリ一覧のスキャンを遮ります。開発は一時停止していましたが、2026年8月にv3.8.3をリリースしています。随時保守される状態として扱い、頼る前にリリース日を確認してください。

Xposedモジュール自体にも同じ問題があります。2年間更新されていないものは、スレッドでの主張がどうであれ、Android 15や16で動く見込みは薄いです。

ステップ4：検証済みリスト

実際に求められそうな用途ごとにまとめています。すべてのリンクは開発者自身のリポジトリに向いています。特に注記がない限り、すべてMagiskで動作します。

広告・トラッカーのブロック

hostsブロッカーは必ず1つだけ動かしてください。 2つ、あるいは1つに加えてAdAwayのrootモードを使うと、同じファイルを2つの仕組みが取り合うことになります。強すぎるリストは正規のアプリ機能も壊すので、まず標準的なプロファイルから始め、具体的に困った場合のみ追加してください。

前提として、hostsブロックはドメインの名前解決を止めるだけです。コンテンツと同じドメインから配信される広告には効果がありません。AndroidのプライベートDNS設定なら、rootなしでほぼ同じことができます。

バッテリーと電源

ACCは、リポジトリへのリンクが一切ない「バッテリー管理」としか書かれていない曖昧な項目に対する、誠実な代替です。他の端末の充電スイッチをそのまま流用せず、ACC自身の検出機能を使ってください。

ゲームとスケジューリング

全体にではなく、ゲームごとに設定してください。効果は端末、カーネル、ゲームに左右され、デモ動画はそれを誇張しています。他のスケジューラ系モジュールと重ねて使わないでください。

インターフェースとテーマ

一度に1グループずつ変更を適用してください。対応していないROMとアップデートの組み合わせの後にSystemUIがクラッシュしブートループに陥るのは、テーマ系モジュールでよく見られるパターンです。大型のシステムアップデート前にはオーバーレイを元に戻してください。

ユーティリティ

開発者・セキュリティテスト向け

これらは端末の信頼境界を広げます。 通信デバッグやセキュリティ調査のために存在するもので、日常使いの端末に入れるのは得策ではありません。作業が終わったらテスト用CAを削除してください。どちらも証明書ピンニングは回避できません。

代替の整合性ツールキット

Integrity-Box（MeowDump/Integrity-Box）は、整合性機能と環境管理を独自インターフェースの下にまとめています。PlayIntegrityFix-NEXT（EricInacio01/PlayIntegrityFix-NEXT）はAndroid 10〜16を対象とした実験的なフォークでしたが、v3.0リリース後の2025年10月に所有者がアーカイブしたため、これを土台に新しい構成を始めるべきではありません。Integrity-Boxは非常に頻繁にリリースされており（2026年10月29日時点でv46）、これは良し悪し両面があります。修正は速い一方、目標が絶えず動き続けるということでもあります。

どちらもPlayIntegrityForkと機能が重複します。追加としてではなく、代替のスタックとして扱ってください。整合性ツールの重複は、診断が非常に困難な競合を生みます。

カーネルレベルの隠蔽（KernelSU系のみ）

SUSFSはgitlab.com/simonpunk/susfs4ksuにあり、付随するモジュールはsidex15/susfs4ksu-moduleにあります。SUSFSがパッチされたカーネルを必要とするため、KernelSU、KernelSU Next、SukiSU Ultraの選択肢です。MagiskやAPatchでは利用できません。

リスクの階層

すべてのモジュールが同じリスクを抱えているわけではありません。

現在モジュールを入手する場所

内蔵リポジトリがなくなった今、入手先は次のとおりです。

1. プロジェクト自身のGitHub Releasesページ。 上記すべてにとって正しい入手元であり、本記事のすべてのリンクがここを指しています。ソースアーカイブではなく、.zipアセットをダウンロードしてください。
2. Magisk-Modules-Alt-Repo、新規投稿を受け付けているコミュニティリポジトリです。
3. MMRL、手動でダウンロードするより閲覧して探したい場合に、Magisk、KernelSU、APatchのモジュールを扱えるモジュールマネージャーアプリです。

インストール方法：root管理ツールを開き、Modulesへ行き、「ストレージからインストール」をタップしてZIPを選び、再起動します。

当サイトはモジュールのバイナリをホストしておらず、それを行っているところには注意が必要だと考えています。ミラーサイトや短縮リンク、Telegramのファイルではなく、必ずプロジェクト本体からダウンロードしてください。

モジュールを見極める方法

rootモジュールはフル権限で動作します。それに見合った精査をしてください。

• ソースは公開されていますか？ リポジトリがなければインストールもなし。これだけで多くが除外されます。
• 最後のリリースはいつですか？ 変化の速い対象で2年間放置されているなら、それはリスクです。
• 保守担当者はissueに応答していますか？ 何か月もの沈黙はサインです。
• ドキュメントに対応状況が明記されていますか？ Androidバージョン、root管理ツール、既知の競合。
• 自分のAndroidバージョンとroot管理ツールで動かしている人はいますか？ 2023年当時に書かれた対象端末ではなく。
• 何かを弱体化させるよう求めてきますか？ SELinuxの無効化を要求するものは、厳しく見るべきです。

ブートループからの復旧

必要になる前に準備しておいてください。優先順の高い順に並べます。

1. セーフモード。 Magiskはセーフモードでの起動を検知すると、すべてのモジュールを無効化します。セーフモードで起動し、その後通常どおり再起動すれば、すべてが無効化された状態のシステムが立ち上がるので、アプリから原因のモジュールを削除できます。KernelSUも同様です。キーの組み合わせは端末によって異なるので、何事もないうちに一度練習しておいてください。

2. 削除コマンド。 起動を試みている端末をPCが認識できる場合、Magiskは次の方法を公式に文書化しています。

adb wait-for-device shell magisk --remove-modules

これはすべてのモジュールを削除し、再起動します。

3. シェルから特定の1つを無効化する。 /data/adb/modules/内にある該当モジュールのフォルダにdisableという名前のファイルを作成すると、そのモジュールだけを無効化できます。

4. 純正のブートイメージを復元する。 最後の手段であり、だからこそ1つ保存しておく理由になります。先に下の注意点を読んでください。

ブートイメージに関する注意点

Magisk自身のドキュメントは、パーティションの復元が端末ごとに異なると警告しており、特にSamsungユーザーに対してはboot、init_boot、recovery、vbmetaを安易に復元しないよう注意しています。汎用的なfastbootの手順はメーカーをまたいでは通用しません。APatchユーザーも、パッチの対象がinit_bootではなくbootである点に注意してください。

必ず自分の端末に合った正確な手順に従ってください。すでにフラッシュに失敗している場合は再度フラッシュする前に状態を診断し、端末がまったく起動しない場合はまずどの状態にあるかを把握してください。

何があっても初期化はしないでください。手順の順番が重要であり、工場出荷状態へのリセットはデータと一緒に暗号鍵も破壊します。

関連記事： Magisk・KernelSU・APatchの比較 ・ SafetyNetとPlay Integrity（root環境） ・ 2026年のMagisk：変更点まとめ ・ Magiskのフラッシュ失敗 ・ root化端末でOTAが失敗した場合 ・ Androidデブロートガイド

情報源：各プロジェクト自身のGitHubまたはGitLabリポジトリ（本文中にリンク）。Magisk公式ドキュメント、FAQ、リリースノート。APatchおよびKernelSUの公式ドキュメント。モジュールの状態は、上記の日付時点でのリポジトリの活動状況と保守担当者の発言に基づいて確認しています。

最終確認日：2026年10月30日。このエコシステムは変化が速く、ここに掲載したプロジェクトは確認時点では活動していましたが、予告なく終了・フォーク・後継への移行が起こり得ます。インストール前にリンク先のリポジトリを確認し、互換性は端末ごとに異なるものとして扱ってください。