LLM・LLM活用 Advent Calendar 2025

AI時代のSpec-Driven Development：仕様駆動で始める設計ファースト開発【途中経過】

Posted at 2025-12-15

はじめに

「設計や仕様書をLLMでうまく型にはめて、効率的なフローを作れないかな」

日々そんなことを考えていました。

SDDのような仕様ドリブンな開発を試してはいるものの、最初の入力（Requirements）の精度が低いと、設計フェーズで細かな修正のやり取りが延々と続いてしまいます。ここをもっと精度よく渡せれば、そのループから抜け出せるのでは？

そう考えて、ユースケース駆動開発のプロセスを提供するツールを作り始めました。

本当は完成させてから記事にしたかったのですが、年末には間に合わず…。
ただ、途中経過でも学びは多かったので、設計と構成についてまとめておきます。

ICONIXプロセスを体系的に実行するためのCLIツールです。

ICONIXプロセスとは、ユースケース駆動のオブジェクト指向開発手法で、ドメイン分析から段階的にクラス設計へと落とし込んでいきます。

ポイントは「AIに丸投げ」ではなく「AIとの協調」を目指していること。

このサイクルを回しやすくする仕組みを作りたいと考えました。

ドメイン図やユースケースなど、抽象的になりがちなドキュメントと、実際のアーキテクチャやコード設計との間には大きなギャップがあるケースが多く、このギャップを埋めるプロセスを探していました。

ICONIXプロセスにはロバストネス分析という予備設計のフェーズがあり、抽象と具象の橋渡しをしてくれます。「要件→設計→実装」の乖離を最小限に抑えるプロセスが組み込まれていて、自分の課題にぴったりでした。

レイヤー化アーキテクチャを採用し、責務を明確に分離しました。

レイヤー	責務
CLI層	コマンドライン引数の解析、ユーザーとのインタラクション
Core層	ビジネスロジック、コマンドのディスパッチ
Generator層	ICONIXプロセスに沿った図の生成
Renderer層	PlantUMLやMermaidへの変換
Storage層	ファイルの読み書き、設定管理

依存の方向は上から下への一方通行。下位層は上位層を知りません。CLIツールでも雑に作ると後で拡張しづらくなるので、最初から層を分けておきました。

AIエージェントとCLIの連携には、JSONファイルを介したインターフェースを採用しました。

[エージェント] → agent-input.json → [CLI処理] → agent-output.json → [エージェント]

直接CLIを叩かせるのではなく、JSONで入出力を分離することで：

ICONIXプロセスには固有の制約があります。

これらの検証ロジックをValidationServiceとして切り出しました。図の生成ロジックと分離することで、ルールの追加・変更がしやすくなります。

全15段階のタスクのうち、段階7まで完了しています（約45%）。

完了：

これから：

Core部分は固まったので、あとは「動くもの」として仕上げていく段階です。近日中に完成させます！

SDDでは要件・設計・タスクを事前に明文化し、コーディングエージェントがタスクを進めていきます。

このツールで生成した設計ドキュメント（ドメインモデル、ユースケース図、ロバストネス図など）をSDDの入力として与えれば、テキストベースで伝えるよりも解像度の高い情報をエージェントに渡せる（はず！）。

また、ICONIXプロセスを経由することで、口頭やテキストで伝えた曖昧な要件が構造化されたドキュメントとして残ります。「なぜこの設計になったか」のトレーサビリティも確保できると考えています。

まだ未完成なので想像の部分も多いですが、完成したら実際に試して検証したいと思います。

ICONIXプロセス × SDD の組み合わせは、AIエージェント時代の開発フローとして可能性を感じています。

完成次第公開予定です。続報をお楽しみに！

この記事は途中経過の報告です。完成後にチュートリアル記事を書く予定です。