development·

Claude Code × Git連携ガイド|コミット・PR・ブランチ操作を自然言語で自動化

Claude CodeでGitの日常操作を効率化する方法を解説。コミットメッセージ自動生成、PR作成、コンフリクト解決、worktree並列開発まで、15個以上のプロンプト例付きで実践的に紹介します。

Claude Code × Git連携ガイド|コミット・PR・ブランチ操作を自然言語で自動化

Git操作の多くは定型作業です。コミットメッセージの作成、ブランチの命名、PRの作成 — これらを「コミットして」「PRを作成して」といった自然言語の指示だけで完結させるのが、Claude CodeのGit連携です。

Claude Codeは、Anthropicが提供するターミナルベースのAIコーディングエージェントで、gitコマンドとghコマンドを直接実行できます。本記事では、日常のGitワークフローをClaude Codeで効率化する方法を、実務で使えるプロンプト例とともに解説します。Claude Codeの基本的な使い方についてはClaude Code完全ガイドを参照してください。

この記事でわかること:

  • Claude Codeがブランチ・diff・コミット履歴をどう認識し、Git操作に活用するか
  • コミットメッセージの自動生成からConventional Commits準拠まで、段階的な活用方法
  • CLAUDE.mdにGit規約を記述し、チーム全員のClaude Codeを同じルールで動かす設定例
  • force pushやrebase -iなど、Claude Codeに任せるべきでない操作の明確な線引き

Claude CodeのGit認識の仕組み

Claude Codeは、プロジェクトディレクトリで起動すると、Gitの状態を自動的に認識します。現在のブランチ名、ステージされた変更、未コミットのdiff、直近のコミット履歴といった情報を読み取り、それらを踏まえた上で操作を提案・実行します。

ブランチ・diff・コミット履歴を自動認識する

Claude Codeに「現在の状態を教えて」と聞くだけで、git statusgit diffgit logの結果を統合した要約が得られます。内部的には、Claude Codeはセッション開始時にプロジェクトの.gitディレクトリを検出し、現在のブランチ名、ステージングエリアの状態、直近のコミット履歴を自動的に読み取ります。

ブランチを切り替えた場合も、Claude Codeは新しいブランチのファイルを参照しますが、会話の履歴はそのまま保持されます。つまり、「先ほどmainブランチで議論した設計方針を、featureブランチで実装して」といった文脈を跨いだ指示が可能です。この仕組みにより、ブランチ間の作業を1つのセッションでシームレスに行えます。

セッションとディレクトリの関係

Claude Codeのセッションは、起動したディレクトリに紐づきます。claude --continueで再開すると、そのディレクトリのセッション一覧から選択できます。claude --resumeを使えば、過去のセッションを一覧から選んで復元することも可能です。

この「セッション = ディレクトリ」の設計が、後述するworktreeによる並列開発を自然に実現する基盤になっています。1つのリポジトリから複数のディレクトリを作れば、それぞれで独立したClaude Codeセッションを走らせることができるからです。

コミットメッセージの自動生成

コミットメッセージの作成は、Claude CodeのGit連携で最も頻繁に使われる機能です。変更内容のdiffを解析し、適切なメッセージを自動生成します。

基本的な使い方

変更をステージした状態で、以下のように指示するだけでコミットが完了します。

変更をコミットして

Claude Codeはgit diff --cachedの内容を解析し、変更の意図を要約したコミットメッセージを生成します。単にファイル名の羅列ではなく、「何を変更したか」「なぜその変更が必要か」を推測した上でメッセージを構成するため、後から履歴を辿る際にも読みやすいコミットメッセージになります。

デフォルトの権限モードでは、コミット実行前に確認プロンプトが表示されるため、メッセージを確認してから承認できます。メッセージに修正を加えたい場合は、「typeをfixに変更して」のように自然言語で指示すれば再生成されます。

ステージされていない変更がある場合でも対応可能です。

すべての変更をステージしてコミットして

Conventional Commitsに準拠させる

チームでConventional Commitsを採用している場合、CLAUDE.mdにルールを記述することでClaude Codeが自動的に準拠します。

# Git規約

## コミットメッセージ
- Conventional Commits形式を使用する: `<type>(<scope>): <description>`
- type: feat, fix, refactor, test, docs, chore, perf, ci
- scope: 変更対象のモジュール名(例: auth, api, ui)
- description: 日本語で簡潔に記述(50文字以内)
- 例: `feat(auth): ソーシャルログイン機能を追加`

この設定により、以下のプロンプトだけでConventional Commits準拠のコミットが生成されます。

この変更をコミットして。scopeはauthで

生成されるコミットメッセージの例:

feat(auth): パスワードリセットのメール送信機能を追加

カスタムスラッシュコマンドで/commitを作る

毎回の指示をさらに省略するには、カスタムスラッシュコマンドを活用します。.claude/commands/commit.mdを作成します。

変更内容を確認し、適切なコミットメッセージを生成してコミットしてください。

ルール:
- Conventional Commits形式に従う
- scopeはディレクトリ構成から推測する
- descriptionは日本語で50文字以内
- 破壊的変更がある場合はBREAKING CHANGEフッターを追加する

これで、/commitと入力するだけで規約準拠のコミットが実行されます。

なお、Claude Codeで生成されたコミットにはCo-Authored-By: Claude <noreply@anthropic.com>のトレーラーが自動付与されます。GitHubのコミット履歴でAIが関与したコミットを識別でき、チーム開発での透明性を確保できます。

ブランチ操作をプロンプトで実行する

Claude Codeは、ブランチの作成・切り替え・マージ・削除を自然言語で操作できます。複雑なgitコマンドを覚える必要はありません。

ブランチの作成・切り替え・削除

ユーザー認証機能用の新しいブランチを作って

Claude Codeは、CLAUDE.mdのブランチ命名規則(後述)に従い、feat/user-authenticationのような適切なブランチ名を生成して切り替えます。

その他のブランチ操作のプロンプト例:

mainブランチに切り替えて
マージ済みのブランチを一覧表示して、不要なものを削除して

ブランチ命名規則をCLAUDE.mdで統一する

チーム開発では、ブランチ命名規則の統一が重要です。CLAUDE.mdに以下のように記述します。

## ブランチ命名規則
- feat/{機能名} — 新機能
- fix/{バグの概要} — バグ修正
- chore/{タスク名} — ビルド・設定変更
- docs/{対象} — ドキュメントのみ
- refactor/{対象} — リファクタリング

これにより、Claude Codeが「新しい機能を実装するブランチを作って」と指示された際に、自動的にfeat/プレフィックスを付けたブランチを作成します。

コンフリクト解決のAI支援

コンフリクトの解決は、Git操作の中でも特に認知負荷が高い作業です。Claude Codeは、コンフリクトの内容を解析し、両方の変更の意図を理解した上で解決策を提案します。

マージコンフリクトとリベースコンフリクトの対応

マージでもリベースでも、コンフリクトが発生した場合の対応は同じです。

コンフリクトを解決して

Claude Codeは、コンフリクトマーカー(<<<<<<<=======>>>>>>>)を含むファイルを検出し、両方の変更内容を読み取り、合理的な統合案を生成します。

意図を指定して解決させる

単純な「コンフリクトを解決して」ではなく、意図を指定することでより精度の高い解決が可能です。

コンフリクトを解決して。API側の変更を優先して、テストは両方残して
コンフリクトを解決して。リモートの変更を取り込みつつ、ローカルで追加したバリデーションは維持して

意図の指定は、特にビジネスロジックに関わるコンフリクトで効果的です。Claude Codeはコードの意味を理解するため、「どちらの変更がより重要か」の判断材料を与えることで、的確な解決が得られます。

解決後の検証手順

コンフリクト解決後は、以下のプロンプトで検証を依頼します。

コンフリクト解決後の変更をレビューして、テストを実行して

Claude Codeは、解決内容のdiffを表示し、関連するテストを実行して問題がないことを確認します。コンフリクト解決は自動化しやすい反面、ビジネスロジックの意図を見落とすリスクがあるため、解決結果のレビューは省略しないことを推奨します。

PR作成・レビューの自動化

Claude Codeはghコマンド(GitHub CLI)を通じて、PR(プルリクエスト)の作成からレビューまでを自動化できます。詳しい設定と運用パターンはPRの自動作成・レビューで解説しています。

PRの作成とテンプレート準拠

ブランチでの作業が完了したら、以下のプロンプトでPRを作成します。

この変更でPRを作成して。レビュアーにはteam-leadを指定して

Claude Codeは、ブランチのコミット履歴とdiffを解析し、PRのタイトルと説明文を自動生成します。リポジトリにPRテンプレート(.github/pull_request_template.md)がある場合は、そのフォーマットに従います。PRの説明文には変更の要約とテスト計画が含まれるため、レビュアーが変更内容をすぐに把握できます。

Draft PRから始めて、実装完了後にReady for Reviewに変更するフローも自然言語で指示できます。

この変更でDraft PRを作成して
PRをReady for Reviewに変更して

セルフレビューをClaude Codeに依頼する

PR作成前のセルフレビューも効率化できます。人間がレビューする前に、明らかな問題を事前に検出しておくことで、レビューの往復回数を減らせます。

PRを出す前にこのブランチの変更をレビューして。セキュリティ問題、パフォーマンス懸念、テスト漏れを重点的にチェックして

Claude Codeは、変更されたすべてのファイルを読み、指定した観点でレビューコメントを生成します。

GitHub Actions連携

Claude Code ActionをGitHub Actionsに統合すると、PRへの@claudeメンションでAIレビューを自動起動できます。セットアップの詳細はPR自動化ガイドを参照してください。ワークフローの基本構成は以下のとおりです。

name: Claude Code Review
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

jobs:
  claude-review:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

チーム開発でのGit規約統一 — CLAUDE.mdの設定例

Claude Codeの強みは、CLAUDE.mdに規約を記述すれば、チーム全員のセッションが同じルールで動作する点です。Gitの規約をCLAUDE.mdに集約することで、ルールの属人化を防ぎます。

コミットフォーマット・ブランチ命名・PRテンプレートを一元管理

以下は、チーム開発用のCLAUDE.md Git規約セクションの実例です。

# Git規約

## コミットメッセージ
- Conventional Commits形式: `<type>(<scope>): <description>`
- type: feat | fix | refactor | test | docs | chore | perf | ci
- description: 日本語、50文字以内
- bodyには「なぜ」を書く

## ブランチ命名
- feat/{機能名}, fix/{バグ名}, chore/{タスク名}
- mainへの直接pushは禁止

## PR
- タイトル: 70文字以内
- 本文: 変更内容の要約 + テスト計画
- Draft PRを先に作成し、実装完了後にReady for Reviewに変更

複数人開発での運用ポイント

CLAUDE.mdはリポジトリのルートに配置し、Gitで管理します。規約を変更した場合はPRを通じてチームでレビューすることで、全員が最新のルールに従った状態を維持できます。新しいメンバーがチームに加わった場合も、CLAUDE.mdを読むだけでGit規約が把握できるため、オンボーディングのコストが下がります。

個人の設定は~/.claude/settings.jsonに、プロジェクト固有の設定は.claude/settings.jsonに記述する二層構造になっています。チームで共有すべきルールはプロジェクト設定に、個人の好み(エディタ設定など)は個人設定に分離することで、柔軟な運用が可能です。

たとえば、プロジェクトの.claude/settings.jsonnpm testgit statusといった安全なコマンドを許可リストに追加することで、Claude Codeの確認プロンプトを減らし、作業効率を高められます。チーム開発でのClaude Code導入も参考にしてください。

Claude Codeに任せてはいけないGit操作

Claude CodeのGit連携は強力ですが、すべてのGit操作を無条件に任せるべきではありません。安全な運用のために、操作の性質ごとに判断基準を明確にしておくことが重要です。

force push・rebase -i・履歴改変の制約

Claude Codeには、対話的な入力を必要とするコマンドを実行できないという技術的な制約があります。git rebase -igit add -iは、エディタが開くのを待ち続けてしまうため使用できません。

ただし、対話的リベースと同等の操作を自然言語で指示することは可能です。

直近5つのコミットを整理して。「fix typo」の2つのコミットはその前のfeatureコミットにsquashして

Claude Codeは、git reset --softやcherry-pickなどの非対話的コマンドを組み合わせて同等の結果を実現します。コンフリクトが途中で発生した場合も、Claude Codeが検出して解決策を提案します。

また、git rebase自体は実行可能ですが、rebase中にコンフリクトが複数発生するケースでは、1つずつ手動で確認することを推奨します。Claude Codeに「各コンフリクトを1つずつ表示して、確認してからrebase --continueして」と指示すれば、ステップバイステップで進められます。

以下の表で、操作ごとの判断基準を整理します。

操作判断理由
git commit任せてOKデフォルトで承認制。メッセージ確認可能
git push任せてOKデフォルトで承認制
git branch -d任せてOKマージ済みブランチのみ削除される
git merge確認推奨コンフリクトの可能性。結果の確認が必要
git rebase確認推奨履歴が書き換わる。コンフリクトの可能性
git stash任せてOKローカル操作で可逆
git push --force任せるべきでないリモートの履歴を破壊する可能性
git rebase -i実行不可対話的入力が必要(技術的制約)
git reset --hard任せるべきでないローカルの変更が不可逆に失われる
git branch -D確認推奨未マージのブランチも強制削除される

権限モードによる安全設計

Claude Codeには複数の権限モードがあり、Shift+Tabで切り替えられます。

  • 通常モード(Default): ファイル編集とコマンド実行の両方に確認を求める。Git操作を始めたばかりの段階ではこのモードが最適
  • 編集自動承認モード(Auto-accept edits): ファイル編集は自動承認し、コマンド実行のみ確認を求める
  • 計画モード(Plan Mode): 読み取り専用。変更を加えず、操作計画の提案のみ行う
  • 全自動モード(Auto accept): バックグラウンド安全チェック付きですべてのアクションを自動実行する。チームの規約が十分に整備され、CI/CDの安全網がある場合に推奨

チーム開発では、.claude/settings.jsonでコマンドの許可リストを定義し、安全なコマンド(git statusgit loggit diff)を自動許可に設定する一方、破壊的操作(force push等)は常に確認を求める設計が推奨されます。Claude Codeのセキュリティと権限管理も合わせて確認してください。

Git hooks × Claude Code Hooksの使い分け

Git操作の品質を担保する仕組みとして、git hooksとClaude Code Hooksの2つがあります。どちらも自動実行の仕組みですが、発火タイミングと用途が異なります。詳細はClaude Code Hooksの実践ガイドで解説しています。

git hooksの役割

git hooks(pre-commit、pre-pushなど)は、gitコマンドの実行をトリガーにシェルスクリプトを実行します。git commitの直前にlintを走らせる、git pushの前にテストを実行するといった用途で、Claude Codeの有無に関わらず動作します。git hooksはリポジトリの.git/hooks/ディレクトリに配置され、huskyやlefthookといったツールで管理するのが一般的です。

Claude Code Hooksの役割

Claude Code Hooksは、Claude Codeのツール操作(ファイル書き込み、コマンド実行)をトリガーにします。つまり、コミットする前の段階 — Claude Codeがファイルを編集した瞬間に — lint・型チェック・テストを走らせることができます。設定は.claude/settings.jsonに記述し、イベントタイプ(PreToolUse、PostToolUse、Notification)ごとに実行するコマンドを指定します。

適材適所の設計

フックトリガー主な用途
git pre-commitgit commit実行時lint、フォーマット、秘密情報の検出
git pre-pushgit push実行時テスト、ビルド確認
Claude Code PostToolUseファイル編集後型チェック、lint(即時フィードバック)
Claude Code PreToolUseコマンド実行前危険なコマンドのブロック

両者は「二重チェック」ではなく「異なるタイミングでの品質ゲート」として機能します。Claude Code Hooksで編集直後に問題を検出し、git hooksでコミット・プッシュ時に最終確認する — この2段構えが、TDDワークフローと組み合わせることでコード品質を高めます。

worktreeを使った並列開発

Git worktreeは、1つのリポジトリから複数の独立した作業ディレクトリを作成するGitの標準機能です。Claude Codeのセッションはディレクトリに紐づくため、worktreeごとに別々のセッションを起動することで、複数のタスクを並列に進められます。

worktreeの基本的な使い方

git worktree add ../project-feat-auth feat/auth

このコマンドで、feat/authブランチ用の作業ディレクトリが../project-feat-authに作成されます。そのディレクトリに移動してclaudeを起動すれば、メインの作業ディレクトリとは独立したセッションが開始されます。

並列開発の典型的なパターン

たとえば、メインの作業ディレクトリでリファクタリングをClaude Codeに任せている間に、worktreeで作成した別ディレクトリでバグ修正に着手するといった使い方が可能です。Claude Codeがタスクを処理している「待ち時間」を、別タスクの作業時間に転換できるのが最大のメリットです。

worktreeの作業が完了したら、以下のコマンドで削除します。

git worktree remove ../project-feat-auth

具体的なセットアップ手順や3つの運用パターンについては、Claude Code Worktreeで並列開発する方法で詳しく解説しています。

1日の開発フローで使うGitプロンプト集

ここまで紹介したプロンプトを、1日の開発フローに沿ってクイックリファレンスとして再整理します。各プロンプトの詳細は、対応するセクションを参照してください。

ソロ開発のフロー

朝 — 作業開始

mainブランチの最新を取り込んで
今日の作業用にfeat/user-profile-editブランチを作成して

午前 — 実装

ここまでの変更をコミットして
この変更でDraft PRを作成して

午後 — 仕上げ

PRを出す前にこのブランチの全変更をレビューして
PRをReady for Reviewに変更して

夕方 — 整理

マージ済みのブランチを一覧表示して、不要なものを削除して

チーム開発のフロー

朝 — 同期

mainの最新を取り込んで、自分のブランチをリベースして
コンフリクトが発生したら、リモートの変更を優先して解決して

開発中 — こまめなコミット

WIP: 認証ミドルウェアの初期実装 としてコミットして

PR作成

この変更でPRを作成して。タイトルは「feat(auth): ソーシャルログイン機能を追加」にして

レビュー対応

PRのレビューコメントを読んで、指摘事項を修正して
修正をコミットして。メッセージは「fix: レビュー指摘のバリデーション漏れを修正」で

よくある質問

Claude CodeでGitのコミットメッセージを自動生成できますか?

はい。git diffの内容を解析し、Conventional Commits準拠のメッセージを自動生成します。CLAUDE.mdでフォーマットとスコープのルールを設定すれば、チーム全体で統一されたメッセージが生成されます。詳しくは本記事の「コミットメッセージの自動生成」セクションを参照してください。

複数人が同時にClaude CodeでGit操作をすると競合しますか?

Claude Codeのセッションは各開発者のローカル環境で独立して動作するため、同時にコミットすること自体で競合は発生しません。ただし、同じブランチに対して複数人がpushする場合は通常のGitと同様にコンフリクトが発生します。ブランチ運用を分離することで回避できます(本記事の「ブランチ命名規則をCLAUDE.mdで統一する」を参照)。

Claude Codeでコンフリクトを解決する方法は?

「コンフリクトを解決して」と指示するだけで、コンフリクトマーカーを含むファイルを検出し、解決策を提案します。「API側の変更を優先して」のように意図を指定すると、より精度の高い解決が得られます。詳しくは「コンフリクト解決のAI支援」セクションで解説しています。

Claude CodeのGit操作で誤ってデータを失うリスクはありますか?

通常モードではgit commitgit pushの前に確認プロンプトが表示されるため、リスクは低くなっています。Claude Codeはファイル編集前にチェックポイント(スナップショット)を作成するため、Escを2回押すか、「元に戻して」と指示すれば前の状態に復元できます。ただし、チェックポイントはローカルのファイル変更のみが対象で、リモートリポジトリへの操作(pushなど)は元に戻せません。

Claude CodeとCursor・CopilotのGit連携の違いは?

2026年5月時点では、Claude CodeはCLIで完結するフルエージェント型のGit連携を提供し、コード変更からコミット、PR作成、レビュー対応まで一貫して操作できます。各ツールの違いは急速に変化しているため、詳しくはClaude Code vs Cursor比較Claude Code vs GitHub Copilot比較の最新記事を参照してください。

CLAUDE.mdのGit規約を途中で変更したらどうなりますか?

CLAUDE.mdを更新すると、次のセッションから新しい規約が反映されます。既存のセッション内でも、CLAUDE.mdを再読み込みすれば即座に反映されます。ただし、既にコミット済みの履歴には影響しません。規約変更はPRを通じてチームでレビューし、全員が最新ルールに合意した状態を維持することを推奨します。

Git worktreeでClaude Codeを使うメリットは何ですか?

Git worktreeで作成した独立した作業ディレクトリごとに別のClaude Codeセッションを起動できるため、複数タスクの並列開発が実現します。メインの作業を中断することなく、バグ修正や実験的な実装を同時に進められます。詳しくはClaude Code Worktreeで並列開発する方法をご覧ください。

まとめ

Claude CodeのGit連携は、コミットメッセージ生成やPR作成といった定型作業を自動化する一方で、最終判断は人間が行う「半自動化」のアプローチです。CLAUDE.mdにGit規約を集約し、権限モードで安全性を確保し、Claude Code Hooksとgit hooksで品質ゲートを設ける — この設計が、個人開発でもチーム開発でも再現可能なAI駆動のGitワークフローを実現します。


Claude Codeを活用したプロダクト開発にご興味のある方は、koromoのプロダクト開発サービスをご覧ください。AI駆動の開発プロセスで、開発期間を大幅に短縮するアプローチをご提案しています。

関連記事