AIコードレビュー (Codex、GitHub Copilot Code Review、各種SaaS)を業務に取り入れる人は増えています。構造もよく、網羅性も高く、人間レビューでは見落としがちな点を拾ってくれる。一方で、定量的な数値解釈で誤読をすることがあります。鵜呑みにすると、的外れな最適化作業に時間を取られます。
得意な領域と懐疑的に読む領域
経験上、AIレビューは多くの場合、次の領域で安定して動きます。
強い領域
網羅性で「ここも見ておくべき」を全部リストアップしてくれる。構造でP1/P2/P3やcritical/major/minorのような優先度ラベリングが揃う。既知パターン認識でHSTS未設定、CSP未設定、unused dependencies、ESLint違反等を拾ってくれます。コーディング規約準拠の一貫性チェックも得意。
懐疑的に読むべき領域
特定の数値を主因とした優先度判定(例: 「CSS 446KBだからP1」「LCP 2.5sだからP1」)。コードの意図と背景を文脈なしに推論する判断。トレードオフの重み付けの最終判断。これらはツール差や設定差が大きく、出力を真に受けると判断を誤ります。
数値は計測しやすい分、AIレビューが食いつきやすい。その数値が何を計測しているかを分解しないと、優先度を誤ります。
実例: CSS 446KBがFCP直撃という誤読
あるSSGサイトのレビューで、AIがP1指摘として次を出しました。
P1 Performance: CSS 446KB、gzip約134KB。Noto Sans JP 3 weight + Noto Serif JP variableのfont-faceが大量生成。FCP/LCP悪化、CSSレンダリングブロック、フォント取得遅延
「446KBのCSSがレンダリングブロックでFCP直撃」は一見説得力があります。CSSのサイズとレンダリングブロック性質を組み合わせた指摘で、構造としては妥当。
ところがLighthouse mobile P=93 (トップページ)、FCPとLCPも要改善ライン以下でした。「P1指摘なのに数値は崩れていない」という違和感が残ります。実態を分解すると、446KBのCSSはfont-face定義であって、フォント本体ではありません。unicode-range でサブセットに分割されたfont-face宣言が並んでいるだけ。
これは「CSSのサイズ」と「実際にダウンロードされるwoff2のサイズ」の混同。AIレビューはCSSバイト数を直接FCP影響と結びつけましたが、CSSの中身が何で構成されているかまでは分解していません。
その数値は何のバイト数なのか
CSSの @font-face 定義はフォント本体ではなく、ブラウザが必要時に参照する指示書です。CSSのバイト数とフォントのダウンロード量は別の話で、CJKページでも複数サブセットが落ちれば100KBを超えることもあれば、ページ内文字種が狭ければ数十KBに収まることもあります。
@media クエリの条件部分も、CSSとしては転送・解析されます。「適用されていないから無コスト」とは言えません。実行コストと適用コストは別物です。
動的インポートされるモジュールはバンドルに含まれますが、初期チャンクには乗りません。tree shake前のサイズも、最終バンドルには未参照部分が含まれないことがあります。
これらを「rawバイト数だけ」で評価すると、転送と実行と適用が混ざります。AIレビューが数値を出してきたら、DevToolsのNetworkタブとCoverageタブで実測する一手間が要ります。
計測値の主因は本当にそこか
Lighthouse mobile Performance 76という数字があるとします。AIレビューは「React Islandのハイドレーションコストが主因」と推定しますが、実際にどれが主因かは分解しないと分かりません。LCP (Largest Contentful Paint)なら、どの要素がLCPで、描画にどれだけ時間がかかったのか。TBT (Total Blocking Time)なら、どのスクリプトがいつメインスレッドをブロックしたのか。CLS (Cumulative Layout Shift)なら、どの要素がレイアウトシフトを起こしたのか。
LighthouseのPerformance詳細レポートを開けば、各メトリクスの内訳と原因要素が分かります。「Performance 76 → React Islandが主因」とラベルされても、実態はフォントロードの遅延かもしれないし、サードパーティスクリプトかもしれません。
実測で返す
AIレビューに反論するときは実測で返します。「CSSが大きい」と言われたら、ビルド成果物のCSSをgrepしてfont-face定義と実効スタイルの比を出します。「バンドルが大きい」と言われたら、dist/_astro/*.js のチャンク別サイズを ls -lah で出す。「Lighthouseが悪い」と言われたら、lighthouse-audit.mjs を再実行して直近スコアを示す。
AIレビューが間違っているわけではなく、粒度が荒いだけです。反論する側が高粒度で計測して返せば、議論はビルド成果物ベースで進みます。
読む順序
最初に、全指摘を一度受け止めます。「これは違う」と即却下せず、ネットワーク、ビルド成果物、Lighthouseで実測する習慣を持つ。次に、数値の主因推定だけクリティカルに読む。「P1」ラベルでも数値解釈は懐疑、構造は信頼です。最後に、重要指摘とノイズを分離する。critical、major、minorの境界線は自分で引き直し、AIのラベルを最終決定にしません。
この順序で読めば、AIレビューは網羅性の補強、うっかり見落としの確認材料として機能します。逆にAIの優先度ラベルをそのまま最終決定にすると、的外れな最適化に時間を取られます。