CIと連携したレビュー設計をレビューアーが設計するには

Lint、フォーマット、静的解析、ユニットテスト、E2E。
今やCI（継続的インテグレーション）は開発プロセスに欠かせない品質ゲートとなっている。

一方で、こうしたCI自動化の発展により「レビューの意味が薄れてきたのではないか」という誤解も生まれている。
本稿では、CIとレビューが競合するのではなく補完関係にあることを前提に、レビューアーが意図して“分担設計”するための実務戦略を解説する。

1. CIの進化とレビュー役割の再定義

CIの役割は「形式的保証」と「機械的正しさ」

CIでカバーされる範囲は年々広がっている。

• コーディング規約の逸脱（ESLint, Stylelint）
• フォーマット統一（Prettier）
• 静的型解析（TypeScript, mypy, etc.）
• ユニットテスト通過確認
• セキュリティスキャン（Snyk, Trivy など）
• ビルド・デプロイの整合性確認

これらは「コードが形式的に間違っていないか」を機械的に検出する手段であり、再現性・即時性に優れている。

それでもレビューが必要な理由

しかしCIではカバーしきれない領域が確実に存在する。

2. 自動化と人間が担うべき観点を分離する設計

観点のマッピング：CI vs. レビューアー

[CIに任せる観点]
- 構文誤り、文法違反
- インデント・改行・スペース
- 未使用変数・未使用import
- 型の基本的整合
- テスト通過有無
- セキュリティ脆弱性の有無（定義済みルール）

[レビューアーが担当すべき観点]
- 設計意図との整合
- 担当責務の分離
- 命名の意味性と読解性
- 業務ドメインとの対応
- 影響範囲の妥当性
- バグの入り込みやすい構造

意図的な観点分離が文化を作る

「レビューでこれ指摘する必要あった？」という空気があると、レビュー自体が萎縮する。
逆に「この観点はCIでやるから、レビューは構造と背景に集中しよう」という暗黙の観点分離が浸透していれば、
レビュー時間は深く・短く・価値あるものになる。

3. CIで担保すべきチェック項目の設計原則

レビューから形式的なチェックを減らすには、CIが正しくカバーしていることが前提条件になる。

原則1：ルールが曖昧ならCIに移すな

例えば、「関数は3行以内で」や「コメントは必須」といったルールが曖昧な場合、CIに載せても誤検出や過剰検出の温床になる。

→ CIに載せるべきは、「ルール化できて定量的なもの」に限る

原則2：自動修正可能なものはすべてCI＋Pre-commitで

- ESLint + Prettier → `lint-staged`でPre-commit自動適用
- Stylelint → CSS/SCSSの静的解析
- husky → git commit前に実行保証

→ 「直すべきことはCIが先に直す」ことで、レビュー時間を「考えるべきこと」だけに集中させる。

原則3：レビュー観点を明示的に外す設定を持つ

PRテンプレートやチーム規約で「この観点はCIに任せる」ことを明示しておく。

以下の観点はCIで強制されているため、レビュー対象外とする：

- スペース／改行のスタイル
- 変数未使用チェック
- import順
- ファイルサイズチェック

4. レビューアーがCI設計に関与すべき理由

なぜレビューアーがCI構成を理解・設計する必要があるのか

• CIでカバーされていない観点をレビューで見てしまう無駄を減らすため
• 「CIで失敗するかも」と不安になりながらレビューする心理負荷を下げる
• CIとレビューが「互いに補完し合う関係」になるため

よくある問題：CIのエラーをレビューアーが解釈できない

`Line 22:10: 'userInfo' is assigned a value but never used`

→ エラーは出ているが、プロジェクトに特有な命名規約や暗黙仕様などの判断が混ざると、
レビューアーが「どこまで踏み込むべきか」判断できなくなる。

解決策：CIルール設計と観点整理にレビューアーが関与する

• Lint・Test・Buildなど各CIの観点表をレビューアー向けに作成
• PRテンプレートに「このCIエラーは無視して良いか」などの欄を設ける
• 「レビューしなくてよい観点」の記述をCIログとともに明示

5. CIとレビューの役割分担をドキュメント化する実務設計

CIの構成が整っていても、「誰がどこまで見て、どこから見ないのか」が曖昧なままでは運用に乗らない。
そこで、レビュー設計とCI設計を接続した役割分担ドキュメントの作成が重要になる。

ドキュメント構成例：CI vs Review 担当観点一覧

→ このようなマッピングを明文化することで、レビューアーが何を「見ない」かを安心して判断できる

6. レビュー起点でCIを改善するための実務手法

CIが完璧に設計されているチームは稀であり、むしろレビューの中で「これCIで検出できればいいのに」という気づきが重要な改善契機になる。

パターン1：毎回の指摘をCIに昇格させる

@Reviewer: import順がプロジェクト内とずれているようです。

→ 解決策：
.editorconfig や eslint-plugin-simple-import-sort をCIに追加

パターン2：PRテンプレートに「CI化候補」を記入

- レビューで毎回指摘される事項：
（例）APIエラーハンドリング忘れ、nullチェック漏れ

- 今回のPRで「CI化できそう」と思った観点：
（例）ファイルサイズ上限、特定ファイル拡張子の混入

→ レビューアーだけでなく開発者からのCI改善提案フローにもなる

パターン3：レビュー観点漏れをCIで補完する実験

• テスト書き忘れ → jest --coverage とカバレッジ閾値で警告
• コメント未記載 → ESLintルールで特定ファイルに注釈強制

7. レビューアーがCIと連携するときの注意点

注意1：CI結果を「合否」ではなく「会話の起点」として扱う

• 「CIが通っていればOK」ではなく、「なぜこのCIルールがあるのか？」を話題にする
• CIエラーを放置してレビューが進むと、責任の所在が不明瞭になる

@Reviewer: CIで通ってますが、型ガードで防げるミスが1つ見落とされているように思います。tsconfigのstrict設定に反映してもよいかもしれません。

注意2：CIの形骸化を防ぐために「なぜ」を記録する

• LintやTestが「なぜこのルールになっているか」が不明なままでは形だけになる
• ルール導入時に「背景・目的」を .github/CODE_GUIDE.md に書いておくことが望ましい

8. 今後の展望：CIとレビューの相互強化へ

将来像：レビューコメントからCIルールを半自動生成

• 頻出レビューコメントを記録し、パターン化されたものをCI化
• 例：「未使用変数」はESLint、「複数ファイルで繰り返されるロジック」は共通化スクリプトで検出

高度CI：構造解析・ビジネスルール検知

• AST（抽象構文木）レベルでのコード構造チェック
• 「業務的にこのif文は不自然」などを静的解析で補助する研究も進行中

→ レビューとCIは今後さらに近づき、「人間の思考」をルール化・自動化する方向に進む

9. まとめ：レビューアーが設計者になる時代

CIが進化するほど、レビューの本質はむしろ設計の妥当性、背景理解、文脈読解といった
人間にしかできない観点に集中する構造へと進化している。

本記事では以下の点を実務構造として提示した：

レビューアーは、レビューを単に実施する存在ではなく、レビューという“構造そのもの”を設計する存在へと進化している。