微軟逐步淘汰 Claude Code 內部試點，開發者轉向 Copilot CLI

最近的報導指出，微軟正逐步結束內部對 Anthropic Claude Code 的試點計畫，並引導開發者轉向 GitHub Copilot CLI。表面上看起來像是放棄競爭對手工具，但更合理的解讀其實是：把 AI 編程工作流程整合到微軟自家平台。

整個變動更多是平台策略，而不是單純的成本削減。

五個月的 Claude Code 內部試驗

2026 年初，微軟曾要求數千名員工測試 Anthropic 的 Claude Code，同時與 GitHub Copilot 做對比。參與者不只包括軟體工程師，部分設計師、產品人員與非技術員工也被鼓勵嘗試使用這些 AI 編程工具。

這項試驗橫跨多個工程團隊，目的是觀察不同 AI 編程助手在實際工作流程中的效果。

約五個月後，2026 年 5 月的報導顯示，微軟已開始 取消 Claude Code 的內部授權並結束試點。

目前公開資訊只提到影響範圍達「數千名開發者」，但沒有完整列出具體部門或團隊。

為什麼轉向 Copilot CLI

關鍵差異其實不只是模型，而是平台控制權。

GitHub Copilot CLI 是一個在終端機運作的 AI 開發介面，讓開發者可以在 command line 中直接呼叫 AI 協助、執行代理式工作流程，並與 GitHub 生態系整合。

對企業來說，它還提供更重要的能力：

• 管理員可以統一設定模型與插件
• 可以建立企業級政策與安全規則
• 可以集中部署內部代理或工具

GitHub 近期甚至推出 Copilot CLI 插件的集中管理功能，讓企業管理員能透過單一設定檔，向整個組織分發自訂代理、技能、hooks 或 MCP 設定。

如果開發者各自使用不同的 AI 工具，這種集中治理就很難做到。

不是「OpenAI 打敗 Anthropic」

乍看之下，取消 Claude Code 似乎代表微軟更偏向 OpenAI。但現有證據顯示情況更複雜。

Copilot 本身就是 多模型平台。開發者可以在同一介面中選擇不同模型，例如 Anthropic Claude、OpenAI 系列模型，甚至其他供應商的模型。

Anthropic 的 Claude 其實也已經整合到多個微軟產品。例如從 2026 年起，Claude 模型就能在許多 Microsoft 365 Copilot 商業租戶中使用。

此外，GitHub Copilot 也會定期替換模型版本。例如舊版 Claude Opus 4.1 就被更新的 Claude Opus 4.6 取代。

這顯示微軟並沒有移除 Claude，而是 把 Claude 的使用入口放進 Copilot 平台裡。

成本因素存在，但不是唯一原因

在企業環境中，同時維護多套 AI 開發工具確實會增加成本與管理複雜度，例如：

• 多套授權費
• 重疊的工具鏈
• 不同的安全與合規流程

不過，目前沒有公開資料證明成本削減是主要原因。

相反地，更多跡象顯示微軟的核心目標是 平台整合：

• Copilot 成為 AI 編程的主要入口
• GitHub 成為模型與代理的控制平面
• 企業政策與治理集中在同一平台

這樣可以讓 AI 工具更容易與程式碼庫、安全系統與開發流程整合。

微軟 AI 策略的訊號

這次調整反映出微軟 AI 策略的一個清晰方向：

多模型，但由微軟平台統一分發。

也就是說：

• 微軟掌控開發者介面（Copilot / GitHub）
• 模型供應商在平台內競爭
• 企業客戶透過微軟工具管理所有 AI 能力

這種模式既避免依賴單一模型供應商，也確保平台控制權仍在微軟手中。

整個產業的典型取捨

Claude Code 的試點其實也反映了企業 AI 採用的一個常見矛盾：

最佳單一工具 vs. 原生平台整合。

很多專門工具在能力或創新上可能更強，但大型企業通常更偏好平台原生方案，因為它們更容易處理：

• 採購與授權
• 身分管理
• 安全與合規
• 資料治理
• 企業支援

因此，即使某些開發者更喜歡獨立工具，公司往往仍會集中到一個統一平台。

微軟從 Claude Code 轉向 Copilot CLI，本質上就是這種取捨：

保留最好的模型，但把真正的工作入口留在 GitHub。