ai-generated-business-code-review

AI ビジネスコードレビュー

概要

AI が生成したビジネス／アプリケーションコードについて、正確性、堅牢性、保守性、パフォーマンス、セキュリティをレビューします。0〜10 のスコア、リスクレベル、必須修正チェックリストを出力します。C++ コードでは、必須：openharmony-cpp と openharmony-security-review を必須の制約として適用してください。

使用する場面

• AI 生成のビジネス／アプリコードのレビューや品質評価
• スコア、リスクレベル、必須修正チェックリストが必要な場合
• C++ のビジネスコードが OpenHarmony のコーディング／セキュリティ要件を満たす必要がある場合

ワークフロー

1. 言語とコードの種類（ビジネスコードかテストコードか）を特定します。テストコードの場合は、代わりに ai-generated-ut-code-review を使用します。
2. C++ の場合：openharmony-cpp と openharmony-security-review を読み込み、必須の制約として適用します。
3. 要件に対する動作、エッジケース、エラー処理、リソース管理、セキュリティを確認します。
4. 評価基準に基づいて採点し、リスクレベルを割り当て、具体的な根拠（ファイル／行またはコードスニペット）とともに必須修正項目を列挙します。

スコア（0〜10）

各評価項目は0〜2点です。合計が総合スコアになります。

評価項目	0	1	2
正確性	重要な動作が誤っている／欠けている	一部のみ対応／前提に依存	要件を満たしている
堅牢性	クラッシュ／リーク／未確認のエラー	エッジケースへの対応が一部ある	エッジケース／エラーに適切に対応
保守性	読みにくい／変更しにくい	品質にばらつきがある	構造と命名が明確
パフォーマンス	頻繁に実行される処理が非効率	許容範囲だが改善可能	想定負荷に対して効率的
セキュリティ	明らかな脆弱性がある	検証が不十分／安全でない	デフォルトで安全で、検証済み

リスクレベル

• Blocker：セキュリティの脆弱性、重大な論理エラー、または C++ の必須規範への違反
• High：重要な処理の欠落、不完全な例外処理、明らかなリソースリーク
• Medium：保守性またはパフォーマンスに重大なリスクがある
• Low：軽微な問題、またはスタイルの一貫性に関する問題

必須修正チェックリスト

• 外部入力に対する明確な検証とエラーフィードバックがある
• 重要な例外経路に到達でき、その状況を把握できる（ログ／エラーコード／例外）
• リソースの解放または RAII による保証がある（C++）
• C++ の場合、openharmony-cpp と openharmony-security-review の要件を満たしている

AI 生成コードでよくある落とし穴（明示的に確認）

• 要件の誤解、誤った暗黙の前提
• 正常系のみを対象とし、例外／境界ケースを無視している
• 例外を握りつぶす、または不適切なデフォルト値を使用する
• コピー＆ペーストによる重複や不整合
• 過度な複雑化、または誤った抽象化

出力形式（必須、準固定）

• Score: x/10 — Correctness x, Robustness x, Maintainability x, Performance x, Security x
• Risk: Low/Medium/High/Blocker — リスクの理由を簡潔に記載（1 行）
• Must-fix:
  • [アクション + 根拠]
  • [アクション + 根拠]
• Key Evidence:
  • 具体的な関数／クラス／パスを引用（1〜2 件）
• Notes:
  • 最小限の修正案または代替案（1〜2 行）

ルール:

• C++ の場合、Key Evidence または Must-fix で openharmony-cpp／openharmony-security-review への違反箇所を明確に指摘すること
• 根拠を少なくとも2件示すこと。根拠が不十分な場合はその旨を説明し、スコアを下げること
• 総合評価だけを提示することは禁止

よくある間違い

• 根拠を示さず、総合評価だけを提示する
• C++ の必須規範を無視する
• スタイル上の問題をブロッカーリスクとして扱う

例（簡潔）

Score: 6/10 (Correctness 1, Robustness 1, Maintainability 1, Performance 1, Security 2) Risk: High Must-fix:

• createUser() の入力検証がない（null／空、長さ、形式）
• エラー経路で例外をログに記録せず握りつぶしている Key Evidence:
• createUser() は未加工の入力をチェックせずに受け入れている
• persistUser() の catch ブロックが空 Notes:
• 明示的な検証を追加し、構造化されたエラーを返します。