AIがコードを書く時代の ジェネレーティブプログラミング

1. AI がコードを書く時代の ジェネレーティブプログラミング @polidog 設計ナイト 2026 1
2. 自己紹介 @polidog パーティーハード株式会社 Symfony(PHP) が好き 2
3. AI がコードを書く時代に、 ソフトウェアをどう設計すればいいのか？ 3
4. DDD では動くコードがモデルだった エリック・エヴァンスのDDD は「動くコードこそがモデルである」と説い た。 人間が最終的にコードを書き、システムを作り上げる時代だったからこそ、 動くコードがモデルであった。 人間がコードを書かなくなった今、動くコードはまだモデルと言えるのか？ 4
5. コードがモデルであることの限界 AI が生成したコードを人間が全て読み解くのは現実的ではない。 コード量の爆発的増加 生成されたコードの意図が読み取りにくい 全体像の把握が困難に コードをモデルとすることは、限界を迎えつつある。 5
6. ただし、AI がコードを書く時代でも、人の頭の中にはモデルがある 問題は、それが外に出ていないこと 6
7. SDD （仕様駆動開発） SDD （Spec-Driven Development ） という考え方が広まりつつある。 1. 自然言語で仕様を書く 2. AI がそれに基づいてコードを生成する 3. 生成されたコードをレビュー・修正する 4. 変更があれば仕様を更新し、再生成する 仕様がモデルとなり、コードはその派生物という位置づけになる。 7
8. 自然言語で書かれた仕様はモデルと言えるのか？ 自然言語の仕様には、解釈の幅がある。 人によって読み方が変わる AI の解釈も毎回同じとは限らない 実行できない、検証できない 仕様とコードが乖離しても検知する仕組みがない モデルと呼ぶには、曖昧すぎるのではないか。 8
9. ジェネレーティブプログラミング 9
10. ジェネレーティブプログラミングとは コードを手で書くのではなく、コードを生成する仕組みを設 計するという考え方。 2000 年にKrzysztof Czarnecki とUlrich Eisenecker が著書 『Generative Programming 』で体系化した。 10
11. ジェネレーティブプログラミングのプロセス DEMRAL （Domain Engineering Method for Reusable Algorithmic Libraries ） という方法論で、3 つのフェーズからなる。 フェーズ やること 成果物 ドメイン分析 境界を決め、共通性と可変性を識別 スコープ定義、フィーチャーモデル、制約 ドメイン設計 アーキテクチャやDSL 、構成知識を設計 アーキテクチャ、DSL 記法、マッピングルール ドメイン実装 コンポーネントやジェネレータを実装 生成コード、テスト 11
12. エッセンスを取り入れる 特に以下の2 つで、モデルを検証可能にする。 1. フィーチャーモデル ドメインの共通性・可変性を構造化し、何が固定で何が変わるかを明示する。 2. コンフィグレーションDSL フィーチャーの選択を宣言的に記述し、バリデーション可能にする。 自然言語の仕様では曖昧だったモデルが、構造を持ち、検証できるものにな る。 12
13. フィーチャーモデルとは ドメインが持つ フィーチャー（機能的 特徴） をツリー構造で表現したもの。 どのフィーチャーが必須で、どれが オプションか どのフィーチャーが択一で、どれが 共存可能か フィーチャー間にどんな制約や依存 があるか 図の引用元: https://club- z.zuken.co.jp/hint/20250925_vuca_17.html 13
14. DSL で仕様を記述する フィーチャーの選択を宣言的に記述するためのDSL を定義する。 リストコンテナではYAML で仕様を記述する： name: IntList language: go element_type: int storage: type: array initial_capacity: 16 growth_strategy: doubling operations: - remove - insert - linear_search - iteration: direction: forward この記述がAI への入力となり、生成の再現性と検証可能性を高める。 14
15. DEMRAL を参考にClaude Code のスキルに 各活動をスキルとして実装し、AI と対話しながら設計資産を作る。 活動 スキル 成果物 ドメインスコーピング /domain-scoping スコープ定義 フィーチャーモデリング /feature-modeling フィーチャーモデル、制約 ドメイン設計 /domain-design アーキテクチャ、コンポーネント、構成の知識 DSL 定義 /dsl-definition DSL 記法、サンプル仕様書 実装 /implement 生成コード テスト /test テストコード 15
16. サンプル：リストコンテナの生成 Czarnecki の『Generative Programming 』で題材とされたリストコンテナを、 AI 時代のジェネレーティブプログラミングで再実装したサンプル。 フィーチャーモデル — Storage （Array/LinkedList ） 、Operations （Sort 、 Iteration 等）の可変性を構造化 コンフィグレーションDSL — YAML でフィーチャーを選択 構成の知識 — フィーチャー選択からコンポーネントへのマッピング + 言語 別の導出ルール 生成コード — 同じ仕様からGo ・PHP のコードを生成 https://github.com/polidog/gp-example-list 16
17. 構成の知識 DSL に書かなくても、構成の知識が自動的に導出・補完するものがある。 言語別コントラクト導出： PHP → Countable , IteratorAggregate を自動実装 Go → iter.Seq[T] 互換メソッドを自動生成 Python → Sized , Iterable , Container を自動実装 組み合わせルール： Contains 有効 → LinearSearch を自動で有効化 Sort 有効 → ElementType の比較可能性を確認 LinkedList + Singly + Reverse → 非効率の警告を付与 17
18. 実際に生成できたもの リストコンテナのサンプルでは、同じ設計資産から複数言語のコードを生成で きた。 Go — 配列ベース + iter.Seq[T] 対応のイテレータ PHP — Countable , IteratorAggregate を自動実装 いずれも構成の知識のマッピングルールに基づいて生成され、テストも通過し ている。 18
19. まだ実験段階 スキルの構成はまだ試行錯誤中 実際のプロジェクトに導入して、本当に機能するか試していきたい 得た知見は改めて共有したい 19
20. AI がコードを書く時代の設計手法は、まだ誰も正解を持っていない 20
21. 自分も手探りなので、一緒に試して、共有しあえたら 嬉しい。 21
22. 「動くコード」から 「構造化された仕様」へ 22
23. ありがとうございました @polidog 23