EU、Androidのマイク・カメラ・画面アクセスを競合AIアシスタントに開放命令——端末の“耳・目・手”をどう守り直すか

今日の深掘りポイント

• 規制は「機能同等性」を要求しており、第三者アシスタントがGoogle純正と同等のOSレベル権限（マイク常時待機、画面上コンテキスト取得、バックグラウンド操作、ウェイクワード等）へ到達する設計になります。
• これはアプリの話ではなくOSの境界再設計の話で、音声・視覚・操作という3系統の収集面が一挙に広がるため、モバイル攻防は「パーミッション運用」から「役割ベース特権のリスク工学」へ軸足を移す必要があります。
• 実現性と信頼性が高い一方、発効は即日ではなく段階的です。日本企業は「早期の設計・購買・運用方針の更新」を前倒しし、Android 18の動向を前提にモバイル統制を再定義する好機です。
• セキュリティ論点は技術だけでなく調達・法務・ガバナンスにまたがります。特にデータ流通（音声・画面内容）と欧州法域での処理要件を織り込んだベンダー選定が肝になります。

はじめに

欧州委員会がデジタル市場法（DMA）に基づき、Googleに対しAndroid上のAIアシスタント機能を競争相手へ開放するよう命じました。対象はマイク・カメラ・画面上の情報やバックグラウンド操作、ウェイクワード等、事実上「Gemini相当の実行面」です。実装はAndroid 18での対応とし、2027年8月1日までの順守が求められています。Googleは端末セキュリティへの影響を懸念し反発しています。

この決定は競争政策のニュースに見えて、実のところモバイルの攻防面を再定義するイベントです。OSに統合された“耳（マイク）・目（カメラ/画面）・手（操作）”を第三者が握る可能性が開くからです。読者の皆さんにとっては、MDMのポリシー1枚で解ける話ではなく、開発・運用・調達・法務を巻き込んだ再設計の入口になります。

出典としては、当該命令の報道とDMAの一次テキストを確認しています。詳細な実装仕様は今後のAndroid側ドキュメントの公開を待つ段階です。The Hacker Newsの報道と、DMAの公式条文集約であるEUR-Lex（Regulation (EU) 2022/1925）を参考にしています。

深掘り詳細

事実関係（何が決まったのか）

• 欧州委はDMAを根拠に、Android端末上でのAIアシスタント競争を促進する目的で、Googleに対し以下のOSレベル機能の第三者開放を命じました。
  • マイク（常時待機を含む音声トリガの取り扱い）
  • カメラ
  • 画面上の文脈取得やオーバーレイ連携
  • バックグラウンド操作や起動連携
  • ウェイクワード（ホットワード）検出
• 実装対象はAndroid 18で、遵守期限は2027年8月1日です。Googleは端末セキュリティ上の懸念を表明しています。
• DMAはゲートキーパーに対して、OS/ハードウェア機能への差別的アクセスを是正し、相互運用性や機能同等性を確保する義務を課す枠組みです。条文は包括的で、OSに統合されたインターフェースの第三者利用を妨げないことが大枠として求められます。
• 参照:
  • 報道: The Hacker News
  • 法令テキスト: EUR-Lex: Digital Markets Act (Regulation (EU) 2022/1925)
  • 現行Androidの音声基盤API（参考・既存仕様）: VoiceInteractionService

インサイト（なぜ重要か）

• 特権の“質”が変わるから重要です。単なる録音・撮影パーミッションの付与ではなく、「OSに常駐し、ユーザー操作に割り込み、文脈を理解し、起点となるイベントを自ら生成できる」役割の開放になります。これはアプリ権限モデルでは扱いきれない権限の集合で、設計・審査・監査を役割ベースに再定義する必要があります。
• 攻撃面の連動が強化されます。音声（会議、生体音）、画面（チャット/CRM/設計図面/認証コード）、操作（自動化・誘導）が同じ主体に集約されることで、個々は許容でも組み合わせで高リスク化します。DLPやEDRが「単系統監視」を前提にしていると取りこぼします。
• グローバル影響は不可避と見ます。法域限定の要求でも、OSベンダやOEMはビルド・サポートコストの観点からグローバル実装を選ぶ場合が多いです。結果として日本企業の端末にも波及する可能性が高く、早期準備がコスト最適です。
• セキュリティ対策の主戦場は「許容する第三者アシスタントの選定と契約、OSロールの割当管理、権限行使の可観測性確保」に移ります。MDMのランタイム権限制御だけでは粒度が粗く、アシスタント特権のライフサイクル（導入・更新・廃止）を跨ぐガバナンスが求められます。
• 推測として、Googleは新たに「アシスタント・ロール」の設計を強化し、審査・署名・サンドボックス・UIインジケータ（録音/録画/画面取得の強制表示）・強制ログ出力などの安全策をセットで提示するはずです。これにより第三者開放と端末安全性の両立を図る道筋が現実的になります。

脅威シナリオと影響

以下は仮説に基づくシナリオです。MITRE ATT&CKの戦術カテゴリに沿って、実装開放後に起こり得る動きを整理します。

• シナリオ1: 悪性または汚染されたサードパーティAIアシスタントの常時待機化

  • 初期侵入（Initial Access）: 正規ストア配信だが更新で悪性化、あるいはサプライチェーン改ざんで導入されます。
  • 永続化（Persistence）: アシスタント・ロールによりブート時起動、ホットワード待機で常駐します。
  • 権限昇格/防御回避（Privilege Escalation/Defense Evasion）: ロール特権に包摂される形で録音・画面取得のユーザー合意フローを最小化します。
  • 収集（Collection）: 音声録音（Audio Capture）、画面キャプチャ（Screen Capture）、クリップボードや通知の内容取り込みを連続実行します。
  • 流出（Exfiltration）: 音声解析やトランスクリプト同期名目でクラウドへ常時送出します。
  • 影響（Impact）: 会議/設計情報の漏えい、役員レベルの会話盗聴による恐喝や取引妨害が起きます。

• シナリオ2: 善良なアシスタントのゼロデイ悪用

  • 初期侵入: アプリ自体は正規ですが、ホットワード検出モジュールやスクリーンコンテキスト機能の脆弱性をリモート悪用します。
  • 権限昇格: OS間IF（Binder/Permissions Broker）の不備やOEM実装差で特権に到達します。
  • 収集/流出: 正常通信に偽装して高頻度の音声・画面データを抽出します。
  • 影響: 発覚が遅れ、長期の静かなスパイ活動になります。

• シナリオ3: 画面オーバーレイと音声誘導の組み合わせによる認証突破

  • 初期侵入: 善意アシスタントに付随するアドオン/連携アプリが導線になります。
  • 誘導/収集: オーバーレイで「認証コード貼付」や「許可ボタン」の誤タップを誘導し、同時に音声入力で追加情報を引き出します。
  • 影響: SSO/MFAの突破、支払や承認ワークフローの乗っ取りが生じます。

• シナリオ4: コンテキスト取得のログ不備を突いた不可観測な流出

  • 防御回避: 権限行使が統計ログに残らないUIパスやコンテキストAPIを悪用します。
  • 影響: 監査証跡が薄く、インシデント後の範囲特定が困難になります。

• MITRE ATT&CK観点の要点

  • 初期侵入: アプリ配布（User Execution/Malicious App）、モバイルではストア改ざん・サイドロードが典型です。
  • 永続化: 自動起動、常時音声待機、JobScheduler等のスケジューラです。
  • 権限昇格/防御回避: アクセシビリティ乱用、OSロールの誤設定、オーバーレイの悪用です。
  • 収集: Audio/Screen/Input Captureの三位一体です。
  • 流出: 暗号化チャネルでの継続送出、CDN/C2偽装です。
  • 影響: 情報漏えい、認証突破、恐喝・競争優位の毀損です。

総合的に見て、実現性と信頼性は高く、緊急性は中程度ですが、影響の幅と深さは大きいです。期限が先だからこそ、設計・調達・運用の再構築を前倒しで行うべきフェーズに入ったと言えます。

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

期限までの長いマラソンを、フェーズドで走り切る前提で設計・運用・調達の三面から準備します。

• 0〜30日：方針確立と可観測性の土台作りです。

  • 横断チーム発足です（セキュリティ、モバイル運用、法務/プライバシー、購買、開発）です。
  • アシスタント機能の資産棚卸しです（既存の音声入力、CC/コンタクトセンター連携、業務アプリとの音声機能）です。
  • テレメトリ計画です。Android Enterpriseのランタイム権限ポリシー・アプリ許可状態の収集、オーバーレイ/アクセシビリティの許可アプリ一覧をMDMで可視化します。

• 30〜90日：統制の設計と試験運用です。

  • アシスタント許容モデルを定義です（許可リスト方式、業務/個人領域での差別化）です。Work Profileでは音声起点のトリガを原則無効、必要時のみ指定アプリに限定します。
  • 権限の最小化です。MDMのRuntime Permission PolicyでRECORD_AUDIO/CAMERA/POST_NOTIFICATIONS/READ_CLIPBOARD等をデフォルト拒否、指定アプリのみ自動許可です。
  • オーバーレイとアクセシビリティの許容範囲を役割ベースで明文化し、MDMのアプリ制限と組み合わせます（“draw over other apps”とアクセシビリティサービスは原則ブロック、業務必須のみ許可）です。
  • ネットワーク許可リストです。アシスタントの推論・同期先FQDN/IPを明示し、モバイルVPNやPrivate DNSと連動した送信制御を設計します。
  • 監査要件の草案です。録音/録画/画面取得のイベント化（ユーザー通知と管理者ログ）、アシスタントのバージョン固定/更新審査のプロセス定義です。

• 90〜270日：強度評価と運用定着です。

  • レッドチーミング/パープルチーミングで「音声・画面・オーバーレイ連動」攻撃の演習を実施します（MITRE ATT&CKのCollection/Exfiltration軸に沿ったシナリオ）です。
  • ベンダー審査です。第三者アシスタント候補に対し、データ所在・オンデバイス処理割合・保持期間・監査ログ提供・侵害時通知・生成AI安全策（プロンプト/出力検査）の条項をRFPに織り込みます。
  • 監査とDPIA更新です。GDPR/EU域内処理の要否、録音・画面データの機微性に応じたPIA/DPIAを再実施します。

• 具体的な技術ガードレールです。

  • Work Profileでの「Assist & Voice入力」経路を原則無効化、または業務許可アプリに限定します（ベンダの提供するMDM設定で代替策を検討）です。
  • Android Enterpriseの「権限自動付与/拒否」ポリシーを活用し、音声・カメラ・通知・クリップボードは原則拒否、許可アプリのみ付与です。
  • オーバーレイ（SYSTEM_ALERT_WINDOW相当）とアクセシビリティサービスの許可アプリを厳格な許可リストで運用します。
  • ネットワーク監視では、音声/画面の同期パターンに合わせた送信量・時間帯異常を検出します（深夜時間・会議非稼働時間の高頻度アップロード）です。
  • 端末側の「録音/録画インジケータ」が常時点灯しやすくなるため、ユーザー教育を強化し、異常点灯の報告フローを短縮します。

• インシデント対応プレイブックです。

  • 「アシスタント起因の情報流出」プレイブックを独立整備し、即時措置（Work Profile停止/ワイプ、当該アプリのブロック配信、ネットワーク遮断）、範囲特定（権限行使ログ、アプリバージョン、通信先）、規制当局/取引先通知の判断基準を定義します。

• 調達/契約の見直しです。

  • AIアシスタントや音声インフラ調達に「オンデバイス処理優先、最小収集、エッジ保持、暗号化、監査ログ外部提供、サードパーティ監査（SOC 2/ISO 27001）必須」などの条項を標準化します。
  • 欧州法域を跨ぐ利用に備え、データ移転・準拠法・監査の立ち入り権限を明記します。

最後に、これは“待ちのテーマ”ではありません。期限が先でも、要件はOS/運用/契約の三層に広がるため、設計を前倒しするほど移行コストは下がります。Android 18の開発者向け情報が出始めた段階で、すぐにプロトタイプ検証へ移れる態勢を整えておくのが、現場の負荷を最も抑える道です。

参考情報

• 報道: EUがGoogleにAndroidのマイク・カメラ・画面アクセス開放を命令（The Hacker News）: https://thehackernews.com/2026/07/eu-orders-google-to-open-android-mic.html
• 法令テキスト: Digital Markets Act（Regulation (EU) 2022/1925, EUR-Lex）: https://eur-lex.europa.eu/eli/reg/2022/1925/oj
• 参考・既存仕様: Android VoiceInteractionService（開発者ドキュメント）: https://developer.android.com/reference/android/service/voice/VoiceInteractionService

本稿は公開情報に基づき、今後の実装仕様は変更され得ることを前提にした分析です。追加情報が出次第、改めて技術的対策の具体化をフォローアップします。