1. はじめに
私はKENCOPAという会社でPdMをしています。
チームで開発をしていると、どうしても「レビューって大事だけど正直めんどくさい…」と感じる瞬間があると思います。
レビューは品質を担保し、知識共有にもなる一方、AIによるコード生成が爆速になった今では、「レビュー依頼の渋滞」こそがボトルネックになっていることを痛感しました。
そこでCodeRabbitなどAIレビューサービスが増える中で、私たちのチームでは Devinを“レビュー担当”として使う仕組み を整えました。
この記事では以下のような点を実際の運用をベースに紹介します。
- なぜ私たちがDevinを選んだのか
- どうやって「AIレビュー体制」を作ったのか
- その結果どうなったのか...
要約すると、「レビュー依頼を出す → SlackにPRとプレイブックを投げる → Devinが返す」という流れが文化として定着し、人間レビューにかかる時間はぐっと減りましたが、同時にレビューを無くした弊害も出てきました。
「AIレビューって本当に使えるの？」「Devinってどう運用するの？」と疑問を持っている方に向けて、経験談を共有します。
2. なぜレビューが“最大のボトルネック”なのか
AIによってコードを書くスピードは圧倒的に速くなりました。
LLMのおかげで、「コードを書く → 機能が増える」サイクルは、人間だけでやっていた時代とは比べものにならないほど加速 しています。
ところが、レビューそのものはそんなに速くなっていません。
理由を整理すると、こんな感じです：
- 読み手の速度は上がらない：文章を読むスピードはAIで加速しません。
- レビューできる人が限られる：コードを正しく理解できる人にしかレビューは任せられません。
- AI生成コードは読みづらいことがある：文量が増えがちで、可読性が担保されないケースも。
- “とりあえず動くコード”が量産：精神コストが高く、レビュー担当が疲弊する。
つまり、「AIによる実装の加速度」と「人間によるレビュー速度」のギャップが開き続けている のです。
レビュー待ちで開発が止まり、PRが積み上がり、手持ち無沙汰な時間が生まれる…
そんな負のループがどのチームでも課題になっていると思います。
コードを書くスピードが10倍になっても、レビューが10倍速くならない限り開発全体は速くなりません。
3. KENCOPAではどう解決したか
KENCOPAでは、Devinをかなり早いタイミングで導入しました。
ベータ版の頃から触ってはみたものの、当初は「セットアップが大変だし、できることが限られていて便利とは言えない…」という印象でした。
そんな中で方針を 「レビューに振り切って使う」 と決めてから、成果がすこしづつ出始めます。
現在の運用はこんな感じです。
- ✅ Devinマシンにリポジトリを常時セットアップ しておく
- ✅ プレイブックとナレッジ でレビューに必要な前提情報を用意
- ✅ SlackでPR URLとプレイブックを投げるだけ でAIレビュー実行
- ✅ 人間レビューは“例外処理”として位置づける
もちろん重大な箇所や判断が必要な箇所は人間が確認しますが、それ以外は「Devinレビュー → セルフ修正 → マージ」という流れが定着しています。
墨消ししすぎて、機密文書感あるなぁ。。。ｗ
4. Devinレビュー体制の設計と運用で詰まったポイント
Devinを“レビュー担当”としてチームに根付かせるには、単にAIツールを導入する以上の工夫が必要でした。
4-1. セットアップが一番のハードル
Devinは 「リポジトリを事前にセットアップしておくこと」が前提 です。
普通のチャットAIと違い、以下の条件を満たしていないとレビューが機能しません。
- 正しい開発環境を持つ
- 依存関係や認証・実行環境が揃っている
- 最新の状態に同期されている
以前の私たちの環境では Cognito の認証が必須で、Devinマシンも人間と同じようにログインしないと環境構築を完了できませんでした。これが面倒で運用が回らなかったので、
- 人間とDevin共通で認証不要で動く環境へ再設計
- 「Devinが読める状態」を開発要件に含める
- 変更があれば Devinマシンも必ず更新 するルールを設定
といった “Devin前提のアーキテクチャ設計” を取り入れました。
「Devinが動く状態を保つ」意識を持つことは重要です。
4-2. プレイブック & ナレッジでコンテキストを渡す
レビューの精度は「どれだけ正しい前提情報を渡せるか」にかかっています。
- Devin Search や DeepWiki を使って リポジトリ理解用ナレッジを自動生成
- それをもとに プレイブックを整備
- PRごとに「プレイブックを添えてレビュープロンプトを投げる」運用に統一
しました。プレイブックには禁止している書き方やスタイルポリシー、レイヤー分離の注意点、例外としてOKな実装パターンなど、レビュー観点を細かく言語化して蓄積 しています。
このおかげで、Devinに渡すプロンプトが毎回明確になり、レビューの精度と安定性が向上 しました。
4-3. レビュー依頼はSlackで投げるだけ
1. PRを作る
2. Slackで「@devin <PR URL> <プレイブック>」と送る
3. Devinがレビューコメントを返す
ここまでを「セルフレビューの最低ライン」として義務化し、その上で不安な箇所だけ人間にレビューを依頼する二段階フローにしています。
📝 余談：なぜあえてDevinを使うのか？
この記事を読んだ人の中には、きっとこう思う人がいるはずです。
「いやいや、Devin高くね？」
「レビューだけなら CodeRabbit でよくない？」
「Claude Code + GitHub Actions で自動レビューできるじゃん」
正論です。
実際コスパだけで言うと、Devin は最適解じゃありません。
ACUが重たいのも事実。
それでも僕らが Devin をレビュー担当にしている理由はただひとつ。
「Devinを“レビューツール”ではなく“実装者”として使う文化をつくりたいから」 です。
本音を言うと、レビューは入口でしかなくて、最終的には “Devinが開発リソースとして機能する状態” を目指しています。
ただ、今のDevinは実装エージェントとして完全に任せ切れるレベルにはまだ少し足りない。
とはいえ、「Devinに仕事を任せる」という前提をチームに根付かせるには、まずレビューから入るのが一番自然という判断をしています。
さらに言うと、PdMとしての個人的な好みもあります。
- Devinは「人間の代わりに働く」感がプロダクトとしてめちゃくちゃ面白い
- Claude や Cursor は“人間と協働するAI”の思想だけど、Devinはもっと“丸投げできるAI”に寄ってる
- 将来的に「エンジニア＝レビューや設計に集中、実装はAIに任せる」世界を実験したい
だからこそ“Devinを使う文化をつくること”自体に価値がある、というのが本音です。
もちろん、CodeRabbit や Claude Code Action を使えば定額で回せるし、コスパで比べるとそっちの方が優秀な場面もあります。
でも僕らは 「AIに仕事を渡していく未来」を体験するためにあえてDevinを選んでいる。
5. 効果と学び
Devinレビュー体制を導入してから、人間にレビューを依頼する回数は明確に減りました。
実際の工数を細かく計測してはいませんが、「レビューに時間を取られる」というストレスは軽減された というのが実感です。
その一方で、いくつか課題や気づきもあります。
設計レビューは依然として人間の領域
Devinが得意なのはコードレベルのレビューです。
アーキテクチャ設計や責務分割、UXとの整合性など、上流の設計レビューは人間がやらざるを得ない のが現状。
コードレビューが楽になったぶん、設計レビューの重要度が相対的に増しています。
レビュー＝ナレッジ共有が弱くなりがち
AIレビューに置き換えたことで、「この人がどんな実装をしているのか」「どんな悩みがあったのか」といったレビューを通じた暗黙知の共有は薄くなります。
そのため、一定の実装がまとまったら共有会を開く など、別の場でシンクを取る工夫が必要だと感じています。
Devinならではの副産物も
一方で、Devinをレビュワーとして使っているおかげで：
- Devin Search や DeepWiki に蓄積したナレッジを後から参照できるようになり、コードの意図をAIに聞ける状態 ができてきた
- プレイブック整備を通じて、レビュー観点が言語化され資産化された
- レビュー結果を読まずとも、概要だけをAIに要約してもらう こともできる
- 普通にDevinに実装をしてもらえる
6. 正直な話：コードの「治安」とこれからの向き合い方
ここまでメリットを中心にお話ししましたが、人間のレビューをほぼ無くした結果、すべてが上手くいったわけではありません。
正直に言うと、コードの品質が悪化しました。
KENCOPAでは、DDDやクリーンアーキテクチャ、フロントエンドでは独自のレイヤードアーキテクチャを採用するなど、設計思想を強く意識した実装を行っています。
しかし、この思想をメンバー全員が深く理解し、細部まで意識を行き届かせなければ、コードの秩序は保てません。
実際、人間がレビューしていれば防げたような「設計思想から外れた実装」が紛れ込み、治安が悪化するケースもありました。
「人間レビューに戻すべきか」という議論
こうした状況を受けて、エンジニアチームからは「やっぱり人間のレビューを戻すべきではないか」という声も上がっています。
確かに人間に戻せば、コードの品質は担保されやすくなり、設計思想の理解が浅いメンバーへの教育にもなるでしょう。
しかし、私は 「安易に人間に戻してはいけない」 と考えています。
理由はシンプルで、ここで人間に戻れば「AIと共存する開発フロー」の進化が止まってしまうからです。
AIを「育てる」フェーズへ
私たちが選ぶべき道は、人間によるチェックを復活させることではなく、「DevinやレビューAIの設定を見直し、人間のレビュー観点をAIに教えていくこと」 だと思っています。
- なぜその実装がNGなのか
- 我々のアーキテクチャではどう書くべきか
これらをプレイブックやプロンプトとして言語化し、AIレビュワーの観点をブラッシュアップし続ける。
そうやって 「人間のレビューがなくてもコードの治安が良くなる仕組み」 を作り上げることこそが、今やるべき挑戦だと信じています。
もちろん、AIレビューは魔法ではありません。
使いこなすためには、実装者自身のスキルやAIへの深い理解が不可欠です。
「とりあえずAIに通せばOK」という思考停止の状態では、コードは汚れていく一方でしょう。
チーム一人ひとりの意識変革と、AIへの根気強いティーチング。
これらを通じて、最終的にはAIサービス側が進化し、こうした悩みさえも“いい感じ”に解決してくれる未来が来るのが、一番ありがたいんですけどね（笑）。
7. 最後に
導入してわかったのは、AIレビューは単なるツール導入ではなく、開発プロセス全体の設計と文化作り の話だということです。
とはいえ、レビュー渋滞に悩んでいるチームは、Devinを一度“レビュー担当エージェント”として試してみると良いと思います。
AIは人間の代わりにレビューしてくれる存在ではなく、人間がレビューに使っていた脳のリソースを浮かせてくれる存在です。
Discussion