LASSIC Media らしくメディア
App Attest/Play Integrityで不正利用対策
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- App Attest・DeviceCheck・Play Integrity APIがそれぞれ何を検証する仕組みかを整理します。
- iOSとAndroidの対応関係を比較表で確認できます。
- サーバー側検証を内製する場合の難所と、外注を検討すべき判断軸を紹介します。
目次
App Attest・DeviceCheckによる不正利用対策とは
App Attest・DeviceCheckによるアプリ不正利用対策とは、アプリと端末が改ざんされていない正規のものであることをサーバー側で暗号学的に検証し、なりすましAPI呼び出しや不正課金、チート行為を防ぐ仕組みである。iOSではApp AttestとDeviceCheck、AndroidではPlay Integrity API（旧SafetyNet Attestation）*1が、この検証（アテステーションattestation、端末やアプリの真正性を証明する処理）を担う。
なりすましAPI呼び出しと不正課金が増える背景
モバイルアプリのAPIは、リバースエンジニアリングやエミュレーター経由で解析されると、正規アプリを介さずにサーバーへ直接リクエストを送る「なりすましAPI呼び出し」の対象になりやすい。クーポン不正利用・ポイント不正付与・チートツールによるゲーム内資産の不正取得などは、この経路で発生する*2。
従来型の対策であるAPIキー埋め込みや証明書ピンニングは通信経路の保護に有効だが、リクエストの送信元がそもそも改ざんされた正規アプリのクローンなのか、正規のバイナリなのかまでは判別できない。App AttestやPlay Integrity APIは、この「送信元アプリと端末そのものの真正性」を検証する層として位置づけられる。
Apple Developer公式は、App Attestを「サーバーが受け取るリクエストが正規のアプリインスタンスから来ていることを保証する」仕組みと説明している*3。Android Developers公式も、Play Integrity APIを「ユーザー操作とサーバーリクエストが、Google Playでインストールされた改ざんされていないアプリから、認定されたAndroid端末上で発生していることを検証する」ものと位置づけている*4。
App Attestが端末とアプリの正当性を証明する仕組み
端末内の鍵ペア生成とSecure Enclaveへの紐付け
App Attestは、アプリの初回起動時などにアプリ・端末ごとの鍵ペアを生成する。秘密鍵はSecure Enclave（iOS端末が持つ独立したセキュリティ専用チップ）内に保持され、外部に取り出せない構造になっている*3。この鍵ペアがアプリインスタンスと端末を紐づける起点になる。
attestKeyによる証明書チェーン付きattestation object
サーバーが発行したチャレンジ（一度限り使うランダム値）を使い、アプリはattestKeyを呼び出す。この処理でApple自身が署名した証明書チェーンを含む「attestation object」が生成され、サーバーに送られる*5。サーバー側はApple公式の検証手順に従い、証明書チェーンとチャレンジの整合性を確認することで、リクエスト元が改ざんされていない正規アプリかどうかを判定できる。
generateAssertionによる継続的なリクエスト検証
初回のattestationが完了した後は、毎回の重い処理を避けるためgenerateAssertionを使う。これはリクエストの内容（ペイロード）に対して端末内の秘密鍵で署名を行う処理であり、リプレイ攻撃（同じリクエストの再送による不正利用）を防ぐ役割を持つ*5。
DeviceCheckが担う端末単位のリスク判定
DeviceCheckはApp Attestと同じApple Developerのフレームワーク群に属するが、役割が異なる。端末ごとに2ビットの情報をApple側に保存・照会できる仕組みで、ビット自体は開発者が用途を自由に定義できる不透明な状態フラグとして扱われる*6。
典型的な使い方は、無料トライアルの再利用防止や、不正が確認された端末へのフラグ付けである。App Attestが「このリクエストは正規アプリから来ているか」を検証するのに対し、DeviceCheckは「この端末は過去に不正な挙動があったか」を判定する材料になる。両者は代替関係ではなく、補完的に併用されることが多い*6。
Play Integrity APIとSafetyNetからの移行
Androidでは旧SafetyNet Attestation APIが2025年1月31日に完全に終了し、Play Integrity APIへの移行が完了している*1。現在新規に実装する場合はPlay Integrity API一本で対応する。
appRecognitionVerdictとdeviceIntegrityの2軸判定
Play Integrity APIは複数の判定結果（verdict）を返す。代表的なものは、アプリの署名とバイナリ改ざんの有無を示すappRecognitionVerdictと、端末が認定済みでハードウェアに支えられた堅牢性を持つかを示すdeviceIntegrityである*4。deviceIntegrityはさらに複数段階に分かれ、Android 13以降の端末では上位水準のMEETS_STRONG_INTEGRITYまで区別できる。
Standard requestとrequestHashによる改ざん対策
推奨される「Standard」方式では、リクエストの主要な値をハッシュ化したrequestHashをサーバーに渡し、リプレイ・改ざんを検知する。従来の「Classic」方式はnonce（使い捨ての一意な値）による検証で、高頻度な呼び出しには向かない設計になっている*4。デフォルトの利用上限は1日あたり1万件で、超える場合はGoogle Play Consoleから増枠を申請する*4。
iOSとAndroidの対応関係を比較する
iOSとAndroidでは実装する仕組みの名称も検証方式も異なるため、両OS対応を前提にする場合は対応関係を正しく整理しておく必要がある。
| 比較項目 | iOS（App Attest／DeviceCheck） | Android（Play Integrity API） |
|---|---|---|
| 検証対象 | アプリインスタンスと端末の鍵ペア紐付け | アプリ署名の一致・端末の認定状態 |
| 主な判定結果 | 証明書チェーン付きattestation object | appRecognitionVerdict／deviceIntegrity |
| リプレイ対策 | サーバー発行のチャレンジ＋generateAssertion | requestHash（Standard）／nonce（Classic） |
| 端末単位の追加判定 | DeviceCheckの2ビット状態フラグ | deviceRecall（ベータ、再インストール後の再検知） |
| 前身・関連API | DeviceCheckはApp Attestと併用可能 | 旧SafetyNet Attestationは2025年1月末に終了*1 |
内製導入で直面する3つの難所
App AttestもPlay Integrity APIも、公式ドキュメントに実装手順が示されている。しかし実際にサーバー側検証まで含めて内製すると、想定以上に工数がかかる場面が多い。
難所1：証明書チェーン検証とデコード処理をサーバー側で自前実装する負荷
App Attestのattestation objectはCBOR形式（バイナリのデータ構造）でエンコードされており、Appleのルート証明書から検証チェーンをたどる処理をサーバー側言語で自前実装する必要がある。既存の証明書ピンニングや脆弱性診断対応の担当者とは異なる、暗号処理・PKI（公開鍵基盤）の知識が要る領域である。
難所2：チャレンジ・nonce・requestHashの発行と一致検証をリクエスト単位で管理する運用
チャレンジやnonceは使い捨てが前提のため、発行から検証までの状態管理をサーバー側で持つ必要がある。Play Integrity APIのrequestHashも同様に、リクエストごとの値をアプリとサーバーの両方で一致させる実装が要る。設計を誤ると、正規ユーザーのリクエストまで拒否してしまう恐れがある。
難所3：判定失敗時のフォールバック設計とOS・端末差分の吸収
attestationが失敗する状況は、不正だけが原因ではない。OSバージョンの制約やネットワーク不通、非対応の古い端末など正当な理由でも失敗しうる*3*4。失敗時にアプリの利用自体を止めてしまうと正規ユーザーの体験を損なうため、失敗理由に応じて許可・制限・拒否を分けるフォールバック設計が欠かせない。iOSとAndroidでは判定の粒度や失敗パターンが異なるため、共通ロジックのまま流用すると判定精度が落ちやすい。
段階導入とフォールバック設計の考え方
attestationの導入は、いきなり全リクエストを拒否判定に使うのではなく、段階的に進めるのが実務上の定石である。まず判定結果をログに記録するだけの監視フェーズを設け、実際のトラフィックでどの程度の割合が非対応・失敗になるかを把握する。
次に、不正の可能性が高い操作（決済・アカウント登録・キャンペーン応募など）に限定して判定を適用し、通常の閲覧操作には適用しない設計にすると、誤判定による正規ユーザーへの影響を抑えられる。iOSのdeviceIntegrity相当の判定やAndroidのdeviceIntegrityの段階（MEETS_BASIC_INTEGRITY〜MEETS_STRONG_INTEGRITY）を使い分け、リスクの高い操作ほど厳格な水準を要求する設計が有効である*4。
この段階導入とフォールバック設計を内製で行うには、iOS・Android双方のセキュリティ実装経験に加え、不正検知の閾値調整を継続的に行う運用体制が要る。単発の実装だけでなく、リリース後のチューニングまで見据えた工数を確保する必要がある。
外注が有効な場面と確認すべき体制
iOS・Android両対応でattestationを実装する場合、証明書検証・状態管理・フォールバック設計という3つの難所を並行して抱えることになる。社内にPKIや暗号処理の実装経験を持つエンジニアが少ない場合は、外部の開発パートナーに設計・実装を依頼するという選択肢がある。
依頼先を検討する際は、以下の観点を確認するとよい。まず、App AttestとPlay Integrity APIの両方についてサーバー側検証の実装経験があるかどうかである。次に、判定失敗時のフォールバック設計を含めた運用設計まで対応できるかどうかも重要な確認点になる。さらに、リリース後の閾値調整や、OSアップデートによる仕様変更への追従体制があるかも見ておきたい。
まとめ：App Attest・DeviceCheck・Play Integrity API導入の3つの判断軸
本稿では、App Attest・DeviceCheck・Play Integrity APIによるアプリ不正利用対策の仕組みと、内製導入時の難所を整理した。要点を3つに集約すると次の通りである。第一に、App AttestとPlay Integrity APIはそれぞれ鍵ペア・証明書チェーンとverdict判定という異なる方式でアプリ・端末の真正性を検証する。第二に、内製実装では証明書検証・状態管理・フォールバック設計の3つが工数のかかる難所になる。第三に、段階導入とリリース後の運用体制まで見据えた設計が、誤判定による正規ユーザーへの影響を抑える鍵になる。
よくある質問
App AttestとDeviceCheckは両方導入する必要がありますか。
必須ではありませんが、併用されることが多いです。App Attestはリクエスト単位でアプリの真正性を検証し、DeviceCheckは端末単位で過去の不正履歴に近い状態フラグを管理します*3*6。用途が異なるため、不正利用対策の目的に応じて組み合わせを検討するとよいでしょう。
Play Integrity APIの利用に費用はかかりますか。
API自体の利用に基本料金はありませんが、デフォルトでは1日あたり1万件のリクエスト上限があります*4。この上限を超える利用が見込まれる場合は、Google Play Consoleから増枠を申請する必要があります。
旧SafetyNet Attestationをまだ使っているアプリはどうなりますか。
SafetyNet Attestation APIは2025年1月31日に完全に終了しており、呼び出してもエラー応答が返る状態です*1。現在も旧APIを利用したままのアプリは、Play Integrity APIへの移行が必要です。
attestation対応は既存アプリへの後付けでも実装できますか。
既存アプリへの後付け実装は可能です。ただし、既存のAPI設計にチャレンジやrequestHashのやり取りを組み込む必要があるため、通信処理部分の改修範囲を事前に洗い出しておくことが重要です。
attestation判定に失敗した場合、ユーザーのアプリ利用をすぐに止めるべきですか。
すぐに利用を止める設計は推奨されません。OSバージョンや端末の制約など、不正以外の理由で判定が失敗する場合もあるためです*3*4。失敗理由に応じて許可・制限・拒否を分けるフォールバック設計を検討してください。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Android Developers「Migrating from the SafetyNet Attestation API」（developer.android.com）
- *2 出典：Android Developers「Play Integrity API Overview」記載のリスク事例（developer.android.com）
- *3 出典：Apple Developer Documentation「Establishing your app’s integrity」（developer.apple.com）
- *4 出典：Android Developers「Overview of the Play Integrity API」（developer.android.com）
- *5 出典：Apple Developer Documentation「DCAppAttestService」（developer.apple.com）
- *6 出典：Apple Developer Documentation「DeviceCheck」（developer.apple.com）
