Claude Code Git連携の仕組みと設定:コミット・PR・権限の実務

Claude Code は、ターミナルの git と gh を使って Git の作業をします。作業前の状態として現在のブランチや git status の結果を読み込み、組み込みの手順に沿ってコミットや PR を作ります。利用者があらかじめ決めておくべき前提は3つです。コミットや PR に付く帰属表示（Co-Authored-By）をどうするか、git commit や git push をどこまで確認なしで走らせるか、変更をどこで確認し、どう戻すかです。この記事では、作業の戻し方を含むClaude Code の公式ドキュメント（2026年10月18日時点）の記述をもとに、それぞれの設定と、うまくいかないときの切り分けを順に説明します。

Claude Code そのものの基本操作はClaude Codeの使い方ガイドにまとめています。ここでは Git に関わる部分だけを扱います。

Claude Code は Git について何を知っているのか？

Claude Code は Claude に、Git に関する情報を2種類渡しています。設定リファレンスの説明では、1つは Bash ツールの説明文に入っている「コミットと PR の書き方の組み込み手順」、もう1つはリポジトリの「git status スナップショット」です。

スナップショットに入るのは次の4つで、会話を始めたときに読み込まれます。

現在のブランチ
メインブランチ
git status の出力
最近のコミット

「今どのブランチにいるか」を毎回説明しなくても Claude が把握しているのはこのためです。ただし、スナップショットはあくまで会話を始めた時点の状態です。

組み込みの Git 手順を外したいとき

自分たちで Git の運用スキルを用意している場合など、組み込みの手順とスナップショットが不要なときは、設定の includeGitInstructions を false にすると両方を外せます。既定値は true です。

{
  "includeGitInstructions": false
}

環境変数 CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS を 1 にしても両方を外せます。この環境変数を設定すると、includeGitInstructions の値より優先されます。

なお、クラウドセッションにはスナップショットが入りません。また、非対話モード（claude -p）で --system-prompt を使ってシステムプロンプトを置き換えた場合も、スナップショットなしで始まります。スナップショットを残したまま指示を足したい場合は、--append-system-prompt を使うよう公式は案内しています。

コミットと PR はどう頼めばいいのか？

公式のベストプラクティスでは、調査、計画、実装の後の最後の段階として「説明的なメッセージでコミットしてプルリクエストを開く」よう頼む流れが紹介されています。

PR の作り方には2通りあります。「変更の PR を作って」と一度に頼む方法と、段階を分ける方法です。公式の手順は次の3段階です。

変更内容を要約させる（例: 認証モジュールに加えた変更を要約して）
PR を作らせる（例: create a pr）
説明文を補強させる（例: セキュリティ面の改善について説明を足して）

段階を分けると、要約の時点で自分の意図と違う変更が混ざっていないかを確かめてから PR に進めます。公式も、提出前に生成された PR を見直し、潜在的なリスクや考慮点を Claude に挙げさせるよう勧めています。

gh CLI を入れておく理由

GitHub を使うなら gh CLI のインストールが勧められています。ベストプラクティスの説明によると、Claude は gh を使って Issue の作成、PR の作成、コメントの読み取りができます。gh が無くても GitHub API は使えますが、認証なしのリクエストはレート制限に当たりやすくなります。

Claude が gh pr create または GitLab の glab mr create で PR を作ると、そのセッションが PR に紐づきます。後から同じ作業の続きをしたいときは、PR 番号を指定して起動すると、その PR に紐づくセッションだけに絞った一覧が開きます。

claude --from-pr 1234

1234 の部分は自分の PR 番号に置き換えます。

コミットメッセージやブランチ名の規約を守らせるには

ブランチ名の付け方や PR の書き方の決まりは、公式が CLAUDE.md に書く内容の例として挙げている項目です。「プレフィックスは feat / fix / docs」「ブランチ名に Issue 番号を入れる」といった規約は、指示のたびに言うより CLAUDE.md に書いておく方が安定します。書き方はCLAUDE.mdの書き方ガイドで扱っています。

コミットに付く「Co-Authored-By」は消せるのか？

消せます。Claude Code が作ったコミットには、既定で Co-Authored-By のトレーラー（コミットメッセージ末尾の定型行）が付きます。PR の説明文にも帰属を示す一文が入ります。既定の中身は次のとおりです。

対象	既定で付く内容
コミット	`Co-Authored-By: <name> <noreply@anthropic.com>`（name はコミットした時点のモデル名）
PR の説明文	`🤖 Generated with [Claude Code](https://claude.com/claude-code)`

これを変えるのが設定の attribution です。commit と pr にそれぞれ文字列を入れると置き換わり、空文字にするとその帰属が消えます。公式の例は次のとおりで、コミットの帰属を差し替え、PR の帰属を消し、セッションへのリンクも外しています。

{
  "attribution": {
    "commit": "Generated with AI\n\nCo-Authored-By: AI <ai@example.com>",
    "pr": "",
    "sessionUrl": false
  }
}

すべての帰属をまとめて消すなら "attribution": false と書く方法もありますが、これは v2.1.281 以降でしか受け付けられません。古い版はこの値を拒否し、その値を含む設定ファイル全体を読み飛ばします。古い版でも読まれる可能性がある設定ファイルでは、commit と pr を両方とも空文字、sessionUrl を false にする書き方を公式は案内しています。

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

以前からある includeCoAuthoredBy は v2.0.62 から非推奨で、attribution に置き換えられています。新しく設定するなら attribution を使います。

もう1点、優先順位があります。CLAUDE.md やメモリに帰属についての指示を書いた場合、それが settings の帰属行より優先されると Claude に伝えられます。例外は、組織が配布する managed settings で帰属行を設定している場合です。

git push や git commit を確認なしにする、または禁止するには？

権限ルールで決めます。公式の例は、npm スクリプトと git commit を確認なしで実行させ、git push で始まるコマンドは拒否する設定です。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

書くときに気をつける点が2つあります。

* はサブコマンドの後に置く。 Bash(git log *) なら git log だけが対象になりますが、Bash(git *) と書くとあらゆる git コマンドを許可します。Bash(git * main) のように * をサブコマンドより前に置いた許可ルールには、起動時に警告が出ます。

拒否ルールは書いた形のコマンドしか止めない。 Bash(git push *) は git push origin main を止めますが、git -C . push origin main や git -c push.default=current push origin main は止めません。公式も、拒否や確認のルールは Claude が普段書く形のコマンドをカバーするもので、プログラムそのものを囲うセキュリティ境界ではないと書いています。コマンドの文字列に依らずに制限したい場合、公式はサンドボックスや PreToolUse フックを案内しています。

一方、git の読み取り専用の形は組み込みの読み取り専用コマンドのセットに含まれており、どのモードでも確認なしで実行されます。

承認した内容はどこに保存されるか

確認ダイアログで「Yes, and don’t ask again」を選ぶと、そのルールは git リポジトリのルートにある .claude/settings.local.json に保存されます。Claude Code はこのファイルに初めて書き込むとき、グローバルの git excludes に追加するので、自分のコミットには混ざりません。手で作った場合は自分で .gitignore に加えます。チーム全員に同じ権限を配りたいなら、.claude/settings.json の方をコミットします。

権限モードの違いはClaude Codeの権限モード、settings.json の置き場所と優先順位はsettings.jsonの解説で扱っています。

auto mode で Claude が止める Git 操作は？

auto mode では、確認ダイアログの代わりに別の分類器モデルが実行前の操作を判定します。公式が「既定でブロック」として挙げている中に、Git に関わる操作が複数あります。

既定でブロックされる操作	公式の記述の要点
force push	そのまま列挙されている
`git reset --hard`、`git checkout -- .`、`git restore .`、`git clean -fd`、`git stash drop`、`git stash clear`	未コミットの変更を捨てる操作とみなされる
`git commit --amend`	HEAD のコミットがこのセッションで作られたものでない場合
PR のマージ	人間が承認していない PR のマージ、Claude 自身の PR の承認、CI チェックの無効化
秘密情報を外に出すコミットや push	実行時に秘密情報や機密データをリポジトリの外へ送る変更

反対に、作業中のリポジトリへの push は、既定ブランチも含めて既定で許可されています（ただし既定ブランチ以外で、production や gh-pages のようにデプロイ先・公開先を示す名前のブランチは、分類器が個別に判断します）。それでも、permissions.deny の拒否ルールはどのモードでも書いた形の push コマンドを止められ、リモート側のブランチ保護も効きます。main への直接 push を避けたいなら、拒否ルールとリモートのブランチ保護を組み合わせます。

分類器が信頼するのは、作業ディレクトリと、セッション開始時に設定されていたリモートです。セッションの途中で git remote add や git remote set-url で追加・変更したリモートは信頼されません。

.git ディレクトリへの書き込みは自動承認されない

.git は「保護パス」に入っています。保護パスへの書き込みは、bypassPermissions モードなどの例外を除いて自動承認されません。公式の説明では、リポジトリの状態や Claude 自身の設定が誤って壊れるのを防ぐためです。保護対象には .config/git や .husky も含まれます。settings の許可ルールでこの扱いを変えることはできません。

Claude の変更はどこで確認し、どう戻すのか？

確認と巻き戻しの手段は、Claude Code 側の機能と Git の2層に分かれています。どちらが何を戻せるかを分けて理解しておくと、誤った安心を避けられます。

確認に使うコマンド

コマンド	何をするか
`/diff`	作業ツリーの変更を Claude Code の中で表示する。Claude の編集と、まだコミットしていない他の変更を並べて見られる
`/code-review`	現在の diff、または指定した PR 番号・ブランチ・パスを、正しさのバグの観点でレビューする。`--fix` を付けると指摘を適用させられる。`/review` は別名
`/security-review`	現在のブランチと origin の既定ブランチとの差分を、インジェクションや認証の問題、データ露出といった脆弱性の観点で分析する。`origin` リモートが必要

/rewind と Git は戻せる範囲が違う

/rewind（別名 /checkpoint、/undo）を使うと、会話やコードを前の時点に戻せます。ただし、チェックポイントが追跡するのは Claude のファイル編集ツールによる変更だけです。Claude が Bash で rm や mv を実行して変わったファイルは、rewind では戻せません。

公式も、チェックポイントはセッション単位の素早い復旧のためのもので、恒久的な履歴や共同作業には引き続き Git のようなバージョン管理を使うよう書いています。rewind の対象外になる Bash 経由の変更もあるため、残しておきたい状態は Git でコミットしておきます。

うまくいかないときはどこを見るか？

公式ドキュメントに原因と対処が書かれている症状を表にまとめます。

症状	原因	対処
フッターに `install gh for PR status` と出る	GitHub の PR ステータス表示にはトークンが必要で、`gh` CLI が入っていない	`gh` をインストールする。`GH_TOKEN` または `GITHUB_TOKEN` でもよい
フッターに `gh auth login for PR status` と出る	`gh` はあるがトークンが無い	`gh auth login` を実行する
PR や MR のステータスがまったく表示されない	`CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC` を設定していると確認自体を行わない	環境変数の設定を見直す
`/security-review` が `ambiguous argument 'origin/HEAD...'` で止まる	ローカルに `origin/HEAD` が無い	下の手順で作る
`claude --worktree` が `Failed to resolve base branch "HEAD"` で失敗する	コミットが1つも無いリポジトリでは worktree を作れない	最初のコミットを作ってから実行する
`git push` を拒否したのに push された	拒否ルールは書いた形のコマンドしか止めない（`git -C . push` などは対象外）	サンドボックスやフックで制限する
`-p` 実行で Claude がブランチを把握していない	`--system-prompt` でプロンプトを置き換えるとスナップショットが入らない	`--append-system-prompt` で指示を足す
`/install-github-app` が通知を出して終わる	このコマンドは github.com のリポジトリ専用で、リモートが gitlab.com や bitbucket.org だと終了する	GitLab なら下の GitLab CI/CD の記事を参照する

/security-review の origin/HEAD エラーを直す

origin/HEAD は、origin リモートの既定ブランチがどれかを記録するローカルの参照です。シングルブランチや CI のチェックアウト、origin が無いリポジトリ、一度も fetch していないリポジトリでは存在しないことがあります。既定ブランチの名前が分かっているなら、次のように作ります。

git remote set-head origin <default-branch>

名前を指定したくない場合は、fetch した上でリモートに既定ブランチを問い合わせます。

git fetch origin
git remote set-head origin --auto

リモートが既定ブランチを示していない場合、--auto は error: Cannot determine remote HEAD で失敗します。そのときはブランチ名を明示する方法に切り替えます。作り直したら /security-review を再実行します。

Git の履歴を読ませる使い方

コミットや PR を作るだけでなく、Git の履歴を情報源として読ませる使い方も公式の例に出てきます。ベストプラクティスには、あるクラスの git 履歴を調べさせ、その API がどう今の形になったかを要約させる指示の例があります。

非対話モードなら、git の出力をそのまま渡すこともできます。

git log --oneline -20 | claude -p "summarize these recent commits"

公式は、非対話モードを CI や pre-commit フック、一括処理に組み込む用途として案内しています。

GitHub 連携・並列作業・CI はどの記事を読むか

この記事は、ローカルの Claude Code が Git をどう扱うかに絞りました。隣接する話題は次の記事で扱っています。

GitHub との連携全般: Claude CodeのGitHub連携
GitHub Actions で @claude に作業させる: Claude CodeとGitHub Actions
GitLab の CI/CD で動かす: Claude CodeのGitLab CI/CD
worktree で複数のセッションを並列に動かす: Claude Codeのworktree並列作業
コミット前後に処理を挟む: Claude Codeのフック機能

本文の設定名、既定値、コマンドは2026年10月18日時点の公式ドキュメントに基づいています。attribution: false のように対応バージョンが決まっている項目もあるため、挙動が説明と違う場合は使っている Claude Code のバージョンを確認してください。

チームでコミット規約や権限ルールをそろえる段階に入ったら、Claude Codeの運用ルール設計が次の参考になります。月額1,980円から参加できる学習コミュニティのAI駆動ラボでは、こうした運用の型を講座として扱っています。