AI時代に「動くゴミ」を量産しないために。今こそ若手エンジニアにDDDが必要な理由

はい、どうもこんにちは佐藤です！

「AI が全部書いてくれるから、もう緻密な設計なんていらないでしょ？」

最近、若手のエンジニアからこんな声を聞くことが増えました。

AI によるコード生成で、開発のスピードは確かに劇的に上がりましたよね。でも、その勢いのまま設計を捨ててしまうのは、大きな罠です！

むしろ AI 時代だからこそ、ドメイン駆動設計（ DDD ）の基礎、とくに「ユビキタス言語（言葉の定義）」の重要性が、かつてないほど高まっています。その理由を、私の失敗談も交えながら書いていきますね！

AI は「空気を読んで」はくれない

人間同士のやり取りなら、多少のスペルミスや曖昧な指示でも、なんとなく伝わりますよね。「あ、これはあのライブラリのことだな」「いつものあの仕様だな」と、相手が文脈を読んで忖度してくれるからです。

でも、 AI は違います。与えられたテキストを、文字通りに解釈するのです。

以前、私が AI にライブラリの追加を頼んだときのこと。プロンプトでほんのわずかなタイポをしてしまったばかりに、まったく別のライブラリが導入され、想定外の機能が実装されてしまいました。人間なら一瞬で気づくようなミスでも、 AI はそのまま突き進んでしまうのですよね。

スピードが速いぶん、ズレたまま進んだときのダメージも大きい。ここが落とし穴です。

「言葉のズレ」がDB設計まで侵食すると悲劇になる

このズレが、業務ロジックやデータベース設計にまで波及すると、取り返しのつかないことになります。

データの状態管理を例にしましょう。私は「状態や論理削除のフラグは、別のステータステーブルで持たせる」という設計を想定していました。

ところが、その文脈が AI に正確に伝わっていなかった。すると AI は気を利かせたつもりで、こうしてしまったのです。

# 私の想定（ステータスを別テーブルで管理）
invoices         … 請求書の本体
invoice_statuses … 状態・論理削除フラグはこっち

# AI が書いたもの（メインテーブルに直接カラム追加）
invoices
  ├─ is_deleted   ← 勝手に生えた論理削除カラム
  └─ status       ← 勝手に生えた状態カラム

しかも、それに依存したコードまで大量に書き上げてくれました。

DB の変更をともなう修正が、どれほど時間と労力を奪うか。現場のエンジニアなら想像がつきますよね。これがまさに、「動くけれど直しづらいコード」＝ 動くゴミ が生まれる瞬間です。 AI は気を利かせたのに、結果として手戻りを増やしてしまう。皮肉な話なのです。

ならば「コードそのものに文脈を埋め込む」

では、どうすれば AI に正しい文脈を渡せるのでしょうか。

Claude Code のように、リポジトリ内のコードを読み込んでくれる AI に対しては、答えはシンプルです。コードそのものに文脈を埋め込むこと。これが最適解になります。

具体的には、次の3つを意識しています。

汎用的な CRUD ではなく、 API を RPC スタイルにする。「承認する（ Approve ）」「更新する（ Update ）」「削除する（ Delete ）」と、アクションの意図を名前で明確にする
権限まわりの制限をコードに明記する。「誰がこの操作を実行できるのか」を曖昧にしない
状態遷移（ステートマシン）のライブラリを導入する。「どの状態のときに、何ができるのか」をコードで表現する

たとえば、ただの update ではなく approve_invoice というメソッドにする。すると、「これは承認という業務アクションなんだ」という意図が、名前を読むだけで AI に伝わりますよね。

これらを徹底するだけで、「誰が、どの状態のときに、何を実行できるのか」というドメインのルールが、コード上にそのまま表現されます。この明確な定義こそが、 AI にとって最高のコンテキストになるのです。

設計が「いらなくなる」のではなく「最強の武器になる」

ここで誤解してほしくないのは、「 AI がコードを書くから設計はいらない」のではない、ということ。

正しくはこうです。

DDD の基礎、つまり言葉とルールの定義を明確にして AI に渡すことで、 AI は最強の部下になる。

曖昧な指示を投げて手戻りを繰り返すのか。それとも、ドメインの解像度を上げて明確な文脈を与えるのか。どちらを選ぶかで、 AI の出力の打率は天と地ほど変わってきます。

言葉を定義し、ルールをコードに刻む。地味に見えて、これが AI 時代でいちばん効くスキルなのです。

まとめ

というわけで、 AI 時代に「動くゴミ」を量産しないためにこそ DDD が必要だよ！って話でした！

あ。正確には、「言葉とルールを定義して渡せば、 AI は最強の部下になる」 って感じですねっ。

AI は空気を読んでくれません。でも、裏を返せば、こちらが文脈をきちんと言語化できれば、その通りに高速で動いてくれる頼もしい存在です。ドメインの解像度を上げることは、 AI を使いこなすための投資そのもの。次世代をリードする若手エンジニアにこそ、この「 AI を最強の部下にするための設計力」を身につけてほしいと、強く感じています。

ぜひみなさんも、まずは言葉の定義から見直してみてください！