pr-review

セキュアな PR レビュー

出力言語：すべてのレビュー報告を日本語で出力します。

コード変更をレビューする際は、以下のワークフローに従ってください。優先順位は セキュリティ > 正確性 > アーキテクチャ > パフォーマンス です。

レビュー範囲（ベースブランチ）

• レビュー範囲：x をベース（main）ブランチとして扱います。常に現在のブランチ（HEAD）と x の差分（つまり、このブランチで x に対して加えられた変更）として PR をレビューします。
• 差分の生成には PR のセマンティクスを使用します。git fetch origin && git diff origin/x...HEAD（3 点ドット）を実行し、このブランチで x に対して加えられた変更のみをレビューします。

0）変更範囲の把握とファイル構成の分析

• 変更された内容（ファイル、モジュール、エントリーポイント、ルート／画面）を特定します。
• リスク領域（認証フロー、署名／鍵、ネットワーク、分析、ストレージ、依存関係の更新）を特定します。

0.1 ファイル変更一覧（必須）

以下の形式で、変更されたすべてのファイルの構造化された概要を作成します。

## PR File Structure Analysis

### Changed Files Summary
| File | Change Type | Category | Risk Level | Description |
|------|-------------|----------|------------|-------------|
| `path/to/file.ts` | Added/Modified/Deleted | UI/Logic/API/Config/Test | Low/Medium/High | Brief description |

### Files by Category

#### 🔐 Security-Critical Files
- Files touching auth, crypto, keys, secrets

#### 🌐 API/Network Files
- Files with network requests, API calls

#### 🧩 Business Logic Files
- Core logic, state management, services

#### 🎨 UI Component Files
- React components, styles, layouts

#### ⚙️ Configuration Files
- package.json, configs, manifests

#### 🧪 Test Files
- Unit tests, integration tests

#### 📦 Dependency Changes
- package.json, lockfile changes

0.2 ファイルごとの分析（必須）

変更された各ファイルについて、以下を提示します。

### `path/to/file.ts`
**Change Type**: Added | Modified | Deleted
**Lines Changed**: +XX / -YY
**Category**: UI | Logic | API | Config | Test
**Risk Level**: Low | Medium | High | Critical

**What This File Does**:
- Primary responsibility of this file

**Changes Made**:
1. Specific change 1
2. Specific change 2
3. ...

**Dependencies**:
- Imports from: [list key imports]
- Exported to: [list files that import this]

**Security Considerations**:
- Any security-relevant aspects

**Cross-Platform Impact**:
- [ ] Extension
- [ ] Mobile (iOS/Android)
- [ ] Desktop
- [ ] Web

1）シークレット／PII／プライバシー（必須）

• ログ／テレメトリー／エラーレポートに次の情報を含めないでください。ニーモニック／シードフレーズ、秘密鍵、署名ペイロード、API キー、トークン、Cookie、セッション ID、個人を特定できるアドレス、その他の PII。
• すべての「外部流出経路」を調査します。console.*、ロギングユーティリティ、分析 SDK、エラーレポート、ネットワークリクエスト、永続化領域：
  • Web：localStorage／IndexedDB
  • RN：AsyncStorage／セキュアストレージ
  • デスクトップ：ファイルシステム／キーチェーン／sqlite
• 潜在的な漏えいが見つかった場合は、次の内容を明記します。
  • ソース（どの機密データか）
  • シンク（どこに送られるか）
  • トリガー（いつ発生するか）
  • 影響（誰／何が漏えいするか）
  • 修正（具体的な是正策）

2）認証／認可（必須）

• すべての保護対象ルートが認証ミドルウェア／ガードで保護され、回避できないことを確認します。
• 認可チェック（ロール／権限）が正確かつ一貫していることを確認します。
• サーバー／クライアント間の信頼境界を確認します。認可の判断にクライアント入力を決して信用しないでください。

3）依存関係とサプライチェーンのセキュリティ（最優先）

package.json／ロックファイルが変更された場合は、以下をすべて実施する必要があります。

3.1 変更内容の列挙

• 追加／更新／削除された依存関係をすべて、名前 + 変更前→変更後のバージョンと、理由（PR に記載がある場合）とともに列挙します。

3.2 エコシステムのリスクを迅速に確認（承認前）

• 変更されたパッケージごとに、以下を確認します。
  • 最近のメンテナー／所有者の変更、不審なリリース頻度、既知のアドバイザリ／CVE、タイポスクワッティングのリスク。
  • 実行環境で利用できる場合は、npm view <pkg> time maintainers repository dist.tarball などのコマンドを実行します。

3.3 ソースコードの調査（node_modules）— リスクが無視できない場合は必須

• 依存関係の node_modules/<pkg>/package.json とエントリーポイント（main／module／exports）を調査します。
• 高リスクな動作の例を検索します（必要に応じて対象を追加してください）。
  • 外部通信／ネットワーク：fetch(、axios、XMLHttpRequest、http、https、ws、request、net、dns
  • 動的実行：eval、new Function、動的な require、リモートスクリプトの読み込み
  • インストール時のフック：postinstall、preinstall、install、バイナリのダウンロード
  • 特権アクセス：ファイルシステム、クリップボード、キーチェーン／キーストア、環境変数
• 以下は高リスクとして扱い、妥当な理由があり、かつ分離されていない限り承認をブロックします。
  • テレメトリー／リモート設定の取得／予期しない外部リクエスト
  • 動的実行やインストール時のスクリプト動作
  • 機密ストレージまたはウォレット関連データへのアクセス

3.4 React Native ネイティブ層の検査 (RN ライブラリでは必須)

• React Native の依存関係 (またはネイティブバインディングを持つパッケージ全般: .podspec、ios/、android/、react-native.config.js、TurboModules/Fabric) について:
  • iOS/Android のネイティブソースをセキュリティとパフォーマンスの観点で検査します。
  • 予期しない外向きリクエストが存在しないこと、明示的な製品意図のないテレメトリ/アップロードが存在しないこと、ウォレットのシークレット/秘密鍵/シードデータへのアクセスが存在しないことを確認します。
  • 必要であれば、サードパーティのネイティブ依存関係を詳しく調査します:
    • iOS: CocoaPods / Pods/ のソース、ベンダリングされたフレームワーク、ビルドスクリプト
    • Android: Gradle/Maven アーティファクト、JNI/ネイティブライブラリ、ビルド時タスク
  • 隠れたネットワーク動作、動的ローディング、インストール/ビルドスクリプト、または難読化されたネイティブコードは、明示的に正当化され分離されていない限り、高リスクとして扱います。

4) node_modules が外向きリクエストを行う場合の必須の指摘

node_modules のコードが (直接的または間接的に) あらゆる外向きネットワーク/API リクエストを行う場合、レビュー内で明確に指摘してください:

• 正確な呼び出し箇所 (ファイルパス + 関数)
• 送信先 (完全な URL/ホスト)
• ペイロードのフィールド (どのようなデータが送信されるか)
• ヘッダー/認証 (トークン/クッキー/識別子)
• トリガー条件 (いつ/どのように実行されるか)
• クロスプラットフォームへの影響 (拡張機能/モバイル/デスクトップ/web)

4.1 拡張機能マニフェストの権限変更 (最優先)

• manifest.json (permissions、host_permissions、optional_permissions) が変更された場合:
  • レビューの最上位項目として目立つ形で指摘します。
  • 追加/削除された権限を列挙し、それらが有効にする新しい機能を説明します。
  • 最小権限の原則を評価します: その権限が厳密に必要であり、最小限のホストにスコープされ、データアクセス/持ち出し経路を広げていないことを確認します。
  • 権限変更によって生じるデータ露出面 (ネットワーク、ストレージ、メッセージング、コンテンツスクリプト、バックグラウンド/サービスワーカー) を再確認します。

5) クロスプラットフォームアーキテクチャレビュー (拡張機能/モバイル/デスクトップ/web)

シニアなマルチプラットフォームアーキテクトとして実装をレビューします:

• そのアプローチは、保守性/テスト容易性に優れた最もシンプルな正しい解決策ですか?
• プラットフォーム固有の落とし穴を特定します:
  • 拡張機能の制約 (MV3/サービスワーカーのライフタイム、権限、CSP)
  • RN の制約 (WebView、ネイティブモジュール、バックグラウンド化)
  • デスクトップ (Electron のセキュリティ境界、IPC、nodeIntegration)
  • Web (CORS、ストレージ、XSS、バンドルサイズ、ランタイムの違い)
• 最適でない場合は、トレードオフとともに、より良い代替案を提案します。

6) React パフォーマンス (フック + 再レンダリングのホットスポット)

新規/変更されたコンポーネントについて:

• 不安定な参照による不要な再レンダリングがないか確認します:
  • 子に渡されるインラインのオブジェクト/関数
  • 誤ったフックの依存配列
  • 状態が高すぎる位置に置かれ、広範な再レンダリングの連鎖を引き起こしている
• メモ化戦略 (memo、useMemo、useCallback) が正しいか (古いクロージャ/壊れた依存関係がないか) 検証します。
• レンダー内の高コストな処理、リストレンダリングの問題、サブスクリプション/リスナーのクリーンアップ漏れに注意します。
• 新たな親子境界にはより厳格な精査を適用し、再レンダリングのホットスポットになりそうな箇所を指摘します。

7) レビュー出力フォーマット (実行可能な形に保つ)

• セキュリティ/正確性/アーキテクチャ/パフォーマンスに焦点を当てます。
• 実際のバグ、セキュリティリスク、または測定可能なパフォーマンス低下を引き起こさない限り、UI スタイルやコメントの些末な指摘は避けます。
• 指摘事項は次の形式で提供します:
  • ブロッカー (修正必須)
  • 高リスク (強く推奨)
  • 提案 (あると望ましい)
  • 質問 (確認が必要)

追加リソース

• 依存関係の監査: reference/dependency-audit.md
• React パフォーマンス: reference/react-performance.md
• クロスプラットフォームチェック: reference/cross-platform.md
• ファイル分析パターン: reference/file-analysis.md

8) アーキテクチャの可視化（必須）

PR によるアーキテクチャへの影響を示す ASCII 図を生成します。ASCII 図はターミナルで表示でき、外部ツールは必要ありません。

8.1 ファイル依存関係グラフ

変更したファイル同士の関係を示します。

┌─────────────────────┐     ┌─────────────────────┐
│   package.json      │────▶│     yarn.lock       │
└─────────────────────┘     └─────────────────────┘
          │
          ▼
┌─────────────────────┐     ┌─────────────────────┐
│   native patch      │────▶│   iOS/Android code  │
└─────────────────────┘     └─────────────────────┘

8.2 データフロー図

データ処理を伴う PR の場合：

User Input ──▶ Validation ──▶ Business Logic ──▶ API Call
                                                    │
              UI Render ◀── State Update ◀──────────┘

8.3 コンポーネント階層

UI の変更の場合、コンポーネント間の関係を示します。

ParentComponent
├── ChildA (props: data, onSubmit)
│   ├── GrandchildA1
│   └── GrandchildA2
└── ChildB (props: config)
    └── GrandchildB1

8.4 状態フロー

状態に関連する変更の場合：

[*] ──▶ Idle ──fetchData()──▶ Loading
                                 │
         ┌───────────────────────┼───────────────────────┐
         │                       │                       │
         ▼                       ▼                       │
      Success ──reset()──▶    Error ──retry()────────────┘
         │                       │
         └───────dismiss()───────┘
                    │
                    ▼
                  Idle

8.5 シーケンス図

非同期処理の場合：

User          Component        Service           API
  │               │               │               │
  │──click()─────▶│               │               │
  │               │──callSvc()───▶│               │
  │               │               │──POST /api───▶│
  │               │               │◀──response────│
  │               │◀──result──────│               │
  │◀──update UI───│               │               │

8.6 クロスプラットフォームへの影響

影響を受けるプラットフォームを示します。

Changed Code: packages/shared/src/sentry/basicOptions.ts

Platform Impact:
┌───────────┬───────────┬───────────┬───────────┐
│ Extension │  Mobile   │  Desktop  │    Web    │
├───────────┼───────────┼───────────┼───────────┤
│     ✓     │     ✓     │     ✓     │     ✓     │
└───────────┴───────────┴───────────┴───────────┘

Risk Level:  [HIGH]      [HIGH]      [MEDIUM]    [LOW]

図のガイドライン

1. 重要な PR では、必ず 2 つ以上の図を生成します：

   • ファイル依存関係グラフ（必須）
   • ドメイン固有の図を 1 つ（データフロー／コンポーネント階層／状態／シーケンス）

2. ボックス描画文字を使用します：

   • ボックスと表には ┌ ┐ └ ┘ │ ─ ├ ┤ ┬ ┴ ┼ を使用します
   • 矢印には ▶ ◀ ▲ ▼ を使用します
   • 状態インジケーターには ✓ ✗ を使用します

3. リスク領域を強調します：

   • [HIGH] [MEDIUM] [LOW] のラベルを使用します
   • セキュリティ上重要な経路には 🔐 または ⚠️ を付けます

4. 図の範囲を絞ります：

   • 図ごとのノード数は最大 10～15 個にします
   • 複雑なフローは複数の図に分割します