AIコードレビューの理想と現実 ─ Devinをチームに導入して気づいたこと

エンジニアの関口です。私のチームでは、AIエージェントの Devin を使ったコードレビューを日常的に取り入れています。 この記事では、Devinをレビューツールとして活用する際の実践的な使い方や、実際に使ってみて感じたメリット・課題についてまとめます。

Devinとは

Devinは、Cognition AIが開発したAIエージェントです。 コードの実装だけでなく、仕様把握や要件出し、見積もりやコードレビューなど、開発プロセスの様々な場面で活用できます。

詳しくは公式サイトを参照してください。
https://www.devin.ai/

Devinをレビューに使う理由

コードレビューは開発プロセスにおいて重要な工程ですが、以下のような課題があります。

• レビュー工数の増加
• レビュワーの負荷が高い
• 人間同士で細かい指摘をしあうと、レビューする側・される側の双方にとって精神的負担が大きい
• レビュー観点の標準化が難しい
• 細かい指摘を見落としやすい

Devinを使ったレビューを導入することで、これらの課題を軽減できると考えています。

Devinレビューの実践方法

基本的な使い方

Devinにコードレビューを依頼する際は、以下のような観点を明確に指示します。

以下の観点でコードレビューを実施してください：
1. セキュリティ上の問題
2. パフォーマンスの問題
3. コードの可読性・保守性
4. エラーハンドリング
5. テストカバレッジ
6. コーディング規約への準拠

指摘事項は優先度（高/中/低）を付けて提示してください。

レビュー観点の標準化とプロンプトテンプレート

チームでDevinレビューを導入する際は、レビュー観点を標準化することが重要です。 私たちのチームでは、.github/devin-review-prompt.mdというファイルにレビュー観点をまとめています。

実際に使用しているレビュープロンプトの例を紹介します。

# PRレビュー観点

以下の観点に基づいて、プルリクエストのコードレビューを実施してください。

## 1. コード品質
- コードスタイル（ESLint、Prettier、Biome）への準拠
- 型安全性（TypeScriptの型定義）
- エラーハンドリング

## 2. アーキテクチャと設計
- SOLID原則への準拠
- コード構造とプロジェクト構造ガイドライン
- 再利用性とコードの重複

## 3. セキュリティ
- 入力検証
- 認証・認可
- データ保護

## 4. パフォーマンス
- 効率性（再レンダリング、データベースクエリ）
- リソース管理

## 5. テスト
- テストカバレッジ
- テスト品質

## 6. ドキュメント
- コードドキュメント
- 仕様書更新（database-design.md、api-specification.mdなど）

## 7. プロジェクト固有の要件
- ログ記録（OpenTelemetry形式）
- ブランチ・PR管理
- 依存関係

このプロンプトを標準化することで、チーム全体で一貫したレビューが可能になります。

実際のdevin-review-prompt.md

実際にチームで使用している.github/devin-review-prompt.mdの内容を紹介します。

# PRレビュー観点

以下の観点に基づいて、プルリクエストのコードレビューを実施してください。

## 1. コード品質

### 1.1 コードスタイル
- [ ] プロジェクトのコードスタイルガイドライン（ESLint、Prettier、Biome）に準拠しているか
- [ ] 一貫性のある命名規則が使用されているか
- [ ] 適切なインデントとフォーマットが適用されているか

### 1.2 型安全性
- [ ] TypeScriptの型定義が適切に使用されているか
- [ ] `any`型の使用が最小限に抑えられているか
- [ ] 型アサーション（`as`）が適切に使用されているか

### 1.3 エラーハンドリング
- [ ] 適切なエラーハンドリングが実装されているか
- [ ] エラーメッセージが明確で有用か
- [ ] 例外処理が適切に実装されているか

## 2. アーキテクチャと設計

### 2.1 設計原則
- [ ] SOLID原則に準拠しているか
- [ ] 関心の分離が適切に行われているか
- [ ] 依存関係の方向が適切か

### 2.2 コード構造
- [ ] プロジェクト構造ガイドラインに従っているか
- [ ] ファイルとディレクトリの配置が適切か
- [ ] モジュール間の依存関係が明確か

### 2.3 再利用性
- [ ] コードの重複が最小限に抑えられているか
- [ ] 共通機能が適切に抽象化されているか
- [ ] 再利用可能なコンポーネント/関数が適切に設計されているか

## 3. セキュリティ

### 3.1 入力検証
- [ ] ユーザー入力が適切に検証されているか
- [ ] SQLインジェクション、XSSなどの脆弱性対策が実装されているか
- [ ] ファイルアップロードの検証が適切か

### 3.2 認証・認可
- [ ] 認証・認可の実装が適切か
- [ ] 機密情報がハードコードされていないか
- [ ] 環境変数の使用が適切か

### 3.3 データ保護
- [ ] 機密データの取り扱いが適切か
- [ ] ログに機密情報が含まれていないか
- [ ] データベースクエリが適切にパラメータ化されているか

## 4. パフォーマンス

### 4.1 効率性
- [ ] 不要な再レンダリングや再計算が発生していないか
- [ ] データベースクエリが最適化されているか
- [ ] 適切なインデックスが使用されているか

### 4.2 リソース管理
- [ ] メモリリークの可能性がないか
- [ ] ファイルハンドルやデータベース接続が適切にクローズされているか
- [ ] 非同期処理が適切に実装されているか

## 5. テスト

### 5.1 テストカバレッジ
- [ ] 新規機能に対して適切なテストが追加されているか
- [ ] エッジケースがテストされているか
- [ ] 既存のテストが壊れていないか

### 5.2 テスト品質
- [ ] テストが明確で理解しやすいか
- [ ] テストが独立して実行可能か
- [ ] モックが適切に使用されているか

## 6. ドキュメント

### 6.1 コードドキュメント
- [ ] 複雑なロジックにコメントが追加されているか
- [ ] 関数やクラスの目的が明確か
- [ ] JSDocや型定義が適切に記述されているか

### 6.2 仕様書更新
- [ ] データベース変更時に`database-design.md`が更新されているか
- [ ] API変更時に`api-specification.md`と`business-logic-specification.md`が更新されているか
- [ ] インフラ変更時に`infrastructure-diagram.md`が更新されているか

## 7. プロジェクト固有の要件

### 7.1 ログ記録
- [ ] OpenTelemetry形式のロガーが使用されているか
- [ ] `console.log()`や`console.error()`が使用されていないか
- [ ] 適切なログレベルが使用されているか
- [ ] ログ属性（attributes）が適切に設定されているか

### 7.2 ブランチ・PR管理
- [ ] ブランチ名が命名規則に従っているか（`features/{チケット番号}[/作業名]`）
- [ ] PRタイトルが適切な接頭辞（`feat:`, `fix:`, `hotfix:`など）を使用しているか
- [ ] PRテンプレートに従って記載されているか

### 7.3 依存関係
- [ ] 不要な依存関係が追加されていないか
- [ ] 依存関係のバージョンが適切か
- [ ] `pnpm-lock.yaml`の変更が意図的か（通常は不要）

## レビュー時の注意事項

1. **建設的なフィードバック**: 問題点を指摘するだけでなく、改善案も提示してください
2. **優先度の明確化**: 重大な問題（セキュリティ、バグ）と軽微な改善点を区別してください
3. **コンテキストの考慮**: 変更の背景や目的を理解した上でレビューしてください
4. **コード例の提示**: 可能な限り、具体的なコード例を示してください

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

以下の形式でレビュー結果を出力してください：

```markdown
## レビュー結果

### 重大な問題（修正必須）
- [問題点1]: [説明と修正案]

### 改善提案（推奨）
- [改善点1]: [説明と提案]

### 良い点
- [良い点1]: [説明]
```

このファイルをリポジトリに含めておくことで、CI/CDからの読み込みやチームメンバー間での共有が容易になります。

CI/CDでの自動化

手動でDevinにレビューを依頼するだけでなく、GitHub Actionsを使って自動化しています。 プルリクエストが作成・更新されると、自動的にDevinがレビューを実施し、結果をPRにコメントとして投稿します。

GitHub Actionsのワークフローを簡略化すると、以下のような構成になっています。

name: Automated PR Review

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  review-pr:
    runs-on: ubuntu-22.04-4core
    if: |
      github.event.pull_request.head.repo.fork == false &&
      github.event.pull_request.draft == false
    concurrency:
      group: devin-pr-review-${{ github.event.pull_request.number }}
      cancel-in-progress: true
    steps:
      # 1. PRの変更ファイル一覧を取得
      - name: Get PR files
        run: gh api "/repos/.../pulls/${{ PR_NUMBER }}/files"

      # 2. レビュープロンプトを読み込み
      - name: Read review prompt
        run: cat .github/devin-review-prompt.md

      # 3. AGENTS.mdからプロンプトテンプレートを抽出
      - name: Read Devin PR prompt template from AGENTS.md
        run: sed -n '/DEVIN_PR_PROMPT_START/,/DEVIN_PR_PROMPT_END/p' AGENTS.md

      # 4. Devin APIでレビューセッションを作成
      - name: Create Devin Review Session
        run: |
          # テンプレートに変数を埋め込み、プロンプトを組み立てる
          # Devin APIを呼び出してセッションを作成
          curl -X POST \
            -H "Authorization: Bearer $DEVIN_API_KEY" \
            -d '{"prompt": "...組み立てたプロンプト..."}' \
            "https://api.devin.ai/v1/sessions"

主要なポイントは以下のとおりです。

• forkされたPRやdraft PRは除外し、不要なレビュー実行を防止
• concurrencyで同一PRへの重複実行を制御し、最新のpushのみをレビュー
• AGENTS.mdからプロンプトテンプレートを抽出し、PR情報を埋め込んでDevin APIに渡す
• Devinがレビュー結果をPRコメントとして直接投稿するため、開発者はPR作成と同時にレビューが開始される

AGENTS.mdとの連携

AGENTS.mdは、AIコーディングエージェント向けのREADMEとして機能するオープンなフォーマットです。DevinはAGENTS.mdを自動参照するため、プロジェクト固有のルールやコンテキストを記載しておくことで、より精度の高いレビューが可能になります。

AGENTS.mdの詳細については以下を参照してください。

• AGENTS.md 公式サイト: https://agents.md/
• AGENTS.mdとは？AIエージェント専用READMEの役割と使い方: https://zenn.dev/redamoon/articles/article27-agents

AGENTS.mdには以下のような情報を記載しています。

• セットアップコマンド
• コードスタイルガイドライン
• テストガイドライン
• プロジェクト構造
• 開発ワークフロー
• Devin向けの注意事項

実際のレビューフロー

1. プルリクエストを作成
   • GitHub Actionsが自動的にトリガーされる
2. Devinが自動的にレビューを開始
   • 変更されたファイルを確認
   • レビュープロンプトに基づいてチェック
   • AGENTS.mdのルールを参照
3. Devinの指摘を確認
   • PRにコメントとして投稿される
   • 優先度の高い指摘から対応
   • 誤検知や不要な指摘はフィードバック
4. 修正後に再レビュー
   • PRを更新すると自動的に再レビューが実行される

実際のレビュー画面

実際にDevinがPRにコメントしたレビュー結果のキャプチャです。

コードレビュー結果

Devinレビューの出力例

Devinレビューは、PRにコメントとして以下のような形式で出力されます。 プロンプトで指定した出力形式に従って、優先度別に整理された指摘が投稿されます。

## レビュー結果

### 重大な問題（修正必須）

- **セキュリティ**: SQLインジェクションのリスク
  - `src/api/users.ts:45`で、ユーザー入力が直接SQLクエリに含まれています
  - 修正案: パラメータ化クエリを使用してください
  ```typescript
  // 修正前
  const query = `SELECT * FROM users WHERE id = ${userId}`;
  
  // 修正後
  const query = 'SELECT * FROM users WHERE id = ?';
  await db.query(query, [userId]);
  ```

- **エラーハンドリング**: 例外処理が不足
  - `src/utils/validator.ts:23`で、エラーが適切にキャッチされていません
  - 修正案: try-catchブロックを追加し、適切なエラーメッセージを返してください

### 改善提案（推奨）

- **パフォーマンス**: 不要な再レンダリングの可能性
  - `src/components/UserList.tsx:12`で、useMemoを使用することで再レンダリングを最適化できます
  - 提案: 計算コストの高い処理をuseMemoでメモ化してください

- **コードスタイル**: 型定義の改善
  - `src/types/api.ts:8`で、`any`型が使用されています
  - 提案: 具体的な型定義を作成してください

### 良い点

- テストカバレッジが適切に追加されています
- エラーメッセージが明確で理解しやすいです
- コメントが適切に記述されており、コードの意図が明確です

このように、Devinレビューには以下の特徴があります。

• 優先度別に分類された指摘を提供
• 具体的なコード例を含む修正案を提示
• 良い点も指摘することで、開発者のモチベーション向上にも貢献

人間のレビュワーが確認しやすい形式で出力されるため、効率的にレビューを進められます。

Devinレビューのメリット

1. レビュー工数の削減と自動化

CI/CDで自動化することで、開発者はレビューを依頼する手間がなくなります。 Devinが自動的にコードをチェックしてくれるため、人間のレビュワーはより重要な部分（ビジネスロジックや設計判断など）に集中できます。 特に、コーディング規約やフォーマットなどの機械的なチェックは、Devinに任せることで効率化できます。

2. レビュー観点の標準化

プロンプトテンプレートを標準化することで、チーム全体で一貫したレビューが可能になります。 これにより、レビュワーによるばらつきを減らし、品質の標準化につながります。 また、プロジェクト固有の要件（ログ形式、ドキュメント更新など）もプロンプトに含めることで、漏れなくチェックできます。

3. 細かい指摘も見逃さない

人間のレビュワーが見落としがちな細かい問題も、Devinは確実に指摘してくれます。 セキュリティやパフォーマンスに関する潜在的な問題を早期に発見できます。 特に、プロジェクト固有のルール（OpenTelemetry形式のログ、特定のドキュメント更新など）も確実にチェックしてくれます。

4. 24時間いつでもレビュー可能

Devinは人間のレビュワーと違い、時間を問わずレビューを実施できます。 CI/CDで自動化することで、PR作成と同時にレビューが開始されます。退勤前にPRを出しておけば、翌朝にはレビューが完了しているという使い方も可能です。

5. レビュー結果の記録と改善

Devinのレビュー結果はPRにコメントとして残るため、過去のレビュー指摘を振り返ることができます。 また、誤検知のパターンを把握してプロンプトを改善することで、レビュー精度を継続的に向上させられます。

Devinレビューの課題と対策

課題1: コンテキストの理解不足

Devinがプロジェクトの全体像やビジネスロジックを十分に理解できていない場合、的外れな指摘をすることがあります。

対策: - AGENTS.mdやREADME.mdにプロジェクトの背景やルールを明記 - レビュー依頼時に必要なコンテキストを追加で提供 - Knowledge機能を活用してプロジェクト固有の情報を蓄積

課題2: 誤検知や不要な指摘

Devinの指摘内容が実際には問題ない場合や、プロジェクトの方針として許容されている場合があります。

対策: - 指摘内容を必ず人間が確認 - 誤検知のパターンをKnowledgeに記録 - プロジェクト固有のルールを明文化

課題3: レビュー観点の調整が必要

プロジェクトやチームによって、重視するレビュー観点が異なります。

対策: - レビュー観点をテンプレート化 - プロジェクトごとにカスタマイズ - チームでレビュー観点を定期的に見直し

レビューする文化の問題点

AIレビューを導入する以前に、そもそもレビュー文化自体に課題があります。

レビュワーごとの表現のばらつき

人によってレビューコメントの書き方や表現が異なります。同じ指摘でも、書き手の言い回しによって受け手の印象が変わり、不要なコミュニケーションコストが発生します。 AIによってレビューコメントのフォーマットを統一することで、指摘の意図が伝わりやすくなる効果が期待できます。

精度が低いと逆効果になる

AIレビューの精度が低い場合、開発者にとっては対応不要な指摘が増えるだけです。ノイズが多いと、次第にレビューコメント自体を読まなくなるリスクがあります。 プロンプトの調整やKnowledgeの蓄積で精度を上げていく運用が不可欠です。

スピード重視の局面では邪魔になる可能性

リリース直前やホットフィックスのような速度を優先したいタイミングでは、AIレビューが待ち時間を生む場合があります。 CI/CDのconcurrency設定や、特定ラベルでレビューをスキップする仕組みなど、運用面での調整が必要です。

使ってみた所感

反応速度について

導入初期はレビュー開始までの時間が遅い印象がありました。しかしDevinがプロジェクトを学習していくにつれ、レスポンスが改善されてきました。

promptとAgentsの設定による改善

レビュープロンプトの整備やAGENTS.mdでプロジェクト情報を事前に定義しておくことで、Devinが事前情報を読み込む速度が向上しています。ただし、初回のセッションではやはり時間がかかるという課題は残ります。

CI/CD自動化の実装ポイント

GitHub ActionsでDevinレビューを自動化する際のポイントをまとめます。

プロンプトの組み立て

AGENTS.mdに定義したテンプレートと、.github/devin-review-prompt.mdのレビュー観点を組み合わせてプロンプトを構築します。 テンプレート内のプレースホルダー（{{ github_token }}、{{ repository }}、{{ pr_number }}など）を実際の値に置き換えます。

セキュリティ考慮事項

• GitHub Tokenは環境変数として安全に扱う
• Devin API KeyはGitHub Secretsに保存
• プロンプトに含まれる機密情報を適切にエスケープ

エラーハンドリング

• Devin APIのエラーレスポンスを適切に処理
• セッション作成失敗時のリトライロジック
• タイムアウト設定（通常10分程度）

パフォーマンス最適化

• 並行実行の制御（concurrency設定）
• 不要な実行を避ける（draft PRやforkを除外）
• セッションのキャンセル処理

レビュー精度を上げるための取り組み

Devinレビューは導入して終わりではなく、運用しながら精度を上げていく必要があります。現時点ではまだ整備途中ですが、これから取り組んでいく方向性を紹介します。

プロンプトの継続的な調整

レビュー結果を振り返り、誤検知や的外れな指摘が出たパターンをプロンプトに反映していく予定です。「この観点は不要」「この書き方だと誤検知する」といったフィードバックを蓄積し、プロンプトテンプレートを定期的に見直すサイクルを作りたいと考えています。

Knowledge機能によるナレッジ化

DevinのKnowledge機能に、誤検知パターンやプロジェクト固有のルールを登録していく方針です。レビューで「これは問題ない」と判断した指摘をKnowledgeに記録しておくことで、同じ誤検知の繰り返しを防ぎたいと考えています。チームの暗黙知をDevinに伝える手段として活用していく見込みです。

CIワークフローの調整

レビューの実行タイミングや対象を絞ることで、不要なノイズを減らす必要があります。draft PRの除外、特定ラベルによるスキップ、concurrency設定による並行実行の制御など、CIの設定を細かくチューニングして開発フローに自然に組み込める状態を目指します。

レビュー結果の振り返り

定期的にDevinの指摘内容を振り返り、「役に立った指摘」と「対応不要だった指摘」を分類する運用を検討しています。この振り返りがプロンプト改善やKnowledge登録のインプットになり、改善サイクルが回る仕組みにしていきたいです。

まとめ

Devinを使ったコードレビューは、レビュー工数の削減やレビュー観点の標準化に効果的です。 一方で、Devinにもドメイン駆動設計のユビキタス言語やSkill設定を用意することで、ビジネス側の制約やドメインルールをある程度理解させられることは確認できています。

ただし、人間にしかできない領域は残ります。レビューの意思決定や、その判断理由の言語化、エンジニア以外のステークホルダーへの説明といった部分は、現時点のAIでは難しいです。設計判断の背景を伝えるコミュニケーションは、引き続き人間の役割として残り続ける印象を持っています。

また、「なぜこのレビューでOKとしたのか」「なぜ通さなかったのか」という意思決定の記録と説明も、人間が担うべき部分です。レビューの判断根拠をPRコメントやドキュメントに残すことで、チーム内の認識合わせやナレッジの蓄積につながります。

今回はDevinをコードレビューに活用する方法にフォーカスしましたが、私たちのチームではDevinを実装にも活用しています。なぜDevinに実装を任せるのか、どのように指示を出しているのかについては、次の記事で紹介できればと思います。

また、Devinには新機能として「Devin Review」が登場しています。Devin ReviewはWebアプリ上で提供される包括的なコードレビュープラットフォームで、スマートな差分整理やバグキャッチャー機能を備えています。現在私たちが利用しているAPI経由でのレビューとの比較検証も進めていく予定です。機能面やレスポンス速度の違いなど、検証結果がまとまり次第あらためて紹介します。

• Devin Review 公式ドキュメント: https://docs.devin.ai/ja/work-with-devin/devin-review

弥生では一緒に働く仲間を募集しています。
www.yayoi-kk.co.jp
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp