Claude Code のコードレビューを ultra と max で使い分ける — 実例と判断基準

Claude Code には、PR のコードレビューを行う /code-review という機能があります。手元で複数のレビューエージェントを並列に走らせる max エフォートと、クラウド上の独立した環境でレビューを実行する ultra の2つの方式を選べます。私たちは1つの PR に両方をかけて比較する運用を試しているのですが、先日リスクの高いロジックに両者を当てたところ、片方が見つけたバグの数がもう片方を大きく上回りました。ただ、その数字を額面どおりに受け取ると判断を誤ります。この記事では、ultra と max をどう使い分けるべきかを、実例とともに整理します。

ultra と max は何が違うのか

要点は「コンテキストを使えるか」と「独立しているか」が、ちょうど裏返しの関係になっていることです。今回のように コードを書いたのもコーディングエージェントなら、max のレビューを回すのも同じエージェントです。max はコードを書いたときのコンテキストを引き継ぐため、危険箇所を狙い撃ちできて検出効率が上がる一方、コードを書いたエージェントと同じ思い込みを共有し、検証の段階で本物のバグを「これは意図的」と片付けてしまうリスクを抱えます。ultra のように独立したレビューはその逆で、狙いを絞れない代わりに、コードを書いたエージェント由来のバイアスがかからない目を提供します。

実例：1つのバグと、不完全な修正

レビューにかけたのは、イベントを時系列に1ステップずつ評価していく状態遷移ロジックです。ある条件に到達したかを順番に判定していく、と考えてください。

最初に ultra を回したところ、指摘は1件でした。「最初のステップで条件Aは判定しているのに、条件Bを判定していない」というものです。同じステップ内で条件Bを満たしても、それが記録されず次のステップに持ち越されてしまい、本来とは別の結果に化ける——出力を不当に歪めるバグでした。

私たちはこれを修正しました。ところが、この修正が不完全だったのです。最初のステップにだけガードを足し、「入力が条件Bを飛び越えてしまった場合」の退化ケースを後続ステップの判定に残してしまいました。結果として、誤った結果が「正しい結果」として記録される経路が、別の場所に生き残っていました。

次に max を回すと、この残存バグを含む複数の指摘が返ってきました。最重要だったのは、まさに自分たちの不完全な修正が生んだ残存ケースでした。実データで検証すると、ある条件下では誤って記録されていた退化ケースが正しく除外されることも確認できました。

なぜ件数だけで測れないのか

max が「多く見つけた」のは事実です。しかしこれを「max の方が優秀」と結論づけるのは早計で、いくつもの交絡があります。

• 実行順序：ultra を先に、max を後に回しました。両者は同じコードを見ていません。
• 最大の発見は自分たちが作り込んだもの：max の最重要指摘は、ultra の指摘に対する私たちの不完全な修正が生んだ残存バグでした。ultra はそのコードを一度も見ていません。最初から完全に直していれば、この指摘はそもそも存在しなかったのです。
• コンテキストと物量：max には「この周辺を重点的に見て」と指示を出せました。さらに多数のエージェントを並列で走らせています。多く見つかったのは、検出力そのものというより「狙いを絞れた」ことと「物量」の合算です。

つまり「複数 対 1」のような件数差は、実バグの密度差を誇張しています。ultra が当てた1件は、後続のすべての発見につながる「根」のバグでした。件数ではなく役割で見るべきです。

独立性という、件数に表れない価値

ultra の価値は検出件数では測れません。今回まさに、ultra が根のバグを当て、それが私たちの不完全な修正の発見につながりました。これは「コードを書いたエージェントが見落とし、同じコンテキストで狙いを絞った max でも一次パスでは掴みきれなかった核を、独立した ultra が拾った」という構図です。

検証の段階で「これは意図的だから問題ない」と本物のバグを見逃す失敗は、めったに起きませんが、起きると高くつきます（誤って許容したバグが本番に出る）。ultra のような独立したレビューは、その種のテールリスクに対する保険として働きます。

コストをどう織り込むか

max は追加課金がなく、ultra は従量課金です。1バグあたりの限界コストでは max が圧倒的に有利で、「コンテキストを活かせる運用なら、日常のレビューは max で回すのが合理的」という結論を後押しします。

ただし2点、コスト比較に入れ忘れがちな要素があります。

1. max も「無料」ではない：追加課金はゼロでも、計算資源・レート上限・レビュアーの作業時間を消費し、ローカルのセッションを占有します。今回の max は多数のエージェントを回し、人間によるオーケストレーションに強く依存しました。
2. ultra の価値はテールリスク保険：平常時の検出件数では測れない、コードを書いたエージェント由来のバイアス対策としての価値があります。

結論：ultra と max の使い分け指針

私たちが今回得た結論はこうです。

• 日常のデフォルトは max。コンテキストを活かせる状況では、検出の広さもコスト効率も優れています。
• ultra は、最高リスクの変更の「最終ゲート」に限定。1件の見逃しが高くつくコードに、独立した目を一度だけ入れる。あるいは、コンテキストを持つレビュアーが同席できない場面で。

そして、この一件から得た最大の教訓は、レビューツールの優劣そのものではありませんでした。指摘への修正は、最初から完全に当てることです。私たちは退化ケースの存在を認識しながら、最初のステップだけを直しました。もし最初から両方の経路を直していれば、後続の指摘は減り、二重の手戻りも避けられました。AI のレビューがどれだけ賢くても、修正の詰めの甘さは別の問題として残ります。

最後に、これらはすべて PR 1本での観察にすぎません。順序・コンテキスト・コードの成熟度といった交絡がある以上、一般化はできません。私たちは ultra の無料枠を使いながら、「ultra だけが拾った」「許容判断を覆した」事例がどれくらいの頻度で出るかを見て、課金してでも回す価値があるラインを見極めていく予定です。AI を開発プロセスにどう組み込むかは、こうした地道な実測の積み重ねで決まっていくものだと考えています。