この記事は、 株式会社ヤプリ アドベントカレンダー2025 2枚目 12/15 の記事です。
ヤプリではClaude CodeをVertexAI経由で利用できるようになっていて、希望するエンジニアは全員使えます！
そこで最近、Claude Code で使えるスラッシュコマンド機能を触っていて、「Pull Request の作成って、もう全部任せられるんじゃないか？」と思ったので、 /pr というコマンドを作り、PR 作成をほぼ自動化してみました。
最終的には、ブランチのチェックから、コミットと push、そして Pull Request 本文の作成（テンプレートの埋め込みも含む）までを、まとめて Claude に任せる形になりました。今回はClaude Code 上で /pr と打つだけで、PR を作成してくれるコマンドに着目していきます。
やりたかったこと
やりたかったことはシンプルです。
Claude Code のスラッシュコマンドを用意し、そのコマンドを実行したら、必要なチェックを行ったうえで Pull Request を自動で作成してくれるようにしたい、ただそれだけです。人間がやっていた「テンプレートを開いて、それっぽく文章を書く」という部分も含めて、できるだけAIに押し付けたいというモチベーションです。
実装の流れ
- リポジトリの
root/.claude/commands/配下にpr.mdというファイルを作成する。 - その
pr.mdの中に「Claude にやってほしいこと」を Markdown で記述する。 - Claude Code を立ち上げ
/prと入力して実行する。
やっていることは本当にこれだけで、特別なプラグインの導入や複雑な設定は不要です。
実際に書いた pr.md
具体的には、Pull Request を作成する専用のスラッシュコマンドとして root/.claude/commands/pr.md を用意し、その中に以下のような内容を書きました。
--- description: "プルリクを作成します" --- 次の手順に従って深く考えてプルリクを作成してください。 - 現在作業しているブランチが `release/vXX.XX.X`（X は数字）もしくは `master` もしくは `develop` 以外のブランチであることを確認し、それらのブランチだった場合は処理を中断して、ブランチを変更するべき旨を出力してください。 - `.github/PULL_REQUEST_TEMPLATE.md` を読み込んでください。 - `<!-- -->` で囲った部分はプルリクを作成する開発者用のコメントです。 - テンプレートの形式に従って、変更内容や背景、レビュー観点などを適切に記入してください。 - 必要に応じてコミット、Push を行い、その上で Pull Request を作成してください。 - 実行したコマンドや前提条件があれば、最後に簡単にまとめてください。 （以下略、実際のプロジェクトに合わせてルールを追記してます）
中身のポイントは二つあります。
ひとつは、release/vXX.XX.X 系のブランチや master、develop といった危険なブランチに対しては、直接このコマンドを実行して処理を進めないようにしていることです。
該当するブランチだった場合は処理を中断し、「ブランチを変更してからやり直してください」というメッセージを出して処理を中断するように指示しています。
もうひとつは、.github/PULL_REQUEST_TEMPLATE.md を必ず読み込ませ、そのテンプレートの形式に従って PR 本文を組み立てさせていることです。
この仕掛けのおかげで、リリースブランチや develop に対してうっかり直接 push してしまう事故を防ぎつつ、PR テンプレートを無視したり、書き忘れが出たりすることも減らせます。「テンプレを開いて、人間が毎回同じことを書いている時間」がまるごと消えるので、精神的にもだいぶ楽です。
実際に生成された Pull Request
実際に /pr コマンドを実行してみると、ちゃんと Pull Request が生成されます。
画像の中に埋め込んでいる動画だけは自分で貼付けましたが、それ以外の説明文や概要、テンプレートに沿った各セクションの文章は、すべて Claude が自動で書いたものです。
とはいえ、現状のプロンプトだと、Overview に書かれる内容はまだ弱く、なぜこの変更が必要なのか、どの範囲に影響するのか、リスクはどこにあるのか、といった観点が薄いと感じました。この辺りは、プロンプトの改善ができそうですね。
スラッシュコマンドの拡張の余地
pr.md の内容はただのテキストなので、ロジックはいくらでも盛り込めます。例えば、「Pull Request を作成する際に UI に関する実装が含まれている場合は hogehoge.md を確認してください」といった条件を文面に書いておけば、実装内容を見たうえで必要に応じて hogehoge.md を読ませ、その内容を PR に反映させるような振る舞いも実現できます。
これはつまり、「特定の種類の実装を行ったときには必ずこのドキュメントを読む」「この領域の変更ではこのチェックリストを確認する」といったプロジェクトルールを、スラッシュコマンドの中に埋め込んでしまえる、ということです。ルールを wiki に書いておくだけでは守られないけれど、コマンドにしてしまえば、少なくとも「コマンドを経由する限りは守られる」状態に寄せられます。
さらに、MCP と組み合わせれば、リポジトリ外の仕様書やチケット管理ツールなどにアクセスさせて、「該当する仕様書を読んだうえで PR を作成する」といった流れも現実的に狙えそうです。人間が「あの仕様書どこだっけ」と探し回る代わりに、コマンド側に「この種の変更ならこの仕様書を参照する」というルールを閉じ込めてしまうイメージです。
他にもPush前にClaudeによるコードレビューを実施して合格しないとPushできないようにするなど、改善の余地がまだまだありそうですね！
※余談ですが、Push先の制限は.claude/settings.jsonにて以下のような設定をしても制限可能です！
{
"permissions": {
"deny": [
"Bash(git push *master)",
"Bash(git push *main)",
"Bash(git merge *master)",
"Bash(git checkout master)",
"Bash(rm -rf *)"
],
"allow": [
"Bash(git status)",
"Bash(ls -la)"
]
}
}
まとめ
正直なところ、スラッシュコマンドと聞いたときは「実装が面倒そう」「ちゃんと動かすまでが重そう」と勝手に構えていたのですが、実際にやってみると、必要なのは Markdown ファイルを一枚用意するだけで、とても簡単でした。だからこそ、ここで止まるのはもったいないとも思っています。
今後は、Pull Request 作成だけにとどまらず、定型的な調査や同じパターンを何度も繰り返している作業についても、どんどんスラッシュコマンド化していくつもりです。「人間が手を動かしているだけの作業」は、なるべく「コマンドを叩けば終わる仕事」に変えていきたい。その第一歩として、今回の /pr はわりと良い題材だったと思います。🫡
