AIコード生成時代に「車輪の再発明」と「DRY原則」を考え直す

はじめに

Claude Code などの AI コード生成機能を使って実際にプロジェクトを本格的に回してみると、これまでよりも明らかに効率的にものが作れるようになりました。これは実際に手を動かした上での感想です。設計から実装、テストまで、以前なら「そこそこの時間がかかる」と見積もっていた作業が、体感で何分の一かで実現可能になりました。

その効率の良さを味わっているうちにふと引っかかったことがあります。私たちがこれまで学んできた設計の原則である「車輪の再発明を避けよ」「DRY原則」といったものが、どうも肌に合わなくなってきた瞬間が増えているのです。原則が間違っているわけではないのですが、この状況ではこれらの原則をあえて守らない方がよいのではないか？ と考える場面が以前より確実に多くなっています。そこで一度、AIコード生成という変化を織り込んだ上で、この二つの原則を考え直してみたいと思い、この記事にまとめました。

先に結論を言っておくと、原則そのものの重要さは大きく変わっていません。今も昔も、これらの原則は重要な役目を持ち、開発者であれば修めておく必要がある教養です。一方、変わったのは、原則が作動する「基準」であると捉えています。こちらについては本文で説明します。

「車輪の再発明」と「DRY原則」とは

念のため簡単に補足しておきます。

「車輪の再発明を避けよ」とは、すでに成熟した既製品やライブラリがあるものを、わざわざ一から作り直すな、という戒めです（Wikipedia）。歴史的な根拠は明快で、一から作る総コスト（実装・バグ・テスト・保守）のほうが、既製品を学習して自分の要件を枠に合わせる無理よりも大きかったからです。だから「多少無理してでも既製品に乗る」のが合理的な判断でした。

「DRY原則（Don’t Repeat Yourself）」は、同じ知識をコードの中で二度書くな、一箇所に集約せよ、という原則です（Wikipedia）。これも根拠は二つあります。二度書くのは単純に労力の無駄だという話と、重複はいずれ片方だけ修正されて食い違い、バグになってしまうという話に基づいています。言い換えると「真実は一つの場所に（single source of truth）」という原則を守れ、ということです。

ここでは一つ、あとの議論の鍵になることを指摘しておきます。どちらの原則も、実は二種類の正当化を一つに束ねています。片方は 「労力の節約」（以下、労力側）。もう片方は 「正しさの担保」（以下、正しさ側）――車輪なら蓄積された検証（多くの現場や視点で潰されてきたエッジケース）、DRYなら真実の単一性です。普段この二つは分けて意識されませんが、本記事の議論はこの「労力側／正しさ側」という分解を軸に進みます。

AIコード生成によって変わったこと

AIが確実に下げたのは、ソースコードの書き起こしコスト、つまり「コーディングにかかる労力」です。　一方、既製品が長年かけて蓄積してきた検証の価値は、AIに書かせても手に入りません。

ただし、ここは丁寧に話をする必要があります。ロール付きCRUDのような頻出パターンであれば、学習データに大量に含まれているぶん、AIの出力する「本体」のコードはかなり信頼できるものになっています。この点でAIのコードを一律に「未検証」と切り捨てるのはフェアではありません。
しかし、既製品の検証価値の本体はそこではありません。何千という現場で実際に踏まれ、報告され、修正されてきたエッジケースの網羅こそが価値であり、これは学習データに含まれていたとしても、その場の一回の生成で正確に再現されることは（ほぼ）ありません。頻出パターンの幹は書けても、枝葉の異常系まで揃った状態では出てこない、と言うのが正確でしょう。既存コードが持つ「実際に動いていた」「そのための検証が行われてきた」という強みは、依然としてその場で出力されたAIのコードには無いものです。

まとめると、AIは労力側は解決してくれるのですが、正しさ側は完全には解決してくれません（むしろ、疑うべき箇所になります）。すると、束ねられていた二つの正当化が分離します。

労力だけが理由だった適用箇所では、その理由が消えるので原則が発火しなくなります。かつて「ライブラリがあるんだから再発明するな」と言われていたもの、例えば、ロール付きのCRUDや、コンテンツページの管理といったものは、もはや「車輪」と呼ぶほどのものではなくなります。書き起こしがほぼタダになった今、少しでも「本来欲しいものと違う」と思ったのであれば、それらは再発明の対象から静かに脱落することになるでしょう。

一方、正しさが理由の箇所では、原則はそのまま生き残ります。例えば、暗号、決済、エンコードエンジン、ブラウザ、DBエンジン。これらを既製品に任せるべきなのは、作るのが難しいからというより、時間をかけた検証を短絡できないからです。ここでの判定は変わりません。むしろ労力という濁りが抜けたぶん、「これは検証の蓄積そのものに価値があるのか、それとも単に書くのが面倒なだけだったのか」という本当の問いが、以前よりくっきり見えるようになります。

「所有コスト」という反論に答える

ここで、想定される反論に先に答えておきます。「コードのコストは書き起こしではなく、その後の保守・改修・セキュリティ対応・引き継ぎの方が大きい。ライブラリに乗る利点は初期労力の節約ではなく、上流が脆弱性を直し続けてくれること、新しいメンバーが公式ドキュメントで学べることにある。フルスクラッチした瞬間、そのコードの将来を全部自分たちが背負うことになるが、AIはそこまで肩代わりしてくれないのではないか」という指摘です。

これはまったく正当な指摘で、私の言う「労力側」を初期実装コストだけに矮小化してはいけません。判断の天秤に載せるべきは総所有コストです。

その上で、二点述べておきます。

第一に、AIが下げているのは初期実装コストだけではない、というのが実感です。生成したコードは自分たちの要件だけを含む小さなコードベースになり、AIに読ませて改修させることも、挙動を説明させることも容易です。巨大な汎用フレームワークの内部を追いかけるより、自案件専用の数千行を保守する方が、AI併用下では軽いことが珍しくありません。つまり保守労力もゼロにはならないまでも、以前の見積もりのままではなくなっています。

第二に、それでもなお動かない領域があります。上流が継続的に配ってくれるセキュリティパッチや、脆弱性報告のエコシステムは、自作コードには付いてきません。これは労力の問題ではなく、外部の目による継続的な検証、つまり正しさ側の資産です。だからこそ、認証・暗号・入力境界のような攻撃対象になる層は、AI時代でも既製品に乗るべきという判断になります。 所有コストの反論は、本記事の分解を崩すものではなく、むしろ「労力側と正しさ側を混ぜずに天秤に載せよ」という同じ結論を補強するものだと考えています。

DRYも同じ視点で語れる

DRYもずっと「二度書くのは無駄」＋「真実は一つでなければならない」の束でした。ただし、車輪のときより一段丁寧に見る必要があります。

DRYの労力側の価値は「守っていれば修正は一箇所で済む」という点にあります。裏返せば、破った場合に「重複したN箇所を仕様変更のたびに同期して直し続ける保守労力」が発生する、その回避こそが本丸であって、タイプ量の節約ではありません。

ここで、原則の基準が動いたかどうかは、この「破った場合のコスト」をAIがどれだけ下げたかで判定されます。車輪の再発明では、破った場合のコスト（＝自分で書き、保守するコスト）をAIが激減させるパターンがあるため、原則が発火しなくなりました。

ではDRYはどうか。AIは複数箇所の同期修正を人間よりは網羅的にこなしてくれますが、「N箇所を同時に正しく直す」作業の修正漏れ・不整合リスクをゼロにはしてくれません。破った場合のコストは依然として高いままです。つまりDRYは、車輪の再発明ほどには労力側が溶けていない原則です。

それでも基準は動いています。ただし、動いたのは先ほどの判定軸でいう「破るコスト」ではありません。恒久的に重複を抱え続けるコストは、今も高いままです。安くなったのは、「本当に同じ知識だと確信できるまで重複を許して待ち、確信してから寄せる」という先送りのコストの方です。車輪では「破ってよいかどうか」の閾値が動いたのに対し、DRYで動いたのは「いつ寄せるか」というタイミングの閾値だ、と整理できると考えています。

かつては「似ているから」という理由だけで無理に共通化し、本当は別の知識であるものを一つの関数に押し込めて、条件分岐まみれの抽象を作ってしまうことがよくありました。共通化のコスト（設計と、外れたときの解体）と、二度書くコストの比較で、後者が重かったからです。書き起こしと書き直しが安くなった今、「偶然似ているだけのもの」はためらわず二度書き、本当に同じ知識だと確信できてから共通化する、という順序が取りやすくなりました。DRYが「タイプ量の節約」として発動していた箇所は役目を終え、システムの設定値、正規の税率、システム上の時刻といった、本当の意味で「真実を単一に保つべき場所」だけが残ります。

もう一つ、AI時代ならではの逆方向の論点も挙げておきます。重複だらけのコードベースは、AI自身にとっても扱いにくいのです。同じ知識が散らばっていると、AIに修正を指示したときにコンテキストを圧迫し、修正漏れや不整合な変更を誘発します。「真実は一つの場所に」は、人間のためだけでなく、コードを読むAIエージェントのための原則にもなりつつあります。DRYの正しさ側は、AI時代にむしろ重要度を増している、というのが著者の見立てです。

まとめると、車輪の再発明もDRYも、同じ軸で説明がつきます。労力側が（程度の差はあれ）溶けて、正しさ側がむき出しになったのです。

基準が動いたと感じた例

抽象論だけでは弱いので、実際に判断を変えた案件を挙げます。

ある動画配信系の案件で、当初は WordPress（YouTube や Vimeo などの貼り付けによる動画ページ管理）＋ Laravel（会員管理）の二本立てが想定されていました。コンテンツページの管理には WordPress があるのだからそれを再発明せず、あまり本格的でない WordPress の会員管理は外に出して別システムで受け持ち、両者を組み合わせるという構成です。これは弊社で提案しているパターンの一つでもあり、発想としては自然なものでした。

しかし、この設計に違和感を覚えた私は、Laravel 一本でのフルスクラッチを提案しました。

一番大きな理由は、動画まわりのバックエンド処理でした。動画の管理機能では独自エンコード用マイクロサービス（あるいは Vimeo）との連携になり、アップロード受付→API連携→エンコードジョブ投入→Webhook受信→内部の動画エンコードステータス更新という、能動的なバックエンド処理が必要になります。こうした処理には遅延実行の仕組みが要りますが、WordPress はそもそもそれを想定した作りになっておらず、実現にはかなりの工夫を強いられます。一方 Laravel は scheduler や queue / job の仕組みを標準で備えており、こうした処理を素直に書けます。

ここまでは純粋に技術的な理由であり、正直に言えば、AI以前から成立する判断材料です。的確な指摘をする読者なら「それは普通のアーキテクチャ選定の話では？」と思うでしょう。しかし、AI以前の私であれば、この違和感を抱えたまま、それでも WordPress 案を飲んでいた可能性が高いのです。管理画面・投稿一覧・権限まわりを一から作るコストが重すぎて、「多少のハックを我慢してでも既製の管理画面に乗る」方が天秤で勝っていたからです。AIコード生成は、この「管理機能を一から作る」側の皿を軽くしました。天秤が傾いたのはAIのせいであり、まさに基準が動いたと実感した瞬間でした。

ここまでは労力側の話でした。残る正しさ側から捉え直すと、同じ結論にもう一つの理由が加わります。この案件で WordPress に動画ページ管理をやらせるという発想は、WordPress の検証価値を回収する使い方ではありません。エンコードのような非同期処理を投稿編集のフローに差し込むには、WordPress が想定していない作りへ管理画面を改造することになり、これはカスタム投稿タイプや functions.php のフックによる枠外へのハックです。再利用しているつもりの「車輪」が、この使い方では実のところ何の検証価値も提供していないどころか、本来テストされていない領域に自分で踏み込むことになります。労力側の理由が消えた瞬間、この構成に残っていたのは「正しさ側の価値ゼロの車輪」だけだった、ということです。

つまり「管理画面を再利用する」よりも「必要な管理機能を一から作る」方がよい。そう結論づけた一例です。

念のため補足すると、これは WordPress を否定する話ではまったくありません。WordPress が本来のブログ・メディア用途に使われるなら、定型・編集UI・エコシステムというフルセットの価値がきちんと効きます。線が動くのは、あくまで枠外の使い方をしたときだけです。

まとめ

「車輪の再発明を避けよ」も「DRY」も、廃れてなどいません。変わったのは、原則が作動する基準から「労力側」の部分がコードの自動生成によって取り除かれ（あるいは大きく軽くなり）、本来の「正しさ側」のためであるという部分がむき出しになった――そう捉えるのが正確だと思います。

ただし、労力側を初期実装コストだけで測ってはいけません。保守・セキュリティ・引き継ぎまで含めた総所有コストで天秤に載せること。そして、外部の継続的な検証（上流のパッチ、コミュニティの目）は労力ではなく正しさ側の資産であり、AIでは代替できないこと。この二点を踏まえた上でなお、以前なら既製品一択だった領域のかなりの部分で、天秤が動いていると感じています。

この記事は「再発明せよ」という呼びかけではありません。反射で従うのをやめて、自分の文脈で損益分岐点を計算し直そう、というだけの話です。AIが前提の一つを動かした以上、その計算は一度やり直す価値があると思います。