GitHubが、GitHub Copilotによるプルリクエスト内の「agent tips」表示を停止した。発端になったのは、豪州のソフトウェア開発者Zach Manson氏が、自身のプルリクエスト本文にRaycastを案内する文言が差し込まれていたと報告した件である。見た目には小さな誤挿入のようだが、開発者コミュニティが強く反発したのは、販促文の是非そのものより、Copilotが人間の共同作業空間へどこまで介入してよいのかという境界線を揺らしたためだ。
GitHub側は2026年3月31日までに、「GitHubに広告を入れる計画はない」と説明し、問題は「プログラミングロジックの問題」によって不適切な文脈でtipが表示されたものだと述べたうえで、今後はプルリクエストコメントからagent tipsを削除すると表明した。火消しとしての対応は早かったが、2026年3月24日の機能拡張から停止までの短い期間に露出したのは、コード生成AIが“補助”から“編集主体”へにじみ出たとき、設計上の小さな判断がそのまま信頼問題へ転化するという現実である。
発端は1本のPRに入ったRaycast案内だった
最初に広く注目を集めたのは、Manson氏の投稿である。チームメンバーがCopilotにプルリクエスト内のタイプミス修正を依頼したところ、修正そのものに加えて、PRの説明文へ「⚡ Quickly spin up Copilot coding agent tasks from anywhere on your macOS or Windows machine with Raycast.」という案内が追記されていたという。
開発者の目線では、PR本文は単なる説明欄ではない。変更の意図、レビューの前提、判断の経緯を共有する作業文書であり、そこで使われる文章には誰が書いたのかという文責が伴う。そこへ本人が意識していない販促文が紛れ込めば、文書としての信頼性が下がる。レビュー担当者は、その一文が執筆者の意思なのか、ツールの補助なのかを都度見分けなければならなくなる。
Manson氏自身も当初、学習データ汚染やプロンプトインジェクション、あるいはRaycast側の実験的なマーケティングを疑ったと伝えられている。裏を返せば、利用者から見て、その文言が誰の意図で、どの権限によって挿入されたのかが直ちには分からなかったのである。エージェント型の支援AIが開発フローへ深く入るほど、この「出どころの不透明さ」はそれ自体がリスクになる。
単発の不具合ではなく、1万件規模で見つかった
騒動が一気に広がったのは、同種の文面が1件だけではなかったためだ。GitHub検索で同一または近い文言を調べると、PRが1万1000件超、あるいは1万1400件超見つかっている。つまり数件の誤動作ではなく、相当な規模でこれが展開されていたことになる。
さらに重要なのは、PRの生テキストやコード検索から「START COPILOT CODING AGENT TIPS」という隠しコメント付きのブロックが確認されたことだ。これにより、外部サービスが勝手に文言を差し込んだというより、Copilot側のtips機構が何らかの条件で前面に出ていた可能性が高い。また、広告にはRaycast以外にもSlack、Teams、VS Code、Visual Studio、JetBrains IDEs、Eclipseなどを案内する別の定型文が存在するとされており、問題は単一の提携文言にとどまらなかった可能性がある。
もっとも、ここは慎重に扱う必要がある。Raycast向けの文言の件数と、より広い「agent tips」全体の件数は同じではなく、どこまでを同一現象として数えるかは判断が難しいところだ。GitHub自身が詳細な総数を示したわけでもない。現時点で確実に言えるのは、1万件規模で類似事例が観測され、しかもGitHub側が挿入ロジックの存在そのものは否定していない、ということだ。
GitHubは「広告ではない」と説明し、機能自体を止めた
GitHubのDeveloper Relations担当副社長 Martin Woodward氏は、X上でこの挙動を説明した。そこで示された筋立ては比較的はっきりしている。Copilotが自ら作成したPRにtipsを入れること自体は以前からあった一方、2026年3月24日に「Copilotをメンションすれば任意のPRで作業できる」方向へ機能を広げた結果、振る舞いが “不快な物” になった、という説明である。
その後の声明では、「GitHub は現在も将来も広告を掲載する予定はありません」としたうえで、第三者向けリンクが誤った文脈で表示されたのは「プログラミングロジックの問題」によるものだったと述べた。あわせて、今後はプルリクエストコメントからagent tipsを削除するとした。
Copilot担当のPrincipal Product Managerである Tim Rogers氏も、Hacker News上で、tipsは「開発者にagentの新しい使い方を知ってもらう」意図だったと説明している。そのうえで、人間が書いたPRに対し、本人に気づかれない形でCopilotが変更を加えることは “誤った判断” だったと認めた。結果として、Copilotが作成したPRや触れたPRを含め、PR上でのtipsは停止された。
この対応は、少なくとも危機対応としては妥当である。GitHubが問題を仕様として押し切らず、短期間で無効化したことは評価してよい。Raycastとの正式な広告契約を否定した点も、今回の事象をそのまま広告ビジネス化の既成事実として読むべきではない理由になる。
なぜ反発が大きかったのか PR本文は広告面ではなく責任の置き場所だからだ
それでも反発が強かったのは、「広告かtipsか」というラベルの争いでは説明しきれない。PR本文は、コードそのものではなくても、レビュー、監査、責任分担と結びつく作業記録である。そこへ製品の利用促進や連携案内の文言が、ユーザー自身が書いた文章に見える形で混ざれば、文書の責任の所在が曖昧になる。
企業利用の文脈では、この問題はさらに重い。GitHubとCopilotは趣味の補助ツールにとどまらず、有料プランや組織導入の基盤でもある。そこで求められるのは、便利さより前に、誰がどの権限で何を編集したかが追えることだ。今回の騒動は“広告”という強い言葉で広がったが、本質的な争点は、AIエージェントが人間の共有文書へどこまで介入してよいのかという設計原則の欠落にある。
仮にGitHubの説明どおり「広告ではなかった」としても、この論点は消えない。第三者リンク付きの案内文がユーザーのPRに現れれば、多くの開発者は販促と受け取る。ヘルプセンターやサイドバーに出る補助情報と、共同編集文書の本文に混ざる一文は、同じtipでも意味が違う。今回の一件は、その差をプロダクト設計上どこまで厳密に扱うかが、AI機能ではこれまで以上に問われることを示した。
次の争点は性能ではなく、権限と帰属の見える化になる
今回の問題は、Copilotの性能が高すぎたから起きたものではない。むしろ、能力拡張に対して、権限表示と出力の置き場所の設計が追いつかなかった結果と見るほうが自然である。コード提案、レビュー補助、PR作成、コメント生成を一続きの体験として統合したいという発想自体は理解できる。GitHubが目指しているのも、補完AIからエージェント型支援への移行だろう。
だが、その移行が進むほど、利用者は「これは誰の文章なのか」を強く気にするようになる。ユーザー本人の記述、システムの補助表示、AIによる提案、AIによる自動挿入が混線すれば、便利さはあっても安心して任せられる道具にはならない。とりわけ開発現場では、コードの正しさと同じくらい、説明文やコメントの帰属が重要になる。
もしtipsのような補助情報を残すのであれば、置き場所はPR本文ではなく、専用のUI、サイドパネル、あるいはGitHub名義の明示的なシステムコメントであるべきだった。少なくとも、利用者が自分で書いたように見える位置へ置く設計は避ける必要がある。今後のエージェント機能で問われるのは、何ができるかだけではない。どの権限で、どの場所に、誰の名義で作用するのかを、利用者がひと目で理解できるようにしているかである。
2026年3月24日の機能拡張から、3月31日の停止表明までに起きたのは、表面上は短い炎上に見える。だが、この短期間でGitHubが学んだ教訓は軽くない。開発支援AIが「人の代わりに書く」範囲を広げるたびに、性能競争より先に、編集権限の透明性、帰属の明確さ、監査可能性が問われる。今回の即時撤回はダメージを抑えた一方で、次に出てくるエージェント機能の評価基準を、開発者コミュニティ自身が一段厳しくした出来事でもあった。
Sources
