はじめに
この記事は、
なんとなく開発に生成AIを取り入れていた、
フロントエンジニアのお話。
みなさんは生成AI使っていますか？
2025年の頭ぐらいから、
グッと生成AIの普及が広まった感がありました。
エンジニアたるもの最先端のツールは触ってみにゃ！
ということで、Cursor/Claude codeへ奉納金を納め、早速触ってみました。
ワイ：「へぇ、、、やるじゃん、、、、」
当時はその便利さに度肝を抜かれましたが、
なんやかんやちゃんと使っていなかった。(設計/運用できていなかったに近い)
そんなこんなで重い腰がやっと上がり、
ちゃんと取り入れてみることにしました。
ワイ：「さーーーーーて、どんなもんですか？っと。(首の骨ポキポキ)」
やったこと
- MCP周りを整えた(Github/JIRA/Figma)
- Skills/rulesの作成(↓で載せます)
- JIRAへ要件をまとめてもらった
- 開発フローにAIを組み込んだフローにした
AI駆動開発を調べて手軽にできそうなことをとりあえずやってみました🥸
何が楽になったの？
まず結論↓がめちゃくちゃ楽になりました。
- JIRAチケットの自動起票
- Figmaからのコンポーネント作成
- セルフレビュー、AIレビューによるレビュワーの負担軽減
- 自動PR作成
などなど
プランニングやバグ発生時
タスクにチケットを起票して、、、
詳細を埋めてって、、、
担当者を自分にして、、、
実装時
デザイン確認して、、、、
モックデータ確認して、、、
要件の漏れ確認して、、、
実装して、、、
レビュー時
セルフレビューチェックリスト確認して、、、
PRを作って、、、
PRの内容埋めて、、、
指摘対応して、、、、
なんとここまで全て手動でやっていました(今となっては信じられない)
それでは早速！！
1. まずMCP周りを整える
MCPを繋ぐために以下記事を参考にしながら、
Git hub/Figma/JiraのMCPを設定しました
▪️Git hub
https://qiita.com/shiminori0612/items/ef68132781937a8b0566
▪️Figma
https://qiita.com/syukan3/items/497a8a1aa93b4e2bafe8
▪️Jira
https://zenn.dev/shogo828/articles/48bb44e3d74090
2. Skills/rulesの作成
自動PR作成コマンド
---
name: create-pr
description: GitHubのPull Requestを自動作成する。PRボディに「目的・方針・チケットURL・テスト観点・変更点のスクリーンショット」セクションを含む定型フォーマットで生成する。「PRを作って」「プルリク作成」「PR出して」「create PR」と言われたとき、またはJIRAチケットURLとともにPR作成を依頼されたときに適用する。
---
# PR 自動作成
git の差分・ログと JIRA チケット情報をもとに、定型フォーマットの PR を生成して `gh pr create` で作成する。
## ワークフロー
### Step 1: 現状把握
以下のコマンドを**並列**で実行する。
```bash
git status
git log main..HEAD --oneline
git diff main..HEAD --stat
```
ブランチが `main` / `origin/main` のどちらを base にするか確認し、適宜調整する。
### Step 2: JIRA チケット情報の取得
会話コンテキストまたはユーザー入力から JIRA チケットキーを抽出する。
キーが取得できた場合 → `jira_get_issue_summary` MCP ツールを呼び出し `summary` と `description` を取得する。
取得できない場合 → ユーザーに「チケット URL を教えてください」と一度だけ確認する。それでも不明なら空欄プレースホルダーのまま進める。
### Step 3: PR タイトルの決定
```
<type>(<scope>): <JIRA キー> <日本語で変更概要>
```
- `type`: `feat` / `fix` / `chore` / `refactor` / `docs` など
- `scope`: 変更した機能名（例: `UserList`、`auth`）
- 例: `feat(UserList): SCRUM-33 ユーザー詳細モーダルを実装`
### Step 4: PR ボディの生成
以下のテンプレートを使って生成する。各セクションは **Step 1〜2 の情報から自動補完**する。
スクリーンショットセクションは自動補完できないため、プレースホルダーを残す。
```markdown
## 目的
<!-- JIRAチケット summary・description をもとに「なぜこの変更が必要か」を1〜3文で記述 -->
## 方針
<!-- 実装アプローチ・設計判断・採用したパターンを箇条書きで記述 -->
-
## チケットURL
<!-- JIRAチケットの完全URL -->
[<JIRA キー>](<チケット URL>)
## テスト観点
<!-- 変更内容から導出した手動・自動テストのチェックリスト -->
- [ ]
- [ ]
## 変更点のキャプチャ
<!-- Before / After のスクリーンショットを貼り付ける。UIに変更がない場合は「該当なし」と記載 -->
| Before | After |
| ---------------------- | ---------------------- |
| （キャプチャ） | （キャプチャ） |
```
### Step 5: ブランチのプッシュと PR 作成
```bash
# ブランチが未プッシュの場合のみ実行
git push -u origin HEAD
```
```bash
gh pr create --title "<タイトル>" --body "$(cat <<'EOF'
<生成したボディ>
EOF
)"
```
作成後、PR の URL をユーザーに返す。
---
## テスト観点の自動補完ガイド
JIRA の `description` と `git diff` からテスト観点を導出する。
| 変更の種類 | 自動生成するテスト観点の例 |
| --------------------- | ------------------------------------------------- |
| UI コンポーネント追加 | 表示確認・ローディング/エラー状態・キーボード操作 |
| API 追加 | 正常系レスポンス・404/500 エラー時の挙動 |
| フォーム | 入力バリデーション・送信成功/失敗 |
| モーダル | 開閉動作・Escape キー・オーバーレイクリック |
| テーブル | ホバー色・行クリック・空状態 |
---
## 注意事項
- `gh` CLI が未認証の場合は `gh auth login` を先に促す
- `main` への直接プッシュは行わない。必ず feature ブランチから PR を作成する
- コミットが 0 件の場合は「コミットがありません。先にコミットしてください」と伝えて中断する
- スクリーンショットは自動取得できないため、ユーザーに手動で貼り付けを依頼する
セルフレビューコマンド
---
name: self-review
description: このリポジトリ（TypeScript + React + Vite SPA）のコードを自己レビューする。rules.mdc の規約・設計思想・命名規則・テスト・既存実装の改善点を多角的にチェックする。「self-review」「セルフレビュー」「コードレビューして」「実装を確認して」と言われたとき、または実装完了後に自動的に適用する。
---
# Self Review
対象ファイルを以下の 6 観点でレビューし、問題を重要度付きで報告する。
## 観点と確認項目
### 1. ルール準拠（`rules.mdc`）
- `any` を使っていないか → `unknown` + 型ガード、または具体ユニオンに
- インポートパスが `@/` エイリアス経由か（深い相対パス `../../../` は禁止）
- 生の `fetch` をコンポーネントやフックに直書きしていないか → `utils/api/apiRequest.ts` 経由
- MSW ハンドラが `src/mocks/handlers/<リソース>.ts` に分割され `handlers/index.ts` で集約されているか
- `browser.ts` を直接編集していないか
- ユーザー向け文言が `@/constants/messages` に集約されているか
- 色の Hex がコンポーネントに直書きされていないか
- マジックナンバーが名前付き定数になっているか
### 2. 設計思想
- feature ローカルのものが誤って `component/` に置かれていないか（3 feature 未満の再利用は feature 内に留める）
- `component/` に業務ロジック・API・ドメイン文言が混入していないか
- データ取得ロジックがカスタムフック（`hooks/useXxx.ts`）に分離されているか
- ローディング / 空 / エラーの 3 状態が UI で明示されているか
- API 関数が `features/<FeatureName>/api.ts` か `utils/api/` に置かれているか（コンポーネント直書き禁止）
- 型が `src/types/` または `features/<FeatureName>/types.ts` に定義されているか
### 3. タイポ
- 変数名・関数名・コメント・文字列リテラル・CSS クラス名にスペルミスがないか
- 日本語文言に誤字・脱字がないか
### 4. 命名規則
| 種別 | 期待する規則 |
|------|------------|
| React コンポーネントファイル | `PascalCase.tsx` |
| フック | `useXxx.ts`（`use` + camelCase） |
| ユーティリティ | `camelCase.ts` |
| feature ディレクトリ | `PascalCase/`（例: `UserList/`） |
| Props 型 | `XxxProps` |
| 定数（モジュール横断） | `UPPER_SNAKE_CASE` |
| boolean 変数 | `is` / `has` / `can` / `should` プレフィックス |
| イベントハンドラ（内部） | `handleXxx` |
| イベントハンドラ（props） | `onXxx` |
### 5. テスト
- `tests/` または `*.test.tsx` が存在するか
- テストが未導入の場合、テストすべき純関数・フックを指摘する
- ビジネスロジックが純関数またはカスタムフックに分離されテスト可能な形になっているか
### 6. 既存実装の改善
- 同じ処理が複数箇所に重複していないか（共通化を提案）
- `useEffect` のクリーンアップ（`cancelled` フラグ等）が漏れていないか
- `catch` が空になっていないか（空の catch 禁止）
- 不要な `React.memo` / `useMemo` / `useCallback` の過剰使用がないか
- `console.log` のデバッグ残留がないか
- `TODO` / `FIXME` コメントが放置されていないか
---
## 出力フォーマット
レビュー結果は以下の形式で報告する。問題がない観点は「✅ 問題なし」と明記する。
```
## Self Review: <対象ファイル or 機能名>
### 1. ルール準拠
🔴 **Critical**: <必ず直すべき問題>
🟡 **Suggestion**: <改善が望ましい問題>
✅ 問題なし
### 2. 設計思想
...
### 3. タイポ
...
### 4. 命名規則
...
### 5. テスト
...
### 6. 既存実装の改善
...
---
### まとめ
- 🔴 Critical: N 件
- 🟡 Suggestion: N 件
- 修正必須ファイル: <ファイルパス一覧>
```
重要度の定義:
- 🔴 **Critical**: ルール違反・型安全性の破壊・設計原則違反。マージ前に必ず修正。
- 🟡 **Suggestion**: 改善が望ましいが即時対応でなくてもよい。
- 🟢 **Nice to have**: 任意の改善提案。
3. 実装
JIRA MCPを接続後、
JIRAチケットから要件の詳細を取得。
※要件はテンプレートの部分をpdmの方に記載してもらう
Figma MCPからデザイン取得。(※記載のデザインはテンプレートです)
↓そのまま要件とデザインから実装
ワイ：「実装内容は置いておいて、outputはなかなかですな🥸」
実装内容をレビュー
🚨ここが大事、実装内容や設計思想に沿っているかを人間がレビュー🚨
output精度を上げるために試行錯誤は必要そうだけど、
今回は一旦OKだね👍
4. セルフレビュー
2で作成した「self-review」コマンドを実行
いい感じ。ルールをもっと厳格にすればoutputの質も上がりそう
5. 自動PR作成
2で作成した「create-pr」コマンドを実行
これが地味に楽。今まで手作業で作成してたのが馬鹿らしい...
開発リードタイムめちゃくちゃ短くなった！！！🎉🎉🎉🎉
最後に
やっと重い腰を起こして触ってみましたが、
これはすごい！！
便利と感じる一方で、
人間のレビューはやっぱり必須だなぁと感じました。
これからの開発はAIとともに進化しそう。
株式会社Hello worldでは、一緒に働く仲間を募集中です。
興味のある方はぜひチェックしてみてください！