Post
JA EN

AIが重複を増やすなら、DRY原則はもっと厳格であるべきだ：『間違った抽象化』論への反論

Posted
By
32 min read
AIが重複を増やすなら、DRY原則はもっと厳格であるべきだ：『間違った抽象化』論への反論
  • 想定読者： ソフトウェアエンジニア、テックリード、AIコーディングツールを日常的に使う開発者
  • 前提知識： DRY原則・コードクローンの基礎、AIコーディングエージェント（Claude Code、Cursor等）の使用経験
  • 所要時間： 15分

概要

「間違った抽象化より重複を選べ」。Sandi Metzのこの一言は、この10年でソフトウェア設計の準公式な教訓になった。AIコーディングエージェントが日常的にコードを書く今、この教訓はさらに都合よく響く。重複していても、後でAIに一括修正させればいい。無理に共通化して破綻するより、そのほうが安全ではないか。

だが、この教訓には昔から反論がある。エンジニアのJason Swettは、Metzの主張が問題を単純化しすぎていると指摘する。「間違った抽象化」という言葉自体が、実は単なる悪いコードを指す婉曲表現に過ぎず、本当に危険なのは重複の方だという立場だ。検出されないまま複数箇所に散らばった重複コードは、片方だけ直して他方を直し忘れるというサイレントな不整合を生む。これは理論上の懸念ではない。2009年のICSEで発表された古典的な実証研究は、コードクローンの52%が不整合な変更を受けており、そのうち15%が実際の不具合を引き起こしていたことを示した1。

この対立は、AIコーディングの時代に新しい重みを持つ。AIが重複を作りやすい理由は、コンテキストの外にある実装を見ていないからだ。だが、その同じ「見えていない」という性質こそが、Swettが警告した最悪のシナリオ、検出されない重複と正確に一致する。検出できないから重複を作るAIに、後で「その重複に気づいて一括整理してくれ」と期待するのは、実はかなり楽観的な賭けだ。

さらに、AI生成コードにはもう一つの層がある。Veracodeの2025年の調査では、100以上のLLMが生成したコードの45%がセキュリティテストに失敗し、OWASP Top 10の脆弱性を含んでいた2。コード品質プラットフォームQodo.aiの分析は、セキュリティ問題の70%以上が重複または一貫性のない実装に由来すると報告している3。同じ欠陥パターンが複数箇所、あるいは複数リポジトリに黙って複製されるなら、それは「いずれ気づいて直す」で済ませていい代物ではない。

本記事では、Metzの主張への古典的な反論を、AI時代のデータで検証し直す。重複を許容してAIに後始末を任せるのではなく、レビュー時点で重複を厳しく捕まえるべきだという、逆側の実務的な結論に至る。ただし、この立場にも限界はあり、正直にそこも扱う。

「重複より抽象化を恐れよ」という合意はどう生まれたか

Sandi MetzがRailsConf 2014で述べた「間違った抽象化より重複を選べ」は、その後多くの現場で引用され、Kent C. Doddsの「AHA（Avoid Hasty Abstractions、早まった抽象化を避けよ）」という折衷案にもつながった。重複を恐れず、複数箇所で同じコードが動くようになって初めて、共通点が「抽象化してくれ」と主張し始めるのを待つ、という考え方だ。

この主張の背景には、Metzが観察した具体的なパターンがある。プログラマーが重複に気づいて関数に切り出す。しばらくして「ほぼ同じだが少し違う」要件が現れ、次の担当者は既存の抽象化を守ろうとしてパラメータと条件分岐を追加する。これが繰り返されるうちに、単純だった抽象化は条件分岐だらけの理解不能なコードに劣化していく。この観察自体は正確で、誰もが一度は見たことのある光景だろう。

問題は、ここから「だから重複の方が安全だ」という結論への飛躍だ。

Swettの反論:「間違った抽象化」は婉曲表現に過ぎない

Jason Swettは、Metzの主張に対してこう反論する。まず、「間違った抽象化」という言葉自体を疑うべきだ。条件分岐だらけで理解不能になったコードは、そもそも「抽象化」の名に値しない。それは単に書き方の下手なコードであって、抽象化という概念そのものの欠陥ではない。この言葉づかいが、問題の本質を明らかにするどころか覆い隠していると指摘する。

次にSwettが強調するのは、重複が持つ見えにくいコストだ。重複の最悪のシナリオは、コードベース内に検出されないまま散らばっているケースだ。片方のインスタンスに変更が加えられても、もう片方には反映されない。この不整合は誰にも気づかれないまま本番で悪さをする。Swettはこれを「コーディングにおける最も危険な間違いの一つ」と呼ぶ。条件分岐が積み重なった見苦しいコードは、少なくとも目に見える。誰かがいずれ「これは酷い」と気づいてリファクタリングする対象になる。だが黙って散らばった重複は、気づかれるまで誰の目にも留まらない。

Swettはさらに、リファクタリングをためらう心理自体が、テストカバレッジ不足や集団的なコードオーナーシップの欠如、失敗を恐れる文化といった、もっと根深い組織の問題の症状だと見る。解決策は重複を受け入れることではなく、自動テストや継続的デプロイ、協調的なコードレビューを通じてその根本原因を直すことだと主張する。

この対立に、AIコーディングは新しい重みを持ち込む

ここまでは人間だけが書くコードをめぐる、10年来の論争だ。AIコーディングエージェントが日常的にコードを書くようになると、この対立の力学は変わる。

理由は単純だ。AIが重複コードを生成しやすいのは、自分が今読んでいるファイルやディレクトリの外にある実装を知らないまま生成することが多いからだ。開発者の65%が、AIツールはリファクタリングやレビューの際に関連する文脈を見落とすことが多いと回答している3。AI生成コードは、既存の共有ライブラリの存在を知らずに同じロジックを再生成するケースが特に多い。

これはSwettが描いた最悪のシナリオそのものだ。AIは「検出されない重複」を、人間よりも構造的に作りやすい。しかも、AI導入後にコピー/ペースト行の割合が増え、重複コードブロックが増加したという調査結果や、AI生成プルリクエストは人間のコードより再利用が少なく複製が多いという学術研究も、この傾向を裏づけている45。

問題はここからだ。「重複していても、後でAIに一括で直させればいい」という発想には、隠れた前提がある。誰か、あるいは何かが、まずその重複が同じ知識を表していると気づかなければならない、という前提だ。だが、その気づきこそAIが苦手とする部分だ。コンテキストの外にある実装を見ていないからこそ重複を作るAIに、後になって「あの重複に気づいて一つにまとめてくれ」と期待するのは、同じ弱点に二度賭けているようなものだ。見えていないから作られた重複を、見えていないままのAIが見つけて直すという想定は、都合が良すぎる。

もちろん、コードベース全体を見渡せる環境（整理されたモノレポや、十分な文脈を与えられたエージェント）であれば、この懸念はいくらか和らぐ。だが「見晴らしのよい環境を整備する」ことと「見晴らしが悪いまま重複を許容し、いつか誰かが気づくのを待つ」ことは、まったく別の話だ。前者は設計投資であり、後者は先送りに過ぎない。

セキュリティという文脈では、先送りの代償が跳ね上がる

この先送りのコストは、扱う対象がセキュリティやコンプライアンスに関わる領域だと、机上の議論ではなくなる。

Veracodeが2025年に発表した調査では、100以上の大規模言語モデルを対象にJava・Python・C#・JavaScriptの4言語、80のコーディングタスクで生成コードのセキュリティを検証した結果、生成コードの45%がセキュリティテストに失敗し、OWASP Top 10の脆弱性を含んでいた2。モデルのサイズや新しさとセキュリティ性能には相関が見られなかった。構文的に正しいコードを書く能力は向上しているが、安全なコードを書く能力はモデル規模によらず頭打ちのままだった。

Qodo.aiの分析は、この問題を重複という切り口から見ている。セキュリティ問題の70%以上は、まったく新しい脆弱性ではなく、重複または一貫性のない実装に由来すると報告している3。認証ヘッダーの扱い、リトライ処理、タイムアウト設定といったサービス間連携のロジックは、まさに重複が起きやすい領域として挙げられている。

この二つを重ねると、見えてくる構図はこうだ。AIはある程度の確率で脆弱なパターンを生成する。同時にAIは、そのパターンをコンテキストの外にある別の箇所へ、気づかないまま複製する。結果として、同じ脆弱性が一箇所ではなく複数箇所、あるいは複数のサービスやリポジトリに黙って広がる。一箇所ずつ監査していては、この横方向の拡散を発見できない。

こうなると、「いずれAIが気づいて一括修正してくれる」という前提はかなり危うい賭けに見える。修正される前に、脆弱なパターンが本番環境で複数回稼働する時間の方が長くなりうるからだ。Kent C. Doddsが言う「複数箇所で同じコードが動くようになって初めて、共通点が抽象化を主張し始める」という悠長さは、認証やペイメントのような領域では単純に間に合わない。共通点が「抽象化してくれ」と叫び出す頃には、その重複はすでに何度も本番で実行されている。

だから、検出はレビュー時点で厳格に行うべきだ

以上を踏まえると、実務的な結論はAHA的な「様子を見る」姿勢とは逆になる。AIが既存のロジックと重複するコードを提案してきた場合、それを「まだ抽象化するタイミングではない」として通すのではなく、レビュー時点でデフォルトのブロック対象として扱うべきだ。

これは精神論ではなく、すでに手をつけられる話でもある。重複コードを「完全重複」「近似重複（変数名や分岐順序が違うだけ）」「意味的重複（見た目は違うが振る舞いが同じ）」に分類し、コードの見た目が異なっていても振る舞いが同じものを検出しようとするツールが登場し始めている（意味的重複の高精度な検出はまだ発展途上で、万能ではない）。それでも、プルリクエストの段階でこの種の検出を機械的にゲートとして機能させれば、「AIが気づかなかった重複」を人間が事後的に気づく前に止められる可能性は上がる。マージ後に参照され始めた重複コードは、リファクタリングのリスクが跳ね上がり、長期的な技術的負債として固定化しやすいという指摘もある。捕まえるなら早いほうがいい。

Swettの言葉を借りれば、これはリファクタリングへのためらいという組織的な問題を、AIという新しい先送りの手段に置き換えないための備えでもある。「後でAIに任せればいい」は、「後でテストを書けばいい」「後でリファクタリングすればいい」と同じ構造の先送りになりうる。テストカバレッジや協調的なレビュー文化が整っていない組織ほど、この先送りは実行されないまま積み上がっていく。

この立場にも限界はある

ただし、この記事の立場を無条件の「常に厳格にDRYを守れ」に一般化するのは誠実ではない。

まず、コードクローンが常に不具合を生むという主張自体、学術的に決着しているわけではない。先ほど紹介した2009年の研究はクローンの52%が不整合な変更を受け15%が不具合につながったと報告した一方、同時期の別の研究は、リリース単位で見ると実際に不具合を導入したクローン系譜はわずか1.02%から4.00%にとどまったと報告している6。分析の粒度（コミット単位かリリース単位か）によって、重複の実害はかなり違って見える。重複が生まれてから実害に至るまでの間に、多くの不整合は誰かの手で吸収されている可能性がある。

次に、ゼロ重複主義そのものにもコストがある。あらゆる類似コードを機械的にブロックする運用は、レビューの摩擦を増やし、本来なら軸Bで見たとき別の知識を表している（たまたま似た形になっただけの）コードまで無理に一本化させてしまうリスクがある。これはまさにMetzが警告した「間違った抽象化」を、皮肉にも検出ツールの側から誘発することになりかねない。

つまり、この記事の主張が効くのは主に、解釈のずれが実害に直結する領域（認証・課金・権限判定・外部連携）や、規制・監査対応が求められる領域だ。実験的な機能や、まだ要件が固まっていない領域まで同じ厳格さで縛る必要はない。

まとめ

重複していてもAIに後で一括修正させればいいという発想には、誰かが先にその重複に気づかなければならないという隠れた前提がある。だが、AIが重複を作りやすい理由そのもの、コンテキストの外にある実装を見ていないという性質は、その同じAIが後から気づいて直すことも難しくする。Jason SwettがSandi Metzに向けた反論、検出されない重複こそが最悪のシナリオだという指摘は、この構造とぴったり重なる。認証やセキュリティのように解釈のずれが事故に直結する領域では、この先送りの代償は決して小さくない。

だから、少なくとも一部の領域では、AHA的に様子を見るのではなく、レビュー時点で重複を機械的に捕まえて止める方が理にかなっている。ただしこれは万能の答えではない。学術研究の結果は割れているし、厳格すぎる検出はそれ自体が新しい摩擦を生む。結局のところ、AIが増やす重複にどう向き合うかは、扱う知識がどれだけ間違えられないかで決まる。

もう一つの見方: 本記事はSandi Metzの主張への反論を軸にしたが、姉妹記事のAIは重複コードを増やしながら共通化の意味を変えるは、同じAI時代のデータから「多少の重複は許容し、後から一括で畳み直せばいい」という逆の実務的結論を導いている。どちらの立場が自分のチームに合うかは、扱っている知識の性質（間違えたときの代償）次第で変わる。両方読んで判断材料にしてほしい。

関連記事

このテーマに関連する他の記事もご覧ください：

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

その他参考資料（本文中で番号引用なし）

  1. Do Code Clones Matter? - Elmar Juergens, Florian Deissenboeck, Benjamin Hummel, Stefan Wagner, ICSE 2009（2017年arXiv再掲）. 【信頼性: 高】 ↩︎

  2. 2025 GenAI Code Security Report - Veracode (2025). 【信頼性: 中〜高】 ↩︎ ↩︎2

  3. How to Catch Code Duplication Across 100 Repositories - Nnenna Ndukwe, Qodo.ai (2026). 【信頼性: 中】 ↩︎ ↩︎2 ↩︎3

  4. AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones - GitClear (2025). 【信頼性: 中〜高】 ↩︎

  5. More Code, Less Reuse: Investigating Code Quality and Reviewer Sentiment towards AI-generated Pull Requests - MSR ‘26 会議論文 (2026). 【信頼性: 中〜高】 ↩︎

  6. An Empirical Study on Inconsistent Changes to Code Clones at Release Level - Bettenburg et al., WCRE 2009. 【信頼性: 中〜高】 ↩︎

ソフトウェア設計
DRY原則 ソフトウェア設計 AIコーディング コードレビュー 技術的負債 セキュリティ
This post is licensed under CC BY 4.0 by the author.