日本経済新聞社はレビュー待ち1週間をどう縮めたか？

先に結論

日経電子版などのフロントエンド開発を担うWebチームは、協力会社のメンバーが書いたコードを日経社員がレビューする体制でした。

チームは担当社員12名と協力会社のメンバーを含めて20名超いる一方、高度な設計判断ができるテックリード的なメンバーは2名で、レビュー待ちが開発の停滞点になっていました。

CodeRabbit を入れたあと、プルリクエストを出してからマージされるまでのリードタイムは、多い時で中央値1週間だったものが約1日に縮みました。

日経のチームは試験導入の段階で、デフォルトのままではレビュー頻度が多く、プルリクエストのサマリーに出るシーケンス図も情報が多すぎると感じ、シーケンス表示をオフにして頻度を少なめに絞りました。

チーム特有の規約は Markdown で書き起こす代わりに Learnings に持たせ、プルリクエストへのコメントが蓄積されて次回のレビューから適用される形にしています。

既存の実装を流用したようなコードのレビューは CodeRabbit に任せ、キャッシュの設定などシステムの稼働に影響するクリティカルな部分は人間が見る、という線を引きました。

AI によるコードレビューは、この1年で一気に標準になりました。GitHub の Copilot Code Review は一般提供の1か月後に100万ユーザーへ届いています。

そのなかで導入が続かなくなる原因は、指摘の精度より量にあるとみられます。すべてのプルリクエストに全力で指摘が付くと、開発者はやがて読み流すようになり、本当に見るべき指摘が埋もれます。

日経のチームが試験導入で最初にやったのは、検出力を上げることではなく出力を減らすことでした。AI レビューの設定は性能のチューニングではなく、人の注意をどこに残すかの設計なのだと思います。