dbtは中国本土で使えるか：データの国内保存、ICP、越境ルール
dbtは変換レイヤーであり、データウェアハウスの内側でSQLを実行します。したがって中国の問いは、上海から開くかではなく、そのウェアハウスとdbtの実行がどこにあるか、です。dbtのエンジンはオープンソースでセルフホストできる（国内に留められる）一方、dbt Cloudは中国本土のリージョンを持たないSaaSです——到達性ではなく、PIPLの越境とデータ国内保存の問題です。
dbtは中国本土で使えるか
はい——dbtは中国本土から動きますが、それは問いではありません。dbtは変換レイヤーです：データウェアハウスの内側でSQLを実行するため、コンプライアンスの軸は、ツールが上海から開くかではなく、そのウェアハウス——そしてそれに対するdbtの実行——がどこにあるか、です。
dbtのエンジンはオープンソースでセルフホストできます（Apache-2.0ビルド）。これがてこです：中国国内のウェアハウスに対して中国国内で動かせば、中国由来のデータとその変換は国内に留まります。ホスト型のSaaSであるdbt Cloudは中国本土のリージョンを一つも挙げず、プロジェクト、実行ログ、アーティファクト、メタデータをオフショアに置きます——データの構造を地図にするメタデータです。中国由来の個人データをオフショアに着地させること、または重要情報インフラ運営者や大量取扱者（英語）としてそこに保存することは、PIPL（第38〜40条）とサイバーセキュリティ法 第39条（旧第37条）の下での越境とデータ国内保存の問い（英語）であって、到達性の問いではありません。
これは判定ではなくリスクの見取り図です——どの義務が当てはまるかは、貴社の法人、役割、データ量、そしてウェアハウスとモデルが実際に何を抱えるかで変わります。当社の中国チームが貴社のリスクを一緒に整理します →
コンプライアンス・スナップショット
- ! dbtはウェアハウスの内側でデータを変換する——国内保存はウェアハウスの所在で決まる
- ! dbt Cloud（SaaS）は11のリージョンを挙げる——中国本土には一つもない
- ! dbt Cloudはプロジェクト、実行ログ、メタデータをオフショアに保存する
- ! 中国由来のデータがオフショアに着地することはPIPLの越境移転
- ! CIIO／大量取扱者：国内保存——サイバーセキュリティ法 第39条（旧第37条）
- ✓ dbtのセルフホストのエンジンを、中国国内のウェアハウスに対して中国国内で動かす
dbtの公式ドキュメントが中国について述べていること
| 事実 | 一次情報源 |
|---|---|
dbtのエンジンはオープンソースでセルフホストできます——貴社自身の環境にインストールして動かします。dbt Labs自身のdbt-coreリポジトリは “The source code in this repository is available to everyone under the standard Apache 2.0 license,”（このリポジトリのソースコードは、標準的なApache 2.0ライセンスの下で誰でも利用できる）とし、dbtの文書は、オープンソースビルドを貴社自身でインストールし（python -m pip install dbt-oss）、貴社自身のコマンドラインから貴社自身のデータウェアハウスに対して動かすようになっています。エンジンは置いた場所で動くため、中国国内のインフラで中国国内のウェアハウスに対して動かし、中国由来のデータとその変換を国境を越えさせずに国内に留めることができます。 | dbt Labs — dbt-core リポジトリ（github.com/dbt-labs/dbt-core）＆ dbt docs「Install dbt」（docs.getdbt.com）、2026-10-12 取得 |
| ホスト型のSaaSであるdbt Cloudは、11のホスト型リージョンを挙げています——中国本土には一つもありません。dbtの “Regions & IP addresses” 文書は、AWS・GCP・Azure上の、北米（米国）、EMEA（フランクフルト、ロンドン、アイルランド）、オーストラリア（シドニー、Australia East）、日本（東京）にわたるホスト型リージョンを挙げ、各dbtアカウントは単一のリージョンに紐づきます。中国本土のリージョンはありません。dbt Cloudで動かせば、プロジェクト、実行メタデータ、ログ、アーティファクトはそれらオフショアのリージョンの一つに置かれます——したがって中国由来のデータについて、ホスト型テナントは国内保存義務を満たせません。 | dbt docs —「Regions & IP addresses」（docs.getdbt.com）、2026-10-12 取得 |
| 中国由来の個人情報をオフショアへ移すことは、PIPLの下での越境移転です。中国本土で収集した個人情報をオフショアのウェアハウスに着地させること——またはそれを記述するプロジェクト、ログ、メタデータをオフショアのテナントに保持すること——は、PIPL 第38〜40条が規律する越境移転です：通知、適法な移転メカニズム（CACの安全評価、CAC標準契約、または認証）を要し、センシティブ個人情報（テーブルやフィクスチャ内の政府発行ID、金融・健康のデータ）についてはPIPL 第28〜29条の下での個別の同意を要します。 | 個人情報保護法（PIPL）第38〜40条・第28〜29条——21YunBox gov-doc 翻訳、2026-10-12 取得 |
| CIIOまたは大量取扱者の場合、中国で収集したデータは国内に保存しなければなりません。サイバーセキュリティ法 第39条（旧第37条）（英語）——2026年1月1日施行の2025年改正が、データ国内保存の条番号を37から39へ、内容を変えずに変更——の下で、重要情報インフラ運営者（そしてPIPL 第40条により大量取扱者）は、中国で生成した個人情報と重要データを中国本土内に保存し、いかなる移転の前にも安全評価を行わなければなりません。中国本土のリージョンを持たないオフショアのdbt Cloudテナントは、構造的にその義務を満たせません。中国国内のウェアハウスに対するセルフホストのdbtの実行なら満たせます。 | 中華人民共和国サイバーセキュリティ法 第39条（旧第37条）——21YunBox gov-doc 翻訳、2026-10-12 取得 |
情報源は21YunBox コンプライアンスチームが2026年10月12日に確認しました。
中国本土を相手にするデータチームにとって、dbtについてまず片付けるべきは、問いが dbt コマンドが上海から動くかでも、dbtのモデルの上に作られたダッシュボードが速く描画されるかでもない、ということです。dbtはスタックの変換レイヤー——ELTの「T」です。データをホストするのではなく、データがすでに存在するデータウェアハウスの 内側 でSQL変換をコンパイル・実行し、計算をウェアハウスへ押し下げます。この一点が中国の問いを組み替えます。作業がウェアハウスで起きるため、コンプライアンスの軸は そのウェアハウス——そしてそれに対するdbtの実行——がどこにあるか、そしてdbt自身の副産物（実行ログ、アーティファクト、メタデータ）が貴社のデータについて何を記述するか、です。dbtには、それらの副産物をまったく違う場所に置く二つの形があります：貴社自身の環境にインストールして動かすオープンソースのエンジンdbt Coreと、dbt Labsが固定のオフショアのリージョン群でホストするSaaSのdbt Cloudです。
中国でのdbt：ひと目で
| 決め手 | dbt自身の言葉、そして中国の法 |
|---|---|
| dbtとは何か——変換（「T」）レイヤー | dbtは、データがすでに置かれているデータウェアハウスの内側でSQL変換をコンパイル・実行します。データ自体をホストするのではなく、計算をウェアハウスへ押し下げます。二つの形があります：dbt Core——貴社自身の環境にインストールして動かすオープンソースのエンジン（dbtの現行のオープンソースビルドは、Apache-2.0ライセンスの下でdbt OSSとして配布されています）——と、dbt LabsがホストするSaaSのdbt Cloudです。 |
| 国内保存はウェアハウスに従う——そしてコントロールプレーンにも | 変換はウェアハウスで実行されるため、そのウェアハウスがどこにあるかが、データがどこで処理・保存されるかを決めます。dbtは変換のために行を外へ運び出す必要はありません。しかしdbt Cloudではコントロールプレーンがオフショアにあります：プロジェクト、実行メタデータ、ログ、アーティファクトはdbtのホスト型リージョンに置かれ——dbtは中国本土のリージョンを一つも挙げていません。 |
| 際立った後半——メタデータとログ | 到達性チェックには決して見えない半分です。dbtのアーティファクト——マニフェスト、カタログ、実行結果、ログ——は貴社のデータの構造的な地図です：スキーマ、テーブル名とカラム名、コンパイル済みSQL、リネージ、そして（テストとログの設定によっては）失敗したテストのサンプル行。オフショアのdbt Cloudテナントに保持されれば、そのデータの地図——そしてそれと一緒にログされるもの——は実行のたびに海外に置かれます。 |
| 国内保存と越境 | 中国で収集した個人情報をオフショアのウェアハウスに着地させること、またはそれを記述するプロジェクトとメタデータをオフショアのテナントに保持することは、PIPL 第38〜40条の下での越境移転（数据出境）です——通知、個別の同意、そして移転メカニズムのいずれか一つ（CACの安全評価、CAC標準契約、または認証）。テーブルやテストフィクスチャが政府発行のID、金融・健康のデータを抱える場合、その内容はPIPL 第28〜29条の下でのセンシティブ個人情報に当たりえます。 |
| ローカライズとICPの扉 | 重要情報インフラ運営者または大量取扱者の場合、サイバーセキュリティ法 第39条（旧第37条）（英語）は、中国で収集した個人情報を中国本土内に保存することを求めます——これはオフショアのdbt Cloudテナントでは満たせません。そしてdbtの出力の上に立ち上げる公開の中国向けの画面——ダッシュボード、データアプリ、ドキュメント——は、本土のホスティングに紐づくICP備案（备案）の義務を負うインターネット情報サービスです。 |
| 到達性は軸ではない | dbt コマンドが本土から応答するかは運用の問題であり、コンプライアンスの問いではありません。それを決めるのは、ウェアハウス、dbtの実行、そのメタデータがどこに置かれるかです。dbtのエンジンはセルフホストできるため、適法なてこがあります：中国国内のウェアハウスに対して中国国内でdbtを動かし、データとその変換を国内に留め、中国向けの画面はどれも法令に沿って配信します——21YunBox Optimizer——既存の構成の前段で。 |
dbtとは実際に何か——変換レイヤーと、そのメタデータが露出するもの
dbtはデータストアでもウェブサイトでもありません。生のテーブルを、分析が依拠するモデルへ変える、作業エンジンです。貴社のSQLを読み、コンパイルし、それを貴社のデータウェアハウス——Snowflake、BigQuery、Databricks、Redshift、Postgres、あるいは別の宛先——の 内側 で実行するので、重い処理はデータがすでに存在する場所で起きます。dbtのオープンソースのエンジンは長らくdbt Coreとして知られてきました。dbtの現行のオープンソースビルドは、同じApache-2.0ライセンスの下でdbt OSSとして配布されています。いずれにせよ、それは貴社自身の環境から、貴社が選んだウェアハウスに対して、貴社自身がインストールして動かすソフトウェアです。
その設計こそ、中国の問いが国内保存の問いである理由です。dbtは変換のために行をウェアハウスの外へコピーする必要がないので、最も重要な一点は ウェアハウスがどこにあるか です。しかしdbtは、移動するもう一つの静かな資産も生み出します：メタデータです。すべての実行はアーティファクト——プロジェクトのマニフェスト、スキーマとカラムのカタログ、実行結果、ログ——を吐き出し、それらが合わさって貴社のデータの正確な構造的地図を形づくります：どんなテーブルが存在し、どう名付けられ結合されるか、それらを形づくるコンパイル済みSQL、そして、テストとログの設定によっては、テストに失敗した行のサンプル値です。dbt Coreではその地図は動かした場所に留まります。dbt Cloudではそれはdbtのホスト型リージョンに、プロジェクトと実行履歴とともに置かれ——dbtは中国本土内のリージョンを一つも挙げていません。
モデルが顧客・ユーザー・従業員のテーブルに触れるところでは、それが変換するデータは中国の個人情報保護法（PIPL）の下での個人情報であり、政府発行のID、金融・健康の記録を含む場合はセンシティブ個人情報でありえます。そのデータ——そしてそれを記述するメタデータ——が本土にあるかオフショアにあるかは、どのdbtを、どこで動かすかで決まります。
扉：国内保存、越境、センシティブ個人情報、ICP
dbtをオフショアのウェアハウスに向けるか、オフショアのdbt Cloudテナントで動かせば、最初の扉が開きます。そのオフショアの宛先に着地する、中国で収集した個人情報——そしてdbtがそれについて保持するプロジェクト、ログ、メタデータ——は海外に置かれ、それが越境移転（数据出境）になります。義務はdbt Labsではなく、取扱者である貴社に落ちます：PIPL 第13条と第23条はデータ収集の通知と根拠を求め、第38〜40条はそれをオフショアへ送るための移転メカニズム（CACの安全評価、CAC標準契約、または認証）を、海外移転のための個別の同意とともに求めます。
一部の取扱者にとって、保存はそもそもメカニズムの問題ではありません——国内に留まらなければならないのです。貴社の組織が重要情報インフラを運用するか、個人情報を大規模に取り扱う場合、サイバーセキュリティ法（英語）第39条（旧第37条——2026年1月1日施行の2025年サイバーセキュリティ法改正が、データ国内保存の条番号を37から39へ変更、内容は不変）は、中国で生成した個人情報と重要データを中国本土内に保存し、いかなる移転の前にも安全評価を行うことを求めます。オフショアのウェアハウス、または中国本土のリージョンを持たないオフショアのdbt Cloudテナントは、構造的にその義務を満たせません。
より静かで鋭い扉は、モデルが通り抜けるデータのセンシティブさです。テーブル、シード、テストフィクスチャが実在の政府発行ID、金融記録、健康データを抱えるところでは、その内容はPIPL 第28〜29条の下でのセンシティブ個人情報でありえ、具体的な目的、高められた必要性、個別の同意を要します。そして第三の扉は公開から生じます：dbtの出力の上に作られた公開の中国向けの画面——BIダッシュボード、データアプリケーション、あるいは本土のユーザーが到達するホスト型のdbtドキュメントサイト——を公開した瞬間、その画面はインターネット情報サービスであり、本土のホスティングリソースに紐づくICP備案（备案）の義務を負います。
なぜ到達性チェックはこれを見落とすのか
中国国内からのプローブは、dbtで動くダッシュボードが読み込まれるのを見たり、dbt run が本土のマシンから完了するのを確認したりして、「使える」と結論づけられます。その答えは的外れです。コンプライアンスのリスクは画面にはありません——データとその記述がどこに置かれ、どう動くかにあります：中国由来の行を保持するウェアハウス、そしてdbtがそれらについて保持するプロジェクト・ログ・アーティファクト・メタデータで、dbt Cloudではそれらがdbtの挙げるリージョン（北米、ヨーロッパ、オーストラリア、日本——中国本土は決してない）に置かれます。ページ読み込みテストはそのどれも測りません。ウェアハウスがどのリージョンにあるか、dbtのメタデータがどこに置かれるか、個別の同意が取られたか、移転メカニズムが整っているか、中国向けのダッシュボードにICP備案が必要かは、見えないのです。
変換ツールに特有の第二の罠があります。オフショアのdbt Cloudのコントロールプレーンを単に 到達可能 にすること——中国国内からdbtコマンドを動かすことさえ——は、規制対象のデータを何一つ国内へ移しません。dbtの計算はウェアハウスで動くため、ウェアハウスがオフショアならデータはオフショアに留まります。そしてプロジェクト、実行履歴、メタデータは、Cloudテナントが動く場所に依然として置かれます。データを保持するのは、ウェアハウスとコントロールプレーンがどこにあるかであって、本土の端末から動かしたコマンドではありません。それが、競合が真似できないこの問いの後半であり——ウェアハウス、dbtの実行、そのメタデータを単に到達可能にするのではなく、国内に留めることが答えである理由です。
適法な道筋——マッピング、ローカライズ、配信
中国本土のデータチームのためにdbtを運用する、法令に沿ったやり方があり、dbtのエンジンはオープンソースでセルフホストできるため、それは貴社がすでに使っているスタックに乗ります——作り直しも、dbtからの移行もありません。
まずマッピング：当社の中国コンプライアンスチームが、貴社のdbtの足跡が運ぶものを棚卸しします——モデルがどのソースと宛先を読み書きするか、dbtが変換するテーブルに個人情報があるか、ウェアハウスがどこにあるか、dbtの実行がどこで行われるか、そのプロジェクト・ログ・アーティファクト・メタデータがどこに置かれるか（オフショアのdbt Cloudリージョンか、セルフホストのインスタンスか）。各フローが依拠する同意と国内保存の根拠を確立し、技術的な見取り図を作ります。法的結論は専門家と確定します。
次にローカライズ：dbtのセルフホストのエンジンを、中国国内のウェアハウスに対して中国国内で動かし、データとその変換を本土の地に置き、プロジェクト・実行履歴・メタデータをオフショアのCloudテナントではなく国内に留め、第13条・第23条の通知と個別の同意を取得し、テーブルやフィクスチャ内の政府発行IDや金融データをセンシティブ個人情報として扱い、適法な越境メカニズム（CACの安全評価、標準契約、または認証）は本当に移転が必要なところでのみ使います。ローカライズとは、適法で国内のdbtを立ち上げることを意味します——結局データをオフショアへ送る経路では決してなく、いかなる不正な手段でもありません。
そして配信：dbtの出力の上に作られた公開の中国向けの画面——BIダッシュボード、データアプリ、あるいは本土のユーザーが到達するホスト型のドキュメント——はインターネット情報サービスなので、ICP備案の義務を負い、法令に沿った国内からの配信を必要とします。21YunBoxはそれを国内から配信します——21YunBox Optimizer——既存の構成の前段で、中国のユーザーに適法かつ法令に沿って提供します。21YunBoxはいかなる不正な手段も用いず、推奨もしません——法が留まるべきと定めるものは国内に保ち、残りは本土の内側から法令に沿って配信し、個人情報を密かに国境を越えて移すことは決してありません。21YunBoxは、貴社がすでに動かしているdbtに対するコンプライアンスのオーバーレイでありパートナーであって、競合ではありません。
これはいずれも、dbtが中国で「遮断されている」とか「違法だ」とする判定ではありません。これは国内保存と同意の見取り図であり、どの義務が貴社のケースに当てはまるかは、貴社の法人、中国法の下での役割、データ量、そしてウェアハウスとモデルが実際に何を抱えるかで変わります——貴社の中国チームのデータとその構造的地図がそれに依存する前に、具体的な点を専門家と整理する価値があります。
関連する読み物：
よくあるご質問
dbtは中国で遮断されていますか？そこで「使える」ようにする必要がありますか？
到達性は問題ではありません。dbt Coreはオープンソースでセルフホストできるため、中国国内のインフラで問題なく動き、dbt Cloudも到達できます。本当の問いは国内保存です：dbtは貴社のSQL変換をデータウェアハウスの内側で実行するため、そのウェアハウスがどこにあるか——そしてdbt Cloudでは、プロジェクト、ログ、メタデータがどこに置かれるか——が貴社の中国リスクを決めます。中国由来の個人データがオフショアに着地する、またはそこに保存されるなら、それは接続性の問題ではなく、PIPLの越境とデータ国内保存の問題です。
中国で法令適合になるために、dbt Cloudを最も近いリージョンに切り替えるだけでよいですか？
いいえ。dbt Cloudの文書化されたリージョンは北米、ヨーロッパ、オーストラリア、日本にあります——中国本土のリージョンはなく、dbtアカウントは単一のリージョンに紐づきます。最も近いリージョン（東京やシドニー）も依然として本土の外なので、そこで処理・記述される中国ユーザーのデータは依然として越境移転であり、CIIOや大量取扱者にとってデータ国内保存の義務（PIPL 第40条、サイバーセキュリティ法 第39条（旧第37条））は依然として満たされません。てこは、より近いリージョンではありません——中国国内のウェアハウスに対して中国国内でdbtのセルフホストのエンジンを動かすことです。
21YunBoxは当社のdbt設定を中国で使えるようにする手助けができますか？
はい——dbtは貴社のスタックに残ります。当社の中国チームが、モデルが実際に何を変換するか、ウェアハウスとdbtの実行がどこに置かれるか、そしてdbtのプロジェクト・ログ・アーティファクト・メタデータがどこに置かれるかを整理し、貴社の法人とデータ量に照らしてPIPLの越境とデータ国内保存のリスクを評価します。そこから、中国国内のウェアハウスに対して中国国内でdbtを動かし、データとその構造的地図を国内に留めることを支援し、中国向けのダッシュボードやデータアプリが必要とするICP備案済みの国内からの配信を——既存の構成の前段に、作り直しも二つ目のコードベースもなく——立ち上げます。お問い合わせいただければ、個別のケースを一緒に整理します。
