🤖

リリース作業はAIエージェントにお任せあれ

に公開

はじめに

みなさんAIの流行についていけてますか?僕はあんまりついていけてません。そんな僕でも最近MCPという単語が街で飛び交いすぎて気になったので思い腰を上げてGitHubのMCPの設定をしたら、なんとまあGitHubの操作をAIエージェントに任せることができてびっくりしています。

そんな僕ですが最近個人バイブス開発した趣味のWebページのリリース作業をCursor+ProjectRules+GitHubMCPで半自動化したので紹介します。

作ったサイトの紹介

僕はAdo(歌い手)の推し活に勤しんでいるのですが、最近発売されたベストアルバムの特典に曲を読み札/絵札にしたかるたがついていました。読み札はもちろん曲の歌詞ですので、せっかくなら楽曲を流しながら楽しみたいと思い、YouTube上の曲をランダムに読み札の頭の歌詞部分から流せば、かるたとして遊びやすいのでは?と思いGWに1日足らずで開発しました。

https://ado-karta.vercel.app/

カルタを遊ぶためだけにアプリインストールするのはハードルが高いと思ったので、Next.jsで開発しVercelにHostingしています。

リポジトリはこちら
https://github.com/miyasic/ado-karta

今回やりたいこと

リリースのための細かい作業をCursorのAgentモードに丸投げする。

とは言っても、VercelとGitHubの連携は済んでおり、mainブランチにpushすれば自動的にデプロイはされるので、今回はCICDの話ではなくその一歩手前のバージョンをインクリメントするとか、リリースノートを書くとかそういう細かい作業の話です。

実際にどれくらい丸投げできるようになったかはこんな感じです。

https://x.com/miyasic_x/status/1929693639615435263

MCPによるPRのマージのタイミングでエラーが起きちゃったので、何度か指示し直していますが、基本的には最初の指示だけで一通りのリリース作業はできそうです。

戦略

先ほども記述した通り、GitHubのMCPを接続することでGitHub上での操作をCursorにお願いできます。
またCursorのプロジェクトルールを細かく書くことで、都度指示を細かくする必要がなくなります。例えば、プロジェクトルールがない状態でPR作ってと依頼するとリポジトリはどれですか?と聞かれます。
それくらいわかってよ〜と思うのですが、これをプロジェクトルールに書いておくと指定しなくてもリポジトリを判断してくれます。たまにそれでも聞いてくるけどその時はプロジェクトルールをメンションしてあげると解決します。

プロジェクトルール

プロジェクトルールは複数用意しておきます。
例えば、コミット用のルール、PR作成用のルール、GitHubの操作を行う際のルールなどです。

さらに今回はリリース作業を行う際のルールも用意します。

ここからはそれぞれのプロジェクトルールを紹介します。現在時点のものを添付しますが、GitHubのリンクも合わせて貼っておきますので、そちらもご参照ください。

リリース作業用のルール

リリース作業用のルール(release.mdc)
---
description: リリース作業時に参照すること
globs: 
alwaysApply: false
---
作業手順

1. 現在のdevelopブランチを最新に更新する。
2. GitHubMCPを利用して、前回のリリース以降にdevelopブランチにマージされたPR一覧を取得する。
前回のリリースとは一番最近developブランチをmainブランチにマージしたものとする。タイトルは Release Version <x.y.z>となっているはずである。

取得したPR一覧からタイトルのprefixがfeat,bugfix,improvementsとなっているものがリリースノートの対象なので、これらのPRを元にリリースノートを作成する。release-note.jsonの形式を参照すること。
ユーザはエンジニアではないので、誰が読んでもわかりやすい言葉を利用すること。また、PRへの参照などは不要。

リリースノートに書く内容がない場合、improvements扱いとし下記のようにすること
日本語タイトル:軽微な改善を行いました。
英語タイトル:General improvements.

3. リリースVersionを決定する。 先ほど確認したリリース内容からSemanticVersioningに従いVersionをincrementする。
major: 目玉機能のリリース、破壊的変更を含むアップデート
minor: 新機能の追加、大きな不具合の解消
patch: 軽微な不具合の解消

4. リリース内容を @release-notes.json に反映する。
5. package.jsonに新しいversionを反映

6. ユーザにここまでの変更内容が正しいかを確認
7. developブランチからリリースブランチ release/<x.y.z> を作成する。(x.y.z)には正しいVersionを入れること
8. release/<x.y.z> をdevelopブランチにマージするPRを作成する。タイトルは <x.y.z>: Release note/Version increment とすること
9. developブランチをmainブランチにマージするPRを作成する。
タイトルは Release Version <x.y.z> とすること
10. 8で作ったPRをマージする。
11. 9で作ったPRをマージする。


## release-note.jsonの形式
```json
[
  {
    "version": "x.y.z",
    "releaseDate": "YYYY/MM/DD",
    "changes": {
      "ja": {
        "newFeatures": [
          { "title": "新機能1", "descriptions": ["詳細1", "詳細2"] },
          { "title": "新機能2" }
        ],
        "improvements": [
          { "title": "改善点1" }
        ],
        "bugFixes": [
          { "title": "バグ修正1", "descriptions": ["修正内容詳細"] }
        ]
      }
    }
  }
]
```

以下は、`release-note.json` の各エントリに対応するTypeScriptの型定義風の表現です。

```typescript
interface ChangeItem {
    title: string; // 必須: 変更点のタイトル
    descriptions?: string[]; // 任意: 変更点の詳細説明(配列)
}

interface LocalizedChanges {
    newFeatures?: ChangeItem[]; // 任意: 新機能のリスト
    improvements?: ChangeItem[]; // 任意: 機能改善のリスト
    bugFixes?: ChangeItem[]; // 任意: バグ修正のリスト
}

interface ReleaseNote {
    version: string; // 必須: リリースバージョン (例: "1.2.3")
    releaseDate: string; // 必須: リリース日 (YYYY/MM/DD 形式)
    changes: { // 必須: 変更内容
        [locale: string]: LocalizedChanges; // キーはロケール文字列 ("ja" | "en")
    };
}

// release-note.json は ReleaseNote[] 型 (ReleaseNote の配列) として構成されます。
// 各リスト (newFeatures など) や descriptions は、該当する変更がない場合は省略するか、空の配列 [] としてください。
```

上記の `ReleaseNoteEntry` の配列として `release-note.json` は構成されます。
`changes.ja` 内の各リスト (`newFeatures` など) は、該当する変更がない場合は省略するか、空のリスト `[]` としてください。

https://github.com/miyasic/ado-karta/blob/develop/.cursor/rules/release.mdc

リリースノートの作成とバージョニング

このリリース作業における重要なポイントは、リリースノートの作成とバージョニングです。
これは作業手順2~5で指示をしているのですが、まずmainブランチの最新のコミットから前回のリリースタイミングを取得し、それ以降にDevelopにマージされたPRを一覧で取得しています。
その後、PR一覧からリリースノートの掲載対象となる「feat,bugfix,improvements」のprefixがついているPRを選び、今回のリリースノートを作成してもらいます。

「ユーザはエンジニアではないので、誰が読んでもわかりやすい言葉を利用すること。また、PRへの参照などは不要。」この一文は割と重要で、Cursorは普通にユーザ目線ではない言葉でリリースノートを書いてくるので、ユーザはエンジニアではないということを伝えておくのが良さそうです。

また、このプロジェクトではリリースノートをjson形式で保存しサイトから見れるようにしているのですが、このjsonの形式もrelease.mdcの下部に定義しています。
jsonのフォーマットを厳密に定義する記述方法がわからなかったので、TypeScript風に型定義もしています。

また、バージョニングについても言及しており、リリースノートの内容と前回のバージョンから適切なバージョンを決定し、リリースノートやpackage.jsonに反映するように指示をしています。

PR作成とマージ

リリースノートとバージョニングを反映したら、手順7から手順11でリリースブランチの作成、Developブランチへのマージ、その後mainブランチのマージをします。
ここでは下記の2つのPRの作成を依頼しています。
①リリースブランチ→Developブランチ
②Developブランチ→mainブランチ

ここでマージ順がおかしくならないようにmainブランチはGitHubのブランチプロテクションルールを使って、 release-note.jsonの差分がない限りマージできないように設定をしています。
①のPRがマージされない限りrelease-note.jsonの差分が発生しない運用なので、これでマージ順がズレることはありません。

また、PR作成時にVercelへPreviewのデプロイがされるのですが、これに失敗するとPRをマージできないため、ビルドが通らない状態で①がマージされちゃうこともありません。

これらのプロテクションのおかげで手順書でPRのマージまで指示しています。個人的にはAgentが全ての指示を正しく実行してくれることを期待していないので、あとから戻せない操作や戻すのが大変な操作がフローに入っている場合はブランチのプロテクションルールなど、機械的にCheckを入れることをオススメします。

GitHub操作時のルール

GitHub操作時のルール(github-mcp.mdc)
---
description: GitHubの操作をする際に参照すること
globs: 
alwaysApply: false
---
GitHubの操作をする際に参照すること

GitHubの操作をする場合はGitHubMCPを利用すること
特に指定がない場合 miyasic/ado-karta のレポジトリを利用すること

https://github.com/miyasic/ado-karta/blob/develop/.cursor/rules/github-mcp.mdc

これがないと毎回リポジトリとオーナーを確認されるので、ルールとして定義しておきます。

prefixについてのルール

prefixについてのルール(prefix.mdc)
---
description: Git,GitHubの操作時に参照すること
globs: 
alwaysApply: false
---
以下のprefixは、ブランチ名、コミットメッセージ、PRタイトルなどで利用します。

- `feat`: 新機能の追加
- `bugfix`: 不具合の修正
- `improvements`: 機能改善
- `docs`: ドキュメントのみの変更
- `revert`: 以前のコミットに戻す場合
- `refactor`: リファクタリング(バグ修正や機能追加ではないコード変更)
- `chore`: ビルドプロセスや補助ツール、ライブラリの変更(コードの動作に影響しないもの)

## 各種操作時のprefix利用について

### ブランチ名
ブランチの種類に応じてprefixを付与します。
例:
- `feature/<Issue番号>-<簡単な説明>` (例: `feature/123-user-authentication`)
- `bugfix/<Issue番号>-<簡単な説明>`

### コミットメッセージ
変更内容の種類を示すprefixをメッセージの先頭に付与します。
Conventional Commits の形式を推奨します。
例:
- `feat: 新しいログイン機能を追加`
- `docs: READMEの誤字を修正`

### PRタイトル
コミットメッセージと同様に、PRの内容を表すprefixを付与します。
対応するIssueがある場合Issue番号を含めること。
例:
- `feat: <Issue番号> - ユーザー認証機能の実装`

### リリースノートへの影響
PRのタイトルに付与されたprefixによって、リリースノートへの掲載有無が判断されます。

- **リリースノートに掲載されるprefix:**
  - `feat`
  - `bugfix`
  - `improvements`

- **リリースノートに掲載されないprefix:**
  - `docs`
  - `revert`
  - `refactor`
  - `chore`

詳細な運用ルールは、各操作に対応するルールファイル(`branch-strategy.mdc`, `commit.mdc`, `pr.mdc`, `release.mdc`など)も併せて参照してください。

## Prefix利用対応表

| Prefix         | ブランチ名                                  | コミットメッセージ        | PRタイトル                          | リリースノート |
|----------------|-------------------------------------------|-------------------------|-------------------------------------|--------------|
| `feat`         | `feature/<Issue>-<desc>`                  | `feat: <description>`   | `feat: <Issue番号> - <description>` | 掲載         |
| `bugfix`       | `bugfix/<Issue>-<desc>`                   | `bugfix: <description>` | `bugfix: <Issue番号> - <description>` | 掲載         |
| `improvements` | `feature/<Issue>-<desc>` <br> or `improvements/...` | `improvements: <description>` | `improvements: <Issue番号> - <description>` | 掲載         |
| `docs`         | `docs/<Issue>-<desc>` <br> or `feature/...` | `docs: <description>`   | `docs: <Issue番号> - <description>`   | 非掲載       |
| `revert`       | `revert/<Issue>-<desc>`                   | `revert: <description>` | `revert: <Issue番号> - <description>` | 非掲載       |
| `refactor`     | `refactor/<Issue>-<desc>`                 | `refactor: <description>`| `refactor: <Issue番号> - <description>`| 非掲載       |
| `chore`        | `chore/<Issue>-<desc>`                    | `chore: <description>`  | `chore: <Issue番号> - <description>`  | 非掲載       |

* 表内のブランチ名は一例です。詳細な命名規則は `branch-strategy.mdc` を参照してください。

https://github.com/miyasic/ado-karta/blob/develop/.cursor/rules/prefix.mdc

ブランチ、コミットメッセージ、PRタイトルに利用するprefixを定義しています。
コミットメッセージではfeatにしたいけど、ブランチ名はfeature/で始めたい気持ちありますよね。これらの対応関係を表にまとめています。
また、リリースノートに掲載するかどうかをprefixで定義しておくことで、今回のリリースに含まれるPRのうちリリースノートに含めるものかどうかを機械的に判断できるようにしています。

PR作成時のルール

PR作成時のルール(pr.mdc)
---
description: PullRequest (PR)作成時に参照すること
globs: 
alwaysApply: false
---
## 必須事項

- buildの確認: `npm run build` を実行してエラーが発生しないことを確認してください。

- **リモートブランチの存在確認**: プルリクエストを作成する前に、対象のローカルブランチがリモートリポジトリにプッシュされていることを必ず確認してください。ローカルのみに存在するブランチからプルリクエストを作成することはできません。
  - コマンド例: `git push origin <branch-name>`

- PRのタイトルについて
prefixのルールは [.cursor/rules/prefix.mdc](mdc:.cursor/rules/prefix.mdc) を参照してください。

- PRの本文について
プルリクエストの本文は、リポジトリの [.github/PULL_REQUEST_TEMPLATE.md](mdc:.github/PULL_REQUEST_TEMPLATE.md) に定義されたテンプレートに従って作成してください。

PRのタイトル、内容は特に指示がない限り、日本語で書いてください。

https://github.com/miyasic/ado-karta/blob/develop/.cursor/rules/pr.mdc

このプロジェクトは機能開発も基本的にCursorのAgentに全て依頼して実装したため、PRもAgentに作ってもらっています。
1人で開発している規模なので、簡単なテンプレートを用意して、それを参照してもらうようにしています。
また、prefixのプロジェクトルールについても言及しています。
PRの作成を依頼すると、Pushをしていない状態でPRを作成しようとしてエラーが発生することが多々あったので、PR作成前にリモートブランチを作成することも明記しています。

コミット時のルール

コミット時のルール(commit.mdc)
---
description: 変更内容をCommitする際に参照
globs: 
alwaysApply: false
---
Commitする前にブランチが正しいかを確認してください。
mainブランチ、developブランチに対する直接のコミットは禁止です。

また、commitを依頼した際にはローカルだけで行い,pushは禁止です。

コミットメッセージを作成する際は、[.cursor/rules/prefix.mdc](mdc:.cursor/rules/prefix.mdc) を参照し、
いずれかのprefixをメッセージの先頭に付与してください。

例:
feat: 新しいログイン機能を追加
docs: READMEの誤字を修正

https://github.com/miyasic/ado-karta/blob/develop/.cursor/rules/commit.mdc

ブランチについて言及することで、間違ったブランチにコミットしてしまうことを防いでいます。
main、developブランチに対するコミットは禁止と書いていますが、そもそも本プロジェクトではGitHubのブランチプロテクトルールで直接Pushはできないようにしています。Agentが暴走してmainブランチに直pushする可能性を否定しきれないので、これはちゃんと設定したほうが良さそう。

念の為、コミット依頼した時はpushしないように指定していますが、どうせその後にpushするので禁止しなくても良いかもしれません。

ここでもprefixのルールに言及しています。

おわりに

こんな感じでGitHubMCPを設定して、プロジェクトルールを整えてあげると「リリース作業して」と入力するだけで自動でリリース作業をしてくれます(たまに上手くリリースノートが書けなかったり、PRのマージに失敗したりするけど)。
今回は簡単なアプリのリリース作業でしたが、応用すれば複雑なプロジェクトのリリースにも適用できると思うので、ぜひ活用してみてください!

記事が参考になった方は記事とGitHubのいいね(スター)とフォローをしていただけると励みになります!
最後まで読んでいただきありがとうございました✨

https://github.com/miyasic/ado-karta

Discussion