【学習メモ】AIチャットアプリのコードレビュー観点と改善プロセス
学習メモ約3分で読めます
この記事でわかること
- 20 ファイル超の大きな PR を、4 つの観点に分けて別々にレビューするやり方
- 指摘に信頼度スコアを付けて 80% 以上だけ採用することで、「念のため」の指摘を落とす方法
- 実際のスコアリング結果（9 件中 6 件採用）と、採用しなかったもの
- 修正の優先順（セキュリティ → データ整合性 → UX → コード品質）
チームでのコードレビューをしたことがあれば十分です。例は React / Next.js の PR です。
メモ
PR全体を複数の観点から並列レビューし、信頼度スコアリングで優先度をつけて修正した実践プロセスを紹介します。
はじめに
チャット履歴永続化機能のPR（20ファイル以上の変更）をレビューした際のプロセスを振り返ります。大きなPRを効率的にレビューし、本当に重要な問題だけを抽出するための手法です。
レビューの観点（4つの並列レビュー）
- バグスキャン — ロジックエラー、Race Condition、型安全性
- Git履歴レビュー — コミット間の整合性、振る舞いを変えた意図の確認
- 既存PRコメント確認 — 過去のレビュー指摘が反映されているか
- コメントガイダンス準拠 — コード内コメントの指示が守られているか
Tips
4 つを別々に走らせるのがポイントです。一つのレビューで全部見ようとすると、最初に見つけた問題に引っ張られて残りが雑になります。観点を固定して独立に回すと、見落としが減ります。
信頼度スコアリング
各レビューで発見された問題に0〜100の信頼度スコアをつけ、80%以上のものだけをPRコメントに投稿しました。これにより「念のため」の低品質な指摘を排除し、本当に修正すべき問題に集中できます。
実際のスコアリング結果
| Issue | 信頼度 | 採用 |
|---|---|---|
Typo: xxx_promt → xxx_prompt |
95% | ✅ |
| Race Condition: セッションID上書き | 90% | ✅ |
| isSessionLoading 未使用 | 90% | ✅ |
| Path Traversal リスク | 85% | ✅ |
| useQuery enabled未設定 | 85% | ✅ |
| キャラ未発見サイレント失敗 | 85% | ✅ |
| Timezone問題 | 70% | ❌ |
| トランザクション未使用 | 70% | ❌ |
| Hydrationミスマッチ | 65% | ❌ |
修正の優先順位
採用した6件を以下の優先度で修正しました：
- セキュリティ（Path Traversal）— path.basename()で正規化
- データ整合性（Race Condition）— sessionIdをローカル変数にコピー
- UX（isSessionLoading）— 入力フォームをdisabled制御
- 堅牢性（キャラ未発見フォールバック、enabled）
- コード品質（Typo修正）
追加のリファクタリング
レビュー指摘の修正後、ベストプラクティスの観点でさらに改善しました：
- useEffect + useState → useQuery に置換（TanStack Query導入）
- zustand storeからサーバーデータ（characters配列）を削除し、queryのdataを直接使用
- let排除（Map lookup、nullish coalescingで代替）
- 重複コード削減（appendMessageヘルパー、content.trim()の一元化）
catch (error: any)→instanceof APIErrorの型安全なエラーハンドリング
このうち useQuery への置き換えは、別記事の TanStack QueryでuseEffect/useStateパターンを撆滅する で詳しく書いています。
参考リンク
まとめ
- 大きなPRは複数観点で並列レビューすると漏れを減らせる
- 信頼度スコアリング（80%以上のみ採用）でノイズを排除
- 修正はセキュリティ → データ整合性 → UX → コード品質の順で優先
- レビュー指摘の修正後に、ベストプラクティス視点のリファクタリングも行うと品質が上がる
更新履歴
- Typo の例にプロダクト固有の名前が入っていたのを汎用の形に差し替え。観点を分けて別々にレビューする理由を補足。コードの識別子をインラインコードに統一。参考リンクの節を新設し、同じ PR を題材にした他記事へのリンクを追加。「行動変更」という訳語を「振る舞いを変えた意図」に修正。
