Post
JA EN

AIは重複コードを増やしながら共通化の意味を変える：DRY原則を原典から読み直す

Posted
By
39 min read
AIは重複コードを増やしながら共通化の意味を変える：DRY原則を原典から読み直す
  • 想定読者： ソフトウェアエンジニア、テックリード、AIコーディングツールを日常的に使う開発者
  • 前提知識： DRY原則・リファクタリングの基礎、AIコーディングエージェント（Claude Code、Cursor等）の使用経験
  • 所要時間： 15分

概要

「AIに『この変更を全箇所に適用して』と頼めば済むなら、そもそも共通化しておく意味は薄れるのではないか」。AIコーディングエージェントを日常的に使うようになると、一度はこう感じる。重複コードの修正コストが下がるなら、DRY原則（Don’t Repeat Yourself）の存在理由の少なくとも一部は失われるように見える。

ところが実際のデータを見ると、様相はもっとねじれている。GitClearが211百万行のコード変更を分析した2025年の調査では、AI導入後にコピー/ペースト行の割合が8.3%から12.3%に増え、重複コードブロックは4倍に増加した1。2026年の学術研究も、AI生成プルリクエストは人間のコードより再利用が少なく複製が多いという傾向を独立に確認している2。つまりAIは、重複を減らすどころか増やす方向に働いている。

一方で、AIコーディングエージェントは横断的な一括変更を劇的に安くしてもいる。モノレポ環境であれば、5つのサービスが参照する共有フィールドの名前を変える作業を、エージェントは全消費先を見渡しながら一度の変更で終える3。これは「N箇所に同じ修正を書く手間」というDRY原則の古典的な根拠を、少なくとも一部の状況では弱める材料になる。

AIは重複を増やす存在であり、同時に重複の修正を安くする存在でもある。この矛盾をどう理解すればいいのか。

答えの手がかりは、DRY原則の原典に戻ると見えてくる。Andy HuntとDave Thomasが定式化したDRY原則が本来言っていたのは「コードの見た目を重複させるな」ではなく「知識を重複させるな」だった4。この区別に立つと、共通化の価値は二つに分解できる。ひとつは「同じ処理を何度も書く手間を省く」という執筆コストの話、もうひとつは「ある知識・振る舞いの正解が、システム内でただ一箇所にしか存在しない」という一貫性の話だ。AIが変えているのは主に前者であり、後者はAIとは無関係に残る。それどころか、AIが持つ構造的な弱点のぶん、後者の重要性はむしろ増している。

本記事では、この非対称な変化を、実証データと設計原則の原典の両方から検証する。

AIは、なぜ重複コードを増やすのか

複数の独立した調査が同じ傾向を示す

GitClearの2025年レポートは、Google・Microsoft・Metaを含む大企業のリポジトリから2020〜2024年の5年間、211百万行のコード変更を分析した1。コピー/ペーストされたコード行の割合は8.3%から12.3%に増加し（約50%増）、5行以上の重複コードブロックは4倍に増えた。同時に「リファクタリング」に分類されるコード変更の割合は、2021年の25%から2024年には10%未満まで落ち込んでいる（60%減）。AIアシスタントの利用が広がった時期と、この変化の時期はおおむね重なる。

これが単発の調査結果であれば慎重に扱うべきだが、独立した手法による裏付けがある。2026年のMSR（Mining Software Repositories）カンファレンスで発表された学術研究「More Code, Less Reuse」は、コードクローン検出と循環的複雑度の指標を使い、AI生成プルリクエストが人間のプルリクエストよりコード量が多く再利用が少ないことを確認した2。

もうひとつ、より具体的な手がかりがある。2026年5月、GitHub上で「vibe-coded」とタグ付けされた49プロジェクト、合計720万行をコピー/ペースト検出ツールjscpdで分析したレポートでは、平均重複率は7.98%だった5。ここで目を引くのは、重複率の上位に、AIアプリそのものではなくAIエージェント向けの「スキルライブラリ」が食い込んでいた点だ（agent-skillsが37.48%で全体2位）。スキル定義はもともとテンプレート的な構造になりやすいという事情もあるが、AIに指示を与えるための定型的な設定・手順書ほど、AI自身がコピー&微調整で量産しやすい面はありそうだ。

原因は「見えていない」こと

なぜAIは重複を作りやすいのか。理由は単純で、AIエージェントは自分が今読んでいるファイル・ディレクトリの外にある実装を「知らない」まま生成することが多いからだ。コード品質プラットフォームQodo.aiの分析では、開発者の65%が「AIツールはリファクタリングやレビューの際に関連する文脈を見落とすことが多い」と回答している6。同記事は重複を「完全重複」「近似重複（変数名や分岐順序が違うだけ）」「意味的重複（見た目は違うが振る舞いが同じ）」の3種に分類し、AI生成コードは特に、既存の共有ライブラリの存在を知らずに同じロジックを再生成するケースが多いと指摘する。人間のエンジニアなら「これ、前にどこかで書かなかったっけ」と立ち止まる場面で、AIはコンテキストウィンドウの外にある実装を単純に見ていない。

これは能力の問題というより、視界の問題だ。次の節で見るように、この「視界」を広げる環境を整えれば、AIは重複を減らす側にも一括で回れる。

同時に、AIは横断的な一括変更を劇的に安くする

ここで先ほどの矛盾が生きてくる。エンジニアのFrancis Eytan Dortortは、モノレポとマルチレポの選択という古典的なアーキテクチャ論争が、AIコーディングエージェントの登場で判断基準ごと変わりつつあると論じている3。

従来この選択は「人間の作業単位」を最適化する議論だった。マルチレポはチーム間の所有権境界を明確にする代わり、共有インターフェースを変更するたびに複数リポジトリをまたぐ調整（ライブラリの更新、全消費先へのプルリクエスト、マージ順序の調整、バージョン互換期間の管理）を必要とした。モノレポはこの調整コストを避けられる代わり、専用のビルドツール（Bazel、Nxなど）への投資を要求した。

Dortortが挙げる例はわかりやすい。5つのサービスが参照するprotobufのフィールド名を変更する場合、モノレポであればエージェントはフィールド定義・生成されたバインディング・全消費先のコードを一度に見渡し、アトミックに変更を完了できる。マルチレポでは、エージェントはスキーマ側のリポジトリしか見えず、消費側の各サービスは次のビルドで個別に壊れ、人間が調整して回る必要が生まれる。

つまり「AIが重複を一括修正できるかどうか」は、AIの能力そのものではなく、AIがどこまでのコードベースを一望できる状態に置かれているかで決まる。同じモデル・同じエージェントでも、境界の引き方次第で「重複を量産する存在」にも「重複を安く解消する存在」にもなる。GitClearやQodoが観測した重複増加は、多くの現場でAIがまだこの一望できる状態に置かれていない（あるいは意図的に境界を切っている）ことの反映でもある。

DRY原則の原典に戻る:「知識」であって「見た目」ではない

ここまでの矛盾を整理する軸として、DRY原則の原典に戻る価値がある。Andy HuntとDave Thomasは1999年の著書『The Pragmatic Programmer』でDRY原則をこう定式化した。

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. （あらゆる知識は、システム内でただ一つの、曖昧さのない、権威ある表現を持たなければならない）4

この原則の射程は、コードの見た目の重複だけではない。データベーススキーマ、テスト計画、ビルド設定、ドキュメントまで含む「知識の重複」全般を対象にしている7。

この区別は、AI時代の議論を整理するうえで効く。GitClearや今回のvibe-coding調査が計測しているのは、あくまで「コードの見た目の重複」、つまりコピー/ペースト検出ツールが検出できる範囲の話だ。これは本来のDRY原則が主眼に置いていた「知識の重複」とイコールではない。似たコードが2箇所にあっても、それぞれが表している「知識」が実は違う（Sandi Metzの言う「間違った抽象化」を避けた結果、たまたま似た形になっただけ）のであれば、それはDRY違反ではない。逆に、コードの見た目は違っていても、同じビジネスルールを2箇所で別々に実装していれば、それは立派なDRY違反であり、AIがどれだけ一括修正を安くしても解消されない問題として残る。

つまり、「コードの見た目の重複が増えた」という観測結果だけから「AI時代は共通化が軽視されている」と結論づけるのは早計だ。問うべきは、その重複が知識の重複を伴っているかどうかだ。

共通化の価値を二つに分ける

この原典的な区別を踏まえると、共通化が持っていた価値は二つの異なる軸に分解できる。

ひとつは軸A、執筆・保守コストの削減だ。同じ処理を何度も書きたくない、直すときにN箇所を回りたくない、という「手間」の話であり、これはAIによって相対的に軽くなっている。書く手間はAIが肩代わりし、モノレポのように見晴らしのよい環境であれば、一括修正の手間もAIが肩代わりできる。

もうひとつは軸B、知識の単一ソース化だ。ある仕様・ルール・契約の「正解」が、システム内にただ一つしか存在しない状態を保つという話であり、これはAIの得手不得手とは無関係に残る。むしろ、AIがコンテキストの外にある実装を見落として意味的重複を生みやすいという弱点（前述のQodo.aiの指摘6）を踏まえると、知識が分散していること自体のリスクは、AI時代にはむしろ高まっている可能性がある。人間のエンジニアなら「これ前にも見た気がする」という記憶が緩い歯止めになっていた部分を、AIは見えている範囲でしか持っていない。

軸Aだけを根拠に共通化していた箇所、たとえば「単に書くのが面倒だから関数化した」程度の共通化は、AIによってその存在理由が薄れる。一方、軸Bを根拠にする共通化、認証ロジック・料金計算・型定義や契約など「ここの解釈がずれると事故になる」箇所は、AIの登場とは関係なく重要であり続ける。

早すぎる抽象化のリスクは、AI時代にむしろ大きくなる

共通化の判断にはもう一つ、DRY原則そのものとは別の軸として「早すぎる抽象化」の問題がある。Sandi MetzはRailsConf 2014の講演で「間違った抽象化より重複を選べ」と主張し、その後のブログ記事でこの主張を体系化した8。

Metzが描く「間違った抽象化」が生まれる過程はこうだ。あるプログラマーが重複に気づいて関数に切り出す。しばらくして「ほぼ同じだが少し違う」要件が現れ、次の担当者は既存の抽象化を守ろうとしてパラメータと条件分岐を追加する。これが繰り返されるうちに、かつて単純だった抽象化は、条件分岐だらけの理解不能なコードに劣化していく8。Metzはこの背景にサンクコスト・バイアスを見ている。複雑で理解しづらいコードほど「これだけ手間がかかっているのだから重要に違いない」という心理的圧力がかかり、間違った抽象化を延命させてしまう。

Kent C. Doddsはこれを踏まえ、DRYにもWET（重複を許容する立場）にも教条的にならない「AHA（Avoid Hasty Abstractions、早まった抽象化を避けよ）」という折衷案を提示している9。重複を恐れず、複数箇所で同じコードが動くようになって初めて、共通点が「抽象化してくれ」と主張し始めるのを待つ、という考え方だ。

この「間違った抽象化」のパターンは、AIエージェントが日常的にコードを書く環境ではむしろ加速するリスクがある。Metzが描いた6番目のステップ、つまり「既存の抽象化を守る義務感からパラメータを追加する」振る舞いは、人間のエンジニアが感じるサンクコストの心理から生まれていた。AIエージェントに「この機能を既存の関数に追加して」と頼めば、エージェントは律儀にその指示に従い、パラメータと条件分岐を足す方向に進みやすい。既存コードを差し替えて新しい設計を提案するより、既存の構造を尊重して変更を最小化する方が、多くのエージェントにとって「安全な」振る舞いだからだ。人間ならためらう場面でエージェントは淡々と実行してしまう分、条件分岐が蓄積する速度は人間主体の開発より速くなりうる。

断っておくと、ここから先は厳密な実証データに基づく主張ではなく、Metzが描いた人間側の心理パターンを、AIエージェントの既知の挙動特性に当てはめた推論だ。一見、AIが重複コードを書きたがる傾向（前述の各種データ）と、早すぎる抽象化を導入する傾向は矛盾するように見える。だがどちらも「今この瞬間に求められている指示に、最短距離で応える」というエージェントの振る舞い方から生まれているなら、根は同じはずだ。目の前のタスクを解決することが最優先になり、「この先どちらの設計が長持ちするか」という判断は後回しになりやすい。

だとすれば、AHA原則が求める「抽象化を急がず、複数の実例が揃うまで待つ」という判断は、AI時代にこそ人間が意識して持ち込む必要がある視点になる。AIは指示された抽象化を実装するのは得意でも、「まだ抽象化すべきタイミングではない」と判断してブレーキを踏むことは、少なくとも今のところ苦手だ。

実務でどう判断するか

以上を踏まえると、「共通化すべきか」の判断は、AI以前と比べて軸足を移す。

もう重く問う必要がなくなったのは、「書く手間・直す手間を省くために共通化すべきか」だ。AIが横断的な一括変更を安くしている環境（見晴らしのよいモノレポ、あるいは十分な文脈を与えられたエージェント）では、多少の重複を許容しても、後から一括で畳み直すコストは下がっている。

問い続けるべきなのは、「この処理が表している知識は、システム内で一箇所に統一されているべきものか」だ。認証・課金・権限判定のように、解釈がずれれば事故になる領域では、コードの見た目が重複していようがいまいが、知識としての単一ソースを維持する設計判断は変わらず必要になる。この判断はAIに委ねられるものではなく、人間が持ち込む設計意図の問題だ。

新しく重要になったのは、「このコードベースは、AIエージェントにとって見晴らしがよいか」という問いだ。マルチレポやサービス境界の切り方によってAIの視界が制限されていると、意味的重複を見落として量産するリスクが上がる63。共通化そのものの是非とは別に、共通化の判断をAIが正しく支援できる環境を整えること自体が、新しい設計課題になっている（この視点をさらに掘り下げた記事は本文末尾で紹介する）。

そして、あえて急がない方がいいのが、「今この重複は、まだ抽象化すべきではないのではないか」という判断だ。AIが早すぎる抽象化を提案してきたときに、それを差し戻すかどうかは、AHA原則が示す通り人間の役割として残る。

まとめ

「AI時代に共通化は意味をなさなくなるか」という問いへの答えは、単純な是非ではない。実証データが示すのは、AIが重複コードを増やしているという事実と、AIが横断的な一括変更のコストを下げているという事実が、同時に成立しているという状況だ。この矛盾は、DRY原則の原典に立ち返り、共通化の価値を「執筆・保守コストの削減」と「知識の単一ソース化」に分けて考えると解ける。前者の必然性はAIによって薄れつつあり、多少の重複はAIに任せて後から畳み直す選択肢が現実的になった。後者の必然性はAIの登場と無関係に残り、AIがコンテキストの外にある実装を見落としやすいという弱点のぶん、意識して守る価値はむしろ上がっている。

早すぎる抽象化への警戒、Sandi MetzやKent C. Doddsが説いてきたAHA原則も同じだ。AIエージェントは指示に対して最短距離で応えようとする。だからこそ「まだ抽象化すべきタイミングではない」とブレーキを踏む役割は、AI以前よりもむしろ人間の手元に残ったというのが、ここまで調べた上での見立てだ。書く量は減っても、判断の量は減っていない。

さらに深く読みたい方へ: 「知識の単一ソース化をどのレイヤーで実現すべきか」という組織・アーキテクチャ設計の具体論は、多段階ハーネスエンジニアリングで扱っている。本記事はその一段手前、「そもそも共通化の目的は何であり、AIはそのうちどこを変えたのか」という原則レベルの整理にあたる。

もう一つの見方: 本記事は「多少の重複は許容し、AIに後から一括で畳み直させればいい」という結論を導いたが、姉妹記事のAIが重複を増やすなら、DRY原則はもっと厳格であるべきだは、同じAI時代のデータから逆の実務的結論、セキュリティや認証など解釈のずれが事故に直結する領域ではむしろ厳格にDRYを運用すべきだという主張を展開している。どちらの立場が自分のチームに合うかは、扱っている知識の性質次第で変わる。両方読んで判断材料にしてほしい。

関連記事

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

参考資料

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

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

  • AHA Programming 内で引用されているConlin DurbinのWET原則定義 - Conlin Durbin (2019). 【信頼性: 中】

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

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

  3. Monorepo vs Multi-Repo: Why AI Agents Tip the Scale - Francis Eytan Dortort. 【信頼性: 中】 ↩︎ ↩︎2 ↩︎3

  4. The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition - David Thomas, Andrew Hunt, Addison-Wesley Professional (2019、原著初版1999). 【信頼性: 高】 ↩︎ ↩︎2

  5. Copy/Paste Detection Report: Vibe-Coded Projects Analysis - jscpdによる49プロジェクト分析レポート (2026). 【信頼性: 中〜高】 ↩︎

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

  7. Don’t repeat yourself - Wikipedia. 【信頼性: 中】 ↩︎

  8. The Wrong Abstraction - Sandi Metz (2016、RailsConf 2014講演を基にした記事). 【信頼性: 中〜高】 ↩︎ ↩︎2

  9. AHA Programming - Kent C. Dodds (2020). 【信頼性: 中〜高】 ↩︎

ソフトウェア設計
DRY原則 ソフトウェア設計 AIコーディング リファクタリング Claude Code 技術的負債
This post is licensed under CC BY 4.0 by the author.