見落としがちな観点を拾うためにAIレビューを進化させた話

12月4日から5日にかけて、スペースマーケットでは開発合宿が開催されました。
今回のテーマは「開発プロセスにおけるAI活用」で、EPICリファインメント / PBIリファインメント / テスト / コードレビューなど各工程における効率化・生産性の向上を目指す2日間でした。

開発合宿全体の様子は別途ブログで公開予定ですが、この記事では私を含む4名で担当したコードレビューチームの成果を紹介します。

私たちが目指したのは、以下の3つの進化です⚡️

• 体験の進化: AIによるサポートでレビューの心理的ハードルを下げ、全エンジニアが参加できる文化を作る
• 品質の進化: 保守しやすいコードを長期で安定して提供し続ける
• 速度の進化: 一部のレビュアーに集中することによるボトルネックを解消し、デプロイサイクルと価値提供を加速させる

🔍 コードレビューの課題

まずは、チームで抱えていた課題の整理をブレストするところから始めました。

その結果、おおまかに以下の3つの課題があるよねという話になりました。

1. 観点不足

大きな課題は、レビューの観点が不足していることでした。

コードレビューで見るべきポイントは多岐にわたります。

• パフォーマンス
• 設計思想に基づくクラス構成
• 命名の良さ
• セキュリティ
• テストの網羅性

でも、人間だけでこれらすべてを網羅的にチェックするのは難しい上に時間がかかります。
特に、自分の専門外の領域では見落としがちです。
そのため、一部のエンジニア（シニアやリードクラス）にレビューが集中してしまう傾向がありました。

2. 心理的ハードル

コードレビューは心理的なハードルの一面も持っています。

• 詳しくない分野、コンテキスト不足（例えば隣のチーム）のコードをレビューするとき
• 「これ本当に指摘していいのかな...」と迷うとき

ちょっと自信ないな・・と思って自分で調べたり検証した結果をコメントで残したこともみなさんあるんじゃないでしょうか。
（かくいう私もそうです。コメントするからには誤ったこと書けないという暗黙のプレッシャーがありますよね）

そのため、レビュアーが気軽に意見を出せる環境づくりも重要になってきます。

3. 既存のAIレビューにおける課題

実は、すでにAIレビュー(GPT-5-Codex)を会社で導入していましたが、物足りなさも感じていました。

• 観点の偏り: アーキテクチャの設計方針やパフォーマンスなど観点が不足しがち
• 品質のばらつき: レビューフローが統一されず、リポジトリごとに品質がばらつく
• 改善サイクルの欠如: 人間レビューで得られた知見がAI学習に還元されておらず、改善サイクルが回っていない

結果として、AIレビューが十分に活用されていない状況でした。

🚀 方針と実装

ブレストの結果、以下の方針で進めることにしました。

1. AIモデルの刷新: 同じPRに対して、Codex（GPT-5-Codex）と Claude Opus 4.5 および Claude Sonnet 4.5 のレビューコマンドで比較をしたところ、明らかに Claude Opus 4.5 の方が優れていることが分かり、こちらをベースにレビューを実行する仕組みを構築することに。大きな理由としては、「この仕様で大丈夫？」という観点での指摘が入るのが大きなメリットです。
2. プロンプトのカスタマイズ: Claude /reviewコマンドそのままでは痒いところに手が届かず、以下の課題も含めてプロンプトをカスタマイズすることに。
   • 変更された差分のみがレビュー対象になり、全体で見たときの整合性が合わないといった問題
   • 重要な指摘が軽微な扱いになるなど、優先度の判断にばらつきがある
   • 問題点の指摘はあるが、改善案の説明が不足していて意図が伝わりにくい
   • 人間レビュー者に対して「どこに注目すべきか」のアドバイスが不十分
3. 継続的改善の仕組み: 人間のレビューで得た知見を次回のAIレビューに活かすサイクルを構築（kemezz さんの記事をお楽しみに！）

実装は GitHub Actions で行い、 @claude メンション時に実行する仕組みとしました。

✨ 成果

現在、以下のプロジェクトで運用が始まっています。

• TypeScript（バックエンド） × 1
• TypeScript（フロントエンド） × 2
• Rails × 2

プロンプトはこちらにありますので、活用いただければ幸いです。
Claude のレビューコマンドをベースとし、上記に挙げた改善点を加えたものになっています。
https://gist.github.com/8zca/f470c04ee59a0789b728dc25fc181e1a

スペースマーケットでは上記をベースに、リポジトリごとの特性によって追加の指摘を加えたプロンプトを組み立てています。

改善後のAIレビューでは、以下のような成果が出ています。

問題検出までの時間短縮 / 見落としの減少

• 冪等性チェック、信頼性問題
• DBトランザクション内で外部とのAPI通信が実行される問題
• マルチDBトランザクションの一貫性問題
• テストの網羅性
• ドメイン境界の提案

これらの重要な指摘を、人間のレビュー前にAIが早期検出してくれるようになりました。

人が見る部分を明確化

AIレビューでは「不明点・確認事項」と「人間が重点的にレビューすべき箇所」を分けて提示します。

これにより、人間は本当に重要な部分（ビジネス要件の整合性、設計判断の妥当性など）に集中できるようになり、レビューコスト削減が期待できます。

また、ドメイン境界の考慮や責務についてのレビューが捗るようになり、レビューチームの中では「これが欲しかったやつ！」と感動の渦に包まれていました（笑）。

この施策によって期待できる効果は以下の通りです。

• ビジネス要件 / 設計 / パフォーマンス / セキュリティ / テスト観点などの重要論点を網羅的にチェックでき、人間では見落としがちな問題を早期に検出可能
• 軽微な指摘（nits）が大幅に減り、人間は重要な設計・仕様判断に集中できる。差し戻しが減ることでレビューサイクル全体の効率が向上
• スペースマーケットでは月約200回のレビューが発生しており、1回あたり10分短縮されれば約0.2人月分のコスト削減を見込める

🤝 一緒に取り組んだメンバー

最後に、今回のレビューチームのメンバーを紹介します。

• kemezz さん（Claudeの申し子）: Claude活用のエキスパートで、今回の実装でも中心的な役割を果たしてくれました
• lei さん（切り込み隊長）: エンジニア内で一番ユーザーの声を聞きに行く切り込み隊長。今回のプロンプトを組み上げていただきました
• dumbled0re さん（AI推進を進める若きエース）: みんなの四男で、AI推進を進める若きエース。実装面で大活躍してくれました

このメンバーで取り組めたからこそ、2日間という短期間で実装 + 実リポジトリへの展開まで到達できたと思います。

✅ まとめ

開発合宿でのAIレビュー改善の取り組みをまとめます。

• コードレビューには「心理的ハードル」と「観点不足」という課題がある
• AIによるレビュー精度向上と、人間のフィードバックを取り込む仕組みで対応
• GitHub Actionsで実装し、複数プロジェクトで運用開始
• まだ導入初期だが、継続的な改善を通じて効果を検証していく

他のチームでも導入を検討される場合のTipsとしては、以下が挙げられます：

• プロンプトにプロジェクト固有の情報を含めること
• 人間のフィードバックを収集する仕組みを最初から組み込むこと
• 小さく始めて、効果を見ながら拡大すること

現時点では「人間のレビューをAIが置き換える」フェーズではなく、「人間のレビューを補完する」段階です。

GPT5.2 の登場によりモデルの変更があるかもしれませんが、何事も検証と改善が大事です。
これからも継続的に改善を続けて、より良いレビュー体制を作っていきたいですね。

それでは、良いコードレビューライフを！ 👋