✏️

5年前に作った設計サンプルをAIで現代化したら、疎結合アーキテクチャの価値が期せずして活用された話

に公開
2026/05/22

放置していたリポジトリを思い出した

2020年頃、フロントエンドでドメイン層とView層を分離する設計の実証サンプルを作った。React、Vue、jQueryという3つの異なるフレームワークで、同じビジネスロジック(ショッピングカートの管理)を共有できることを示すためだ。

当時の考え方は、このスライドにまとめている:
https://speakerdeck.com/tooppoo/web-front-end-design-to-avoid-being-a-fat-component

概念実証として一通り動くものができたので、そのままGitHubに上げて放置していた。


それから約5年。ふと思い出してリポジトリを見ると、Vue2・React17・Lerna・Jestといった構成が、当然ながら2025年の今ではすっかり古い。更新が面倒で放置していたところもあるが、なかなかの化石ぶりだった。

何気なく、「今ならAIがあるし、更新も簡単では?」と思い、試してみた。

結果、想像以上に簡単だった。そして、5年前の設計判断が今回の作業を驚くほど楽にしていたことに気づいた。

リポジトリの構造

packages/
  domain/       # フレームワーク非依存のコアロジック
    ├── model/        # Cart、Item等のドメインモデル
    ├── controller/   # CartInteraction(操作の受け口)
    └── repository/   # データ永続化(インメモリ実装)
  react/        # React実装
  vue/          # Vue実装
  jquery/       # jQuery実装

ポイントは、domainパッケージがReact/Vue/jQueryのいずれにも依存していないこと。ビジネスロジックはすべてdomainに集約され、各フレームワークの実装はこのAPIを呼び出すだけの薄い層として設計されている。

更新作業

基本方針

  1. ドメイン層には触らない(ビジネスロジックは5年前のまま)
  2. ビルド環境を現代化(Lerna→pnpm+Turbo、Jest→Vitest、Vite統一)
  3. フレームワークを最新化(Vue2→Vue3、React17→React18)

実際の手順と結果

  1. monorepo環境の刷新: Lerna → pnpm + Turborepo
  2. ビルドツールをViteに統一: React/Vue/jQueryすべてで
  3. jQuery実装の更新: 手動で最新版に(この実装が次の参考になる)
  4. Vue3への移行: AIに「jQueryの実装を参考にVue3で書き直して」→ ref → shallowRefの1箇所だけ修正
  5. React18への移行: 同様の指示 → AIが生成したコードは100%そのまま動いた
  6. テストの移行: Jest → Vitest、テストコード自体は一行も変更なし

変更の全体像

項目 変更
ドメイン層の実装 0行
View層(Vue) ほぼ全面書き換え(1箇所のみ修正)
View層(React) 全面書き換え(AIが100%完了)
テストコード 0行
ビルド設定 全面刷新
合計 98ファイル変更

なぜこれほど簡単だったのか

View層が薄かった

各フレームワークの実装がやっていることは、つまるところ以下の内容のみ。

  1. ドメイン層のAPIを呼ぶ
  2. 結果を表示する
  3. ユーザー操作をドメイン層に伝える

状態管理やビジネスロジックは、すべてドメイン層にある。View層は本当に「表示するだけ」だからこそ、AIであっても機械的に変換できたのだろう。

ドメイン層の安定性

5年前のコードがそのまま動いている。Vue2・Vue3・React17・React18・jQueryのいずれにおいても、同じAPIを使える。フレームワークが変わっても、ビジネスロジックは変わらないまま、利用できている。

AIとの協働がうまくいった理由

AIが得意だった部分をピンポイントで任せることができたのは大きいと考えている。

  • フレームワークAPIの変更(Options API → Composition API等)
  • 定型パターンの変換
  • jQueryの実装から、Vue/Reactの構造を類推
  • TypeScript型定義の生成

特に印象的だったのは、「jQueryを参考に」という曖昧な指示だけで、慣用的なコードが生成されたこと。AIはドメイン層のAPIを理解する必要すらなく、既存実装から推論できた。

人間が判断した部分は、以下の3点のみ。

  • ドメイン層に触らないという設計判断
  • ビルドツールの選定
  • 「これで十分」というゴール設定

疎結合な設計は、AIが扱いやすい。
View層が薄いから機械的に変換でき、ドメイン層が独立しているから影響範囲が明確。責務分担が明確だから、AIへの指示も簡潔になる。

まとめ:期せずして実証された価値

2020年の主張と2025年の実証

5年前の主張は、「フレームワークとドメイン層を分離すれば、フレームワークの変更に強くなる」だった。
少なくとも5年前の時点で、異なるフレームワーク・ライブラリに対して単一のドメイン実装を提供可能なことは確認できていた。

それが今回のアップデートで、期せずして以下のことも実証できたと思う。

  • ✅ Vue2→Vue3という大きな変更でも、ドメイン層は無傷
  • ✅ 5年経ってもテストは価値を保つ
  • ✅ ビルド環境が完全に変わっても、ビジネスロジックは影響を受けない

予想外の発見として、疎結合な設計は「AIが活用しやすい」ようだ。2020年にはなかった視点だが、View層の薄さが機械的な変換を可能にし、明確な責務分担がAIへの指示を簡潔にしたのだと思う。

教訓

  1. 良い設計は時間を超える - ビジネスロジックはフレームワークより長生きする
  2. AIは良い設計をさらに活かす - 疎結合な構造は、AIの時代により重要
  3. フレームワークは変わるが、原則は変わらない - 変化が速いからこそ、疎結合が重要

限界の認識

サンプル規模だからこそ可能だった面もある。実プロジェクトでは、ドメイン層も進化が必要だし、完全な分離は難しい。それでも**「影響範囲を限定できる」**という価値は変わらないだろう。

このリポジトリの今後

また数年放置することになるだろう。次に触るのは2029年頃か。その時、Vue4やReact20を使うかもしれない。でも、ドメイン層はきっと、また無事だと信じている。

参考リンク

Discussion