Vertical Slice ArchitectureはなぜAI開発と相性がよいのか：1スライス＝1コンテキストという設計原理

• 想定読者： アーキテクチャ選定に関わるソフトウェアエンジニア、テックリード、AIコーディングツール（Claude Code、Cursor、Copilot等）を日常的に使う開発者
• 前提知識： レイヤードアーキテクチャ、Clean Architecture、DDDなどの基本概念、AIコーディングツールの基本的な使用経験
• 所要時間： 25分

概要

GitHub Copilot、Cursor、Claude Codeといった大規模言語モデル（LLM）ベースのコーディングツールが日常の開発に浸透するにつれ、「どのアーキテクチャがAI支援開発と相性がよいのか」という問いが現実的な設計判断となってきた。

その答えとして近年注目されているのが、Jimmy Bogardが2018年に提唱したVertical Slice Architecture（VSA）¹だ。VSAは「機能ごとに垂直に切り分け、1スライス内で必要なコードを完結させる」という設計原理で、伝統的なレイヤードアーキテクチャやClean Architectureとは異なる組織化を行う。

この構造は、AIコーディングツールに渡す「コンテキスト」の単位と自然に一致する。Rick Hightowerは2025年4月の記事で、VSAは「特定機能に関連するすべてのコードが1ディレクトリに含まれるため、AIツールが全体像を把握しやすく、トークン消費も大幅に削減できる」と論じている²。Basti Ortizも2025年初頭、コーディングエージェントが「深さ優先」でリポジトリを探索する性質と、機能単位の縦割り構造が噛み合うことを指摘した³。

ただし、VSAは万能ではない。コードの重複を生みやすく、共有ロジックの管理に注意が必要であり、Copilotが構造を崩す事例も報告されている⁴。本記事では、VSAの原典に立ち返って基礎を整理した上で、Layered/Clean/FSDといった他手法との違い、AI親和性の根拠、Next.jsとGoでの実装上の選択肢、そして現実的な留保までを順に検証する。

Vertical Slice Architectureとは何か

Bogardの原典に戻る

VSAの原典であるBogardの2018年4月の記事¹は、わずか数千語の短いブログ記事だが、設計の核心を明確に定式化している。

“Minimize coupling between slices, and maximize coupling in a slice.” （スライス間の結合は最小化し、スライス内の結合は最大化する）

ここでいう「スライス」は、HTTPリクエストやユースケースのような個別の要求（distinct request）を指す。フロントエンドからバックエンド、データアクセスに至るまで、その要求を満たすために必要なすべての関心事（concerns）を1つのまとまりとして扱う、という考え方だ。

Bogardが解決したかったのは、伝統的なレイヤード構造で起きる以下の問題だった：

1. 横断的変更コスト：1機能を追加するためにController → Service → Repositoryと複数レイヤーを横断する必要がある
2. 過剰な抽象化：Repositoryパターンのような共通抽象が、実際には機能ごとに異なる要件を強引に1つの形に押し込めてしまう
3. モック過剰：レイヤー間のインターフェース境界が多いほど、テストでモックを大量に書く羽目になる

VSAは、これらを解消するために、「変更の軸」に沿って結合するという発想を採用した。ある機能を変更したいなら、1つのスライスフォルダだけを開けば、UI・APIハンドラ・ビジネスロジック・データアクセスがそこに揃っている――この状態を目指す設計である¹。

構造の典型例

具体的なフォルダ構造は言語・フレームワークによって異なるが、共通する形は以下のようなものだ：

features/
├── creating_product/
│   ├── command.go         # コマンドオブジェクト
│   ├── handler.go         # ビジネスロジック
│   ├── endpoint.go        # APIエンドポイント
│   ├── dto.go             # 入出力データ
│   └── handler_test.go    # テスト
├── getting_product_by_id/
│   ├── query.go
│   ├── handler.go
│   ├── endpoint.go
│   └── dto.go
└── updating_product_price/
    └── ...
shared/                    # 真に共有すべきものだけを最小限に

これはGoのVSAテンプレート⁵に基づく構造例だが、.NET、Next.js、Pythonでも本質は同じ――「機能フォルダの中に、その機能を完結させるコード一式が入っている」という形になる。

他のアーキテクチャ手法との違い

VSAの位置づけを正しく理解するには、よく対比される手法との違いを整理しておくのが早い。

flowchart TB
    A[アーキテクチャ手法] --> B[技術レイヤー軸<br>で分割]
    A --> C[機能/スライス軸<br>で分割]
    B --> D[Layered<br>N-Tier]
    B --> E[Clean / Onion<br>Hexagonal]
    C --> F[Vertical Slice<br>Architecture]
    C --> G[Feature-Sliced<br>Design FSD]
    F --> H[スライス内は<br>自由・最小ルール]
    G --> I[スライス内も<br>層的ルールあり]

vs Layered Architecture

Layered（N-Tier）はUI層 → ビジネス層 → データ層という水平の技術レイヤーでコードを分ける。1つの機能を追加するには複数のレイヤーを横断的に編集することになり、変更点がプロジェクト全体に散らばる。

VSAはこの構造を意図的に解体する。スライス間の共通抽象を最小化し、機能ごとに最適な実装を選べるようにする。Bogard自身が原典で「Controller → Service → Repositoryの周りに不必要な抽象が作られている」と指摘している通り、レイヤード構造への直接的なアンチテーゼがVSAの出発点である¹。

ただしこれは「レイヤード=悪」という単純な話ではない。小規模アプリや、技術スタッフのスキルセットが層単位（DBA、フロントエンドなど）で分かれている組織では、レイヤードのほうが理解しやすい場合もある。

vs Clean / Onion / Hexagonal Architecture

Clean Architecture（およびその同類であるOnion、Hexagonal/Ports & Adapters）は、「依存方向の制御」を中心原理とする。ビジネスロジックを中央に置き、外側の層が内側に依存する一方向の構造を厳格に保つ。

VSAとClean系の違いは、抽象化の量にある。Cleanはユースケース・エンティティ・リポジトリ・プレゼンターといった役割を明確に分け、各層の責務を厳格に切り分ける。一方VSAは、それらの境界を意図的に取り払い、機能ごとに必要な実装を直接書く。

両者は排他ではなく、ハイブリッド利用が現実的によくある。dev.toのrexebinによる比較記事は、自身の本番アプリで「Cleanのレイヤー構造（Domain/Application/Presentation/Infrastructure）の中に、Application層をVSAで組織化する」という両立アプローチを採用している⁶。

vs Feature-Sliced Design（FSD）

FSDはVSAと同じく機能軸での分割を行うが、より構造化されたルールを持つ⁷：

• 層の階層：App / Pages / Widgets / Features / Entities / Sharedの6層構造（公式にはProcesses層を含む7層だが、Processesはdeprecated）
• 同層スライス間の依存禁止：「同じ層のスライスは互いに参照できない」という明示ルール
• スライス内のセグメント分け：ui / api / model / lib / configといった技術的セグメント

これに対しVSAは、スライス内での組織化に明示的なルールを課さない。「最小主義」の方がVSAの思想に近く、FSDは「フロントエンド向けに最適化された規律あるVSA派生形」と位置づけるのが正確だろう。

vs CQRS

CQRS（Command Query Responsibility Segregation）はコマンド（書き込み）とクエリ（読み取り）の責務を分離するパターンであり、VSAのようなアーキテクチャ全体の組織化原理ではない。

ただし両者の相性は良く、特に.NETエコシステムではVSA + CQRS + MediatR（リクエスト/ハンドラの仲介ライブラリ）の組み合わせが定番化している。Goエコシステムでも、mehdihadeli/go-vertical-slice-template⁵のように、Go-MediatRを介してVSAとCQRSを組み合わせる実装が公開されている。

なぜAI支援開発と相性がよいのか

ここからが本記事の核心である。VSAがAIコーディングツールと高い親和性を持つ理由を、3つの観点から整理する。

観点1：コンテキストウィンドウの効率化

LLMは「コンテキストウィンドウ」と呼ばれる入力長の上限を持つ。Claude Sonnet 4.5で標準200Kトークン、ベータ版で1Mトークンに達するが、長ければ良いというものではない。

開発者コミュニティでは、いわゆる「40%ルール」が経験則として共有されている。Basti Ortizが2026年1月の記事で言及している通り、「LLMはコンテキストウィンドウの40%を超えると出力品質が著しく低下する」というアネクドータルな観察だ³。これは学術的に確立された数値ではなく、開発者の経験則であることに注意が必要だが、現場の感覚として広く受け入れられている。

VSAでは、機能を実装・修正するときに必要なファイルが1ディレクトリに集約されている。AIに「このフォルダ全体を読んで、新しいエンドポイントを追加して」と指示すれば、コンテキストとして渡すべき情報が自然に必要十分の範囲に収まる。

一方でレイヤード構造では、1つの機能変更でController、Service、Repository、DTO、Test、Migrationといったファイルがプロジェクト全体に散らばっている。AIにすべてを把握させようとすると、無関係なクラスやヘルパーまで一緒に読み込ませることになり、トークン効率が悪い。Hightowerが2025年4月の記事で指摘した通り、「Layered Architectureは、AIツールが複数ファイル・複数レイヤーを跨いで動作する必要があり、トークン消費が増える」という構造的な不利がある⁸。

観点2：変更の局所性とエージェントの独立動作

近年のAIコーディングは、単発の補完から「エージェント的な自律動作」へとシフトしている。Claude Code、Cursor Composer、CopilotのAgent Modeなど、AI自身がファイルを探索・編集・テスト実行までを行う。

このとき、変更が1スライスに閉じていることの価値は大きい。Ortizは「自己完結したモジュールは、増分的な機能追加（高速イテレーション）と並行実装（マージ衝突なし）を促進する」と論じている³。複数のエージェントを並列で動かしても、機能ごとにスライスが独立していれば衝突しにくい。

逆に、横断的な共有抽象（巨大なService層、共通Repositoryなど）が多いプロジェクトでは、AIが1つの変更を加えるだけで、想定外のファイルにまで波及効果が出てしまう。これは人間の開発でも同様の問題だが、AIの場合は「副作用がどこまで及ぶかを完全に把握しきれない」リスクがより顕在化する（AI生成コードが密結合を生みやすい構造的問題については、AIペアプログラミングが生む密結合の罠で詳しく扱っている）。

観点3：Few-shot生成サイクルとの相性

観点1（コンテキスト効率）・観点2（変更の局所性）はAIに「読ませる・書かせる」ときの境界の話だが、観点3は「生成サイクルの再現性」の話だ。

VSAでは、1つのスライスが完成すると、それが次のスライスの「型」になる。AIに対して「features/creating_product/の構造とテストパターンを参照して、features/creating_order/を同じスタイルで作って」と指示すれば、命名規約・エラーハンドリング・バリデーションロジック・テストの粒度までが自動的に踏襲される。これはFew-shot prompting（既存の例を参照させて新しい出力を生成させる手法）の最も効率的な使い方であり、レイヤード構造では同じ精度で再現することが難しい。

このサイクルが回り始めると、機能追加のたびにAIへの指示が短くなっていく。最初のスライスは詳細な要件と規約を伝える必要があるが、3つ目・4つ目は「既存の◯◯と同じパターンで、フィールドだけこう変えて」だけで済むようになる。CodemagのJohn Millerは2026年3月の記事で、AI支援によるグリーンフィールド開発において「ドメインの事実 → ワークフローの棚卸し → スライスへのマッピング → 依存図 → 実装順序」というスライス単位の計画立案を推奨しているが⁹、これはまさにFew-shot生成サイクルを前提とした計画術と言える。

flowchart TB
    A[新機能追加の要求] --> B{アーキテクチャ}
    B -->|Layered| C[Controller編集]
    C --> D[Service編集]
    D --> E[Repository編集]
    E --> F[DTO編集]
    F --> G[Test編集]
    G --> H[コンテキスト散在<br>トークン非効率]
    B -->|VSA| I[features/new_feature/<br>フォルダを作成]
    I --> J[1ディレクトリ内で<br>すべて完結]
    J --> K[コンテキスト局所化<br>AIが理解しやすい]

技術スタック別の実装パターン

VSAの本質は構造原理であり、特定の言語に縛られない。ただしエコシステムによって典型的な実装パターンが異なる。

Next.js（App Router）でフロントエンドを含む場合

Next.js 15以降のApp Routerは、ディレクトリベースのルーティングとServer Components / Server Actionsという仕組みを持っており、VSAと自然に噛み合う。Farzaneh Haddadiは2025年11月の記事で、以下のような構造を推奨している¹⁰：

app/(dashboard)/
├── _components/    # ダッシュボード全体で共有するUI
├── _hooks/         # 共有ロジック
├── _services/      # 共有ネットワークヘルパー
├── _utils/         # 小さなユーティリティ
├── products/       # 機能スライス：商品
│   ├── page.tsx
│   ├── _components/
│   ├── _services/
│   ├── _schemas/
│   └── _hooks/
├── orders/         # 機能スライス：注文
│   └── ...
└── customers/      # 機能スライス：顧客
    └── ...

_プレフィックスのフォルダはNext.jsのルーティング対象から除外される「プライベートフォルダ」であり、整理用に使える。「2つの機能が同じものを共有する場合、再利用可能な部分を親階層の共有空間に移動する」というルールで、共通化と独立性のバランスを取る¹⁰。

Server ActionsやRoute Handlersもスライス内に閉じ込めることで、UI・サーバー処理・スキーマ定義が1つのフォルダに揃い、AIに渡すコンテキストが自然にまとまる。

Go（API中心）の場合

GoでVSAを実装する場合の代表例が、mehdihadeli/go-vertical-slice-template⁵だ。Echo（Webフレームワーク）、GORM（ORM）、Go-MediatR（CQRS仲介）、Uber Zap（ロギング）、Viper（設定管理）といった軽量スタックを組み合わせ、以下の構造を採る：

internal/
├── catalogs/                          # ドメイン
│   └── products/
│       └── features/
│           ├── creating_product/
│           │   ├── commands/
│           │   ├── endpoints/
│           │   ├── dtos/
│           │   └── events/
│           └── getting_product_by_id/
│               ├── queries/
│               ├── endpoints/
│               └── dtos/
├── pkg/                               # 共有ユーティリティ
└── shared/                            # 横断的関心事

各機能フォルダにCommand/Query、Handler、Endpoint、DTO、Eventがすべて入っている。GoのインタフェースとDIコンテナ（uber-go/dig）を組み合わせることで、レイヤード構造に頼らずスライスごとの依存性管理が可能になっている⁵。

スタック選択の現実的な指針

「Next.js vs Go」という二者択一は実務的には少なく、どちらを使う場面でもVSAは適用可能というのが正確な理解だ。選択指針としては以下のようになる：

• フロントエンドを含むフルスタック：Next.js（App Router） + Server Actions + 機能フォルダ
• API中心のバックエンド：Go + Echo + Go-MediatR、または.NET + MediatR + Carter
• 既存コードベースの段階的移行：「新機能だけVSA」というハイブリッドが現実的

なお、Next.js vs GoでAIコーディングの生産性を定量比較したベンチマークは、2026年4月時点では信頼できるものを見つけられなかった。経験則として「AIの学習データ量が多い言語（JavaScript/TypeScript、Python）の方がAI生成精度が高い」と言われているが、Goも標準ライブラリ・主要フレームワークについては十分な学習がなされており、実務的な差は小さくなってきている。

反論と留保：VSAは万能ではない

ここまでVSAのメリットを論じてきたが、過大評価しないために反論と留保を整理しておく。

コードの重複問題

VSAへの最も典型的な批判は「DRY（Don’t Repeat Yourself）原則に反する」というものだ。複数のスライスで同じようなバリデーションロジックや変換処理が書かれることになる。

これに対するVSA派の応答は、「意図的なトレードオフ」である。スライス間の偶発的な重複を許容する代わりに、スライス内の独立性と変更の局所性を得る。Bogardは原典で「共有を強制するための抽象が、実際にはバラバラの要件を1つの形に押し込めてしまう」と指摘しており¹、表面的な重複の方が、無理な共通化より健全だという立場をとる。

実務的には、本当に共有すべきもの（認証、ロギング、横断的バリデーション）だけを_sharedやshared/に置き、ビジネスロジックの重複は許容する、という運用に落ち着く。

AIが構造を崩す問題

dotnetwebacademy.substackが2026年2月に公開した記事「Stop Letting Copilot Ruin Your Vertical Slice Architecture」は、VSAプロジェクトでCopilotを使った際に起きる問題を具体的に指摘している⁴：

• 構造的不整合：Copilotがminimal APIエンドポイントではなくControllerを生成し、「フォルダがあちこちに散らばり、ロジックがあちこちに置かれる」
• DTOの重複：サーバー、共有、クライアントの各プロジェクトに同じDTOが冗長に生成される
• アーキテクチャ規律の欠如：明示的な指示なしには、CQRS分離やMediatorパターンが守られない

著者の処方箋は、プロンプトでアーキテクチャ規約を明示することだ。「Use minimal APIs instead of controllers」「Use CQRS」「Use Mediator」といった指示を、再利用可能なinstruction file（Claude CodeのCLAUDE.mdやCursor Rules、Copilot Instructionsなど）に保存しておけば、機能ごとに繰り返す必要がなくなる。

つまり、「VSAだからAIが勝手に良いコードを書いてくれる」わけではない。VSAの恩恵を受けるには、AIに対するアーキテクチャ的ガイドラインを明示することが必要条件となる。

大規模プロジェクトでの限界

スライス数が数十～数百規模になると、スライス間の関係性を把握すること自体が課題になる。この規模では、Modular Monolith（モジュラーモノリス）と組み合わせて、複数の関連スライスを「モジュール」としてグルーピングする戦略が現実的だ。

また、ドメイン駆動設計（DDD）の境界づけられたコンテキスト（Bounded Context）と、VSAのスライスは異なる粒度の概念である。大規模システムでは、Bounded Context単位でCleanの依存ルールを保ち、その内部の実装をVSAで組織化する、というハイブリッドが安定する。

チームとプロジェクトの前提

VSAは、Bogard自身が原典で「強いリファクタリング能力とコードスメル認識能力を持つチーム」を前提にしていることを明言している¹。「機能ごとに最適な実装を選べる」という自由は、判断力のないチームでは「機能ごとにバラバラの品質」を生むリスクがある。

ジュニア中心のチームや、品質基準を明示できていないプロジェクトでは、レイヤードやCleanのような「型」がある手法の方が、結果的に安定することもある。

実装Tips：AIを活用したVSA開発

最後に、AIコーディングツールでVSAを実践する際の具体的なTipsをまとめる。

1. プロジェクトレベルのインストラクションを書く

CLAUDE.md、.cursorrules、.github/copilot-instructions.mdなどのファイルに、以下のような規約を記述しておく：

## Architecture Rules
- Use Vertical Slice Architecture: each feature in its own folder under `features/`
- Each slice contains: command/query, handler, endpoint, DTO, test
- Do not create shared Service classes; keep logic inside slice handlers
- Shared code goes only into `shared/` (auth, logging, validation primitives)
- Use CQRS pattern with MediatR-style request handlers

2. 既存スライスをテンプレートにする

新規機能を作る際は、AIに「features/creating_product/と同じ構造でfeatures/creating_order/を作って」と指示する。Few-shotとして既存スライスの全ファイルを読ませると、命名規約・テストパターン・エラーハンドリングまで自動的に踏襲される。

3. 1スライス＝1セッションで作業する

AIエージェントセッションは「1つのスライスの完成」までを単位にすると、コンテキストが膨れずに済む。複数スライスをまたぐ大きなリファクタリングは、人間が分解してから個別のスライスタスクとしてAIに渡す。

4. 共有コードを最小化する原則を守る

AIは「便利そうな共有ヘルパー」を生成しがちだ。レビュー時に「これは本当に複数スライスから使われるか」を確認し、1スライスからしか使われないなら、そのスライス内に閉じ込める。

まとめ

Vertical Slice Architectureは、機能ごとにコードを縦割りで完結させるという、シンプルだが強力な設計原理だ。Jimmy Bogardが2018年に明文化した「スライス間の結合を最小化し、スライス内の結合を最大化する」という原則は、AIコーディングツールが普及した2026年現在、改めて再評価されている。

その理由は、LLMが扱う「コンテキスト」の単位とVSAのスライスが自然に一致することにある。1ディレクトリで完結する機能は、AIに渡すコンテキストとして必要十分な範囲を持ち、生成精度とトークン効率の両方で有利に働く。Next.jsのApp RouterもGoのフレームワーク群も、それぞれの形でVSAを支える実装パターンを提供している。

ただし、VSAは万能ではない。コードの重複、AIによる構造崩しのリスク、大規模プロジェクトでの複雑性、チームスキル前提――いずれもAI親和性とは独立した課題として残る。Cleanとのハイブリッド、Modular Monolithとの組み合わせ、プロジェクトインストラクションでのガイドラインの明示など、現実的には複数の手段を組み合わせる判断が必要になる。

「AI時代の正解は1つではないが、機能を縦割りに完結させる発想は、AIを使う使わないにかかわらず、変更の局所性という基本的な価値に立ち返らせてくれる」――VSAをAI親和性という切り口で捉え直すことの意義は、結局のところそこにある。

採用判断の指針を一行で言えば、こうだ。「機能ごとの独立性が高く、新機能追加が継続的に発生し、AIコーディングツールを日常的に使うチーム」ならVSAは強力な選択肢になる。 一方で、機能間の整合性が極めて重要なドメイン（金融トランザクション、医療記録など）や、ジュニア中心のチームでは、Cleanとのハイブリッドや段階的導入の方が安定する。アーキテクチャ選定は常に「何を最適化したいか」の問いに帰着する。

関連記事

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

• 『ソフトウェア設計の結合バランス』解説：疎結合至上主義を超えた新しい設計原則 — VSAの「スライス内結合最大化」を理論的に裏付ける結合度議論
• AIペアプログラミングが生む密結合の罠 — AIが生成するコードの密結合問題と、それを避けるための設計判断
• AIに効率的に読ませるMarkdownドキュメントの書き方 — コンテキスト効率化の観点からのドキュメント設計
• AIネイティブなエンジニアリングチームの作り方 — チーム規模でAIを活用する際の組織と設計の論点

参考資料

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

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

• Vertical Slice Architecture and Comparison with Clean Architecture - Mehmet Özkaya, Medium. 【信頼性: 中】VSAとCleanの位置づけ比較。
• From Layers to Slices: Revolutionizing .NET Application - Bhargav Koya, Medium. 【信頼性: 中】.NETエコシステムにおけるレイヤード→VSA移行の解説。

1. Vertical Slice Architecture - Jimmy Bogard (2018年4月19日). 【信頼性: 高】VSAの原典。提唱者本人による定義と原理の説明。 ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶

2. A Deeper Dive: When the Vibe Dies — Comparing Codebase Architectures for AI Tools - Rick Hightower, Medium (2025年4月18日). 【信頼性: 中】専門家ブログによるVSAとAIツールの相性分析。定量データなし。 ↩︎

3. Coding Agents as a First-Class Consideration in Project Structures - Basti Ortiz, DEV Community (2026年1月5日). 【信頼性: 中】コーディングエージェント時代のプロジェクト構造論。「40%ルール」はアネクドータルと明記。 ↩︎ ↩︎² ↩︎³

4. Stop Letting Copilot Ruin Your Vertical Slice Architecture - .NET Web Academy, Substack (2026年2月16日). 【信頼性: 中】CopilotがVSA構造を崩す具体的事例とプロンプト対策。 ↩︎ ↩︎²

5. mehdihadeli/go-vertical-slice-template - Mehdi Hadeli, GitHub (v1.0.0: 2025年7月26日). 【信頼性: 中】Go言語向けVSA + CQRSテンプレート。Echo、GORM、Go-MediatRを使用。 ↩︎ ↩︎² ↩︎³ ↩︎⁴

6. Clean Architecture vs Vertical Slice Architecture - rexebin, DEV Community (2022年2月1日). 【信頼性: 中】CleanとVSAの両立アプローチを実装事例とともに解説。 ↩︎

7. Feature-Sliced Design: Overview - Feature-Sliced Design 公式ドキュメント. 【信頼性: 中〜高】FSDの公式ドキュメント。層・スライス・セグメントの構造ルール。 ↩︎

8. Keep the AI Vibe: Optimizing Codebase Architecture for AI Coding Tools - Rick Hightower, Medium (2025年4月18日). 【信頼性: 中】AIコーディング向けアーキテクチャ最適化の概論。VSAをAIフレンドリーと位置づけ。 ↩︎

9. AI-Assisted Greenfield Software Development, Part 6: Vertical Slices and Implementation Planning - John Miller, CODE Magazine (2026年3月31日). 【信頼性: 中〜高】AI支援グリーンフィールド開発におけるスライス単位の計画立案手法。 ↩︎

10. How to Organize a Growing Next.js App: A Practical Guide to Vertical Feature Slicing - Farzaneh Haddadi, Medium (2025年11月7日). 【信頼性: 中】Next.js App RouterでのVSA実装パターン。 ↩︎ ↩︎²