AIアシストコードレビュー：8人チームの導入実践

フロントエンドプラットフォーム責任者として、昨年から AI を Code Review プロセスに導入する試みを始めました。数ヶ月の実践を経て、私たちの経験と陥った落とし穴を整理します。

AIアシストが必要な理由

私たち8人チームは毎週約40〜50のPRを処理しており、手動レビューがしばしばボトルネックになっていました：

シニアエンジニアの時間が限られており、レビューが滞留しがち
単純な問題（命名、フォーマット、n+1クエリ）がレビュー時間の60％以上を占める
新人のコード品質のばらつきが大きく、より多くの注意が必要

目標は、AI に60％の機械的なチェックを処理させ、人間はアーキテクチャと設計に集中することです。

私たちのアプローチ

第一層：Biome + 型チェック（ゼロレイテンシ）

json

// biome.json コア設定
{
  "linter": {
    "rules": {
      "recommended": true,
      "correctness": {
        "noUnusedVariables": "error",
        "useExhaustiveDependencies": "error"
      },
      "suspicious": {
        "noExplicitAny": "error"
      },
      "complexity": {
        "noExcessiveCognitiveComplexity": ["error", { "max": 15 }]
      }
    }
  }
}

第二層：AI Review Bot（PR レベル）

GitHub Actions + Claude API を使用して自動レビューを行います：

yaml

# .github/workflows/ai-review.yml
name: AI Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: AI Review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          # diff を取得
          DIFF=$(gh pr diff ${{ github.event.pull_request.number }})

          # Claude API を呼び出し
          node scripts/ai-review.mjs "$DIFF"

プロンプトの核心設計：

typescript

// scripts/ai-review.mjs
const SYSTEM_PROMPT = `你是一个资深前端 Code Reviewer。请审查以下代码变更：

重点关注：
1. 潜在的运行时错误
2. 性能问题（不必要的重渲染、大列表无虚拟化）
3. 安全问题（XSS、注入、敏感信息泄露）
4. API 设计一致性
5. React/Vue 最佳实践

格式：
- 🔴 严重：必须修复
- 🟡 建议：最好修复
- 🟢 肯定：写得好的地方

不要检查：代码格式、变量命名风格（由 Biome 处理）`;

第三層：手動レビュー（AI は参考としてのみ）

AI の出力は PR コメントの最初のエントリとして表示され、人間のレビュアーは参考にできますが、盲従する必要はありません。

重要な知見

うまくいったこと

プロンプトは具体的に。初期は曖昧なプロンプトを使っていたため、AI は「コードは良さそうです」といった意味のない出力をすることがよくありました。チェック項目を明確に指定した後、有効な提案の割合が20％から65％に向上しました。

関心事の分離。フォーマットチェックとリントは Biome に任せ、AI はロジックとアーキテクチャに集中させます。AI にツールがより得意とすることをさせないようにします。

コンテキストの制限。ファイル全体ではなく、diff のみを送信します。トークンを節約し、AI を変更点に集中させます。

陥った落とし穴

初期の誤検出率が高かった。AI は妥当なコードを問題として報告することがありました。2週間かけてプロンプトを反復改善し、プロジェクトのコンテキスト（Vue 3 コンポジション API、TypeScript strict モードを使用）を AI に伝えることに重点を置きました。

トークン消費の管理が必要。大きな PR の diff は非常に大きくなる可能性があります。500行の制限を設け、それを超える場合は PR の分割を推奨しています。

アーキテクチャ議論の代替にはならない。AI はビジネスコンテキストを理解しないため、アーキテクチャレベルの決定は手動レビューが必要です。

効果データ

3ヶ月の実践を経て：

PR レビューの平均待機時間が 4.2 時間から 1.8 時間に短縮
マージ前に発見される問題の数が 35％増加（AI 発見 + 人間発見）
本番環境のバグ率が約 20％低下
シニアエンジニアのレビュー時間が 40％削減

まとめ

AI Code Review は機械的なチェックの処理に適しており、アーキテクチャの決定には適していません
プロンプトエンジニアリングが鍵であり、チームの技術スタックに合わせてカスタマイズする必要があります
階層化戦略（lint → AI → 人間）が最も効果的です
AI が人間を置き換えると期待するのではなく、AI に低価値な作業を処理させ、人間の労力を解放します
プロンプトを継続的に反復改善し、実際の誤検出率に基づいて調整します

AIアシストコードレビュー：8人チームの導入実践

AIアシストが必要な理由 ​

私たちのアプローチ ​

第一層：Biome + 型チェック（ゼロレイテンシ） ​

第二層：AI Review Bot（PR レベル） ​

第三層：手動レビュー（AI は参考としてのみ） ​

重要な知見 ​

うまくいったこと ​

陥った落とし穴 ​

効果データ ​

まとめ ​