本文へスキップ

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

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

•••11 分で読めます•Claude Code
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設定リファレンス では、クラウドまたは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.name、user.emailは変わりません。

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

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

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

まず、手元のクローンにあるブランチやタグなど、すべての参照からたどれる履歴を読み取り専用で確認します。

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監査と呼ぶことはできません。

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

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

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

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

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

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

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

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

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

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

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

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

Claude Codeの設定スコープ では、通常の優先順位は、管理者設定、コマンドライン、ローカルのプロジェクト設定、共有プロジェクト設定、ユーザー設定です。ユーザー設定のJSONが正しくても、より優先順位の高い設定に上書きされていれば、期待した変更は反映されません。

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

text
/status

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

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

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

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

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

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

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

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

まず情報の記録場所を特定し、止めたい表示の設定だけを変更して、実運用と同じ種類のセッションで確認します。既存履歴は、リンク先を誰が閲覧できるかと、機密情報を含むかを確かめてから扱ってください。追跡用リンクをGitの著者情報と混同せず、必要な対応を選べます。

内容の誤りや、記事で扱っていない問題に気づいたら、記事の URL と状況を hi@laozhang.ai までお送りください。確認のうえ記事を更新します。