中国、アプリの生体データを「端末内完結」とする新規制案—越境からエッジ保護へ舵を切る動きです

今日の深掘りポイント

• 生体データの「原則オンデバイス・原則送信禁止」という設計要件は、クラウド中心のKYCや不正検知の常識を覆し、エッジ推論とローカル暗号化の実装競争を加速させます。
• 規制は大量漏えいの母集団となるサーバ側リスクを抑えますが、対価として端末側マルウェアやサプライチェーンSDK経由の抜け道が主戦場になります。
• 端末内完結はパスキー等の非伝送型認証と整合的であり、IDベリフィケーションは「サーバ審査」から「端末内信頼性検証＋真正性証明」へ重心が移ります。
• 運用面では「サーバ監視の目」が届きにくくなるため、オンデバイスの改ざん検知、ルート化・脱獄耐性、動的計測がSLOの一部になります。
• グローバル提供者は「中国向けビルド（データフロー別設計）」の準備が避けられず、越境データ・第三者SDK・ログ設計の棚卸しが直ちに必要です。

はじめに

生体情報は便利さの象徴でありながら、一度こぼれると取り返しがつかない「最終識別子」でもあります。中国が示した新しい規則案は、そんな生体データを端末の中で閉じ切ることを原則とし、外への送信は基本認めないという強いメッセージです。世界最大級のデジタル市場がクラウドからエッジへ基準線を引き直すことは、ただの技術選択ではなく、攻守の地図を塗り替える政策的シグナルでもあります。今日は、その実務と脅威の重心移動を、現場の目線でほどいていきます。

参考情報として現時点で公表されている報道は以下のとおりです。提案はパブリックコメントを2026年2月9日まで受け付けるとのことです。詳細の最終文言や適用範囲・例外規定は今後の確定版で変動しうるため、以下の分析には明示した仮説を含みます。

• Biometric Update: China proposes new biometric data rules for app makers

深掘り詳細

事実関係（現時点で報じられている内容）です

• アプリが収集する生体データについて、インターネット経由での送信を原則禁止し、端末内保存を義務付ける規則案が提示されています。
• 生体情報の収集は特定の目的と必要性を要し、ユーザー同意が必須とされています。
• 意見募集は2026年2月9日まで受け付けられます。
• これらはアプリ開発者に対する遵守事項として提案されており、最終確定に向けたパブコメ段階の情報です。 （出典は上記リンクの報道です）

インサイト（技術・運用の重心移動、設計・市場インパクト）です

• クラウド審査からエッジ審査へ
  • これまで「顔/声の生体KYCや高精度ライベネス判定」をクラウドで実施してきた事業者は、オンデバイスでの推論・検証に切り替える必要が生じます。高精度ライベネス（3D/IR/テクスチャ解析）を端末内で成立させるため、モデルの軽量化、端末ハードウェア機能（セキュアエンクレーブやハードウェア鍵）活用、推論の再現性と改ざん耐性の両立が新たなKPIになります。
• 「パスキー文化」との親和性
  • 生体テンプレートを外へ出さないという思想は、そもそもサーバ側へ生体を渡さない非伝送型認証（例：端末内の秘密鍵を生体でアンロックし、サーバには署名のみ伝える）と親和的です。サインインや決済認証はこの路線で質を上げやすい一方、本人確認（IDベリフィケーション）やリスクスコアリングは設計の再定義が要ります。
• セキュリティのトレードオフが移動する
  • サーバ保管や越境送信が減ることで大規模漏えいの母集団リスクは低下します。一方で、攻撃者は端末内の一時ファイル、キャッシュ、特徴量、モデルの中間表現を狙うようになり、モバイルマルウェア、フッキング、サプライチェーンSDKが「一番の近道」になります。監視の目がクラウドからエッジに移る分、観測と証跡の設計が難しくなります。
• 市場分断とプロダクトの二層化
  • 中国域内向けは「オンデバイス完結」設計、域外はクラウド併用設計、という二層アーキテクチャが現実解になります。コードベース、SDK、ロギング、A/Bテスト、モデル更新手法に至るまでガバナンスを分ける必要があり、プロダクト運用コストが上がります。
• 実務への示唆（メトリクスからの読み解き）
  • 信頼性は高く、実施される可能性も高めに見える一方、現場の「いますぐ変える」性質は限定的で、設計とコンプラの仕込みが先行課題になります。準備の先手を打てば、移行コストを平準化できる見通しです。

脅威シナリオと影響

以下は、規則案が想定する「端末内完結」前提における脅威シナリオの仮説です。MITRE ATT&CKのタクティクスに沿って要点を整理します（具体的なテクニックIDは環境依存のため、ここでは戦術レベルでの整理に留めます）。

• シナリオ1：端末内での生体データ窃取（モバイルマルウェア/悪性SDK）です

  • 想定手口
    • 初期侵入（Initial Access）：不正広告SDKやサプライチェーン経由のアップデート差し替え、フィッシングによる不正アプリ導入です。
    • 収集（Collection）：カメラ/マイクのセンサーデータ、処理中の一時ファイル、特徴量（エンベディング）やライベネス推論ログの吸い上げです。
    • 防御回避（Defense Evasion）：暗号化されたチャネルや正規トラフィックへの偽装、難読化や動的ロードでの検知回避です。
    • 流出（Exfiltration）：C2への断続的アップロード、サーバ送信禁止を回避するためのステガノグラフィ風パケット化です。
  • 影響
    • サーバ側の大量漏えいは減る一方、広範な端末分散漏えいが表在化します。個別端末の事後調査が難しく、早期検知はモバイルEDR/MTDとアプリ内計測の設計力に依存します。

• シナリオ2：ライベネス/本人性検査のバイパス（フッキング/コードインジェクション）です

  • 想定手口
    • 権限昇格（Privilege Escalation）や防御回避：ルート化・脱獄によりデバッグ保護を解除し、カメラ入力ストリームやモデル推論結果を改ざんします。
    • 収集/影響（Collection/Impact）：事前に生成したディープフェイクのフレームを仮想カメラやメモリインジェクションで注入し、オンデバイスのKYC審査をすり抜けます。
  • 影響
    • 本人確認の信頼性が低下し、アカウント開設やハイリスク取引での詐欺コストが跳ねます。クラウド側の二次検証が使いにくくなるため、端末側真正性証明（デバイス健全性・アプリ整合性）の重要度が増します。

• シナリオ3：テンプレート/特徴量のオフライン復元・再識別です

  • 想定手口
    • 収集：アプリが持つローカルの特徴量・テンプレート（設計により存在）やキャッシュの抽出です。
    • 防御回避：鍵管理の脆弱性を突き、ハードウェアバックドキーを回避、もしくはデバッグインターフェースの悪用です。
  • 影響
    • 生体データの不可逆性ゆえ、長期的なプライバシー被害に直結します。テンプレートや特徴量を「非生体」扱いして緩く保護すると、規則の想定からも逸脱しうるため、設計段階で最も厳しい分類を適用すべきです。

• シナリオ4：コンプライアンス回避としての偽装分析送信です

  • 想定手口
    • 防御回避/指揮統制（Defense Evasion/C2）：トラッキングや品質改善と称して、特徴量や疑似再構成可能な派生データを「非生体」と位置付けて送信します。
  • 影響
    • 規制違反リスクと、ブランド毀損の二重打撃になります。監査対応での説明責任が強く問われます。

総じて、クラウド一極の大量漏えいリスクを削りつつ、端末側の「小さな穴」を潰す戦いに移る構図です。検知・阻止の重心をどこに置くかを、設計と運用で再配置する必要があります。

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

• データフローの再設計（中国向けプロファイル）です

  • 生体データの生成・処理・保存・廃棄の各ポイントをデータフローダイアグラムで可視化し、「ネットワーク越しに出ない」を満たす経路に張り替きます。
  • 例外要件が後日定義される場合に備え、機能フラグで送信経路を物理的に排除できる構造を用意します（ビルド時・実行時の両面）です。

• オンデバイス完結を成立させる暗号・実行基盤です

  • ハードウェアバックドキーとセキュアエンクレーブ/TEEを必須化し、テンプレート・特徴量・ライベネス中間データは暗号化＋最小期間の揮発運用にします。
  • デバッグビルドやリリースビルドで暗号鍵の取り回しが変わらないよう、鍵管理のパイプラインをCI/CDで固定化します。

• 改ざん・不正端末の排除です

  • ルート化・脱獄検知、フッキング/仮想化検知、環境アテステーション（端末健全性・アプリ整合性）、改ざん耐性をアプリに組み込みます。
  • カメラ/マイク入力パスの真正性を検証し、仮想カメラやフレームインジェクションの兆候を検出するローカル検査を実装します。

• ライベネスと本人性の再設計です

  • サーバ側の高負荷推論に頼らず、端末内の多要素（動作・深度・赤外・反応時間など）を組み合わせたローカル評価を標準化します。
  • 認証は「生体は鍵アンロックにしか使わない」非伝送型設計を基本とし、本人確認（KYC）は端末内評価＋真正性証明（健全性・署名）で補強します。

• ログと可観測性の新バランスです

  • 生体データそのものを含まないテレメトリで異常兆候（例：ライベネス失敗パターンの偏り、端末環境の不整合）を検出できるよう、特徴量非依存のメトリクス設計に切り替えます。
  • オフライン時の監査可能性を担保するため、プライバシー保護型のローカル監査証跡と、規約に適合した後送信の設計を検討します（規則の確定文言を要確認）です。

• サプライチェーンの総点検です

  • 第三者SDKのデータ収集・送信挙動を動的・静的に検証し、生体処理経路に関与するSDKはホワイトリスト方式に限定します。
  • ライセンス、SLA、監査権限に「生体データの端末外送信禁止」「派生データの取り扱い定義」を明記します。

• リーガル・プロダクト連携です

  • 目的・必要性・同意の提示文面を見直し、同意は「その場・その目的限定のJIT同意」を基本にします。
  • パブコメ期間中に業界団体等と連携し、運用可能な例外や定義の明確化を働きかけることも検討します。

• 移行ロードマップの現実解です

  • まずは「現行フローの棚卸し→送信経路の遮断→端末内推論のPoC→真正性・改ざん耐性の強化→監査設計」の順で段階導入します。
  • モデル更新は「端末配信・差分更新・署名検証」を前提にし、更新経路の乗っ取り耐性を高めます。

最後に、今回の規則案は信頼性が高く、実現可能性も低くない方向性に見えますが、現場での差し込みは設計・サプライチェーン・運用監査の三位一体が肝になります。サーバ側で積んできたガバナンスの知恵を、端末の中に丁寧に持ち込むこと。それが「端末内完結」の時代における競争力そのものになります。

参考情報

• 報道: China proposes new biometric data rules for app makers | Biometric Update