はじめに
Kimi-K2.6やQwen3.6の性能に興味はあるのに、「中国のAIは会社的にNG」の一言で選択肢から外していませんか？
私は小売の購買データや位置情報を扱うデータエンジニアで、扱うデータの性質上「海外にデータを出せるか」を常に意識せざるを得ない立場です。その視点で調べていくと、「モデルの国籍」と「データの行き先」を混同したまま思考停止しているケースが多いことに気づきました。この記事では、中国発のオープンモデルを国内ホストで使うという第三の道を、一次情報の確認と実測の両方で確かめます。
対象読者
- KimiやQwenを業務で使いたいが、データの扱いが気になっているエンジニア
- 「中国AI禁止」という社内ルールの中身を整理したい人
- さくらのAI Engineをこれから触ってみたい人
参考文献
まず一次情報から。この記事の主張はすべて以下に基づいています。
先に結論
中国発のモデルを使う経路は1つではありません。データの行き先はどの経路を選ぶかで決まります。
| 経路 | データの行き先 | 導入の手間 |
|---|---|---|
| A. モデル提供元のAPIを直接叩く | 提供元が指定するサーバ（DeepSeekの場合は中国所在で中国法令の適用が指摘された） | 小 |
| B. 国内事業者のホスティングAPIを叩く | 国内のデータセンター | 小 |
| C. 自前のGPUでセルフホスト | 自社内 | 大 |
補足すると、経路Aでも常に中国にデータが行くわけではありません。たとえばQwenの提供元APIであるAlibaba Cloud Model Studioにはシンガポールなどの国際リージョンがあります。ただしその場合も「どの契約・どのエンドポイントだとデータがどこに保存されるか」を提供元の規約で個別に確認する必要があり、確認コストは残ります。
経路Bの実例がさくらのAI Engineです。KimiもQwenもオープンウェイトなので、さくらインターネットが国内のGPU基盤に重みを持ち込んでホストできる。アプリから見れば「国内APIに投げたら国内で推論されて返ってくる」だけで、データが中国に渡る経路がそもそも存在しません。
そもそも何が問題視されたのか
2025年2月、個人情報保護委員会がDeepSeekの生成AIサービスについて情報提供を出しました。要点は2つです。
- 利用に伴い取得された個人情報を含むデータが、中国に所在するサーバに保存される
- そのデータには中国の法令（個人情報保護法、サイバーセキュリティ法、データセキュリティ法、国家情報法など）が適用される
読んでみると分かるのですが、ここで問題にされているのはデータの保存場所と適用法令であって、モデルの性能や出自ではありません。なおデジタル庁が政府機関向けに出した事務連絡は、これに加えて「要機密情報は約款型の外部サービスで扱わない」という政府の外部サービス利用基準の再確認も含んでおり、保存場所だけの話ではない点は付記しておきます。それでも共通する軸は「中国発のモデルだから危ない」ではなく「データがどの法域に渡り、誰の基準で管理されるか」です。
ここを分解せずに「中国AI禁止」とだけ覚えてしまうと、本来は使えるはずの選択肢まで捨てることになります。
オープンウェイトという前提知識
KimiとQwenは、モデルの重み（パラメータ）が公開されているオープンウェイトモデルです。ライセンスを実際に確認しました。
- Kimi K2系はModified MITライセンス。月間アクティブユーザーが1億を超える、または月間売上が2,000万米ドル相当を超える商用製品・サービスではUIにモデル名（K2.6なら「Kimi K2.6」）を目立つ形で表示する義務が付きますが、それ以外は通常のMITと同様に利用できます
- Qwen3系はApache 2.0。制約のゆるい定番ライセンスです
重みが公開されているということは、ライセンスの範囲内なら誰でも・どこでも推論を動かせるということです。提供元のAPIを叩くこととモデルを使うことはイコールではない——これがこの記事の主張の土台になります。
さくらのAI Engineのホスティングを確認する
では経路Bの実例、さくらのAI Engineは実際どうなっているのか。公式マニュアルには次の記載があります。
データはすべてお客様とさくらインターネット間の通信だけで完結し、チャットなどに使われるデータはLLMモデルの学習に使われることのない、データ安全性の高いサービス
対応しているLLMモデルはすべてさくらインターネットによりホスティングされている
公式記載だけを鵜呑みにするのもエンジニアらしくないので、外形的にも確かめてみました。まず名前解決でIPアドレスを取り、そのIPの所属ASを別途調べます。
dig +short api.ai.sakura.ad.jp
curl -s https://ipinfo.io/153.120.132.21/json
IPアドレス: 153.120.132.21
所属AS: AS7684 SAKURA Internet Inc.
エンドポイントはさくらインターネット自身のAS配下にありました。参考値として、手元の回線からTLSハンドシェイクは約0.18秒、モデル一覧APIの応答まで約0.25秒です。提供モデルの一覧も実際に取得でき、執筆時点（2026年8月）ではKimi-K2.6、Qwen3.6、Qwen3-VLのほか、gpt-oss-120b、gemma、国産のllm-jpなどが並んでいました。
IPジオロケーションは推定を含み、応答時間も測定地点や経路の混雑に左右されるため、これらは所在地の証明にはなりません。ここでの確認は「エンドポイントがさくらのAS配下にある」ことの外形確認で、国内完結の根拠としては公式マニュアルの記載が一次情報です。
登録して最初のリクエストを送るまで
私が実際にやった手順は3ステップでした。
- さくらインターネットの会員登録を済ませる（電話認証が必要で、支払い方法はクレジットカードのみでした）
- コントロールパネル（secure.sakura.ad.jp/ai/）にアクセスし、利用規約に同意してプランを選ぶ。無償で試せる枠が用意されています。枠の内容は変わる可能性があるので、最新は公式の料金ページで確認してください
- 左メニューの「アカウントトークン」から「アカウントトークンを作成」でトークンを発行する
（スクショ挿入位置①：コントロールパネルのアカウントトークン作成画面）
トークンは UUID とシークレットのペアで、作成時にしか表示されません。私は環境変数に入れて管理しています。OpenAI互換とAnthropic互換の両エンドポイントがあるので、既存のコードがどちらのSDKで書かれていても差し替えは最小限で済みます。
（スクショ挿入位置②：Playgroundでモデルを選んでリクエストを送った画面）
中国系モデルに実際にリクエストを投げてみた
登録できたので、業務で頻出する「問い合わせメールの要約」タスクをKimi-K2.6に投げてみます。
自然な日本語の要約が返ってきました。データの経路を気にせずKimiに仕事を頼める、というのは想像以上に気楽です。
続けて、同じタスクをKimi-K2.6・Qwen3.6-35B・gpt-oss-120bの3モデルに各2回ずつ投げ、応答時間を測りました。
gpt-oss-120bが約1秒で完了する一方、KimiとQwenは6〜10秒かかっています。ただしこれは遅いのではなく、両者が推論（思考）トークンを先に生成するタイプだからです。リクエスト全体で見た実効スループット（応答時間あたりのcompletionトークン数で、思考トークンも含みます）はQwen3.6が約200トークン/秒と最も高い値でした。純粋なデコード速度を測るならストリーミングで初トークンまでの時間と生成時間を分けて計る必要がありますが、今回は「体感の待ち時間」を知りたかったのでリクエスト全体を計っています。
ここでひとつハマりました。最初、max_tokensを600に設定してKimiとQwenを呼んだところ、レスポンスのcontentがnullで返ってきたんです。ステータスは200なのに中身がない。原因は、思考トークンがmax_tokensを食い尽くして、本文を書く前に打ち切られていたことでした（finish_reasonがlengthになっているのに気づくまで、しばらくAPIの不具合を疑っていました。恥ずかしい話ですが）。
Kimi-K2.6やQwen3.6のような推論系モデルを呼ぶときは、思考トークンの分を見込んでmax_tokensを大きめに確保してください。私は2500に上げて解決しました。同じ罠を踏む人は多いはずです。
計測に使ったコード（Python標準ライブラリのみ）
import json, os, time, urllib.request
BASE = "https://api.ai.sakura.ad.jp/v1/chat/completions"
TOKEN = os.environ["SAKURA_AI_ENGINE_TOKEN"]
def call(model: str, prompt: str) -> dict:
body = json.dumps({
"model": model,
"messages": [{"role": "user", "content": prompt}],
"max_tokens": 2500,
}).encode()
req = urllib.request.Request(BASE, data=body, headers={
"Authorization": f"Bearer {TOKEN}",
"Content-Type": "application/json",
})
t0 = time.time()
with urllib.request.urlopen(req, timeout=180) as res:
data = json.loads(res.read())
elapsed = time.time() - t0
usage = data["usage"]
return {
"model": model,
"elapsed_s": round(elapsed, 2),
"completion_tokens": usage["completion_tokens"],
"tok_per_s": round(usage["completion_tokens"] / elapsed, 1),
"answer": data["choices"][0]["message"].get("content"),
}
if __name__ == "__main__":
prompt = "次の問い合わせメールを200字以内で要約してください。（本文は省略）"
models = ["preview/Kimi-K2.6", "preview/Qwen3.6-35B-A3B", "gpt-oss-120b"]
for model in models:
runs = [call(model, prompt) for _ in range(2)]
avg_s = sum(r["elapsed_s"] for r in runs) / len(runs)
avg_tps = sum(r["tok_per_s"] for r in runs) / len(runs)
print(f"{model}: {avg_s:.2f}s / {avg_tps:.1f} tok/s")
それでも残る論点
国内ホストが解決するのは「データの行き先」だけです。フェアに書いておくと、解決しないものもあります。
モデルの重みには学習データ由来の知識や応答の傾向が焼き込まれており、これはどこでホストしても変わりません。特定の話題への応答の偏りが業務上問題になる用途なら、それはデータ主権とは別の軸で評価する必要があります。また、社内規程が「中国製ソフトウェアの利用」自体を制限している場合、ホスティング場所の議論だけでは通らないこともあるでしょう。previewとして提供されているモデルは提供条件が変わる可能性もあります。
それでも、「データが中国の法域に渡るから使えない」という最大の懸念が消えるだけで、選択肢は大きく広がると私は思います。
まとめ
「中国AI禁止」を分解すると、多くの現場で本当に禁止したいのは「データが中国の法域に出ること」のはずです。そしてそれは、オープンウェイトのモデルを国内事業者のホスティングで使えば構造的に発生しません。今回さくらのAI Engineで確かめた限り、エンドポイントは国内AS配下、入力データは学習不使用と明記され、Kimi-K2.6は普通に実用速度で日本語の仕事をこなしました。
「モデルの国籍」と「データの行き先」を分けて考える。この整理だけ持ち帰ってもらえれば、この記事の目的は達成です。もし社内で「中国AIって使っていいんだっけ？」という議論が起きたら、この整理を叩き台にしてみてください。試した結果や、御社ではこう整理しているという話があれば、コメントで教えてもらえると嬉しいです。