UPSIDER Tech Blog

Git 操作を Claude Code に任せたら、開発スピードが上がった話：AIで変わるプロダクト開発現場 登壇レポート

AI Event

こんにちは。支払い.comチームでフロントエンドエンジニアをしている村上です。

先日開催された、SalesNow さん主催・WHERE さん共催のイベント「AIで変わるプロダクト開発現場 〜開発プロセスとナレッジ運用を加速させる実践知〜」に登壇し、僕が支払い.comチームで実際に取り組んでいる Git 操作のAI自動化 についてお話ししました。

登壇では時間の都合もあり、どうしても駆け足になってしまったので、この記事では、スライドの中身も含めて、もう少し丁寧に解説したいと思います。

connpass.com

プルリクを作る「だけ」で、なぜこんなに時間がかかるのか

まず最初に共有したのは、日々の開発の中でずっと感じていた違和感です。

プルリクを作る作業って、地味に時間がかかりませんか？

支払い.comのチームでも、一般的なフローと同じように

  • ブランチを作る
  • コミットする
  • プッシュする
  • プルリクを作成する

という流れを踏んでから、誰か一人にApproveしてもらい、マージしています。

フロー自体は普通なのですが、問題はその中身です。 実際に時間を使っているのは、コード変更そのものではなく、「ブランチ名を考える」「コミットメッセージを書く」「プルリク本文をまとめる」といった“文章を考える時間”でした。

特にフロントエンドの仕事では、ちょっとした文言変更やスタイル調整のような「小さい変更」を頻繁に行います。
変更は数行なのに、

  • ブランチを切って
  • ちゃんとした名前を付けて
  • コミットメッセージを考えて
  • プルリクテンプレートに沿って本文を書く

という一連の作業をフルでやると、「コードを書いている時間より、プルリクを準備している時間の方が長いのでは？」という状態になってしまうことがありました。

気づいたら、ブランチ名に悩んで数分、コミットメッセージを眺めて数分。「いや、これはさすがに面倒だな」と本気で思うようになりました。

解決の方向性：プルリク作成までを「丸ごとAI」に任せてみる

そこで試してみたのが、プルリク作成までの作業をまるごとClaude Codeに任せるというアプローチです。

その中でも今回使ったのは、次の二つでした。

1つ目は「カスタムスラッシュコマンド」
あらかじめ手順を書いておくことで、「/ship」のような一つのコマンドで、複数ステップの作業を一括で実行できます。

2つ目は「Skills」
ルールやナレッジをMarkdownで定義しておき、それをAI側から参照させることで、出力のブレを抑えたり、チームごとのお作法を守らせたりすることができます。

この二つを組み合わせることで、「ブランチ作成 → コミット → プッシュ → プルリク作成」という4ステップを一つのコマンド「/ship」で自動化しました。

/ship コマンドの全体像

スライドでは、「/ship コマンドの対象範囲とskillの役割」として、4ステップをこう整理していました。

  • STEP1: git checkout -b（ブランチ作成）
    → skill: branch-naming を利用

  • STEP2: git add ＋ git commit（コミット）
    → skill: conventional-commits を利用

  • STEP3: git push -u origin（プッシュ）
    → skillなし（素直にpushするだけ）

  • STEP4: gh pr create（プルリク作成）
    → skill: pr-template を利用

/ship を叩くと、この4つが上から順番に実行されます。
つまり、「とりあえず変更が済んだ状態」で /ship を呼ぶだけで、ブランチ名の提案からプルリク作成までが一気に終わる、というイメージです。

Skill 1：branch-naming — ブランチ名の悩みをゼロにする

最初のSkillは「branch-naming」です。名前の通り、ブランチ命名のルールを定義しています。

branch-naming.md では、feature / fix / refactor / hotfix といったプレフィックスと、簡潔な英語の description を組み合わせる、というルールを書きました。

たとえば、

  • feature/add-corporate-number-search
  • fix/payment-button-disabled

のような形式です。

実際のSkillには、パターンだけでなく細かいルールも書いています。

  • description は英語で簡潔に書く
  • 不要に長くしない
  • チームで読みやすい粒度を意識する

こういったルールをAIに渡しておくことで、 「日本語のブランチ名が紛れ込んだ」「毎回違うフォーマットになる」といった揺れを防げるようになりました。

結果として、僕自身がブランチ名を1つ1つ考える必要がなくなり、レビューする側も「だいたいこの形式ね」と一目で分かる状態になっています。

---
description: ブランチ命名規則
---
# ブランチ命名規則
## パターン
- `feature/brief-description` - 新機能
- `fix/brief-description` - バグ修正
- `refactor/brief-description` - リファクタリング
- `hotfix/brief-description` - 緊急修正
## ルール
- descriptionは**英語**で簡潔に
- 例: `feature/add-corporate-number-search`

Skill 2：conventional-commits — チームのコミット規約をAIに覚えさせる

二つ目のSkillは conventional-commits.md です。支払い.comのチームでは、コミットメッセージをConventional Commits に則って書くことにしています。

type と description を組み合わせるフォーマットで、feat や fix、refactor などのtypeを使います。

Skillでは、

  • フォーマット：<type>[optional scope]: <description>
  • 使ってよい type 一覧
  • 具体例（feat(payment): … のような例）

をまとめておき、さらに「メッセージは日本語で書く」といったチーム特有のルールも記載しています。また、コミット時に使うコマンドのテンプレートもSkillに含めました。

---
description: Conventional Commits ルール
---
# Conventional Commits

## フォーマット
`<type>[optional scope]: <description>`

*コミットメッセージは日本語で記述*

## 利用可能なtype
- `feat`: 新機能の追加
- `fix`: バグ修正
- `docs`: ドキュメントのみの変更
- `style`: コードの意味に影響しない変更
- `refactor`: バグ修正や機能追加以外のコード変更
- `perf`: パフォーマンス向上
- `test`: テストの追加・修正
- `chore`: ビルドプロセスや補助ツールの変更

## 例
- `feat(payment): クレジットカード決済のバリデーション機能を追加`
- `fix(auth): ログインリダイレクトの問題を修正`
- `refactor(components): フォームバリデーションロジックを共通化`

## コミット実行フォーマット
git commit -m "$(cat <<'EOF'
<commit-message>
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <[email protected]>
EOF
)"

これによって、

  • コミットメッセージの形式が毎回揃う
  • 人間が手入力するときに起こりがちなミスがなくなる

という効果が出ました。

Skill 3：pr-template — Done / Not To Do / Other でプルリクを整理する

三つ目が pr-template.md です。UPSIDERの支払い.comチームでは、プルリク本文の構造として「Done / Not To Do / Other」という形式を採用しています。

Skillには、次のような情報を書いています。

  • タイトルはConventional Commits形式（日本語）で書くこと
  • タイトルにはタスク番号（例：SHITASK-XXXX）を含めること
  • 本文は
    • Done：このプルリクで何をやったか
    • Not To Do：関連しそうだけれど、今回あえてやっていないこと
    • Other：確認事項や補足情報

というセクション構造にすること。

AIにはこのテンプレートに沿って内容を埋めてもらい、僕はそれを読んで、不正確なところだけ手で直すようにしています。

ゼロから文章を書くのではなく、「すでに6割できている文章をチェックして直す」ぐらいの負荷になるので、プルリク作成の心理的ハードルもかなり下がりました。

---
description: PRテンプレート構造
---

# PRテンプレート
## タイトル
- Conventional Commits形式（日本語）
- フォーマット: `<type>[optional scope]: [SHITASK-XXXX] <description>`
- 例: `feat(payment): [SHITASK-3673] クレジットカード決済のバリデーション機能を追加`

## 本文構造

## Done
<!-- このプルリクで何をしたのか箇条書きで記載 -->
-

## Not To Do
<!-- 関連するけどこのPRではやらなかったこと -->
<!-- なければ「なし」と記載 -->

## Other
<!-- 確認した内容、補足事項など -->
<!-- なければ省略可 -->

🤖 Generated with [Claude Code](https://claude.ai/code)


## 作成手順
1. 一時ファイル`pr_body.txt`にPR本文を書き出し
2. `gh pr create --title "..." --body-file pr_body.txt`で作成
3. 作成後、`pr_body.txt`を削除
4. PR URLを表示

カスタムスラッシュコマンド /ship の中身

実際のコマンド定義は .claude/commands/ship.md に書いています。ここでは、変更内容の分析からプルリク作成までの手順を順番に指示しています。

手順としては、

  1. git status と git diff で変更内容を確認する
  2. branch-naming Skillを使ってブランチ名を提案し、git checkout -b でブランチを作成する
  3. 関連するファイルを git add でステージングする
  4. conventional-commits Skillに従ってコミットメッセージを生成し、git commit を実行する
  5. git push -u origin <branch-name> でリモートにブランチを作成する
  6. pr-template Skillを使ってプルリクのタイトル・本文を生成し、gh pr create で作成する

といった流れです。

Claude CodeのPlanモードを利用して実行する前に必ず人間の確認をはさむようにしていて、「勝手に全部やられてしまう」ことを防ぐようにしています。

また、秘密情報を含むファイルはコミットしない、といった注意事項もコマンドの中に明示しています。

---
description: Branch, Commit, Push, and Create PR
---

# 引数

- `$ARGUMENTS`: タスク番号（例: SHITASK-3673）
- 引数が指定されていない場合はユーザーに確認

# タスク

現在の変更内容を分析して、ブランチ作成・コミット・プッシュ・PR作成を一度に実行してください。

## 前提: 以下のスキルファイルを最初に読むこと

- `.claude/skills/branch-naming/SKILL.md`
- `.claude/skills/conventional-commits/SKILL.md`
- `.claude/skills/pr-template/SKILL.md`

## 手順

### 1. 変更内容の確認

- `git status`で変更ファイルを確認
- `git diff`で変更内容を詳細に確認（ステージング済みとそうでないもの両方）

### 2. ブランチ名の提案と作成

- 変更内容を分析
- `branch-naming/SKILL.md`に従ってブランチ名を提案
- 提案したブランチ名をユーザーに確認
- 承認されたら`git checkout -b <branch-name>`でブランチを作成

### 3. 変更のステージング

- 関連する変更ファイルを`git add`でステージング
- 不要なファイル（.envなどの秘密情報を含むファイル）は除外
- ステージング後、`git status`で確認

### 4. コミットメッセージの生成と実行

- `conventional-commits/SKILL.md`に従ってコミット

### 5. リモートへのプッシュ

- `git push -u origin <branch-name>`でリモートブランチを作成してプッシュ
- プッシュ完了後、ブランチ名とプッシュ結果を表示

### 6. プルリクエストの作成

- `pr-template/SKILL.md`に従ってPRタイトル・本文を生成
- `$ARGUMENTS`のタスク番号をPRタイトルに含める

gh pr create --title "<type>: [SHITASK-XXXX] <description>" --body "$(cat <<'EOF'
## Done

- やったこと

## Not To Do

なし

## Other

なし

🤖 Generated with [Claude Code](https://claude.ai/code)
EOF
)"

## 注意事項

- 各ステップで確認を取りながら進める
- 秘密情報を含むファイルはコミットしない

なぜ「Skills＋スラッシュコマンド」に落ち着いたのか

実は最初からこの形だったわけではありません。当初はスラッシュコマンドだけで何とかしようとしていました。

しかし、このやり方には問題がありました。

  • プルリクのテンプレートを読まないことがある
  • テンプレを読んだ上で、なぜか無視して別の形式で書いてくる
  • その結果、出力にムラが出る

といった現象が頻発していました。

そこで、ルールやフォーマットなど「変わってほしくない部分」をスラッシュコマンドの中の単なる文章ではなく、Skillとして分離し、構造化されたナレッジとして渡すようにしました。

この変更によって、AIの出力はかなり安定しました。「プルリクのテンプレを守ってくれない」というストレスがほぼなくなり、毎回同じ構造・同じトーンのプルリクが生成されるようになりました。

効果：作業スピードが“シンプルに”上がった

導入後に特に実感しているのは次のような点です。

まず、ブランチ名やコミットメッセージを考える時間がゼロになりました。
さらに、コミットメッセージを手入力していたときにたまに起きていたフォーマットミスもなくなりました。

そして何より大きいのは、生成されたプルリクを修正するだけで良くなったことです。

以前は、プルリクを書き始めるまでの腰が重かったのですが、今は /ship を叩けばひと通り形ができあがるので、レビュー依頼前のセルフチェックだけに集中できます。

結果として、体感レベルではありますが、「プルリクを作るためにかかる時間」と「それに向き合う気力」がかなり軽くなったと感じています。

AIをどこに使えばいいかわからない人へ：小さな不便から、そして“バイブコーディング開発縛り”

イベントの中でもお話ししましたが、AI活用に悩んでいる方には、「小さな不便から始める」ことです。コミット文、プルリク本文、ブランチ名など、日々「地味にめんどい」と感じている定型的な作業は、AIとの相性が非常に良いです。

いきなり大きな業務プロセス全体をAI化しようとするのではなく、目の前の「今日もこれやっててだるいな」という作業から手を付けると、導入のハードルがぐっと下がります。

そして、その「小さな不便」を見つけるための手段として「バイブコーディング開発縛り」をおすすめします。 これは実際に僕たちのTechチームでやってみた取り組みです。

tech.up-sider.com

文言変更のような軽いタスクから、もう少し込み入った修正まで、とにかく一定期間AIに任せてみる。そのうえで、「ここはAIの方が速い」「ここは人間がやった方が良い」といった境界線が自然と見えてきます。

支払い.comをはじめとしたプロダクトの開発現場では、今回紹介したような「AIをうまく使って開発プロセスを軽くする工夫」をこれからもどんどん試していくつもりです。

もしこういった取り組みに興味を持っていただけたら、ぜひ採用ページやTech Blogも覗いてみてください。

なお、この発表で使ったスライド自体もClaude Codeと一緒に作っています。AIに任せられるところは任せつつ、人間は「何を作るのか」「どんな体験にしたいのか」というところに集中する。そんな開発スタイルを、これからも模索していきたいと思っています。

発表資料はこちら

speakerdeck.com

We Are Hiring !!

株式会社UPSIDERでは現在積極採用をしています。 ぜひお気軽にご応募ください。

herp.careers

herp.careers

UPSIDER Engineering Deckはこちら📣

speakerdeck.com