Kento
Claude CodeにGit運用を任せる仕組みを作る — CLAUDE.mdで定義するワークフロー設計をしてみた!
2026年03月31日
見出しはありません
要約を生成中...
Git操作やPRレビューまで任せるには「どう動くべきか」を事前に定義しておく必要があります!
その定義を書く場所が CLAUDE.md 。
プロジェクトルートに置くことでClaude Codeが自動で読み込み、以降は毎回指示しなくてもルール通りに動いてくれます!
ただし実際には git push や gh pr create などの操作前に確認ダイアログが表示され、人間がOKをクリックする場面があります!
これは完全自律ではなく、「Claudeが手順を把握して動き、人間が承認する」半自律の状態。
本記事ではその仕組みをどう設計する前提での紹介です!
project/
├── CLAUDE.md # エントリーポイント(importのみ)
└── .claude/
└── git/
├── git-rules.md # ブランチ運用・コミットメッセージ規則
├── review-checklist.md # PRレビュー項目
└── pr-workflow.md # ステージング〜マージの手順CLAUDE.md 側は import する。
CLAUDE.md@.claude/git/git-rules.md
@.claude/git/review-checklist.md
@.claude/git/pr-workflow.md静的なチェックリストではなく、実際のdiffを取得してClaudeがレビューする仕組みにするのがポイント を使ってシェルコマンドを実行し、差分を読んでからレビュー結果を出力する。
.claude/git/git-rules.md
PRレビュー
レビュー実行手順変更対象ファイルを取得
!git diff --name-only main...HEAD詳細なDiffを取得
!git diff main...HEAD以下の観点でレビューすること
セキュリティの脆弱性
- 認証・認可の漏れ
- 機密情報のハードコード
- SQLインジェクション・XSSのリスク
コード品質
- ロジックが意図通りか
- エッジケースの考慮
- 変数名・関数名の命名
インシデントリスク
- 既存機能への影響範囲
- データの破壊・消失リスク
テストカバレッジ
- テストが不足している箇所
パフォーマンス
- 不要な処理・重い処理がないか出力形式
ファイルごとに具体的で実行可能なフィードバックを日本語で出力すること。
問題がない場合も「問題なし」と明記すること。レビュー完了後
PRを作成しマージまで実行すること。ブランチの使い分けとコミットメッセージのフォーマットを定義する。
.claude/git/git-rules.md
Gitブランチ運用ルールブランチ構成
- main:リリース用(直接pushしない)
- develop:開発用(機能はここに積み上げる)基本フロー
- developブランチから作業を開始
- コミット → developにpush
- develop → main へPR作成・マージコミットメッセージ規則
形式
<type>: <変更内容を日本語で簡潔に>
typeの種類
| type | 使う場面 | 例 |
|------|---------|-----|
| feat | 新機能の追加 | `feat: ログイン機能を追加` |
| fix | バグ修正 | `fix: パスワードリセットが動かない問題を修正` |
| refactor | リファクタリング・パフォーマンス改善 | `refactor: 認証処理を関数に切り出し` |
| style | フォーマット・コメント修正(動作に影響なし) | `style: インデントを統一` |
| test | テストコードの追加・修正 | `test: ログインのユニットテストを追加` |
| docs | ドキュメントのみの修正 | `docs: READMEのセットアップ手順を更新` |
| chore | ライブラリ導入・更新・設定変更 | `chore: shadcn/uiを導入` |ルール
- 必ず日本語で書くこと
- typeの後はコロン+スペース(: )を入れること
- 1行目は50文字以内に収めること
- 何をしたかではなく、なぜしたかを意識して書くこと複数の変更がある場合
1コミット1目的を原則とする。
やむを得ず複数の変更をまとめる場合は本文に箇条書きで記載する。feat: カート機能を追加
- 商品をカートに追加できるようにした
- カートの合計金額を表示するようにした
- カートが空の場合のメッセージを追加
Claudeが実行する操作の順番を明示する。PR本文のフォーマットもここに定義することで、毎回同じ形式で出力される。
.claude/git/pr-workflow.md
PR作成〜マージの手順全体フロー
1.変更をステージング
2.コミット
3.リモートにpush
4.レビュー実行
5.PR作成
6.マージStep1. ステージング〜コミット
変更内容を確認
!git status
!git diffステージング
!git add .
※ 不要なファイルが含まれていないか必ず確認してからステージングすること。
※ .env や機密情報を含むファイルが含まれていないか確認すること。コミット
コミットメッセージはgit-rules.mdのフォーマットに従うこと。
!git commit -m "<type>: <変更内容を日本語で>"Step2. リモートにpush
!git push origin developStep3. レビュー実行
review-checklist.mdの手順に従いレビューを実行すること。Step4. PR作成PRタイトル
日本語で変更概要を記載すること。PR本文フォーマット
作業目的
(なぜこの変更をするのか)変更内容| # | ファイル | 変更内容 | コミットID |
|---|---------|---------|-----------|
| 1 | `src/xxx/yyy.ts` | 変更の概要 | [abc1234](https://github.com/ken512/mokucafe/commit/abc1234) |エビデンス
(動作確認内容、テスト結果など)Step5. マージ〜後処理
- Squash mergeで実行すること
- マージ後にブランチを削除すること
- ローカルのdevelopを最新に更新すること!git checkout develop
!git pull origin develop定義が完了したら、Claude Codeでこう一言伝えるだけで全工程をClaudeが把握して動いてくれる。
CLAUDE.mdとgit/配下のルールを読んで把握して。
その後、developからmainへのPRをレビューしてから作成、マージまでやって。承認ダイアログを省略したい場合は settings.local.json に許可コマンドを追加することで確認を減らせる。
ただしpushやマージが確認なしに実行されるため、チーム開発では慎重に判断すること。
CLAUDE.mdにGit運用ルールを定義することで、毎回細かく指示しなくてもClaudeがステージングからPRマージまでの手順を把握して動いてくれるようになる。
完全な自律実行ではないが、「何をすべきか」をClaudeが理解した上で動く状態は、毎回ゼロから指示するより大幅に効率が上がりました!
要約
コメント
まだコメントはありません。