Claude Code活用 #11 レビュー待ちで実装が止まる──一次レビューをAIに任せて滞りを解消した

2026年7月10日 2026年7月10日

blueleaf

受託開発の現場で、開発メンバーが次々とプルリクエスト（PR）を上げてくれるのは、とてもありがたいことです。ただ、その一方で「レビューが追いつかない」という別の問題が生まれます。

私が関わっているある開発案件でも、まさにこの状態が起きていました。実装はどんどん進むのに、レビューできるのは私ひとり。私の手が空くまでPRは列を作って待ち、開発メンバーは「レビュー待ち」で次に進めない時間が積み上がっていく。実装が速いほど、レビューがボトルネックになるという、少し皮肉な状況です。

これを、Claude Code に一次レビューを任せることで解いた話を書きます。ポイントは2つあります。ひとつは、いきなり自動化しなかったこと。もうひとつは、自動化する前に「レビューのやり方」そのものを時間をかけて仕込んだことです。

何が起きていたか

コードレビューは、ただ「動くかどうか」を見る作業ではありません。要件と実装がずれていないか、既知の落とし穴を踏んでいないか、他の箇所に影響が出ないか──こうした観点を一つずつ確認していくため、それなりに集中力と時間を使います。

PRが1〜2件なら問題ありません。ですが、複数のメンバーが並行して開発を進めると、レビュー依頼はあっという間に溜まります。私がまとまった時間を取れるのは1日に数回。その間、開発メンバーは指摘が返ってくるのを待つしかなく、待っている間は記憶も薄れます。レビューが半日後に返ってくると、実装した本人も「どういう意図だったか」を思い出すところからやり直しになります。

つまり困りごとは、私の作業負荷だけではありませんでした。レビューが返るまでの時間そのものが、プロジェクト全体の速度を落としていたのです。

いきなり自動化しなかった理由

「AIにレビューさせればいい」と思いつくのは簡単です。ですが、質の低いレビューを高速で返す仕組みは、むしろ現場を混乱させます。的外れな指摘、判断を相手に丸投げする曖昧なコメント、対応すべきかどうか分からない提案──こうしたものが3時間おきに飛んでくれば、開発メンバーの手はかえって止まってしまいます。

そこで最初にやったのは、自動化ではなく「レビューのやり方を Claude Code のスキルとして言語化し、手作業で回しながら鍛える」ことでした。しばらくの間は私が手動でAIレビューを走らせ、出てきたコメントを一つずつ見て、「この言い回しはダメだ」「この観点は要る」と調整を重ねていきました。

レビューの質を安定させるために仕込んだこと

この「手で鍛えた」期間で決めたルールが、この取り組みの肝です。代表的なものを挙げます。

実装者に設計を考えさせるフィードバックをしない。 「ここはどうするのがいいでしょうか？」とレビュー側が問いを投げ返すと、実装者はまた考え込むことになります。仕様の曖昧さや要件とのずれに気づいたら、レビュー側で仕様を確定させたうえで、「こう変更してください」という具体的なアクションの形に変換してから渡す。判断は渡す側が引き取る、という原則です。

「おすすめです」のような曖昧な表現を使わない。 「〜した方がよいです」「推奨します」「望ましいです」といった言い回しは、対応するかどうかの判断を相手に残してしまいます。指摘するなら「〜に変更してください」と、相手がやることを言い切る。言い切れないものは、そもそも指摘として出さない（消す）。この基準を徹底しました。

アクションは断定し、理由は協調的に伝える。 やってほしいことは明確に言い切る一方で、「それは間違いです」と相手のミスを断ずるような口調は避けます。「〜したいので、〜に変更をお願いします」と、意図を共有する形にする。指示は明確に、伝え方はやわらかく、という使い分けです。

指摘に優先度をつけ、要らない情報は載せない。 マージ前に必須の修正なのか、対応してほしい改善なのかを分ける。PRの画面を見れば分かるメタ情報や、相手が何もする必要のない感想は、コメントには含めない。読んだ相手が「次に何をすればいいか」だけが残るようにしました。

こうした調整を重ねて、AIが出すレビューが「そのまま開発メンバーに渡して大丈夫」と思える水準に安定してきた。ここで初めて、自動化に進みました。

3時間ごとに巡回する仕組みにした

自動化の中身はシンプルです。VPS（常時稼働のサーバー）上で、日中の3時間おきにClaude Codeを起動し、レビューが必要なPRを探して1件だけレビューさせる、という巡回を仕込みました。

動きはこうです。

日中のみ、3時間ごとに起動する。 深夜にレビュー通知が飛ぶのは相手にとってプレッシャーになるので、夜間は動かしません。
レビューが必要なPRを新しい順に探し、1回につき1件だけ処理する。 対象が無ければ何もせず終了します。
レビュー結果を課題管理ツールにコメントとして投稿する。 コメントの1行目には必ず「AIレビューです」という目印を付けます。これは自動レビューだと分かるようにするためと、同じPRを二重にレビューしないための印です。
指摘があれば、その課題を「処理中」に戻す。 開発メンバーにボールを返す、という意味です。指摘が無ければ「指摘はありません」とだけ伝えます。
結果をチャットツールにも通知する。 「指摘あり（概要つき）」か「指摘なし」かが、私の手元にも流れてきます。

うまくできていると感じるのは、修正して再提出されたPRは自動的に再レビューの対象になる点です。開発メンバーが指摘を直して push すると、そのPRは前回のAIレビューより新しくなるため、次の巡回でまた拾われます。人が「もう一度見て」と依頼しなくても、AIと実装者の間でやり取りが自然に続いていきます。