VSAとDDDをAI開発でどう組み合わせるか：いま議論されている複数の方向性を俯瞰する

• 想定読者： 中〜大規模AIアプリ（LLMアプリ、Agentic AI、マルチエージェント系）を本格開発するソフトウェアエンジニア、テックリード、アーキテクト
• 前提知識： Vertical Slice Architecture（VSA）の基本、Clean Architecture/DDDの概念に触れたことがある程度
• 所要時間： 27分

概要

「VSAは機能スライスを縦割りに完結させる設計で、AIコーディングと相性がよい」――この命題は、先行記事VSAはなぜAI開発と相性がよいのかで示した通りで、ここまでは実装事例とコミュニティの議論の蓄積がある領域だ。

ところがスライス数が増え、システムが Agentic AI やマルチエージェント構成に進むと、VSA単体では捌きにくい問題群が浮上する――「スライス間で同じ概念が違う名前で扱われる」「エージェントの責任範囲をどこで切るか」「Bounded Context（境界づけられたコンテキスト）と機能スライスは何が違うのか」。

これらに対し、2025〜2026年にかけていくつかの組み合わせ案が並走的に議論されている。本記事はそれを推奨するためではなく、「いま何が実装され、何が提案段階なのか」を俯瞰し、読者が自分のプロジェクト規模・チーム・ドメインに応じて判断するための材料を提供する。

結論を先に置けば、こうなる：

• VSA + DDD の戦略的設計のハイブリッドは、AI開発文脈を除けば.NET/Spring Boot で複数の実装テンプレートと OSS プロジェクトが存在する成熟領域である。AI開発で「効く理由」も論理整合性がある程度示されているが、定量データはまだ薄い
• マルチエージェント × Bounded Context、Hexagonal Agents などのAIネイティブな組み合わせ案は、Microsoft や Siemens の個人エンジニアの発信・カンファレンス講演・arXiv論文として複数同時並走しているが、運用事例の蓄積はこれから
• 「DDDはオーバーキル」という長年の批判はAI開発文脈でも引き継がれており、「戦略的設計だけ採用して戦術パターンは最小限に」というスタンスを取る論者のほうが現状は多い

本記事では、これらの方向性を実装段階・提案段階に分けて並べ、関連する反対論と arXiv 実証研究まで含めて全体像を提示する。判断軸は読者に委ねる構成だ。

姉妹記事：基礎の整理として Vertical Slice ArchitectureはなぜAI開発と相性がよいのか を参照すると、VSAの原典・他手法との違い・AI親和性の根拠が掴める。本記事はその上に複数のDDD/Hexagonal議論を重ねる地図。

§1. 議論の地図：何が実装され、何が提案段階か

組み合わせ議論を整理する上で、まず「実装事例の有無」で線を引いておく。エビデンスの強度がまったく違うからだ。

実装事例がある領域

組み合わせ	代表的な実装/テンプレート	公開時期
VSA + DDD（戦略的設計）+ Modular Monolith (.NET)	meysamhadeli/booking-modular-monolith — 497 stars、.NET 10、Identity/Flight/Passenger/Booking の4 Bounded Context1	2025年7月更新
VSA + DDD + Clean Architecture (.NET)	Evgeni Rusev のテンプレート — Bounded Contextごとにソリューションディレクトリ、各モジュール内は Clean Architecture（著者は「Clean Architecture with a Modular Vertical Slice monolith」と表現）2	2024年6月
VSA + DDD + CQRS (Spring Boot)	hpalma/ddd-verticalslice-example — Java/Spring Boot 環境での小規模な参考実装3	—
VSA + DDD + SOLID (ASP.NET Core)	jeangatto/ASP.NET-Core-Vertical-Slice-Architecture4	継続更新
AIエージェント向け DDD/Hexagonal バックエンド規約	Bardia Khosravi の GitHub 規約集 — コード例は Python、著者は Java/C#/Go への置き換え容易性に言及5	2025年7月
VSA向け Claude Code Skill (.NET)	Vladyslav Furdak の dotnet-vsa-webapi — Microsoft MVP 作6	2026年3月

これらは全て動くコードとして存在しており、git clone して構造を直接読める。ただし、いずれもAI開発文脈との結びつきは「議論として」「規約として」提示されているものであり、「導入したらAIコーディングの生産性が何%向上した」という統計的測定はされていない。

提案・概念整理の段階の領域

議論	提唱者	公開時期
マルチエージェントAI × DDD Bounded Context	James Croft (Microsoft Senior SWE)7	2026年4月
Agent as Bounded Context（Cognitive Agent / Workspace の2モデル）	Philipp Kostyra8	2025年8月
Agentic Codebases × DDD 4原則（契約スキーマ・ACL・Context Map）	Nikita Golovko (Siemens AI Portfolio Architect, AI Coding Summit 講演)9	2026年2月
AI開発でのDDDの効き目（Ubiquitous Language とプロンプト整合）	Leric Zhang (Senior Software Architect)10	2025年8月
Hexagonal Agents（中心にAIエージェント、Portsをツール境界に）	Joshua Oliphant11	2026年3月

これらはいずれも個人の発信・講演・ブログであり、所属企業が組織として採用していることを意味しない。「Microsoft 所属のエンジニア」が書いている＝「Microsoft でこう運用されている」ではないことに注意したい。

flowchart TB
    A[VSAとDDDの組み合わせ議論] --> B[実装事例あり]
    A --> C[提案・概念整理段階]
    B --> D[VSA+DDD戦略設計<br>Modular Monolith]
    B --> E[VSA+DDD+CQRS<br>テンプレート]
    B --> F[AIエージェント向け<br>規約集]
    C --> G[マルチエージェント×<br>Bounded Context]
    C --> H[Agent as<br>Bounded Context]
    C --> I[Hexagonal Agents]

§2. 方向性A：VSA + DDD 戦略的設計（最小限）

最も成熟した組み合わせはここだ。DDDのうち戦略的設計――Bounded Context、Ubiquitous Language、Context Map――だけを採用し、戦術パターン（Aggregate、Repository、Domain Service等）はスライス内で必要な分だけ導入する派閥である。

どういう構造か

meysamhadeli/booking-modular-monolith¹の例を見ると、Identity、Flight、Passenger、Booking の4つのBounded Contextをモジュールとして分け、各モジュールの内部をVSAの機能スライス（Command/Query Handler、Endpoint、Repository）で構成している。複数モジュールは単一バイナリにまとめてデプロイし、モジュール間通信は gRPC と Masstransit（イベント駆動）で行う。

Next.js / Go でも同じ発想は適用可能だ。Go で例示するとこうなる：

internal/                          # Go の例
├── sales/                         # Bounded Context: 販売
│   ├── domain/                    # 必要に応じて最小限の Aggregate/VO
│   ├── acl/                       # 他Contextからの入力を翻訳
│   └── features/                  # VSAスライス
│       ├── creating_order/
│       └── cancelling_order/
├── inventory/                     # Bounded Context: 在庫
│   ├── domain/
│   ├── acl/
│   └── features/
└── shared/                        # 真に横断的なもの（最小）

議論されているメリット

実装テンプレートが言及する利点は概ね一致している：

• スライスの増加がContext単位で階層化されるため、依存図の把握コストが抑えられる
• Bounded Context境界でACL（Anti-Corruption Layer、腐敗防止層）を経由させると、Context内のリファクタリングが他Contextに波及しない
• 用語規約をContextごとに分けて文書化できる（CLAUDE.md / .cursorrules を Context ごとに置く運用が提案されている）

Leric Zhang は「プロンプトが Ubiquitous Language を使うとき、AIの出力はビジネス意図と密接に整合する」と論じている¹⁰。直感的には頷ける主張だが、定量データはなく、現時点では論理整合性ベースで受け取るべきだ。

限界として指摘されていること

「VSAは Clean Architecture の進化形ではなく、別の思想だ」と論じる Rico Fritzsche は、Clean の層構造を保ったまま Bounded Context で囲うパターンを批判している。「Clean Architecture can never be domain-driven anyway（Clean Architecture はそもそもドメイン駆動になりえない）」というのが彼の主張で、機能独立性を本気で追うなら Clean の層を温存するハイブリッドは中途半端だと指摘する¹²。

実装テンプレートの多くは Clean の層を温存しているため、この批判は無視できない。「Bounded Context × VSA」を採用すること自体は問題ないが、内部を Clean の依存ルールで縛るかどうかはさらに別の判断になる。

§3. 方向性B：戦術パターンも含むフルDDD

「Aggregate、Value Object、Repository、Domain Service までしっかり実装する」派閥は、AIに対するコーディング規約として戦術パターンを利用する。

Bardia Khosravi が GitHub に公開している規約集⁵はこの方向の代表例だ。著者は「AIコーディングエージェントはチームのもう一人の開発者」と位置づけ、予測可能なパターンを提示することで AI の生成をレビュー可能にすることを目指している。コード例は Python で書かれているが、Entity / Value Object / Aggregate Root / Repository Interface といった戦術パターンは言語非依存の概念として整理されており、著者は Java/C#/Go への置き換え容易性に言及している。

この方向の前提

戦術パターンまで導入する場合、以下の前提が満たされているかが鍵になる：

• ドメインに真の複雑性がある（単純なCRUDではない）
• チームにDDDの戦術パターンを理解しているメンバーが複数いる
• AIに対して、戦術パターンを「規約」として明示できるドキュメント体系がある

「Dogmatic DDD」批判

Derek Comartin は2021年に “STOP Doing Dogmatic Domain Driven Design” と題した記事で、「リポジトリやアグリゲートを書いているだけでは DDD をやっていることにならない」「真の DDD はパターン適合ではなく、ドメインの境界と言語の理解」と論じている¹³。

つまり、フルDDDを採用しても、戦術パターンを機械的に並べただけでは恩恵を受けられない。むしろ、コードがパターン適合のために重くなり、AI に渡すべきコンテキストが膨れる逆効果さえありうる。Comartin が翌2022年に書いた “Should You Use Domain Driven Design?” では「小規模アプリケーションには DDD はオーバーキル、戦略的パターンに集中するのが現実的」とまとめている¹⁴。

この批判は AI 開発文脈でも当てはまる。「戦術パターンを最初から完備するか、戦略的設計から始めて必要に応じて戦術を追加するか」は、現時点では後者を勧める論者のほうが多い。

§4. 方向性C：Hexagonal Agents（Ports & Adapters）

VSA とは別系統だが、AI開発で同時に議論されているのが Hexagonal Architecture（Ports & Adapters）の応用だ。

Joshua Oliphant が2026年3月に公開した “Hexagonal Agents” は、「ヘキサゴンの中心は規則エンジンである必要はない――それは推論エンジンでもいい」と提案する¹¹。AI エージェントを中心に置き、Inbound Ports（トリガー）と Outbound Ports（ツール・能力）をエージェント境界として定義する設計だ。

flowchart TB
    A[Inbound Port<br>HTTP/Event/Schedule] --> B[AI Agent<br>推論エンジン]
    B --> C[Outbound Port: DB]
    B --> D[Outbound Port: External API]
    B --> E[Outbound Port: Tool]
    F[ガードレール<br>検証ポリシー] -.-> B

この方向の特徴

• LLM の差し替え可能性：プロバイダ依存（OpenAI/Anthropic/Google）を中心ロジックから切り離せる
• ツール境界の明示：各 Outbound Port が「LLM が呼べるツール」になり、Function Calling/MCP との親和性が高い
• ガードレールの差し込みポイント：Port 層でバリデーション・権限チェックを強制できる

VSA との関係

Hexagonal Agents は VSA と排他的ではないが、思想の重心が違う。VSA は「変更の局所性」を、Hexagonal は「依存方向の制御」を中心に置く。両者を統合した実装例はまだ少なく、「Bounded Context 内に Hexagonal を適用し、その内部の機能を VSA で組織化する」という三層ネストも理論的には可能だが、ここまで来ると概念ネストが深すぎてAIに渡すコンテキストの整理コストが上がる懸念もある。

§5. 方向性D：マルチエージェント × Bounded Context（完全に提案段階）

複数のLLMエージェントが協調して動くアーキテクチャで、エージェントの責任範囲を Bounded Context にマッピングする発想だ。

現在の論者

• James Croft（Microsoft Senior SWE）が2026年4月に「1つ以上のエージェントが Bounded Context を表現し、エージェントは特定ドメインの知識と規則をカプセル化する」という対応関係を提示⁷
• Philipp Kostyra は2025年8月、Bounded Context を Cognitive Agent（コンテキスト全体が1つの自律エージェント） または Workspace（複数エージェントが協調する作業空間） として位置づけるモデルを提案⁸。例えば「規制遵守 Context」を単一の Cognitive Agent として扱い、ポリシーチェックを完結させる構成と、「在庫 Context」を Workspace として複数の専門エージェント（補充判断・引当・棚卸し）を同居させる構成を使い分けるイメージだ
• Nikita Golovko（Siemens AI Portfolio Architect）は2026年2月の AI Coding Summit で、Bounded Context をエージェントの責任範囲、契約をスキーマ、ACL をセマンティック・ファイアウォール、Context Map を実行可能な統合アーキテクチャとして位置づける整理を提示⁹

何が「提案段階」なのか

これらの論者はいずれも個人発信ベースで、所属企業が組織として運用していることを意味しない。「マルチエージェント本番運用での失敗パターン・成功パターン」は2026年5月時点では公開された蓄積がほぼない。論じられているのは設計の枠組みであり、「採用してこう失敗した／成功した」というケーススタディは出てきていない。

ただし、関連する実証研究は出始めている。arXiv 2604.04990「Architecture Without Architects」（2026年4月）は、AIコーディングエージェントがプロンプトを通じて暗黙的にアーキテクチャ決定を行っていることを実験的に示した¹⁵。同じタスクでもプロンプトの文言だけでコードサイズが141行〜827行に変動するという報告は、「プロンプト=アーキテクチャ仕様」の発想を裏付ける。Bounded Context の境界をプロンプトに焼き込むという発想は、この観点からも今後注目されると考えられる。

取り扱いの注意

Croft/Kostyra/Golovko の議論は刺激的だが、現時点で本番採用する場合は「自分のチームで失敗パターンを引き当てる側になる」ことを覚悟する必要がある。様子見の方向性として位置づけるのが穏当だ。

§6. AI開発全体に効く実証データ（限定的）

組み合わせ議論を判断する材料として、AI開発が横軸の役割分担そのものを変えていく可能性を示す論文がある。

arXiv 2601.22667「From Horizontal Layering to Vertical Integration: A Comparative Study of the AI-Driven Software Development Paradigm」（2026年1月）は、AI 支援で「個別エンジニアが end-to-end の機能所有を担う Vertical Integration」が成立しうると論じる。著者らは2つのケースで 8.3 倍（伝統的エンタープライズ）〜33 倍（AIネイティブスタートアップ）の人月削減を報告している¹⁶。

ただし数字の読み方には注意が必要だ：

• ケーススタディは2件であり、統計的一般化は困難
• 「人月削減」は AI 自体の能力向上だけでなく、組織再編・スコープ縮小も含む可能性が高い
• 著者らの所属（Moximize.ai 等）は AI ネイティブ系のため、選好バイアスが入りうる

そのうえで、論文の質的な観察――「シニアエンジニアが実行コーディングからアーキテクチャ監督と責任ガバナンスへ移行する」「単一エンジニアが従来の役割境界をまたぐ」――は、VSA や Bounded Context のような「機能と責任の縦割り構造」が、AI 時代の組織と整合的になる方向性を示唆している。

§7. 反対意見・留保

組み合わせ議論全体への反対意見・留保も同じ重みで並べておく。

反対1：DDD はオーバーキル

Derek Comartin が一貫して論じているように¹³¹⁴、複雑性のないドメインに DDD を持ち込むことはコストに見合わない。「Bounded Context が3つも見えないのに DDD を導入しても、戦術パターンの重さだけが残る」可能性は十分にある。

反対2：VSA そのものの限界

VSA への伝統的な批判――コードの重複、スライス間の一貫性低下、横断的関心事の管理コスト――は組み合わせ後も残る。Milan Jovanović の整理によれば、「誤った抽象化より重複の方が安い（Duplication is cheaper than the wrong abstraction）」として、Rule of Three（同じコードが3回現れるまで抽象化しない）に達するまでは重複を許容するトレードオフ論が VSA の前提にある。ただし規模が大きくなるとこの重複が負債化することもある¹⁷。

反対3：プロンプトがアーキテクチャを決める時代

arXiv 2604.04990 が示すように、AI エージェント時代のアーキテクチャはコードよりプロンプト・スキャフォールディング・既定設定で決まる側面が大きい¹⁵。VSA や DDD を採用すると決めても、AI に渡すプロンプトの規約が緩いと構造はすぐ崩れる。「アーキテクチャ選定」と「プロンプト規約整備」は同じ重要度で議論する必要がある。

反対4：定量データの不在

組み合わせ議論全体に共通する弱点として、AI開発文脈での定量的な効果測定がほぼないことが挙げられる。論理整合性と実装事例の蓄積はあるが、「VSA+DDD を採用したチームと採用しなかったチームの生産性比較」のような対照研究は2026年5月時点では見つけられない。

反対5：チームスキルの前提

DDD は戦略的設計だけでも一定の経験を要求する。「Bounded Context をどこで切るか」の判断は、ドメインモデリングに慣れていないチームには重い。VSA も Bogard 自身が原典で「強いリファクタリング能力とコードスメル認識能力を持つチーム」を前提にしていることを明言している。両方を採用するなら、両方の前提が必要だ。

§8. 自分のプロジェクトでどう判断するか

ここまでの議論を踏まえて、判断軸を整理する。結論を一行で出さないのが本記事の方針だが、判断のための問いは提示できる。

問い1：Bounded Context が見えているか

システム内で異なる文脈で同じ言葉が異なる意味を持つ場面があるか。「販売の『注文』」と「在庫の『注文』」が違うモデルになっているか、「規制遵守の『顧客』」と「マーケティングの『顧客』」が違う属性を持っているか。

• 見えていない（Bounded Context が1つ）：VSA 単体で十分。DDD の戦略的設計は今後必要になった時に追加
• 2〜3個見える：VSA + DDD 戦略的設計のハイブリッド（§2 の方向性A）が現実的な検討対象
• 4個以上見える、または増え続ける：Modular Monolith パターンとの組み合わせ（§2 booking-modular-monolith のような構造）が議論の対象

問い2：戦術パターンの複雑性を引き受けるか

Aggregate、Value Object、Repository、Domain Service を実装する余力と必要性があるか。

• 必要性も余力もない：戦略的設計だけ、戦術パターンはスライス内で必要に応じて
• 両方ある：§3 の方向性B（Khosravi の規約集など）が参考になる
• 必要性は感じるが余力がない：「戦略的設計から始めて、痛みを感じた箇所だけ戦術パターンを足す」という段階的導入

問い3：エージェント構成は採用するか

• シングルエージェント（Claude Code / Cursor 等）でのコーディング支援が中心：§2 / §3 の議論が直接効く
• マルチエージェント本番運用を検討：§5 の議論を「参考にしつつ、自前で失敗パターンを記録する覚悟」が必要
• AIをツールとしてのみ使う：DDD の議論はAI抜きで成立する範囲で判断するのが安全

問い4：プロンプト規約とアーキテクチャ規約をどう統合するか

arXiv 2604.04990 が示す通り、プロンプトはアーキテクチャ仕様の一部だ¹⁵。CLAUDE.md / .cursorrules / .github/copilot-instructions.md でBounded Context の境界・Ubiquitous Language・スライス規約をAIに明示できる体制があるかが、組み合わせ議論を実装に落とす際の最後の鍵になる。

まとめ

VSA と DDD の組み合わせ議論は、2026年5月時点で実装事例と提案段階が混在する成長中の領域だ。

• 実装事例があるのは：VSA + DDD 戦略的設計のハイブリッド、Modular Monolith との統合、AI エージェント向けコーディング規約――いずれも.NET/Spring Boot で複数のテンプレートが公開されている
• 提案段階にあるのは：マルチエージェント × Bounded Context、Hexagonal Agents、Cognitive Agent モデル――個人発信・カンファレンス講演ベースで運用蓄積はこれから

本記事は推奨ガイドではなく、地図として書いた。「どれを採用すべきか」の答えは、Bounded Context の数、戦術パターンを引き受ける余力、エージェント構成、プロンプト規約の体制――こうした個別状況によって変わる。

ひとつ確実に言えるのは、「AI コーディングが普及しても、アーキテクチャ選定が消えるわけではない」ということだ。むしろ arXiv 2604.04990 が示すように、プロンプトとスキャフォールディングが暗黙的にアーキテクチャを決めてしまう時代だからこそ、明示的な構造の議論が今まで以上に重要になる。VSA、DDD、Hexagonal――いずれも単独で銀の弾丸ではないが、組み合わせ方の議論を追うことで、自分のプロジェクトに必要な構造を見つけやすくなる。

本記事を読んだ後の現実的な次の一歩は、「自分のシステムで Bounded Context が見えるか」を問うことだろう。見えるなら、§1 の実装テンプレートのうち言語と規模が合うものを1つ読み解くと、議論が一気に具体化する。

関連記事

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

• Vertical Slice ArchitectureはなぜAI開発と相性がよいのか：1スライス＝1コンテキストという設計原理 — 本記事の基盤となる元記事。VSAの原典・他手法との違い・AI親和性の根拠を整理
• 『ソフトウェア設計の結合バランス』解説：疎結合至上主義を超えた新しい設計原則 — Bounded Context間の結合制御を理論的に裏付ける議論
• AIペアプログラミングが生む密結合の罠 — AI生成コードの密結合問題と、それを設計で抑える視点
• AIネイティブなエンジニアリングチームの作り方 — チーム規模でAIを活用する際の組織と設計の論点

参考資料

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

実装事例（GitHub テンプレート / OSS プロジェクト）

提案・概念整理（個人発信・カンファレンス講演）

反対論・批判

実証研究 (arXiv)

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

• Vertical Slice Architecture - Jimmy Bogard (2018年4月19日). 【信頼性: 高】VSAの原典。
• Leveraging Generative AI for Enhancing Domain-Driven Software Design - Götz-Henrik Wiegand, Filip Stepniak, Patrick Baier, arXiv:2601.20909 (2026年1月28日, Upper-Rhine AI Symposium 2024 proceedings). 【信頼性: 中】生成AIを使ってDDDメタモデル生成を部分自動化する逆方向の研究。
• mehdihadeli/go-vertical-slice-template - Mehdi Hadeli, GitHub (v1.0.0: 2025年7月26日). 【信頼性: 中】Go言語向け VSA + CQRS テンプレート。
• VSAはなぜAI開発と相性がよいのか - 本ブログ前記事 (2026年4月26日). 本記事の基盤となる元記事。

1. meysamhadeli/booking-modular-monolith - .NET 10 で VSA + DDD + Modular Monolith + Event-Driven + CQRS を統合した実装。Identity/Flight/Passenger/Booking の 4 Bounded Context。497 stars (2025年7月時点). 【信頼性: 中〜高】規模・継続更新ともに実装事例として参照価値が高い。 ↩︎ ↩︎²

2. .NET Domain Driven Design Template with a Vertical Slice architecture - Evgeni Rusev, Medium (2024年6月22日). 【信頼性: 中】Bounded Context ごとにソリューションディレクトリを切り、ソリューション全体をモジュラーVSAモノリスとして組む（著者は「Clean Architecture with a Modular Vertical Slice monolith」と表現）。GitHub テンプレートあり。 ↩︎

3. hpalma/ddd-verticalslice-example - Spring Boot で DDD + VSA + CQRS + Domain Events を統合した小規模な参考実装. 【信頼性: 中】Java エコシステムでの参考実装。 ↩︎

4. jeangatto/ASP.NET-Core-Vertical-Slice-Architecture - VSA + CQRS + REST API + DDD + SOLID の統合実装. 【信頼性: 中】.NET エコシステムでの参考実装。 ↩︎

5. Backend Coding Rules for AI Coding Agents: DDD and Hexagonal Architecture - Bardia Khosravi, Medium (2025年7月12日). 【信頼性: 中】AIコーディングエージェント向けDDD/Hexagonal規約。コード例は Python で書かれており、著者は Java/C#/Go への置き換え容易性に言及。GitHub に規約集 (bardiakhosravi/ai-agent-backend-standards) を公開。 ↩︎ ↩︎²

6. Vertical Slice Architecture for Claude Code: dotnet-vsa-webapi Explained - Vladyslav Furdak, Microsoft MVP (2026年3月16日). 【信頼性: 中】Claude Code 向け VSA スキャフォールディング Skill。MediatR/AutoMapper/汎用 Repository を意図的に排除する立場。 ↩︎

7. Applying domain-driven design principles to multi-agent AI systems - James Croft, Microsoft Senior Software Engineer (2026年4月8日, 2026年5月4日更新). 【信頼性: 中】Microsoft 所属だが個人発信。組織採用の保証ではない。 ↩︎ ↩︎²

8. Agent as Bounded Context (Part 1) - Philipp Kostyra, Medium (2025年8月1日). 【信頼性: 中】Cognitive Agent / Workspace の2モデル提案。実装事例は未提示。 ↩︎ ↩︎²

9. From Prompt Spaghetti to Bounded Contexts: DDD for Agentic Codebases - Nikita Golovko, Siemens AI Portfolio Architect, AI Coding Summit (2026年2月26日). 【信頼性: 中】カンファレンス講演。Bounded Context・契約スキーマ・ACL・Context Map を4原則として提示。 ↩︎ ↩︎²

10. Domain-Driven Design: Streamlining AI-Powered Software Development - Leric Zhang, Senior Software Architect, Medium (2025年8月2日). 【信頼性: 中】AI開発でDDD（Ubiquitous Language・Bounded Context・Aggregate）が効く論点を整理。実証データなし。 ↩︎ ↩︎²

11. Hexagonal Agents: What If Your App’s Business Logic Was an AI Agent? - Joshua Oliphant (2026年3月18日). 【信頼性: 中】Hexagonal Architecture の中心をAIエージェントに置く提案。LLM プロバイダ差し替え性とツール境界の議論。 ↩︎ ↩︎²

12. Why Vertical Slices Won’t Evolve from Clean Architecture - Rico Fritzsche (2025年5月15日). 【信頼性: 中】VSAとCleanは別思想である主張。「Clean Architecture can never be domain-driven anyway」。 ↩︎

13. STOP Doing Dogmatic Domain Driven Design - Derek Comartin, CodeOpinion (2021年6月9日). 【信頼性: 中〜高】戦術パターン適合に偏った DDD への批判。境界と言語の理解こそが本質。 ↩︎ ↩︎²

14. Should You Use Domain Driven Design? - Derek Comartin, CodeOpinion (2022年2月16日). 【信頼性: 中〜高】DDDオーバーキル論。「単純CRUDなら不要、戦略パターンに集中せよ」。 ↩︎ ↩︎²

15. Architecture Without Architects: How AI Coding Agents Shape Software Architecture - Phongsakon Mark Konrad et al., arXiv:2604.04990 (2026年4月5日). 【信頼性: 中〜高】AIコーディングエージェントがプロンプト経由で暗黙的にアーキテクチャ決定を行うことを実証。同一タスクで141〜827行のコードサイズ変動を報告。 ↩︎ ↩︎² ↩︎³

16. From Horizontal Layering to Vertical Integration: A Comparative Study of the AI-Driven Software Development Paradigm - Chi Zhang et al., arXiv:2601.22667 (2026年1月30日). 【信頼性: 中】AI支援でのVertical Integration成立論。ケーススタディ2件で8.3×〜33×の人月削減を報告するが、組織再編・スコープ縮小要因を含むため数字単体での評価は要注意。 ↩︎

17. Vertical Slice Architecture: Where Does the Shared Logic Live? - Milan Jovanović. 【信頼性: 中】VSAでの共有ロジック配置の議論。DRY違反トレードオフの整理。 ↩︎