Claude Code の /ultrareview が 4/20 週にパブリックリサーチプレビュー、4/27 週には CI / スクリプト連携が GA に。複数のバグ狩りエージェントがクラウドで並列に走り、現在のブランチや指定 PR を多角的に検証する。バックエンドのコードレビュー負荷を実際に下げるか、業務で試した整理を残す。
/ultrareview とは:W17 リサーチプレビュー → W18 CI 連携
機能のリリース順を整理すると分かりやすい:
- **W16(4/13–17)**:Other wins セクションで初出。`/ultrareview` または `/ultrareview <PR#>` で使えるとアナウンス
- **W17(4/20–24)**:パブリックリサーチプレビューに昇格。複数の bug-hunting エージェントが**クラウドで並列**に走り、結果が CLI / Desktop に**自動で戻ってくる**
- **W18(4/27 – 5/1)**:`claude ultrareview` コマンドで **CI / スクリプトからも実行可能**に。これで「PR 立てる前に CI が ultrareview を走らせる」運用が可能になった
つまり、いま手元の CLI で `/ultrareview` と打ったとき、その裏では Claude Code on the web 上で複数のエージェントが立ち上がり、ブランチを丸ごと検証している。ローカルの CPU は使わない。
最短の使い方
ブランチをローカルで切って、コミットしたあと:
> /ultrareviewこれで現在のブランチが対象。GitHub PR 番号を指定するなら:
> /ultrareview 1234W17 公式ドキュメントが推奨する使いどころは「**マージ前のクリティカルな変更、特に認証やデータマイグレーション**」。バックエンド業務でいうと、まさにここが一番手厚いレビューが欲しい領域。
/ultrareview と Code Review の違い
Code w/ Claude 2026 では Code Review 機能も同時に GA された。両者の違いは:
- **Code Review**: 単一エージェントが PR の差分を順に見るタイプ。継続的・軽量・全 PR にかけてもコスト負担が小さい
- **/ultrareview**: 複数エージェントが**並列に**、しかも**敵対的批評(adversarial critique)**のパスを持って走る。重い変更や複雑なロジック向け
実務的には「**全 PR に Code Review、マージ直前に /ultrareview**」の二段構えがハマる。Code Review で日常の凡ミスを潰し、ultrareview でリスク変更に集中投資する。
バックエンド業務で効くシーン
実際に効いたシーンを 3 つ:
- **マイグレーションの不可逆性チェック**: ALTER TABLE / DROP COLUMN を含む PR で、ロールバック計画の妥当性まで指摘してきた
- **トランザクション境界の見落とし**: 複数の DB 更新を 1 関数で扱っているのに、トランザクションで囲っていない箇所を発見
- **N+1 と RPC の冗長**: ループ内で SELECT を発行しているコードを、JOIN ベースに書き換える提案
逆に効きにくかったシーン:
- 純粋なリファクタ PR(変更が機能的中立だと、批評の手がかりが薄い)
- 大量の自動生成ファイル(CSS-in-JS のスナップショット等)が混ざる PR
リサーチプレビューの段階なので、出力は「**ロー(Raw)な批評の集合**」で来ることが多い。これを人間が**取捨選択する責任**は当然ある。すべての指摘に対応しようとすると消耗する。
CI / スクリプト統合(W18)
W18 で **`claude ultrareview` が CI から呼べる**ようになった。実装イメージ:
# .github/workflows/pre-merge.yml
on:
pull_request:
types: [ready_for_review]
jobs:
ultrareview:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: claude ultrareview --from-pr "${{ github.event.pull_request.html_url }}"無料でアカウント作成
CCHub は Claude Code 開発者のための日本語コミュニティです。