GitHub Copilot反発の本質：開発者はなぜ怒っているのか

火種は「AI補完が便利か」ではない

Copilotへの反発は、AIによるコード補完そのものの是非だけでは説明できない。問題になっているのは、Copilotがどこで、どこまで動くことを許されるのかだ。

The Registerによると、過去12カ月で最も注目を集めたGitHub Communityの議論は、Copilotがリポジトリ内でIssueやPull Requestを生成することをブロックする方法を求めるものだった 。さらに、賛成票で見た2番目に人気の議論は、Copilotによるコードレビューを無効化できない問題の修正を求めるものだった 。

ここには大きな違いがある。個人のエディタ内でコード候補を出すアシスタントなら、使うかどうかは比較的個人の判断に近い。だが、Issueキュー、Pull Request、レビュー画面にAIが現れると、それはプロジェクト運営そのものに関わる。メンテナーにとっての論点は、Copilotの出すコードが良いか悪いかだけではない。自分たちのコミュニティのルールを、プロジェクト側が決められるのかという問題なのである 。

品質への不満が「勝手に動くAI」への不安を強める

不満の一部は、信頼性への疑念からも来ている。GitHub Communityのある議論では、VS Code上のCopilotが信頼できず、プロジェクトに損害を与えたというユーザーの主張が投稿されている 。

もちろん、こうしたスレッドはCopilot全体の品質を測る独立したベンチマークではない。すべてのユーザー、すべてのワークフローで同じ問題が起きているとまでは言えない。しかし、少なくとも一部の開発者が「望んでいないCopilotの動作」を単なる便利機能ではなく、リスクとして受け止めるようになっている背景は見えてくる 。

ツールが避けにくく、しかも一部のユーザーから信頼性を疑われている場合、議論の焦点は「生産性が上がるか」から「同意なく入り込んでいないか」へ移る。

AIエージェント時代には、障害も開発計画の問題になる

GitHub自身のステータスページも、エージェント型ワークフローのリスクを示している。2026年4月22日18時49分から19時32分（UTC）にかけて、Agent HQ CodexエージェントのCopilot Cloud Agentセッションが、Issueのアサインや@copilotコメントメンションなどの入口から開始できない障害が発生した 。GitHubによると、影響を受けたのはCopilot Cloud Agent全体のジョブの0.5％で、失敗したジョブは約2,000件だった。Copilot本体や他のエージェントセッションには影響しなかったという 。

これはGitHub全体が止まったという話ではない。それでも、実作業をAIエージェントに流すチームが増えるほど、Copilotの可用性が開発の前提条件になり得ることを示している。Issueをエージェントに割り当てたり、Pull Requestコメントで作業を起動したりするなら、Copilotの稼働状況はリリース計画や運用設計に関わってくる 。GitHubのニュースページも、最近の可用性インシデントを認め、障害が顧客に影響を与えると述べている 。

MicrosoftのAI戦略が、信頼の前提を変えている

Business Insiderは、MicrosoftがGitHubを強化するためにチームを再編しており、AIコーディングやエージェントに対応するためGitHubを作り替えようとしていると報じた。背景には、CursorやClaude CodeといったAIコーディング分野の競合がある 。

製品戦略として見れば、この方向性は理解しやすい。リポジトリ、Pull Request、Issue、レビューは、コーディング支援AIを組み込む場所として自然だからだ。

しかし文化的には、そこが繊細な点でもある。多くの開発者にとって、GitHubは単なるSaaSではなく、オープンソースやチーム開発の共有インフラに近い。Copilotを避けにくいと感じると、メンテナーはそれを任意の生産性ツールではなく、MicrosoftがGitHubの中心的な立場を使って自社のAI戦略を配布しているものとして受け止めやすくなる 。

AI Creditsで、境界線はコストの問題にもなる

GitHubは、Copilotを使用量ベースの課金へ移行し、6月1日からCopilotの利用がGitHub AI Creditsを消費するようになるとしている 。これは、すべてのチームの支払いが必ず増えることを意味しない。ただし、組織はCopilotがどこで動き、誰が起動でき、AI利用が予算にどう結びつくのかを把握する必要がある 。

すでに共有リポジトリ空間でのCopilotの振る舞いに不満を持っているチームにとって、従量的なAI利用は、GitHubの方向性を「必要なら使える補助ツール」ではなく、「開発ワークフローに組み込まれた課金レイヤー」と感じさせる可能性がある 。

すべての「脱プラットフォーム」話がGitHub離れとは限らない

開発者の自立や大手プラットフォーム依存の見直しをめぐる話題は、GitHub反発の文脈に取り込まれやすい。たとえばDavid Heinemeier Hansson氏のHEYプロフィールでは、同氏は37signalsの共同オーナー兼CTOであり、Ruby on Railsの作者だと紹介されている 。同氏の最近の文章では、37signalsのクラウド離脱について、20台のDell R7625サーバーが届いたことや、クラウドの複雑さから離れる計画が語られている 。

ただし、これらはクラウドインフラに関する投稿であって、GitHubから離脱した証拠ではない。この区別は重要だ。中央集権的なソフトウェアプラットフォームへの懐疑が強まっている可能性はあるが、それは開発者がGitHubから一斉に離れている証明とは別の話である 。

開発チームがいま確認すべきこと

必要なのは、慌ててGitHubを捨てることではない。GitHubとCopilotに関する前提を、チーム内で明文化することだ。

• Copilotの入口を棚卸しする。 Issue、Pull Request、コードレビュー、コメント、Issueのアサイン、@copilotワークフローで、Copilotがどこに現れ、どこで動けるのかを確認する 。
• リポジトリ単位の方針を決める。 どのCopilot機能を許可し、どれを制限または禁止するのかを決める。特にオープンソースプロジェクトや、コンプライアンス上の配慮が必要なリポジトリでは重要だ 。
• 6月1日前にAI Creditsを確認する。 Copilot利用はGitHub AI Creditsを消費するため、エンジニアリング、プラットフォーム、財務の各チームが、利用量の数え方を理解しておく必要がある 。
• AIエージェントの障害を前提にする。 Issueアサイン、Pull Requestコメント、エージェントセッションに開発フローが依存しているなら、Copilotの可用性を運用上の依存関係として扱う 。
• 人間が回せるフォールバックを残す。 重要なリポジトリでは、明確な担当者、文書化されたリリース手順、自動化が失敗したときの復旧経路を維持しておくべきだ。

結論：GitHubはまだ重要だが、信頼は自動更新されない

「開発者がGitHubから大量離脱している」という見方は、ここで確認できる根拠だけでは支えられない。より強い結論は、GitHubが信頼の問題に直面しているということだ。Copilotは共有開発ワークフローの中へ入り込み、MicrosoftはGitHubをAIコーディングとエージェントに合わせて再編していると報じられ、エージェントが実作業を担うほど信頼性インシデントの影響は大きくなり、使用量ベースのAI課金も始まろうとしている 。

GitHubはいまも重要な場所だ。だが、AIプラットフォームとしての性格が強まるほど、開発者やメンテナーは「どこまで自分たちで制御できるのか」を、これまで以上に強く求めることになる。