こんにちは。ENECHANGEエンジニアの石橋です。
AIによって実装コストは劇的に下がりました。しかし、そこから競争優位が自動的に生まれるわけではありません。
本記事で考えたいのは、次の問いです。
AI時代、補完サブドメインは本当にエンジニアが担うべきなのか？
結論から言えば、サブドメインの分類（コア／補完／一般）は変わりません。
変わるのは、補完サブドメインを「誰が構築するのが合理的か」という前提です。
AIによって、
補完領域の一部は、非エンジニアのドメインエキスパートでも構築可能になりつつある
という現実が生まれています。
はじめに
ENECHANGEでは現在、O’Reilly『ドメイン駆動設計をはじめよう』の輪読会を行っています。
- 毎週火曜 14:00-15:00
- 章担当制
- 事前読書＋議論
目的は明確です。
実案件に効く設計知識を身につけること。
実際に、料金計算プロダクトのデータ設計や責務分割の議論に、輪読会で扱った概念が活用され始めています。
その中で浮かび上がったのが、次の問いです。
AIによって実装が容易になった今、補完的サブドメインは誰が担うべきなのか？
DDDにおけるサブドメインの整理
DDDでは業務領域を次の3つに分類します。
| 種類 | 特徴 | 投資方針 | 実装（典型アプローチ） |
|---|---|---|---|
| コアサブドメイン | 競争優位の源泉 | 最大投資 | ドメインモデル中心。厳密なユビキタス言語運用。最も優秀な人材を投入。 |
| 補完的サブドメイン | 自社特有だが差別化ではない | 適度 | 必要十分に作る（内製／外注は状況で選ぶ。コアほど投資しない）。 |
| 一般的サブドメイン | 業界共通 | 最小、外部活用 | 既製品／SaaS／OSSを優先。原則外部活用。 |
補完的サブドメインは、もともと「コアほどの投資は不要な領域」と整理されています。
原則は変わらない
まず前提として、DDDの基本構造は変わりません。
- コアは内製し、最優秀人材を集中させる
- 一般は外部活用を優先する
- 補完は必要十分に作る
この分類は依然として有効です。
では、何が変わったのでしょうか。
補完は「エンジニアでなくても作れる」領域になりつつある
補完的サブドメインの典型例を挙げると、
- CSVレイアウト変換バッチ
- 社内向け管理画面
- データ整形ワークフロー
- 外部APIとのマッピング層
- 定型レポート生成
といった領域があります。
これらは自社特有ではあるものの、競争優位の源泉ではありません。
従来はエンジニア（あるいは外注）が実装してきました。
しかし現在は、コード生成、API統合、データ変換ロジックの雛形作成などが、プロンプトベースで高速に生成できます。
その結果、
業務を深く理解しているプロフェッショナルが、AIを使って補完領域を構築する
という選択肢が現実味を帯びています。
例えば、
- 業務担当者が仕様を文章で整理し
- AIに変換ロジックやバッチ処理を生成させ
- エンジニアが境界・セキュリティ・統合部分のみをレビューする
といった形です。
これは「エンジニアが不要になる」という話ではありません。
エンジニアが補完を常に主導する必然性が下がる
という構造変化です。
ただし、放置すれば崩れる
ドメインエキスパートが補完を構築する場合でも、
- 境界コンテキストが崩れないか
- コアへ技術的負債が侵食しないか
- アーキテクチャ整合性が保たれているか
は、エンジニアの責任です。
補完を軽く扱いすぎれば、やがてコアを歪ませます。
したがって、主導権が業務側に寄るとしても、
境界と構造の最終責任はエンジニアが持つ
という前提は変わりません。
AIリテラシーという現実
もう一つの現実は、
すべてのドメインエキスパートがAIを使いこなせるわけではない
という点です。
AIを前提とした補完構築は、
- プロンプト設計能力
- ロジックの妥当性判断
- セキュリティ意識
といったリテラシーを必要とします。
したがってこれは「自然にそうなる」という話ではなく、
組織が意図的に設計する役割再編
です。
外部委託という選択肢はさらに縮小する
補完はもともと外部委託も可能な領域でした。
しかし、
- 業務理解は社内にあり
- 実装はAIで高速化でき
- 統合だけエンジニアが担えばよい
のであれば、外部委託を選ぶ理由は弱まります。
外注の価値は「実装能力の提供」にありました。
その部分がコモディティ化すると、
ドメインエキスパート＋AI＋最小限のエンジニア支援
という構成が合理的な選択肢になります。
それでもコアは変わらない
一方で、コアサブドメインは全く異なります。
AIはコードを生成できますが、
- 何を解くべきか
- どの概念を抽象化するか
- どこに境界を引くか
といった戦略的判断は依然として人間の責任です。
料金計算のような複雑ドメインでは、
- 契約電力の定義
- 最大需要電力の扱い
- 制度改定への適応
といった判断が競争優位を左右します。
ここでは
ドメインを深く理解したエンジニアが主導する体制
が不可欠です。
補完が軽くなるほど、コアへの集中はむしろ強まります。
AI前後での役割の違い
AI以前
| サブドメイン | 主体 |
|---|---|
| コア | 最優秀エンジニア |
| 補完 | エンジニア（中堅）または外注 |
| 一般 | 外部活用 |
AI以後
| サブドメイン | 主体 |
|---|---|
| コア | 最優秀エンジニア（不変） |
| 補完 | ドメインエキスパート＋AI（エンジニアは構造責任） |
| 一般 | 外部活用（不変） |
変わったのは、補完における「主導権」と「実装主体」です。
なぜそれでもDDDが効くのか
DDDのサブドメイン分類は、
どこにエンジニアリング資源を集中させるか
を明確にするための枠組みです。
AIによって補完の実装ハードルが下がると、
- コアに集中する意味はより明確になり
- 補完はより軽量な運用が可能になり
- 一般は引き続き外部化される
という構造が強化されます。
AIはDDDを無効にするのではなく、
コアとそれ以外の差を、よりはっきりさせる
存在だと言えます。
まとめ
- サブドメイン分類は変わらない
- 補完はもともと過度な投資をしない領域である
- AIにより、補完の一部はドメインエキスパートが構築可能になる
- ただし境界と構造の責任はエンジニアが持つ
- 外部委託の必然性はさらに低下する
- コアへの集中はむしろ強化される
AI時代に問われているのは、
どこにエンジニアを使い、どこを手放すのか
という戦略判断です。
その意味で、DDDは依然として有効な戦略フレームワークであり続けます。
