はじめに
Dress Code 株式会社のかわうそです。
今日はとある記事をきっかけに、AI時代における設計やアーキテクチャで大事なことについて考えてみたので、その内容を共有したいと思います。
TL;DR
気になったきっかけ
最近、とある記事を見かけました。
この記事の中で紹介されている"Mutable Code Accumulates Entropy"という部分が気になったので、少し考えてみました。
Mutable Code Accumulates Entropy
In-place modification has a hidden cost profile. Incremental edits entangle intent with the sequence of changes that produced them. Code gets layered atop code (this is why developers often prefer to use git rebase instead of git merge). Local fixes obscure global behavior. Understanding requires replaying the evolution of the codebase in your head — archaeology instead of engineering.
This is exactly how legacy systems are born. Not through age, but through mutation. A system becomes legacy when understanding it requires historical knowledge that isn't encoded anywhere except the code itself.
The tragedy is that teams recreate this failure mode faster with AI, because mutation feels cheap while understanding quietly becomes expensive. You can generate a thousand lines in seconds. But the moment you start editing those lines, you've created an artifact that can only be understood historically. You've created brittle legacy code in an afternoon.
Replacing code avoids this entirely.
簡単に要約すると、「インクリメンタルな編集は意図を曖昧にし、レガシーを生む。AIはミューテーションを簡単に感じさせるが、理解コストを高める。生成は速いが、編集は脆いレガシーを数時間で作る。代わりに再生を推奨。」という内容です。
インクリメンタルにやるからレガシーになるっていうのも納得感がありました。仕様がインクリメンタルになると、複雑になりやすいし、特に仕様とコードは一致されなくなっていくイメージはとてもあります（そうやって崩れてきたなという経験もあります笑）
また、AIによる開発がより現実的になり、ゼロから作り直すコストが劇的に下がりました。AI的にも（人間的にも）「少しずつ直す」より「仕様から全部再生する」方が楽でかつ正確で速いと思います（人間としては速くはならないかもしれないですが）
つまり、AIにとっては、インクリメンタルに編集するより、再生できる（既存の仕組みを破壊して作り直せる）状態の方が向いており、破壊性（Destroyability）と回復性（Recoverability）が大事なのではないかと思ったので、この中身についてつらつらと語ってみたいと思います。
なぜ、インクリメンタルな変更がエントロピー（レガシー）を生むのか？
ソフトウェアにおけるエントロピーとは、システムの「理解しにくさ」や「予測不可能性」の度合いだと考えられます。
達人プログラマーでは、ソフトウェアの劣化を"割れ窓理論"になぞらえて説明しています。
建物の割れた窓を放置すると次々に荒廃が進むように、コードベースの小さな劣化を放置すると、それが連鎖的にシステム全体の品質を蝕んでいくという考え方です。インクリメンタルな変更は、まさにこの「割れ窓」を積み重ねるリスクを表しています。
では、なぜインクリメンタルな変更がエントロピーを増大させるのか、考えてみたいと思います。
意図の地層化
コードに変更を重ねるたびに、「なぜそうなっているのか」という意図が地層のように積み重なっていきます。最初の設計意図の上に、バグ修正の意図、仕様変更の意図、パフォーマンス改善の意図が折り重なり、現在のコードがどの意図を反映しているのか判別できなくなります。
先ほど引用した記事で"archaeology instead of engineering"（エンジニアリングではなく考古学）という表現があり、まさにこの状態を表していると思います。
局所最適がグローバルな整合性を壊す
インクリメンタルな変更は「今ここだけ直せばいい」という局所的な判断で行われがちです（他人事ではありませんね笑）
個々の修正は正しくても、それらが積み重なると全体の設計思想との乖離が徐々に広がります。関数の責務が曖昧になり、モジュール間の依存が複雑化し、最終的には「触ると何が壊れるかわからない」状態にすら陥ります。
仕様とコードの乖離
仕様自体もインクリメンタルに変化していく中で、コードだけが過去の仕様の痕跡を残し続けます。「この条件分岐はなぜ存在するのか？」という問いに対して、コードを読むだけでは答えが得られず、当時のPRやドキュメントを遡る必要があります。
つまり、レガシーとは時間の経過によって生まれるものではなく、変更の積層によって生まれるものだと考えることができます。
そして、AIの登場により、この積層の速度が加速している可能性もあると考えられます。
AI時代のパラダイムシフト
AIがまだ開発の大部分を担う前は、既存コードを修正することが基本の戦術だったと思います。
ゼロから書き直すにはコストが高すぎるし、たとえ設計が歪んでいても既存のコードに手を入れる方が合理的なことが多かったのではないかと思います。
これは当然の判断だと思うし、修正コスト ＜ 再構築コストという前提のもとでは、インクリメンタルな変更が最も合理的な選択肢だったはずです。
しかし、現在、AIによるコード生成の精度と速度が劇的に向上したことで、この前提が崩れつつあります。仕様さえ明確であれば、AIが数分でモジュール単位のコードをゼロから再生成できるようになりました。
特定の領域で修正コスト ＞ 再構築コストという逆転が、現実的に起き始めていると考えられます。
これは開発における根本的なパラダイムシフトであり、「壊れたコードを少しずつ直す」のではなく「壊して、仕様から再生する」というアプローチが現実的になってきたのではないかと思います。
先ほど引用した記事にあった"Replacing code avoids this entirely"（コードを置き換えればこの問題は完全に回避できる）という主張が、AIの進化によって現実味を帯びてきたと思います。
ただし、このアプローチを実現するためには前提条件があると思っており、それが安全に壊せて、確実に再生できる構造になっているということです。
破壊性（Destroyability）と回復性（Recoverability）
「安全に壊せて、確実に再生できる構造」を「安全に壊せる」= 破壊性（Destroyability）と「確実に再生できる」= 回復性（Recoverability）として、2つの概念に分けて整理してみます。
破壊性（Destroyability）とはなにか？
破壊性（Destroyability）とは、システムの特定の範囲を破壊しても、その影響をその範囲内に留められる性質のことだと考えています。
たとえば、あるモジュールを丸ごと削除したときに、他のモジュールが連鎖的に壊れるなら破壊性は低い。逆に、そのモジュールだけが消えて他は何事もなく動き続けるなら破壊性は高い。
近い概念として、Martin Fowlerが提唱したSacrificial Architecture（犠牲的アーキテクチャ）があります（今回の記事を書いていたら見つけました）
これは「最初からいずれ捨てることを前提にシステムを設計する」という考え方です。eBayがPerl → C++ → Javaと段階的に書き直してきた事例が紹介されており、各段階のシステムはその時点では正しい選択だったとされています。
この概念自体はAI以前から存在していましたが、AIの登場によって「壊して再生するコスト」が劇的に下がったことで、より現実的なアプローチとなりつつあると考えています。
回復性（Recoverability）とはなにか？
回復性（Recoverability）とは、破壊した部分を新しいものに差し替えて、目的の機能を再び実現できる性質のことだと考えています。
破壊性が「安全に壊せること」だとすれば、回復性は「壊した後に確実に再生できること」が必要です。
仕様が明確に定義されていて、インターフェース（契約）が守られていれば、中身の実装をAIがゼロから再生成しても問題なく動くという状態が回復性の高い状態だと思います。
ただし、この2つはセットで機能します。
破壊性だけが高くても再生できなければ意味がないし、回復性だけが高くても壊すと他に波及するなら怖くて壊せません。両方が揃って初めてパラダイムが成り立ちます。
破壊性と回復性が高い状態とは？
具体的にどんな状態が該当するのか、コードとデータの観点で考えてみます。
コード観点
コードにおいては、SOLID原則が守られている状態が近いと思います。
単一責任の原則（SRP）により、1つのモジュールは1つの理由でしか壊れないので、破壊の影響範囲が限定されます。
開放閉鎖の原則（OCP）により、変更は既存コードの修正ではなく新しい実装への置き換えで対応できるので、壊した後にインターフェースを満たす新しい実装を差し込めばいい状態となります。
さらに、リスコフの置換原則（LSP）は「インターフェースを満たす実装であれば、差し替えても振る舞いが保証される」という原則であり、まさに回復性の理論的根拠とも言えます。
依存性逆転の原則（DIP）は「具象ではなく抽象に依存する」ことで、実装の差し替えを構造的に可能にします。
たとえば、通知処理モジュールのロジックが陳腐化しても、インターフェースが明確であれば中身だけをAIに再生成させて差し替えられるということです。
データ観点
データにおいては、イベント（変化）から状態（Read Model）を再生成できる状態がイメージとして近いと考えています。
イベントと状態が分離されていれば、たとえ、現在の状態を壊してもイベントから新しい状態を作り直せばいい状態にすることができます。つまり、イベントさえ正しく残すことができれば、新しい状態をゼロから再生成できる状態となります。
たとえば、集計用のRead Modelが要件に合わなくなったとき、既存のRead Modelを捨てて、新しいRead Modelをイベントから再生成するだけで済むということです（こんな簡単な話ではないと思っていますが笑）
破壊性と回復性を高めるために必要なこと
ここまで「破壊性と回復性が高い状態」をコードとデータの観点で整理してきました。
では、実際に実現するためには何が必要なのかというと 「事実を丁寧に残す」 ことが必要だと考えています。
仕様も、変化も、決定も、すべてを「後から再生可能な事実をSingle Source of Truth（SSoT）」として記録し続けることが破壊性と回復性を高める鍵だと考えています。
たとえば、ADR（Architecture Decision Records）は、アーキテクチャ上の決定とその理由を軽量なドキュメントとして記録し続ける手法です。
「なぜその設計にしたのか」という事実を残しておくことで、再生時にAIが正しい判断を再現しやすくなります。
余談ですが、Dress Codeでは"Any Decision Record"として、アーキテクチャだけでなくプロダクトに関わる意思決定（Any）を記録する仕組みを構築しています。
コード観点：仕様を唯一の真実の源（SSoT）にする
コードを「少しずつ編集」するのではなく「仕様から再生」するためには、仕様自体が明確で信頼できるSSoTな状態 な状態でなければなりません。
ここで最近普及しはじめた SDD（Spec-Driven Development / 仕様駆動開発） が有効なのかもしれません。GitHubが公開したSpec Kitをはじめ、Technology Radarでも取り上げられるなど、AI時代の本流になりつつあります。
Technology Radar Techniques ※ 2026/03/01現在
仕様がSSoTな状態でかつ、インターフェース（契約）を明確に記述しておくことで、コードを破壊して再生するのは比較的やりやすくなるかもしれません。
その上で、先ほど述べたSOLID原則を遵守した実装やDDD・Clean Architectureなどのアーキテクチャにより部分的な破壊と回復が行いやすくなると考えています。
データ観点：イベント（変化）を丁寧に残す
データの場合は、「何が起きたか」という事実を不変に記録することが重要だと思います。
つまり、「何が起きたか」という事実＝SSoTな情報であり、イベント（変化）を丁寧に残すことで、記録することができます。その上で、事実を元に状態（Read Model）を構築できる状態にすることで、破壊して再生が行いやすくなります。
この状態であれば、状態（Read Model）を破壊してもイベント（変化）から再生できる状態となります。
この実現方法として、"Event Sourcing + CQRS"を組み合わせた設計がとても有効だと考えています（ここに誘導したかったわけではないです笑）
まとめ
AI時代においてインクリメンタルな変更がエントロピー（レガシー）を加速させるリスクがあり、それに対するアプローチとして破壊性（Destroyability）と回復性（Recoverability）の向上が大事なのではないかと考えています。
コードにしろデータにしろ共通して重要なのは 「事実を丁寧に残すこと」 です。
事業やプロダクトにおいても大事なことかもしれません。
2026年現在、「SaaS is Dead」論が話題になっていますが、その中で共通して 「AIエージェント時代に生き残るには信頼できる事実を記録するSoR（System of Record）が必要」 とも言われています。これは事実さえ残っていれば壊して再生できるという文脈も含まれるのではないかと考えています。
AIは「生成」は得意ですが「事実」は作ってくれません。
だからこそ、AIが安心して読み書きできる仕組みの構築が必要になるはずです。
Dress Codeでは「Core DB」という概念が存在しており、全てのビジネスアプリケーションから共通して利用されるOne DB/One Factとなるデータベースの構築を目指しています。コンパウンドの推進上において最も重要な要素であり、SSoTな状態の構築を行っています。
次は、Dress Codeにおける「Core DB」という概念をどのように実現しようとしているかについて記事にまとめようと思います。
Discussion