やって来るAI開発時代、変わりゆくシステム開発フローのひとつに データモデル × 仕様駆動開発 があると思います。
これを検証する為にデータモデルツールを バイブコーディングで自作 し、ツールで作成したデータモデル（ spec.md ）を使用して GitHub Spec Kit のフローで家計簿管理のデモシステムを作ってみました。
生成AIは基本的に Antigravity を使用しました。
コンセプト
業務システムの目的は基本的に台帳を管理することです。台帳について考える時「 どのような 台帳を管理するか」と「 どのように 台帳を管理するか」という二つの観点があります。
「どのような」に対応するのがデータモデル（≒ ドメインモデル）で変更コストが大きいです。一方、「どのように」に対応するのがUIやAPIで変更コストが比較的小さいです。
生成AIは試行錯誤が得意とはいえ、都度全体に影響を与える変更が入ってしまっては実務として耐えられません。そこで、変更コストが大きいデータモデル（≒ ドメインモデル、何を管理したいか）を先に固めておいて、変更コストが小さいUIやAPI等を生成AIを活用して試行錯誤する、というのが基本的なコンセプトです。
また、どのような方法であっても業務要件を生成AIに伝える必要がありますが、実装と切り離したデータモデルやドメインモデルとして業務要件を整理することで最も効率よく正確に生成AIとコミュニケーションすることが出来るのではないか、という気もしています。
まずは開発過程をスクショで見てください
データモデルの作成
データモデルにはドメイン層に相当するビジネスロジックの埋め込みまで行います。
-
テーブルを配置し、関連線を引く
-
コード定義はサブビューで定義する
-
テーブル定義を編集する（外部キーやユニークキーは複数定義できます）
データ型として作成したコード定義を選択できます（値オブジェクトは後述）
-
ビジネスロジックは自然言語で記入する
-
AIに依頼してサンプルインスタンス作成（geminiのAPIを利用）
-
サンプルインスタンスを見てモデルの妥当性を検証する
- 自然言語のロジックがAIに伝わるか確認
- インスタンスを見てモデルの不備を確認
- GitHub Spec Kitに渡してテストの前提データとして使用（機能テストのとき、マスタデータなどスコープ外の前提データを賄う）
-
集約を定義する（機能の単位をAIが検討する材料にします）
-
値オブジェクトの定義も可能（今回の例では使っていません）
このようにデータモデル／値オブジェクト／集約の定義を統合することで、 ドメインモデル全体を設定 できることを目指しました（ ドメインモデリングツール ）。
Github Spec Kitのフローで開発
まずは下記の３点を用意します。
※赤枠は上から順番に「システム開発憲法」「データモデル正本」「全体鳥瞰図・CRUD図」です。
-
システム開発憲法
つまりconstitution.mdです。ここにMyベストプラクティスを詰め込みました。かといって煩雑になりすぎても本質を見失うので、シンプルに把握できる範囲に留めています。 -
データモデル正本
ツールから出力したspec.mdです。 -
全体鳥瞰図・CRUD図による構成確認
機能の単位をAIと相談しながら決めます。名前はspec.mdです。
ここで決めた機能を Github Spec Kit の開発単位にします。今回は下記のように決めました。
-
各機能の仕様を策定
ドメインモデル以外の仕様は各機能のspec.mdの中で決める必要があります。例えば、年月プルダウンに表示する期間の範囲はドメインモデルには含まれないので、各機能のspec.mdに含めました。FR-004: 年月選択プルダウンの動的生成 プルダウンの年月選択肢には、最大で過去6か月分の確定月（存在する場合）と、最新の未確定月（最も新しい確定月の翌月、確定月が1つもない場合はシステム開始月 2026-04-01）のみを表示・選択できるように制御する。
完成した家計管理システム
ここから先は完全自動生成です。バグの修正依頼も対話で行いました。
今回は簡単の為にデータベースは使用せず、データの管理はメモリ上のみとしました。
AIが生成したサンプルデータを初期データとして取り込んでいるので、起動してすぐイメージを確認できます。
-
ダッシュボード
-
取引履歴一覧
-
取引登録
取引後残高は ドメインモデルにて自然言語で定義した通り 、月初残高と当月の先行する収支取引／為替取引／手数料／利息等を考慮して計算されています。
-
予算設定
-
口座管理
-
費目管理
-
月次確定
気になった方はGitHubを見に来てください！
-
オリジナルのデータモデリングツール
SchemaDesigner -
家計簿管理デモシステム
NestLedger
今後の課題：システム開発憲法（ constitution.md ）の改善
-
Chain-of-Thought等のプロンプト技術を応用することで論理の一貫性を強化する -
spec.mdやplan.mdの人間にとっての読み易さを担保する（レビュー容易性の向上） -
spec.mdにMermaid等の描画ツールを組み込み、百聞は一見に如かずを実現する（サンプルインスタンスを組み込んだ画面イメージで仕様のブレを防止）
まとめ：エンジニアの価値は「設計・制約の定義」へ
これからの時代、エンジニアの価値は 「ドメインの本質を捉えたデータモデルを設計すること」 になるのではないかと考えています。これによって 「AIが迷子にならないための開発フローを設定」 できるのではないでしょうか。
日進月歩、いや秒進分歩の生成AIの世界で何が起きるのか、これからも可能性を探っていきたいです。
※参考
Github spec kit
Github Spec Kitのリポジトリです。
業務システムモデリング練習帳
サンプルとして挙げたデータモデルは本書を参考にさせて頂きました。またオリジナルのデータモデリングツールは、もともと渡辺氏作成のツールに自分なりのアレンジを加えたいという願望から始まっています。
実践ドメイン駆動設計
システム開発憲法（ constitution.md ）を書く際の参考にさせて頂きました。