Djangoは中国本土で使えるか：データの国内保存、ICP、越境ルール

中国本土のオーディエンスにとって、Djangoについてまず押さえるべきは、問いが「読み込まれるか」ではなく、そもそもDjangoそのものについてのものでもない、ということです。DjangoはオープンソースのPythonウェブフレームワークです——パッケージインデックスからインストールし、貴社自身のアプリケーションの内側で、展開先のサーバー上で動かします。それ自体はデータの所在に中立なコードです：自前のデータを持たず、どこにも通信を送り返しません。北京のデータセンターでもフランクフルトのそれでも同じように動きます。だから「Djangoは中国で使えるか」は、別の問い——デプロイとデータの問い——に解けます：アプリはどこで動くか、そのデータベースはどこにあるか、そして中国の利用者から収集する個人情報は、国外にあるインフラに達するために国境を越えるか。その国境越えこそがコンプライアンスの事象です——ラウンドトリップの時間でも、フレームワークでもありません。

中国でのDjango：ひと目で

フレームワークは動かした場所で動く——だからデプロイがデータの所在を決める

Djangoがどこで動くかから始めましょう。問い全体がそこに乗っているからです。Djangoは貴社自身のコードベースに追加するフレームワークです：そのホームページはこれを「迅速な開発を促す高水準のPythonウェブフレームワーク」と呼び、「無料かつオープンソースである」と注記します。接続すべきホスト型のDjangoはなく、選ぶべき中国国内のリージョンもありません——フレームワークは、貴社が展開するどのアプリケーションの内側でも実行され、それは本土のサーバー上にも他のどこと同じように載せられます。その意味でDjangoは、遮断された消費者向けサービスとは違う形で中国から到達でき、使え、完全に国内で動かせます。

それはまた、Djangoが貴社のデータ所在のあり方を決して定めない——貴社のデプロイが定める——ことを意味します。二つの選択が重みを担います。一つ目はホストです。本土の利用者に配信するアプリは、ICP備案を担うホスティングリソース上で動かすべきで、そのシステムは、国内の情報システムの運営者としてMLPS（等級保護）の義務を負います。本土の利用者がアクセスするオフショアの仮想マシンこそが本当のリスクであり——それはデプロイの決定であって、Djangoの性質ではありません。二つ目の選択はデータベースで、そこがデータの実際の住処です。

データベースと管理画面が個人データを保持する

Djangoのリクエストは中立なテキストではありません。Djangoは設計上「バッテリー同梱」だからです。箱から出した状態でユーザー認証システムと組み込みの管理インターフェースを同梱するので、アプリを立ち上げた瞬間に、ユーザーアカウント、ハッシュ化パスワード、セッション記録、そしてモデルが定義するあらゆるフィールドを保存しています。Django自身のドキュメントは、*「次のデータベースを公式にサポートする：PostgreSQL、MariaDB、MySQL、Oracle、SQLite」*と明示します——ORMはデータを記述するデータベース非依存の方法を与えますが、エンジンと、決定的に、それが動くサーバーは貴社が選びます。フレームワークはデータの形を決めますが、データがどこにあるかは決めません。

それが効くのは、データベースとDjangoの管理画面こそ、個人情報が集まる場所だからです。アプリの管理URLにある管理サイトは、あらゆる記録——ユーザーアカウント、連絡先、注文、モデルが保持するものすべて——への直接のコンソールです。中国の利用者が個人情報を送信し、貴社のアプリがそれを本土の外にホストされるデータベースに書き込んだ瞬間、その書き込みは中国の個人情報保護法（PIPL）の下での越境移転です。PIPLはその義務を取扱者——貴社——に課します：第38〜40条は通知、個別の同意、そして移転メカニズムのいずれか一つ（CACの安全評価、CAC標準契約、または認証）を求め、第28条は、データが機微な場合——政府発行ID、財務、健康、生体情報、または未成年者の情報——に、強化された義務を加えます。そして組織が重要情報インフラを運営する場合、または個人情報を大規模に取り扱う場合、サイバーセキュリティ法（英語）はデータ国内保存の義務を加えます——第39条（旧第37条；2026年1月1日施行の2025年改正によって繰り下げられ、実質は変わりません）は、そのような運営者が国内で収集・生成した個人情報を国内に保存すること、そして輸出の前に安全評価を行うことを求めます。

依存関係とテレメトリは既定でオフショアに達する

フレームワークのページが率直に名指すべき三つ目の筋があります。Djangoのデプロイは貴社のコードだけではありません——貴社のコードに、ビルド時にpipがPyPIから解決する第三者パッケージのツリーを加えたものです。本土で動くビルドやデプロイのパイプラインは、解決のたびにそのインデックスにオフショアで到達するので、貴社のサプライチェーンは日常的に国境を越え、認証情報やトークンを埋め込んだプライベートパッケージもそれとともに越えます。その上、Djangoアプリに一般的に組み込まれるクラッシュレポートと性能テレメトリのエージェント、そしてアプリが実行時に呼ぶあらゆる第三者APIは、それらのサービスがホストされる場所——しばしば国外——へペイロードを送ります。これらはいずれもDjangoを使わない理由ではありません。単に、ユーザーデータベースの先にある二つ目の面であり、パイプラインとそれらの呼び出しを意図的に国内に保たない限り、データと依存関係が国を出る場所です。

なぜ到達性チェックはこれを見落とすのか

到達性やレイテンシのテストは、エンドポイントにpingを打ち、応答するか、どれだけ速いかを報告します。Djangoにとって、そのテストは誤った問いに答えます。第一に、pingを打つべき「Djangoのエンドポイント」はありません——フレームワークは貴社のアプリの内側で動くので、pip installの青信号や高速に描画されるページは、アプリとデータベースがどこに落ち着くかについて何も教えません。第二に、コンプライアンスを実際に決めるものはプローブには見えません：ホストがICP備案を担いMLPSの義務を満たすか、データベースが本土にあるか、そこへ越える個人情報が機微または「重要データ」か、そして依存関係のプルとテレメトリが国外へ経路するか。これらはデプロイと法律の事実であり、ネットワークの事実ではありません。それが、純粋な速度や到達性の見方では供給できない半分であり——当社が先頭に置く半分です。

合法的な経路——map・localize・deliver

オープンソースのフレームワークについて、21YunBoxの役割は的を絞ったものであり、率直に申し上げます：売りつける「国産Django」などありません——フレームワークはすでに貴社が動かせるものであり、国内でもそうです。当社の価値は三つの動きにあります。

まず、リスクを**map（整理）します：貴社のDjangoアプリが実際にどこに展開されているか、データベースがどこにあるか、モデルと管理画面がどんな個人情報を保持するか（そのいずれかが機微または「重要データ」か）、そしてどの依存関係のプル・テレメトリのエージェント・第三者APIが国外へ経路するか——そのすべてを、ホストにかかるICP／MLPSの義務、PIPLの越境ルール、第28条、サイバーセキュリティ法に照らして整理し、貴社と専門家がガードレールを設定できるようにします。次に、合法的に国外に置けないもののlocalize（国内化）を支援します：DjangoアプリをICP備案済みでMLPSに適したインフラ上で国内で動かし、中国の利用者の個人情報を本土に所在するデータベースに保ち、依存関係をビルドのたびにオフショアに達するのではなく国内のインデックスから解決します。これは中国で合法的な足場であって、ルールを出し抜く経路ではありません。第三に、貴社の中国向けの画面——本土の利用者がアクセスするアプリとAPIのエッジ——を、ICP備案済みの中国国内のインフラ（21YunBox Optimizer）で、すでに運用中のスタックの前段に、作り直しも二つ目のコードベースもなくdeliver（配信）**します。

21YunBoxは移行ではなく法令適合のオーバーレイであり、貴社が使うツールへの競合ではなくパートナーです。21YunBoxはいかなる種類の不正な手段も用いず、また推奨しません。 その結果は、中国の利用者に対して合法かつ法令適合に稼働する構成です。

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

関連する読み物：

• 中国のICP備案の取得方法
• PIPLの下での越境データ移転
• 中国の個人情報保護法
• 中国のサイバーセキュリティ法（データ国内保存、第39条）（英語）

関連テクノロジー

Bun

Bun

Deno

Deno

Laravel

Laravel

Node.js

Node.js

Ruby on Rails

Ruby on Rails

Spring Boot

Spring Boot