はじめに
今年は生成系AIやAIエージェントの台頭によって、ソフトウェア開発の常識が大きく変わった一年でした（これはもう断言します）。
昨年もGPT自体は存在していましたが、2025年の進化はその比ではなく、GitHub Copilot、Claude Codeなど様々なAIツールの普及によって、開発のあり方も変わらざるを得ない気がします。
まさに時代の大きな潮流を感じざるを得ません。
こうした中で、エンジニア界隈では様々な議論や意見が飛び交っています（筆者もその一人ですが）。
その中でふと筆者が思いついた仮説があります。
それは 「AI時代のソフトウェア開発に、DDD（ドメイン駆動設計）はかなり相性が良いのではないか？」 ということ。
AIがコードを書いてくれる時代だからこそ、
ソフトウェアの設計やドメインモデリングの重要性が増すのでは？と考えています。
そこで本記事では、この仮説について筆者なりに言語化し、深掘りしていきましょう。
DDDとは何か（詳細は末尾のAppendixを見てね）
まず前提として、DDD（Domain-Driven Design、ドメイン駆動設計）とは何か簡単におさらいしましょう。
DDDは業務（ビジネス）の本質に根ざしたソフトウェア開発手法です。
2003年にエリック・エヴァンス氏によって提唱され、複雑なビジネス課題を解決する考え方として広まっています。
特徴は、開発の中心にドメイン知識（業務知識）を据え、ビジネスの専門家（ドメインエキスパート）と開発者が協働してモデルを構築する点にあります。
単なる技術的なコード設計手法ではなく、ビジネス価値を最大限に引き出すことを目的とした戦略的な手法だと位置付けられています。
言い換えれば、ソフトウェア設計とビジネス戦略を結びつけ、開発チームとビジネス側のコラボレーションを強化するためのアプローチなのです。
さて、よく分からないですよね。
（筆者もエリックエヴァンスの原著読んで、「？」となっていた身なので、よく分かります。）
正直、DDDの理論や手法については、興味が出たら学んでもらえればいいと思います。
ただ、一つだけして覚えておいて欲しいことがあるとすれば、
「DDDは、難しい理論を並び立ててガチャガチャ設計する、一部のトップエンジニアに許された娯楽では無いんです。コードを絡めたビジネスの話をしようとしているだけなんだ。」
ということですね。
「ドメインに寄り添う」「ユビキタス言語を使う」といった話はもちろん重要ですが、それだけではありません。
要は「ビジネス上価値の高い領域を見極め、境界を引き、適切にモデリングしてソフトウェアに反映する」ことがDDDの核心だということを押さえておいてください。
AI時代に求められる（であろう）4つの能力値
では、AI時代ではDDDの思想をどう活かし、エンジニアにはどのような能力が求められるのでしょうか。筆者なりに考えた4つのポイントを挙げてみます。
1.「課題」を捉える能力（コアドメインを見極める力）
2. 複雑さを分解する「境界づけ」能力
3.「作らない」という判断を下す能力
4.ドメインエキスパートと対話・調整するファシリテーション能力
1.「課題」を捉える能力（コアドメインを見極める力）
ソフトウェアで解決すべき本当の課題は何か――その核心となるドメインを的確に嗅ぎ分ける能力です。
解決すべき課題設定を間違えると、「そもそもそれってシステム化する必要あったの？」という事態にもなりかねません。
このプロセスをないがしろにすると、AIがどれだけコードを書けても的外れなシステムになってしまいます。
これ、DDDにおける「モデリング」と考え方がとても似ているんですよね。
モデリングは単なる設計工程ではありません。「顧客の課題をどう解決し、どう価値提供するか」を顧客と一緒に考え抜く過程そのものなのです。
現在の生成AIは与えられた指示からパターンに沿ったコードを生成できますが、ビジネス文脈やドメイン固有の要求を深く理解することは苦手（な気がしています）。
（※ 今後できるようになるかもしれないけども、まだ到達していないと感じる）
だからこそ、何が本質的な問題でどの領域にテコ入れすべきか判断できる人間の洞察力がますます重要になるのではない？という考え。
2.複雑さを分解する「境界づけ」能力
システムの複雑さを適切に管理するために、問題空間（問題領域）をいくつかのコンテキストに分割し境界を引く能力です。
なんでもかんでも一つの巨大でモノリシックなシステムに詰め込んでしまうと、もはや人間はおろか高度なAIですらその全貌を把握しかねます。（今のところ）
これ、DDDでいう「境界づけられたコンテキスト」の考え方で、「ここから先は別の意味を持つ世界」「この機能群はこのコンテキスト内で自己完結する」といった境界線を明示できることがポイントです。
境界を適切に引けば、各部分が独立性を保ち、全体の複雑さを抑制できます。
このスキルはAI支援開発においても極めて重要で、AIは単体のプログラミングタスクや定型的なコーディングには強いものの、システム全体のアーキテクチャ設計のように高度な抽象化やトレードオフ判断を伴う作業は、まだ苦手なようだからですね。
人間がドメイン知識と経験をもとにシステムのモジュール化戦略を立て、適切に粒度を決めてあげることで、AIにも扱いやすい形で問題を提示できます。
「大きすぎる問題を丸投げしない」ための分割統治能力とも言えるのかもしれません。
3.「作らない」という判断を下す能力
すべてを一から自前開発するのではなく、作るべきところと既製品で済ますところを見極める判断力です。
DDDではドメインを「コアドメイン」「サブドメイン」「汎用サブドメイン」「支援サブドメイン」に分類し、どこに注力すべきかを明確にします。（※ この分類や多少の言い回しについては諸説あり。コアサブドメイン等、多少言い方の違う書籍があったりする。）
特に競争優位に直結するコアドメインには最大限のリソース投下をし、それ以外の汎用的な領域（例えば認証や決済、メール通知など）はSaaSやライブラリ、場合によってはアウトソーシングも検討するのが定石というような戦略的DDDの話ですね。
AI時代においてもこれは同様で、むしろコアドメインこそAIの力も借りて強化し、汎用サブドメインは極力作りこまないというメリハリが一層重要になるでしょう。
言い換えれば、「ここは自社独自の価値を発揮すべき領域だから自前開発（＋AIで生産性向上）」と「ここは世間一般で十分解決されている領域だから既存サービス活用で十分」の取捨選択を適切に下せる能力です。
限られたリソースをどこに投下すべきか、ビジネス戦略と技術戦略の両面から判断するスキルとも言えます。
この判断を誤ると、AIを使って高速に開発したものの実は不要だった…という残念な結果にもなりかねません。
4.ドメインエキスパートと対話・調整するファシリテーション能力
DDDはコードを書く技術であると同時に、対話の技術でもあります。
エンジニアがビジネスサイドのドメインエキスパートと積極的に対話し、お互いの頭の中にあるモデル（メンタルモデル）をすり合わせていく調整力が求められます。
AI時代になっても、この人間同士の創造的対話の重要性は変わりません。
むしろ、AIが自動でコードを書いてくれるからこそ、何をどう作るべきかを正しく導くための対話がこれまで以上に欠かせないでしょう。
例えば要件定義の場面でも、AIが勝手にユーザの業務課題を理解してくれるわけではありません。開発者がドメインエキスパートから本質的な知識を引き出し、共通のユビキタス言語で整理・合意し、それをモデルに落とし込むというプロセスが必要です。
DDDの目的自体、ビジネスと開発が協調しながらドメイン知識をコードに反映することにあります。
この能力は一朝一夕で身につくものではありませんが、AIに任せきれない人間ならではの強みとしてこれからも重要になっていくのではないかな？と筆者は思っています。
この先もずっとそうか？（技術の移り変わりについて）
ここまで「AI時代にはDDDが重要かも！」的な文脈で語ってきましたが、果たしてこの状況は今後もずっと続くんですかね？
正直なところ、明日の常識は今日の非常識になるかもしれないのがこの業界の面白くもあり難しいところです。
技術の進歩は想像以上に早く、昨日まで正しかったプラクティスが明日には陳腐化している可能性すらあります。もしかすると数年後には、これまで積み上げてきた開発手法を一度すべてリセットして、新しいパラダイムに飛び移らなければならない局面が来るかもしれません。
ですから、「AI時代はDDDが大事らしい」と本記事の内容を鵜呑みにしてしまうのも考えものです。
もちろん、こんな記事を書いた手前、筆者自身はDDDが重要になる可能性は高いと思っていますが、それだって絶対ではありません。
AI時代で最も重要な能力を一つ挙げるとすれば、皮肉でも何でもなく、最終的に自分自身で状況を判断し決断する力だと筆者は思います。
ただ一方で、これはずっと大事だったことで、AI時代だから特別という話ではないのですが、情報やツールが溢れる今だからこそ、一層意識しておきたいポイントです。
まとめ
生成AIの登場によって開発者側も良くも悪くも混乱しているのが現状です。
AIはそれらしいコードや回答を確率的に返してくれますが、それを鵜呑みにせず取捨選択し、ドメイン知識と論理的思考で補完する必要があります。
結局のところ、人間が本質を見極めて舵取りをし、AIの力をうまく活用することが今後のソフトウェア開発には求められるのでしょう。
AIという大きな波にもうまく乗っていければ、開発の可能性はこれまで以上に広がるはずです。
筆者もこの激動の波を日々感じつつ、どうすればもっと上手にAIと協調し価値あるシステムを構築できるか模索する毎日です。
便利なツールが増えた反面、勉強すべきこともどんどん増えて時間がいくらあっても足りませんが、新しい時代に適応しながら引き続き精進していきたいですね。
今後も状況が変われば柔軟に学び直しつつ、しかし軸としての「ドメインへの向き合い方」は忘れずに、開発者として成長していければと考えています。
最後に繰り返しになりますが、本記事の内容も含めて何が正解かは自分で判断するしかありません。
読者の皆さんもぜひ自分なりの考えを持って、このAI時代のソフトウェア開発とDDDの可能性について議論してみてください！以上！
Appendix：DDDをもうちょっと知りたい
DDDのエッセンスとしてよく語られるのが、「ユビキタス言語」と呼ばれる共通言語を用いてチーム内の認識齟齬をなくすことや、ドメイン（業務領域）そのものを深く理解した上でソフトウェアモデルに落とし込むことです。
ドメインエキスパートと開発者が日常会話から設計・実装まで一貫した用語を使うことで、要求の誤解や手戻りを減らし、ビジネスルールをそのままシステムに反映できるようにします。
こうした対話重視・モデル重視の姿勢はDDDの基本ですが、筆者からすると「ビジネス側と共通言語で会話しドメインに寄り添う」のはもはや前提であり、当たり前とも思えます。
DDDの真髄はそれだけではなく、ビジネス戦略上重要な領域に開発リソースを集中し、的確なモデリングでソフトウェアとビジネスの橋渡しをする点にあると考えています。
DDDには大きく戦略的DDDと戦術的DDDの二つの側面があります。
戦略的DDDではシステム全体の構造や境界を設計し、どのドメインに注力するかといった“大局観”を扱います。
一方、戦術的DDDではエンティティや値オブジェクト、リポジトリなどのパターンを用いて実際のコードレベルでドメインを実装していきます。
本記事の文脈では特に戦略的な側面に注目しています。
戦略的設計の鍵となる概念に境界づけられたコンテキストがあります。これは「特定のモデルや用語の意味が通用する明確な境界」を定義し、その境界ごとに独立したモデルを設計するという手法です。
大規模なシステムでも境界を明示して分割し、それぞれの内部で一貫したモデルと言葉遣いを保つことで、複雑さを制御しやすくします。
例えば「注文」という言葉も、販売コンテキストと配送コンテキストでは意味や属性が異なります。一つの巨大なモデルに詰め込むのではなく、コンテキストごとに分けることで、モデルの肥大化や認識違いを防ぎ、チームごとの並行開発も容易にするわけです。