😉

月間PR数 65→184を達成！Devinにレビューを丸投げするためのTips

maya honey

2025/09/22に公開

こんにちは、mayaです！
突然ですが、こんなお悩みありませんか？？
『AI駆動開発で実装スピードは上がったけど、レビューが追いつかなくてパンクしちゃう😢』
今回はそんなあなたに向けて、「AIにコードレビューを丸投げしたらレビュー効率が180%向上した話」をしようと思います！

使用したのは万能開発エージェントのDevinくんです
https://docs.devin.ai/get-started/devin-intro
コードレビューにDevinを活用することで「品質」を犠牲にすることなく、「レビュースピード」を上げることができたので、取り組んだ内容を共有させていただきます！
!この記事の成果サマリー
🚀 1ヶ月でレビューPR数が180%UP！（65件→184件）
⚡ ドメインロジックのレビューもDevinにお任せできた
📈 人間のレビュー負担の大幅減に成功

 この記事で分かること / 対象読者Devinをある程度使用したことがある人向けの内容です
Github PR作成時に自動でDevinにレビュー依頼する方法
僕のチームが実際に使用しているプロンプト

 筆者のステータスエンジニア歴：そろそろ3年
主な開発環境：React/TypeScript、Next.js、Node.js
Devin導入のきっかけ：レビューに追われる毎日が辛すぎたため

 Devin導入背景｜レビュー待ちで開発が止まった僕らのチームが本格的にAI駆動開発をスタートしたのは今年の6月頃。

1ヶ月たらずで実装スピードが劇的に向上するなど良い結果が出たものの、同時に新たな問題も発生しました
『レビューが追いつかない！！！』
実装スピードが上がっても、レビュー速度が上がらない限り開発速度は頭打ちになります。すべての実装はレビューを通らなきゃいけないわけで レビュー速度＝開発速度 なのだと改めて気づいた瞬間でした。
時系列で言うと、今年の5月はAIをほとんど導入していなくて月間PR処理数は27件。6月にAI駆動開発を導入したことで65件まで跳ね上がったんですが、このあたりでレビュー速度の限界を感じ始めました。

 DevinのPlaybookで2つのレビューを実現そこで導入したのがDevinによる自動レビューです。

実装もAIで高速化したし、レビューにもAIを使っちゃおうということで
使用したのはDevinの「Playbook」という機能です

大きく分けて2種類のPlaybookを作成しました。
!💡 Playbookとは？

特定のタスクを実行させるためのカスタムプロンプトを実行させることができる機能。レビュー用PlaybookやPR作成用Playbookなどプロンプト次第で色々作れる。汎用性が高い。
プレイブックの作成｜Devin公式

 1. 実装ガイドラインチェック用Playbookプロジェクト固有の実装ルールに沿っているか？という観点でレビューしてもらいます。

下記は例です


チェック項目
内容
重要度


アーキテクチャ
レイヤー構造の整合性確認
高

命名規則
ディレクトリ・ファイル・関数名の規約準拠
中

依存関係
責任分離と依存方向の適切性
高

コード規約
リンター・フォーマッターのルール遵守
中

うちのチームでは、リポジトリ内のdocsディレクトリにて実装ガイドラインを記述したファイルを管理しているので、Playbookからそれらを参照させています。
Playbookに直接ルールを書き込んでもOK。

ですが僕らは、他のAIエージェントにも同じコンテキストを与えたいケースがあるため、二重・三重管理を防ぐためにAI向けのナレッジはすべてリポジトリで管理してます。
📦 実際のPlaybookテンプレート（コピペ可能）## 役割
あなたはシニアエンジニアとして、Pull Requestのコードレビューを行います。

---

## スキルセット
以下の技術に精通しているものとします：

- TypeScript
- React
- Next.js（App Routerを含む）

---

## 使用宣言
作業開始時に、以下を宣言してください：
`playbook：コードレビューを使用します`

---

## レビューの進め方

1. ユーザーにレビュー対象のPull Request（PR）の番号またはURLを尋ねる。
2. PRの差分を確認し、後述する「レビュー方法」に従って実装を分析
3. レビューコメントをPR向けに出力する（GitHubコメント形式）
  - コメントは要点毎に1つ出力
  - 関連のない複数の指摘を行う場合は複数のコメントを出力してOK
4. 問題点がある場合は以下を明示する：
   - 問題の内容（具体的にどのコードが、なぜ良くないのか）
   - 参照した資料のパスや場所、ファイル名
   - 修正案には、わかりやすいようにスニペットのdiffを使用する（diffの書き方の例参照）
   - 修正案（コード付き）
   - 修正案が複数ある場合、それぞれのメリット・デメリットと推奨案
 5.レビュー完了後、`gh pr comment [PR番号] --body-file [ファイルパス]`でコメントを直接投稿する

---

## レビュー方法

### 概要

コードが既存の実装ガイドラインに準拠しているかを体系的にレビューします。機械的・網羅的なチェックを通じて、一貫性のあるコード品質を確保することを目的とします。

### 参照ガイドライン一覧

以下のガイドライン文書を必ず参照してレビューを行います：

#### アーキテクチャ・設計関連

- @docs/guidelines/アーキテクチャ.md
- @docs/guidelines/共通実装方針.md
- @docs/guidelines/API実装方針.md

#### データアクセス・処理関連

- @docs/guidelines/データ取得の実装方針.md
- @docs/guidelines/データ更新の実装方針.md
- @docs/guidelines/Prismaの実装方針.md

#### フロントエンド・バックエンド関連

- @docs/guidelines/フロントエンド実装方針.md
- @docs/guidelines/バックエンド実装方針.md
- @docs/guidelines/NextAuth利用ガイドライン.md

#### エラー・バリデーション関連

- @docs/guidelines/エラーハンドリング実装方針.md
- @docs/guidelines/バリデーション実装方針.md

#### テスト・品質関連

- @docs/guidelines/ユニットテスト実装方針.md
- @docs/guidelines/テーブル定義書運用方針.md

#### コーディング規約関連

- @docs/guidelines/命名方針.md
- @docs/guidelines/コメント方針.md
- @docs/guidelines/定数定義方針.md

#### その他

- @docs/guidelines/ローディング実装方針.md
- @docs/guidelines/環境変数の管理方法.md

### レビュー実行フロー

#### 1. レビュー対象の確認

**必須**: 実行前に以下の確認をユーザーに行う

```text
ガイドライン準拠レビューを実行するのだ：

対象確認:
- レビュー対象のファイル・ディレクトリを確認
- 変更差分の把握（PRの場合）
- 実装の概要理解

レビュー方針:
- 全ガイドライン文書に基づく網羅的チェック
- 違反箇所の具体的指摘
- 改善提案の提示

この方針でレビューを実行してよろしいですか？ (y/n)

 2. 対象ファイルの分析以下の手順で対象ファイルを体系的に分析します：
2.1 ファイル種別の判定- TypeScript/JavaScript ファイル → フロントエンド・バックエンド実装方針適用
- Prisma スキーマファイル → Prisma実装方針適用
- テストファイル(.spec.ts, .test.ts) → ユニットテスト実装方針適用
- 設定ファイル → 環境変数管理方針適用
2.2 レイヤー判定- src/app/ → プレゼンテーション層
- src/servers/services/ → Service層
- src/servers/usecase/ → Usecase層
- src/servers/repositories/ → Repository層
- src/servers/helpers/ → Helper層
- src/lib/ → Utility層

 3. アーキテクチャ準拠チェック3.1 レイヤー間依存関係チェック
 Service層から他のService層を直接呼び出していないか

 Helper層からRepository層を呼び出していないか

 Repository層呼び出し権限が適切か（Usecase層・Service層のみ）

 循環依存が発生していないか
3.2 責務分離チェック
 各関数・クラスが単一責務を持っているか

 ビジネスロジックが適切な層に配置されているか

 データアクセスロジックがRepository層に集約されているか

 4. コーディング規約チェック4.1 命名規則チェック
 ファイル名がケバブケース（例: user-service.ts）

 関数名がキャメルケース（例: getUserInfo）

 定数名がアッパースネークケース（例: MAX_RETRY_COUNT）

 型名がパスカルケース（例: UserBasicInfo）
4.2 コメント方針チェック
 関数に適切なコメントが記述されているか

 複雑なロジックに説明コメントがあるか

 TODO・FIXMEコメントが適切に記述されているか

 5. データアクセス実装チェック5.1 データ取得実装チェック
 Server Actionsが適切に使用されているか

 キャッシュ戦略が適切に実装されているか

 エラーハンドリングが実装されているか

 読み書き分離（prisma.$reader）が適切に使用されているか
5.2 データ更新実装チェック
 トランザクション境界が適切に設定されているか

 楽観的ロック（updated_at）が実装されているか

 バリデーションが適切な層で実行されているか

 アクションログが記録されているか

 6. エラーハンドリング・バリデーションチェック6.1 エラーハンドリングチェック
 構造化されたエラークラス（BusinessError等）が使用されているか

 try-catch文が適切に配置されているか

 エラーログが適切に出力されているか

 ユーザー向けエラーメッセージが適切か
6.2 バリデーションチェック
 Yupスキーマが適切に定義されているか

 プレゼンテーション層でバリデーションが実行されているか

 エラーメッセージが日本語で適切に定義されているか

 7. テスト実装チェック7.1 テスト対象チェック
 必須テスト対象ディレクトリ（helpers/, utils/, services/, usecase/）にテストが存在するか

 TDD（Red-Green-Refactor）サイクルが実装されているか
7.2 テスト内容チェック
 ブラックボックステストが実装されているか

 ホワイトボックステストが実装されているか

 モック化が適切に行われているか

 レビュー結果の出力形式
 8.1 レビューサマリー# 実装ガイドライン準拠レビュー結果

## 📊 総合評価
- **準拠度**: XX% (YY項目中ZZ項目が準拠)
- **重要度別違反数**: 
  - 🔴 Critical: X件
  - 🟡 Warning: Y件
  - 🔵 Info: Z件

## 📋 チェック結果詳細

### ✅ 準拠している項目
- アーキテクチャ層間依存: 適切
- 命名規則: 準拠
- ...

### ❌ 違反している項目
- Service層間依存: src/services/mypage/UserService.ts:34
- エラーハンドリング未実装: src/services/admin/AdminService.ts:12
- ...

 8.2 具体的改善提案各違反項目に対して以下の形式で改善提案を提示します：
## 🔧 改善提案

### 1. Service層間依存の解消
**ファイル**: `src/services/mypage/UserService.ts:34`
**問題**: Service層から他のService層を直接呼び出し
**改善案**: 
- Usecase層での統合処理に変更
- 共通Service層の新設を検討
**参照ガイドライン**: @docs/guidelines/アーキテクチャ.md

### 2. エラーハンドリングの実装
**ファイル**: `src/services/admin/AdminService.ts:12`
**問題**: try-catch文が未実装
**改善案**:
- BusinessErrorクラスを使用した構造化エラー処理
- 適切なログ出力の追加
**参照ガイドライン**: @docs/guidelines/エラーハンドリング実装方針.md

 品質確保のポイント
 レビューの網羅性全ガイドライン文書の内容を反映
チェック項目の漏れを防ぐ体系的アプローチ
実装パターンごとの適切なガイドライン適用

 改善提案の具体性違反箇所の正確な特定（ファイル名・行数）
実装可能な具体的改善案の提示
参照すべきガイドライン文書の明示

 継続的改善レビュー結果を通じたガイドライン文書の改善
よくある違反パターンの文書化
チーム全体での知識共有

 エラー発生時の対処
 ガイドライン文書が見つからない場合該当ガイドライン文書の不在をユーザーに報告
一般的なベストプラクティスに基づく代替レビュー
ガイドライン文書作成の提案

 判断に迷う実装パターン複数の解釈が可能な場合は全てを提示
ユーザーに判断を委ねる
将来のガイドライン明確化提案

 まとめこのプレイブックに従うことで：

一貫性: 統一されたガイドライン準拠チェック

網羅性: 全ガイドライン文書に基づく体系的レビュー

具体性: 実装可能な改善提案の提示

継続性: レビュー品質の維持・向上
重要: すべてのレビューは必ずユーザーの事前確認を取ってから実行します。

 実行しないこと（非対応範囲）ファイルの直接変更
ブランチやPRの作成
テストやビルドの実行

 参考資料Next.js公式ドキュメント
Prisma公式ドキュメント
React公式ドキュメント
TypeScript公式ドキュメント
MySQL公式ドキュメント


 2. ビジネスロジック検証用Playbook処理内容が要件を満たしているか？という、より本質的な部分のレビューです。


チェック項目
内容
重要度


要件整合性
要件定義書との一致確認
高

ロジック妥当性
ビジネスルールの正確な実装
高

テスト網羅性
エッジケースを含む十分なテスト
高

UXフロー
ユーザー操作との一致
中

あらかじめ要件定義書や仕様書、テストケースなどをリポジトリ内で管理しておいて、Playbookからそれらを参照させます。
🎯 ビジネスロジック検証Playbookの例## 役割
あなたはシニアエンジニアとして、Pull Requestのコードレビューを行います。

---

## スキルセット
以下の技術に精通しているものとします：

- TypeScript
- React
- Next.js（App Routerを含む）

---

## 使用宣言
作業開始時に、以下を宣言してください：
`playbook：コードレビューを使用します`

---

## レビューの進め方

1. ユーザーにレビュー対象のPull Request（PR）の番号またはURLを尋ねる。
2. PRの差分を確認し、後述する「レビュー方法」に従って実装を分析
3. レビューコメントをPR向けに出力する（GitHubコメント形式）
  - コメントは要点毎に1つ出力
  - 関連のない複数の指摘を行う場合は複数のコメントを出力してOK
4. 問題点がある場合は以下を明示する：
   - 問題の内容（具体的にどのコードが、なぜ良くないのか）
   - 参照した資料のパスや場所、ファイル名
   - 修正案には、わかりやすいようにスニペットのdiffを使用する（diffの書き方の例参照）
   - 修正案（コード付き）
   - 修正案が複数ある場合、それぞれのメリット・デメリットと推奨案
 5.レビュー完了後、`gh pr comment [PR番号] --body-file [ファイルパス]`でコメントを直接投稿する

---

## レビュー方法

### 概要

実装されたコードがアプリケーションの仕様・ビジネスルールに沿って正しく動作するかを段階的に分析します。仕様情報の自動収集と、ユーザー提供情報に基づく実装検証を組み合わせることで、実用的で信頼性の高いドメインレビューを実現します。

### 段階的レビュー実行フロー

#### Phase 1: 自動情報収集
実装種別に応じて以下のディレクトリから詳細仕様を収集

**API実装の場合** (`docs/api/`)
- エンドポイント仕様書
- リクエスト・レスポンス定義
- 認証・認可要件
- エラーレスポンス仕様

**バッチ実装の場合** (`docs/batch/`)
- バッチ処理仕様書
- 実行タイミング・頻度
- データ処理ロジック
- エラーハンドリング要件

**画面実装の場合** (`docs/page/`)
- 画面仕様書（画面パスと対応するディレクトリ構成）
- UI/UX要件
- 画面遷移フロー
- 入力検証ルール
- 表示データ仕様

#### Phase 2: ユーザー情報提供・確認
Github PRの概要やコメント、ユーザーからの補足説明などから情報を収集、不明点は必要に応じてユーザーに確認・質問すること

- 収集した仕様情報の正確性確認
- 不足している仕様・要件の補完
- 最新の仕様変更・追加要件の確認
- レビュー対象機能の優先順位・重要度
- 実装内容の説明、仕様の説明
- レビュー時の留意点

#### Step 3: ドメインレビュー実行

確定した仕様情報に基づいて実装レビューを実行
要件/仕様情報を正として、要件を漏れなく実装できているかチェックします

#### Step 4: エッジケース・例外処理検証

##### 4.1 境界値・異常系テスト観点

- [ ] 数値の上限・下限値での動作確認
- [ ] 文字列長の制限値での処理確認
- [ ] 空値・null値の適切な処理
- [ ] 日時の境界値（月末・年末等）での動作
- [ ] 大量データでの性能・メモリ使用量

##### 4.2 競合状態・並行処理チェック

- [ ] 同時実行時のデータ競合回避
- [ ] 重複処理の防止機構
- [ ] 非同期処理の完了待ち・エラーハンドリング
- [ ] タイムアウト処理の適切な実装

#### Step 5: 外部システム連携検証

##### 5.1 API・外部サービス連携

- [ ] 外部APIの仕様変更への対応
- [ ] 通信エラー・タイムアウト時の処理
- [ ] リトライ機構・サーキットブレーカー
- [ ] レート制限・制御機構の実装

##### 5.2 データ同期・整合性

- [ ] 外部システムとのデータ同期タイミング
- [ ] データ不整合発生時の検知・修復
- [ ] バッチ処理での大量データ処理

#### Step 6: ユーザー体験・運用観点

##### 6.1 ユーザー体験チェック

- [ ] エラーメッセージの分かりやすさ・適切性
- [ ] 処理時間・レスポンス性能の妥当性
- [ ] 画面遷移・フロー設計の自然さ
- [ ] アクセシビリティ・ユーザビリティ

##### 6.2 運用・監視観点

- [ ] 監視・アラート対象の適切な設定
- [ ] ログ出力内容の十分性・検索性
- [ ] トラブルシューティング情報の充実
- [ ] 性能メトリクス・KPI測定の実装

### レビュー結果の出力形式

```markdown
# ドメインロジックレビュー結果

## 📋 仕様情報の収集結果
- **収集方法**: リポジトリ内のdocsディレクトリ
- **参照した仕様書**: [収集できた仕様書のリスト]
- **ユーザー提供情報**: [ユーザーから補完された情報]
- **仕様の完全性**: 完全/部分的/不完全

## 🎯 対象機能概要
- **機能名**: XXX機能
- **ドメイン**: ユーザー管理・本人確認・決済・その他
- **主要ビジネスルール**: [収集した仕様に基づく記述]

## 📊 レビュー評価
- **仕様適合度**: XX% （収集した仕様との一致度）
- **データ整合性**: XX%
- **セキュリティ対応**: XX%
- **エラーハンドリング**: XX%

## 🔍 検証結果詳細

### ✅ 仕様に適合している観点
- [具体的な仕様要件]: 適切に実装されている
- [収集した業務ルール]: 正しく実装されている
- ...

### ⚠️ 仕様との相違・改善推奨事項
- [特定の仕様要件]: 実装が不完全または相違あり
- [収集した制約条件]: 考慮が不十分
- ...

### 🔴 重要な仕様違反・リスク
- [必須仕様要件]: 実装されていない
- [セキュリティ要件]: 仕様に反する実装
- ...

## 🔧 問題詳細と改善提案

### 1. 仕様適合性の問題
**仕様要件**: [収集した特定の仕様要件]
**実装状況**: [実際の実装内容]
**問題**: 仕様要件と実装が一致していない
**リスク**: 
- 業務要件を満たさない可能性
- システム動作の予期しない挙動
**改善提案**:
- [収集した仕様に基づく具体的な修正案]
- [仕様書で定義された処理フローへの修正]

### 2. 収集した業務ルールとの相違
**業務ルール**: [BacklogMCPで取得した業務ルール]
**実装状況**: [実際の実装での処理]
**問題**: 業務ルールが正しく実装されていない
**リスク**: [仕様書に記載されたリスク]
**改善提案**:
- [収集した仕様に基づく修正方針]
- [仕様書に記載された例外処理の実装]
正直、AIレビューを思いついた時は「実装ルールのチェックはAIでできても、ビジネスロジックのチェックは人間じゃないとできないよな...」などと思ってましたが、そんなことはありませんでした。
Devinはリポジトリ全体の実装内容を把握していて、ドメインロジックも握ってます。

さらに要件定義/仕様書を「正」として渡すことで高い精度でビジネスロジックのレビューも行ってくれました。

 運用フローはこんな感じ実際の運用フローはシンプルです：

PR作成：実装が完了したらPRを作成

自動レビュー起動：GitHub ActionsでDevinにレビューを依頼（Devin API使用）

レビューコメント：しばらくするとPRにDevinからレビューコメントが追加される

修正対応：PR作成者がDevinの指摘を確認して修正
指摘が間違っている場合はコメントでレビュアーに連携


人間のレビュー：レビュアーはDevinのレビュー内容を踏まえてレビュー開始
Playbookの呼び出し方はいくつかありますが、レビューで必ずPlaybookを使うならワークフローを定義し、Github ActionsにてDevin APIを使用して呼び出すのがベストです。
🚀 GitHub Actions設定ファイル（.github/workflows/devin-review.yml）name: Devin PR Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  devin-review:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Run Devin Review - Implementation Guidelines
        env:
          DEVIN_API_KEY: ${{ secrets.DEVIN_API_KEY }}
        run: |
          curl -X POST https://api.devin.ai/v1/playbooks/run \
            -H "Authorization: Bearer ${DEVIN_API_KEY}" \
            -H "Content-Type: application/json" \
            -d '{
              "playbook_id": "implementation-guidelines-review",
              "variables": {
                "PR_URL": "${{ github.event.pull_request.html_url }}",
                "REPO_URL": "${{ github.repository }}"
              },
              "callback_url": "https://api.github.com/repos/${{ github.repository }}/issues/${{ github.event.pull_request.number }}/comments"
            }'

      - name: Run Devin Review - Business Logic
        env:
          DEVIN_API_KEY: ${{ secrets.DEVIN_API_KEY }}
        run: |
          curl -X POST https://api.devin.ai/v1/playbooks/run \
            -H "Authorization: Bearer ${DEVIN_API_KEY}" \
            -H "Content-Type: application/json" \
            -d '{
              "playbook_id": "business-logic-review",
              "variables": {
                "PR_URL": "${{ github.event.pull_request.html_url }}",
                "REPO_URL": "${{ github.repository }}"
              },
              "callback_url": "https://api.github.com/repos/${{ github.repository }}/issues/${{ github.event.pull_request.number }}/comments"
            }'

      - name: Post Review Status
        if: always()
        uses: actions/github-script@v6
        with:
          script: |
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: '✅ Devinレビューが完了しました。コメントをご確認ください。'
            })
!Devin APIはTeamプラン以上の契約で利用可
Coreプランの場合は、DevinのWebアプリ画面がから直接呼び出すか、SlackとDevinを連携させてSlackから呼び出すのが良いかと思います。手動での呼び出しなので少し手間ですが...
Devinのレビューが終わるとこんな感じでコメントを残してくれます

 何がそんなに良いの？
 ✨ レビューの質がめちゃくちゃ高い要件書と実装を比較して、意図しないデグレや他機能への影響も検出してくれます。ドキュメントが整備されていれば、かなり高精度でビジネスロジックの検証も可能です。
要件書や仕様書がないプロジェクトも多々あると思いますが、これを機に一通り揃えてしまうのをオススメしたいです。

今後レビューの高速化を考えるなら間違いなくAIレビューが必須です。
AIレビューの精度はドキュメントの充実度に比例する
Devinに限らずAIにドメイン部分のレビューをしてもらうには、「正」となる基準が必要
私見ですが「AIフレンドリーな環境構築」がこの先当分のテーマになると思ってます。

今時間をかけてでもドキュメントを揃える価値はあると思います。

 ⚡ レビュー負荷が劇的に軽減ぶっちゃけ他人が作ったコードを0から読み込むのって大変じゃないですか！

でもDevinを使うと...
PR概要の作成
変更箇所の要点整理
問題がありそうな箇所の指摘
これらをDevinが事前にやってくれるのでレビュアーは要点を素早く把握できます。最初のキャッチアップのハードルがグッと下がる。

また、PR作成者が事前にDevinの指摘を修正してからレビュー依頼を出す運用にすることで、レビュアーの負荷はさらに軽減されます。
おおよその問題点はDevinによって指摘されている状態からレビューを始められるので、めちゃくちゃ楽にPRを捌けます。

 リポジトリを跨いだレビューもできちゃうこれはDevinならではの特徴なんですが、複数のリポジトリを跨いでレビューできちゃいます
僕が携わってるPHP/LaravelからNext.jsへのリプレイスプロジェクトでは、旧システムに要件定義書がない状態でした。でもDevinなら「旧システムの実装を正として、新システムの実装に不備はないか？」というレビューが可能なんです。
仕様書がないプロジェクトでも、Devinは頼もしいパートナーになってくれます。

 実際どれくらい効果があったの？

月
施策
PR処理数
前月比
状況


5月
AI未導入
27件
-
ベースライン

6月
AI駆動開発導入
65件
2.4倍
レビューが限界に

7月
Devinレビュー導入
184件
2.8倍
ボトルネック解消！

Devinの導入で約3倍の処理数を実現できてます。
もちろんこれはDevinだけの成果じゃなくて、チームメンバーがAI駆動開発に慣れてきたことや、別日で進めていたワークフローの効率化施策なども大いに影響していると思います。
それでもDevinの影響は本当に大きくて、開発メンバーはもう手放せない状態になってます。

それだけ価値のある取り組みでした。

 まとめレビューボトルネックに悩んでいる方はぜひ一度Devinを試してみてください。

ドキュメントが揃っていなくてもある程度の質のレビューはしてくれるはずです。Devinレビューの価値を体験するには十分です。
最後まで読んでいただき、ありがとうございました！

皆さんのプロジェクトでもレビュー速度が爆上がりすることを願っています

チェック項目	内容	重要度
アーキテクチャ	レイヤー構造の整合性確認	高
命名規則	ディレクトリ・ファイル・関数名の規約準拠	中
依存関係	責任分離と依存方向の適切性	高
コード規約	リンター・フォーマッターのルール遵守	中

チェック項目	内容	重要度
要件整合性	要件定義書との一致確認	高
ロジック妥当性	ビジネスルールの正確な実装	高
テスト網羅性	エッジケースを含む十分なテスト	高
UXフロー	ユーザー操作との一致	中

月	施策	PR処理数	前月比	状況
5月	AI未導入	27件	-	ベースライン
6月	AI駆動開発導入	65件	2.4倍	レビューが限界に
7月	Devinレビュー導入	184件	2.8倍	ボトルネック解消！

ラッコ株式会社Publication

ラッコキーワード、ラッコM&A、ラッコツールズの会社です。 Webエンジニア・SREエンジニア・インフラエンジニアを大募集しています。

この記事で分かること / 対象読者

筆者のステータス

Devin導入背景｜レビュー待ちで開発が止まった

DevinのPlaybookで2つのレビューを実現

1. 実装ガイドラインチェック用Playbook

2. 対象ファイルの分析

2.1 ファイル種別の判定

2.2 レイヤー判定

3. アーキテクチャ準拠チェック

3.1 レイヤー間依存関係チェック

3.2 責務分離チェック

4. コーディング規約チェック

4.1 命名規則チェック

4.2 コメント方針チェック

5. データアクセス実装チェック

5.1 データ取得実装チェック

5.2 データ更新実装チェック

6. エラーハンドリング・バリデーションチェック

6.1 エラーハンドリングチェック

6.2 バリデーションチェック

7. テスト実装チェック

7.1 テスト対象チェック

7.2 テスト内容チェック

レビュー結果の出力形式

8.1 レビューサマリー

8.2 具体的改善提案

品質確保のポイント

レビューの網羅性

改善提案の具体性

継続的改善

エラー発生時の対処

ガイドライン文書が見つからない場合

判断に迷う実装パターン

まとめ

実行しないこと（非対応範囲）

参考資料

2. ビジネスロジック検証用Playbook

運用フローはこんな感じ

何がそんなに良いの？

✨ レビューの質がめちゃくちゃ高い

⚡ レビュー負荷が劇的に軽減

リポジトリを跨いだレビューもできちゃう

実際どれくらい効果があったの？

まとめ

Discussion