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の中身が何で構成されているかまでは分解していません。
分解の問い1: 何のバイト数なのか
最初に問うべきは、その数値は何を表すかです。
CSSの @font-face 定義はフォント本体ではなく、ブラウザが必要時に参照する指示書。CSS のバイト数とフォントのダウンロード量は別の話で、CJK ページでも複数サブセットが落ちれば 100KB を超えることもあれば、ページ内文字種が狭ければ数十 KB に収まることもあります。@media クエリの条件部分も、CSS としては転送・解析されるので、「適用されていないから無コスト」とは言えない (実行コストと適用コストは別)。動的インポートされるモジュールはバンドルに含まれますが、初期チャンクには乗りません。tree shake前のサイズは、最終バンドルに未参照部分が含まれない可能性があります。
これらを「rawバイト数だけ」で評価すると、転送と実行と適用が混ざる。AIレビューが数値を出してきたら、DevTools の Network タブと Coverage タブで実測する一手間が要ります。
分解の問い2: 計測値の主因は本当にそこか
もう一つ問うべきは、その計測値の悪化は本当にこの指摘箇所が主因か。
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レビューが間違っているわけではない。粒度が荒いだけ。反論する側が高粒度で計測して返せば、議論はビルド成果物ベースで進みます。
AIレビューを活かす読む順序
AIレビューの読み方として有効な順序があります。
最初に、全指摘を一度受け止める。「これは違う」と即却下せず、ネットワーク、ビルド成果物、Lighthouseで実測する習慣を持つ。次に、数値の主因推定だけクリティカルに読む。「P1」ラベルでも数値解釈は懐疑、構造は信頼。最後に、重要指摘とノイズを分離する。critical、major、minorの境界線は自分で引き直し、AIのラベルを最終としません。
これでAIレビューは網羅性の補強、うっかり見落としの確認材料として機能します。逆にAIの優先度ラベルを最終決定にしてしまうと、的外れな最適化に時間を取られます。
AIレビューは多くの場合、構造もよく網羅性も高く、人間より速いし疲れません。その数値は何を計測しているか、主因はこれで正しいか。これを分解する習慣を持つだけで、AIレビューは強力な確認材料になります。