目次
AIコーディングツールは機能する。GitHub Copilotを使った開発者はコーディング速度が平均55%向上したというデータがある（GitHub Octoverse 2024）。Stack Overflow調査では開発者の62%がすでにAIツールを業務に使い、39%が「生産性が顕著に上がった」と回答している。否定しても仕方のない数字だ。
しかし、速くなったことと良くなったことは、まったく別の話だ。
通説：AIコーディングは開発を革命する
市場の熱狂を見れば通説の強さがわかる。GitHub Copilotは4,000万人超のユーザーを持ち、CursorはARR1億ドルを突破した。Claude CodeやDevinのようなエージェント型は「GitHubイシューを自律解決する」と謳われる。McKinseyは開発生産性向上による経済効果を年間2,000〜3,700億ドルと試算する。
この流れに逆らう議論はほぼ聞こえない。「AIを使わない開発者は時代遅れ」という空気が業界全体に広がっている。
反論の論拠
しかし数字を丁寧に追うと、別の事実が見える。
セキュリティの問題。 GitHubのセキュリティ研究チームは2023年に、Copilotが生成したコードの40%に少なくとも1つのセキュリティ上の問題が含まれていたと報告している。AIは公開コードのパターンを学習しており、既知の脆弱性パターンをそのまま再現することがある。
「レビュー時間が増えた」という声。 Stack Overflow調査で39%が「生産性が上がった」と回答する一方、**36%が「AIのコードをレビューする時間が増えた」**と答えている。速度向上の恩恵が、レビュー負荷の増加で部分的に相殺されている。
「ラバースタンプ問題」の静かな拡大。 GitHub社内データでは、Copilot導入後にコードレビューの平均所要時間が短縮された一方で、本番障害件数が変わらなかったプロジェクトが報告されている。AIが出力したコードを十分に検証しない傾向——いわゆるラバースタンプ問題——は、可視化されにくい形で品質を蝕む。
コンテキスト窓の限界は本物だ。 大規模なコードベースでAIがシステム全体を把握しきれないことは、エージェント型ツールでも解決していない。複数のマイクロサービスにまたがる設計判断や、ビジネスドメインの深い理解が必要な実装は、現状のAIが最も苦手とする領域だ。
結論
AIコーディングツールは「使うべきか」という段階を過ぎた。問いは「どう使うか」に移っている。
だが組織レベルで見ると、まだ多くの企業が「速くなった」ことを「良くなった」ことと同一視している。コーディング速度という一次指標の改善に注目し、バグ密度・セキュリティインシデント・レビュー負荷という二次指標を追跡していない。
AIコーディングの恩恵を本当に享受する組織は、速度計測だけでなく品質計測を同時に導入した組織だ。 AIの出力を評価・統合し、ドメイン固有のロジックを判断できるシニアエンジニアの価値が落ちていない理由は、まさにここにある。「55%速くなった」という数字に安心するより、「品質はどう変わったか」を問い続ける組織だけが、AIコーディングの果実を本当に収穫できる。
引用元・参考リンク
免責事項 — 当記事は情報提供を目的としており、特定の金融商品の売買を推奨するものではありません。投資判断はご自身の責任で行ってください。