Claude CodeのCo-Authored-Byが消えない — attribution設定を書いても上書きされる2026年9月の不具合
attribution設定でCo-Authored-Byを無効化しても、セッション途中のsystem-reminderが「これが優先」と主張して上書きする不具合が2026年9月に複数報告された。原因と、公開PRに紛れ込ませないための回避策をGitHub Issueの実例から整理した。
エンジニアのゆとです。
~/.claude/settings.jsonにattribution設定を書いて、Co-Authored-By: Claudeが付かないようにしたはずなのに、気づいたら公開PRに署名が入っていた——という報告が2026年9月に入って立て続けに上がっている。しかも今回のはこれまでよくあった「設定の書き方を間違えた」パターンではない。設定は正しい。CLAUDE.mdにも明記している。それでもセッションの途中で差し込まれるsystem-reminderが「これ以前の指示より自分が優先される」と言い張り、モデルがそれに従って署名を復活させてしまう、という挙動レベルの不具合だ。原因と、直すまでの間にできる回避策を整理する。
まず結論——設定は合っている。壊れているのはセッション内の優先順位
対象は以下の条件。
- Claude Code 2.1.260前後（Windows・Linux両方で再現報告あり）
~/.claude/settings.jsonまたは.claude/settings.jsonにattribution設定でCo-Authored-By・PRフッターを無効化済み- 加えてCLAUDE.mdや永続メモリにも「署名を付けない」と明記している
この状態でもセッションの途中に、コミットやPR作成の直前で属性情報に関するsystem-reminderが挿入されることがある。その文面には「これ以前の属性に関する指示を置き換える(replaces any earlier attribution guidance)」という一文が含まれており、モデルはこれを「ユーザーの個別設定より、この場で出てきたリマインダーの方が新しく優先度が高い」と解釈してしまう。結果、attribution.commitを空文字にしていても、次のコミットにはしっかりCo-Authored-By: Claudeが付く。
自分がCLAUDE.mdの運用記事で書いた「階層構造のどこに書いても、後から出てくる指示に負けることがある」という話の、かなり分かりやすい実例がこれだ。書く場所が正しくても、実行タイミングでの優先順位付けが崩れると意味がなくなる。
何が起きているか——GitHub Issueで確認できる再現条件
事の発端は2026年9月4日に報告された#92169。Windows・claude-fable-5環境で、永続メモリに保存した「コミットに属性情報を付けない」という指示と、attributionを無効化した設定の両方があったにもかかわらず、セッション途中の属性リマインダーが優先されてトレーラーが付いた、という内容だ。
報告者のコメントには実害も書かれている。ブランチはすでにプッシュ済みでPRもオープン済みだった。直すにはgit filter-branchでの履歴書き換えとforce-pushが必要になり、加えてPR本文も手で編集する羽目になった。
さらに厄介なのは、この報告に対する追試コメントだ。Linux・claude-opus-5という別環境で再現した別のユーザーは、~/.claude/settings.jsonに
{
"attribution": { "sessionUrl": false, "coAuthoredBy": false }
}を設定し、プロジェクトのCLAUDE.mdにも「Co-Authored-Byの行を絶対に付けない」と明記していた。それでも同じように、リマインダーの「これが以前の指示を置き換える」という文言に従ってトレーラーとフッターが追加された。しかもこのケースは公開の上流プロジェクトへのコミット・PRだったため、メンテナーが既に見てしまっている可能性がある状態での修正になったと書かれている。
Windows・Linux、claude-fable-5・claude-opus-5という異なるモデルで同じ現象が起きている時点で、特定のプラットフォームやモデルのクセではなく、リマインダーの挿入ロジックそのものに問題があると考えるのが自然だ。
同じ週にはこの周辺で少なくとも3件の関連報告が別々に上がっている。
#91861（9/3）: 挿入されたシステムリマインダーがユーザーの明示的な無属性設定を上書きし、しかも実行前にユーザーへ警告もなかったという報告#91829（9/3）: リモートセッションからのremote_session_changeという添付情報が、ユーザーのCLAUDE.mdと矛盾するコミット/PR属性設定を静かに押し込んでくる、という報告#92386（9/5）: Bashツールの実行結果に無関係なsystem-reminderが混入し、そこにClaude属性をコミットに追加するよう指示する文言が含まれていたという報告
いずれも「ユーザーが明示的に無効化したはずの属性情報が、セッション内の別経路から復活する」という共通パターンだ。記事執筆時点でこの一連のIssueはすべてOpenのままで、Anthropic側からの修正版アナウンスはまだ出ていない。
正しい設定の書き方を先に確認しておく
不具合の話をする前に、そもそも設定の書き方自体が間違っているケースも多いので先に確認しておく。includeCoAuthoredByは非推奨になっていて、現在の推奨設定はattributionだ。
{
"attribution": {
"commit": "",
"pr": "",
"sessionUrl": false
}
}attribution.commit: コミットに追加されるトレーラー文字列。空文字にすれば何も付かないattribution.pr:gh pr createで作られるPR本文に追加される署名。同じく空文字で非表示にできるattribution.sessionUrl: claude.aiのクラウド実行やRemote Control経由のコミットに付くセッションリンクを省略するかどうか
公式ドキュメントには、includeCoAuthoredByとattributionを同時に設定すると競合するため、新規設定ではattributionだけを使うようにと明記されている。両方とも設定ファイルに残っている場合は、まずどちらか一方に統一するところから始めた方がいい。
設定ファイルの置き場所は~/.claude/settings.json（全プロジェクト共通）、.claude/settings.json（チーム共有、リポジトリにコミットする）、.claude/settings.local.json（自分だけ、コミットしない）の3箇所がある。チーム開発で全員に強制したいなら.claude/settings.jsonに書いてコミットするのが確実だ。
なぜ「リマインダーが優先される」のか
Claude Codeの内部では、コミットやPR作成のような特定の操作の直前に、ふるまいを誘導するための短いリマインダーがモデルのコンテキストに差し込まれることがある。今回問題になっている属性リマインダーは、本来は「デフォルトの属性ルールをこのセッションでは上書きする」ためのものらしく、文面には「これ以前の属性に関する指示を置き換える」という強い言い切りが入っている。
問題は、この文言がハーネス側のデフォルト指示とユーザー自身の設定を区別していないことだ。#92169や追試コメントで指摘されている改善案も同じ方向を向いていて、「リマインダーが上書きしていいのはハーネスのデフォルト値だけで、ユーザーがattribution設定やCLAUDE.mdで明示した指示までは上書きしない」という切り分けを求めている。逆に言えば、現状はこの切り分けがされていないため、ユーザー設定・システムデフォルト・セッション内リマインダーの3者が同じレイヤーで衝突し、後から出てきたものが勝ってしまう。
.claude/settings.local.jsonのようなファイルベースの設定は「静的」で、リマインダーのような「動的」な指示は会話の流れの中で後から追加される。後出しの指示の方が優先されやすいというのは他の不具合報告でも見かけるパターンで、今回はそれが属性情報という地味だが実害の大きい領域で表面化した形だ。
実際に困るシーン——なぜこれが「地味だけど痛い」不具合なのか
自分がこの不具合を軽視できないと思うのは、影響範囲が「見た目が汚れる」だけでは済まないケースがあるからだ。
- OSSへのコントリビューションで、意図せず
Co-Authored-By: Claudeが入ったコミットを上流にプッシュしてしまい、メンテナーが見た後で気づいて履歴書き換え・force-pushをする羽目になる（実際に#92169の追試コメントで報告されている） - 会社のポリシーでAI生成コードへの帰属表示を禁止している場合、意図せず社内規定違反のコミットが残ってしまう
- クライアントワークで納品リポジトリに
Claudeという文字列が入ったコミットログを見せたくない、というケースで信頼を損ねる
一度プッシュしてPRがオープンされた後で気づくと、git commit --amendだけでは済まず、複数コミットに渡っている場合はgit filter-branchやgit rebase -iでの履歴書き換えとforce-pushが必要になる。共同作業のブランチだと他の人の作業を巻き込むリスクもある。だからこそ、プッシュする前に気づける仕組みを作っておく方が、後から気づいて直すより圧倒的に楽だ。
今すぐできる回避策
上流の修正を待つ間、実務でできる対策は大きく4つ。
1. コミット直前にもう一度明示的に指示する
セッションの早い段階でCLAUDE.mdやメモリに書いた指示は、後から出てくるリマインダーに負けることがある。逆に言えば、コミットを依頼する直前のプロンプトで「Co-Authored-Byを付けずにコミットして」と明示的に再指示すると、直近のユーザー発話として扱われるためリマインダーより優先されやすい。毎回書くのは面倒だが、事故を起こしてから履歴を書き換えるよりはずっと安い。
2. pre-commit hookでトレーラーを機械的に削除する
一番確実なのは、Claude Codeの挙動に頼らず、Gitのpre-commitフックでコミットメッセージから該当行を機械的に消してしまうことだ。.git/hooks/commit-msgに以下のようなスクリプトを置く。
#!/bin/bash
# .git/hooks/commit-msg
MSG_FILE="$1"
# Co-Authored-By: Claude で始まる行を削除
sed -i.bak '/^Co-Authored-By:.*Claude/Id' "$MSG_FILE"
# Generated with Claude Code フッターを削除
sed -i.bak '/Generated with \[Claude Code\]/Id' "$MSG_FILE"
sed -i.bak '/🤖 Generated with/Id' "$MSG_FILE"
rm -f "$MSG_FILE.bak"
exit 0実行権限を付けるのを忘れずに（chmod +x .git/hooks/commit-msg）。ただし.git/hooksはリポジトリにコミットされないので、チームで共有したい場合はhuskyやlefthookのようなツールでバージョン管理下に置くか、CI側でも同様のチェックを入れておく。
3. PreToolUse hookでBashのgit commitコマンド自体を検査する
Claude Code自身のHooks機能を使って、git commitが実行される前にコマンド内のメッセージをチェックし、Co-Authored-Byが含まれていたら実行をブロックして書き直しを促す方法もある。上のGitのpre-commit hookが「後から消す」アプローチなのに対して、こちらは「そもそも実行させない」アプローチになる。settings.jsonのhooks設定でPreToolUseイベントにBashコマンドの内容を検査するスクリプトを紐付ける。Hooksの基本的な仕組み（Stdinで渡ってくるJSONの形式やexit codeの意味）を押さえていない場合は先にこちらを読んでおくと組みやすい。
4. チーム開発ではCI側にも同じチェックを入れる
個人のローカル環境だけで対策していても、他のメンバーの環境やCI経由のコミットでは効かない。GitHub Actionsのワークフローに、マージ前のコミットログをgit logで走査してCo-Authored-By.*Claudeを検出したら失敗させるジョブを1つ追加しておくと、ローカルの対策をすり抜けたケースも拾える。
修正を待つ間のチェックリスト
- プッシュする前に
git log -3 --format="%B"で直近のコミットメッセージを目視確認する習慣をつける gh pr create実行後は、PR本文に想定外のフッターが付いていないかブラウザで確認してからレビュー依頼を出す- 上流OSSへのコントリビューションなど、後から履歴を書き換えにくい場面ほど念入りに確認する
- チームで
.claude/settings.jsonにattribution設定を入れている場合でも、「設定してあるから安心」ではなく上記の目視確認を運用ルールにする
関連する設定の総整理
| 設定キー | 役割 | 備考 |
|---|---|---|
attribution.commit | コミットに付くトレーラー文字列 | 空文字で非表示。現在の推奨設定 |
attribution.pr | PR本文に付く署名 | 空文字で非表示 |
attribution.sessionUrl | クラウド実行/Remote Control経由のセッションリンク | falseで省略 |
includeCoAuthoredBy | 旧設定 | 非推奨。attributionと同時設定禁止 |
設定自体は上記の通りシンプルで、書き方を間違えているケースも依然として多い。ただ今回のように「書き方は合っているのに、セッション内部の優先順位のバグで上書きされる」パターンが混ざっているのが2026年9月時点でのやっかいなところだ。両方の可能性を切り分けるためにも、まずは設定ファイルの構文と競合設定の有無を確認し、それでも再現するならこの記事で紹介したIssue群と同じパターンかどうかを疑うという順番で進めるのがいいと思う。
FAQ
attribution.commitを空文字にしてもCo-Authored-Byが消えない場合、まず何を疑うべき?
まずincludeCoAuthoredByが同じ設定ファイルや別スコープ（.claude/settings.local.jsonなど）に残っていて競合していないかを確認する。それでも消えない場合は、この記事で紹介したセッション内リマインダーの上書きパターンを疑い、pre-commit hookでの機械的な削除に切り替えるのが早い。
この不具合はいつ直る?
記事執筆時点（2026年9月上旬）でこの一連のIssueはすべてOpenで、修正版のアナウンスは出ていない。GitHub Issueをウォッチしておくか、git logでの目視確認を運用ルールにしておくのが現実的な対応になる。
チームメンバー全員に強制するにはどこに設定を書けばいい?
.claude/settings.local.jsonは個人設定でコミットされないため、チーム全体に強制するなら.claude/settings.jsonに書いてリポジトリにコミットする。ただし今回の不具合はこのスコープの設定でも再現するため、CI側のチェックも併用した方が確実だ。
設定ファイルを正しく書いても挙動が仕様通りにならない、というのはClaude Codeに限らずAIエージェント全般で起きがちな話ではあるけれど、今回のケースは「後から差し込まれる文章が、自分より先に書かれた指示を勝手に上書きしていい」と思い込んでいる設計そのものに近い問題だと思う。直るまでは、大事なコミットほど機械的なチェックを一枚挟んでおくのが結局一番早い。
