中国AIモデルの業務利用リスク｜APIと自社ホストで何が違うか

「DeepSeekは中国製だから使わない」——社内の生成AI利用ルールを作るとき、この一行で議論が終わってしまうことがあります。ただ、同じ「中国発のモデル」でも、公式アプリに社内資料を貼り付ける行為と、公開された重みを自社サーバーで動かす行為とでは、起きることがまるで違います。国籍だけを理由に一括で禁止すると、本当に危ない使い方を見落としたまま、安全に使える選択肢まで捨てることになります。

結論として、中国発AIモデルの業務利用リスクは「モデルの出身国」ではなく「入力したデータがどこへ流れ、どの法域に置かれるか」でほぼ決まります。公式のクラウドAPIやアプリでは、入力データが中国国内のサーバーに保存され中国の法令が適用されうる点が最大の論点です。一方、MITやApache-2.0で公開された重みを自社環境や国内クラウドで動かす場合、入力データは自社の管理下から出ません。この2つを同じ「中国AIリスク」でまとめることが、判断を誤らせる原因です。

この記事では、公式ライセンス、提供元のプライバシーポリシー、各国当局の公表資料に当たりながら整理します。なお本記事は一般的な情報提供であり、法的助言ではありません。個別の判断は弁護士等の専門家にご確認ください。

リスクを分けるのは「国籍」ではなく「データの経路」

生成AIの情報リスクは、突き詰めると「自社の情報が、自社の管理外のどこへ、どういう条件で渡るか」という一点に集約されます。開発元の国籍は、その経路を推し量る手がかりではあっても、経路そのものではありません。

公式のクラウドサービスを使う場合、入力したプロンプトと添付ファイルは提供元のサーバーに送られ、以後の扱いは提供元の規約と所在国の法令に従います。この構造は開発元が中国でも米国でも同じで、違うのは適用される法令の中身と、自社がそれを把握できているかどうかです。

対してオープンウェイトのモデルを自社サーバーや国内クラウドで動かす場合、推論は自社が管理する環境で完結し、越境移転そのものが発生しません。実務では「使う・使わない」ではなく「どの経路なら使えるか」を先に決めるほうが、現実的な結論にたどり着きます。自社で動かす選択肢のコストや性能はローカルLLMは業務で実用になるかを検証した記事で扱っています。

この論点は「どこの国のAIに依存するか」という国全体の議論とも地続きで、国産モデルやデータ主権の動きはソブリンAIと日本の現在地を整理した記事にまとめています。ただし実務判断としては、国策の議論と自社の情報管理は切り離したほうが結論がぶれません。

自社ホストという選択肢が現実的になった背景には、AIインフラへの旺盛な投資があります。エヌビディア決算で見るべき指標を見ると、この投資が今も続いているかどうかの手がかりになります。

主要な中国発モデルとライセンスを公式で確認する

前提として、モデルのライセンスと公式サービスの利用規約はまったく別のものです。ライセンスは「公開された重みを自分で使うときの条件」で、公式アプリやAPIに入力したデータの扱いはプライバシーポリシーと利用規約が定めます。混同したまま「MITだから安全」と判断する例が少なくありません。

DeepSeek（深度求索）

DeepSeekは重みをMITライセンスで公開しています。Hugging FaceのDeepSeek-V3.2のモデルカードには「This repository and the model weights are licensed under the MIT License」と明記され、商用利用を含め制約の少ないライセンスです。一方、公式のプライバシーポリシーには、収集した情報を中華人民共和国にあるサーバーに保存する旨が記載されています。

Qwen（アリババ）

アリババが開発するQwenシリーズも、多くのモデルがオープンウェイトで公開されています。Hugging FaceのQwen3-235B-A22Bのモデルカードにはライセンスとしてapache-2.0が指定されています。Apache-2.0はMIT同様に商用利用を許容しますが、変更点の告知や特許条項などMITにはない条件を含みます。

Kimi（Moonshot AI）

Moonshot AIのKimi K2は「Modified MIT License」で公開されています。GitHubのLICENSEを読むとMITに追加条項があり、月間アクティブユーザー1億人超、または月間売上2,000万米ドル超の商用製品で利用する場合は、そのUIに「Kimi K2」を目立つ形で表示することが求められています。多くの日本企業には該当しない閾値ですが、「MIT」と書かれていても条文を読まないと分からない条件が入っている典型例です。

いずれのライセンスも「重みの使用条件」を定めるものであって、モデルの安全性や情報の流れを保証するものではありません。ライセンス確認は必要条件であって十分条件ではないということです。

利用形態ごとに論点はこう変わる

同じモデルでも、どの経路で使うかによってデータの行き先と法令上の論点は大きく変わります。社内ルールは、モデル名ではなく下表の行単位で可否を決めるほうが運用しやすくなります。

最後の行は実在する選択肢です。AWSはDeepSeek-R1をAmazon Bedrockのフルマネージド・サーバーレスモデルとして提供しており、指定したAWSリージョン内で推論を実行できます。「中国発のモデルを使うこと」と「中国の事業者にデータを預けること」は、技術的にも契約的にも切り離せます。

日本の個人情報保護法から見た論点：第28条

個人データを含む入力を海外の事業者に送る場合、個人情報保護法第28条（外国にある第三者への提供の制限）が問題になります。この条文の建付けはシンプルで、外国にある第三者へ個人データを提供するには、原則としてあらかじめ「外国にある第三者への提供を認める旨の本人の同意」を得る必要がある、というものです。

同意を取得する際には、本人に3つの情報を提供しなければなりません。①移転先の外国の名称、②当該外国における個人情報の保護に関する制度についての情報、③当該第三者が講ずる保護措置に関する情報、の3点です。移転先の国が特定できない場合は、その旨と理由を説明する形での代替も認められています。

例外もあります。EUや英国のように日本と同等の水準にあると認められた国への提供、提供先が相当措置を継続的に講ずる体制を整備している場合、法第27条第1項各号に該当する場合は同意が不要です。中国は十分性認定の対象ではないため、公式サービス経由で個人データを送るなら原則ルートでの対応を検討することになります。

実務的に厳しいのは②です。「当該外国における個人情報の保護に関する制度」を適切かつ合理的な方法で確認して本人に説明する作業は、法務体制が薄い中小企業には相当な負担です。だからこそ、そもそも個人データを入力しない運用に寄せるほうが現実的な場面が多くなります。線引きは生成AIに入力してはいけない情報を整理した記事、規約側の確認ポイントはAI利用規約と学習オプトアウトの読み方の記事を参照してください。

Mihataでも、AI導入のご相談で最初に整理するのは「どのモデルを使うか」ではなく「どの情報をどの経路に流してよいか」の一覧です。自社だけで線引きを詰めきれない場合は、貴社の業務実態に合わせて一緒に整理しますので、下記からご相談ください。

各国当局が実際に公表している措置

報道では「各国が禁止」とまとめられがちですが、実際の措置は対象範囲も強さもばらばらです。社内資料に載せるなら公式発表の原文に当たり、範囲を正確に書いたほうが後から困りません。

日本の個人情報保護委員会は、令和7年2月3日付（同年3月5日更新）で「DeepSeekに関する情報提供」を公表しています。示されているのは同社のプライバシーポリシーの記載に基づく2点、すなわち①取得した個人情報を含むデータは中華人民共和国に所在するサーバに保存されること、②当該データには中華人民共和国の法令が適用されること、です。禁止ではなく、利用者が判断するための情報提供という位置づけです。

イタリアのデータ保護当局（Garante）は2025年1月30日、DeepSeekのサービスを提供する中国企業2社に対し、イタリア国内ユーザーのデータ処理を緊急かつ即時に制限する措置を採り、調査を開始したと公表しました。韓国の個人情報保護委員会は2025年2月、DeepSeekアプリの国内サービスを暫定停止し改善・補完を行う旨の報道資料を公表しています。オーストラリアでは内務省がPSPFに基づくDirection 001-2025を発出し、政府機関にDeepSeek製品の使用・導入禁止と既存分の削除を求めました。対象は政府機関であり、民間企業一般を規制するものではありません。

中国国内でも生成AIサービスには規制の枠組みがあります。国家インターネット情報弁公室など7機関による「生成AIサービス管理暫定弁法」が2023年7月に公布され、同年8月15日に施行されました。提供者に適法な情報源からのデータ利用、知的財産権の尊重、個人情報の同意取得などを求める内容です。日本の規制動向は日本のAI規制の現在地をまとめた記事もご覧ください。

これら以外にも各国の自治体・省庁レベルの措置が報じられていますが、一次資料を確認できないものは「報道ベース」として扱い、社内文書では出典と確認日を添えて区別することをおすすめします。

誤解されやすい3つの点

ひとつめは「MITライセンスだから安全」という誤解です。ライセンスが定めるのは重みを使う法的条件であって、モデルの挙動やセキュリティを保証しません。Kimi K2のようにMITを名乗りつつ追加条項を持つ例もあります。

ふたつめは「自社で動かせば何のリスクもない」という誤解です。越境移転の論点は消えますが、重みの入手経路が信頼できるか、出力に業務上不都合な偏りがないか、脆弱性の更新を誰が追うのかという論点が残ります。セルフホストはリスクの種類を「外部への情報流出」から「自社の運用責任」へ移し替える選択です。

みっつめは「禁止すれば管理できる」という誤解です。社内で禁止しても個人のスマートフォンで使われるだけ、という状況が生まれやすくなります。むしろ「この経路なら使ってよい」という道を用意したほうが実態を把握できます。詳しくはシャドーAI対策を扱った記事で整理しています。

自社で使ってよいかを決める7つの手順

ここまでの整理を、判断する順番に並べ直します。上から順に潰していくと、感情論に流れずに結論が出せます。

1. 用途を書き出す。何のためにそのモデルを使いたいのか、代替できる手段はないのかを1〜2行で言語化する。
2. 入力する情報を分類する。公開情報のみか、社外秘を含むか、個人データを含むかの3段階で仕分ける。
3. 利用形態を決める。公式API・中継サービス・セルフホスト・大手クラウドのマネージドのどれかを、上の分類に合わせて選ぶ。
4. 公式の一次資料を確認する。モデルカードのライセンス条文、提供元のプライバシーポリシーと利用規約を、記憶ではなく原文で読む。
5. 個人データを含むなら法28条の整理をする。同意を取るのか、そもそも入力しない運用にするのかを決め、根拠を文書に残す。
6. ログと監査の方法を決める。誰がいつ何を入力したかを追える状態にし、問題が起きたときの窓口を明確にする。
7. 禁止事項ではなく許可された経路を社内に告知する。使ってよいツールと入力してよい情報を一枚にまとめて配る。
8. 見直しの期日を入れる。規約もライセンスも当局の見解も変わるため、半年ごとに再確認する日をカレンダーに置く。

この手順を通すと、「中国製だから禁止」でも「話題だから全社導入」でもない、自社の情報の性質に基づいた結論になります。しかもこの手順は中国発モデルに限らず、どの国のどのAIサービスにもそのまま使えます。

とはいえ、日々の業務のかたわらで一次資料を読み込み、社内ルールに落とすところまで走りきるのは簡単ではありません。Mihataは中小企業のAI導入支援として、ルール整備からツール選定、運用定着までをお手伝いしています。現状の困りごとだけでも聞かせていただければ、進め方をご提案します。