2026-07-05

アリババ、従業員にClaude Codeの使用禁止を通達

アリババは、従業員に対してAnthropicのプログラミングツールであるClaude Codeの使用を禁止することを発表しました。この禁止措置は2026年7月10日から施行される予定です。Anthropicは中国企業やその所有する外国企業に対しても同様の禁止を行っており、最近では中国ユーザーのアクセスを防ぐための対策を強化しています。アリババはClaude Codeを高リスクソフトウェアと見なしており、従業員には自社のQoderツールの使用を指示しています。

メトリクス

このニュースのスケール度合い

7.5 /10

インパクト

7.8 /10

予想外またはユニーク度

7.2 /10

脅威に備える準備が必要な期間が時間的にどれだけ近いか

7.0 /10

このニュースで行動が起きる/起こすべき度合い

7.1 /10

主なポイント

  • アリババは、従業員にClaude Codeの使用を禁止する方針を発表しました。
  • Anthropicは中国企業に対しても同様の禁止を行っており、アクセス防止策を強化しています。

社会的影響

  • ! この禁止措置は、アリババの従業員に対するセキュリティ意識の向上を促す可能性があります。
  • ! また、AIツールの利用に関する規制が強化されることで、企業の技術革新に影響を与えるかもしれません。

編集長の意見

アリババがClaude Codeの使用を禁止する決定は、企業のセキュリティ戦略において重要な一歩です。AI技術の進化に伴い、企業は外部ツールの利用に対して慎重になる必要があります。特に、データ漏洩や不正利用のリスクが高まる中で、企業は自社の情報を守るために厳格なポリシーを採用することが求められています。Claude Codeのような外部ツールは、便利である一方で、企業の機密情報が漏洩する危険性を孕んでいます。アリババが自社のQoderツールを推奨することは、内部開発の重要性を再認識させるものであり、企業の競争力を維持するためにも必要な措置と言えるでしょう。今後、他の企業も同様の方針を採用する可能性が高く、AIツールの利用に関する規制が強化されることが予想されます。企業は、外部ツールの利用に際してリスクを評価し、適切な対策を講じることが重要です。これにより、企業の情報セキュリティを強化し、信頼性を高めることができるでしょう。

解説

アリババがClaude Codeを高リスク指定、7月10日から社内利用を全面禁止です

今日の深掘りポイント

  • 外部AIコード支援は「開発SaaS」ではなく「越境データ経路」と捉えるべき段階に入った、という示唆です。標準のSaaS調達ガバナンスではなく、DLP・ソースコード機密・輸出入管理まで束ねた統合統制が必要です。
  • ベンダ側(Anthropic)が中国企業の利用を制限し、ユーザ側(アリババ)が高リスク分類で遮断するという“両側遮断”は、デカップリングのオペレーショナルな顕在化です。開発現場のシャドーAIと依存パッケージのサプライチェーン管理が直ちに課題になります。
  • 短期は“禁止→代替”の運用切替で生産性が落ちやすい一方、中期は社内LLMゲートウェイ/パッケージ許可制/プロンプトDLPの整備が競争力に直結します。先に仕組みを作った組織が、次の外部AIリスクにも強くなります。

はじめに

アリババが社内開発者に対し、Anthropicのコード支援AI「Claude Code」の使用禁止を通達し、7月10日から施行と報じられています。あわせて、同社は自社の「Qoder」ツールの利用を指示したとされます。報道ではAnthropic側も中国企業およびその支配下の海外企業に対する利用制限やアクセス防止策を強化しているとされ、両者の動きが同時に現場の選択肢を狭める格好になっています。

このニュースは一社のツール選定にとどまらず、AIコード支援をめぐるデータ越境、サプライチェーン、輸出管理、法令順守が一体で動く時代に入ったことを象徴します。現場の開発生産性、SaaSガバナンス、法務・調達・SOCの連携の遅れがそのままリスクに転化します。緊張度は高く、実務に直結する話です。

出典はTechCrunchの報道に基づきます。一次情報の公開範囲が限定的であるため、以下の分析は公開情報からの事実確認と、セキュリティ運用の観点からの仮説・示唆を明示して整理します。

深掘り詳細

事実関係(報道ベース)

  • アリババが従業員によるAnthropic「Claude Code」の使用を禁止し、2026年7月10日から施行と報じられています。自社の「Qoder」ツールの使用を指示しているとされます。
  • 報道では、Anthropic側も中国企業やその所有する外国企業の利用禁止やアクセス防止策を強化しているとされます。
  • 上記はTechCrunchの報道に基づくもので、詳細な社内メモや利用規約の原文は一般公開されていない状況です。

参考:

インサイト(編集部の見立てと仮説)

  • 両側遮断が示すものです。
    • ベンダ側の地理・組織ベースのアクセス制御強化と、ユーザ側の高リスク分類は、AIサービスが国境や契約主体に強く依存する段階に入ったことを示します。これにより、開発者が“とりあえず便利だから使う”といった慣行は通用しにくくなります。
  • 「コード支援AI=開発SaaS」から「越境データ経路」への認識転換が必要です。
    • 開発者はバグ報告、設計断片、APIキー断片、顧客コード断片などをプロンプトに貼り付けがちです。たとえツール提供側が“学習しない”と表明していても、送信・保管・ログ閲覧・司法当局からの開示等のリスクは残ります。従来のソースコード管理・DLP・秘密情報取り扱い規程を、プロンプト入力の瞬間にまで拡張する必要があります。
  • サプライチェーン攻撃の面が強まります。
    • AIアシスタントは依存パッケージや設定例を提案します。提案先に紛れ込むタイポスクワッティングや悪性パッケージの混入は、攻撃者の常套手段です。AI提案経由での依存関係汚染は、現場の“うっかり”と結びつきやすく、可視化とガードレールが必須です。
  • 開発組織の運用負荷は短期に跳ね上がります。
    • 急な切替は生産性低下・シャドーAIの横行を招きます。完全遮断だけでは逆効果になりがちで、認可済み代替の即時提示、LLMゲートウェイ、プロンプトDLP、パッケージ許可制などの代替統制を同時に打つ必要があります。

以上の見立ては、提供された報道情報に基づく仮説を含みます。一次情報の追加公開により解釈が変わる可能性があります。

脅威シナリオと影響

本件は政策・ガバナンスのニュースですが、開発環境は攻撃面でも最前線です。以下は、コード支援AIに伴うリスクの仮説と、MITRE ATT&CKへの対応づけです。

  • シナリオ1: プロンプト経由の機微情報流出です。

    • 典型像: 開発者が顧客固有コード、APIトークン、設計図をプロンプトに貼り付け、外部サービスへ送信します。
    • ATT&CK対応:
      • Exfiltration Over Web Service (T1567) とくに T1567.002/003(クラウド/ウェブサービス)です。
      • Unsecured Credentials: Credentials In Files (T1552.001) からの連鎖流出です。
    • 影響: 知財・個人情報・鍵の漏えい、法規制違反、取引先契約違反です。
  • シナリオ2: 依存パッケージ汚染(AI提案の悪用)です。

    • 典型像: AIが提案した依存ライブラリ名が実はタイポスクワットで、ビルド時に侵入します。
    • ATT&CK対応:
      • Supply Chain Compromise (T1195) とくに T1195.002(ソフトウェア依存関係・開発ツールの妥協)です。
      • User Execution (T1204) により開発者操作を起点に成立します。
    • 影響: 開発端末・CI/CD・本番環境への横展開、サプライチェーン事故の連鎖です。
  • シナリオ3: プロンプトインジェクションによるコマンド誘導です。

    • 典型像: リポジトリ内や参照ドキュメントに埋め込まれた指示で、AIツールが危険コマンドや設定変更を提案します。
    • ATT&CK対応:
      • Command and Scripting Interpreter (T1059) の実行誘導です。
      • Masquerading (T1036) による提案の正当化です。
    • 影響: ビルドスクリプト改変、権限設定の逸脱、CI秘匿値の漏えいです。
  • シナリオ4: LLMエンドポイントを迂回路に使うC2/データ逃がしです。

    • 典型像: 悪性拡張やスクリプトがLLM APIを経由してデータを送出し、通常のC2検知を回避します。
    • ATT&CK対応:
      • Application Layer Protocol: Web Protocols (T1071.001) です。
      • Exfiltration Over Web Service (T1567) の亜種です。
    • 影響: SOCのトラフィック基準で「正当なAI利用」に紛れる形での持ち出しです。
  • シナリオ5: ベンダ規約違反・地政学的要因に起因する突然死リスクです。

    • 典型像: 利用規約や地域制限の変更でAPIが即時停止し、CI/CDや運用フローが崩壊します。
    • ATT&CK対応: 技術的TTPではなく事業継続上のリスクですが、最終的に可用性喪失がセキュリティ事故に波及します。

総合的に、今回の“両側遮断”は上記シナリオの顕在化を抑止する面と、未整備の現場でシャドーAIに流れる面の両刃です。抑止を有効にするには、代替統制の即時実装が鍵になります。

セキュリティ担当者のアクション

時間軸と優先度で整理します。禁止の即日施行に耐える“止血”と、持続的ガバナンスの“体幹作り”を並走させます。

  • 48時間以内(止血策)です。

    • Egress制御とDNS/HTTPブロックで対象LLMエンドポイントを網羅遮断します。シャドー利用を想定してワイルドカードや既知ASNも含めます。
    • 暫定ホワイトリストの代替AIツール(社内/地域適合済み)を周知し、開発停滞を回避します。Qoder等の社内承認済み導線を1クリックで案内します。
    • リスク告知を“開発者向け”に書き換えて再周知します。貼り付け禁止データの具体例(鍵/顧客名/機密コード)、違反時の影響、代替手順を短文・図解で配信します。
  • 2週間以内(最小限のガードレール)です。

    • LLMゲートウェイを導入または暫定構築します。プロンプト/応答のロギング、PII/機密自動編集、秘密情報のリアルタイム検知・ブロックを適用します。
    • プロンプトDLPと秘密情報スキャナをIDE/CLIに組み込みます。APIキー、証明書、顧客名などのシグネチャで即時警告し、送信を遮断します。
    • パッケージ許可制(Allowlist)を施行します。新規依存はセキュリティレビュー必須、CIでの新規導入ブロックを設定します。
    • SOCで“AI利用ベースライン”を策定します。時間帯・部門・転送量の正常像を作り、逸脱検知のルールを作成します。
  • 1〜2カ月(体幹整備)です。

    • プロキュアメント/法務/セキュリティでAIサービスの審査基準を統一します。データ所在、保管期間、学習利用、当局要請対応、SLA/BCP、監査ログ開示の項目を標準化します。
    • 開発ポリシーを“AI前提”に更新します。プロンプトの分類(Green/Amber/Red)と許容/禁止例、レビュー要否、ログ保持期間を明文化します。
    • 依存関係セキュリティを強化します。SCAとリポジトリ保護、タイポスクワット検知、ソースの整合性検証(署名/ハッシュ)、再現可能ビルドを導入します。
    • メトリクス駆動の品質監視を始めます。AI提案コードの脆弱性率、依存追加件数、ビルド失敗率、インシデント起因率などを継続観測し、ガードレールの強弱を調整します。
  • 日常運用(習慣化)です。

    • レッドチームで“AI誤用演習”を四半期ごとに実施します。シナリオは上記4類型(流出・依存汚染・インジェクション・C2隠れ蓑)を回します。
    • 開発者向けに“AI提案の危険信号”チートシートを配布します。未知作者の依存、権限拡張、外向き通信、難読化などを赤旗にします。
    • 監査で“プロンプトと生成物のトレーサビリティ”を確保します。重大障害時に、どの提案を誰が受け入れたかを遡れることが肝要です。

最後に、今回のニュースに表れた空気感は“即応が要る、しかも長引く”です。短期の衝撃は大きく、現場の混乱は避けにくいですが、ここでAIガバナンスの体幹を固めた組織は、次の規制変更やベンダー方針変更にも揺れにくくなります。禁止と同時に“使い方の設計”を前に進めることが、攻めと守りの両立につながるはずです。

参考情報

背景情報

  • i Claude Codeは、Anthropicが開発したプログラミング支援ツールであり、AI技術を活用してコードの生成や修正を行うことができます。しかし、同社は中国企業による利用を制限しており、特にデータの漏洩や不正利用のリスクを懸念しています。
  • i アリババは、Claude Codeを高リスクと見なしており、従業員に自社開発のQoderツールを使用するよう指示しています。この決定は、企業のセキュリティポリシーの一環として、外部ツールの使用に対する厳格な管理を示しています。