Claude Codeを使ってPR作成を自動化してみたいけど、勝手にpushされたらどうしよう、変な実装をされたらどうしよう。そんな不安を感じていませんか。
私自身、実際にPR自動作成のスキルを組んで運用してみたところ、最初はいくつも壁にぶつかりました。
この記事では、その中でも特に印象に残ったハマった経験談を交えながら、Claude CodeでPRを自動作成する具体的な手順と、つまずきやすいポイントを解説していきます。
手順だけを知るよりも、実際に何で困ったかを知っておくほうが、遠回りせずに済むはずです。
Claude CodeでPRを自動作成する基本の流れ
まずは基本形から見ていきましょう。カスタムスキルとして .claude/skills/pr-create/SKILL.md のようなファイルを用意し、そこに手順を書いておくと、Claude Codeがその通りに動いてくれます。
まずは、いろいろClaudecodeと対話しながら最終的に落ちついたPR自動作成するskillsです。
---
name: pr-create
description: 変更内容を確認し、プルリクエストを自動作成する。
---
## 手順
1. `git status` と `git diff` で変更内容を確認する
2. 未コミットの変更があれば、適切な日本語のコミットメッセージを生成する
※現在のブランチを確認し、main ブランチの場合は変更内容に応じた feature ブランチ名を生成して切り替える
3. `git add .` でステージング
4. `git commit` でコミット
5. この時点で一度ユーザーに確認をして、承認すれば下記の操作を実行する。
6. `git push` でリモートに反映する
7. `git push -u origin <ブランチ名>` でリモートに push する
8. `gh pr create` でプルリクエストを作成する
- タイトル：変更内容を要約した日本語タイトル
- 本文：変更の概要・目的・確認事項を日本語で記載このスキルファイルを用意しておくだけで、コマンド一つでこの流れをClaude Codeが順番にこなしてくれるようになります。それぞれのステップでどんなことが起きているのか、順を追って見ていきましょう。
ステップ1：変更内容の確認
git statusとgit diffで変更内容を確認する
まずは git status と git diff で、今どんな変更が加わっているのかを洗い出します。ここは人間が最初にやる作業とほぼ同じで、Claude Codeが変更ファイルと差分を読み取り、このあとのコミットメッセージ生成の材料にします。
ステップ2：コミットメッセージとブランチの生成
未コミットの変更があれば、適切な日本語のコミットメッセージを生成する
未コミットの変更があれば、その内容にふさわしい日本語のコミットメッセージをClaude Codeが自動で考えてくれます。
ここで地味に助かるのが、現在のブランチがmainだった場合の挙動です。
mainのままコミットを進めるのではなく、変更内容に応じたfeatureブランチ名を自動で生成し、そこに切り替えてから作業を進めてくれます。
ステップ3、4：ステージングとコミット
git add .でステージング
git commitでコミット
git add . でステージングし、git commit でコミットします。
ここまでは淡々と進む部分で、特につまずくポイントはありません。
ステップ5：ユーザー確認をする
この時点で一度ユーザーに確認をして、承認すれば下記の操作を実行する。
ここが今回のスキルでいちばん大事な一行です。
コミットが終わった時点で、pushに進む前に必ずユーザーへ確認を挟むようになっています。
差分やコミット内容を目視してから、承認してはじめて次のステップに進む仕組みです。
ステップ6〜8：pushとPR作成
git pushでリモートに反映するgit push -u origin <ブランチ名>でリモートに push するgh pr createでプルリクエストを作成する
- タイトル：変更内容を要約した日本語タイトル
- 本文：変更の概要・目的・確認事項を日本語で記載
承認が出たら、git push でリモートに反映し、git push -u origin ブランチ名 でリモート追跡ブランチを設定しつつpushします。
最後に gh pr create で、変更内容を要約した日本語タイトルと、概要・目的・確認事項をまとめた日本語の本文つきでPRを作成します。
ここまで来れば、あとはレビューを待つだけの状態になります。
Claude codeでPRを自動作成する時に実際にハマったこと
ちなみに、最初にClaude codeでPRを自動作成する時に定義していたskillsです。
1. `git status` と `git diff` で変更内容を確認する
2. `git add .` でステージングする
3. `git commit` でコミットする
4. `git push -u origin ブランチ名` でリモートにpushする
5. `gh pr create` でプルリクエストを作成する一見するとこれだけで完結しそうに見えます。実際、私も最初はこの手順をそのままスキルファイルに書いて動かしてみました。ところが、ここからいくつもの想定外にぶつかることになります。
経験談①AIが勝手にpushしそうになって焦った話
最初にスキルを組んだとき、手順は上から順番に流れるだけのシンプルな内容にしていました。
実際に動かしてみると、Claude Codeはコミットメッセージを自動生成し、ステージングを終え、そのままpushのコマンドを発行しようとした瞬間がありました。
思わず「待って」と止めたのを覚えています。
ローカルで閉じている間はいくらでもやり直せますが、リモートに反映されると話は変わります。
不完全な実装や確認前の変更が外部に出てしまうのは、個人開発であってもかなり心理的に嫌なものでした。
スキルファイルに、コミットが終わった時点で一度ユーザーに確認を挟むという一行を追加しました。
たったそれだけで、Claude Codeの動作はガラッと変わります。
コミット後に「以下の内容でコミットしました。pushとPR作成を進めてよいですか」と確認を挟むようになり、差分を目視してからGOを出せるようになりました。
AIにどこまで自律的に動いてもらうかは、どこで人間が介入するかをスキルファイルで明示的に設計することが正解なのだと痛感した出来事です。
経験談②PRを作ったのにマージされずCloseになった話
あるIssueを受けて実装を進め、PRを作成したことがありました。本文を見返すと、一見ちゃんとした実装に仕上がっているように見えました。
データを可視化するダッシュボードを作り込み、グラフや集計テーブルまで用意した力作でした。
しかし私が冷静に見返すと、本当に欲しかったのは統計を眺めるダッシュボードではなく、まとめ記事のMarkdownをそのままコピペできる機能でした。
結局そのPRはCloseし、Issueを起票し直して、別の実装として作り直すことになりました。
原因は、Issueの要件が曖昧なまま実装に突入してしまったことにありました。
Claude Codeは指示を忠実に実装する力はかなり高い一方で、要件の解釈が人間の意図と微妙にズレることがあります。
そのズレが実装後に発覚すると、PRを丸ごと作り直す二度手間になってしまいます。
この反省を受けて、実装前に必ずヒアリングを行い、要件定義書を作成し、詳細設計を経てからユーザーの承認を得るという工程を挟むスキルを新たに導入しました。
承認が出てから初めてIssueを作り、実装に入るという順番に変えたことで、方向性のズレを事前につぶせるようになりました。
PRを自動作成してもらうときに私が感じたこと
Claude codeにskillsを定義しておけば、今やPRも自動に作成できる時代となりました。「便利になったな〜」と感じる一方で、どのようなGitの操作がされてPRが作成されるのか？
AIがどのようにGitのコマンドを叩いているのかちゃんと私が理解しているのか、怪しくなったこともあります。
GitのコマンドはわかっているつもりでもAIが操作した内容を説明できなければ、「これはClaude codeが実行したことなんで私の責任ではありません。」とも言えないですよね。
AIが実行したことはせめて最低限は理解している必要があります。しかもGitのコマンドも全部自動化していたらいずれ忘れていくのが人間です。
体系的にGitのコマンドを学ぶ必要もあるかと思うので、
Gitの操作に少しでも不安がある人は下記の記事で学び直しておくことを推奨します。
まとめ
Claude CodeでPRを自動作成する仕組みは、正しく設計すれば作業時間を大きく短縮してくれる心強い味方になります。
ただし、何も考えずに手順を並べるだけでは、私のように思わぬところでつまずくことになりかねません。
まずは、pushのような取り返しのつきにくい操作の直前に、確認を挟む一行をスキルファイルに追加してみることから始めてみてください。
それだけでも、AIに任せる安心感がかなり変わってくるでしょう。
コメント