画像生成AIアプリ「ComfyUI」の開発チームが、OpenAI・Anthropic・Google・Moonshotの4モデルを並列で走らせてプルリクエスト（PR）をレビューする仕組み「Cursor Review」を公式ブログで公開しました。4つのモデルがそれぞれ別の観点から同一PRをチェックし、最後に1つの判定モデルが各レビュー結果を統合・整理してGitHub上にコメントとして投稿する、という構成です。競合関係にある4社のモデルを意図的に組み合わせた設計が注目されています。
「どのAIが一番コードレビューに使えるか」という問いに対して、ComfyUIチームが出した答えは「全部使う」でした。これはシンプルに見えて、だいぶ示唆に富んだ設計思想です。
各モデルに「別の観点」を割り当てて並列実行し、最後に判定モデルが集約する構成は、アンサンブル学習の発想をコードレビューに応用したものと言えます。単一モデルに頼ると、そのモデルが苦手とする観点（セキュリティ・パフォーマンス・可読性など）がそのままレビューの抜け漏れになりますが、複数モデルで手分けすれば理論上はカバレッジが上がります。コードレビューという「正解が一義的ではないタスク」との相性は悪くないはずです。
もう一点、運用コスト面での判断材料を整理しておくと、4モデルを毎回フルで走らせる構成は、PRの数やコードの規模によってはAPI費用が無視できない水準になり得ます。元記事ではコスト試算の具体的な数値は示されていないため、この仕組みをそのまま大規模リポジトリへ適用しようとする場合は、費用感を別途検証する必要があります。ComfyUI自体が比較的小規模・特定用途のコードベースであることを前提に設計された可能性もあるため、「そのままスケールする」と読むのは早計です。
判定モデルが「結果を整理してGitHubに投稿する」という最終段も興味深いポイントです。4モデルの意見が割れたとき、どのモデルの指摘を採用するか、あるいは全件羅列するのかという調停ロジックが、実際の運用品質を左右します。この部分の詳細は元記事の範囲では明らかになっていませんが、判定モデルの選定と調停ルールの設計が実質的な肝になると考えられます。
【編集部補足】
OpenAI・Anthropic・Google・Moonshotという競合4社のモデルを明示的に並べる選定は、特定ベンダーへの依存（ベンダーロックイン）を避ける意図があるとも読めます。「どれかが性能で劣ってもシステム全体は崩れない」という冗長性の確保という観点は、業界では近年よく語られる設計方針のひとつです。ただしこれはあくまで編集部の見立てであり、公式ブログがそのような意図を明示しているかどうかは元記事の範囲では確認できていません。
関連サービス（広告）
AIの挙動を実際に試してみたい方は、ブラウザだけで本格的なAI画像生成ができる ConoHa AI Canvas
で、出力傾向を自分の手で確かめてみるのも面白い切り口です。
