はじめに

この記事は、株式会社asken (あすけん) Advent Calendar 2025の12/8の記事です。

こんにちは。iOSエンジニアの三浦です。

皆さんは大規模なPRのレビュー依頼が来たとき、どこから手をつければいいかわからなくなったことはないでしょうか。PRの分割指針を設けていても、実装していくうちに変更差分がいつの間にか大きくなったり、既存実装の都合で複雑になったりしてしまうのはよくある話です。

加えて、私たちのチームでは、メンバーの増加とAIによる実装の高速化に伴い、PRレビューを効率的に実施する必要性が高まってきました。

これらの課題を解決するため、Claude Codeのスラッシュコマンド機能を使ってPR関連業務を効率化するツール群を構築しました。本記事では、その設計と実装について紹介します。

なお、本記事ではClaude Codeの利用を想定していますが、Cursorでも同様に適用可能です。

作成したコマンド

まずは全体像から紹介します。今回作成したコマンドと使い方は以下の通りです。

👉 実際のコマンドはこちら（GitHub）

※ GitHub側で更新される可能性があるため、記事内の説明は2025年12月8日のブログ公開時点のものです。最新の使い方についてはREADMEをご覧ください。

前提条件

本ツール群を利用するには、以下の環境が必要です。

GitHub CLI (gh): PR情報の取得や作成に使用します。
Claude Code または Cursor: スラッシュコマンドの実行環境として必要です。

コマンド一覧

コマンド	目的	実行タイミング
`/git:commit`	論理単位でのコミット作成	実装完了時
`/pr:create`	PR説明文の生成・更新	PR作成時・更新時
`/pr:assist-review`	PRの構造理解支援	レビュー開始前
`/pr:analyze-feedback`	フィードバック分析・対応案生成	レビュー後の対応時

基本的な使い方

# 変更を論理単位でコミット（レビュイー）
/git:commit

# コミット後にpushも実行
/git:commit -p

# 現在のブランチからPR作成（レビュイー）
/pr:create

# 既存PRの説明文を更新（レビュイー）
/pr:create https://github.com/owner/repo/pull/123

# レビュー準備（レビュワー）
/pr:assist-review https://github.com/owner/repo/pull/123

# フィードバック対応（レビュイー）
/pr:analyze-feedback https://github.com/owner/repo/pull/123

配置方法

Claude Codeの場合は ~/.claude/commands/ ディレクトリに配置します。サブディレクトリで整理でき、commands/git/commit.md は /git:commit として呼び出せます。

ディレクトリ構成例：

~/.claude/commands/
- git/
  - commit.md
- pr/
  - create.md
  - assist-review.md
  - analyze-feedback.md

Cursorの場合はCursor Commandsとして配置します。

Claude CodeとCursor間で共通のCommandを利用したい場合は、Cursorの「基本設定 > Cursor Settings > Rules and Commands」から「Import Claude Commands」を有効にすることで、~/.claude/commands に配置したコマンドを両方で利用できます。

なぜ作ったのか：AI×人のハイブリッドレビュー体制

私たちのチームのレビュー体制

私たちのチームでは、PRレビューを人によるレビューとAIによるレビューのハイブリッド体制で実施しています。

AIレビュー（Devin）： PRに devin_review ラベルを付与すると、GitHub Actionsを通じてDevinによるAIレビューが実行されます。コードの品質・設計、潜在的なバグ、改善提案などを自動でコメントしてくれます。

人によるレビュー： AIレビューと並行して、チームメンバーが設計判断やビジネスロジックの妥当性を確認します。

この体制において、「レビュワーがPRを理解するための支援」と「レビュイーがフィードバックに対応するための支援」をClaude Codeで自動化することにしました。

具体的な課題

PRレビューでは、以下のような点に工夫の余地があります。

全体像の把握に時間がかかる：変更ファイルが多いと、どこから見ればいいかわからない
修正前後の挙動の違いがわかりにくい：diffだけでは、実際の挙動変化が見えない
レビュー観点の抜け漏れ：機能確認に集中し、パフォーマンスやセキュリティの観点を見落としがち
フィードバック対応の管理が煩雑：複数のレビュワーからのコメントを整理・追跡するのが大変

これらの課題を解決するために、各フェーズで専用のコマンドを用意し、以下のようなワークフローを構築しました。

全体の流れ

各コマンドの詳細

`/git:commit`：論理単位でのコミット作成

目的

変更を論理的な単位に分割し、わかりやすいコミット履歴を作成します。レビュワーがコミット単位で変更を追いやすくなります。

仕組み

git status・git diff・git diff --cached で変更内容を確認
変更を機能単位・変更種別・依存関係で分類
各単位ごとに適切なコミットメッセージを生成
順番にコミットを作成
-p または --push オプション指定時はpushも実行

コミットタイプ

タイプ	用途
feat	新機能追加
fix	バグ修正
refactor	リファクタリング（機能変更なし）
style	コードスタイル変更（フォーマット等）
chore	ビルド、設定、依存関係等
docs	ドキュメントのみの変更
test	テストの追加・修正

設計意図

論理的な分割：1つのコミットに複数の変更目的が混在しないようにしています
コミットメッセージの統一：feat: / fix: / refactor: 等のプレフィックスで変更種別を明示します
レビュー効率化：コミット単位でレビューできるため、大きなPRでも変更の意図が追いやすくなります

`/pr:create`：PR説明文の生成・更新

目的

テンプレートに沿ったPR説明文を自動生成し、レビュワーが理解しやすいPRを作成します。既存PRの説明文更新にも対応しています。

仕組み

gh pr view と gh pr diff でPR情報と変更内容を取得
リポジトリの .github/pull_request_template.md を読み込み
テンプレートに沿った説明文を生成
新規の場合：gh pr create --draft でdraft PRを作成
既存PRの場合：gh api でPR説明文を更新

PR説明文の整合性検証

既存PRの説明文を更新する際、実際のコード変更との整合性を必ず検証しています

PR説明文に記載された各変更項目が、実際のdiffに存在するか
diffに含まれる主要な変更が、PR説明文に漏れなく記載されているか
途中のコミットで変更が取り消し・修正されていないか

設計意図

テンプレート準拠：チームで決めたPRテンプレートに沿った説明文を自動生成することで、情報の抜け漏れを防いでいます
draft優先：デフォルトでdraft PRとして作成し、意図しないマージを防止しています
更新対応：フィードバック対応後など、PR説明文を最新の状態に更新できます
整合性検証：PR説明文と実際のコード変更の乖離を防止しています

`/pr:assist-review`：PRの構造理解支援

目的

レビュワーがPRの全体像を素早く把握し、重要なレビュー観点を見落とさないようにします。

仕組み

GitHub APIからPR情報（説明文、変更ファイル、コミット履歴）を取得
変更内容を分析し、構造図（Mermaid）を生成
修正前後の挙動比較表を作成
レビュー観点をカテゴリ・優先度別に整理
調査結果を PR_Review_{pr_number}.md として出力

分析内容

クラス構造の分析：クラス間の継承・実装関係、依存関係
関数・メソッドの分析：呼び出し関係、シグネチャ、責務
データフローの分析：データの受け渡し、変換、保存
処理フローの分析：API呼び出し順序、条件分岐、非同期処理
状態遷移の分析：状態定義と遷移条件

出力例

以下は、実際にコマンドを実行した際の出力イメージです（一部抜粋）。

# PR Review Assistant: ユーザープロフィール編集機能の追加

## PR基本情報（最小限）
- **PR**：#456 - [owner/repo](https://github.com/owner/repo/pull/456)
- **作成者**：@developer
- **変更規模**：8ファイル、+245/-32行
- **調査日時**：2025-12-01 10:30
- **調査結果ファイル**：`PR_Review_456.md`

## 目的
ユーザーが自身のプロフィール情報（表示名、自己紹介文、アバター画像）を
編集できる機能を追加する。

## 全体像
### 変更の概要
プロフィール編集画面の新規作成と、既存のユーザー設定画面への導線追加。
バックエンドAPIは既存のものを利用。
### 主要な変更領域
- ProfileEditViewController（新規）
- UserSettingsViewController（導線追加）
- ProfileEditViewModel（新規）
- UserRepository（メソッド追加）

## 修正前後の挙動比較
| 機能/修正項目 | 修正前 (Before) | 修正後 (After) | 備考 |
| :--- | :--- | :--- | :--- |
| プロフィール編集 | 編集機能なし | 表示名・自己紹介・アバターを編集可能 | ProfileEditViewController |
| 設定画面 | プロフィールへの導線なし | 「プロフィール編集」セルを追加 | UserSettingsViewController |
| バリデーション | - | 表示名1-20文字、自己紹介0-200文字 | ProfileEditViewModel |

## 懸念点とレビュー観点
### 高優先度（必須確認）
- [ ] 画像アップロード時のファイルサイズ制限が適切か
- [ ] 入力値のサニタイズ処理が実装されているか
### 中優先度（推奨確認）
- [ ] 編集中に画面を離れた場合の確認ダイアログ
- [ ] エラー時のユーザーへのフィードバック
### 低優先度（任意確認）
- [ ] アクセシビリティ対応（VoiceOver等）

## 詳細情報

UML図の例

処理フロー図の例

設計意図

情報の提示順序：「目的→全体像→懸念点→詳細」の順で提示し、自然な理解の流れを作っています
Mermaid図による可視化：構造や処理フローを図で示して全体像のイメージを容易にします
Before/After比較表：修正前後の挙動変化を明確に可視化しています
レビュー観点のカテゴリ化：機能性、セキュリティ、パフォーマンスなど8カテゴリに分類し、優先度を設定しています
理解の個別最適化：PR作成者の説明文や既存のテンプレート形式によらず、レビュワー自身にとって最も理解しやすい形に最適化できます

`/pr:analyze-feedback`：フィードバック分析・対応案生成

目的

AI・人両方のレビューコメントを整理し、優先度付きの対応アクションプランを生成します。

仕組み

GitHub APIからレビューコメント（レビュー、Issue/Discussionコメント、ファイル単位のコメント）を取得
コメントをタイプ別に分類
優先度別に整理
各コメントに対する対応案を生成
フェーズ別のアクションプランとレビュワーへの回答案を作成

コメント分類

タイプ別：

タイプ	説明
Bug	実装のバグや論理エラー
Improvement	コードの改善や最適化の提案
Style	コードスタイルやフォーマット
Architecture	設計やアーキテクチャの懸念
Performance	パフォーマンスの懸念や最適化
Security	セキュリティの懸念事項
Testing	テストの不足や改善
Question	説明や確認が必要な質問

優先度別：

優先度	説明	対象
Must Fix	マージ前に必須	バグ、セキュリティ、重大な設計問題
Should Fix	対応を強く推奨	パフォーマンス問題、重要な改善提案
Nice to Have	対応は任意	スタイル、軽微な改善、ドキュメント
Info	対応不要	質問への回答、称賛

出力例

# PR Feedback Analysis Report

## サマリー
| 項目 | 値 |
|------|-----|
| 総コメント数 | 5 |
| 必須対応 | 1 |
| 推奨対応 | 2 |

## フィードバック一覧
### Must Fix
| # | タイプ | レビュワー | ファイル | 内容 | 対応案 |
|---|--------|-----------|----------|------|--------|
| 1 | Bug | @reviewer | file.swift:45 | TODOコメントの解決 | 仕様担当と相談してSearchModeを決定 |

## アクションプラン
### Phase 1: 必須対応
- [ ] task1

### Phase 2: 推奨対応
- [ ] task2

## レビュワーへの回答案
### @reviewer
> ご指摘いただいたTODOコメントの件を修正しました。コミット: abc123

設計意図

2軸での分類：タイプ別×優先度別の分類で「何を優先して対応すべきか」を明確化しています
対応案の自動生成：AIが対応案を提示することで、レビュイーの対応負荷を軽減しています
回答案の生成：レビュワーへの返信を自動生成し、コミュニケーションコストを削減しています

実装のポイント

Cursorとの互換性を意識した設計

私たちのチームでは、Claude Codeを利用するメンバーとCursorを利用するメンバーが混在しています。そのため、各コマンドはスキル参照をせず、コマンド単体で完結する設計にしています。

Claude には「Skills」という機能があり、複数のコマンドやツールからエージェントが自律的に共通ロジックを呼び出すことができます。一方、Cursor は現状この Skills をネイティブにはサポートしていません。チーム全員が同じ仕組みを使えるようにするため、本記事のコマンドはSkillsに依存しない設計としました。

GitHub CLIを活用したデータ取得

PR情報の取得には gh コマンドを使用しています。Claude Codeから直接実行できるため、シームレスなワークフローが実現できました。

# PR基本情報を取得
gh api repos/{owner}/{repo}/pulls/{number} --jq '{
  title,
  body,
  state,
  author: .user.login,
  base: .base.ref,
  head: .head.ref
}'

# 変更ファイル一覧を取得
gh api repos/{owner}/{repo}/pulls/{number}/files --jq '.[] | {
  filename,
  status,
  additions,
  deletions
}'

# レビューコメントを取得
gh api repos/{owner}/{repo}/pulls/{number}/comments

PR説明文更新時の注意点

gh pr edit コマンドはGitHub Projects Classic廃止の影響でGraphQLエラーが発生することがあります。この問題に遭遇した際は、gh api を使った更新で回避できました。

# gh api を使ったPR説明文の更新
gh api repos/{owner}/{repo}/pulls/{number} -X PATCH -F body=@/tmp/pr_body.md

コマンド定義ファイルの構造

各ファイルの先頭には、FrontMatter形式でメタデータを記述できます。

---
description: Pull Requestを理解しやすくするための支援ツールです。
arguments:
  - name: pr-url
    description: レビューしたいPull RequestのURL
    required: false
    default: ""
    argument-hint: "PR URLを入力してください。形式: https://github.com/{owner}/{repo}/pull/{number}"
allowed-tools:
  - Bash
  - Read
  - Write
---

description：コマンドの説明。Claude Codeが「どのコマンドを使うべきか」を判断する手がかりになります
arguments：コマンドの引数を定義。$ARGUMENTS でコマンド本文から参照できます
allowed-tools：コマンド実行時に使用可能なツールを制限できます（セキュリティ向上）

成果

この方法を運用していく中で、以下のような効果を実感しています。

定性的な効果：

レビュワーがPRの全体像を把握する時間が短縮された
レビュー観点の抜け漏れが減少した
フィードバック対応の優先順位が明確になった
AIと人のハイブリッドレビューにより、品質とスピードの両立ができるようになった

運用面での変化：

コミット・PR作成・レビュー準備・フィードバック対応といったGit関連の操作を、ほぼAI経由で実行するようになった
AIに常にコンテキストを共有しながら進められるため、一貫した支援を受けやすくなった
定型作業だと感じたらすぐにCommands化を検討するようになった

課題と今後の展望

現在はコマンドを明示的に呼び出す設計にしていますが、今後はCursorとの互換性の問題を解消し、Skill化してAIが状況に応じて自律的にツールを選択・実行できる環境への進化を検討しています。

今後取り組みたいこと：

CommandsからSkillへの移行：AIが状況に応じて自律的にツールを選択・実行
CI/CDとの連携：PR作成時に自動でレビュー支援レポートを生成
レビューコメントのトレンド分析：よくある指摘パターンの可視化
チーム固有のレビュー観点の追加：プロジェクト特有のチェック項目をカスタマイズ

おわりに

PRレビューの効率化の課題に対して、Claude Codeのスラッシュコマンドを活用したツール群を構築しました。まだまだ改善の余地があるツールなので、日々の運用の中でさらに磨き上げていきたいと思います。

スラッシュコマンドは比較的簡単に作成・カスタマイズできます。本記事で紹介した内容を参考に、チームの課題や運用フローに合わせて自分なりのコマンドを作り上げていってください。

参考リンク

積極採用中です

askenではエンジニアを絶賛募集中です。

まずはカジュアルにお話しできればと思いますので、ぜひお気軽にご連絡ください！

asken techのXアカウントで、askenのテックブログやイベント情報など、エンジニアリングに関する最新情報を発信していますのでフォローお願いします。

Follow @asken_dev

はじめに

作成したコマンド

前提条件

コマンド一覧

基本的な使い方

配置方法

なぜ作ったのか：AI×人のハイブリッドレビュー体制

私たちのチームのレビュー体制

具体的な課題

全体の流れ

各コマンドの詳細

/git:commit：論理単位でのコミット作成

目的

仕組み

コミットタイプ

設計意図

/pr:create：PR説明文の生成・更新

目的

仕組み

PR説明文の整合性検証

設計意図

/pr:assist-review：PRの構造理解支援

目的

仕組み

分析内容

出力例

UML図の例

処理フロー図の例

設計意図

/pr:analyze-feedback：フィードバック分析・対応案生成

目的

仕組み

コメント分類

出力例

設計意図

実装のポイント

Cursorとの互換性を意識した設計

GitHub CLIを活用したデータ取得

PR説明文更新時の注意点

コマンド定義ファイルの構造

成果

課題と今後の展望

おわりに

参考リンク

積極採用中です

`/git:commit`：論理単位でのコミット作成

`/pr:create`：PR説明文の生成・更新

`/pr:assist-review`：PRの構造理解支援

`/pr:analyze-feedback`：フィードバック分析・対応案生成