こんにちは。
ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。
現在のソフトウェア開発の世界は、生成AIの登場により大きな転換点を迎えています。
GitHub CopilotやClaude Codeなど生成AIを活用した開発支援ツールが次々と登場し、開発者の日常的なワークフローに組み込まれつつあります。
弊社でも例に漏れず、生成AIを活用して開発効率の向上に取り組んでいます。その中でFindy Team+で開発組織の生産性をチェックしていたところ、Pull requestの質が落ちているのでは？という仮説が浮かび上がりました。
今回は仮説が浮かんできた経緯と、その対策として導入したセルフレビューの仕組みについて紹介します。
それでは見ていきましょう！
思っていたよりPull requestの数が増えていなかった
稼働人数は昨年比で1.5倍程度増えており、それと比例する形でPull requestの作成数も単純に1.5倍に増えていました。この図から、人数の増加とPull request作成数が概ね比例していることが分かります。
しかし、1人あたりのPull requestの作成数は、昨年とほぼ変わらずでした。この図を見ると、人数が増えても1人あたりのPull request作成数はほぼフラットであることが分かります。
生成AIにPull requestを作成してもらうのであれば、1人あたりの作成数も伸びて、増えた人数以上に総数も伸びるはずでは？ここが疑問ポイントでした。
Pull requestの数が多ければ必ずしも良いわけではありませんが、AIを導入しても1人あたりの数値が伸びていないということは、どこかしらに問題があるはずです。
Pull requestの作成数だけでは判断することが出来ないので、他の数値に目を向けてみました。すると、各種リードタイムが昨年比で悪化していることがわかりました。
その中でも私が特に目を付けたのが「レビューからApproveまでの平均時間」です。この数値が昨年比で平均約20分近くも伸びていたのです。
更に「平均コメント数」と「平均レビュー数」にも目を付けました。こちらも昨年比で30%近くも増えていたのです。
これらの数値の変化から、1つの仮説が浮かび上がりました。それは「レビューで指摘された内容の対応で各種リードタイムが伸びており、マージまでの時間が伸びて結果的にPull requestの作成数が伸びていないのでは？」ということです。
この仮説を一言で言うと、「作成されているPull requestの質が落ちているのでは？」と言い換えることもできます。仮説を整理できたので、その仮説が正しいのかどうかを検証することにしました。
理解しないままレビュー依頼を出していた
AIが作成したPull requestを幾つか確認してみたところ、確かにセルフレビューである程度防げるような指摘が多く見受けられました。
例えばAIが次のようなテストコードを追加しているシーンがありました。
import { render, screen } from '@testing-library/react'; it('should render with isHiddenTitle', () => { render(<HogeComponent isHiddenTitle />); expect(screen.queryByText("Title")).not.toBeInTheDocument(); });
一見特に問題なさそうなテストコードですが、仮にテキストが常に非表示になっている状態だった場合、このテストコードは常に成功してしまいます。つまり、テストコードとしての意味を成していないのです。
特定の条件下で「表示されないこと」を守りたいのあれば、その条件下以外で「表示される」ことも同時に守る必要があります。この変更に対してはリードクラスのエンジニアからレビューで指摘が入り、次のようなテストコードになりました。
import { render, screen } from '@testing-library/react'; it('should render', () => { render(<HogeComponent />); expect(screen.getByText("Title")).toBeInTheDocument(); }); it('should render with isHiddenTitle', () => { render(<HogeComponent isHiddenTitle />); expect(screen.queryByText("Title")).not.toBeInTheDocument(); });
このテストコードで文言が表示されること、特定の条件下のみで表示されないことの両方を守ることができるようになりました。
このように、AIが出力したコードを依頼主が理解しないままレビュー依頼を出しているケースが少なからず見受けられました。そしてそれらをレビューするリードクラスのエンジニアのレビュー負担が上がっており、結果的にマージまでのリードタイムが伸びている。という状態に陥っていたのです。
これらの多くは難しい問題点ではなく、セルフレビューの時点で気づくことが出来るような内容が大半でした。
AIが出力したコードの責任は人間にあります。 レビュー依頼を出す前に、まずセルフレビューをして、早い段階で問題点に気付けるように仕組みを作ることにしました。
AIでセルフレビューを支援する仕組みを導入
自動でレビューをしてくれるサービスも利用したのですが、汎用的な内容でのレビューなのでドメイン知識や個人の癖などを考慮出来ておらず、指摘内容としても薄いものが多く、レビュー依頼する前のセルフチェックという意味合いでは不十分でした。
そこで、自分自身にカスタマイズされたセルフレビューのチェックリストを作成する仕組みを内製することにしました。
流れとしてはこうです。
まず直近数カ月で自分が作ったPull requestの一覧を取得します。そのPull requestに対して作成されたレビューコメントを全て取得します。それらレビューコメントの全てをLLMに渡して、どういう内容や傾向で自分自身が指摘されているのかを分析後にチェックリストを作成します。
作成されたチェックリストに沿って、Claude Codeにセルフレビューしてもらいます。
一連の流れはこのようになります。
このシーケンス図から、チェックリストの生成からセルフレビュー、修正の反映までが一連のフローとして自動化されていることが読み取れます。
この一連の流れを全て自動で行うカスタムコマンドを作成し、Pluginsに入れて社内に展開しました。
チェックリストを更新するカスタムコマンドと、そのチェックリストを使ってセルフレビューを実行するカスタムコマンドは分けています。チェックリストは定期的に更新すれば良いので、セルフレビューの度に更新する必要はないからです。
まずチェックリストを作成するコマンドを実行して、次のようなファイルが出力されます。
# Self-Review Checklist for hoge このチェックリストは、過去3ヶ月間（2025年9月30日〜2025年11月26日）にマージされたPRとレビューコメントを分析して作成されました。 ## 🧪 テストコード ### アサーションの品質 - [ ] `toEqual` の代わりに `toStrictEqual` を使用しているか - より厳密な型チェックのため - [ ] テストケースは実装の意図を正確に検証しているか - [ ] スナップショットテストは適切に使用されているか ### テストの網羅性 - [ ] 主要な機能パスはすべてカバーされているか - [ ] エラーハンドリングのテストは含まれているか - [ ] エッジケースを考慮しているか ## 🎨 UI/UX 設計 ### アクセシビリティ - [ ] aria-label は適切に設定されているか - [ ] キーボード操作に対応しているか - [ ] カラーコントラストは十分か ## 🎯 コミットメッセージ ### Conventional Commits - [ ] プロジェクトのコミットメッセージ規約に従っているか - [ ] 適切な type を使用しているか（feat, fix, refactor, chore, etc.） - [ ] scope は正しく指定されているか --- **最終更新日**: 2025-11-28 **分析期間**: 2025-09-30 〜 2025-11-26
次にセルフレビューのコマンドを実行します。出力されたチェックリストの内容に沿って、変更箇所をレビューしてもらいます。実際の出力例は次のようになります。
> 変更箇所に対して、`self-review-check-list.md` の内容を元にレビューしてください
⏺ 変更箇所をレビューするために、まず self-review-check-list.md の内容を確認します。
⏺ Search(pattern: "**/self-review-check-list.md")
⎿ Found 1 file (ctrl+o to expand)
⏺ Read(self-review-check-list.md)
⎿ Read 33 lines
⏺ Read(packages/feature-server/src/clients/github/github-client.spec.ts)
⎿ Read 863 lines
⏺ self-review-check-list.md の内容に基づいて、変更ファイルのレビューを実施しました。
レビュー結果
✅ コード品質
命名の明確さ
- 関数名や変数名が実際の動作を正確に表現しています
- ドメイン用語（GitHub API関連）を正しく使用しています
✅ テストコード
テストの網羅性
- 各関数に対して以下のテストケースを網羅しています：
- すべてのパラメータを指定した成功ケース
- 必須パラメータのみの成功ケース
- エラーケース
- toStrictEqual を使用してオブジェクト全体の検証を適切に行っています
テスト依存関係
- 不要なテスト依存関係は追加されていません
- プロジェクト標準のテストライブラリのみを使用しています
✅ プロジェクト固有のルール
- TypeScript Deep Dive のスタイルガイドに従っています
- ファイル名がケバブケース（github-client.spec.ts）になっています
⚠️ 改善提案
テストアサーションの統一性
packages/feature-server/src/clients/github/github-client.spec.ts:307
expect(response.data).toEqual(mockData);
他のテストケースでは toStrictEqual を使用していますが、ここだけ toEqual を使用しています。toStrictEqual に変更することを推奨します：
expect(response.data).toStrictEqual(mockData);
toStrictEqual は toEqual よりも厳密なチェック（undefined
プロパティも検証）を行うため、より堅牢なテストになります。
---
全体的に非常に高品質なテストコードです。上記の1点のみ修正すれば、チェックリストのすべての項目を満たしま
す。
テストコードを変更した場合のセルフレビュー例ですが、コード品質やテストコード、プロジェクト固有のルールに関しては基本的にクリアしていましたが、改善提案として1点のみ指摘がありました。
このレビュー結果を元に、修正も自動で行ってもらいましょう。続いてプロンプトを実行します。
> レビュー結果を元に、変更箇所を修正してください
⏺ レビュー結果に基づいて修正します。
⏺ Update(packages/feature-server/src/clients/github/github-client.spec.ts)
⎿ Updated packages/feature-server/src/clients/github/github-client.spec.ts with 1 addition and 1
removal
304 }
305 );
306 expect(response.status).toBe(HttpStatusCode.OK);
307 - expect(response.data).toEqual(mockData);
307 + expect(response.data).toStrictEqual(mockData);
308 });
309
310 it('fetch data with only required params', async () => {
⏺ 修正が完了しました。
修正内容
packages/feature-server/src/clients/github/github-client.spec.ts:307
変更前:
expect(response.data).toEqual(mockData);
変更後:
expect(response.data).toStrictEqual(mockData);
この修正により、テストアサーションが統一され、すべてのテストケースで toStrictEqual
を使用するようになりました。toStrictEqual は toEqual よりも厳密なチェック（undefined
プロパティも検証）を行うため、より堅牢なテストになります。
これで self-review-check-list.md のすべての項目を満たすコードになりました。
この仕組みにより、定期的にチェックリストのファイルを更新することによって、セルフレビューの精度を上げ続けることが可能となります。
まとめ
今回はジュニアエンジニアがAIを使ってPull requestを作成した場合に、セルフレビューでのチェックが甘くなり、レビュワーの負担が上がっているといったケースでした。
「AIに使われる」のではなく、「AIを使う」ためにも、AIが出力したコードを理解することが必要不可欠です。AIが出力したコードの責任は人間にあります。自分自身の責任を果たす意味でも、生成AI時代のセルフレビューが持つ意味合いは、これまで以上に重要になってくるでしょう。
現在、ファインディでは一緒に働くメンバーを募集中です。
興味がある方はこちらから ↓ herp.careers
