以下の内容はhttps://tech.findy.co.jp/entry/2026/03/13/070000より取得しました。


Findyの爆速開発を支えるセルフレビュー自動化の仕組み

こんにちは。ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。

現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。

GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。

ファインディではClaude CodeのSkillやカスタムコマンドなどをPlugins経由で社内展開しています。Pluginsに関しては前回の記事を参照してください。

tech.findy.co.jp

AIに設計やタスク分解、コード生成を任せる分、Pull requestのコード品質やコードレビューがネックになることがあります。「型チェックが抜けてる」「命名がチームの規約と違う」といった指摘で手戻りが発生すると、AIで加速した開発のテンポが崩れてしまうからです。

本記事では、その課題に対処するために社内Pluginsに作ったセルフレビュースキルを紹介します。過去のレビューコメントから自動生成するチェックリスト、複数のAIエージェントによる並列レビュー、修正の段階的な適用を組み合わせて、Pull requestを出す前のセルフレビューを自動化しています。

Pull requestの質と、コードレビューをめぐる課題

AIが設計やコード生成を行うようになり、1日に作成できるPull requestの数は増えました。しかし一方で、Pull requestの質やコードレビューで問題が出てきました。

AIが出力したコードがチームのコーディング規約に沿っていなかったり、型チェックが抜けていたり、テストコードが不十分だったりすると、コードレビューで指摘されて手戻りが発生します。AIで加速した開発のテンポが崩れてしまうのです。

そしてこれら全てを人間のコードレビューで事前に防ぐのは、現実的に難しくなってきています。

AIが生成するコードの量とPull requestの数が増えており、これら全てを人間がチェックしようとすると、人間がボトルネックとなるのです。

そこでファインディでは、人間がチェックしないといけない領域と、AIにチェックを任せる領域を切り分けたうえで、AIにチェックを任せる領域を自動化することにしました。それが今回紹介するセルフレビューのスキルです。

セルフレビュースキルの概要

セルフレビュースキルは社内展開しているClaude Codeのスキルの一つで、Pull requestを出す前にコード変更をセルフレビューするためのものです。「セルフレビューして」と話しかけるだけで起動します。

# カレントブランチ全体をレビュー
セルフレビューして

# 特定ファイルに絞る
src/services/UserService.ts をセルフレビューして

# コミット範囲を指定
HEAD~3..HEAD の変更をレビューして

起動すると、リポジトリ全体の過去指摘パターン・バグ検出・セキュリティ・コード品質・実装漏れといった 異なる視点を持つ複数のエージェントが同時に動き出します。

それぞれが独立してdiffを解析し、全エージェントの完了後に結果をサマリとして統合します。

指摘事項は出典エージェント付きで一覧化され、「すべて反映」「個別に選択して反映」「反映しない」の3択でコードに適用できます。

エージェント並列レビューの設計

現在は最大6つのエージェントを並列起動します。各エージェントはレビュー対象のdiff(git diff DEFAULT_BRANCH...HEADの結果)を受け取り、それぞれ異なる観点で独立して動作します。

全エージェントの完了を待ってから結果を統合するため、直列実行と比べて待ち時間を大きく削減できます。

規約・スタックベースのチェック

プロジェクトの命名規則への準拠、テストコードの適切さ(テスト漏れ・カバレッジ・テスト規約への準拠)、ドキュメントとの整合性に注力して確認を行います。

CLAUDE.mdやrulesなど、プロジェクトの規約やスタックに関するドキュメントを学習したエージェントが、diffの内容と照らし合わせて規約違反やスタックの不適切な使用を指摘します。

チェックリスト照合

事前に用意しているセルフレビューのチェックリストの各項目とdiffを照合します。チェックリストの項目は該当リポジトリの過去のPull requestで指摘された内容から生成されているため、「やりがちなミス」にピンポイントで反応します。

チェックリストの自動生成の仕組みについては、次の記事で詳しく紹介しています。

tech.findy.co.jp

このチェックリストは定期的に自動で更新されるように仕組み化しており、常に最新の指摘パターンをカバーできるようになっています。

コード品質チェック

Claude Code公式プラグインのfeature-dev:code-reviewerエージェントが動きます。

github.com

バグ・セキュリティ・コード品質の3観点で検査し、信頼度80以上の指摘のみを報告する設計になっています。「これは問題かもしれない」程度の低確信度の指摘は出力されないため、レビュー結果がノイズで埋まりません。

具体的には次のような問題を検出します。

  • ロジックエラー(条件分岐の誤り、状態管理の不整合)
  • セキュリティ問題(SQLインジェクション、認証チェックの欠落、機密情報のハードコード)
  • コード品質(デッドコード、過剰な複雑度、テストの網羅性)

Codex AI

OpenAI Codex CLIのcodex reviewコマンドにdiffを渡してレビューを実行します。

developers.openai.com

プロンプトは次の優先順位で構成されており、スタイルやフォーマットの指摘は明示的に除外しています。

【最優先】バグ検出
- ロジックエラー、エッジケースの見落とし、例外処理の漏れ
- null/undefined処理の欠落、境界値チェックの不足

【第2優先】セキュリティ問題
- SQLインジェクション、XSS、CSRF
- 認証・認可の欠陥、機密情報の露出

【第3優先】パフォーマンス問題
- 非効率なアルゴリズム、メモリリーク、不要なループ

【除外】コードスタイルやフォーマットの指摘

Codex CLIが未インストールの場合は起動時に確認を求め、承諾されればnpm install -g @openai/codexを自動実行します。認証(ChatGPTアカウントへのログイン)も同様に案内します。

ファインディでは基本的にClaude Codeでコード生成を行っており、Codexはレビューの観点を増やすための補完的な役割で使っています。コード生成したモデルとは別のモデルの観点でのレビューを挟むのをオススメします。

コード簡潔化

Claude Codeのビルトインスキル/simplifyを呼び出します。/simplifyはコード変更を対象に「コード再利用」「コード品質」「効率性」の3観点でレビューエージェントを並列実行し、結果を統合して報告します。既存ユーティリティとの重複検出、冗長な状態管理、不要な処理・並列化漏れ・メモリリークなどが検出対象です。

code.claude.com

要件確認

現在のPull requestのタイトルとBody、紐づくIssueの内容から要件を抽出し、実装コードとテストコードの両方に反映されているかを2軸で分析します。

要件は「機能要件」「非機能要件」「エッジケース」の3種類に分類したうえで、実装ギャップ(要件があるのに実装がない)とテストギャップ(実装はあるのにテストがない)を区別して報告します。

## ギャップ分析レポート

### ✅ 実装・テスト両方あり
- ユーザー認証: 実装: UserService.ts:42 / テスト: user_service_spec.rb:15

### ⚠️ 実装済み・テストなし → テストが必要です
- パスワードリセット: 実装は PasswordService.ts にあるが、テストがない
  理由: 異常系(トークン期限切れ)の挙動が未検証

### 🚨 実装なし・テストなし → 実装漏れの可能性があります
- メール通知: Issueに「登録完了メールを送信する」とあるが、実装が見当たらない

レビュー結果の統合と出力

全エージェントの完了を待ち、結果を統合して表示します。

各レビュー用エージェントからの報告のサマリを出力して、コードの品質を全体的に把握できるようにします。

## セルフレビュー結果

### 📋 チェックリスト照合

#### ✅ 問題なし
- nullチェック: OK

#### ⚠️ 改善提案
- 関数名の命名規則: getUserById → fetchUserById に統一するとよい

#### ❌ 要修正
- エラーハンドリング: 外部API呼び出しにtry-catchがない

---

### 🔍 コード品質チェック

#### ❌ 要修正
- L42: 認証トークンのnullチェックが欠落
  修正案: `if (!token) throw new UnauthorizedError()`

---

### 🤖 Codex AI

#### ⚠️ 改善提案
- L78: N+1クエリの可能性。ループ内でDBアクセスが発生している

---

### 📊 レビューサマリー
- チェックリスト照合: ✅ 3個 / ⚠️ 1個 / ❌ 1個
- コード品質チェック: ✅ 0個 / ⚠️ 0個 / ❌ 1個
- Codex AI: ✅ 0個 / ⚠️ 1個 / ❌ 0個
- 要件確認: ✅ 2個 / ⚠️ 1個(テストギャップ)
- 合計指摘事項: 4個

修正の段階的な適用

レビュー結果が揃ったら、AskUserQuestionで3択を提示します。

? 修正を反映しますか?
> 個別に選択して反映する (Recommended)
  すべて反映する
  反映しない
  Other…

「個別に選択して反映する」では、指摘事項を一件ずつ確認しながら採否を判断できます。「この修正を適用しますか?(出典: コード品質チェック)」のように出典が表示されます。

## 未対応リスト(インラインコメント用)

### 1
- path: src/services/UserService.ts
- line: 42
- source: code-reviewer
- body: **[出典: コード品質チェック]** 認証トークンのnullチェックが欠落しています

  **修正案**: `if (!token) throw new UnauthorizedError()`

  <sub>*AIセルフレビュー*</sub>

「すべて反映する」を選ぶと、レビュー用エージェントそれぞれからの修正提案をEditツールで順次適用します。

「反映しない」を選ぶと、レビュー結果の確認だけで終了します。内容を把握してから自分で修正したい場合に使います。

まとめ

AIが開発ワークフローに入れば入るほど、生成されるコードやPull requestの数は増えていきますが、それら全てに人間が対応するのは現実的に難しくなってきています。

人間が対応する必要のある領域と、AIに任せる領域を切り分けたうえで、AIに任せる領域を自動化することが重要になります。

全ての変更内容を同じレベルでレビューしない ようにすることがAIレビューの設計のコツです。

軽微なリファクタリングと、データベースからの項目削除は、同じレベルでレビューする必要はありません。前者はコード品質の観点で簡単にAIに任せてしまい、後者は人間がしっかりレビューする、といった具合に、変更内容の性質に応じて適切なレビューのレベルを設計するのがポイントです。

ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。

herp.careers




以上の内容はhttps://tech.findy.co.jp/entry/2026/03/13/070000より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14