バイブコーディングに最適なアーキテクチャ比較 - なし・VSA・FSD・レイヤードの選び方
バイブコーディングでプロジェクトが崩壊するケースが増えています。原因の多くは「アーキテクチャの不在」。一方で「AIがすべて処理するからアーキテクチャは不要」という主張もある。
正直なところ、プロジェクトの条件次第です。使い捨てプロトタイプなら構造は不要。長期保守が前提なら必須。
2026年の最新議論を踏まえて、5つのアプローチを見ていきます。
アーキテクチャは本当に必要か？
「AIがコード書くならアーキテクチャいらなくない？」という議論、一度は見たことありませんか？
バイブコーディングとアーキテクチャの関係について、2つの対立する見解があります。
不要論の主張
Disposable Code（使い捨てコード） という考え方が注目されています。各コンポーネントを独立してAIに生成させ、APIで接続する。内部実装は他の部分に依存しないから、いつでも差し替えられる。デザインパターンは不要、という発想です。
主な根拠は3つ。
- Pure Vibe Coding: Karpathyの原義通り「HOWを見ない」。結果だけを評価する
- コードは見なくなる: 「人間がコードを気にする時代は終わる」という未来予測
- 速度 > 構造: 今日の速度が、明日の構造より重要
海外の開発者コミュニティでは「Day 1の速度に酔いしれる」という表現が使われています。30秒でランディングページ、5分でDB接続。魔法のように感じる。
必要論の主張
一方で、2026年に入ってベンダー各社がアーキテクチャ重視にシフトしています。
「AIコーディングツールは2026年にリセットを迎える。企業は'vibe coding'の実験段階から、アーキテクチャ重視・ガバナンス重視の共同開発者へとシフトしている」
— IT Brief
主な根拠は4つ。
-
AIの出力品質は設計文書に依存:
ARCHITECTURE.mdがあると提案品質が「劇的に改善」する - 技術的負債の爆発: 「維持コストが初期の速度メリットをすぐに上回る」
- セキュリティ脆弱性: Veracodeの調査によると、AI生成コードの45%にセキュリティ脆弱性が含まれる
- AIはシステム設計が苦手: 関数は書けるが、スケールするシステム全体の設計は人間が必要
面白いのは、Cursor、Lovable、Replitなどのベンダーが「アーキテクチャ・ガバナンス重視」にシフトしていること。vibe codingを推進してきた側が、限界を認識し始めています。
結論：条件次第
| 条件 | 推奨 |
|---|---|
| 使い捨てプロトタイプ | 不要論が有効 |
| 検証目的のMVP | 不要論が有効 |
| 長期保守・スケール | 必要論が有効 |
| チーム開発 | 必要論が有効 |
どちらも正しい。問題は「どの条件で」という文脈が抜け落ちていること。
比較する5つのアプローチ
| アプローチ | 一言で言うと |
|---|---|
| なし（Pure Vibe） | AIに任せる。構造は気にしない |
| VSA（Vertical Slice） | 1機能 = 1フォルダ。レイヤー分離なし |
| FSD（Feature Sliced Design） | 7層構造。AIとの境界が明確 |
| レイヤード | 責任ごとに分離。domain / application / infrastructure |
| ハイブリッド | 機能単位 + レイヤー構造の組み合わせ |
それぞれの特徴と向いているケースを整理しました。
なし（Pure Vibe Coding）
Karpathyが提唱した「vibeに身を任せる」アプローチ。コードの中身は見ない。結果だけを評価する。
特徴
src/
├── なんでもあり
└── AIが生成したまま
構造を定義しない。AIが生成したコードをそのまま使う。
メリット
最速でMVP完成。学習コストゼロ。アイデアを30分で形にできます。
ゲーム開発未経験のデータエンジニアが、バイブコーディングで娘用の迷路ゲームを作り、Google Playのチャートに載った例もあります。
デメリット
Day 3問題。3日目に破綻が始まる。
「Cursorが1時間前に書いたコードを勝手に削除し始める。Claudeはどのpage.tsxを編集しているか混乱する。ボタンの修正を頼んだだけなのに、認証ロジックを書き換えてしまう」
— 海外開発者の報告
実際に試してみると分かりますが、AIがコンテキストを見失い、意図しない変更を加え始めます。
セキュリティリスクも深刻。Lovableで作られた1,645のWebアプリをスキャンした調査では、170アプリに個人情報が誰でもアクセスできる脆弱性がありました。
向いているケース
- 使い捨てプロトタイプ
- 検証目的のMVP（1週間以内に捨てる前提）
- 個人の趣味プロジェクト
- 「動けばいい」ハッカソン
向いていないケース
- 1週間以上保守する予定があるもの
- ユーザーデータを扱うもの
- チームで開発するもの
VSA（Vertical Slice Architecture）
Jimmy Bogard（MediatRの作者）が提唱したアーキテクチャ。「1機能に必要なコードを1フォルダにまとめる」という考え方です。
構造
src/
└── features/
└── users/
├── create-user/
│ ├── handler.ts
│ ├── validator.ts
│ └── types.ts
└── get-user/
├── handler.ts
└── types.ts
Controller、Service、Repositoryのような横の分離はしない。代わりに機能ごとに縦に切ります。
メリット
AIコンテキスト効率が最高。1つの機能を実装するとき、必要なファイルが1フォルダに収まっている。AIが参照するファイルが少なくて済むため、意図通りのコードが生成されやすい。これは地味にありがたい。
Cursor Forumでは、4000行のコードを約30プロンプトでリファクタリングした実績が報告されています。
機能間の独立性が高い。ある機能を変更しても、他の機能に影響しにくい。「1つの機能への変更はそのスライス内に限定される」ため、予期しない副作用を最小化できます。
デメリット
コードが重複しやすい。似たようなバリデーションや共通処理を各機能で書くことになりがち。
依存ルールがない。どこから何を呼んでもいいので、カオスになる可能性があります。
向いているケース
- チーム1-3人の小規模開発
- MVP・プロトタイプ段階
- CRUD中心でビジネスロジックが少ない
- AI活用度が高い（コンテキスト効率重視）
FSD（Feature Sliced Design）
フロントエンド向けのアーキテクチャ手法。7つの標準化されたレイヤーでコードを整理します。2026年、AIコーディングとの相性の良さから注目が高まっています。
構造
src/
├── app/ # ルーティング、エントリーポイント、グローバルスタイル
├── pages/ # 完全なページ
├── widgets/ # 自己完結した大きな機能チャンク
├── features/ # ビジネス価値をもたらす再利用実装
├── entities/ # ビジネスエンティティ（user, product）
└── shared/ # 再利用可能な機能（UI kit, libs）
依存ルール
上位層は下位層にのみ依存できます。
-
app→ すべてを利用可能 -
pages→ widgets, features, entities, shared -
widgets→ features, entities, shared -
features→ entities, shared -
entities→ shared -
shared→ 外部ライブラリのみ
メリット
AIとの境界が明確。Feature-Sliced Design公式ブログでは、フォルダ構造が不明確だとAI生成コードがランダムな場所に散在してしまうが、FSDの依存ルールがあればAIもそれに従わざるを得ない、と述べられています。
AIが生成したコードがどこに属するか明確なので、意図しない結合を防げます。
チームのオンボーディングが速い。あるチームでは、ジュニア開発者が3日で意味のあるコードを書き始めたという報告があります。「構造が論理的なので、レイヤーを理解すればどのFSDコードベースでもナビゲートできる」とのこと。
リファクタリングしやすい。「最大のメリットは見た目の構造ではなく、リファクタラビリティ。境界が明確だと、変更がローカルで予測可能になる」。
デメリット
学習コスト。7層の概念を理解する必要があります。
フロントエンド特化。バックエンドには別のアーキテクチャが必要です。
過剰になりやすい。小規模プロジェクトでは層が多すぎることも。
向いているケース
- 中〜大規模フロントエンド
- チームでの開発
- 長期保守が前提
- AIコーディングを積極的に活用
レイヤードアーキテクチャ
責任ごとにコードを分離する伝統的なアーキテクチャ。Clean ArchitectureやOnion Architectureもこの系譜です。フロントエンドでの導入判断については以下の記事で詳しく解説しています。
構造
src/
├── domain/ # ビジネスロジック、エンティティ
├── application/ # ユースケース、サービス
├── infrastructure/ # API、DB、外部サービス
└── presentation/ # コンポーネント、hooks
依存ルール
- domain は他のどのレイヤーにも依存しない
- application は domain のみに依存
- infrastructure は domain, application に依存
- presentation は全レイヤーを利用可能
このルールがあることで、AIへの指示が明確になります。
❌ 「ユーザー登録機能を作って」
→ AIが全レイヤーを一気に生成、責任の境界が曖昧
✅ 「Repository層にcreateUserメソッドを追加して」
→ 1つのレイヤーに集中、他レイヤーへの影響を最小化
メリット
責任の所在が明確。どこに何を書くかのルールがあるので、AIが迷いにくい。
テストが書きやすい。各レイヤーを独立してテストできます。
// Repository層のテスト - 外部依存をモック
const mockApi = { createUser: vi.fn() }
const repository = new UserRepository(mockApi)
// UseCase層のテスト - Repository層をモック
const mockRepository = { create: vi.fn() }
const useCase = new CreateUserUseCase(mockRepository)
変更の影響範囲が予測しやすい。依存ルールがあるので、どこを変えると何が壊れるか分かります。
デメリット
コンテキストが分散する。1つの機能を実装するために、Controller → Service → Repository と複数ファイルを編集する必要があり、AIのコンテキストウィンドウを圧迫します。
過剰設計になりやすい。小規模プロジェクトでは「実装が3倍複雑になる」という批判もあります。
向いているケース
- チーム5人以上の中〜大規模開発
- 長期保守が前提のプロジェクト
- ドメインロジックが複雑
- テスタビリティを重視
ハイブリッド（Feature-based + レイヤード）
VSAとレイヤードの中間。機能単位でまとめつつ、内部にはレイヤー構造を持たせます。
構造
src/
├── features/
│ ├── user/
│ │ ├── domain/ # User関連のドメインロジック
│ │ ├── application/ # User関連のユースケース
│ │ └── presentation/ # User関連のUI
│ └── order/
│ ├── domain/
│ ├── application/
│ └── presentation/
└── shared/
├── domain/ # 共通のドメインロジック
└── infrastructure/ # 共通のインフラ層
メリット
機能ごとのまとまりと設計原則を両立。関連ファイルが近くに配置されるので見通しが良く、かつ依存ルールも維持できます。
共通化も可能。shared/ に共通ロジックを置けるので、VSAのようなコード重複を避けられます。
デメリット
ディレクトリ構造が深くなる。features/user/domain/entity.ts のように階層が増えます。
featuresの分類基準を間違えやすい。ページ単位ではなく、ドメインコンテキスト（ビジネス上の境界）で分類するのがポイント。
❌ ページや画面単位での分類
features/
├── settings-page/
├── admin-dashboard/
└── user-profile/
✅ ドメインコンテキストでの分類
features/
├── user/ # ユーザーというビジネス概念
├── order/ # 注文というビジネス概念
└── payment/ # 決済というビジネス概念
向いているケース
- 中規模プロジェクト（チーム3-10人）
- ドメインロジックがそこそこ複雑
- AIコンテキスト効率と設計原則の両立を求める
参考データ
バイブコーディングに関する調査・研究データを並べてみました。
AI生成コードのセキュリティ
| 指標 | 数値 | 出典 |
|---|---|---|
| AI生成コードの脆弱性率 | 45% | Veracode GenAI Code Security Report 2025 |
| Lovableアプリの脆弱性調査 | 1,645アプリ中170アプリに脆弱性 | Matt Palmer（Replit）調査 |
開発者生産性
| 指標 | 数値 | 出典 |
|---|---|---|
| 経験豊富な開発者のAI使用時完了時間 | +19%（遅くなった） | METR 2025研究 |
| プロンプト最適化での改善 | 10-15% | Arize AI |
コミュニティ推奨
| 指標 | 数値 | 出典 |
|---|---|---|
| 推奨ファイルサイズ | 500行以下 | Cursor Forum等 |
| VSAでの大規模リファクタリング実績 | 4,000行を約30プロンプトで完了 | Cursor Forum |
METR 2025の研究では、経験豊富な開発者がCursor + Claudeを使用した場合、完了時間が19%増加した（遅くなった）という発見がある。AIツールが必ずしも生産性向上に直結しないケースを示唆している。
選び方：判断基準
| 条件 | 推奨アプローチ |
|---|---|
| 使い捨てプロトタイプ | なし（Pure Vibe） |
| 1週間以内のMVP | なし or VSA |
| チーム1-3人、MVP段階 | VSA |
| フロントエンド中〜大規模 | FSD |
| チーム5人以上、長期保守 | レイヤード or ハイブリッド |
| ドメインロジックが複雑 | レイヤード |
| CRUD中心 | VSA |
| AI活用度が高い | VSA or FSD |
| テスタビリティ重視 | レイヤード |
| 中規模で両立したい | ハイブリッド |
Claude Codeでの実践
どのアーキテクチャを選んでも、CLAUDE.mdでルールを明記しておくと効果的です。Claude Code Hooksを活用した自動化については以下の記事も参考になります。
VSAの場合
## Architecture Rules
このプロジェクトはVertical Slice Architectureを採用しています。
### ルール
- 1機能 = 1フォルダ（features/機能名/）
- 機能間で直接importしない
- 共通処理は shared/ に置く
FSDの場合
## Architecture Rules
このプロジェクトはFeature Sliced Designを採用しています。
### レイヤー構造
- app/ : ルーティング、エントリーポイント
- pages/ : 完全なページ
- widgets/ : 自己完結した機能チャンク
- features/ : ビジネス機能
- entities/ : ビジネスエンティティ
- shared/ : 再利用可能なコード
### 依存ルール
上位層は下位層にのみ依存可能。
例: features/ は entities/ と shared/ のみimport可能
レイヤードの場合
## Architecture Rules
このプロジェクトは3層アーキテクチャを採用しています。
### 依存ルール
- domain/ は他のどのレイヤーにも依存しない
- application/ は domain/ のみに依存
- infrastructure/ は domain/, application/ に依存
### 禁止事項
- domain/ に React hooks を書かない
- infrastructure/ にビジネスロジックを書かない
.claude/rules/ ディレクトリを使うと、ファイルパターンごとにルールを適用できます。
---
globs: ["**/domain/**"]
---
# Domain Layer Rules
このディレクトリはビジネスロジック専用です。
Reactのインポート、fetch/axiosのインポートは禁止。
まとめ
バイブコーディングに「これが正解」というアーキテクチャはありません。
- なし: 使い捨て前提、速度最優先なら
- VSA: AIコンテキスト効率を最優先するなら
- FSD: フロントエンドで境界を明確にしたいなら
- レイヤード: 設計原則とテスタビリティを重視するなら
- ハイブリッド: 両方のバランスを取りたいなら
「アーキテクチャ不要」も「アーキテクチャ必須」も、文脈なしには正しくない。
大事なのは「何かしらの判断をしてAIに伝える」こと。判断が「構造は不要」でも構いません。ただし、その判断を意識的にすること。無意識に流されると、Day 3で破綻します。
あなたはバイブコーディングでどんなアーキテクチャを採用していますか？
Discussion