Claude Code「バックドア」騒動｜中国の警告とAnthropicが認めた隠しコード

発端は政府機関でもセキュリティベンダーでもなく、Redditの一人のユーザーだった。

2026年6月30日、r/ClaudeAIに投稿されたリバースエンジニアリング（プログラムを解析して内部の仕組みを調べること）の報告が波紋を広げた。Claude Codeの内部に、システムのタイムゾーンとプロキシURLを147件の中国関連ドメインのリストと照合するロジックが、目的を判別しにくいよう難読化された状態でバージョン2.1.91（4月2日）から含まれていたという内容だ（出典：The Register、2026年7月8日）。

そこから2週間足らずで、事態は企業間の対立から国家レベルの応酬へ発展した。7月8日には中国の国家脆弱性データベース（NVDB）が「セキュリティバックドア」として公式警告を出し、Alibabaは7月10日から従業員のClaude Code使用を禁止した（出典：CBS News、2026年7月8日）。

Claude Codeを毎日使っている自分にとって、これは他人事ではない。何が起きたのか、時系列で整理する。

2週間で国家間の応酬になった：時系列の整理

まず全体の流れを押さえておきたい。個人の発見から中国政府系機関の警告まで、わずか8日間だ。

日付（2026年）	出来事
3月頃	Anthropicが位置検出の「実験」を開始（同社エンジニアの説明）
4月2日	Claude Code 2.1.91リリース。報道によれば難読化コードはこの版から
6月30日	r/ClaudeAIのユーザーがリバースエンジニアリングで発見・公開
7月1日	2.1.198リリース。該当コードが削除されたと報道
7月3日頃	Alibabaの社内使用禁止方針が報道され、Hacker Newsで大きな議論に
7月8日	中国NVDBが「セキュリティバックドア」警告を公表
7月10日	Alibabaの使用禁止が発効。従業員には自社Qoderへの移行を指示

出典：The Register、CBS News、Tom’s Hardware（いずれも2026年7月）

注目すべきは順序だ。NVDBが警告を出した7月8日の時点で、問題のコードはすでに削除済みだったと報じられている。警告の対象となった2.1.91〜2.1.196は過去のバージョンであり、警告は「即時アンインストールか安全なバージョンへの更新」を推奨する内容だった。

Claude Codeに含まれていたコードは何をしていたのか

Redditの発見者が報告した内容と各社の報道を突き合わせると、コードの挙動は次のように整理できる。

• システムのタイムゾーン設定を確認する
• プロキシのURLを147件の中国関連ドメインのリストと照合する
• 難読化されており、通常のコードリーディングでは目的が判別しにくい状態だった

中国NVDBはこれを「ユーザーの位置情報や身元関連の識別子を、同意なくAnthropicのサーバーへ送信し得る」機構だと表現し、「深刻な脅威」と位置づけた（出典：CBS News、2026年7月8日）。

ただし、ここは慎重に読む必要がある。「中国関連の指標をチェックするコードが存在した」ことはAnthropic自身が認めた事実だが、「どんなデータがどこまで送信されていたか」についてはNVDBの主張と各社報道の間に幅がある。2026年7月12日時点でCVE（世界共通で使われる脆弱性の識別番号。深刻な脆弱性なら通常は登録される）は登録されておらず、中国国外の独立研究者がNVDBの主張を裏付けたという報告も確認できていない（出典：Cybernews、2026年7月）。

Anthropicの釈明：「蒸留対策の実験だった」

Anthropicはこの発見を否定しなかった。Claude CodeのエンジニアThariq Shihipar氏はX上で、このコードが2026年3月に始めた実験であることを認めた上で、目的をこう説明した。

「非正規リセラーによるアカウントの不正利用を防ぎ、蒸留（distillation）から保護するための実験だった」（筆者訳。出典：CBS News、2026年7月8日）

さらに同氏は「チームはその後より強力な対策を実装しており、このコードは以前から削除するつもりだった」とも述べている（出典：The Register、2026年7月8日）。

蒸留とは、他社の高性能モデルに大量の質問を投げ、その出力を自社モデルの学習データにする手法を指す。Anthropicはこの問題で中国AI企業と長く争ってきた。アリババによる2880万回・偽アカウント2.5万件の蒸留攻撃の告発や、DeepSeek・Moonshot・MiniMaxによる組織的な能力抽出の分析は以前の記事で書いたとおりだ。今回の隠しコードは、その防衛戦の一環だったことになる。

Anthropicは中国からのアクセスを規約上ブロックしているが、実際にはVPNやプロキシ経由での利用が横行している。South China Morning Postの取材に対し、Anthropic側は「中国のユーザーはそもそも使用を想定していない」という趣旨の回答をしている（出典：SCMP、2026年7月9日）。

Alibabaの禁止とQoderへの誘導

Alibabaは今回の発見を受けてClaude Codeを高リスクソフトウェアに分類し、7月10日から従業員の使用を禁止した。移行先として指示されたのは自社製コーディングエージェントのQoderだ（出典：Tom’s Hardware、2026年7月）。

この判断を額面どおり「セキュリティ対応」と受け取るのは難しい。AnthropicとAlibabaは蒸留攻撃の告発で真っ向から対立してきた当事者同士であり、中国ではAI研究者の海外渡航制限が民間企業に拡大するなど、AI開発が国家戦略として管理されつつある。セキュリティ上の懸念と、自社・自国ツールへの移行圧力が重なった構図だ。

皮肉なことに、Claude Codeが使えなくなった中国の開発者には受け皿がすでにある。Kimi K2.7やGLM-5.2といった中国製コーディングAIは、2026年6月にClaude Fable 5が政府命令で一時停止した際に「代替」として一気に注目を集めた。今回の騒動も同じ方向に作用するだろう。

コミュニティの反応は真っ二つ

Hacker NewsではAlibaba禁止のスレッドが336ポイント・280コメントまで伸びた。読んでいて面白いのは、Anthropic批判と擁護がきれいに割れている点だ（以下のコメント要約の出典はいずれもHacker News、2026年7月3日）。

批判側で目立ったのは、Claude Codeを「デバイスやファイルシステムの情報を明示的な承認なしに収集する」ツールだと断じ、オープンソース代替への移行を主張する声だ（rvnx氏）。

擁護側からは正反対の整理が出る。Anthropicの措置と、地理制限をプロキシで回避してアカウントを不正利用する行為は別問題であり、責められるべきは後者だという立場だ（breppp氏）。

面白いのは、どちらにも与しない技術的なツッコミが議論の質を上げていたことだ。「不正利用検知のためのデータ収集を『バックドア』と呼ぶのは適切なのか」という用語への疑問（dgellow氏）。「蒸留には本来logit（モデル内部の確率スコア）へのアクセスが必要で、出力を学習データにする行為は厳密には蒸留ではない」というAnthropic側の用語法への指摘（causal氏）。Claude CodeはCLIとして複数のモデルを扱えるため「禁止」の実効性は見た目ほど大きくない、という実利的な観察（yanhangyhy氏）や、「GLMやDeepSeekは独自に追いついており、蒸留を制限しても影響は限定的だ」という防衛策の効果自体への疑問（feverzsj氏）もあった。

日本のClaude Codeユーザーが今やるべきこと

騒動の政治的な側面はさておき、実務上の対応はシンプルだ。

1. ターミナルで claude --version を実行する
2. バージョンが2.1.198以降なら、今回指摘されたコードは削除済みと報じられている
3. 2.1.91〜2.1.196のまま使っている場合は更新する（自動更新が有効なら通常は最新化されている）

チームでClaude Codeを導入している場合は、もう一歩踏み込みたい。メンバーの利用バージョンを棚卸しし、自動更新が無効になっている環境がないかを確認する。社内のAIツール利用ポリシーに「クライアントツールが収集し得る情報」の項目がなければ、今回の件は追加するきっかけになる。

日本のユーザーが中国関連ドメインのチェックに引っかかる可能性は低い。ただし、今回の件が残した教訓はバージョン番号の話にとどまらない。

Anthropicのツールがユーザーへの十分な説明なしに機能を組み込んでいたと指摘されたのは、今回が初めてではない。2026年4月にはClaude DesktopがmacOSの7種のブラウザへ説明なくブラウザ連携用の通信経路（ネイティブメッセージングブリッジ）をインストールしていたと指摘された問題が話題になった。安全性を強く打ち出す企業が透明性の面で二度批判を受けたという経緯は、企業でAIツールの導入判断をする立場なら記憶しておくべきだ。

PMとして考えたこと：問題は「何をしたか」より「黙っていたこと」

自分はエンジニアではないので、難読化コードの技術的な精巧さを評価する立場にない。ただ、プロダクトマネジメントの視点で見ると、今回の件は「不正利用対策として何をやるか」ではなく「それをユーザーにどう開示するか」の失敗だと思う。

蒸留攻撃への防衛自体は正当な事業判断だ。2880万回の不正利用を受けたと告発するほどの事態を認識していた企業が検出機構を作るのは自然な流れで、そこを責めるのは筋が悪い。問題は、その検出機構を難読化してクライアントに同梱し、発見されるまで説明しなかったことにある。利用規約に「不正利用検出のためにクライアント側で地域指標を確認することがある」と一行書いてあれば、NVDBに「バックドア」と呼ばれる隙はずっと小さかったはずだ。

そして中国側の警告も、削除済みのバージョンを対象に「深刻な脅威」と宣言している時点で、純粋な脆弱性情報というより政治的なメッセージの色が濃い。CVEなし・独立検証なしの警告を、米中対立の文脈から切り離して読むことはできない。

自分はClaude Codeを使い続ける。ただし、この種のツールがOSのタイムゾーンやプロキシ設定を読める権限を持っていることを前提に、扱う情報を選ぶ。それが現時点での現実的な落とし所だと考えている。

---

関連記事

• アリババのClaude蒸留攻撃｜2880万回・偽アカウント2.5万の全貌
• AI蒸留攻撃とは｜DeepSeekらが2.4万偽アカウントでClaude能力を抽出か
• Claude Desktopのブラウザ無断ブリッジ問題｜macOSリスクと対処法
• Kimi K2.7 vs GLM-5.2：中国から来たコーディングAI

---

本記事の情報は2026年7月12日時点のものです。本件は係争的な性質を持ち、中国NVDBの主張には2026年7月12日時点で独立した検証がありません。記事中の各主張は出典元の報道に基づくものであり、事実関係は今後の調査で変わる可能性があります。ツールの利用判断は公式情報を確認の上、ご自身の責任で行ってください。記載の企業名・製品名は各社の商標または登録商標です。