Play Integrity API：改ざん検知の最低限の導入判断

2026/9/20

背景と問題

Android 側の IAP 防御（opc-receipt-validation-minimum の Play 侧）の深掘り：Play Integrity API（SafetyNet 後継）を solo が入れるべきかの判断。

（出典はいずれも 2026-09-20 アクセス）

事実（Google 公式ドキュメント 2026-04）：Play Integrity API=正規の app バイナリか（appIntegrity verdict：改ざん検知）・Play からインストールされたか・リスクのあるデバイスかを判定する唯一の公式 attestation（SafetyNet の後継）。
事実（Sonar 2026-06）：全 app が導入すべきではない——fintech/HIPAA/PSD2 系の規制対象 app は必須扱い、一般 app は判断制。日次 10,000 リクエスト/project の quota（超過は申請）。
事実（Approov/Guardsquare の指摘）：Play Integrity は関数レベルの防御を自前で書く必要がある——導入だけでは何も守られない（verdict の使い方まで設計が必要）。
事実（Firebase App Check）：App Check の Play Integrity provider 経由が solo の最短導入路——Firebase 利用中なら設定だけで接続可能。
事実（注意点）：古い Android で MEETS_DEVICE_INTEGRITY が落ちる互換性問題（コミュニティ報告）——判定をハードに使うと正規ユーザーを締め出す。
推测：solo の防御の実はサーバー側 entitlement（opc-receipt-validation-minimum）に Integrity verdict を補助材料として 1 つ足す程度——verdict 単体で拒否すると偽陰性で正規ユーザーを落とす。

導入判断の基準：金融/健康データを扱う→導入必須扱い；一般ツール→導入せずサーバー側 entitlement 検証のみでも可（リスク許容の問題）。
導入するなら App Check 経由：Firebase 利用製品は App Check+Play Integrity provider が最短（手書きの API 呼び出しは不要）。
quota 認識：日次 1 万リクエスト——検証は「購入時・復元時」など低頻度イベントに限定し、起動毎には使わない。
verdict は補助材料：MEETS_DEVICE_INTEGRITY が無くても正規ユーザーが居る（古端末）——拒否ではなく「警告フラグ」に使う。