Devinにファーストレビューをさせ、コードレビュー を効率化するには 〜認知負荷を減らし、エンジニアが本質的な作業に集中するため に〜 株式会社グロービス 大沼 和也 1 

開発業務やレビューをする中で こんなことで時間溶けてませんか？ 「またこの指摘か…（typo、命名規則、PRが大きすぎる、PRにリファクタと本実 装が混じっているなど） 」 「レビュー待ちのPRが溜まっていく…」 「もっと設計やロジックの議論に時間を使いたいのに！」 「忙しいときに限ってFlaky Testが爆発してCIが通らない（虚無） 」 2 

もし、AIがこの一部を肩代わりしてくれたら？ →人間はより創造的で高度な作業に集中できる！ 3 

今日の「おみやげ」 AIレビュアー導入による認知負荷軽減と本質的作業への集中の可能性 リアルな運用ノウハウと直面した課題 AIレビュアーを 「育てる」ための継続的なチューニング方法 明日から 皆さんのチームで試せるかもしれないアクションのヒント 4 

現状の課題 なぜコードレビューは“気をつけること”の塊なのか？ Linterだけではカバーしきれない領域 プロジェクト固有の設計ルール チーム内の暗黙的なお作法 過去の障害事例からの教訓 人間によるチェックの限界 見落とし、揺らぎ 繰り返しによる疲弊 「同じような指摘」の再生産 例：わかりづらい既存コードの誤用 5 

解決策 AIレビュアーという新たなパートナー AIに“気をつけること”の一部を任せる 定型的なチェック 過去の指摘パターンに基づくアドバイス チームのノウハウの形式知化・自動チェック 人間の役割の変化 AIの指摘を踏まえ、より高度な判断に集中 設計思想、アーキテクチャ、ビジネスロジックの妥当性評価など 目指すは「人間の認知負荷削減」と「本質的な作業への集中」 6 

AIレビュアーを育てる、継続的運用の3本柱 1. AIレビュアー を Testable に保つ 変化に対応し、信頼性を維持するために 2. 効率的な Knowledge 管理 AIが学習しやすく、人間もメンテナンスしやすい知識ベース 3. エージェントをA/Bテストしやすい仕組み 既存への影響を最小限にしつつ、AIレビュアーの効果を測定・改善するため に 7 

柱1: AIレビュアー を Testable に保つ 背景：AIモデルは進化し、最適解は常に変わる フィードバックループを短く、迅速な検証が不可欠 テスト容易性の鍵：単一責任の原則 (SRP) AIレビュアーの各チェック機能を疎結合に 例：FlakyTestsチェッカー、脆弱性チェッカーなど アンチパターン：責務過多の巨大AIレビュアー テストが複雑化、変更の影響範囲大 FlakyTestsと脆弱性チェッカーは依存関係がないので、独立させるべき （例：1つのAIに何でもやらせようとするとテストが難しくなる） 8 

柱2: 効率的な Knowledge 管理 AIレビュアーの「脳」となる知識ベース コードベース、設計ドキュメント、 コーディング規約など 「コード整頓」のアプローチ DevinWikiのようにコードからドキュメント 生成されるように 人間にもAIにも直感的でないコードはリフ ァクタしていく リファクタリングが難しい既存コード構造 化 例：説明コメント、説明変数の追加、 デッドコード削除など 9 

柱3: エージェントをA/Bテストしやすい仕組み 目的：AIレビュアーの改善効果を客観的に評価 新しいルール、異なるプロンプト、Knowledgeベースの変更など 仕組みのポイント 同一のPRに対して複数のAIレビューパターンを適用・比較 継続的な改善ループを回す AIレビューの精度を必ず人間が評価する 10 

AIエンジニア「Devin」との出会い Devinとは？ 自律型AIソフトウェアエンジニア 期待したこと 高度なコード理解と文脈を読んだレビュー 設計原則に基づいた指摘 11 

Devinのレビューで実現できたこと 例：Railsアプリケーションにおけるビジネスロジックの配置 Devinの指摘概要: このPRでは、期限切れGroupProposalUserの個人情報をマスクするジョ ブが実装されています。…DHHスタイルのRailsパターンの観点からいくつ か改善点があります。 ビジネスロジック（期限切れGroupProposalの検索とGroupProposalUser のマスキング処理）がジョブクラスに配置されています。…ビジネスロジ ックは必ずモデルに配置することが推奨されています。 12 

Devinのレビュー：Before Jobがビジネスロジックを持って肥大化している例 class ExternalService::Contact::BulkUpdateUserNameJob < BaseJob sidekiq_options queue: :low_priority def perform(contact_ids_cache_key) # ... external_service_contacts.each do |contact| updated_name_attrs = user_name_attributes(contact) # ... (ビジネスロジックの一部) bulk_update_payload << ExternalService::Schemas::Bulk::Contact.new( id: contact.object_id, properties: updated_name_attrs ) # ... (さらにビジネスロジック) end # ... end private def user_name_attributes(contact) # 本来モデルにあるべきロジック # ... end 13 

Devinのレビュー：After モデルにロジックを移動しJobはシンプルに # app/models/group_proposal_user.rb class GroupProposalUser < ApplicationRecord def mask_personal_information! # ... マスキング処理 ... end end # app/models/group_proposal.rb class GroupProposal < ApplicationRecord def self.expired_without_application # ... 検索ロジック ... end def mask_users_personal_information! group_proposal_users.each(&:mask_personal_information!) end end 14 

Devinのレビュー：After モデルにロジックを移動しJobはシンプルに class MaskGroupProposalUsersJob < BaseJob def perform GroupProposal.expired_without_application.find_each(&:mask_users_personal_information!) end end 15 

Devinのレビューで Flaky Testの芽を摘む Devinからの指摘例: xxxのテストは、時間依存の処理を含んでおり、 環境によってはFlaky Testになる可能性があります： 固定の待ち時間（2秒）を使用するのではなく、 要素の状態変化を待つようなより堅牢な方法を検討してください。 効果：潜在的なテストの不安定性を未然に防止 16 

Devin運用の壁 見えてきた課題 知識を詰め込みすぎるとかしこ さが減る 詰め込みすぎると、以前参 照されていた知識が参照さ れないことがある エージェントのA/Bテストが手軽 にできない 17 

Devin運用の壁 見えてきた課題 Knowledge管理の難しさ バージョン管理ができない → 変更追跡が困難 コストが高い 他のAIエージェント（例： Cline や Roo Code ） と比較して5倍以上かかることも 18 

AIエージェント「Roo Code」で課題解決 Roo Code とは？ Cline（自律的なAIコーディングエージェント）から派生 Mode（エージェント人格のようなもの）を定義可能 Devinの課題に対するRoo Codeの利点 Knowledge・Rulesのファイル管理 Git等でバージョン管理できて扱いやすい 変更履歴の追跡、複数人での共同編集 人格の増やし方がかんたんなので、エージェントの優劣をみるためのA/Bテス トができる 19 

Devin RooCodeにファーストレビューをさせ、コード レビューを効率化するには 〜認知負荷を減らし、エンジニアが本質的な作業に集中するため に〜 株式会社グロービス 大沼 和也 20 

AIエージェント「Roo Code」で課題解決 Orchestrator Modeで親となるModeを定義 new_task を実行し、他のModeにサブタスクを振る new_taskに渡す引数であるmessageを調整し、渡すコンテキストの量を調整 することができる コンテキストを適切に調整できれば、出力を安定させることができる 21 

理想的なレビューフロー new_taskを非同期で実行し、特化 Modeにサブタスクを振って集約させ ることで、大幅に速度が上がる 22 

Roo Code AIレビュアー育成マニュアル 1. 障害やヒヤリハット事例のPRをAIに見せる (インプット) 2. 「何がリスクだったか？」を答えを与えずにAIに徹底分析させる (思考訓練) 3. 実際の障害対応PR（正解例）を見せる (模範解答) 4. 「どうすれば事前に気づけたか？」をAIに分析させる (再発防止策の検討) 5. 分析結果を 新規ModeのRulesにルールとして記述 (形式知化) 6. ルールが具体的すぎたら、適度に抽象化して汎用性を持たせる (応用力UP) 7. 別の類似PRをレビューさせ、正しく指摘できるかテスト (実践演習) →指摘できなかったら正しく指摘できるまで繰り返す 23 

Roo Code AIレビュアー育成マニュアル 単純化するとこんなフローイメージ 24 

Roo Code でのチューニング例 25 

Roo Code でのチューニング例 26 

Roo Code でのチューニング例 27 

Roo Code でのチューニング例 28 

明日から個人で始めるAIレビュー 「AIレビュアーが賢くなり続けている！」と感じる間は1つの大きなモデルに知識 を追加していって一旦OK 「書いてあるのに指摘してくれない」など出てきたら少しずつ分割を始める Linterでは拾えないけど単純な指摘をするAIレビューから始めてもOK 29 

まとめ AIレビュアーは、人間の認知負荷を減らし、本質的な作業への集中を助ける強力 なパートナー 導入・運用には工夫と継続的な「育成」が必要 Testableな設計、効率的なKnowledge管理、効果測定と改善 具体的なツール（Devin, Roo Codeなど）の特性を理解し、目的に合わせて活用 30 

ご清聴ありがとうございました！ 31