こんにちは。iOSアプリチームのsceneeです。
2022年11月にChatGPTがリリースされて以降、生成AIの劇的な進化を目の当たりにしている日々ですが、ヤプリでも着々とAI活用が始まっています。
その一環としてヤプリの開発チームでは、2024年6月に生成AIによるコードレビューを導入しました。最初はiOSアプリチームから始まり、Androidアプリチーム、そして他のフロントエンドやデータサイエンスチームにも導入されています。導入当初は半信半疑ではあったものの生成AIコードレビューはなかなか良い成果を上げおり、今では欠かせないツールとして定着しつつあります。
この記事では、ヤプリでなぜ・どのように生成AIコードレビューを導入したのかを紹介し、導入後のアンケート結果から見えてきた成果や課題もお伝えしていきます。
なぜ生成AIコードレビューなのか？
そもそもなぜ導入したのでしょうか？それはアプリにおける不具合・インシデントをできるだけ回避するためでした。
ヤプリでは1つのコードベースで850以上のアプリを生成しています。アプリの挙動はCMSの設定によって非常に動的に変わりますので、通常のアプリ開発以上に多くの点を考慮する必要が生じます。その結果、大きな改修になるほど軽微なミスや考慮漏れが起きやすくなることが課題でした。さらに社内のQAプロセスで捕捉できない不具合はインシデントとなってしまいます。
ここの問題を解消するために、iOSおよびAndroidアプリチームでは、コードレビューを強化してきました。主にレビュー担当者を増やし、レビュー項目をリスト化しました。一方でメンバーの時間的・心理的負荷は増大していきました。特に差分が大きいプルリクエストとなると顕著ですが、そのようなプルリクエストこそ問題が発生しやすくなります。
これらの問題は通常のコードリンターでは解決できず、静的解析ツールを充実させるリソースもありませんでした。そこで、ちょうど話題になっていた生成AIをコードレビューに応用することになったのです。生成AIなら大きな差分でもコントラストなく均一に判断して迅速にミスを発見できると予想したためです。
どのようにレビューさせているのか？
では、どうやって生成AIにコードレビューさせているのでしょうか？導入事例を調べると主にPRAgentやCodeRabbitを使った方法が出てきます。ただ、ヤプリではコスト面と製品による制約回避を理由としてこれらを利用せず、代わりに内製のgpt-reviewというツールを開発しました。これはGitHub - microsoft/gpt-reviewをベースに結果的にほぼ一から作り直したツールになります。
内製したgpt-reviewのアーキテクチャはこちらです。
gpt-reviewはGitHub Actionsのカスタムアクションとして社内レポジトリへ導入できるようになっています。また、レビューコメントは上書きされるようになっており、何度もプルリクストにPushしてもレビューコメントが増えないようになっています（過去の投稿は履歴で閲覧できます）。このGitHub Actionsによる柔軟な導入方法と自動化、そしてレビューコメントが増えない仕組みは、のちのアンケート結果でも好評でした。
さらにプロンプトファイルをワークフローで指定する(prompt_file)と個々のレポジトリに最適なプロンプトを実行できます。プロンプトファイルはプルリクエストごとに読み込まれるのでそのプルリクエストに特化したレビューコメントを出力させることもできます。
ツールを内製化したことで、チーム固有のリリースノート文言をレビューさせたり、新しいモデルに対応するなど機能拡張も迅速にできています。最新バージョンではAzure AI Searchを利用したレビュー出力やLLMのパラメーター(temperature、top-kなど)の指定、Geminiの利用も可能になっています。
なお、社内リリース前にレビューの品質面についてバックテストを実施したところ、過去にインシデントとなった巨大なプルリクエストからインシデントの発生箇所を的確に指摘することも確認できました。
使ってみてどうだったのか？
実際に役に立っているのかどうかを定性評価するために社内リリースして1ヶ月後と半年後にアンケートを実施しました。
アンケート結果 (1ヶ月後)
1ヶ月後にiOS/Androidチームへアンケートを実施した結果がこちらです。有効回答数は7でチーム全体のおよそ半数です。全メンバーが回答していないことを考慮しても良い評価が得られていることがわかります。
合わせてフィードバックコメントを記載してもらっていますが、一番多かったのはタイポなどの軽微な不備についてでした。
- 「タイポに気がつくことができた」
- 「タイポなどの細かい指摘を代行してくれるので両者心理的にもよい。」
- 「タイポや軽微な実装不備をコードレビューで指摘する必要がなくなった。」
このようにレビュー前に軽微な不具合を潰せるようになり、レビューワーの心理的・時間的負荷の軽減に役立っていることがわかります。
さらに興味深いフィードバックもありました。
- 「タイポや処理の改善案を提案してくれるため、メンバーへのレビュー前にコードの質を向上させることができる」
- 「各メンバーのプルリクを見ると、実際にAIレビューを元に改修しており、品質向上に活かせているのが確認できました。」
当初想定していませんでしたが、生成AIコードレビュー導入でメンバーがレビュー依頼前に自主的にコード品質を改善するようになりました。これは嬉しい誤算でした。最近では、実装者が見過ごしていた生成AIコードレビューの指摘をレビューワーが改めて指摘することもあります。
アンケート結果 (半年後)
半年後のアンケート結果も見てみましょう。今回はiOS/Androidチームに加えて導入チーム全体に任意で回答してもらいました。有効回答数は10で導入チーム全体のおよそ30%です。対象者を広げた割には少ないのですが、回答いただいた方にとっては概ね満足度が高い状態を保てているようです。
ただ、導入当初ほどの満足度ではないこともわかります。これは時間が経つにつれて新規性が薄れ、よりレビュー品質が注目されるようになったためです。
以下のフィードバックのようにタイポなどのわかりやすいレビューは良いのですが、よりドメイン知識が必要となる領域では期待するレビューコメントを出力できない課題が浮き彫りになりました。
- 「例えばどんなinterfaceを継承しているかなどのクラスの構造までは見られていないのか実現できない実装例が出てくることも少なくない」
- 「まだまだレビュー内容は完全とは言い難い」
一方で以下のようなフィードバックもあり、生成AIレビューがレビューアシスタントとしてチームの中に浸透してきていることがわかります。
- 「他人の工数を使わずにある程度のレビューができるのが素晴らしいので！」
- 「レビュー担当者が一人増えた感覚で安心感がある。」
2回目は推奨度も回答いただいたのですが、概ね高い推奨度を得られることができました。
半年経過しても全体的に高い評価が得られており、一過性ではなく長期的に有用なツールになってきている言っていいでしょう。
面白い活用例
最後に面白い活用例をお伝えします。
実はこのテックブログにも生成AIによるレビューが導入されています。すでにtextlintを活用されていましたが、gpt-reviewを社内公開したところ担当エンジニアの方がテックブログに応用してくれました。より的確なレビューをしてくれることがあるそうで、コードレビュー以外にも利用できるというのはなかなか面白い発想ですね。(この記事もtextlintとgpt-reviewでレビューされています)
今後について
アンケート結果のとおり、レビューコメントの品質にはまだまだ課題があります。特にドメイン知識を求められるコードレビューについては十分とは言えません。そのため、チーム固有の設計不備やプロダクトに依存した仕様不備はまだ指摘できません。
考えられる要因として、入力情報がプルリクエスト内のdiff情報に限定されていることが挙げられます。ここはソースコードの入力範囲の拡大や、関連チケット・仕様書の活用など試行錯誤が必要になるでしょう。また、本記事では全く触れていませんがプロンプトエンジニアリングも実施しており、その点での改善も必要になるはずです。
生成AIはまさに日進月歩で進化しています。その進化をキャッチアップしつつ、よりよいフィードバックを提供できるように改善していきたいと思います。
