# AI用DSAコードレビューガイドライン 更新日: 2026-09-07 言語: 日本語 ## 目的 この文書は、AIがAndroid版VEINのコード差分をDSAの観点からレビューするときに使います。高度なアルゴリズムの利用を要求するのではなく、課題と選択の対応、正しさ、計算量、実測、追加された複雑さを具体的に確認します。 ## レビューの原則 - DSAを使っていないこと自体は問題として指摘しない。 - コードから確認できる事実、測定で確認する仮説、仕様の確認が必要な事項を分ける。 - 性能問題を指摘するときは、入力サイズと実行頻度から影響経路を説明する。 - Big Oの差だけで実機上の問題や改善を断定しない。 - 正しさの後退は性能改善より優先して指摘する。 - 差分だけで判断できない場合は、呼び出し元、データ量、テスト、ベンチマークを確認する。 - 根拠がない場合は無理に指摘を作らず、「DSAの観点から指摘なし」と回答する。 ## レビューの進め方 1. 差分が変更する利用者の場面と処理を特定する。 2. 入力サイズ、実行頻度、主な操作を確認する。 3. 順序、重複、同値、境界値など、守る振る舞いを確認する。 4. 変更前後の時間・空間計算量と、前処理・更新コストを確認する。 5. Androidの測定が主張を支える条件になっているか確認する。 6. 問題、影響、再現条件、最小の修正方針を示す。 ## 指摘の出力形式 ```text [important] Setへの変更で表示順が失われる 対象: app/src/.../CreatureRepository.kt:42 根拠: 一覧の順序を表示に利用しているが、変更後のデータ構造ではその順序を守る条件が確認できない。 影響: 同じデータでも魔物の表示順が変わり、保存後に並びが安定しない可能性がある。 修正方針: 順序を不変条件としてテストし、順序と重複排除の両方を満たす構造または処理を選ぶ。 関連ルール: dsa-review-correctness-regression 確信度: high ``` ## 解く課題と入力サイズが曖昧ではないか - ルールID: `dsa-review-unclear-problem` - 重要度: 重要（`important`） - 既定の確信度: `high` - 状態: `current` - 適用対象: `problem`、`complexity` - 概要: 最適化やデータ構造の変更が、どの操作と規模を対象にしているか確認します。 - 理由: 対象と規模が分からなければ、計算量の差が利用者へ影響するか判断できません。 気になる兆候 - 『重い』『効率化』だけで対象操作がない - nが何を表すか書かれていない - 呼び出し頻度を確認せず局所コードだけ変更している 確認する質問 - 利用者が困る場面はどこですか？ - 入力サイズと1秒または1フレーム当たりの実行回数はいくつですか？ 改善の候補 - 再現できる利用場面と入力条件を追加する - 変更前の基準値を記録する ## 速度と引き換えに振る舞いを変えていないか - ルールID: `dsa-review-correctness-regression` - 重要度: 重要（`important`） - 既定の確信度: `high` - 状態: `current` - 適用対象: `correctness` - 概要: 順序、重複、同値、空入力、境界値など、データ構造変更で失われやすい性質を確認します。 - 理由: 処理が速くなっても、利用者が必要とする結果や順序が変われば改善とは言えません。 気になる兆候 - ListからSetへ変えたが順序のテストがない - 近似や枝刈りで結果が変わる条件が不明 - 最適化前後を比較する正しさのテストがない 確認する質問 - 変更前後で必ず一致すべき結果は何ですか？ - 結果が変わってよい場合、許容条件はどこで定義されていますか？ 改善の候補 - 不変条件と境界値のテストを先に追加する - 近似の場合は誤差やゲーム上の許容範囲を明記する ## 主な操作とデータ構造が合っているか - ルールID: `dsa-review-wrong-operation` - 重要度: 要検討（`consider`） - 既定の確信度: `medium` - 状態: `current` - 適用対象: `complexity`、`maintainability` - 概要: 検索、挿入、削除、順序保持、重複排除のうち、頻繁な操作に選択が合うか確認します。 - 理由: データ構造ごとに得意な操作と更新・メモリの代償が異なるため、利用頻度との対応が必要です。 気になる兆候 - ID検索のたびに全件走査している - 順序が必要なのに順序を保証しない構造を使う - 変換コストが本処理より頻繁に発生する 確認する質問 - 最も頻繁な読み書きは何ですか？ - 更新コストと追加メモリを含めても利点がありますか？ 改善の候補 - 操作ごとの頻度と計算量を表にする - 必要なら表示用と検索用の構造を責務を明確にして分ける ## Big Oだけで実機性能を断定していないか - ルールID: `dsa-review-big-o-claim` - 重要度: 要検討（`consider`） - 既定の確信度: `high` - 状態: `current` - 適用対象: `complexity`、`measurement` - 概要: 漸近計算量と、実際の端末での処理時間・割り当て・フレーム時間を分けて確認します。 - 理由: Big Oは入力増加の傾向であり、端末、定数時間、割り当て、GCを含む実測値ではありません。 気になる兆候 - O(1)なので高速とだけ説明している - 実際の入力規模がない - 追加メモリ、GC、前処理を無視している 確認する質問 - VEINで実際に扱うnはいくつですか？ - 端末上のBefore / Afterはありますか？ 改善の候補 - 計算量を成長の予測として説明する - 同一条件のベンチマークを追加する ## 測定条件に比較を壊す違いがないか - ルールID: `dsa-review-invalid-benchmark` - 重要度: 重要（`important`） - 既定の確信度: `high` - 状態: `current` - 適用対象: `measurement` - 概要: ビルド種別、端末、入力、コンパイル状態、反復回数、温度などが比較可能か確認します。 - 理由: 実装以外の条件が変わると、観測した差がアルゴリズムによるものか切り分けられません。 気になる兆候 - debugとreleaseを比較している - 一回の測定だけで結論を出す - Before / Afterで入力や端末が違う - 局所計測だけで体感改善を主張する 確認する質問 - 測定を再現する手順はありますか？ - 差はばらつきより大きいですか？ 改善の候補 - 測定環境と反復条件を固定する - 局所ベンチマークと利用者操作の計測を分ける ## 効果より実装の複雑さが大きくないか - ルールID: `dsa-review-unnecessary-complexity` - 重要度: 要検討（`consider`） - 既定の確信度: `medium` - 状態: `current` - 適用対象: `complexity`、`maintainability` - 概要: 現在の制約を単純な実装が満たす場合、複雑なDSAを維持する価値があるか確認します。 - 理由: 複雑な実装は理解、テスト、変更の費用を増やすため、確認できる効果との比較が必要です。 気になる兆候 - 再現可能な問題や測定値がない - 独自実装にテストがない - 小さな固定長データへ複雑な構造を導入している 確認する質問 - 単純な実装が満たせない制約は何ですか？ - 複雑さを追加して得られた利用者上の差は何ですか？ 改善の候補 - 単純な基準実装と比較する - 必要性が出る入力規模まで単純な方法を維持する ## AIが避けること - 実際の入力規模を確認せず、二重ループだけを理由に不具合と断定する。 - ライブラリや標準コレクションより独自実装を優先する。 - 性能の好みをcorrectnessの問題と同じ重要度で扱う。 - ベンチマークの追加だけを求め、何を測るべきか説明しない。 - 問題のない単純なコードを、面接で有名なアルゴリズムへ置き換える。