DDD（ドメイン駆動設計）は2026年、ようやく実用に乗ってきた

ソフトウェア設計の世界に、20年以上「重要だが難しい」と言われ続けてきた思想がある。DDD（Domain-Driven Design、ドメイン駆動設計＝ソフトウェアを業務現場の語彙そのままで書こうとする設計思想）である。Eric Evans が2003年に「青本」と呼ばれる原典を世に出してから23年が経つが、現場の勉強会では「DDD はやっぱり難しい」「導入したが何も得られなかった」という声が今でも絶えなかった。

ところが2026年に入って空気がはっきり変わりつつある。きっかけは AI コーディングエージェント（Claude Code、Cursor、Devin など自律的にコードを書く AI）の本格実用化である。長らく ROI が見えないと評されてきた DDD が、AI と組み合わせることで具体的な効能を見せ始めた。本稿は Strickland Media の Development カテゴリとして、この20年越しの再評価を外部の一次情報から整理する。

DDD とは何か、まず一文で

DDD とは、ソフトウェアを「現場で使われている語彙そのまま」で書こうとする設計思想である。

経理担当者が「請求」と呼んでいるならコードでも Invoice と書く。「立替金」と呼んでいるなら Reimbursement と書く。当たり前のようでいて現実のシステム開発ではほとんど守られていない。エンジニアの都合で data_001 tmp_table のような名前が増え、業務担当者とエンジニアが同じものを別の語で呼ぶうちに、組織のなかで「言葉の翻訳コスト」が積み上がっていく。

Evans が青本で提示した中心概念は二つある。Ubiquitous Language（ユビキタス言語＝関係者全員が同じ意味で使う共通語彙）と、Bounded Context（境界づけられたコンテキスト＝その語彙が一貫した意味を持つ範囲）である。たとえば「顧客」は、営業部門では「契約見込みの会社」を意味し、サポート部門では「契約済みで問い合わせてくる人」を意味する。無理に統合せず境界線を引いて別物として扱う。この境界が Bounded Context である。

DDD はコードの話に見えて、実は組織の語彙の話をしている。Martin Fowler の bliki “DomainDrivenDesign” が言うとおり、業務の語彙でコードが書かれていれば、要件変更がコードのどこに影響するかを非技術者でも追いやすくなる。

なぜ20年も「難しい」と言われ続けたのか

20年「難しい」と言われ続けた理由は、青本に書かれている戦術的パターン（Aggregate、Entity、Value Object、Repository、Domain Event といった実装上の型）の学習コストが極めて高かったからである。

HackerNews では2021年に「DDD Is Overrated」というスレッドが数百票を集めた。dev.to の「Domain Driven Disaster」は現場の悲鳴を伝える。「20〜50倍のクラス数になり、CRUD（典型的なデータ操作）の To-Do アプリに DDD を当てた結果、どう変更すればいいか誰もわからなくなった」。英語圏のブログ “The failed promise of Domain-Driven Design”（no-kill-switch.ghost.io）はより根本的な批判を投げる。Bounded Context の定義は極めて曖昧で結局は主観的判断に頼らざるをえない、というものだ。

日本でも事情は変わらない。経費精算 SaaS の Tokium 社のエンジニアが Zenn に書いた記事は生々しい。「『なんか良いらしい』で DDD を導入した結果、何も得られなかった」。社内で「chunk」と呼ばれていた概念を「Ubiquitous Language だから」と「portion」に改名したが、誰も portion とは呼ばなかったという。「DDD の目的を知らないまま設計手法を導入すると、余計な複雑さだけが残り、大きな負債になりかねない」と同記事は結ぶ。Eric Evans 本人ですら、2017年の Explore DDD カンファレンスで “It would be a shame if we did DDD like I wrote it in the book.”（本に書いた通りに DDD をやるのは残念なことだ）と発言している（InfoQ 2017年報道）。問題は思想そのものではなく、戦術的パターンの過剰適用と目的を見失った導入だった。

実践者は何に気づいたのか

失敗を経験した日本のエンジニアたちは共通の気づきにたどり着いている。DDD が機能するのは図解どおりにレイヤを切り分けたときではなく、エンジニアと業務担当者が同じ語彙で会話できるようになったときだ、というものだ。前述の Tokium のエンジニアは「DDD の目的は、エンジニアと PdM が同じ言葉で会話できるようにすること。そしてその言葉をそのままコードに反映させること」と言い切る。この目的が共有されていない導入はほぼ例外なく失敗する。20年の試行錯誤を通じて DDD コミュニティは「青本を聖典として崇める」段階を抜け、「使える部分だけを目的に応じて選び取る」段階に入った。

2024年、Evans 本人が LLM と DDD を接続した

潮目が変わった決定的な瞬間は2024年3月の Explore DDD Denver カンファレンスでの Eric Evans 基調講演である。Evans はこう述べた。“Training a language model on the ubiquitous language of a bounded context makes it far more useful for specific needs.”（Bounded Context の Ubiquitous Language で言語モデルを fine-tuning（微調整）すれば、汎用モデルよりはるかに有用になる）。さらに「将来のドメインモデラーは、自然言語解釈が必要なサブタスクを特定し、そこに LLM（大規模言語モデル）を配置するだろう」とも語った（InfoQ 2024年3月報道、動画は YouTube に “DDD and LLMs - Eric Evans - Explore DDD 2024” として公開）。

DDD の生みの親本人が AI 時代との接続を明示的に語った事実は重い。Evans は2017年に「本のとおりにやるな」、2024年には「LLM と組み合わせろ」と言った。23年かけて DDD は「教科書をなぞる重い手法」から「AI と組織の語彙を媒介する軽い思想」へと位置づけを変えた。

なぜ AI エージェント時代に DDD が効くのか

AI エージェント時代に DDD が効くのは、AI が文法には強いが意味には弱いからである。

Qiita の記事「AI 駆動開発時代の DDD スキル」（nogataka 氏）はこの本質を「AI がコードを書くなら、人間はモデル（概念）を書く必要がある」と凝縮する。AI は構文的に正しいコードを驚くべき速度で生成するが、「請求」と「立替」の業務上の違い、「申請」と「承認」の組織上の順序は学習データから自動では推論できず、AI は「それらしく」実装してしまう。

Bardia Khosravi が2025年に Medium に書いた論考も同じ方向を指す。“AI エージェントをチームの別の開発者だと思え”。AI ツールは人間が一度の PR で出すよりずっと大量のコードを生成するため、予測可能なパターンが整っていないとレビューと修正が手に負えなくなる、というロジックだ。Bounded Context を引いておけば AI が境界を越えてビジネスロジックを混線させるリスクが下がり、Ubiquitous Language を整えておけば AI への指示と出力のあいだで翻訳ロスが起きにくい。earezki.com（2026年5月）が指摘するとおり、「claim（請求）と ticket（チケット）」「approval（承認）と authorisation（認可）」のような業務上の微妙な区別を AI エージェントに理解させるには、Ubiquitous Language をプロンプトに埋め込む以外に方法がない。

AWS Architecture Blog の2025年記事「Architecting for agentic AI development on AWS」では、AWS が DDD の層構造（/domain、/application、/infrastructure の3層分離）を AI エージェント開発の推奨アーキテクチャに据えた。「AI エージェントがクラウド依存コードに触れずにビジネスロジックを変更してローカルで検証できる」という運用メリットが理由である。巨大クラウドベンダーが推奨する時点で、DDD はもはや一部の好事家の理論ではなくなった。

日本の最新事例：パーソルキャリアの DX

国内でも、大企業 DX の核心に DDD を据える事例が表に出始めた。パーソルキャリアの技術ブログ techtekt（2026年3月公開）の一文が印象的である。「AI の実用化が一気に進み、データ構造を根本から見直す必要性が急速に高まった」。

同社の事業構造は典型的だった。各事業が自律的に成長してきた反面、本来つながっているはずの情報が分断されていた。ある事業の「求職者」と別事業の「応募者」が本質的には同じ人物を指していても、システム間で語彙が違うために結びつかない。AI を入れようとした瞬間にこの語彙の断層が決定的な障害として表面化し、同社は「DDD で境界と責務を再定義した」と書く。経営層にとってのインパクトはここで、DDD はエンジニアのお作法ではなく「組織がどこで自分を分割しているか」を問い直す作業になる。

それでも「DDD は不要」と言う人への反論

当然「やはり不要だ」「過大評価だ」と言う声もある。代表的なのが Andrej Karpathy が2025年2月に提唱した Vibe coding（バイブコーディング＝意図だけ伝えれば AI が実装する開発スタイル）である。設計などせず AI と会話するだけでアプリができる、という主張だった。しかし Karpathy 自身が約1年後にこの見方を修正している（The New Stack 報道）。「このフェーズは終わり、次はエージェント工学の時代だ」と。Vibe coding 単体では本番システムに耐える設計は出てこないという反省だ。

Dariusz Gafka が2026年3月に Medium に書いた “DDD Was Never the Problem. Your Rules Were.”（DDD は問題ではなかった、あなたのルールが問題だった）も重要である。DDD そのものが悪かったのではなく「青本に書かれた通りに全部やる」ドグマとして適用したことが悪かった、という主張で、Tokium の失敗談と本質的に同じ診断だ。実務的な落としどころとして、戦略的設計（Bounded Context と Core Domain＝ビジネスの核心領域の特定）だけを取り入れ、戦術的パターンは捨てる派が増えている。「組織の語彙と境界線を整える」上流の知恵だけを取り、クラス設計の細かい流派には深入りしない。この実利的なスタンスが AI 時代の DDD の主流になりつつある。

経営層とエンジニア、それぞれが持ち帰るもの

経営層が DDD から学ぶべきは戦術的なクラス設計の話ではない。「組織の語彙を AI に渡せる形で整理する」上流工程が、これからの DX のボトルネックになるという事実認識である。AI を業務に組み込もうとした瞬間、パーソルキャリアが描いた「情報の分断」がそのまま技術負債として顕在化する。

エンジニアが取るべきスタンスはより具体的だ。戦術的パターンを全部入れる必要はない。Aggregate を真面目に設計するかはシステムの規模と寿命次第である。一方、戦略的設計（Bounded Context、Core Domain、Ubiquitous Language）の3点セットは AI エージェント時代において費用対効果が一気に好転している。AI に正しく仕事を任せるには責任範囲と語彙を事前に決めておくしかなく、これは小規模なチームでも明日から始められる作業である。

Strickland から見ても、これは同じ景色である

Strickland は法人・自治体向けにセキュアな生成 AI プラットフォームを提供する事業者として、顧客の業務文脈に AI を埋め込む現場に立ち会っている。痛感するのも同じ景色だ。最初にぶつかる壁は技術ではなく、組織内部の語彙の不一致と責任範囲の曖昧さである。「申請」と「依頼」と「リクエスト」が部署ごとに別の意味で使われ、AI への指示が翻訳不可能になる。DDD の用語を使うかどうかは別として、AI を真面目に業務に組み込もうとすると Bounded Context と Ubiquitous Language に相当する整理を誰もが結局やることになる。

締めくくり

DDD は20年「難しい」と言われ続けた。その評価は事実だった。しかし2026年現在、AI が「コードを書く」工程を引き受けたことで、人間は「組織の語彙を整える」工程に集中できるようになった。Evans 本人が2024年に LLM と DDD の接続を語り、AWS が層構造を推奨し、パーソルキャリアのような日本の大企業が DX の核心に据え始めた。ようやく道具のほうが追いついた、というのが2026年の景色である。

DDD を「重厚な開発手法」と身構えるとまた失敗する。「組織の語彙と境界線を AI にも渡せる形で整える作業」として受け取ったときに、ようやく実用に乗ってくる。それが20年越しの再評価が示す唯一の教訓である。Strickland Media では今後もこの上流工程の知見を発信していきたい。