GitHub Copilot Code Review の誤検知が多い理由

配信ステータス：未配信 配信URL：（配信済みになったら記入）

台本

オープニング

【ジングル】 はい、どうもこんにちは。「雨宿りと WEB の小噺」、始まりました。Keeth こと桑原です。 今回もちょっとだけ、雨宿りしていきませんか。 今回のお題はですね、「GitHub Copilot Code Review の誤検知が多い理由」。実際に自分のPRで起きたことをベースに、ちょっと実務寄りの話をします。まぁ聞いてってください。

本題

  • 今回の PR で起きたこと

    • PR に対して Copilot から 26 件のレビューコメントが届いた
    • 実際に修正が必要だったのは 2〜3 件程度
    • 残りは誤検知・意図的設計・既対処済みに分類できた
    • つまり適合率（precision）は 1 割未満

  • 理由1：ファイルをまたいだ実行フローを追えない

    • 個々のファイルの内容は読めている
    • ただし「どこから呼ばれるか」「呼ばれる前提条件は何か」を接続できない
    • 例：auth-store.ts の sendEmailChangeVerification で auth.currentUser! を使っている
      • →「null になるかも」と指摘
      • → でも account.riot の onMounted() にログインガードがあり、未ログインなら画面自体が開けない
      • → この2ファイルにまたがる因果関係を Copilot はつなげられていない
    • 「コードを読んでいる」のではなく「コードのパターンを認識している」状態

  • 理由2：コードの見た目のパターンで判断している

    • 実行時に何が起きるかではなく、コードの見た目の特徴だけで「危険に見える」と判断する
    • 具体例
      • href なしの <a> に onclick がある → アクセシビリティ問題として検知（これは正しかった）
      • auth.currentUser に ! がある → null リスクとして検知（呼び出し元でガード済みだった）
      • 正規表現のパターンが特定の形をしている → 変換ロジックのバグとして検知（現在のキーには問題なかった）
    • パターンが意図的かどうか・すでに対処済みかどうかを判断する手段がない

  • 理由3：見逃しを極端に嫌う設計になっている

    • セキュリティ系のレビューツールとして「本物のバグを見逃す」ほうが「誤検知する」より悪い、という設計判断がある
    • 結果として疑わしいものはとりあえず全部報告する方向に振れる
    • 適合率を犠牲にして再現率を上げているトレードオフ
    • ユーザー視点では「狼少年」になりがち

  • 理由4：学習データのカットオフ

    • Gravatar が SHA-256 を正式サポートしたのは 2024 年
    • Copilot の学習データにその情報が含まれていない可能性がある
    • 「MD5 を使うべき」という古い常識で指摘してきた
    • 最新の仕様変更・ライブラリアップデートへの追従が遅れる

  • 誤検知を減らすためにやったこと

    • ESLint の導入
      • → Copilot が見る前にツールが検知してコードを直す
      • → Copilot に到達する頃には対処済みの状態になる
    • TypeScript strict モードの対象を拡大（JS ユーティリティを TS に移行）
      • → 型情報があれば Copilot も「ここは安全」と判断しやすくなる
      • → 今回の pubDateObj バグのように型定義があればコンパイル時に気づけた
    • 誤検知には根拠を示して反論・クローズする
      • → 全部鵜呑みにしない運用が重要

  • まとめ

    • Copilot のコードレビューは「パターン認識」であり「理解」ではない
    • 複数ファイルにまたがる設計意図・実行フローの把握が苦手
    • 見逃しを嫌う設計なので誤検知は構造的に多くなる
    • ツール（ESLint・TypeScript）で先に問題をつぶすと誤検知の絶対数は自然と減る
    • 使い方は「全部信じる」でも「全部無視する」でもなく「トリアージして使う」

エンディング

【ジングル】 さて、そろそろ今回もお時間です。 面白かったよーという方は、ぜひチャンネル登録もお願いします。話してほしいトピックや感想は、概要欄のフォームか 𝕏 で「WEB 小噺」でつぶやいてください。web はアルファベット、「小噺」は漢字でもひらがなでも大丈夫です！ それでは、また雨宿りしに来てください。お相手は Keeth でした。さようなら！ 【ジングル】

📚 参考情報

  • 今回のPRでの実測値
    • Copilotのレビューコメント26件中、実際に修正が必要だったのは2〜3件（適合率1割未満）
  • 誤検知が起きる4つの構造的理由
    • ①ファイルをまたいだ実行フロー・呼び出し元の前提条件を接続できない
    • ②コードの見た目のパターンだけで判断し、意図的な設計かどうかを識別できない
    • ③「見逃し」を嫌う設計のため、疑わしいものは全部報告する方向に振れる（適合率より再現率を優先）
    • ④学習データのカットオフにより、最新の仕様変更（例：Gravatarの SHA-256 対応）に追従できない
  • 誤検知を減らす実践的な対策
    • ESLint導入でCopilotが見る前に機械的な問題を解消する
    • TypeScript strictモードの対象拡大で型情報を増やし、判断材料を与える
    • 誤検知には根拠を示して反論・クローズする運用を徹底する

🎙️ 収録メモ

  • トーン
    • 冒頭：軽く実体験ベースであることを伝える
    • 理由1〜4：分析的、淡々と、でも具体例は面白く
    • 対策とまとめ：実務的、前向きに
  • 強調ポイント
    • 「適合率1割未満」という具体的な数字
    • 「コードを読んでいるのではなく、パターンを認識している」という表現
    • 「トリアージして使う」という結論
  • 尺
    • 合計：約8〜10分
    • オープニング：30秒
    • 本編：7〜9分
    • クロージング：30秒
  • タグ

    • GitHubCopilot #コードレビュー #AI #ESLint #TypeScript #開発生産性 #実務ネタ

results matching ""

    No results matching ""