メインコンテンツへスキップ
ブログ一覧

Claude Code /ultrareview 実践ガイド — マルチエージェントレビューで本番バグを事前に潰す

Claude Codeコードレビュー自動化マルチエージェントCI/CD開発効率化

「レビュアーが自分しかいない」「PRが大きすぎて見落としが怖い」——そんな課題を、クラウド上で複数のAIエージェントが並列レビューする /ultrareview が解決する。2026年4月、Claude Code v2.1.86とともにリサーチプレビューとして登場したこの機能は、従来の /review とは根本的に異なるアーキテクチャで動く。本記事では、内部アーキテクチャからCI/CD組み込みまでを実践的に解説する。

/ultrareview とは何か — /review・Managed Code Review との違い

3層レビュー体系の全体像

Claude Codeのコードレビューは現在、目的とコストが異なる3つの層で構成されている。

/review /ultrareview Managed Code Review
実行場所 ローカル クラウドサンドボックス Anthropicインフラ(GitHub App)
エージェント数 単一パス 複数エージェント並列 複数エージェント並列
所要時間 数秒〜数分 5〜10分 平均20分
コスト サブスク内無料 $5〜$20/回 $15〜$25+/回
最適な用途 開発中の高速フィードバック マージ前の高リスク変更 全PRの自動レビュー(Team/Enterprise)
導入方法 CLIで /review CLIで /ultrareview GitHub App連携

/review はサブスクリプション内の通常利用としてカウントされるため追加コストが発生しない。一方 /ultrareview はextra usage課金で、Pro/Maxプランでは3回のみ無料(ワンタイム、補充なし)。Team/Enterpriseプランには無料枠がない。

利用制限として、Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry、およびZero Data Retention(ZDR)が有効な組織では /ultrareview を利用できない。 APIキーのみでサインインしている場合は、事前に /login でClaude.aiアカウントを認証する必要がある。

内部アーキテクチャ解剖 — Find + Verify 二段階パイプライン

/ultrareview の核心は「バグを見つけること」と「バグを確認すること」を明確に分離した二段階アーキテクチャにある。

Find phase: 感度重視の並列スキャン

Find phaseでは、複数のレビューエージェントがクラウドサンドボックス上で並列に起動する。各エージェントは異なるクラスの問題——ロジックバグ、セキュリティ脆弱性、境界条件、API誤用、パフォーマンス問題——を担当し、感度を高めに設定して漏れを防ぐ。Opus級のサブエージェントがバグやロジック問題を、Sonnet級のエージェントがスタイルやCLAUDE.md違反をそれぞれ担当するという階層構造になっている。

Verify phase: 独立再現検証と偽陽性フィルタリング

Find phaseの結果は、別のエージェント群によるVerify phaseに渡される。ここでは各findingが実際のコードに対して独立に再現検証される。再現できないfindingは偽陽性として除去され、信頼度スコアが高いもののみが最終報告に残る。

正直、最初にこのアーキテクチャを知ったときは「二重にエージェントを走らせるのはコスト的に無駄では」と思ったが、実際に使ってみると偽陽性がほぼゼロで、報告される問題のほぼ全てが対処すべきものだった。

mermaid
graph TD
    A["/ultrareview 実行"] --> B["リポジトリをクラウドサンドボックスにアップロード"]
    B --> C["Find Phase"]
    C --> D["Agent 1: ロジックバグ検出"]
    C --> E["Agent 2: セキュリティ脆弱性"]
    C --> F["Agent 3: 境界条件・エッジケース"]
    C --> G["Agent N: パフォーマンス・API誤用"]
    D --> H["Verify Phase"]
    E --> H
    F --> H
    G --> H
    H --> I["独立再現検証"]
    I --> J{"再現できたか?"}
    J -- Yes --> K["最終レポートに含める"]
    J -- No --> L["偽陽性として除去"]
    K --> M["検証済みfindingsをセッションに通知"]

信頼度スコアリングと報告閾値

Verify phaseを通過した各findingにはファイル位置と問題の説明が付与される。レビュー結果はセッションの通知として表示され、そのままClaudeに修正を依頼できる。

使い分け判断フロー — いつ /review で十分で、いつ /ultrareview を使うか

PR規模別コスト対効果マトリクス

PR規模 変更内容 推奨 理由
〜50行 UI調整、文言変更 /review 無料・即時。単一パスで十分
50〜100行 軽微なバグ修正 /review コスト対効果が合わない
100〜500行 UI/フロントエンド /review 視覚的な確認が主で、ロジックバグは少ない
100〜500行 DB migration・認証・決済 /ultrareview クロスファイル依存やエッジケースの見落としリスクが高い
500行超 大規模リファクタ /ultrareview 人間が見落とすクロスファイル依存を並列検出

なお、ネット上で「70行のPRに$31かかった」という報告を見かけるが、これはManaged Code Review(GitHub App版、$15〜$25+/回)の話であり、/ultrareview は$5〜$20とそれより安い。混同しないように注意が必要だ。

判断フローチャート

  1. 変更が決済・認証・DB migrationに関わるか? → Yes なら /ultrareview
  2. PRが500行を超えるか? → Yes なら /ultrareview
  3. レビュアーが自分だけか? → Yes かつ100行超なら /ultrareview を検討
  4. 上記すべてNo/review で十分

無料枠の3回は補充されないため、最初の3回はpayments・migration・認証変更など最もリスクの高いPRに集中投下するのが賢い戦略だ。

高リスク変更での実戦パターン

実行方法

ローカルブランチをそのままレビューする場合:

bash
# 現在のブランチとデフォルトブランチのdiffをレビュー
/ultrareview

GitHub PRとしてレビューする場合(リポジトリが大きい場合に推奨):

bash
# ブランチをpushしてPRを作成後
git push -u origin feature/payment-refactor
gh pr create --draft
/ultrareview 1234

PR番号を指定すると、ローカルのワーキングツリーをバンドルする代わりに、リモートサンドボックスがGitHubから直接PRをクローンする。リポジトリが大きすぎてバンドルできない場合は、このPRモードを使う。

payments・課金ロジックのレビュー

決済系の変更は、二重課金・冪等性の欠如・エラーハンドリングの抜けが本番障害に直結する。/ultrareview は複数エージェントがこれらを並列で検証するため、単一パスでは見落としがちなエッジケースを捕捉できる。

認証・認可変更のレビュー

権限昇格、トークン漏洩、セッション管理の不備は、セキュリティ専門のエージェントが重点的にチェックする。認証フローの変更は影響範囲が広いため、/ultrareview のクロスファイル分析が特に有効だ。

DB migration のレビュー

データ損失、ロールバック不能、長時間ロックによるダウンタイムといったリスクを、Verify phaseで実際のスキーマ変更を追跡しながら検証する。

REVIEW.mdによるスコープカスタマイズ

Managed Code Review(GitHub App版)では、リポジトリルートに REVIEW.md を配置することでレビュー方針を詳細に制御できる。/ultrareview はCLAUDE.mdを読み取ってプロジェクトのコンテキストを把握するため、高リスク領域の指針をCLAUDE.mdに記述しておくことで精度を高められる。

markdown
<!-- REVIEW.md の例(Managed Code Review向け、/ultrareviewではCLAUDE.mdに類似の指針を記述) -->

# Review instructions

## What Important means here

Reserve Important for findings that would break behavior, leak data,
or block a rollback: incorrect logic, unscoped database queries, PII
in logs or error messages, and migrations that aren't backward
compatible. Style, naming, and refactoring suggestions are Nit at
most.

## Always check

- Stripe webhook の冪等性キーが全エンドポイントで使用されていること
- DB migration に対応する rollback migration が存在すること
- 認証ミドルウェアの変更が全保護ルートに適用されていること
- Log lines don't include email addresses, user IDs, or request bodies

## Do not report

- Generated files under `src/gen/` and any `*.lock` file
- Test-only code that intentionally violates production rules

CI/CDパイプラインへの組み込み

GitHub Actions での自動実行

高リスクPRにのみ /ultrareview を自動実行するワークフロー例:

yaml
# .github/workflows/ultrareview.yml
name: Ultrareview on high-risk PRs

on:
  pull_request:
    types: [labeled]

jobs:
  ultrareview:
    if: github.event.label.name == 'needs-ultrareview'
    runs-on: ubuntu-latest
    timeout-minutes: 30
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install Claude Code
        run: npm install -g @anthropic-ai/claude-code

      - name: Run ultrareview
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          claude -p "Run /ultrareview ${{ github.event.pull_request.number }} and report findings" \
            --output-format json > review-results.json

      - name: Post results to PR
        if: always()
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const results = fs.readFileSync('review-results.json', 'utf8');
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: ${{ github.event.pull_request.number }},
              body: `## Ultrareview Results\n\n${results}`
            });

自律開発デーモン(slave)への組み込み例

自律開発パイプラインにultrareviewステージを追加し、デプロイ前に高リスク変更を自動検証する設計例:

typescript
// src/pipelines/autonomous-dev.ts に追加するステージ例
import { runClaude } from '../claude-runner.js';
import { notify } from '../notifier.js';

interface UltrareviewResult {
  findings: Array<{ file: string; line: number; issue: string }>;
  hasCritical: boolean;
}

async function ultrareviewStage(
  projectSlug: string,
  prNumber: number
): Promise<UltrareviewResult> {
  const projectDir = `${process.env.HOME}/Repo/${projectSlug}`;

  // PR の変更行数を取得してコスト判定
  const diffStat = await runClaude(
    `Run "git diff --stat main" in ${projectDir} and return the total lines changed as a number only.`,
    { cwd: projectDir }
  );

  const linesChanged = parseInt(diffStat.trim(), 10);

  // 100行未満の変更は /review で十分
  if (linesChanged < 100) {
    const reviewResult = await runClaude(
      `Run /review in ${projectDir} and summarize findings as JSON.`,
      { cwd: projectDir }
    );
    return { findings: JSON.parse(reviewResult), hasCritical: false };
  }

  // 100行以上の変更に /ultrareview を実行
  const result = await runClaude(
    `Run /ultrareview ${prNumber} and wait for completion. Return findings as JSON array with {file, line, issue} objects.`,
    { cwd: projectDir, timeout: 30 * 60 * 1000 } // 30分タイムアウト
  );

  const findings = JSON.parse(result);
  const hasCritical = findings.some(
    (f: { issue: string }) =>
      f.issue.toLowerCase().includes('security') ||
      f.issue.toLowerCase().includes('data loss')
  );

  if (hasCritical) {
    await notify(
      `*[${projectSlug}]* ultrareview で重大な問題を検出。デプロイを中断します。\n` +
      findings.map((f: { file: string; line: number; issue: string }) =>
        `• ${f.file}:${f.line} — ${f.issue}`
      ).join('\n')
    );
  }

  return { findings, hasCritical };
}

この設計では、PR規模に応じて /review/ultrareview を自動で切り替え、重大な問題が検出された場合はデプロイを中断してSlack通知を送る。地味だが、深夜の自動デプロイで本番障害を防ぐ安全ネットとして機能する。

ハマりポイントと対処法

よくあるエラーと回避策

タイムアウト: レビューは通常5〜10分で完了するが、巨大なPRでは時間がかかる場合がある。リポジトリが大きすぎてバンドルできない場合は、ブランチをpushしてPRモード(/ultrareview <PR番号>)を使う。

ZDR組織での利用不可: Zero Data Retention が有効な組織では /ultrareview を利用できない。CI/CDパイプラインではフォールバックとして /review を実行するように設計しておくとよい。

認証エラー: APIキーのみでサインインしている場合、/ultrareview は動作しない。事前に /login でClaude.aiアカウントを認証しておく。

コスト管理のTips

  • 無料枠3回は高リスクPRに集中: 補充されないため、payments・migration・auth変更に使う
  • extra usageの有効化が必須: 無料枠を使い切った後は、アカウントまたは組織でextra usageを有効にしておかないと起動がブロックされる。/extra-usage で現在の設定を確認できる
  • 確認ダイアログを活用: 起動前にレビュースコープ・残り無料回数・推定コストが表示されるため、想定外のコストを防げる
  • /tasks で進行状況を管理: 実行中のレビューの確認や停止が可能。不要なレビューを早期に停止すればコストを抑えられる

まとめ

/ultrareview は「人間レビュアーの代替」ではなく「高リスク変更に対する安全ネット」として位置づけるのが最適解だ。/review で日常のPRを高速に回しつつ、決済・認証・migrationといった本番障害に直結する変更にだけ /ultrareview を投入する——この使い分けが、コストと品質のバランスを最大化する。

Pro/Maxユーザーならまず無料の3回で自分のプロジェクトの高リスクPRに試し、ROIを実感してから本格導入を判断してほしい。


参考リンク

もっと読む他の技術記事も読む