生成AI時代のアプリケーションのレビュー観点

ページについて

• 生成AIが苦手とする、プロジェクトや現場特有の観点を『ハイコンテキストな観点』とする。
• 生成AIでも比較的適切に判断・生成可能な汎用的の観点を『ローコンテキストな観点』とする。

バックエンド用

ハイコンテキストな観点

▼ 仕様・要件との整合性

• [ ] API設計が仕様書と正確に一致しているか？

  • エンドポイントのパス、HTTPメソッド、リクエストとレスポンスのJSON構造が設計通り。
  • パラメータの必須・オプションが正しく反映されている。
  • エラー時のレスポンスボディが仕様どおりの形式を保っている。

• [ ] 異常系のステータスコードやエラーメッセージが適切に設計されているか？

  • 認証エラー時に401、アクセス権限エラー時に403が返される。
  • バリデーションエラーは400で、エラー詳細がメッセージとして含まれる。
  • サーバエラーは500系のコードで適切に示される。

• [ ] データの永続化処理やトランザクション制御が仕様を満たしているか？

  • 途中でエラーが発生した場合、トランザクションがロールバックされる。
  • 更新・削除操作で整合性が崩れないよう排他制御が考慮されている。
  • データベース上に意図したデータ型やスキーマで記録される。

• [ ] 非機能要件（処理性能、応答時間、スループット、耐障害性）が明確に反映されているか？

  • APIレスポンスが要件で定められた時間以内に完了する。
  • 想定される最大同時接続数やスループットを満たせる。
  • 外部依存サービス障害時にもシステムが適切に対応できる仕組みがある。

▼ プロジェクト文脈との整合性

• [ ] DBスキーマやORM設定が既存構造と一貫しているか？

  • テーブル名・カラム名が既存の命名規約に従っている。
  • ORMの設定が既存コードと統一されている。
  • DBマイグレーション方法が既存プロジェクトと一貫している。

• [ ] ドメインロジックが既存の共通処理と重複していないか？

  • 既存ユーティリティクラスや共通関数を活用している。
  • 似た処理が新たに作られておらず、重複がないことを確認する。
  • ロジックが適切なレイヤーに配置されている。

• [ ] ディレクトリ構造やディレクトリ間の依存方向がアーキテクチャ規約に合っているか？

  • MVCやクリーンアーキテクチャなど、決められた設計方針に従っている。
  • ファイル配置がアーキテクチャのルールに沿っている。
  • 新規機能追加時に規約に反するディレクトリが作られていない。

• [ ] ファイル命名が実装規約に合っているか？

  • ファイル名がスネークケースやキャメルケースなど、指定された規約を守っている。
  • 命名に関する用語や略称の使い方が統一されている。
  • テストファイルの命名規則が守られている。

• [ ] 使用している組み込み機能がプロジェクトの規約に合致しているか

  • 同じような定義や処理が複数の組み込み機能で実装できる場合に、プロジェクトの規約に従っている。

▼ セキュリティと堅牢性

• [ ] 認証・認可・JWTの扱いが安全か？

  • JWTの署名が正しく検証され、有効期限のチェックもある。
  • 認可処理で権限が適切に制御されている。
  • トークン漏洩時のリスクが軽減されている設計か。

• [ ] SQLインジェクション、リクエストフォージェリ等への対策が十分か？

  • ORMを用いるか、パラメータ化クエリが適切に使われている。
  • CSRFトークンがフォームに含まれている。
  • 入力値に対するサニタイズ処理が行われている。

• [ ] 機密情報（パスワード・トークン）が漏洩しないよう配慮されているか？

  • 環境変数など安全なストレージから取得している。
  • 誤ってリポジトリにコミットされない設定がある。
  • 機密データが平文でDBに保存されていない。

• [ ] 機密情報をログに出力しないよう配慮されているか？

  • ログにユーザーパスワードやアクセストークンを記録していない。
  • エラー時のスタックトレースにも機密情報がないことを確認する。

▼ エラーハンドリングと障害時対応

• [ ] 外部サービス・DB接続障害時に安全に処理を停止または回復するか？

  • リトライ処理やフェイルオーバーが適切に組み込まれている。
  • サービス停止時には適切なエラーメッセージが返される。

• [ ] 意図的な例外発生により異常系テストが行われているか？

  • 手動やテストコードで、強制的に例外を発生させて挙動を確認したログがある。
  • エラーハンドリングコードが正常に動作していることを確認。

• [ ] 非同期処理やジョブが適切に再試行されるか？

  • リトライの回数や間隔が適切に設計されている。
  • リトライがログや監視で確認可能。

• [ ] 信頼性パターンが導入されているか？

  • サーキットブレーカー
  • レートリミット
  • リトライ
  • タイムアウト

▼ ロギングと監視の配慮

• [ ] 重要な処理（認証・決済など）に適切なログがあるか？

  • 処理の開始、成功、失敗を記録。
  • ログからトラブルシューティングが可能。

• [ ] ログは監視ツールと連携可能か？

  • PrometheusやDatadogなどにログを転送できる仕組みがある。
  • モニタリング用メトリクスが適切に定義されている。

• [ ] ログの機密情報マスク処理が実装されているか？

  • パスワードや個人情報がログに記録される際にマスクされる。

▼ ハードコーディングの回避

• [ ] DB接続文字列や外部APIのURLが環境変数化されているか？

  • .envファイルや環境変数から読み込む仕組みを利用。

▼ 国際化と環境差異への対応

• [ ] サーバータイムゾーンや日付フォーマットが環境によって影響を受けない設計か？

  • 日付処理にUTCなど一貫したタイムゾーンを使用。

ロウコンテキストな観点

▼ 処理の分割と構造化

• [ ] ビジネスロジック、データアクセス、HTTPルーティングが適切に分離されているか？

  • HTTPハンドラーにデータベースアクセスやロジックが直接書かれていない。
  • ロジックが適切なサービスクラスやリポジトリに配置されている。
  • コードの責務が明確に分離されている。

• [ ] Fat ControllerやFat Serviceが発生していないか？

  • クラスやメソッドが特定の処理だけを担当し、肥大化していない。
  • 一つの関数が複数の責務を担っていない。

• [ ] 関数が適切に単一責務原則（SRP）を遵守しているか？

  • 各関数が1つの機能・処理に特化している。
  • 複数の目的のために分岐処理が多く入っていない。

• [ ] 多重ネスト構造や深すぎるif文が排除されているか？

  • 条件文が深くネストされず、早期リターンが活用されている。
  • 読みやすさを保つために関数を分割している。

▼ パフォーマンスとスケーラビリティ

• [ ] クエリに適切なインデックスが貼られているか？

  • WHERE句やJOINのキーにインデックスが存在する。
  • 実行計画でフルテーブルスキャンが発生していない。

• [ ] ループ内で不要なI/OやDBアクセスがないか？

  • ループ内でのDBアクセスを一括処理にまとめている。
  • 無駄なファイルアクセスが避けられている。

▼ テスト容易性と検証性

• [ ] APIの単体テスト・統合テストが存在し、異常系を含め十分網羅されているか？

  • 正常系・異常系それぞれのテストが整備されている。
  • エラー発生時の挙動を確認するテストケースがある。

▼ データ型と型安全性

• [ ] 型定義が明確であり、曖昧な型が排除されているか？

  • 明示的な型が定義され、any型や曖昧な型がない。
  • 型定義がモデルやインターフェースとして共通化されている。

• [ ] 静的型付けによる検証が行われているか？

  • コンパイル時や静的解析で型チェックがされる。
  • IDEの型ヒントが正常に表示される。

▼ ライセンスと依存管理

• [ ] 依存ライブラリにライセンス上の問題がないか？

  • 使用ライブラリがプロジェクトのライセンス規約に違反していない。

フロントエンド用

ハイコンテキストな観点

▼ 仕様・要件との整合性

• [ ] UI/UXがデザイン仕様を正確に再現しているか？

  • 指定のカラーコードやフォント、余白が一致している。
  • 各コンポーネントが仕様通り動作する。
  • レスポンシブデザインが適切に動作している。

• [ ] エラーメッセージ・バリデーション表示が適切に設計されているか？

  • 入力項目に対し即時のエラーフィードバックがある。
  • エラー内容が具体的かつ分かりやすいメッセージである。

• [ ] エッジケースの表示崩れ・レスポンシブ対応がされているか？

  • 極端に長い文字列や空データでもUIが崩れない。
  • モバイルやタブレット表示で不自然なレイアウトにならない。

• [ ] アクセシビリティがデザイン仕様通りに考慮されているか？

  • aria属性が適切に付与され、スクリーンリーダーに対応。
  • キーボードのみで操作が完結する。

▼ プロジェクト文脈との整合性

• [ ] コンポーネント設計・CSS構成がプロジェクトのスタイルガイドに合っているか？

  • CSSクラスの名前がBEM命名やプロジェクト規約に従っている。
  • コンポーネントが適切に細分化されている。

• [ ] UIライブラリやユーティリティが適切に再利用されているか？

  • 共通コンポーネントやユーティリティが再利用されている。
  • 不要な独自コンポーネントが作成されていない。

• [ ] コンポーネントやページ単位で明確にディレクトリが整理されているか？

  • ページやコンポーネントごとにディレクトリが整理されている。

▼ セキュリティと堅牢性

• [ ] XSSやCSRFへの基本的な防御がされているか？

  • ユーザー入力が適切にエスケープ・サニタイズされている。

• [ ] クライアント側で機密情報を保持しないよう配慮されているか？

  • JWTやパスワードがLocalStorageに直接保存されていない。

• [ ] フォーム入力の検証・サニタイズが行われているか？

  • ユーザー入力値に対し適切なバリデーションが実施されている。

• [ ] サードパーティスクリプトや外部ライブラリ導入でセキュリティリスクがないか？

  • 脆弱性が報告されているライブラリが使われていない。

▼ エラーハンドリングと障害時対応

• [ ] API呼び出し失敗時にユーザーへ適切にフィードバックされているか？

  • 通信エラー時にエラーメッセージが表示される。

• [ ] 意図的なエラー発生で障害時の表示をテストしているか？

  • エラーを手動で発生させた場合の表示を確認している。

▼ ロギングと監視の配慮

• [ ] クライアントエラーが適切にログ収集されているか？

  • Sentryなどのエラー監視ツールへエラー情報が送信されている。

▼ 国際化と環境差異への対応

• [ ] 表示テキストがハードコードされず、i18n対応されているか？

  • テキストが国際化対応の仕組みを利用して表示される。

▼ ハードコーディングの回避

• [ ] APIのURLや画像リソースパスが環境設定から取得されているか？

  • 開発環境、ステージング環境、本番環境ごとに設定値が分離されている。

ロウコンテキストな観点

▼ 処理の分割と構造化

• [ ] コンポーネントがシンプルで再利用可能な単位に分割されているか？

  • ボタン、入力フォーム、カードなどが独立した再利用可能なコンポーネントになっている。
  • 一つのコンポーネントが複数の異なる責務を持っていない。

• [ ] コンポーネント内に多責務な処理が集中していないか？

  • 状態管理、イベント処理、表示ロジックが分離されている。
  • 複雑なコンポーネントは複数のサブコンポーネントに分割されている。

▼ 冗長・不自然なコードの排除

• [ ] 未使用のstate, props, importが存在しないか？

  • 未使用のインポート文が残っていない。
  • 未使用のstateやpropsが削除されている。

• [ ] 無駄な再レンダリングが発生していないか？

  • React.memoやuseCallback、useMemoなどの最適化が適切に使われている。
  • コンポーネントの再レンダリングが開発者ツールで確認されている。

• [ ] コンポーネント内で過剰なstate管理や不必要なレンダリング制御がないか？

  • 必要最低限の状態のみを管理している。
  • 状態が複雑に絡み合っていない。

▼ パフォーマンスとスケーラビリティ

• [ ] 非効率なDOM操作・レンダリングが回避されているか？

  • 頻繁なDOM操作が仮想DOMを通して最適化されている。
  • DOMへの直接アクセスが最小限に抑えられている。

• [ ] リソース（画像・フォント）の最適化がされているか？

  • 画像が圧縮・最適化されている。
  • フォントが遅延読み込みやプリロードされている。

• [ ] 非同期処理やデータフェッチにおいてキャッシュ戦略が適切に設定されているか？

  • APIレスポンスが適切にキャッシュされ、再フェッチが制限されている。
  • SWRやReact Queryなどのキャッシュライブラリが適切に使われている。

• [ ] 静的アセットの適切なキャッシュコントロールヘッダーが設定されているか？

  • CSSやJSなど静的ファイルに適切なキャッシュ期間が設定されている。

▼ テスト容易性と検証性

• [ ] コンポーネント単位で単体テストが整備されているか？

  • JestやReact Testing Libraryでコンポーネントの挙動がテストされている。
  • propsやstate変化に応じたレンダリング結果を確認するテストケースがある。

• [ ] UIのE2Eテスト（Cypress, Playwrightなど）が存在するか？

  • 実際のブラウザ操作を伴うE2Eテストが作成されている。
  • 主要なユーザー操作シナリオがテストされている。

• [ ] コンポーネントのpropsやstateの初期値・境界値を考慮したテストケースが設定されているか？

  • propsの境界値や極端な値でレンダリング確認がされている。
  • stateの初期値や例外ケースをテストしている。

▼ データ型と型安全性

• [ ] Propsやstateに明確な型定義がされているか？

  • TypeScriptのインターフェースや型エイリアスでpropsが定義されている。
  • stateに対して型が明示され、型エラーがない。

• [ ] 型定義が共通化され再利用されているか？

  • 共通利用される型がプロジェクト全体で共有されている。
  • 重複する型定義が存在しない。

▼ ライセンスと依存管理

• [ ] 外部ライブラリの依存管理が適切でライセンス問題がないか？

  • npmやyarnの依存関係が適切に管理されている。
  • OSSライブラリがプロジェクトのライセンス規約に合致している。