中国向けFirebaseソリューション：ICP、PIPL、そして「動かす」に本当に要るもの

Firebaseを中国本土で動かす方法をチームが探しているなら、問題が実際に何なのかを明確にする価値があります。反射的に、これはパフォーマンスの問題——Googleのサーバーへの速い経路を見つければ悩みは消える——と扱いがちです。消えません。障害はそもそも距離ではなかったからです。FirebaseはGoogle Cloud上に築かれたGoogleのサービスで、Google Cloudは中国本土の内側にリージョンも、別個の中国国内パーティションも運用しません——したがって、そもそも速くすべきFirebaseのエンドポイントが国境の中国側に存在しません。本物の解法が確定しなければならないのは二つのライセンスの問いです。公開アプリが中国のICP制度の下で備案できるか、そして中国ユーザーの個人データがどこに置くことを許されるか。到達性は重要ですが、その両方の下流にあります。

中国本土でのFirebase——ひと目で

到達性は現実だ——それでも関門ではない

これはどれも、到達性が架空だという意味ではありません。FirebaseはGoogleのネットワークから配信するように作られ、そのネットワークは本土の端で止まります。Googleのエンドポイントは中国の内側から日常的にフィルタされるか不安定で、一部のFirebaseの機能は、本土の端末が備えないGoogleの端末レイヤーを前提とします。FirebaseのAndroidガイド自身が、メッセージングのクライアントを“that also have the Google Play Store app installed”（Google Play Storeアプリもインストールされた）端末で動かすことを要求します——本土の多くで販売される端末が出荷時に備えないストアです——そのため、プッシュとその上に築かれた機能は、ネットワークをどう整えても一度も発火しないかもしれません。

しかし到達性は、人を惑わせる半分です。即座に返ってくるFirebaseの呼び出しも、配信している相手を、配信している場所から配信してよいかについては何も語りません。その許可は二つの別々の関門であり、どちらも速度の問題ではありません。

関門その一——公開アプリとそのICP備案

関門その一は、そもそもアプリを見せる許可についてです。本土のユーザーに向けた公開のWebサイトやアプリは、国務院令第292号とMIIT令第33号の下でICP備案（备案）を担わなければならず、その記録は、オフショアのFirebaseスタックが中国側に持たない二つのもの——本土内に物理的に所在するホスティングリソースと、その背後の中国本土の法人——に結びつきます。FirebaseのホストはGoogle Cloudのオフショアのリージョンで——Googleは“43 global regions and 130 zones”（43のグローバルリージョンと130のゾーン）を公表し、本土に最も近いのは香港です——備案が名指す中国国内の先がありません。アプリは完全に到達できても、そこにいる許可を持たないことがあり、Googleへの速い経路はそれを変えません。

関門その二——PIPLの下の中国ユーザーのデータ

関門その二はデータについてです。記録が物理的にどこに置かれるかは、データベースを作る瞬間に決まります。Firebaseは“must choose a location for the instance”（インスタンスのロケーションを選ばなければならない）とし、“once you provision a database instance, you cannot change its location setting”（データベースインスタンスを一度プロビジョニングすると、そのロケーション設定は変更できない）と警告します。Firebaseが提示するすべてのロケーションが本土の外にあるため、中国ユーザーの個人情報は最初のサインアップからオフショアに保存されます——そして本土の居住者の個人データを国境の向こうへ運ぶことは越境移転です。中国の個人情報保護法（PIPL）（英語）はこれに条件を付けます。通知、個別の同意、そして承認された移転メカニズムのいずれか一つ（第38〜43条）。重要情報インフラ運営者、または規制された量を超える取扱者の場合、データはそもそも本土に留めなければならないかもしれません（PIPL第40条、サイバーセキュリティ法 第39条（旧第37条））。これらのどれがどう効くかは、役割と数字によります——既定の設定ではなく、専門家の判断です。

中国向けの本物のFirebaseソリューションはどう見えるか

速度ダイヤルではなく二つの関門として捉えると、正直な解法のセットは短くなります——そしてそのどれも、Googleへのより速い経路ではありません。

Firebaseをグローバルのオリジンとして保つ。 本土の外のユーザーには、何も変える必要はありません。Firebaseは優れたグローバルバックエンドです。中国の作業は付加的です。本土の利用者が見る体験の前段に、法令適合のICP備案済みの拠点を中国本土の内側に立て、公開アプリが備案される中国国内の土台を持つようにしつつ、オリジンは今日動いている場所のままにします。

Google依存のピースは、それぞれの条件で扱う。 Firebaseのうち、Googleの端末レイヤーに寄りかかる部分——Cloud Messagingと、Google Play servicesの上に築かれたもの——は、ネットワークをどう整えても、本土の大半のユーザーが持つ端末には確実には届きません。それら特定の機能について、持続する答えは、その一つの能力の中国国内の代替（たとえば本土のプッシュサービス）であり、Firebaseのコードの残りは手つかずにします。代わりに全面的な乗り換えを検討しているなら、姉妹記事中国向けFirebaseの代替（英語）が、候補のバックエンドにこの同じ二つの関門を当てはめています。

出荷前に、中国ユーザーのデータをどこに置けるか決める。 Firestoreのロケーションは作成時に設定され、あとから動かせないため、データの国内保存は前もって確定するのが最も安上がりです。アプリによっては、PIPLの移転メカニズムを伴うオフショア保存が擁護可能で、別のもの——CIIO、または大量取扱者——にとっては、データは本土に留まらなければなりません。それはコンソールに委ねられる既定ではなく、法的な判断です。

これは判定ではなくリスクの見取り図です。どの関門がどれだけ効くかは、アプリが何をするか、どれだけの個人データを保持するか、ユーザーが誰かによって変わります——それを中心に構築する前に、専門家と確定させる価値があります。

21YunBoxの位置づけ——移行ではなく、法令適合のオーバーレイ

Firebaseをグローバルのオリジンかつ信頼できる情報源として保ってください。それが中国本土に残すギャップは、調整で消せるものではありません——Googleのネットワークが保つように作られていなかった、ライセンスを得た中国国内の拠点です。それが当社が加えるピースです。すなわち、すでに運用中のFirebaseオリジンの前段に立つ、法令適合のICP備案済みの中国本土の内側からの配信——作り直しも、並行する中国のコードベースも、Firebaseからの乗り換えもありません。当社の中国チームが、貴社の法人と取扱データ量についてどの関門が効くかを整理し、中国国内のホストに対してICP備案を担い、訪問者とユーザーのデータが国境でどう扱われるかを設計するので、PIPLの問いには擁護できる答えが出ます。機能がGoogleの端末レイヤーに依存するところでは、アプリをその周りで作り直すのではなく、その一つのピースの中国国内の代替を計画するお手伝いをします。

コンプライアンス評価を依頼する（英語） →

関連する読み物：

• 中国のICPライセンスとは何か、どう取得するか
• PIPLの下での越境データ移転（英語）
• 中国向けFirebaseの代替：二つのコンプライアンスの関門（英語）