GitHub Actionsを活用したAIコードレビューツールの開発・導入から見えた「次のステージ」

株式会社ヤプリ / 山本伸
メンバー / モバイルエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|---|
Enterprise Cloud | カスタムアクション | 11名〜50名 | 2024年6月 | B to B |
利用プラン | Enterprise Cloud |
---|---|
利用機能 | カスタムアクション |
ツールの利用規模 | 11名〜50名 |
ツールの利用開始時期 | 2024年6月 |
事業形態 | B to B |
アーキテクチャ

アーキテクチャの意図・工夫
アーキテクチャは、GitHub Actionsのカスタムアクションを基盤としたサーバーレス構成です。バックエンドにはAzure AI ServicesとAzure AI Searchを採用し、RAGを用いたレビュー機能を実現しました。この構成により、開発のすべてをアプリチーム内で完結できました。
ツールを利用したいリポジトリで専用のワークフローを作成することで簡単に導入ができるので、他のチームへの展開も容易に行うことができました。
導入の背景・解決したかった問題
導入背景
はじめに、この記事は、2024年6月に内製したAIコードレビューツールについて、2025年1月までに2回実施した社内アンケートの結果を基に、その導入成果を記載したものです。
2025年10月現在、生成AIの進化に応じて、AIコードレビューツールを取り巻く環境は大きく変化しています。それを踏まえた考察は「ツールを検討されている方へのアドバイス」と「今後の展望」をご覧ください。
ツール導入前の課題
ツール導入前、ヤプリのiOSチームは主に以下のような課題を抱えていました。
- コードレビューの負担増大
- 軽微な実装不備の指摘に、レビュワーとレビューイー(コードの作成者)の双方が心理的な負担を感じていました。レビュワーは細かい点を指摘することに気を遣い、レビューイーはそれを修正する必要がありました。これらの細かい指摘作業が、本来もっと重要であるべき設計や仕様のレビューに割く時間を圧迫していました。
- ケアレスミスによるインシデントの発生
- コードの細かい確認漏れといったヒューマンエラーが原因で、インシデント(不具合)が発生していました。これにより、ユーザーに影響が及ぶだけでなく、開発チームの負担も増えていました。
- リリースノート品質のばらつき
- ヤプリでは各PRごとに実装者がリリースノートを書きます。このリリースノートの表記が統一されていなかったり、書き方にばらつきがあることが課題となっていました。また、リリースノートを作成する実装者も毎回ガイドラインを読むことがままならず、なんとなく記載している状況でした。
どのような状態を目指していたか
上記の課題を解決するために、AIコードレビューツールの導入によって以下のような状態を目指していました。
インシデントの未然防止
- AIによる自動レビューでケアレスミスをなくし、インシデントの発生を根本から防ぐことを目指していました。
レビュープロセスの効率化と負担軽減
- タイポや単純なミスなど、機械的に検出できる指摘はAIに任せることで、レビュワーの負担を軽減し、より本質的なレビュー(設計の妥当性や仕様の確認など)に集中できる環境を目指しました。これにより、レビュワーとレビュイー双方の心理的な負担を減らし、より円滑なコミュニケーションを促進することも期待されていました。
コード品質の向上
- 開発の初期段階でバグをより多く見つけ出し、QAチームへの負担軽減と手戻りの削減を狙っていました。
リリースノートの品質向上
- 初歩的な記載忘れをなくすことはもちろんのこと、チームで策定したリリースノートガイドラインの遵守を自動でチェックし、表現を統一することを目指しました。またリリースノートを書く実装者が、生成AIによるフィードバックによってより書きやすくなることも期待しました。
以上に加えて、レビューツールの導入自体がスムーズであることも重要でした。
比較検討したサービス
(比較検討は2024年6月に実施されました)
- CodeRabbit
- PRAgent(Qudo.a)
比較した軸
(比較検討は2024年6月に実施されました)
他のツールと比較する際に重要視していた点は、主に以下の3つです。
コスト増大
- 既存のSaaSツールを利用すると固定費が増大することが懸念されました。例えば、
CodeRabbit
は月額$12、PRAgent
は月額$19(GPT-4利用時)といった費用がかかりました(2024年6月時点)。2024年は特に会社として収益性改善を図っており、追加の固定費をなるべく避けたいという意図がありました。
- 既存のSaaSツールを利用すると固定費が増大することが懸念されました。例えば、
技術的な制約と利用環境への適合性
- ツールを検討し始めた当時、
PRAgent
やCodeRabbit
といった既存のツールは、ヤプリが利用していたAzure OpenAI Serviceに対応していませんでした。自社の技術スタックにスムーズに統合できるかどうかが重要な判断基準でした。
- ツールを検討し始めた当時、
開発の柔軟性と将来性
- 既製品を利用する場合、そのツールの仕様やアップデートに依存することになります。自社開発にすることで、制約を回避し、GPT-4oのような最新技術を迅速に導入できるといった柔軟性を確保したいと考えていました。実際に、GitHub Actionsのカスタムアクションとして開発したことで、各リポジトリへの導入が容易になるとともに、細かな調整でレビューコメントが増え続けないような仕組みも実現できました。
選定理由
これらの観点から自社でAIコードレビューツールを開発・導入することを決めました。
ここでGitHub Actionsのカスタムアクションを選んだ理由は以下の4点です。
- サーバーなどのバックエンド構築が不要
- 社内のさまざまなGitHubリポジトリへ簡単に導入できる
- 開発からデプロイまでリポジトリ内で完結できる
- GitHub内で完結するためサービス公開によるセキュリティリスクが低い
導入の成果
導入1ヶ月後(2024年7月)と半年後(2024年12月)で社内アンケートを実施しました。その結果、半年経過しても約9割が満足しているという結果が得られています。詳しい結果は https://tech.yappli.io/entry/intro-gpt-review をご覧ください。
コードレビューの負担軽減とコード品質の向上
- 細かい点を指摘することがなくなり、設計などより本質的なレビューに集中できるようになったことがわかりました。さらに、開発者がレビューを依頼する前のセルフチェックに役立ち、ヒューマンエラーが削減され、コード品質が向上しました。当初の狙いであったレビュワー・レビュイー双方の負担軽減に繋がりました。
- 過去に大きな問題となったインシデントのコードをこのツールでレビューしたところ、原因となった箇所を正確に指摘できたことも確認されており、インシデントの未然防止に有効であることが示されました。
リリースノートの向上
- ガイドラインのチェックを生成AIが事前に行うことでリリースノートがより統一した表記になりました。
運用の容易さ
- GitHub Actionsのカスタムアクションとして作成したことでiOSチーム以外も自発的に容易に導入できました。
導入時の苦労・悩み
まず、AIコードレビューツールの開発についてです。実装は1週間もかからずできたのですが、苦労したのはプロンプトでした。いわゆるプロンプトエンジニアリングです。自前で検証環境を作成して、満足のいくレビュー内容が出力されるようにプロンプトを改良していきました。
次に、GitHub Actionsのカスタムアクションの開発です。理解してしまえば難しくないのですが、ドキュメントがわかりづらく、全体像を把握するのに想定より時間がかかりました。必要事項は全て公式ドキュメントに記載されています。しかし、ワークフローとカスタムアクションの説明が混在しているため、カスタムアクション開発の視点だけで読み解くのが困難でした。
導入に向けた社内への説明
上長・チームへの説明
AIコードレビューツールの開発は、コードレビューの課題がチームの共通認識としてあったこと、さらに生成AIへの期待もあり、特に問題なく開発・導入を進められました。また開発自体も短期間に終わったことも良かったと思います。
次に、GitHub Actionsカスタムアクションの導入に関しては、コストが一番の懸念点でした。そのため、事前に直近のPull Request利用データから費用見積もりを算定してITチームに相談しました。結果、無料枠で収まることがわかったため問題なく導入することができました。
活用方法
社内用GitHub Actionsのカスタムアクションを作成し、各リポジトリでワークフローを作成することで、GitHub Pull Request上でAIによる自動コードレビューを利用できるようにしました。
2025年現在はGemini Code Assistの導入に伴ってコードレビューの役割は終えていますが、リリースノートレビュー機能は引き続き利用しています。
よく使う機能
- コードレビュー
- コードの概要説明
- リリースノートレビュー
ツールの良い点
- バックエンドの環境構築なしに、開発ワークフロー向けの生成AIツールを簡単に開発・導入できます。
ツールの課題点
- カスタムアクションの公式ドキュメントは情報が分散している傾向があり、理解に時間がかかる可能性があります。
ツールを検討されている方へ
GitHub Actionsのカスタムアクションは、GitHub上の開発ワークフローへ生成AIツールを導入する上で、非常に有用な選択肢となり得ます。開発だけでなく運用と社内展開が簡単でスピード感を持った導入と改善ができます。
一方、2025年現在においてAIコードレビューツールにおいては自社で開発する必要はないでしょう。Gemini Code AssistやClaude Code Actionなどが有力な候補となります。
今後の展望
2024年にAIコードレビューツールを内製・導入し社内では一定の評価を得ました。しかし、2025年に入りGemini/Claudeの導入が進み、今ではメインのAIコードレビューツールとしてGemini Code Assistを使用しています。
内製のAIコードレビューツールは現在コードレビューの役割は終えていますが、RAGを活用した「リリースノートレビュー機能」を引き続き利用しています。
このツールの変遷で印象的だったのが、AIコードレビューツールの移行がレビュー内容の差によるものではなかったことでした。一番のポイントは、Gemini Code Assistでは設定なしで「インラインレビュー・コードサジェスト」が得られることでした。レビューの品質が拮抗したとき、次に、いかにレビューコメントが読みやすいか、またレビューを読む負荷が少ないかが重要になってきたのです。
一方で、Gemini Code Assistではコードスタイル以外のドメイン知識を持たせることが難しいという課題もあります。そのため、別のより良いツールが登場すると置き換えられるかもしれません。
このような変化はありましたが、内製のAIコードレビューツール導入から現在に至るまで、AIコードレビューツールそのものが有用であるという事実に変わりはありません。
今後、チームとしては何をAIコードレビューに求めるかを定期的に議論し共通認識を持ちながら、AIの進化に応じて最適なツールを採用していくことになるでしょう。

株式会社ヤプリ / 山本伸
メンバー / モバイルエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
よく見られているレビュー

株式会社ヤプリ / 山本伸
メンバー / モバイルエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法