ある開発者がIDEのダッシュボードを開いたら「PCW 98%」と表示されていました。AIが書いたコードの割合が98%という意味です。怪しいですよね。そこで彼は実験を始めました。結果は衝撃的でした。49文字を手で打っても、システムは46文字しか人間の貢献として認めず、自分のコードをコピー&ペーストすると0点で全部AIの得点になったんです。
何が起きてるんですか?
2026年4月、William O''Connellが自分のブログに公開した話です。会社で使っているWindsurf(VS Codeベースの AI IDE)の分析ダッシュボードを見たら、「% new code written by Windsurf」が98%と表示されていました。本人の体感では10〜20%程度。「私が手で書いたコードよりAIが書いたものが49倍多い? それなら今頃トークン予算が枯渇して、神レベルの生産性で昇進したか、49/50の開発者が不要として解雇されているはずでは?」 疑問に思って実験を始めたんです。
Windsurf自身も「お客様のPCW値は通常85%以上、しばしば95%以上です」と公式ブログに書いています。「これはハルシネーションではなく、計算方式に基づいた正確な数字です」と強調しながら。 しかし測定方式を分解すると、これを「正確」と主張するのは無理があります。
O''Connellはmitmproxyでネットワークトラフィックを傍受しようとしましたが、protobufエンコーディングに阻まれました。幸いダッシュボードのAPIレスポンスにuser_bytes、codeium_bytes、total_bytes、percent_code_writtenフィールドが露出していました。これで彼が発見したバイアスは5つです。
WindsurfのPCWが人間の貢献を削り取る5つのメカニズム
1. 自動補完される閉じカッコや引用符は人間の入力にカウントされない。49文字打っても46文字しかuser_bytesが増えない。
2. ペーストはuser_bytesに加算されない。自分のコードを別ファイルに移動しても0点。
3. リファクタリングは丸ごとAIの得点。自分の関数をAIに移させると100% AI貢献。
4. セッション境界がない。再起動するとどの行がどこ由来か忘れる。
5. 「コミット時に測定」と書いてあるがgit連動は機能していない。実際はタイピングごとにカウンタが動く。
O''Connellは決定的な実験をしました。human_file.jsに1行直接タイピング(49文字)、AIに同じ長さの1行をai_file.jsに書かせる。次に自分が書いた関数をAIファイルにコピペし、自分の関数をAIに別ファイルへ移すよう指示。結果: AIが人間の2倍以上のコード量を書いたと報告された(67.9%)。実は両ファイルはほぼ同じ長さだったのに。
Cursorの「AI Share of Committed Code」はもっと正直なgitベースの測定でした。でもO''Connellが100行のJSファイルを貼り付けて、AIに引用符だけ書き換えるよう指示したら、100行全体が「AI作成」としてカウントされました。AIが実際に触ったのは49行だけだったのに。 結局、両ツールともバイアスがあって、その方向は常に「AI比重を過大評価」です。
これがもっと深刻な問題な理由
AnthropicのClaude Code責任者Boris Chernyが2026年1月に「私のコードの100%はClaudeが書いている。会社全体もほぼ100%」とXに投稿して話題になりました。 似たようにMicrosoft CEOのSatya Nadellaは30%、Googleは75%を自慢しました。役員が発表しやすい数字です。AI企業にとっては自社ツールの価値を証明する数字でもあります。
ところがMETRの研究は真逆の結果を示します。16人のシニアOSS開発者を対象にしたRCT(無作為化比較試験)で、AIツールを使ったグループは19%遅かった。もっと怖いのは「AIのおかげで速くなった」と本人たちが信じていたこと。本人感覚では20%速くなったと答えたのに、実際は19%遅くなっていたんです。
GitClearが2億1,100万行のコード変更を5年分分析した結果も衝撃的です。リファクタリング比率は2021年の25%から2024年の10%以下に低下し、コピペコードは8.3%から12.3%に4倍増加(歴史上初めて「コピペ」が「移動」を上回った)。 AIはコード量は増やしたものの、コードベースの健全性は測定可能な形で悪化しているという話です。
| ベンダーの指標 | 現場で本当に見るべきシグナル | |
|---|---|---|
| 測定単位 | バイト/行数(量) | PRサイクルタイム、事後修正率(質) |
| バイアス方向 | AI比重を過大評価 | 中立 — マージ後にイシュー/ロールバックで検証 |
| 測定タイミング | タイピング即時またはコミット時 | マージ後7〜30日間追跡 |
| 意思決定への効用 | 「AIが全部やるから人を減らそう」 | 「どこに検証負債が溜まっているか」 |
| 法的リスク | 「コードの大半が著作権保護対象外」 | 人間の貢献比率を保守的に算定 |
これは単なる指標の精度問題ではありません。「うちの会社のコードの90%がAI」という一文が作られると、経営陣は「じゃあ人がなぜこんなに必要?」と聞き始めます。さらに米国ではAI生成著作物が著作権保護の対象外という判決が出ているため、「コードの大部分がAIで書かれた」という指標は法務チームの悪夢です。
韓国の現場でも同じ悩みが始まっています。ある社内ガイドラインの記事では「AIコード受容率をKPIにすると、品質検証なしにアクセプトだけする行動が出る」とGoodhartの法則を引用していました。 別のCTOは「AIが1分で書いたコードを人間が10分かけてレビューする皮肉」を指摘しました。 指標が嘘をついている間、本当のコストはコードレビュー時間に移っているんです。
核心まとめ: PRで本当のシグナルを掴む検証チェックリスト
- ダッシュボードのPCW/AI Share数値は「方向性」だけで見る
Windsurf自身のガイドも「directional proxy」と明記しています。絶対値は無意味。同じチーム、同じツール、同じ四半期内で推移変化だけを活用してください。 他のツール・他のチームと絶対に比較しないこと。 - PRレビュー時に「diffレイアウト」から見る
AIが書いたPRは普通触る必要のない場所まで一緒に修正されていることが多いです(O''Connell実験の「100行全体がAI」のようなパターン)。diffが異常に広範囲なら「この変更の本当の意図は何か」をまず聞くのがシグナルです。 - テストがきれいすぎたら疑う
METRの研究によるとAIは「ハードコーディングされた値で通過する自己充足的テスト」をよく作ります。 アサーションが入力値そのままを比較していたり、エッジケースなしでhappy pathだけだったりすると赤信号です。失敗ケースを1つ追加してテストが崩れるか確認してください。 - 重複コードと死んだコードを自動検出する
GitClear研究が示した4倍増加したコピペパターンがPRに入ってきたら阻止すべきです。 jscpd、SonarQube duplications、または単純にgrepで同じ関数シグネチャが2箇所にあるか確認するだけでも効果が大きいです。AIは既存コードを再利用せず、似たものを新しく書く傾向が強いです。 - 「AIに自分のコードをディフェンドさせる」
Adam Ferrariが提案した検証パターンです。同じまたは別のモデルにPR diffを渡して「この変更がなぜ必要だったか、どんなリスクがあるか」を説明させてください。自分のコードも説明できないなら、人間レビュアーの時間を節約したのではなく、ただ負債を後回しにしただけです。
マネージャー用のワンライナーチェック
「うちのチームのAIコード比率はX%です」という報告が上がってきたら、2つの質問だけ投げてください。① この数字はどう計算されたか(Windsurf PCWかCursor Shareか自社定義か)。② 同じ四半期内でPR事後修正率・ロールバック率はどう変化したか。2つの質問に答えが出ないなら、その数字は意思決定の根拠に使わないでください。
もっと深く知りたいなら
Your AI Might be Lying to Your Boss William O''Connellの原本実験記 — WindsurfとCursorの測定方式を直接デバッグしたフルレポート williamoconnell.me
Percentage of Code Written Windsurf公式PCW説明 — 85〜95%が正常というベンダー側の立場と6つのcaveat windsurf.com
METR: Early-2025 AI on Experienced Developers シニア16人のRCT — AI使用時に19%遅くなり、本人は20%速くなったと信じていた metr.org
GitClear AI Copilot Code Quality 2025 2億1,100万行分析 — コピペ4倍増、リファクタリング25%→10%下落 gitclear.com
Anthropic・OpenAI「100% AIコード」発言報道 Boris ChernyとRoonが本人コード100%がAIと主張 fortune.com
Quantifying AI Coding Impact Adam Ferrariの測定パターン分析 — PCWの限界と代替指標提案 adamferrari.substack.com
AIコードレビュー信頼度を高める開発組織運営原則 韓国の社内導入事例 — AIレビューの上にシニアレビューを重ねる二重構造 brunch.co.kr
