AIFreeAPI Logo

Claude CodeのセッションURLとGit帰属表示を安全に確認・停止する

A
10 min readAI Development Tools

コミットにあるセッションURLはGitの著者情報ではありません。記録された層を確認し、必要な項目だけを止め、共有履歴の改変は実際のリスクに応じて判断します。

Claude-Sessionリンク、Co-Authored-By、Gitのauthorとcommitterを分け、監査コマンド、設定スコープ、履歴リスクを示す日本語の濃色インフォグラフィック

公開リポジトリのコミットで Claude-Session: https://claude.ai/code/session_... を見つけても、その一行だけで「会話が一般公開された」「ClaudeがGitの著者になった」とは判断できません。これはコミットメッセージに含まれるセッションリンクです。Git本体のauthor/committer、Co-Authored-Byの共同著者表示、PRの帰属文とは別に扱う必要があります。

Claude Codeの現在の設定は、この違いを三つのキーで表します。attribution.commit はコミットメッセージ、attribution.pr はPR説明、attribution.sessionUrl はセッションリンクを制御します。2026年8月31日時点の Git and attribution設定リファレンス では、cloudまたはRemote Controlセッションから作成するコミット/PRの sessionUrl はデフォルトで true です。

URL、帰属表示、Gitの著者は別の記録

例えば、コミットメッセージの末尾が次のようになっているとします。

text
Fix token refresh race Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_...

下の二行はどちらもコミットメッセージのトレーラーです。一方、Gitのコミットオブジェクトにはauthorとcommitterが別フィールドとして保存されています。ホスティング画面が Co-Authored-By を共同著者として表示しても、authorフィールドを置き換えたことにはなりません。

一つのコミットについて両方を確認するには、次を実行します。

bash
git show -s \ --format='author: %an <%ae>%ncommitter: %cn <%ce>%n%n%B' \ <commit>

最初の二行がGitの識別情報、その後がトレーラーを含むメッセージ本文です。Claude Codeの帰属設定を変更しても、既存コミットのauthor/committer、署名、user.nameuser.emailは変わりません。

claude-cli:// で始まるdeep linkも別物です。これはローカルのClaude Codeを開き、作業ディレクトリやプロンプトを事前入力するためのURLであり、Claude-SessionのHTTPS会話リンクではありません。用途は公式の リンクからセッションを起動する で確認できます。

三つの帰属レイヤー、Gitヘッダーとメッセージの確認、全履歴の読み取り専用検索、独立設定、スコープ、履歴対応を整理した日本語の監査図
三つの帰属レイヤー、Gitヘッダーとメッセージの確認、全履歴の読み取り専用検索、独立設定、スコープ、履歴対応を整理した日本語の監査図

リンクを開かずに全履歴を調べる

まず、現在のcloneから到達できるすべてのrefsを読み取り専用で確認します。

bash
git log --all --grep='^Claude-Session:' \ --format='%h %ad %s%n%(trailers:key=Claude-Session,only)%n' \ --date=short

共同著者トレーラーは独立して抽出できます。

bash
git log --all \ --format='%h %ad %s%n%(trailers:key=Co-Authored-By,only)%n' \ --date=short

Git公式の git log リファレンス でも、--grep はコミットメッセージ、--author--committer はヘッダーフィールド、%(trailers:...) はメッセージトレーラーを扱います。Co-Authored-Byの検索結果を、そのままGitのauthor監査と呼ぶことはできません。

最初のコマンドが空なら、ローカルで到達可能なrefsに一致するトレーラーはありません。ただし、削除済みのリモートブランチ、他人のclone、fork、ホスティング側の古いオブジェクトまで消えた証明にはなりません。通常の予防設定ならここで十分です。実際の機密情報事故が確認された場合だけ、調査範囲をリモートと共同作業者へ広げます。

また、URLが見えることと会話を閲覧できることも同義ではありません。Anthropicの cloudセッション共有設定 は、Team/EnterpriseとPro/Maxで異なる可視性、受信者のログイン、組織やリポジトリのアクセス確認を説明しています。公開コミットではURL文字列が公開されますが、リンク先の可視性は対象アカウントで別途確認します。

セッションリンクだけを止める

AI利用の透明な帰属は残し、会話へのリンクだけを追加しない場合、最小設定は次のとおりです。

json
{ "attribution": { "sessionUrl": false } }

この設定は Co-Authored-By やPRのClaude表示を自動では消しません。三つすべてを表示しない方針なら、各選択を明示します。

json
{ "attribution": { "commit": "", "pr": "", "sessionUrl": false } }

commitpr には空文字列だけでなく、チーム独自の開示文も設定できます。commit はGitトレーラーを含むメッセージ文字列、pr はPR説明の通常テキストです。未設定の項目には、その時点のClaude Code標準文が使われます。

旧キー includeCoAuthoredBy はv2.0.62以降deprecatedです。互換性のため読み取られる場合はありますが、新規設定では attribution を使います。特に sessionUrl は独立した判断なので、古い一つのBooleanで意図を表そうとしない方が安全です。

個人、リポジトリ、組織のどこで決めるか

同じJSONでもファイルによって適用範囲が変わります。

方針設定ファイル対象
自分の全プロジェクトで止める~/.claude/settings.json個人のデフォルト
リポジトリ全体で統一する.claude/settings.jsoncommitして共有するチーム設定
このcloneだけで試す.claude/settings.local.json通常Git管理外のローカル上書き
全員へ強制するManaged settings管理者が配布する最優先ポリシー

Claude Codeの設定スコープ では、通常の優先順位はmanaged、コマンドライン、local、project、userです。ユーザー設定のJSONが正しくても、より上位の値が勝てば挙動は変わりません。

編集後は関連するセッションを新しく開始し、次を実行します。

text
/status

Statusは読み込まれた設定ソースと無効なJSONを表示します。ただし、各キーが最終的にどのファイルから来たかまでは示しません。複数のソースに attribution がある場合は、優先順位の高い順に調べます。

cloudセッションへチーム設定を届けるには、.claude/settings.json をリポジトリにcommitしておく必要があります。手元だけの .claude/settings.local.json は新しいcloud cloneには入りません。検証も、実運用と同じセッション種別で無害なテストコミットを作り、git show -s --format=fuller で確認します。ローカルCLIのテストだけではcloud/Remote Controlの挙動を証明できません。

Claude Codeの三層帰属、監査コマンド、最小設定、優先順位、既存コミットの三段階対応と機密情報時の注意を示す日本語の判断図
Claude Codeの三層帰属、監査コマンド、最小設定、優先順位、既存コミットの三段階対応と機密情報時の注意を示す日本語の判断図

既存コミットを改変する前の三段階

まだ共有していない直近コミットなら、git commit --amend でメッセージを修正できます。より古いローカルコミットは、対象範囲を確認してinteractive rebaseの reword を使います。いずれも新しいコミットIDになりますが、影響をローカルに限定できます。

すでに共有済みで、リンク先が第三者に閲覧できず機密情報もない場合は、将来の追加を止めて履歴を残す方が低リスクなことがあります。見た目だけをそろえる履歴改変は、コミットID、署名、リリース参照、オープン中のPR、共同作業者のブランチへ影響します。

ポリシー上どうしても公開履歴から削除するなら、先に共同作業者と作業時間・対象refs・復旧手順を合意します。GitHubの コミットメッセージ変更ガイド は、新しいIDの生成、force pushによる協業への影響、旧オブジェクトIDから機密メッセージが残る可能性を警告しています。

リンク先を確認し、APIキー、秘密鍵、顧客データなどが実際に閲覧可能だった場合は、帰属表示の問題ではなくインシデントです。まずセッションの可視性を制限し、秘密を失効またはローテーションします。その後にGit履歴とホスティング側の削除を調整します。GitHubの 機密データ削除ガイド が示すとおり、履歴を書き換えるだけでは資格情報は無効化されず、古いcloneから再混入することもあります。

判断の順番は、記録された層を特定する、最小の独立キーを変更する、同じセッション種別で確認する、実際の可視性と機密性に応じて過去を扱う、です。これなら追跡用リンクをGit著者と誤認せず、必要のない履歴破壊も避けられます。