Google Playが“ストアのストア”を受け入れる日—配布と課金のゲーム盤が動き、モバイルの信頼モデルが書き換わる可能性です

今日の深掘りポイント

• 単一ゲートキーパーから複数審査体制へ。アプリ配布の信頼チェーンが多層化し、攻撃面も責任分界も変わります。
• 「ストアのストア」がPlay経由で届くことで、ユーザーは容易に第三者ストアを導入可能に。権限・更新・支払いの3点が新たなリスク接点になります。
• 反トラストの是正策とEU DMAの潮流が合流。規制発の競争促進は、結果として企業側のモバイル管理・検知要件の高度化を迫ります。
• 直ちに炎上する話ではないですが、確度は高く、設計・ガバナンス・監視の「前倒し準備」を評価すべきタイミングです。
• セキュリティ組織は「第三者ストアの許容方針」「REQUEST_INSTALL_PACKAGES権限の扱い」「代替決済の安全実装」の3点で運用ルールを具体化すべきです。

はじめに

Epic Gamesの反トラスト訴訟を背景に、GoogleがGoogle Play上でサードパーティ製アプリストア（以下「第三者ストア」）の配布を許容する方針へ動きました。報道ベースですが、開発者の配布・課金選択肢が広がり、利用者も新たなアプリ発見経路にアクセスできるようになる見込みです。この変更は市場競争に資する一方、Androidのセキュリティ・トラストモデルを現場目線で「どう運ぶか」の論点を一気に増やします。

編集部としての読みはこうです。実装・ポリシー細部は今後明らかになるはずですが、方向性の確度は高く、足元の脅威が即跳ね上がるというより「中期にわたる運用設計・監視強化」が最も効果的な投資になります。CISO・SOC・TIは、組織のAndroid管理スタックと顧客向けモバイルアプリの双方で、配布・更新・決済レイヤーのリスクを再棚卸しする好機と捉えるべきです。

参考：今回の動きは下記の報道で示されています。一次情報の解禁条件やAPI/ポリシー変更は今後の公式文書を待つ必要がある点を明示しておきます。

• EFF: Challengers Approach: Third-Party App Stores Arrive on Google Play（2026-10）

深掘り詳細

いま分かっている事実（報道整理）

• Google Play上で第三者ストアアプリの配布が可能になる見通しです。これにより、ユーザーはPlayから第三者ストアを入手し、そのストア経由で他アプリを導入できるパスが広がります。
• 背景にはEpic Gamesによる反トラスト訴訟の帰結があり、配布・課金の選択肢拡大が焦点になっています。
• 具体的な実装面（警告画面の文言・トグルUI、Play Protectとの連携、ストア側に課すセキュリティ要件、決済のガイドラインなど）は、今後の正式ポリシーやドキュメントで確定するはずです。現時点では憶測を避け、原則として「第三者の配布経路がPlayに登場する」という構造変化を押さえるのが妥当です。

出典：上記EFFの報道。公式の詳細条件は今後の公表待ちです。

セキュリティ視点のインサイト（設計・運用・規制）

• 信頼チェーンの多層化と責任分界の再設計

  • 従来の「Playのポリシー審査＋Play Protect」が一次防壁だった配布面に、第三者ストアの審査・スキャン・署名・更新経路が追加されます。審査基準の差異と更新パイプラインの堅牢性が、新たな「供給網リスク」の主因になります。
  • 企業側は「どのストアを信頼するか」を組織方針として明文化し、端末管理（EMM/MDM）・ネットワーク制御・MTD（モバイル脅威防御）のルールへ落とし込む必要があります。

• 権限・更新・決済の三位一体リスク

  • 第三者ストアはアプリを配布するため「不明ソースからのアプリのインストール」許可や、REQUEST_INSTALL_PACKAGESなどの権限を正当な理由で要求します。これらは本質的に強力な権限で、悪用されるとサイドロード経由でPlayの審査外アップデートが継続的に可能になります。
  • ストア独自の更新機構は、CDN・署名鍵・配布マニフェストのいずれかが侵害されると大量の端末へ一斉配信される「面の脅威」になります。検知はPlayの外側で起こるため、MTDやネットワーク監視が一次検知線になります。
  • 代替決済の拡大は、アプリ内のWebViewや外部ブラウザ遷移を増やしがちです。オーバーレイやアクセシビリティ乱用型のバンキング型マルウェアにとっては新たな釣り場になり得ます。開発側の安全実装規律が品質差となってユーザーリスクに直結します。

• 規制潮流と国際整合の重み

  • 反トラストの是正策とEUのDMAが促す「ゲートキーパー機能の分散」は不可逆的に進んでいます。セキュリティは「集中の強さ」から「分散の冗長化」へ考え方を切り替える段階です。複数の審査・スキャン・署名運用を相互牽制として活かす設計が鍵になります。

• 実務優先の温度感

  • いま求められるのは、場当たり的な遮断ではなく「基準と可視化」の整備です。信頼できる第三者ストアの評価フレーム、強権限アプリの継続モニタリング、代替決済のセキュア実装ガイドライン—この三点セットを整えた組織が、中期のTCOと事故率の両面で有利になります。

脅威シナリオと影響

以下は、MITRE ATT&CK for Mobileの観点に沿った仮説シナリオです（実装詳細は今後の公式ポリシーに依存するため、あくまで想定ベースです）。

• シナリオ1：Play掲載の「第三者ストア」アプリを足がかりに、審査外アプリを継続配布

  • 初期アクセス（Initial Access）：正規のアプリストアアプリとしてPlayから導入される（公式チャネル由来の信頼を獲得）です。
  • 権限獲得・永続化（Privilege/Persistence）：「不明ソースからのインストール」許可やREQUEST_INSTALL_PACKAGESを取得し、アプリ内アップデーターを常駐させます。端末再起動後もBOOTP_COMPLETEDレシーバで復帰します。
  • 防御回避（Defense Evasion）：難読化や動的コード読み込み（外部DEX/Bundleの取得）で静的検知を回避します。Play Protectの事後スキャンを回避するタイミングでサイドロードを実行します。
  • 資格情報・金銭詐取（Credential Access/Impact）：オーバーレイ権限やアクセシビリティ乱用で金融アプリの画面乗っ取りを図ります。
  • 影響：正規アプリに見える導入経路＋強権限の組合せで、利用者の警戒心を鈍らせます。企業端末ではMTD/EMMの適用状況で被害差が大きく出ます。

• シナリオ2：正規第三者ストアのサプライチェーン侵害

  • 初期侵入はストアの署名鍵・ビルド環境・配布マニフェストのいずれかです。
  • 配布（Delivery）：正規更新として改ざん版ストアや配下アプリを一斉配信します。
  • C2/窃取（Command and Control/Exfiltration）：FCMやHTTPSでの常時通信、端末・連絡先・SMSの抜き取りを実行します。
  • 影響：1対Nの面展開。検知はネットワーク異常や端末ふるまい監視に依存し、Playの審査外で発生するため封じ込めの初動が遅れがちです。

• シナリオ3：代替課金のフィッシング・中間者化

  • 初期アクセス：アプリ内WebViewや外部ブラウザでの決済フローへ誘導します。
  • 処理改ざん：ディープリンク/インテントのハイジャック、オーバーレイでカード情報・ワンタイムコードを詐取します。
  • 影響：決済安全性はPSP選定と実装品質に大きく依存。アプリ側に3DSや意図検証（App Links/Intent Filtersの厳格化）を組み込むかが分水嶺です。

• シナリオ4：EMMの設定不備を突く企業端末の“外部配布”横滑り

  • 初期アクセス：Play経由で第三者ストアを導入（Managed Google Playの許容範囲に残る場合）します。
  • 展開：第三者ストアに「不明ソースからのインストール」を許可した瞬間に、EMMのアプリ許可リスト外アプリが流入します。
  • 影響：MDM/EMMの制御面で「Play由来ならOK」という前提が崩れ、パッケージ名ベースの許容・禁止や権限ベースの制御にアップデートが必要です。

総じて、初期アクセス（正規アプリ装い/公式流通）、防御回避（難読化・動的ロード）、永続化（自動更新機構）、情報搾取（オーバーレイ/アクセシビリティ）、指揮統制（FCM/HTTPS）といったモバイルATT&CKの典型的な流れが、第三者ストアという新しい踏み台で再構成されるイメージです。

セキュリティ担当者のアクション

すぐにできる現実的な対策から、中期の設計変更までを優先度順で並べます。

• ポリシーとガバナンス

  • 「第三者ストアの取り扱い方針」を制定します。評価基準（審査プロセス公開度、マルウェア検知エコシステム連携、署名鍵運用、Incident Disclosure方針など）を明文化します。
  • 社内端末向けに「ストアのストア」を原則禁止／許可（条件付き）いずれにするかを決め、例外承認フローを整えます。

• EMM/MDM・MTDの実装ルール

  • Managed Google Playの厳格な許可リスト運用を徹底します。第三者ストアのパッケージ名を個別に拒否できるか検証します。
  • 「不明ソースからのアプリのインストール」とREQUEST_INSTALL_PACKAGES権限の行使をアプリ単位でブロック/監査します。
  • MTDで以下のシグナルを高感度に監視します。
    • 動的コード読み込み、外部DEX取得の痕跡
    • オーバーレイ・アクセシビリティ権限の要求と同意率の異常
    • 署名者の不一致や急激なアップデート配信の増加
    • 新規インストーラアプリ（パッケージインストーラAPIの濫用）

• ネットワーク・検知

  • 第三者ストアの更新CDN/リポジトリへのアクセスをカテゴリ化し、プロキシで観測・制御します。ゼロトラスト方針に合わせ、リポジトリ単位の通行許可モデルを検討します。
  • FCM/HTTPSベースのC2を前提に、SNI/JA3や振る舞い相関で未知の常時通信を可視化します。

• 自社モバイルアプリ（開発者として）

  • 代替決済を採用する場合、PSPのPCI適合性・3DS対応・SDKの脆弱性対応SLAを契約で詰めます。アプリ内WebViewのカード入力は避け、可能ならTrusted Web Activity等でブラウザコンテキストへ退避します。
  • アプリ実行環境の健全性検証（例：アプリ整合性検証API等）を導入し、配布源に関わらず不正実行を抑止します。ライセンスやサブスク認可はサーバ側で最終判断します。
  • 署名鍵のHSM保管・二人承認・鍵ローテの計画を策定します。第三者ストア向けにAPKを配布する場合でも、デバッグ情報混入や過剰権限を排除します。

• インシデント・演習

  • 「第三者ストアのバックエンド侵害」や「偽ストアの拡散」を想定した机上演習を実施し、検知からユーザー告知・封じ込め・回復までのSOPを整備します。
  • 顧客・従業員向けコミュニケーション雛形（どのストアを推奨/非推奨とするか、権限付与時の留意点）を用意します。

• スレットインテリジェンス

  • 新興ストアのカタログと審査基準、過去の不正流通インシデントを継続モニタリングし、社内「ストア信頼レジストリ」を運用します。
  • マルウェア系譜（特にオーバーレイ型/バンキング型/サブスクリプション詐欺）のTTP更新をトラッキングし、YARA-L/シグネチャを継続更新します。

最後に温度感を一言でまとめます。これは「すぐ閉めろ」という話ではなく、「どう開いて、どう見張るか」という設計の話です。配布・更新・決済のそれぞれで、責任の置きどころと可視化のやり方を作った組織が、競争と安全の両方を取りにいけます。

参考情報

• EFF: Challengers Approach — Third-Party App Stores Arrive on Google Play（2026-10）

※本稿は現時点の報道に基づく分析で、正式ポリシーや実装は今後の公開情報により変動する可能性があります。推測・仮説はその旨を明示しており、確定情報は一次資料の更新を待つ必要があります。