SafetyNetとPlay Integrity API：root化した状態で通す方法（2026年）

Androidのroot化コミュニティが10年間使ってきたSafetyNet APIは、2024年初めにGoogleが正式に廃止し、Play Integrity APIに置き換えられました。2024年より前のガイドはすべて古くなっており、古いフォーラムのスレッドには誤った情報が多く残っています。このガイドは、2026年の最新の実践的な手順です。何が変わったか、Play Integrityの3つの判定が実際に何を意味するか、2026年に使える回避ツール、具体的なMagiskのコマンドを含む手順を解説します。すでにroot化した端末を持っていて、銀行アプリや決済アプリを動かしたい上級者向けです。

SafetyNetからPlay Integrityへ：簡単な経緯

SafetyNet（2014〜2024年）は、Googleの端末の状態を証明するAPIでした。返す値は2つの真偽値で、ctsProfileMatch（その端末が既知のCompatibility Test Suiteのプロファイルに一致するか）とbasicIntegrity（ブートローダーがロックされた状態など、基本的な整合性の検査に通るか）です。銀行アプリはGoogle Play開発者サービス経由でこれを呼び出し、2つの真偽値を受け取って、どちらかがfalseなら動作を拒否していました。回避方法は10年の間に変わりました。最初はMagiskHide、Magisk 24でMagiskHideが廃止されたあとはZygisk + DenyList、さらに強力に隠すためにその上にShamikoが使われるようになりました。

Play Integrity API（2023年〜現在）は、公式の後継です。廃止までの経緯は次のとおりです。

• 2023年6月：Play Integrity APIが、推奨される後継として公開
• 2023年半ば〜2024年初め：アプリがSafetyNetからPlay Integrityへの移行を開始
• 2024年1月：SafetyNetが正式に非推奨化。新しいAPIの応答は保証されなくなる
• 2026年半ばまで：主要な銀行アプリや決済アプリのほとんどが、Play Integrityのみを使用

Play Integrityは、2つの真偽値ではなく3つの判定を返し、最も厳格なレベルではハードウェア鍵アテステーションを使います。そのため、ソフトウェアだけの方法で回避するのは根本的に難しくなっています。

Play Integrityの3つの判定を解説

Play Integrityのチェックは、毎回3つの真偽値を返します。

MEETS_DEVICE_INTEGRITY

基本のレベルです。端末が改変されていないAndroidで動作し、Google Play開発者サービスがインストールされ、基本的な互換性の検査に通っていることを意味します。現在のツール（Magisk + Zygisk + DenyList + Shamiko + Play Integrity Fixモジュール）で、root化した端末でも回避できます。アプリの約60%が、通常どおり動作するためにこの判定を必要とします。

MEETS_BASIC_INTEGRITY

システムファイルの整合性、Google Play開発者サービスの想定される状態、一部のデバッグ状態のチェックなど、環境の追加検証を含む、より厳しいチェックです。root化した端末でもほとんどは回避できますが、モジュールの設定の影響を受けやすくなります。アプリの約30%が、DEVICE_INTEGRITYに加えてこの判定を必要とします。ほとんどの銀行アプリは両方を必要とします。

MEETS_STRONG_INTEGRITY

最も厳しいレベルです。ハードウェアで保護された鍵によるアテステーションを使います。端末のTEE（Trusted Execution Environment）が応答に署名し、その署名は端末メーカーのルート証明書までさかのぼって検証できます。鍵がセキュアエレメントで保護されているため、この仕組みはブートローダーがロックされていても成立します。ブートローダーをアンロックした端末では、現在のソフトウェアの方法では回避できません。アンロックによって、TEEの鍵が依拠する検証済みブートのチェーンが壊れるためです。

アプリの約10〜20%が、STRONG_INTEGRITYを必要とします。

• 一部の地域のGoogleウォレットのタッチ決済
• 一部のネオバンク（Revolut、Wise、一部の地域のN26）
• 一部の公的IDアプリ（デジタルパスポート、有権者ID）
• 厳格なコンプライアンス要件を持つ医療アプリ
• 一部の、勤務先が配布したMDM保護の業務アプリ

必須のアプリがSTRONG_INTEGRITYを必要とする場合、そのアプリとrootは両立せず、現時点でこれを変える回避策はありません。

回避ツール：Magisk Hide、Shamiko、TrickyStoreの違い

2026年現在、root化した端末でPlay Integrityを回避するには、主に3つのツールを組み合わせて使います。

手順：一般的な銀行アプリ向けにPlay Integrityを通す

すでに次の条件を満たしている前提です。

• ブートローダーをアンロック済み
• パッチ済みのboot.img経由でMagiskをインストール済み
• Magisk Managerでrootの動作を確認済み

まだの場合は、先にブートローダーのアンロックガイドとMagisk・KernelSU・APatchの比較をご覧ください。

手順1：MagiskでZygiskを有効にする

Magiskアプリを開き、Settings（歯車アイコン）でZygiskのトグルをオンにします。再起動します。

再起動後、MagiskのSettingsに戻り、Enforce DenyListをオンにします。

手順2：Shamikoをインストールする

GitHubの公式LSPosed/LSPosedのリリースから、最新のShamikoのzipをダウンロードします。MagiskアプリのModulesタブで+アイコンをタップし、Shamikoのzipを選んでインストールします。再起動します。

再起動後、Shamikoが読み込まれていることを確認します。MagiskアプリのModulesタブにShamikoが表示され、有効になっているはずです。

手順3：Play Integrity Fixモジュールをインストールする

GitHubのchiteroman/PlayIntegrityForkのリリースから、最新のPIFのzipをダウンロードします（現在メンテナンスされているフォークを使ってください。最新の推奨はXDAのRecognized Developerのスレッドで確認できます）。

MagiskアプリでModulesを開き、+をタップしてPIFのzipをインストールし、再起動します。

手順4：PIFのフィンガープリントを、現在通るものに更新する

PIFのフィンガープリントは、現在Play Integrityに通っている既知の端末のものと一致している必要があります。PIFモジュールにはautoupdateスクリプトが含まれています。ターミナルアプリ（Termuxで問題ありません）を開き、次を実行します。

su -c sh /data/adb/modules/playintegrityfix/action.sh

コミュニティが管理する、通る最新のフィンガープリントを取得して適用します。再起動します。

手順5：対象アプリのDenyListを設定する

MagiskアプリでConfigure DenyListを開き、使う必要がある銀行、決済、Play Integrityを確認する各アプリを検索します。各アプリの横のトグルをタップして、隠蔽を有効にします。サブプロセスの項目は、通常は自動でオンになります。

追加する主なアプリ：

• メインの銀行アプリ（HDFC、SBI、Bank of America、Lloydsなど）
• モバイルマネーのアプリ（bKash、GCash、M-Pesa、JazzCash）
• 決済アプリ（Google Pay、PayPal、Venmo、Cash App）
• 証券アプリ（Robinhood、Zerodha、Groww）
• 公的サービスのアプリ（DigiLocker、Aadhaar、NHSアプリ）
• DRM付きの動画配信アプリ（Netflix、Disney+、Amazon Prime。HD/4K再生のためにPlay Integrityを確認します）

手順6：Play Integrity API Checkerで確認する

PlayストアからPlay Integrity API Checkerをインストールします（複数のバージョンがあります。gkkang版か、LSPosedチームがメンテナンスしているものを試してください）。

アプリを開き、Checkをタップします。次を確認します。

• MEETS_DEVICE_INTEGRITY：trueになっているはずです
• MEETS_BASIC_INTEGRITY：trueになっているはずです
• MEETS_STRONG_INTEGRITY：ブートローダーをアンロックした端末ではfalseになりますが、想定どおりです

DEVICEとBASICの両方がtrueなら、判定のレベルでは回避が機能しています。ほとんどの銀行アプリと決済アプリは、通常どおり動作するはずです。

手順7：銀行アプリを1つずつテストする

各アプリを1つずつ開きます。スプラッシュ画面を越えて起動し、ログインできることを確認します。動かないアプリがある場合は、次を試します。

1. アプリがDenyListで有効になっていることを確認する
2. PIFのautoupdateコマンドを再実行して、フィンガープリントを更新する
3. 再起動
4. それでも動かない場合、そのアプリはPlay Integrity以外の検出も使っている可能性があります。TrickyStoreを追加のレイヤーとして試すか、現在のroot環境にそのアプリは対応しないと割り切ってください

判定は通っているのにアプリが動かない場合

一部のアプリは、公式のPlay Integrity API以外の検出手段も使っています。

• ファイルの直接スキャン：/system/bin/su、Magiskのバイナリのパス、既知のモジュールのインストール先を探します。対処法：Magiskのファイル隠蔽（MagiskHide相当の機能。最近のMagiskに内蔵）を有効にします。
• プロセスの名前空間の確認：/proc/self/statusなどを調べて、Zygiskのフックの痕跡を探します。対処法：ほとんどのケースはShamikoで処理できます。
• Play Integrityとは別のTEEアテステーションのチャレンジ。対処法：一部のアプリはTrickyStoreで対応できますが、不可能なアプリもあります。
• アプリ開発者が管理するアプリ固有のブロックリスト：root関連の既知のパッケージ名が含まれます。対処法：SettingsのHide the Magisk appでMagiskアプリの名前を変更し、Magiskらしくない名前を付けます。

地域別の銀行アプリの状況：root化したAndroidで現在動くもの

銀行アプリの動作は、各銀行が整合性チェックの厳しさを独自に決めるため、地域によって大きく異なります。2026年にかけて、BD/IN/PK/UKの市場のお客様から寄せられた報告に基づいています。

バングラデシュ

• bKash：ほとんどのユーザーはMagisk + Shamiko + PIFで動作します。Googleの更新後に、フィンガープリントの更新が必要になることがあります
• Nagad：同じ構成で動作します。フィンガープリントの新しさの影響をやや受けやすい
• Rocket（DBBL）：標準の構成で動作します
• City Bank、BRAC Bank、EBL、Dutch-Bangla Bankのアプリ：ほとんどは標準の構成で動作します。Play Integrityの更新のたびに確認してください
• 銀行独自のタッチ決済：通常はSTRONG_INTEGRITYが必要です。root化した端末では回避できません

インド

• Google Pay（Tez）：UPIは標準の構成で動作します。タッチ決済（対応地域）にはSTRONG_INTEGRITYが必要です
• PhonePe、Paytm：UPIは標準の構成で動作します
• HDFC、ICICI、SBI YONO、Axis Mobile：ほとんどは動作します。HDFCとAxisはやや厳しく、一部の機能にTrickyStoreが必要な場合があります
• 証券アプリ（Zerodha Kite、Groww、Upstox）：標準の構成で動作します
• Aadhaar mAadhaarアプリ：ほとんどの機能で動作します。生体認証の機能では、追加の隠蔽設定が必要な場合があります

パキスタン

• JazzCash、Easypaisa：どちらも、ほとんどのユーザーは標準の構成で動作します
• HBL Mobile、UBL Digital、Meezan Bank Mobile：ほとんどは動作します。3つの中ではMeezanが最も厳しいです
• NayaPay、SadaPay（ネオバンク）：ばらつきがあります。これらのためにrootに頼る前に確認してください

英国とEU

• ほとんどの大手銀行のアプリ（Lloyds、Barclays、HSBC、Santander、NatWest）：2026年半ば時点では、標準の構成で動作します
• ネオバンク（Revolut、Wise、N26、Monzo）：RevolutとWiseは厳しいことで知られ、一部の操作でSTRONG_INTEGRITYを求められることがよくあります。MonzoとStarlingは、通常はもう少し寛容です
• AppleとGoogleのタッチ決済に相当するサービス：STRONG_INTEGRITYが必要です。回避できません

この一覧は執筆時点の状況を反映したもので、定期的に変わります。時間的に急ぎの金融取引でrootに頼る前に、必ずお使いのアプリを実際にテストしてください。

STRONG_INTEGRITYがTEEレベルで実際に行っていること

ブートローダーをアンロックした端末では、STRONG_INTEGRITYを根本的に回避できない理由について、上級者向けの技術的な背景です。

最近のAndroid端末にはTrusted Execution Environment（TEE）があります。メインのAndroid OSから隔離された、独自のメモリとオペレーティングシステムを持つ別のセキュアなプロセッサです。TEEは、工場で割り当てられ、メーカーのルート認証局が署名した、端末固有の暗号鍵を保持しています。

アプリがSTRONG_INTEGRITYを要求すると、リクエストはTEEを通り、TEEはこれらの工場で割り当てられた鍵で応答に署名します。応答には、現在の検証済みブートの状態が含まれます。これは、ブートローダーがロックされ、boot、system、vendorの各パーティションがメーカーの署名済みの想定と一致していることを証明するハッシュチェーンです。

ブートローダーをアンロックすると、TEEは検証済みブートの状態を「yellow」（ユーザーがインストールした鍵）または「orange」（検証済みブートなし）に更新します。TEEは引き続きSTRONG_INTEGRITYの応答に署名しますが、応答にはアンロックされた状態が明記されます。STRONG_INTEGRITYを必要とするアプリはこのフィールドを確認し、「green」（ブートローダーがロックされ、ブートチェーンがメーカーの署名済み）以外の状態では動作を拒否します。

メインのOSはTEEが署名に使う鍵にアクセスできないため、ソフトウェアで偽装することはできません。TrickyStoreはTEEに到達する前にキーストアの呼び出しを横取りし、似た端末から記録しておいた「良い」応答に置き換えられます。応答のハードウェア由来を適切に検証しない一部のアプリには有効ですが、検証するアプリ（厳しいアプリ）には、置き換えを検出されます。

STRONG_INTEGRITYを通す確実な方法は次の2つだけです。

• 純正ファームウェアのboot.imgで動かします。ブートローダーは再ロックします。Pixelや一部のOnePlusなど、メーカー署名のイメージを書き込んだあとでブートローダーを再ロックできる端末があります。STRONG_INTEGRITYは復活しますが、rootは失われます。
• root化していない予備の端末を使います。STRONG_INTEGRITYを必要とする、少数のアプリ用です。

隠された3つ目の選択肢はありません。TEEの設計は、まさにそれを防ぐためのものです。

おすすめしない方法

• Play Integrityの回避モジュールを、特に理由なく複数同時に動かす：競合しやすく、直るアプリより動かなくなるアプリの方が多くなります。
• 出所の分からないPIFのフォークを使う。メンテナンスされている本流のフォークを使い、現在の推奨はXDAのスレッドで確認してください。
• 高額の金融取引で回避に頼る。失うと困る金額には、root化していない予備の端末を使い、root化した端末での不正利用の責任について、銀行の利用規約を読んでください。
• Playストア自体にrootを有効にする。PlayストアをDenyListに入れる必要はありません。入れても利点はなく、Playストアの機能が壊れることがあります。

専門家に相談すべきタイミング

root化後に特定の銀行アプリが動かず、標準の構成を試した場合は、WhatsAppまたはTelegramでご連絡ください。BD、IN、PK、UK、US、EU市場の主要な銀行のほとんどについて、確認済みで動作する設定を把握しており、通常は30〜60分のリモートセッションでアプリを動かせます。含まれる内容は、Android root化サービスをご覧ください。

DenyListとShamikoのモジュールレベルの詳細は、Magiskモジュールのガイドで、現在のPlay Integrity隠蔽の構成と、まだメンテナンスされているフォークを解説しています。