2026年4月29日にリリースされたVS Code 1.118から、GitHub Copilotがコードを変更したコミットに自動で共著者として記録されるようになりました。設定はデフォルトでオンです。多くの開発者がコミット履歴に意図しない行が追加されていることに気づき、Hacker Newsで600点以上を集める騒ぎになっています。
この記事でわかること
- VS Code 1.118で何が変わったか
Co-Authored-Byトレーラーの仕組みと限界- 著作権への影響と企業が注意すべき点
- 無効化する設定手順
VS Code 1.118で何が変わったか
1.118のリリースノートには「Copilot added as a Git co-author by default」と明記されています。Copilotがファイルを変更したコミットには、メッセージの末尾に次の行が自動で追加されます。
Co-Authored-By: GitHub Copilot <copilot@github.com>
これはオプトアウト方式です。使いたくない場合は自分で設定を変更しなければなりません。
Microsoftの意図は「AIの関与をコミット履歴に残すことで透明性を高める」というものです。AIが書いたコードを隠すよりも、明示的に記録すべきという考え方です。ただし、その実装方法に多くの批判が集まっています。
Co-Authored-Byトレーラーの仕組みと限界
Co-Authored-ByはGitのコミットトレーラーと呼ばれる仕組みです。コミットメッセージ本文の後にキー: 値の形式で追記するもので、GitHubはこれを解釈して共著者を表示します。
ただし、Gitはこのトレーラーの内容を検証しません。誰でも手動でこの行を追加・削除・改ざんできます。コミット内容と暗号的に結びついてもいないため、「本当にCopilotが関与したか」を事後に証明する手段がありません。
dev.toのエンジニアが指摘するように、「Co-Authored-Byはドアに貼った付箋であり、セキュリティログではない」という状態です（参考）。検証不可能なメタデータを信頼の基盤にすること自体に設計上の問題があります。
著作権への影響
法的な観点での問題はより深刻です。
米国著作権局はこれまで一貫して「非人間の主体は著作権を持てない」という立場を取っており、2023年のThaler v. Perlmutter判決でも同じ結論が示されました。コミットにCopilotが共著者として記録されると、そのコードの著作権帰属に曖昧さが生まれます。
具体的には次のような問題が起きえます。
- コードの完全な著作権が人間の開発者にあるのか不明確になる
- 「著作物への雇用（work for hire）」の分析が複雑になる
- 下流のユーザーやライセンシーが「明確なタイトル（clear title）」を取得できない可能性がある
すでに一部の組織では「1ファイルあたりのAI生成コードを30%以下に抑える」といった内部ポリシーを設けて著作権保護を維持しようとしています。今回のデフォルト設定はそうした組織の記録管理を複雑にする可能性があります。
GitHub上の関連イシュー（#313064）では「Copilotをまったく使っていないのに共著者トレーラーが付く」という報告も複数あります。誤った帰属情報が自動で記録されるリスクも無視できません。
無効化する設定手順
機能を無効にしたい場合は、VS Codeの設定でgit.addAICoAuthorをfalseに変更します。
GUIで変更する場合
Ctrl + ,（macOSはCmd + ,）で設定を開く- 検索ボックスに
git.addAICoAuthorと入力する - チェックボックスをオフにする
settings.jsonで変更する場合
{
"git.addAICoAuthor": false
}
チームで統一したい場合はワークスペース設定（.vscode/settings.json）に追記すると全員に適用されます。ただし、この設定の存在を知らない開発者のローカル環境では引き続きデフォルト値（オン）のままになります。
まとめ
VS Code 1.118から、Copilotの関与がコミット履歴に自動で記録されるようになりました。透明性の向上を目指した変更ですが、検証不可能なメタデータを使う設計と著作権上の曖昧さが課題として残ります。
個人開発での利用では大きな問題にならないケースが多いですが、IPポリシーを持つ企業やOSSプロジェクトでは設定方針を決めておく必要があります。git.addAICoAuthorを明示的に設定し、チーム全員が同じ状態で作業できる環境を整えておきましょう。