> 連載：Claude Code × GitHub運用フロー（全8回）
> ①Issueの書き方｜②clone & branch｜③実装させる対話術｜④動作確認とテスト｜⑤commit & push｜⑥Pull Requestの作り方｜⑦レビューを依頼する｜⑧merge & deploy（今回・最終回）
【連載⑧】Claude Codeのmerge&deployの流れ
レビューの指摘を直したPull Requestを前に、「これ、マージしていいのかな」「マージしたあと何をすればいいんだっけ」と手が止まったことはありませんか。連載最終回では、Claude Codeと一緒にmergeからdeployまで進めた実際の流れを、そのまま貼れるプロンプトつきでまとめます。
Claude Codeでmerge&deployする流れを一言でいうと
結論から言うと、「CIのグリーンを確認→squash mergeでmain反映→ローカルをpullしてから動作確認」という3ステップに、Claude Codeを”確認係”として挟むのが一番安心できました。
マージボタンを押す作業自体はGitHub上でもClaude Code経由でも数秒で終わります。怖いのはその前後です。「CIが本当に通っているか」「マージ後にローカルとリモートがズレていないか」を毎回自分の目だけで確認するのは地味に負担でした。ここをClaude Codeに肩代わりしてもらうと、迷う時間がほぼなくなります。
マージ前に確認する最低限のチェック
私が実際にやっているチェックは次の2つだけです。
1. CIのステータスがすべて成功しているか（`gh pr checks`で確認）
2. レビュー指摘（連載⑦で依頼した内容）が反映済みか
Claude CodeはGitHub CLI（`gh`）がインストールされていれば、`gh pr view`や`gh pr checks`を使ってCI状況やレビューコメントを直接読み取れます。調査した範囲では、Claude Code向けに`/merge-to-main`のようなカスタムコマンドを自作している例もあり、squash mergeとブランチ削除、mainのpullまでを一連の流れとして任せている人もいるようです（自分ではまだカスタムコマンド化はしておらず、都度指示する運用にとどまっています）。
squash・merge・rebase、結局どれを選べばいいのか
調査ベースですが、2026年時点では小〜中規模のチーム開発において、機能ブランチ単位のPull Requestをsquash mergeでmainに統合するのが標準的な選択とされているようです。理由は、mainの履歴が1PR＝1コミットで揃うため、あとから`git log`を見返したときに追いやすいからだと理解しました。
- **squash merge**：複数コミットを1つにまとめてmainに統合。履歴がシンプルになる一方、途中経過のコミットは失われる
- **通常のmerge**：ブランチの分岐・統合をそのまま履歴に残す。共同開発での経緯を追いたい場合に向く
- **rebase**：コミットを1本の線に並べ直す。コミット単位の粒度にこだわりたい人向けで、コンフリクト解決の手間はやや増える
個人開発の範囲であればsquash mergeで困ったことは今のところありません。ただしチーム開発で複数人が同じブランチを触る場合は事情が変わるはずで、この記事はあくまで個人〜小規模利用の実感である点は正直に書いておきます。
実際にmerge&deployまで進めた記録
連載⑦でレビュー指摘を直したPRを例に、実際の流れを再現します。
1. Claude Codeに「CIの状態を確認して」と依頼 → `gh pr checks`の結果がすべて成功と報告
2. 「問題なければsquash mergeして」と依頼 → マージ実行とブランチ削除まで完了
3. ローカルで`git switch main`と`git pull`を自分の手で実行し、最新のmainを取得
4. デプロイは自分のブログ環境の場合、GitHub Actionsのワークフローがmainへのpushをトリガーに自動実行される構成にしているため、マージ後は数分待つだけでした
Before/Afterで言うと、以前は「マージ後にactionsのタブを開いてビルドが通るか祈るように見ていた」状態でしたが、今は「Claude Codeに`gh run list`で直近の実行結果を確認してもらう」ところまで任せられるようになり、待ち時間の不安がかなり減りました。
正直に書くと、デプロイが失敗したときの切り戻し（ロールバック）まではまだ実践できていません。「デプロイが失敗したらどうするか」は次の課題として、まだ試せていない部分です。
読者へのプロンプト例
Pull Requestのマージからデプロイ確認まで、Claude Codeに次のように依頼しています。
このPull Requestについて、以下を確認してからマージしてください。
1. gh pr checksでCIがすべて成功しているか確認する
2. レビューで指摘された内容が反映されているか確認する
3. 問題がなければsquash mergeでmainにマージし、リモートのブランチを削除する
4. マージ後、gh run listで直近のワークフロー実行結果を確認する
マージ・ブランチ削除・本番反映につながる操作を実行する前に、対象PR・CIの状態・差分内容を一覧で示してください。私が確認してから実行してください。不明点があれば推測せず、確認事項として列挙してください。
まだわからないこと・今後の課題
- デプロイ失敗時のロールバック手順はまだ整備できていません
- チーム開発で複数人が同時にマージする場合の運用は未検証です
- 大規模なリポジトリでCIの実行時間が長い場合の待ち方は、今後試していきたいと思っています
シリーズを振り返って
連載①のIssue作成から始まり、clone・実装・テスト・commit&push・Pull Request・レビュー依頼、そして今回のmerge&deployまで、Claude Codeと一緒にGitHub運用の一連の流れを通しでやってみました。振り返ると、一番変わったのは「一つひとつの工程で立ち止まる回数」が減ったことです。次に何をすればいいか迷う時間が、連載を始める前と比べて明らかに短くなりました。
Gitの操作そのものをもっと体で覚えたい方は、実際にターミナルを操作しながら学べるGit学習アプリも公開しています。今回出てきたmerge・push・コンフリクト解消などは、このアプリのドリルでも練習できます。
まとめ
- マージ前は「CIが通っているか」「レビュー指摘が反映済みか」の2点だけ確認すればいい
- squash mergeは個人〜小規模開発では扱いやすい標準的な選択肢
- Claude Codeには`gh pr checks`や`gh run list`でのステータス確認を任せると安心感が増す
- マージ・push・デプロイなど本番に影響する操作は、必ず内容を確認してから実行する
- ロールバック手順など、まだ試せていない課題も正直に残しておく
8回にわたる連載にお付き合いいただき、ありがとうございました。GitHub運用の「怖さ」が少しでも減っていれば嬉しいです。
