推薦チーム所属 MLエンジニアの漆山です。

私たち推薦チームは2人体制と小規模であるため、開発においてのコミュニケーションを円滑にすることが大切です。そこで、AIによるプルリクの概要とコードレビューの自動化を行いました。

この記事では、自動化前の課題や実装方法、初期の成果、新たな課題と今後の展望について詳しく紹介します。

課題と背景

自動化をする理由①人数体制

推薦チームは現在、2人体制です。少人数で開発をすべて担う必要があり、それぞれの担当範囲が広い状態です。

2人で開発で困るのは、プルリクの管理です。一方がプルリクを出すと、必然的にもう一方がレビューを行うことになります。自分の作業を止めなければなりません。

このような状況が続くと、開発の効率が著しく低下し、リリースに間に合わないリスクが常に付きまとってしまいます。仮に1人が体調を崩した場合、即座にチーム全体の可用性の低下も考えられます。

自動化をする理由②得意不得意の差異をなくす

また、MLチームはRuby、Go、Pythonの3つを利用しており、それぞれの言語に対する熟練度にばらつきがあります。メンバーごとに得意不得意があるので、コードの質を一定に保つのは容易ではありません。

これらのことから、少人数であっても効率的に作業を進めるために、自動化できるところは積極的に自動化したいと考えていました。

自動化が目的ではない。コミュニケーションを円滑にしたい

自動化を検討し始めたきっかけとして、開発体験の向上が挙げられます。元々、開発体験をより良くするためにはどうしたら良いかと考えており、趣味でコーディングアシスタントツールも作っていました。

メンバー間でスキルセットが異なることから、良いコラボレーションを生み出すためのアシストツールが必要でした。特に、技術領域や使用する言語が多岐にわたるため、各メンバーの強みを生かしつつ、弱点を補完する仕組みが求められます。

私は自動化にこだわっているわけではありません。上記を達成できるのであれば、まったく違うソリューションでも構いません。自動化がしたかったわけではなく、開発のコミュニケーションを円滑にするのが目的です。

実装方法

自動コードレビューの実装と仕組み

自動化ツールは、Python ＋ Amazon BedrockのClaude sonnet3.5でCLIツールを作って、GitHub Actionsから手動で起動できるように整備しました。

プルリクに対して、GraphQLのAPIを利用してdiffを取得して整形し、生成AIでレビューを行うフローです。

手動実行にしているのは、すべてのプルリクに対してコードレビューを実行すると金額がかかりすぎてしまうためです。自分がレビューしてもらいたいプルリクがあったときに、ghコマンドで実行するようにしています。

取り組み時の苦労：開発ルールの明文化

技術的な困難はほとんどありませんでした。あえて挙げるとすれば、プルリクを作成してレビューを行う際に必要な情報の設計や管理です。AIが的確に解析できるように、開発プロセスがルールとして明文化されている状態に整備しなければなりません。

自動化の効果と精度

工数の大幅な削減

数十分〜1時間かかっていたレビューが、だいたい数分以内で終わるようになりました。

まだ始めたばかりで、具体的な数値をもとにした計測は十分には行えていませんが、実感としては確実に工数が大幅に削減されたと感じています。

自動化の制度

レビュー精度の個人的な肌感覚としては、必要なことはほぼ全てカバーできていると感じています。

しかし、かなり大きな変更を提案されることもあるため、現実的ではないものは別の課題として持ち越すこともあります。また、AIは開発の背景などのコンテキストに乏しいため、かなり厳しめのレビューが生成されることもあります。

それでも、ある程度の妥当性は確保されており、一部のポイントでは非常に有用な指摘が得られています。

AIはあくまで人間のサポート

基本的には人間のレビューをサポートするための参考情報として、AIを利用しています。特にパフォーマンスに関するチェックは自動化レビューでは対応していないため、人間が確認する必要があります。

逆に、AIレビューの優れた点としては、ログが不足している箇所やセキュリティ懸念、例外処理などを的確に拾ってくれる点です。細かい部分の見落としが減り、より質の高いコードが保たれるようになりました。

振り返りと今後の展望

課題

現在、基本的にはプルリクのdiffからレビューを自動生成しているのですが、この方法では変更範囲に対するレビューの適切性が完全には判断できていません。そのため、プルリクの内容が大きな変更を含む場合、新しいissueを作成して対応しなければならないことがあります。

自動化レビューと連携するために、issueやGitHub Projectとも統合し、適切な情報を取得する方法を考える必要性が出てきました。プロジェクト全体の進行状況や優先順位と連動する仕組みが求められます。

すでに新たな自動化の取り組みも

実はこの記事を書いている途中で、自動化の新たな取組が進行していました。ユーザーストーリーのAIレビューや振り返り会のサマリーの自動作成などを運用中です。

1. ユーザーストーリーのAIレビュー

   • 推薦チームは開発をする際にユーザーストーリーを作成している

   • ユーザーストーリーが適切かどうかをAIがレビュー

2. 振り返りの効率化

   • チームで2週間に一度振り返りを実施

     • しかし、2週間の間に行ったすべてのことを覚えておくのは困難

   • Githubのissueやプルリクからスプリント中の出来事を抽出し次の事柄をまとめる(自動化されたKPT)

     • やったこと

     • 課題

     • 改善点

     • 次のスプリントでやるといいこと

   • 自動化されすぎていて学びを得るという観点では過剰なので、チームの学びを得られるように修正予定

これらについては1ヶ月ほど運用してみたら再び記事化する予定です。ぜひまた記事をご覧いただければと思います。

まとめ

私たちが目指しているのは単にレビューを自動化することではありません。コアのモチベーションは「クリエイターの課題を見つけて解決するためにフルコミットする」という点です。そのために、開発プロセス全体を見直し、よりクリエイターに寄り添った形でのフローを構築したいと考えています。

クリエイターのことを100%考えられる環境で開発をし、noteで創作がよりしやすい環境を目指していきます。

推薦チームは現在、MLエンジニアを募集中です。推薦チームを上記の記事で紹介しているので、こちらもぜひご覧ください。

※ この記事はエンジニアのインタビューをもとにライターが再編しました。

▼noteの技術記事が読みたい方はこちら