AIで"レビュー渋滞"を解消する〜PRレビュー支援と社内ワークショップでレビュー文化を変えた実践記録〜

Orchestration Guildメンバーの福山です。普段はYahoo!プレイスというサービスで、フロントエンド開発を担当しています。

はじめにOrchestration Guildの紹介をさせてください。Orchestration GuildはExecutiveから選抜されたエンジニアが集まり、AI活用の"現場知"を横断的に持ち寄るコミュニティです。Workshopで扱うテーマ提案、実践的ユースケースの共有、技術的観点での品質アドバイスなどを担当し、Orchestration Development Workshopのコンテンツが属人化せず、継続的に発展していくことを支える役割を担っています。

このテックブログでは、私がチームで進めているAIを活用したPRレビュー支援の取り組みと、その実践をもとにOrchestration Guildで開催したワークショップ 「"レビュー渋滞"解消のためのAIと仕組み化の実践講義」 の内容を紹介します。

レビュー効率化や品質維持に課題を感じている方に向けて、AIと仕組み化をどう組み合わせ、どのようにチームや組織に変化をもたらしたのかをお伝えします。本記事を通じて、「どこから着手すればよいか」「どのような指標で効果を測ればよいか」の具体的なイメージを持ち帰っていただければと思います。

コードレビューの現状と「レビュー渋滞」という課題

2024年後半、私はYahoo!プレイスのバックエンド開発チームでテックリードを務めていました。レビュー対応は私ともう一人のメンバーに集中しており、さらに私自身も実装を担当していたため、自分のコードを書きながらレビューもこなす状況が続いていました。

開発のペースにレビューが追いつかず、レビュー待ちのPRが積み上がる一方で、頭の片隅には常に不安が渦巻いていました。「このレビュー、本当に十分だろうか」「見落としているバグがあるのではないか」。レビューに追われて自分の実装に集中できない日々が続き、タスクの締め切りが迫る中、「もっと時間があれば丁寧にレビューできるのに」という葛藤と戦いながら、個人の努力だけでは限界があることを痛感していました。

その結果、次のような"レビュー渋滞"が生じていました。

レビュー待ちPRが滞留し、実装メンバーが次のタスクに進みづらい
一日の作業のほとんどがレビューに回り、自分のタスクが後回しになる
短時間で大きめのPRをレビューしなければならず、質の高いレビューを実施できない

レビュー窓口が一部のメンバーに集中する脆さ（SPOF: Single Point of Failure）が、はっきりと露呈した状況です。レビューを徹底すれば品質は上がるが開発速度が落ち、効率を優先すればバグの見落としが増える――この"レビュー効率と品質のトレードオフ"が、私たちが解くべき課題として明確になりました。

そして2025年、Yahoo!プレイスのリニューアルリリースに向けてフロントエンド専門チームを発足させることになります。この新チーム立ち上げが、バックエンドで経験した課題を解決する絶好の機会となったのです。

タイムライン:

2024年後半
- Yahoo!プレイスのバックエンド開発チームでテックリード
- レビュー対応の集中とPR滞留が発生
- レビュー効率と品質のトレードオフが課題に
2025年前半
- Yahoo!プレイスのフロントエンドチーム発足
- "レビュー渋滞"解決の機会として取り組み開始

AIレビュー支援の導入：レビュー渋滞解消への挑戦

Yahoo!プレイスのフロントエンド専門チームを立ち上げるにあたり、私たちはまずレビュープロセスの仕組み化から着手しました。2024年に経験した「レビュー窓口の集中」「実装とレビューの両立の難しさ」といった課題を繰り返さないため、体制を整える必要があったのです。

その仕組み化の一環として、AIを活用したレビュー支援の導入を検討しました。最初に試したのは、PRの内容をAIで分析して概要を作成し、それを使ってレビューするという方法です。この方法によって、確かに変更内容の把握は楽になりましたが、コードベースを追った影響範囲の調査や潜在的な問題を見つける大変さはあまり変わりませんでした。さらに、レビューのたびにプロンプトをAIに貼り付ける手間が負担となり、2週間ほどで使わなくなっていきました。

転機が訪れたのは、2025年夏頃のClaude Codeの社内導入です。特にカスタムコマンド機能が非常に便利で、レビュー用のコマンドを一度登録しておけば、毎回プロンプトを用意する必要がなくなります。これにより、AIによるスクリーニングレビューが現実的なものになりました。

AIスクリーニングレビューとは

AIスクリーニングレビューとは、レビュアーが本格的なレビューを行う前に、AIが事前チェックを行う仕組みです。

従来のレビュープロセスでは、レビュアーがPRを開いた瞬間から、変更内容の把握、影響範囲の調査、コーディング規約のチェック、潜在的な問題の発見まで、すべてを一から行う必要があります。しかし、AIスクリーニングレビューを導入することで、AIが事前にこれらの作業を実施し、レビュアーに整理された情報を提供できるようになります。

これにより、レビュアーは「ゼロから理解する」のではなく、「AIの分析結果を確認し、最終判断を下す」というスタイルでレビューできるようになります。従来の「人がすべてを見る」レビューから、「AIが一次チェック、人が最終判断」という二段階レビューに移行することで、レビュアーの負担を軽減しつつ、品質も維持できるのです。

AIスクリーニングレビューのClaude Codeカスタムコマンドについて

Claude Codeカスタムコマンドでは、AIに次のような支援を依頼しています:

変更内容と影響範囲の自動要約
コーディング規約や命名規則の自動チェック
潜在的な問題(バグやパフォーマンス懸念)の指摘
実装者へのレビューコメントのサンプル提案

あくまで「AIが人の判断を置き換える」のではなく、「AIがレビュアーの思考を支援する」形にこだわっています。プロンプト設計やコメントトーンの最適化には特に時間をかけ、チーム全体で使えるレベルに仕上げています。

特に工夫した点は以下の3つです:

段階的なレビュー手順: レビュー要件確認 → PR全体像の把握 → 各ファイルの詳細レビュー → コードベース全体への影響調査 → 最終判断、という流れで漏れなくレビュー
コードベースの依存関係調査: レビュー対象ファイルに依存している他のファイルについても確認し、修正による不具合が発生しないかをチェック
レビュアー向けのコメント提案: 指摘事項について、レビュアーが実装者に送るコメントの文章を具体的に提案し、レビューコミュニケーションの質を向上

このAIスクリーニングレビューは、レビュアーだけでなくPR作成者にとっても有効です。レビュアーはレビュー時間の短縮と影響範囲の把握に使える一方、PR作成者はレビュー依頼前にセルフチェックとして使うことで、指摘されそうな箇所を事前に潰すことができます。

結果として、レビューにかかる時間が明らかに短縮され、実装に集中できる時間が増えたことを実感しています。

Claude Codeカスタムコマンドの内容

実際に使用しているレビュー用のカスタムコマンドは以下の通りです。カスタムコマンドの導入方法については、Claude Codeのドキュメントをご参照ください。

※本記事では社外公開用に一部内容を調整しています。

---
allowed-tools: Bash(git:*), Bash(gh:*), Read(*.md)
description: "引数で指定したPRのレビューを行います。"
---

$ARGUMENTSについてレビューしてください。
PRのURLが指定されなかった場合は現在のrepositoryのリモート情報とcurrent branchからPRを特定してください。
あるいは指定されたPRのブランチと現在のブランチが一致しない場合は、指定されたブランチにcheckoutしてください。
もしcommitやファイルの差分が存在する場合は中止してください。

▼具体的な手順

1. PRの内容と現時点のコメントをghコマンドで取得して、その情報を参考に全体像の説明をする
・説明内容:どのような背景や課題があって、そのような変更が加えられたかについて
2. 以下の点について各ファイルの要約文を表示する
・before/afterの修正差分について解説
・PRの目的に対して適切な修正であるかどうか
3. 以下の点についてコードベースを確認する
・コードスタイルが他のファイルと同一であること
・レビュー対象のファイルに依存しているファイルについて変更による不具合が発生しないこと
4. 上記の結果をもとに最終的なレビュー結果と指摘内容を表示する
5. 指摘事項について、レビュアーが実装者に送るコメントの文章を以下の条件で作文する(送信するのはNG)
・実装者へのリスペクトは忘れてはいけないが、文章は短く、簡潔に伝える。最大でも3行程度
・コメントの先頭にはラベルを付ける。例:[must], [want], [imo], [ask], [nits], [info]
・ファイルに対するコメントを優先し、コメントを表示する箇所を明示する
・以下のようなケースが発見された場合はコメントを表示してください。
　・PRの目的に沿った実装になっていない
　・セキュリティ上の問題が発生している
　・コードスメルがある
　・予期しない副作用や既存の機能を破壊している
　・APIやDBの無駄な呼び出しや処理時間の増加やメモリーリークを起こすような要因が含まれている
・以下のケースごとにセクションを分けてコメントを出力すること
　・修正や確認が必要な箇所
　・修正はいらないが懸念がある箇所
・テストの追加についてコードベースを参考にテストが必要なのかどうか判断してください

▼注意点
・.githubフォルダはプロジェクト直下にあります
・PRの情報を取得する時は以下のコマンドを全て実行すると良い。
　・PRのメタ情報:gh pr view --json title,body,files,url {pr_url}
　・PRのファイル差分:gh pr diff {pr_url}
　・PRのコメント:gh pr view --comments {pr_url}
　・PRでファイルの行につけられたコメントを確認する:gh api repos/{org}/{repository}/pulls/{prNumber}/comments | jq '.[] | {file: .path, user: .user.login, comment:.body}'
　・ファイルの特定の行にコメントする:gh api \
    repos/{org}/{repository}/pulls/{prNumber}/comments \
    --raw-field body='[imo]\nこの行の処理はもう少し安全に書けそうです。' \
    -f commit_id=$(git rev-parse HEAD) \
    -f path='src/foo/bar.js' \
    -F line=42 \
    -F side=RIGHT
　・PRのブランチにcheckoutする:gh pr checkout {pr_url}
・ghコマンド実行時はauthorは取得してはいけません
・コメントはです・ます調にし、断定の表現は避けてください。例:「〜のように見受けられます」「〜かもしれません」「〜だと思います」

スクリーニングレビューにとどまらないレビュー効率化の取り組み

AIスクリーニングレビューの導入により一定の成果が出た後、私たちはさらなるレビュー効率化に向けて、技術と文化の両面からアプローチする統合的な仕組みを構築しました。

これは単なるツールの寄せ集めではなく、「効率化の中核」→「レビュー精度向上の基盤」→「文化の醸成」→「継続改善の仕組み」という4つの打ち手が相互に補強し合うパッケージとして設計したものです。各施策の役割と効果は以下の通りです:

手法	主な効果	役割
AIスクリーニングレビュー	レビュー負荷軽減	効率化の中核
AIによるPR作成自動化	作業効率化 + 精度向上	AIレビューの精度を高める基盤
レビュー待ち通知Bot	漏れ防止・促進	文化醸成とAI活用推進
レビュー効率の可視化	モチベーション維持	継続改善とチーム評価

まとめると、レビュー渋滞を解消するためには下記のサイクルで継続的に改善していくことが重要だと考えました。

AIによるPR作成自動化

PRを作成する際の手間を削減するため、AIによるPR作成の自動化を導入しました。これは、ブランチ作成・コミット作成・PR作成までの一連のgit処理を自動化し、さらにAIが以下の作業を支援するものです:

差分からPR説明を自動生成: コミット差分を分析し、変更内容を要約したPRタイトルと説明文を生成
テンプレートの自動埋め: PRテンプレートの項目(背景、変更内容など)をAIが自動で記入

これにより、PRを作成する側の負担が軽減されるだけでなく、PRのコンテキストが充実することでAIスクリーニングレビューの精度が向上します。さらに、PR内容が標準化されることで、チーム全体でレビューの質が底上げされる効果もあります。

Claude Codeカスタムコマンドの実装

実際に使用しているPR作成用のカスタムコマンドは以下の通りです。

※本記事では社外公開用に一部内容を調整しています。

---
allowed-tools: Bash(git:*), Bash(gh:*), Read(*.md)
description: "現在のブランチのコードからPRを作成します。"
---

現在のブランチのコードからPRを作成してください。
$ARGUMENTSには対応内容の説明が記載されているのでこの内容を参考に本文を作成してください。
記載がなければファイル差分を元に本文を作成してください。

▼具体的な手順

1. PRのテンプレートファイルがあるかどうか確認する。
・ファイルはプロジェクトルートまたは.githubフォルダに保存されているのでそのフォルダを確認する。
2. テンプレートファイルの内容に合わせて、本文とそのPRのタイトルを作成してください。
・現在のブランチがmainブランチまたはdevelopブランチでないことを確認してください。mainブランチまたはdevelopブランチであればブランチを作成してください。
・ファイルの変更があるがcommitされてない場合は、関連のファイルごとにcommitを行ってください。
・PR本文には、そのPRを作るに至った背景や課題とそれに対してどのような実装を行ったか簡潔に記載してください。
・もしテンプレートがなければ後ほど記載するPRテンプレートフォーマットを使ってください。
・本文とタイトルを作成したらユーザに表示してください。
・本文とタイトルはユーザの承認を得るまではPRは作成してはいけません。
3. ユーザの承認を得たら、PRの作成を行ってください。
・対象ブランチがリモートリポジトリに存在するか事前に確認し、なければpushしてください。
・コマンドを実行する前に、実行するコマンドをユーザに見せて最終確認を行ってください。
・最終確認がとれたら実行してください。
4. PRの作成が完了したら、そのPRのURLを表示してください。

▼PRテンプレートファイル

```markdown
# 概要
PRの内容を一言で説明しましょう

## 背景や課題
PRを作るに至った背景や課題を記載しましょう

# 実装内容
背景や課題に対してどのような実装を行ったか箇条書きで説明しましょう

```

レビュー待ち通知Bot

レビューの滞留を防ぐため、レビュー待ち通知Botを導入しました。この仕組みでは:

Slackへの定期通知: レビュー待ちのPRを定期的にSlackで通知
レビュアーへのメンション: アサインされたレビュアーに直接メンション
滞留時間の表示: 各PRがどれくらい待っているかを可視化

この通知により、レビュー漏れが減るだけでなく、「早くレビューしてあげよう。そのためにAIスクリーニングレビューを使って効率化しながらやろう」という文化が醸成されます。定期的な通知が、チーム全体でAIレビューを活用する後押しとなり、効率的なレビュー文化の定着につながっています。

レビュー効率の可視化

改善の進捗を定量的に把握するため、レビュー効率の可視化に取り組みました。具体的には、週ごとにPR作成から48時間以内にレビューが完了したPRの割合を計算し、チームで共有しています。

この指標により、レビュー体制の改善がどの程度効果を上げているかを客観的に評価できるようになります。さらに、可視化されたデータはチームのモチベーション維持につながり、評価プロセスにも組み込まれることで、継続的な改善サイクルが回るようになります。数値で成果が見えることで、「AIを使ったレビュー改善は本当に効果がある」という実感がチーム全体に共有され、取り組みの持続性が高まります。

これらの取り組みを通じて、技術的な効率化だけでなく、チームの文化や評価の仕組みまで含めたレビュープロセス全体の変革を実現しました。そして、この実践で得た知見を社内に広めるため、ワークショップの開催に至ります。

ワークショップ開催：「"レビュー渋滞"解消のためのAIと仕組み化の実践講義」

ワークショップの立ち上げは、各組織のExecutiveによって選出されたメンバーで構成されるOrchestration Guildの正式活動としてスタートしました。Orchestration Guildでは、組織横断での知見共有と実践促進を目的に、定期的なワークショップ開催を企画しています。その初回テーマとして「"レビュー渋滞"解消のためのAI活用と仕組み化の実践」を取り上げるきっかけとなったのが、Orchestration Development Workshopプロジェクトのリードを務めるDevRel 井上さんからの声がけでした。Orchestration Guildメンバーの中でもレビュー効率化に積極的に取り組んでいた私の知見が、最初の題材として最適であると判断され、2025年10月30日に Orchestration Development Workshop #1 を開催する運びとなりました。

全エンジニアを対象としたこのワークショップには、リアルタイムで2000人以上が参加し、「AIと仕組み化によるレビュー渋滞の解消」をテーマに、約1時間のプログラムを実施しました。目的は、AI活用を "他人事"ではなく"自分たちの実践"として体験する場をつくることです。

ワークショップでは、前述の4つの打ち手を以下の形式で紹介しました。

手法	実践方法
AIスクリーニングレビュー	ハンズオン
AIによるPR作成自動化	事例紹介
レビュー待ち通知Bot	事例紹介
レビュー効率の可視化	事例紹介

特にハンズオンでは、AIスクリーニングレビューを参加者がその場で実際に体験できる形式を採用しています。2000人以上という大規模なワークショップでしたが、参加者一人ひとりがスクリーニングレビューを実行し、AIが生成するレビューコメントを体験することで、「AIと仕組み化を掛け合わせると何が起きるか」をリアルに体感してもらうことができます。

ワークショップ後、参加者からは「すぐに自分のチームでも使いたい」「思ったより簡単に導入できそう」といった反応があり、実装方法やプロンプトについての具体的な質問も多く寄せられました。

ワークショップの成果

ワークショップの効果を測るため、参加者を対象にアンケートを実施しました。その結果、AIを活用したコードレビュー支援の利用状況が大きく変化していることが明らかになりました。

活用状況	ワークショップ前	ワークショップ後	変化
継続的に活用している	15.0%	27.6%	+12.6pt
一部試している	30.0%	40.9%	+10.9pt
合計(何らかの形で活用)	45.0%	68.5%	+23.5pt
今後試してみたい	27.0%	19.3%	-7.7pt
活用予定なし	28.0%	12.2%	-15.8pt

主要な成果:

AI活用率: 45.0% → 68.5%（+23.5ポイント）
継続利用者: ほぼ倍増（15.0% → 27.6%）
活用予定なし: 半減（28.0% → 12.2%）

ワークショップ後、約7割のエンジニアが何らかの形でAIレビュー支援を活用するようになり、特に「継続的に活用している」層が倍近くに増加しています。これは、体験型のアプローチにより、AIレビューの効果を実感し、「自分のチームでもできる」という確信が得られたことを示しています。

また、アンケートのコメント欄には「同じ課題感を感じていて、ちょうどやってみたかった内容だった」という声が多く寄せられ、多くのチームが同じような悩みを抱えていることを改めて実感しました。結果として、複数のチームでAIレビュー支援の導入が進み、社内でのAI活用の事例として認知度が高まりました。

この取り組みの成果は社内にとどまらず、2025年10月31日に弊社のプレスリリースでも紹介されました。プレスリリースでは、社内エンジニア約7,000名を対象とした「Orchestration Guild」の取り組みとして、AIコードアシスタントを用いたコードレビュー業務の最適化が取り上げられています。全社的なAI活用推進の一環として、私たちの実践が「生成AIを前提とした働き方への転換」の具体例として位置づけられたことは、この取り組みの意義を改めて実感する機会となりました。

この取り組みから得た学び

一連の取り組みを通じて、AIを活用した開発プロセス改善について多くの学びを得ることができました。

AIと人の役割分担の重要性

最も大きな学びは、AIと人の役割分担です。AIはコードの差分分析や影響範囲の調査、潜在的な問題の指摘といった作業を高速かつ網羅的に行えます。一方で、最終的な判断や文脈を踏まえた意思決定は人が行う――この役割分担を明確にすることで、AIは「人を置き換える存在」ではなく、「人の思考を支援するパートナー」として機能します。

実際の運用では、この役割分担が様々な形で現れています。例えば、AIが指摘したコードの改善案について、レビュアーがサービスの利用状況や今後の拡張性を考慮して「現時点では必要ない」と判断するケースがあります。逆に、新規機能を追加する対応のレビューでは、パフォーマンス上の問題をAIが発見し未然に防ぐこともあります。

さらに興味深かったのは、AIの出力を起点とした対話によって、より良い解決策が生まれるケースでした。AIが提案したリファクタリング案に対して、AIと深く議論することで、当初のPRの目的を超えた本質的な改善につながったことがあります。AIは「正解を出す」存在ではなく、「思考のきっかけを与える」存在として機能することで、エンジニアとしての設計力が成長したように感じています。

開発文化の変化

AI導入は、技術的な効率化だけでなく、チームの開発文化にも様々な変化をもたらしました。

特に印象的な変化は、経験の浅いメンバーがレビューに参加しやすくなったことです。以前は「自分の知識では不十分では?」と躊躇していたメンバーも、AIの支援を受けることで自信を持ってレビューコメントを出せるようになります。AIが提案するレビュー観点を参考にすることで、徐々に「何を見るべきか」を学べる環境が整っています。

ワークショップ後、以前から熱心にAIレビューに取り組んでいる方々にインタビューを行ったところ、AIレビューは新規アサインやブランク明けの開発者の早期戦力化に効果的であることが分かりました。AIがコードの背景や影響範囲を要約することで、コードベースに不慣れなメンバーでも迅速に文脈を理解し、建設的なレビューコメントを投稿できるようになります。これは単なる効率化ではなく、チーム全体の知識レベルの底上げにつながっています。

ワークショップから得た学び：体験と共有の力

ワークショップを通じて実感したのは、体験型アプローチと知見共有の相乗効果です。

ワークショップで参加者が実際に手元でAIレビューを体験することで、理解が飛躍的に進み、導入へのハードルが大きく下がります。2000人以上という大規模な場でも、一人ひとりが自分の手でコマンドを実行し、AIの出力を確認することで、「自分のチームでもできる」という確信が生まれます。

ワークショップ後のアンケートでは、「同じ課題感を感じていて、ちょうどやってみたかった内容だった」という声が多く寄せられ、多くのチームが同じような悩みを抱えていることを改めて実感しました。体験と共有を組み合わせることで、個人の学びが組織全体の知見へと昇華していく、そんなプロセスを目の当たりにした貴重な経験となりました。

これから取り組むチームへのおすすめステップ

本記事の内容をすべて一度に導入するのは大変なので、私たちの経験から「まずはここから始めると効果が出やすい」と感じたステップを3つにまとめました。

AIスクリーニングレビューの導入
- まずはレビュアー向けのカスタムコマンドを用意し、「AIが一次チェック、人が最終判断」という二段階レビューの型をつくる。
PRテンプレートとPR自動生成の整備
- PRテンプレートを整え、AIにPR本文のたたきを書いてもらうことで、PRのコンテキストを標準化しつつ、作成コストを下げる。
シンプルなレビュー指標の可視化
- いきなり高度なダッシュボードを作る必要はなく、「48時間以内にレビューが完了したPRの割合」など、シンプルな指標から始めて効果を確認する。

この3つを小さく試しながら、自分たちのチームに合った形にカスタマイズしていくのがおすすめです。

おわりに：AIがチームを育てる時代へ

AIを取り入れたコードレビュー支援はまだ発展途上ですが、現場での試行錯誤を通じて「AIは人を置き換えるのではなく、人とAIが協働する」開発文化の可能性を実感しています。

今後は、レビューだけでなくAIコーディングの普及、特に質の高いバイブコーディング（AIと対話しながらコードを書く新しいスタイル）の実践方法についても展開していきたいと考えています。AIと対話しながらコードを書き、設計を洗練させていく――そんな新しい開発スタイルを、組織全体で身につけていくことが次のステップだと考えています。

AI活用を模索している方々にとって、本テックブログが一つの参考になれば幸いです。完璧を目指さず、小さく始めて改善していくこと。そして何より、「AIは人を置き換えない」という信念を持ち続けることが、成功への鍵だと信じています。