Claude CodeでつくるGitワークフロー：コミットとPRを自動化（2026年）
Claude Code は git ワークフローのほぼ全体を実行できます。差分を読んで適切な Conventional Commits 形式のコミットメッセージを書き、雑多に積み上がった変更をきれいなアトミックコミットへ分割し、コミット前にシークレットをスキャンし、gh でプルリクエストまで作成します。すべて自然言語の指示だけで完結します。中心となる 4 ステップは次のとおりです。(1) git と gh auth login をセットアップする。(2)「conventional commits でこれらの変更をコミットして」。(3)「これを type/scope ごとにアトミックコミットへ分割して」。(4)「pr を作成して」。本ガイドでは各ステップを、コピペで使える CLAUDE.md テンプレートと /commit スラッシュコマンドとともに解説します。
Claude Code は自分でコミットや PR を作成できますか？
はい。しかも追加インストール不要の組み込み機能です。 Claude Code は Bash ツールを通じて git と gh を呼び出します。ですから「変更をコミットして」と伝えるだけで、git status と git diff を実行し、文脈を読み取ってからコミットメッセージを起草します。「pr を作成して」と言えば gh pr create を実行し、あなたのコミットからタイトルと本文を生成します。
最低限の要件は次のとおりです。リポジトリが git init で初期化されていて、あなたがその中にいること。PR を開くには、ログイン済みの gh CLI（GitHub CLI）も必要です。無くても Claude Code は問題なくコミットできます。ただしその場合は PR を代わりに開けないだけです。Anthropic の共通ワークフローのドキュメント（2026/08/09 閲覧）によれば、これらは公式にサポートされたフローであり、サードパーティのハックではありません。
最初に信頼性について一言。Claude Code は Bash ツールの権限レイヤーを介して git を操作するため、書き込み系のコマンド（commit、push）はすべて、事前に許可していない限りあなたの承認を求めます。あなたが頼まない限りリモートへ push はしません。とはいえ本記事の最後で触れるとおり、確実を期すために CLAUDE.md にもその旨を明記しておくべきです。
ステップ 1 - セットアップ：git、gh CLI、認証
git をエージェントに委ねる前に、3 つの点を確認します。ターミナルを開いて（あるいは Claude Code に実行させて）次を確認してください。
git --version
gh --version
gh auth statusgh がインストールされていないと表示された場合は、GitHub CLI をインストールして一度だけログインします。
# macOS
brew install gh
# Windows
winget install --id GitHub.cli
# After installing, log in (opens a browser to authenticate)
gh auth loginGitHub.com を選び、次に HTTPS を選び、ブラウザで認証します。これが済むと gh はトークンを保持し、あなたの代わりに PR を開けるようになります。最後に、正しいリポジトリの作業ブランチにいることを確認します。
git rev-parse --is-inside-work-tree # true if this really is a git repo
git branch --show-currentヒント：main で直接作業しないこと。まずブランチを作りましょう。Claude Code に頼むこともできます。「feat/checkout というブランチを作って切り替えて」。きれいなブランチにしておくと、最後の PR ステップがずっとすっきりします。
ステップ 2 - 適切な Conventional Commits を自動作成する
ここが Claude Code の真骨頂です。コーディングを終えたら、自分でメッセージを打つ代わりに、こう指示します。
commit the current changes using conventional commitsClaude Code は git status と git diff --staged（およびステージ前の差分）を実行し、あなたが実際に変更した内容を分析してから、正しい形式でメッセージを書きます。
type(scope): short description in the present tense
- bullet detail if needed
- the reason for the change, not just a file listよく使う Conventional Commits の type の値は次のとおりです。
type | 使う場面 | 例 |
|---|---|---|
feat | 新機能を追加するとき | feat(auth): add Google sign-in |
fix | バグを修正するとき | fix(cart): correct total when a discount code applies |
docs | ドキュメントのみ | docs(readme): add setup instructions |
refactor | 挙動を変えないコード変更 | refactor(api): split handler into its own module |
chore | 雑務、設定、依存関係 | chore(deps): bump eslint to v9 |
test | テストの追加や修正 | test(cart): add expired-discount-code case |
より質の高いメッセージのためのヒント：コミットしたい部分を正確にステージ済み（意図的な git add）であれば、Claude Code はステージされた差分に忠実になり、推測が減ります。具体的に指定することもできます。「コミットして。scope は 'checkout'、ファイルの列挙ではなく、なぜ変わったかに焦点を当てて」。変更が起きた理由について与える文脈が多いほど、後で履歴を読む人にとってメッセージは有用であり続けます。
「Co-Authored-By」行について：デフォルトでは Claude Code はコミットの末尾に Co-Authored-By: Claude <...> のような帰属表示を付けることがよくあります。個人リポジトリやサイドプロジェクトなら、残しておいても無害で透明性があります。しかしコミット規約が厳しい会社のリポジトリ（あるいは commitlint でメッセージ形式を検査する CI）では、無効にしたい場合があります。最も簡単な対処は CLAUDE.md にルールを 1 つ置くことです。「コミットメッセージに Co-Authored-By 行や AI の署名を一切付けないで」 — Claude Code は従います。これはリポジトリのポリシー判断なので、チーム全体で一律に切り替える前にチームと合意してください。Claude Code でよく使う git コマンドの手早い参照が欲しい場合は、Claude Code チートシート に便利な早見表があります。
ステップ 3 - type/scope ごとにコミットを分割する（自動分割）
実際には、変更が 1 つだけということはめったにありません。1 回のコーディングセッションで、機能追加とバグ修正とドキュメント更新を一度にやることもあります。それを全部 1 つの巨大なコミットに詰め込むとレビュアーは苦しみ、revert すると無関係な変更まで巻き込みます。Claude Code が代わりに分割してくれます。
these changes span several types. Split them into separate atomic
commits by type/scope, one type of change per commit差分をトピックごとにまとめ、各グループをステージし（git add -p またはファイル単位）、1 つずつコミットを作成します。混在した差分は次のようになるかもしれません。
feat(payment): add VietQR payment flow
fix(payment): correct amount rounding
docs(payment): note the SEPAY_KEY environment variable価値がある理由：各アトミックコミットはレビューの独立した単位となり、履歴は明快に読め、git revert が必要になったときは、他に触れずに壊れたものだけを取り除けます。これはほとんどのガイドが触れないテクニックですが、「AI に何でもコミットさせる」と「AI に几帳面な開発者のようにコミットさせる」の大きな違いになります。1 つ注意点：承認する前に提案されたコミットにざっと目を通してください。ときどき、引かれた scope の境界があなたのモジュール構造と一致しないことがあり、その場合は「最初の 2 つのコミットをマージして」と言えば済みます。
ステップ 4 - コミット前にシークレットをスキャンする
エージェントにコミットさせることの、ほとんどのガイドが触れない実際のリスクがここにあります。エージェントは .env、API キー、トークン、データベース接続文字列をうっかりコミットに紛れ込ませることがあり、いったん履歴に入ると、きれいに取り除くのは面倒です。コミット前に、スキャンを依頼しましょう。
before committing, scan the staged files for any secrets:
API keys, tokens, passwords, connection strings, or a stray .env file適用する価値のある安全チェックリスト：
.env、*.pem、*.keyをブロックする.gitignoreをリポジトリの最初から用意する。- Claude Code にステージ済み差分を検査させる。毎回のコミット前に、キーやトークンのような文字列がないか確認する。
- pre-commit フックをインストールする。git のレイヤーでブロックし（たとえば gitleaks や git-secrets）、エージェントだけに依存しないようにする。
- すでにシークレットをコミットしてしまった場合：そのトークンは漏洩したものとして扱い、今すぐローテーションする。ファイルを削除して上からコミットするだけでは済みません。
この部分を完全に自動化するには、スキャンをコミット前に走るフックへ移せます。自動チェックを組み込む方法は Claude Code のフックの使い方 を参照してください。鉄則：git のレイヤーにブロッキング層を置かずに、履歴への書き込み権限をエージェントに完全に委ねてはいけません。
ステップ 5 - gh でプルリクエストを自動で開く
コミットがきれいになったら、PR を開くのは一文です。
create a prClaude Code は（許可すれば）ブランチを push し、gh pr create を実行し、ブランチのコミットからタイトルと本文を起草します。リポジトリに PR テンプレートがあれば、変更概要やチェックリストも含みます。より具体的に指定することもできます。「develop ブランチに対して PR を開いて、実行したテストを明記して」。
Anthropic のドキュメントにある気の利いたヒント：gh pr create で作成した PR は、それを生み出した Claude Code セッションに自動的にリンクされます。後で再びレビューするとき、次のコマンドでその正確なセッションの文脈を開き直せます。
claude --from-pr 1234レビュアーがコメントを残し、元の完全な文脈を覚えたまま Claude Code に作業を続けさせたいときに、とても便利です。
このステップでより踏み込んだ GitHub 操作が必要な場合 — issue の読み取り、コメント、セッション内でのレビュー依頼の管理など — は、gh だけに頼るのではなく GitHub MCP を Claude Code と組み合わせてください。MCP を使うと、Claude Code は CLI コマンドを実行するだけでなく、GitHub の完全な文脈を「見る」ことができます。
CLAUDE.md と /commit スラッシュコマンドで標準化する
自然言語の指示は手早いですが、毎回「conventional commits、push しない、AI 署名なし」と繰り返さなければならないなら、固定のルールにしてしまいましょう。次のブロックをリポジトリのルートにある CLAUDE.md ファイルに置いてください。Claude Code は毎セッションこれを読みます。
## Git Rules
- Commit using Conventional Commits: type(scope): description (present tense).
- Types to use: feat, fix, docs, refactor, chore, test.
- Split a mixed diff into atomic commits by type/scope.
- Scan for secrets (API keys, tokens, .env) before every commit.
- Do NOT run git push on your own; push only when I explicitly ask.
- Do NOT add a Co-Authored-By line or any AI signature to commit messages.
- Scope names follow the repo's module/folder names.このファイルを上手に書く方法は、CLAUDE.md に git ルールを書くガイドを参照してください。次のステップは、プロセス全体をカスタムスラッシュコマンドで包み、チーム全員がまったく同じフローを 1 つのコマンドで実行できるようにすることです。.claude/commands/commit.md というファイルを作成します。
---
description: Conventional commit, atomic split, secret scan
---
Review git status and git diff. Scan the staged files for secrets.
Split the changes into atomic commits by type/scope.
Commit using Conventional Commits. Do NOT push.それ以降、チーム全員がただ /commit と打つだけで同一の挙動が得られ、規約外のコミットはなくなります。これこそが「個人の小技」を「チームの標準」に変える方法です。
上級ワークフロー：worktree、PR レビュー、CI
慣れてきたら、生産性をさらに一段引き上げるいくつかのテクニックがあります。
並列 worktree。メインの作業ディレクトリを乱さずに、Claude Code に独自のブランチで機能を作らせるには、worktree を使います。
claude --worktree feature-auth2 つの worktree にまたがって、一方のセッションでバグを修正し、もう一方で機能を作る、といった作業を互いに邪魔せず並行して進められます。
pre-commit / CI へパイプする。Claude Code は -p で非対話的に動くので、スクリプトに組み込めます。たとえば、最近のコミットを changelog やレビュー用に要約するには次のようにします。
git log --oneline -20 | claude -p "summarize these recent commits into a changelog"スタックド PR。大きな機能が複数の依存し合う PR に分かれるとき（PR B がまだマージされていない PR A の上に積まれる）、Claude Code にスタックしたブランチ連鎖を作らせ、正しい親子順で PR を開かせることができます。これによりレビュアーは 1 つの巨大な PR ではなく小さな塊を承認でき、まさに既製の git スキルが多くの反復作業を省いてくれる場面です。
マージ前に PR を自己レビューする。マージを押す前に、Claude Code に差分を読ませてロジックのバグ、エッジケース、脆弱性を探させましょう — マージ前に Claude に PR をレビューさせる方法を参照してください。リポジトリの CI と組み合わせれば、二層のチェックが得られます。マシンがテストを走らせ、AI が変更の意味を読みます。役割は分けておきましょう。エージェントはしっかりした一次レビューをしますが、最終的なマージの判断は、とくにセキュリティやデータに触れる変更では、やはり人間の目を通すべきです。
既製スキルで git を高速化する（AgentKit の ak-git）
この記事全体は基本的に、自分でそれを組み立てる方法を教えるものです。プロンプトを書き、CLAUDE.md のルールを設定し、スラッシュコマンドを作る。そのやり方でまったく問題なく、しかも無料です。ですが、各パーツを手作業で組み立てたくないなら、この記事の 4 つの作業 — conventional commits、type/scope による自動分割、シークレットスキャン、スタックド PR — をまさに 1 回の呼び出しで行う ak-git という既製の git スキルがあります。
混同を避けるために一言：
ak-gitは AgentKit の一部です — agentkit.best にある Claude Code 向けのキット（akCLI）で、OpenAI の「AgentKit」とは別物です。両者を取り違えないでください。
ak-git は Engineer Kit（$99、サイトに定期課金の記載はありません）に含まれます。他に何が入っているか知りたい場合は、決める前に Engineer Kit レビュー を読んでください。正直に言うと、この git ワークフローを動かすのに何かを買う必要はありません — この記事の内容はすべて素の Claude Code で動きます。キットの価値は、セットアップの手間を省き、チーム全体で挙動を一貫させられることにあります。
プロンプトとスラッシュコマンドを自分で作るのは省きたいですか？ ak-git は conventional commits、自動分割、シークレットスキャンを 1 つのスキルにまとめています — Claude Code の中でそのまま使えます。
よくある失敗と安全のヒント
エージェントに git を任せるのは便利ですが、いくつかおなじみの落とし穴があります。壊れやすいポイントと、その対処法は次のとおりです。
| 問題 | 対処法 |
|---|---|
| コミットが「大きすぎ」て、複数種類の変更が混ざる | アトミック分割を依頼する（ステップ 3）、または CLAUDE.md に自動分割ルールを設定する |
Claude が予期せず git push を実行する | CLAUDE.md に「自分で push しない」ルールを追加する。push コマンドを事前許可しない |
| メッセージの scope が間違っている（モジュール名の不一致） | CLAUDE.md にフォルダ単位の scope 規約を明記する。「scope を … に変えて」で手早く直す |
| rebase 中のコンフリクト | Claude に各コンフリクトを説明させてから解決させる。ただし最終結果はあなたが承認する |
| 帰属表示を誤った場所で／一貫性なく無効化する | リポジトリ単位（CLAUDE.md）で一度決める。セッションごとに変えない |
| うっかりシークレットをコミットした | トークンを直ちにローテーションする。履歴に残るのでファイル削除だけでは不十分 |
覚えておくべき正直な限界：Claude Code はあなたほど深くビジネスロジックを「理解」しているわけではないので、そのメッセージはなぜより何を変えたかをうまく説明することがあります。重要なコミットでは「なぜ」を自分で加えてください。そして承認前には必ず差分をレビューすること。エージェントは速いですが、履歴に対する責任はやはりあなたにあります。
よくある質問（FAQ）
Claude Code は自分でリモートへ push しますか？
いいえ、頼まない限りしません。git の書き込みコマンドはすべて Bash ツールの権限レイヤーを通り、あなたが言わない限り Claude Code は push しません。念のため、CLAUDE.md に「自分で git push しない」ルールを追加してください。
gh CLI をインストールする必要はありますか？
コミットには不要です — git だけで十分です。ただし Claude Code 自身が gh pr create でプルリクエストを開くには、gh をインストールし gh auth login でログインしておく必要があります。
コミットに「Generated with Claude」行は入りますか？どう無効化しますか？
デフォルトでは通常、Claude をクレジットする Co-Authored-By 行が入ります。無効にするには CLAUDE.md にルールを追加します。「コミットメッセージに Co-Authored-By 行や AI の署名を一切付けないで」。Claude Code はそれを外します。
変更の山を複数のコミットに分割させるにはどうすればいいですか？
「これらの変更を type/scope ごとにアトミックコミットへ分割して」と指示します。Claude Code は差分をトピックごとにまとめ、各グループをステージし、変更の種類ごとに別々のコミットを作成します。
プライベート（ドラフト）プルリクエストを開けますか？
はい。「PR をドラフトで作成して」と言えば、Claude Code は gh pr create の実行時に対応するフラグを付けます。対象ブランチやレビュアーを指定することもできます。
GitLab や Bitbucket でも動きますか？
conventional commits、コミット分割、シークレットスキャンは、どの git リポジトリでも動きます。自動 PR ステップだけが gh（GitHub 専用）に依存します。GitLab / Bitbucket では対応する CLI（たとえば glab）を使うか、手動で行ってください。
まとめと次のステップ
Claude Code を使った git ワークフローは 4 ステップに集約されます。git と gh をセットアップし、適切な conventional commits を書き、アトミックコミットへ分割してシークレットをスキャンし、そして gh で PR を開く。ルールを CLAUDE.md と /commit スラッシュコマンドに入れれば、チーム全員が 1 つの標準を共有します。次は、より踏み込んだ GitHub 操作のために GitHub MCP を組み込み、マージ前に Claude に PR をレビューさせましょう。自分で組み立てる部分を省きたいなら、AgentKit バンドル — 現在 $149（$198 から）に、このワークフローをそのまま実行する ak-git スキルが付いています。