AIエージェントをチームで使うためのコミットルール設定

はじめに

前職でチームリードをしていたとき、Jira でタスク管理をしていました。

リリースのたびに「今回何を入れたか」を確認する作業があります。AI が絡んだコミットログだと Jira のチケットと対応が取れないことがあります。feat: ログイン修正 と書いてあっても、それが PRJ-123 なのか PRJ-145 なのかわかりません。追えません。情報が漏れます。

最初は「コミットメッセージをちゃんと書いて」と口頭で伝えました。それでも崩れました。

原因はメンバーの意識ではなく、ルールが明文化されていなかったことです。AI に渡すルールがなければ、エージェントはデフォルトの挙動で動きます。

最終的に、チケット番号を先頭に入れることを必須にしました。
それだけで追跡がかなり楽になりました。

PRJ-123 feat: ログインのバリデーションエラーを修正

チームのコミットルールが崩れる構造

個人が AI を使い始めると、チームの履歴では次のようなパターンが出やすくなります。

• git add . で意図しないファイルが混入する
• WIP tmp fix だけのメッセージが残る
• 1 コミットに複数の変更が混在する（feat と refactor が一緒になる）
• 英語・日本語が混在する
• .env や秘密情報が誤ってコミットされる
• Jira チケットと対応が取れない

どれもエージェントの問題ではありません。ルールを渡していないから、エージェントはルールなしで動きます。ただそれだけの話です。

設計の考え方：「禁止」「手順」「形式」の3点セット

チームのコミットルールは、次の 3 つを決めれば最低限まわります。

禁止

• git add . 不可
• 仮メッセージ（WIP tmp）不可
• 読んでいないファイルを stage に含めない
• .env / 秘密鍵 / 認証情報をコミットしない

手順

1. git status で意図外のファイルがないか確認する
2. git diff --staged で差分の中身を確認する
3. 確認してからコミットする

メッセージ形式

Conventional Commits の type を英語ラベルで使い、説明文は日本語で書きます。チームで Jira を使っているなら、チケット番号を先頭に入れます。

PRJ-123 feat: ユーザー認証機能を追加
PRJ-456 fix: ログイン時のバリデーションエラーを修正
PRJ-789 refactor: 認証ロジックをAuthServiceに分離

使える type はチームで固定します。feat / fix / docs / refactor / test / chore あたりが一般的です。

Cursor .cursor/rules/git-commit.mdc

.cursor/rules/ 配下に git-commit.mdc を作成します。リポジトリに同梱しておけば、チーム全員が同じルールをエージェントに渡せます。

alwaysApply: true は「常に自動コミットする」という意味ではありません。プロジェクトを開いているあいだ、ルールをコンテキストに載せやすくするための指定です。

---
description: コミットメッセージとgit操作のルール
globs: ["**/*"]
alwaysApply: true
---

# Gitコミットルール

## メッセージ形式
<Jiraチケット番号> <type>: <変更内容（日本語）>

例：
PRJ-123 feat: ユーザー認証機能を追加
PRJ-456 fix: ログイン時のバリデーションエラーを修正

## 使用できるtype
- feat: 新機能の追加
- fix: バグ修正
- docs: ドキュメントのみの変更
- refactor: 動作を変えないコードの整理
- test: テストの追加・修正
- chore: ビルド設定・ツール類の変更

## 粒度ルール
- 1つのコミットに含めるのは1機能・1修正まで
- 複数の変更が混在する場合は必ずコミットを分割する
- ファイルをまとめてaddしない。変更単位でstageする

## 禁止事項
- `git add .` の使用禁止
- `WIP` `tmp` `あとで直す` 等の仮メッセージ禁止
- 読んでいないファイルをstageに含めない
- `.env` / 秘密鍵 / 認証情報を含むファイルをコミットしない

## コミット前の確認（必須）
1. `git status` で意図外のファイルが含まれていないか確認する
2. `git diff --staged` で差分の中身を確認する
3. 上記を確認した上でコミットする

ClaudeCode CLAUDE.md

プロジェクトルートの CLAUDE.md に Git セクションを追加します。こちらも同じくリポジトリに含めておきます。

## Gitコミットルール

### メッセージ形式
<Jiraチケット番号> <type>: <変更内容（日本語）>

例：
PRJ-123 feat: ユーザー認証機能を追加
PRJ-456 fix: ログイン時のバリデーションエラーを修正

### typeの種類
feat / fix / docs / refactor / test / chore のみ使用する。

### 粒度
- 1機能・1修正 = 1コミット
- 複数変更が混在する場合はコミットを分割する

### 操作ルール
- `git add .` を使わない。`git add <file>` で明示的にstageする
- コミット前に `git status` → `git diff --staged` の順で確認する
- 読んでいないファイルをコミットに含めない
- `.env` / 秘密鍵 / 認証情報を含むファイルをコミットしない

チームへの展開方法

ファイルを作っただけでは伝わりません。展開は最小限で十分です。

リポジトリに同梱する

.cursor/rules/git-commit.mdc もしくは CLAUDE.md をリポジトリに含めてプッシュします。クローンした時点でルールが手元に来ます。

オンボーディング資料に一行入れる

「コミット時は git-commit.mdc のルールに従う。AI に任せる場合も同様」と書けば十分です。

PR テンプレートに入れる

PR テンプレートに「コミットメッセージにチケット番号が入っているか確認」を追加しておくと、レビュー時に自然とチェックが入ります。

まとめ

AI を使うメンバーがいるチームでは、コミットルールを エージェントに渡せる形で明文化しておく必要があります。口頭や慣習だけでは伝わりにくいです。

ルールは 3 点セットで設計する。

• 禁止：git add . 不可、秘密情報不可、仮メッセージ不可
• 手順：status → diff --staged → コミットの順
• メッセージ形式：チケット番号 + Conventional Commits の type + 日本語の説明

大事なことは、ルールの内容というよりもルールを決めること。
これで、チーム全員でエージェント運用が楽になると思います。