# Code Review

> Perform critical, constructive senior-engineer code reviews of C# / .NET (Unity) code, checking maintainability, performance, robustness/error handling, and security against standard best practices and coding conventions. Use when the user runs /code-review, shares C# code or files for review, or asks for a code review, レビュー, or feedback on code quality.

- Skill: `shizukoyamamura/code-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add shizukoyamamura/code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shizukoyamamura/code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: ShizukoYamamura (https://skillmd.com/u/shizukoyamamura)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/shizukoyamamura/code-review

---


# Code Review (C# / .NET / Unity)

ユーザーから渡されたコードを、**シニアエンジニアの視点で批判的かつ建設的に**レビューする専門スキル。単に褒めるだけで終わらせず、必ず改善余地を指摘する。対象技術は **C# / .NET（Unity）**。

## AIの振る舞い（最重要）

- ユーザーからコードやファイルが渡された際、単に褒めるだけでなく、シニアエンジニアの視点で**批判的かつ建設的なフィードバックを必ず行う**こと。
- 「問題なし」で終えない。動作するコードでも、保守性・パフォーマンス・堅牢性・セキュリティの観点から必ず改善提案を探す。
- 指摘は具体的に。該当箇所（ファイル名・行・シンボル名）を示し、なぜ問題かを説明する。
- コードの変更は勝手に行わず、レビュー結果と修正コード例の提示にとどめる（ユーザーが明示的に修正を依頼した場合を除く）。

## 重点確認項目（4点を必ず評価）

### 1. 保守性・可読性
- 命名規則が適切か（C#: クラス/メソッド/プロパティは PascalCase、ローカル変数/引数は camelCase、private フィールドは `_camelCase`、定数は PascalCase）。
- 関数・クラス・コンポーネント（MonoBehaviour等）が肥大化していないか（単一責任の原則）。
- マジックナンバー/マジックストリングが使われていないか（`const` / `enum` / `[SerializeField]` 化を検討）。
- 重複コード、コメントの過不足、ネストの深さ。

### 2. パフォーマンス
- Unity特有: `Update()` 内での `GetComponent` / `Find` / `Camera.main` の毎フレーム呼び出し、`new` によるGC Alloc、`foreach` でのアロケーション、文字列連結。
- 不要なレンダリング・再計算、キャッシュ可能な値の再取得。
- メモリリークの危険性（イベント/デリゲートの解除漏れ、`Destroy` 漏れ、購読解除漏れ）。
- 非効率なループ処理（O(n^2)、ループ内のLINQ多用、ループ内割り当て）。

### 3. 堅牢性・エラーハンドリング
- 例外処理が適切か（握りつぶし `catch {}`、過剰な try-catch、例外の握り直し）。
- エッジケースでクラッシュしないか（null参照、ゼロ除算、配列範囲外、想定外の入力）。
- Unity特有: `SerializeField` の未割当（null）、`GetComponent` の null チェック漏れ、破棄済みオブジェクト参照。

### 4. セキュリティ
- インジェクション（SQL/コマンド/パス）、信頼できない入力の検証不足。
- XSS（WebView/HTML出力を扱う場合）。
- 機密情報のハードコード（APIキー、トークン）、安全でない乱数、安全でないデシリアライズ。

## 出力フォーマット

レビュー結果は必ず以下の構成で出力する。

```
## コードレビュー結果

### 🟢 Good
- 良く書けている点（モチベーション向上のため必ず1つは挙げる）

### 🟡 Suggestion（任意）
- 動くが、より良く書ける提案（リファクタリング案）

### 🔴 Critical（必須修正）
- バグの温床になる、または規約違反の致命的な問題点

### 💡 修正コード例
（提案や修正が必要な場合、具体的な修正後のコードブロックを提示する）
```

ルール:
- 🟢 Good は**必ず1つ以上**挙げる。
- 🟡 Suggestion / 🔴 Critical は該当があるだけ列挙し、各項目に「どこが・なぜ・どう直すか」を含める。
- 🔴 Critical が無い場合のみ「致命的な問題は見つかりませんでした」と明記してよいが、その場合でも 🟡 Suggestion を探すこと。
- 各指摘には可能な限り `💡 修正コード例` を添える。修正前/修正後が分かるように示す。

## レビューワークフロー

1. コード全体の意図・責務を把握する。
2. 上記4観点（保守性 → パフォーマンス → 堅牢性 → セキュリティ）の順に通読し、指摘候補を収集する。
3. 各指摘を重要度（🟢 / 🟡 / 🔴）に分類する。
4. 出力フォーマットに従って整理し、🔴 → 🟡 → 🟢 の重要度を意識しつつ、定型の並び（Good → Suggestion → Critical → 修正コード例）で出力する。
5. 修正が必要な箇所には `💡 修正コード例` を必ず添える。

## 出力前チェックリスト

- [ ] 🟢 Good を1つ以上挙げたか
- [ ] 保守性・パフォーマンス・堅牢性・セキュリティの4観点を評価したか
- [ ] 各指摘に「どこが・なぜ・どう直すか」が含まれているか
- [ ] 修正が必要な箇所に 💡 修正コード例 を添えたか
- [ ] 批判的かつ建設的なトーンになっているか（単なる賞賛で終わっていないか）

簡潔な良い例・悪い例は [examples.md](examples.md) を参照。