LoginSignup
8
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@zawatti(Ryota Ozawa)in株式会社ノベルワークス

Jira x Devin x GitHub Actionsで実現するAIコードレビュー自動化パイプライン

Posted at

はじめに

こんにちは！ザワッチ(@zawatti)です！

暑い日が続いていますが、AI関連の話題も毎日アツいですね（やけどしそうなほど）

今回は、Jiraのタスク経由で作られたブランチにおいて実装されたコードに対してDevinがタスク情報も加味して、コードレビューを行うシステムを構築しました。

本記事は人間のレビュアーを置き換えることを目的とするものではなく、レビュープロセスをサポートするAI活用事例として共有します。

システム構築の背景

いろいろ背景はありますが、頑張って4つにまとめました。

  • コードレビューのリードタイムが長くなる傾向がある
  • レビュアーの専門領域とコードの技術スタックが異なる場合、適切な観点でのレビューが難しい
  • 基本的なコーディング規約やベストプラクティスのチェックに時間を要する
  • AIレビューでも、コード差分だけでは情報が不足しており、PRが生み出されたタスクの背景をコンテキストとして付与して、レビューする必要がある

目指すゴール

AIを活用してレビュープロセスを効率化し、人間のレビュアーがより高次な設計や要件に集中できる環境を作る

要件の洗い出し

コードレビューの課題を解決するため、以下の要件を定義しました。

機能要件

  • 手動トリガー: コストと必要性を考慮し、PRコメントでの手動実行
  • コンテキスト情報の活用: コード差分だけでなく、Jiraタスクの背景情報を含めたレビュー
  • コードレビュー自動化: 人間の介入なしに、レビュー実行からコメント投稿まで完結
  • 柔軟なレビュー観点: プロジェクトやレイヤーに応じたレビュー基準の適用

非機能要件

  • コスト制約: 1回のレビューは1.0ACU以内に抑える
  • セキュリティ: AIによる意図しないコード変更を防止（あくまでもコードのレビューだけ）
  • 運用性: 既存の開発フローに自然に組み込める仕組み
  • 保守性: レビュー観点やルールの変更が容易

制約

  • 既存ツール活用: GitHub、Jira、GitHub Actionsなど現在使用中のツールを基盤とする
  • 学習コスト最小化: 開発者が新しい操作を覚える必要がない
  • 段階的導入: 全PRではなく、必要に応じて選択的に使用

システム構成

システム構成はシンプルで、ワークフローファイル内で、Jiraのタスク情報を取得するAPIとDevinのセッションを作成するAPIをJSスクリプト内でたたいているだけです。

そして、弊社で管理されているGoogle WorkspaceのSSOで認可されたアカウントでしかGitHubにアクセスできないようになっています。

image.png

Devinコードレビューの流れ

1. PR作成後、Devinをメンション

PR作成後、@devin-review または /devin-reviewとコメントすると、Github Actions Workflowがトリガーされ、Jiraタスクの取得→Devinのセッション作成を行うスクリプトが実行されます。

PR作成後、自動でトリガーさせることも考えましたが、レビューさせるほどでもないPRや費用的な面を考慮して、トリガーは人間主導にしました。
あと、コードレビュー後の修正による２回目以降のトリガー発火も考慮しています。

image.png

2. Devinへのコードレビュー依頼

DevinのAPIにはセッションを作成するAPIがあり、こちらを使い、メッセージを付与してセッション作成しています。

メッセージの内訳は主に以下の通りです。

  • Jiraのタスク情報
  • コードレビューの観点
  • コードレビューの進め方

具体的にそれぞれがどのような情報なのかを説明していきます。

Jiraのタスク情報

私が所属しているチームでは、Jiraのタスク説明に命を懸けています。

というのも、人間とAIとの互換性があるようなコンテキスト設計に重きを置いているからです。

なので、人間でもAIでもそのタスクの説明を見れば、何をしようとしているかがわかるレベルではない＝そのタスクが不必要であると考えています。

という感じで、Jiraのタスク情報の説明欄の内訳は主に以下の通りになっています。

  • タスクの背景

    • このタスクが作成された背景（課題）

  • タスク完了後のゴールライン

    • このタスクを実装することによって、どのようなことが実現できるのか

  • 処理フロー

    • テキストまたはマーメイド図

  • テスト項目

    • 実装した機能に対するテストとその影響範囲までを網羅したテスト項目

  • レビュー観点

    • タスク完了を見極めるためのレビュー項目

  • 外部リンク

    • 参考情報などのリンク（Slackのリンクなど）

  • (+α) 該当ページ

    • スクリーンショットもしくはURLを貼る

  • (+α)デザインリンク

    • Figmaのデザインのリンクを貼る

基本的に以下のテンプレートは共通になっており、フロントエンドのタスクであると、FigmaのデザインコンポーネントURLを載せることもあります。

以下は、タスク説明欄を一部抜粋したものです。

image.png

セッション作成時に載せるメッセージは、人間に与える指示をベースに構成しています。
、そのタスクが生まれた背景も考慮することで、より質の高いレビューをAIにさせることができます。

ブランチの情報

JiraのタスクからGitHubのブランチを作成できる機能があり、ブランチ名にタスクのIDが含まれています。

そのJiraのタスクIDとGithubのブランチ名とで照らし合わせ、Jiraのタスクの詳細情報を取得するAPIをたたきます。

1598の部分がIDにあたります。

image.png

const jiraUrl = `${this.baseUrl}/rest/api/3/issue/${taskId}`;

以下のような形で、Jiraのタスク情報をプロンプトに埋め込みます。

## Jiraタスク情報
- **タスクID**: ${jiraTask.id}
- **概要**: ${jiraTask.summary}
- **説明**: ${jiraTask.description}
- **種別**: ${jiraTask.issueType}
- **優先度**: ${jiraTask.priority}

コードレビューの観点

ここが肝になるところですが、どこまで書くべきかはDevinの使い込み具合に応じて変わりそうです。

というのも、Devinにはナレッジ機能があるため、コードレビューの観点がナレッジとして付与されている場合は、勝手にフックされてコンテキストとして付与されることがあるからです。

以下は、コードレビューの観点の例として挙げたものです。

## コードレビュー観点

### 1. 機能要件の確認
- Jiraタスクの要件が正しく実装されているか
- 実装が仕様通りに動作するか
- エッジケースが適切に処理されているか

### 2. コード品質
- Clean Architectureの原則に従っているか
- Domain Driven Designの概念が適切に適用されているか
- 関数型プログラミングの原則（Immutable）が守られているか
- TypeScriptの型安全性が確保されているか

### 3. アーキテクチャ
- レイヤー間の依存関係が適切か
- Domain層がインフラストラクチャに依存していないか
- UseCase層が適切にビジネスロジックを調整しているか
- Infrastructure層が外部サービスとの結合を適切に管理しているか

### 4. セキュリティ
- 入力値の検証が適切に行われているか
- 機密情報の取り扱いが適切か

### 5. パフォーマンス
- 不要な処理やループが存在しないか
- データベースクエリが最適化されているか
- メモリリークの可能性がないか

### 6. テスト
- 適切なテストケースが存在するか
- テストカバレッジが十分か
- モックが適切に使用されているか

コードレビューの進め方

@レポジトリ名
You are PR Reviewer Devin with a focus on detailed inline code feedback. Your tasks:

1. Clone the repository and navigate to the branch: ${this.branchName || 'feature-branch'}
2. Set up a pre-push Git hook that prevents any pushes from a user with the username "Devin AI" OR an email containing "devin-ai-integration" as a substring. Activate the hook.
3. View the diffs of the changed files for this branch compared to ${this.baseBranch || 'develop'}
4. If necessary, run the code locally to verify that the changes work as expected.
5. Read any existing PR discussion to see what previous comments and suggestions have been made.
6. Perform code review based on the guidelines below.
7. **MANDATORY**: Post your feedback as detailed comments on the PR. You MUST comment on the PR with your findings.

## Rules and Guidelines:
1. **NEVER make any commits or pushes to the repository** - you are ONLY allowed to review code and leave comments
2. **MANDATORY**: You MUST post at least one comment on the PR with your review findings
3. Do not make more than 5 total comments on the PR
4. Use inline feedback where possible with specific line references
5. Include code snippets in markdown format when discussing issues
6. Before commenting, check that you haven't already made a similar comment
7. If no issues are found, post a comment saying "コードレビュー完了: 問題は見つかりませんでした。承認します。" and stop here
8. If issues are found, provide specific feedback and select one of: 「承認」「条件付き承認」「要修正」
9. **Never ask for user confirmation. Never wait for user messages.**
10. **You MUST complete this task by posting comments on the PR**

## 最終アクション要件:
レビュー完了後、必ずPRに以下の形式でコメントを投稿してください：

**総合評価**: [承認/条件付き承認/要修正]
**理由**: [評価の理由を具体的に記載]
**主な指摘事項**: [見つかった問題点のリスト、または「問題なし」]

この最終コメントの投稿をもってタスク完了とします。

DevinにPRレビューをさせるときのポイント・Tipsは公式から出ているので参考にしました。

@レポジトリ名を入れておくといいかも
変なレポジトリでコードレビューされる可能性があります

Jiraのタスク情報、コードレビューの観点、コードレビューの進め方を含めたセッションを作成します。

#リクエスト例

const sessionUrl = `https://api.devin.ai/v1/sessions`;
const requestBody = JSON.stringify({
prompt: prompt,
session_name: 'Code Review Session'
});

const response = await this.makeRequest(sessionUrl, {
method: 'POST',
headers: {
  'Authorization': `Bearer ${this.apiToken}`,
  'Content-Type': 'application/json',
  'User-Agent': 'Devin-Code-Review-Bot'
},
body: requestBody
});

3. コードレビューをPRにコメント

ここまでのACUの消費量は、平均0.5~1.0でした。

コード量とタスクの難しさによって、結構変わってきそうですが、大体150~200円でコードレビューをしてもらえるという認識です。

以下は、実際のDevinからのレビューコメントを抜粋したものです。（一部マスキングしています）

PRのいいところと悪いところの両方を教えてくれるのが、優秀なレビュアーのようで、怖いまであります。

image.png

image.png

承認できるかできないかまで出してくれるのいいですね～

image.png

実装にあたって気づいた点

  • Devin x GitHub連携がかなり効く

セッションに載せる情報には最低限、ブランチの情報がいりますが、そこからGit操作、GitHub CLIの操作はやはりエージェントなので、自律的にやってくれて、コメントまでちゃんとしてくれます。

軌道にちゃんと乗せれば、あとは自動運転というイメージです。

  • レイヤー単位でレビュー観点をスイッチする

フロントエンド、バックエンドであれば、設計の観点も違うので、レビュー観点も異なってきます。

レイヤー単位で変わらないレビュー観点と、タスクに応じて変わるレビュー観点を動的にレビューごとに変える必要があると感じました。

  • レポジトリ固有のコンテキストはナレッジ機能で補完

Devinのナレッジはトリガーがそれぞれにあるので、どのタイミングで呼ばれるかが定義されています。

なので、わざわざセッション作成時に、メッセージに含める必要もないので、コンテキストのオーバーフローも起こることなく、とてもうまくできているなと思っています。

Devinを使い込めば使い込むほど、ナレッジがたまっていき、文脈を読んでいい感じにやってくれる能力が向上するというイメージですね。

  • レビューする上でのドメイン知識の補完

最近、DevinからMCPサーバにアクセスできるようになったため、Devin自体が持つ知識では適切にレビューできないことを考慮して、MCPサーバを用意して、レビューにたたかせるのもありですね。

おわりに

今回構築したJira x Devin x GitHub Actionsによるオートレビューシステムは、レビュー時間の大幅短縮、一貫性のあるレビュー品質の担保、コンテキスト豊富なレビューをDevinに行わせることで、開発チームの生産性向上に大きく貢献しています。

このシステムが、同じような課題を抱える開発チームの参考になれば幸いです。

8
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
8
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?