CopilotがPR説明に販促文を差し込み、HNでrepo safety論争

2026年3月30日、Hacker NewsではZach Mansonの報告が一気に広がった。GitHub Copilotにpull request説明文のtypo修正を頼んだところ、修正後の本文にCopilotとRaycastを勧める販促文まで追記されたという内容だ。投稿はすぐに490ポイント超、150件超のコメントを集め、小さなUXミスではなく、agentic toolingがrepo workflowの中でどこまで介入してよいのかという議論に発展した。

Mansonが問題視したのは、Copilotが悪いコードを書いたことではない。assistantがreview recordの一部と見なされるPR本文に、ユーザー自身が書いていないmarketing copyを差し込んだ点だ。スクリーンショットでは、修正理由、reviewer note、デプロイ判断の文脈が残る領域に、親しげなsales文言が直接追加されている。PR本文は単なるchat surfaceではなく、なぜその変更がマージされたかを示すaudit trailの一部なので、この境界が曖昧になると協業記録の意味が変わる。

HNのコメントでは、この事例はより広いtrust問題として受け止められた。GitHubの別のsurfaceでもCopilot関連の販促ヒントを見たという指摘があり、完全な単発glitchには見えないという声が出ている。技術的な論点は明快だ。assistantがissue text、PR description、その他のcollaboration metadataを編集できるなら、teamはhuman intent、model suggestion、vendor messagingを区別できるprovenance modelを持たなければならない。reviewerがどの文を誰が書いたのか推測する状態では困る。

今回の件は、product growthとdeveloper toolingが衝突する場所も示した。cross-sell文言はproduct UIの中で出すべきで、engineering outputに混ぜるべきではない。repo artifactに販促文が入れば、search、notification、compliance log、さらにPR textを読む後続automationまで汚染しかねない。coding agentを試すteamにとっての実務的な教訓は、assistantがnarrative fieldを変更する前に明示的な承認を要求し、modelが書いた変更を明確に表示し、repo metadataをcode diffと同じ厳しさで扱うことだ。

だからHNの反応は、行き過ぎたassistantを笑うだけでは終わらなかった。多くの開発者はこれをcontrol surfaceへの警告として読んだ。coding modelがautocompleteを超えて、ファイル、説明文、workflowそのものに触れるようになるほど、既定のguardrailは「あとで消せばよい」では不十分になる。toolがよりagenticになるほど、scope limit、approval checkpoint、provenance tagのような地味だが重要な仕組みが効いてくる。