Statuspageは中国本土で使えるか：到達性・ホスティング・購読者データ

Statuspageの公式ドキュメントが中国について述べていること

事実	一次情報源
Atlassian自身の言葉で：データレジデンシーは"gives you control over where your in-scope app data for Jira, Jira Service Management, Jira Product Discovery, Confluence, and Loom is hosted"（Jira・Jira Service Management・Jira Product Discovery・Confluence・Loomの対象アプリデータのホスト先を制御できる）——Statuspageを含まない一覧です。提供する所在地（オーストラリア・カナダ・EU・ドイツ・インド・日本・シンガポール・韓国・スイス・英国・米国）に中国本土のリージョンはなく、既定では"all Atlassian apps are hosted in the Global location, which includes all of our AWS regions"（すべてのAtlassianアプリは全AWSリージョンを含む「Global」の所在地にホストされる）で、Atlassianは必要に応じてリージョン間でデータを移動します。したがってStatuspageの状態ページはオフショアから配信され、中国本土のホスティングもレジデンシーの選択肢もありません。	Atlassian — Understand data residency、2026-10-07 取得
購読者通知を有効にすると、Statuspageは人々に届くための連絡先を集めます。Atlassianのドキュメントによれば"can send out notifications to your customers via email and SMS"（メールとSMSで顧客に通知を送れる）で、購読者はメールアドレスまたはSMSの電話番号で——一つずつ、CSVインポート、またはAPIで——追加されます。それらのメールと電話番号は個人情報です。中国のユーザーから集め、Statuspageのオフショアのインフラに保持されれば、それはPIPLが規律する越境移転であり——通知、個別の同意、移転メカニズムのいずれか一つ（CACの安全評価、CAC標準契約、または認証）を要します。	Atlassian — Enable subscribers (Statuspage)、2026-10-07 取得；PIPL Chapter III, Articles 38–43
購読者データのリスクは、状態ページを単に運用することではなく、量と役割に応じて大きくなります。CACの2024年3月の越境規則の下では、非CIIOが暦年で10万人未満の非センシティブな個人情報を移転する場合、安全評価・標準契約・認証が免除されます。大きな購読者リストやセンシティブな取り扱いは、その計算を変えます。	CAC — データ越境移転の促進と規範化に関する規定、2024年3月
CIIOまたは大量取扱者には、中国で収集した個人情報を中国本土内に保存しなければなりません（PIPL第40条、CSL第39条（旧第37条））。Statuspageは中国本土のリージョンを提供しないため、中国の購読者の連絡先データを中国の地に保ち——かつ本土の内側から到達し続ける状態ページを配信する——には、その配信と保存を本土のインフラで行うことになり、そこでICP備案が視野に入ります。	PIPL Article 40；CSL Article 39 (formerly Article 37)

情報源は21YunBox コンプライアンスチームが2026年10月7日に確認しました。

中国本土の利用者にとって、Statuspageをめぐる問いは、どれだけ速く描画されるかではありません——肝心なときにそもそもページが読み込まれるか、そして通知する相手の連絡先がどこに行き着くか、です。StatuspageはAtlassianのAWSインフラ上で全面的にオフショアにホストされ、中国本土内のリージョンがなく、JiraやConfluenceと違い、より近くに固定するデータレジデンシーの選択肢もありません。それが二つを露わにします。インシデント中に到達し続けねばならない状態ページが、最も当てにならない瞬間に国境リンク越しに配信されること。そして中国ユーザーから集める購読者のメールや電話番号が、中国のデータ法の下で本土の外に存在すること。Atlassianはその両方を自身の言葉で文書化しています。

中国でのStatuspage：ひと目で

読み込めない状態ページは、ないよりも悪い

状態ページの価値のすべては、製品が落ちてもそれは立っていることにあります。サービスが壊れたと感じた瞬間に顧客が開くページです——そして中国本土の顧客にとって、Statuspageはその瞬間にオフショアから応答します。AtlassianのAWSインフラ上でホストされ、*.statuspage.ioで配信されるため、状態ページは越境経路でしか中国に到達せず、その経路は、現実のインシデントに伴う輻輳・経路の乱れ・ネットワークの負荷——まさにその最中に最も当てになりません。Statuspageが名指しで遮断されるわけではありません。問題は構造的です。本土のユーザーが障害のさなかに読み込めると当てにできないオフショアの状態ページは、単に性能が悪いのではなく、自らの目的を反転させます。説明されるのを見られないインシデントは、彼らには、貴社が隠しているインシデントに見えるからです。ここでの到達性は配信の事実であってコンプライアンスの事実ではありません——が、Statuspageが中国の利用者にそもそも「使える」かを最初に決めるものです。

オフショアにホストされ、本土のリージョンもレジデンシーの選択肢もない

状態ページがどこでホストされるかが、それについて何ができ何ができないかを決めます。Atlassianのデータレジデンシーのドキュメントは、対象データの所在を顧客が固定できるとしますが、その制御を“Jira, Jira Service Management, Jira Product Discovery, Confluence, and Loom”に限定しています——Statuspageは一覧にありません。既定では、Atlassianは“all Atlassian apps are hosted in the Global location, which includes all of our AWS regions”（すべてのAtlassianアプリは、全AWSリージョンを含む「Global」の所在地にホストされる）とし、“dynamically determine where their in-scope data is located, and optimize performance by moving data between these regions as necessary”（対象データの所在を動的に決め、必要に応じてリージョン間でデータを移動して性能を最適化する）とします。そのAWSリージョンのいずれも中国本土にはありません。したがってStatuspageのページは中国から遠いだけでなく——それやそのデータを本土の内側に持ち込む仕組みがありません。

その地理はICP備案も閉ざします。中国の内側から本土の訪問者に配信される公開サイトは、国務院令第292号とMIIT令第33号の下でICP備案（备案）を発動させ、その備案は本土に物理的に所在するホスティングリソースに結びつかなければなりません。オフショアのみのサービスには結びつける先がありません——だからこそ「すでにStatuspageで状態を公開している」は中国には持ち込めません。本土に到達することと、本土の内側からそれを配信する許可を得ていることは別物であり、ページを調整してもその隙間は塞がりません。

購読者の連絡先データは国を出る

純粋に公開の状態ページは、個人データをほとんど運びません。リスクが現れるのは、Statuspageの購読者通知を使う瞬間です。Atlassian自身のドキュメントによれば、Statuspageは“can send out notifications to your customers via email and SMS”（メールとSMSで顧客に通知を送れる）ので、それに必要なもの——メールアドレスとSMSの電話番号——を、一つずつ、CSVインポート、またはAPIで集めます。それらは個人情報です。中国本土のユーザーから集め、Statuspageのオフショアのインフラに保持されれば、それは個人情報保護法（PIPL）の下での越境移転です。取扱者である貴社は——Atlassianの顧客であって、Atlassianではなく——通知を行い、個別の同意を取得し、移転メカニズムのいずれか一つ（CACの安全評価、CAC標準契約、または認証）をクリアしなければなりません。

その義務の重さは、購読者リストと役割に応じて大きくなります。CACの2024年3月の越境規則の下では、非CIIOが暦年で10万人未満の非センシティブな個人情報を移転する場合はそれらのメカニズムが免除され、一方でCIIOまたは大量取扱者は、中国で収集した個人情報を本土内に留めなければなりません（PIPL第40条、サイバーセキュリティ法 第39条（旧第37条））——オフショアのみの状態サービスが満たせない国内保存義務です。

これは判定ではなくリスクの見取り図です。購読者のいない状態ページはおおむね到達性の問いで、購読者通知を加えると越境データの問いにもなります——そしてそれがどこまで及ぶかは、取扱量・役割・何を収集するかによって変わります。構築の前に、専門家と確定させる価値があります。

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

貴社はこれまで通りStatuspageを運用し続けます。当社が加えるのは、オフショアのみのサービスにはできないピースです。すなわち、本土の内側から到達し続ける状態の通知経路——既存の状態ページの前段に置く、ICP備案済みの中国国内からの配信——で、中国ユーザーがまさにそれが報告すべきインシデントのさなかにそれを読み込めるようにします。作り直しも、二つ目のシステムもありません。法が求める場合は、中国の購読者の連絡先データも中国の地に保ちます。当社の中国チームが、貴社の法人と取扱データ量に照らして到達性と購読者データの義務を整理し、合法的な中国拠点に必要な中国国内からの配信と保存を立ち上げます——Statuspageは、すでに動いている場所のままで。

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

---

関連する読み物：

• 中国のICP備案の取得方法
• PIPLの下での越境データ移転

よくあるご質問

Statuspageは中国で遮断されていますか？

完全には遮断されていません。StatuspageのページはAtlassianのAWSインフラ上でオフショアにホストされ、statuspage.ioで配信されるため、原理的には到達できますが越境経路に依存します——状態ページが本来向き合うべき輻輳とインシデントの状況のさなかに、最も当てになりません。実務上のリスクは硬い遮断というより、本土のユーザーが必要とするまさにその瞬間に読み込めると当てにできない状態ページです。

Statuspageを使うことは中国のデータコンプライアンスの問題を生みますか？

それを通じて個人データを集める範囲においてのみです。純粋に公開の状態ページはほとんど運びません。しかし購読者通知を有効にすると、Statuspageは購読者のメールとSMSの電話番号を集め、中国本土のリージョンのないオフショアのインフラに保持します——PIPLが規律する個人情報の越境移転です。国内保存義務にも直面するかは、貴社の役割（たとえばCIIOか否か）と取扱量によります。一律の禁止ではなく、専門家と確認すべきリスクとして扱ってください。

21YunBoxは、Statuspageの構成を中国向けに使えるようにする手助けができますか？

はい。当社の中国チームが、貴社の取扱データ量と役割について到達性と購読者データのリスクを評価し、状態の通知のための法令適合のICP備案済み中国国内配信経路を——そして法が中国の購読者の連絡先データを本土に留めよと求める場合は中国国内保存も——立ち上げます。Statuspageからの乗り換えなしに。個別のケースを一緒に整理しますので、お問い合わせください。