コードレビューに関するTipsを投稿しよう！ by CodeRabbit Calendar 2025
https://qiita.com/advent-calendar/2025/coderabbit-02
Code Review
Code Reviewをやる際の手順（分類、時期の種類とやり方）を示します。
プログラムの種類
- インタプリタなどのコンパイラを使わないプログラム
- コンパイラなどのそのPCだけで完結するプログラム
- 通信プロトコルなど複数の計算機器を想定したプログラム
- PC以外の機器にインストールして動かすプログラム
- PC以外の機器にインストールして動かすプログラムのうち安全関連系
ChatGPT
Code Reviewをするときにプログラムの種類によてt項目を分けています。 1. インタプリタなどのコンパイラを使わないプログラム 2. コンパイラなどのそのPCだけで完結するプログラム 3. 通信プロトコルなど複数の計算機器を想定したプログラム 4. PC以外の機器にインストールして動かすプログラム 5. PC以外の機器にインストールして動かすプログラムのうち安全関連系 上記５つ以外に、CodeReviewをする際に他徳分して特別の項目を洗い出した方がいいものはありますか。
以下の5分類は、対象プログラムの「実行環境」や「影響範囲」によって Code Review の観点を分けるという点で非常に合理的です：
- インタプリタ系（コンパイラ不要）
- コンパイラ系でPC内で完結
- 通信プロトコル含む分散・ネットワークプログラム
- PC以外の機器にインストール（組込みなど）
-
その中で安全関連（Safety-Critical）
この分類は “どこで動くか / どれだけ危険か” で整理されていますが、
Code Review ではこれに加えて “どう開発されるか / どう運用されるか” の軸でも特別視点が必要です。
✔ 追加すると有用な 6 つの特別カテゴリ
実務のレビューで頻出するものを中心に、既存の５分類では拾い切れない「レビュー観点が大きく変わるカテゴリ」を述べます。
6. リアルタイム処理（Hard/Soft Real-Time）
対象例：ロボット制御、音声処理、金融高速取引、RTOSプログラム
理由：
- 遅延許容値がミスできない（ミスはバグではなくシステム障害）
- 割込み・優先度・スケジューラとの競合
- ガーベジコレクションの有無 (Java, C#, Python RT系)
特別なReview項目：- Worst Case Execution Time (WCET)
- 優先度逆転の対策
- リアルタイムスレッドの同期方式
- メモリ割り当てタイミング (RTでは動的確保NG が多い)
7. 高信頼性・高可用システム（High Availability / Fault Tolerant）
対象例：クラウドサービス、DBシステム、ミッションクリティカルWebシステム
理由：
- プログラム単体ではなく “サービス” としての連続稼働が目的
- 冗長化設計を前提にしたコードかどうかを見る必要
特別なReview項目：- 再起動サイクル / ヘルスチェック
- 冗長化構成（Active/Standby、マルチAZ）
- セッション状態の扱い（Stateful → Stateless化できているか）
- 障害を想定した例外処理（ネットワーク断、DB再接続）
8. セキュリティ要求が非常に高いプログラム（Security-Critical）
対象例：認証システム、暗号処理、支払いサービス、鍵管理、金融API
Safety（生命安全）とは別に Security（攻撃耐性） で分類。
特別なReview項目：
- 攻撃面（Attack Surface）の排除
- 入力バリデーション
- 例外時に情報漏洩がないか
- 秘密情報の取扱い（鍵、パスワード、トークン）
- ログ出力の取り扱い（秘匿情報の誤ログ）
9. AI / ML / LLM を含むプログラム
対象例：推論サーバ、学習スクリプト、モデル更新パイプライン
従来のプログラムと異なり「動作の正しさ」をコードだけでは判定しにくい。
特別なReview項目：
- データ前処理の再現性
- モデル更新の安全性
- 評価データの偏り・リーク
- 推論APIの遅延とメモリ圧力
- GPU関連（メモリリーク・非同期呼び出し）
10. バッチ処理・ジョブフロー（ETL / 大規模データ処理）
対象例：日次バッチ、ログ解析、ETL、Spark/Presto/BigQuery のジョブ
バッチ特有の課題
- 大量データ × 限られた時間
- 再実行時の冪等性
- 大規模入力時の性能劣化
特別なReview項目： - 冪等性（途中失敗→再実行可能か）
- メモリ使用量・外部IO
- 部分成功／部分失敗の扱い
- スケジューラ（Airflow, cron）との連携
11. フレームワーク特化・DSL（ユニークなルールがあるコード）
対象例：Simulink、Mathematica、LabVIEW、ROS、Unity、Vue/Reactのコンポーネント
通常のプログラムとは全く違う制約がある。
特別なReview項目：
- フレームワークのライフサイクル理解
- コンポーネントの依存関係
- プラットフォームバージョン依存
- 設定ファイル（model, scene, graph, yaml）の妥当性
12. インフラ構成・IaC（Infrastructure as Code）
対象例：Terraform、Ansible、CloudFormation、Dockerfile、K8s YAML
これは実行環境そのものを構築するため Code Review で特殊扱い。
特別なReview項目：
- Stateful / Stateless の区別
- 権限設定（IAMロール、サービスアカウント）
- 破壊的変更の検出
- バージョン固定（Pin）
- セキュリティグループ、ネットワーク境界
✔ 特におすすめの追加カテゴリ（まとめ）
| 追加カテゴリ | なぜ必要か | 主なReview観点 |
|---|---|---|
| 6. リアルタイム処理 | 時間制約でバグ扱いが変わる | WCET、割込み、メモリ管理 |
| 7. 高可用・冗長化システム | 連続稼働が最優先 | 冗長化、再接続、例外処理 |
| 8. セキュリティクリティカル | 攻撃耐性が必須 | バリデーション、秘密情報管理 |
| 9. AI/ML/LLM | 再現性・モデル品質が重要 | データ、評価、GPU資源 |
| 10. バッチ/ETL/大規模処理 | 冪等性・性能が重要 | 再実行設計、IO性能 |
| 11. フレームワーク/DSL | 通常と違う制約 | ライフサイクル、依存関係 |
| 12. IaC / インフラ構成 | 実行基盤そのもの | 権限、破壊的変更、Pin |
必要なら、
「12項目すべてのレビュー観点チェックリスト」
も作成できます。
作成しますか？
はい。
以下に 12分類すべてを対象とした
「包括的 Code Review チェックリスト（約120項目）」 をまとめました。
そのまま社内規約・教育資料として利用できるレベルの網羅性を目指しています。
✅ 総合 Code Review チェックリスト（12分類・約120項目）
## 0. 全プログラム共通チェックリスト（必須）
◎ コード品質
- 命名は意味的で一貫しているか
- コメントは必要十分で、不要コメントが残っていないか
- 関数・クラスの責務が単一か
- 複雑度（Cyclomatic Complexity）が許容範囲か
- Magic Number の除去
- 重複コードの削減（DRY原則）
◎ バグ防止
- Null/None/未定義の扱い
- 例外処理が適切に行われているか
- ログの粒度が適切（多すぎず少なすぎず）
- 入出力の境界チェック
## 1. インタプリタ系（Python, Ruby, JS など）
- 実行時エラーが事前に検出できるようなテストがあるか
- 動的型を使う部分の意図が明確か
- 型ヒント(TypeHint)が定義されているか
- 依存パッケージのバージョン固定（requirements.txt / Pipenv など）
## 2. コンパイル系プログラム（C/C++/Rust/Fortran など）
- 未初期化変数のチェック
- 未使用コード/警告（warning）ゼロ化
- 静的解析（clang-tidy, cppcheck）を通しているか
- メモリ管理（malloc/new の対応 free/delete）が正しいか
- コピーとムーブセマンティクスの扱い（C++）
## 3. 通信・分散システム（プロトコル・API・ネットワーク）
- 入出力のプロトコル仕様に準拠しているか
- タイムアウトが適切に設定されているか
- 再送・再接続ロジック
- ネットワーク断の例外処理
- 並行呼び出しでデッドロックが起きないか
- 非同期処理（async/await, Promise, Future）設計の妥当性
## 4. PC以外の機器上（組込みソフト・ファームウェア）
- EEPROM/Flash 書き込み回数の制限を考慮
- 割込み処理の競合防止
- スタック・ヒープのメモリ上限を見積もっているか
- ハードウェア依存部分(HAL/Driver)とアプリ部分の分離
- 初期化処理の順序（電源ON, センサ初期化など）
## 5. Safety-Critical（車載・医療・産業など）
- 危険要因（Hazard）に対応する安全要求がコードに反映されているか
- MISRA / CERT / IEC などの安全規格に準拠
- 防御的プログラミングができているか
- フェイルセーフ動作が定義されているか
- ウォッチドッグタイマの利用
- 不正状態を検知した際の復帰処理
## 6. リアルタイム処理（Hard/Soft RT）
- Worst Case Execution Time の見積もり
- 割込み優先度の設計
- 優先度逆転への対策（プライオリティ継承）
- 動的メモリ割り当てを避けているか（GCの有無を確認）
- スケジューラが想定通り動く設計
## 7. 高可用・冗長化システム（HA / FT）
- 障害時のフェイルオーバ動作
- State を持つ場合、同期方法は？
- DB接続の再試行ロジック
- サーキットブレーカーパターンの採用
- ログローテーション・メトリクス監視
## 8. セキュリティクリティカル（暗号・認証系）
- 入力バリデーションが徹底されているか
- 秘密鍵・パスワード・トークンは安全に管理
- 暗号アルゴリズムを自前実装していないか（使うのはライブラリ）
- エラー時に内部情報を漏洩しないか
- SQL/コマンドインジェクションの防止
- CSRF/XSS/SSRF 防止対策
## 9. AI/ML/LLM 系（推論・学習・パイプライン）
- データ前処理の再現性（random seed 固定）
- モデル更新時の互換性検証
- モデルサイズとメモリ使用量
- 推論遅延の計測
- 入力データの分布が訓練と一致しているか
- GPU資源の解放・メモリリーク対策
- データリークやラベル漏洩のチェック
## 10. バッチ・ETL・大規模データ処理
- 冪等性の確保（再実行で壊れない）
- 部分失敗時のリトライ方法
- 入力が大きくなった場合の処理性能検証
- 外部IO（DB, S3, NFS）のボトルネック対策
- 並列処理（マップ/Reduce）の適切性
- タイムウィンドウ、境界条件（23:59:59 → 次日処理）
## 11. フレームワーク/DSL（Simulink, LabVIEW, Unity, Vue 他）
- 特有のライフサイクル（Start/Update/Destroyなど）理解
- プラットフォーム依存部分の排除
- GUI / graph / model の構造が整理されているか
- オブジェクト数・ノード数の過剰増加がないか
- 設定ファイル（yaml, scene, model）が正当な値か
## 12. IaC / インフラ構成コード（Terraform, K8s YAML, Dockerfile）
- 権限（IAM、RBAC）が最小権限か
- バージョン固定（Provider、Image tag）
- 破壊的変更（destroy）の危険性がないか
- ネットワークリソース（SG, VPC, Firewall）の境界チェック
- Secrets が平文で埋め込まれていないか
- Pod / Container のリソース制限（limits/requests）
## ✔ 付録：分類 × 利用用途 のマッピング表
どの分類を優先して使うか一目で分かります。
| 分類 | 典型用途 | 重要度 |
|---|---|---|
| 1〜2 | 単体アプリ、ツール | 中 |
| 3 | 通信・API・分散 | 高 |
| 4 | 組込み | 高 |
| 5 | Safety | 最重要 |
| 6 | RT | 高 |
| 7 | 高可用 | 最重要（サービス） |
| 8 | セキュリティ | 最重要 |
| 9 | AI/ML | 中〜高 |
| 10 | バッチ | 高 |
| 11 | DSL/フレームワーク | 中 |
| 12 | IaC | 最重要（運用） |
✔ 必要なら
・上記120項目の Excel版チェックリスト（.xlsx）
・Qiita記事向け Markdown版
・PlantUMLの分類図
も作成します。
どれを作成しましょうか？
PlantUMLの分類図
以下に PlantUML で描ける Code Review 分類図 をご用意しました。
そのままコピペで動作します。
（分類12種類＋共通要素を階層的に整理した図です）🌱 PlantUML：Code Review 分類図（12分類）
📌 図の意図
-
Common（共通チェック） を中心に、
全12カテゴリへ派生する構造を示しています。 - 組込み（4）→Safety（5）、組込み（4）→RT（6）
などの階層関係も反映しています。 - ネットワーク（3）→高可用（7）も別カテゴリとして連結。
必要でしたら、以下のバリエーションも作れます： - ✔ 横長/縦長レイアウト
- ✔ チェック項目つきの詳細版
- ✔ 分類ごとのアイコン入り図
- ✔ Qiita向け ASCII Art版
- ✔ Markdown + PlantUML 図セット
どれを作成しましょうか？
学び
CodeReviewを開発目標に照らして行うことを記述していなかったた。
ChatGPTの指摘は開発目標を含むものであった。
開発目標
- 安全関連系（セキュリティ含む）
- 安全関連系（クラウドと連携）
- 安全関連系ではないリアルタイム系(ゲームを除く）
- 安全関連系ではないリアルタイム系（ゲーム）
- 安全関連系ではないセキュリティ（サーバ）
- 安全関連系ではないセキュリティ（クライアント）
- 稼働中に動的書き換えする可能性があるプログラム
Reviewの時期
-
コンパイルエラー、チェッカのエラーが出て、どこを直すかを決定する設計審査
-
ビルドした結果、時間が遅いか、ソフトが大きくて、どこを直すかを決定する設計審査
-
時間、空間を含め、予定した試験を通過し、今後、どういう改良を食らえるかの設計審査
-
出荷前に、これで出荷してもよいかを決める出荷審査
手順
1 Beautifierで、決めた整形をする。（コンパイルエラーがあるときも）
2 静的試験ツールでコーディングルールの検査を含めて実施し、その結果をつける。
3 試験で使ったデータまたは試験プログラムつけ、実演できるようにしておく。（エラーが出ている場合を除く）
4 Githubなどの共通で見えるところに起き、作者としての Issueを３つ以上あげておく。
5 Review期間は原則１習慣、緊急時は１日。
6 会合を開くかは、作者、事業責任者、出荷責任者のうち一人が申し立てれば行う。