アプリケーションを意味的にアップデートし続ける「仕様書言語」の案

第二幕：Agentic Coding 完全自動化 → 要件定義の自動化への続きで、検討を深めています。

要素

基本的な構造について考える際に、以下のような要素が重要になります。

1. 言語定義に則った処理ができるよう、Markdownを使います
2. Markdownに記号化された情報を埋め込みます
3. 記号化された情報は、ルールベースで集約可能です
4. 記号化された情報は、参照性能と履歴性能を兼ね備えています

と、設計しています。

実装

実装については、以下のような段階的なアプローチを考えています。

1. 記号化された情報を処理するために、JSON Schemaを用いて形式統一します
2. Schemaに基づいて抽出するツールを作成します
3. 抽出結果をプログラム言語的な表現に変換します
4. SerenaなどのLSPを通して検索性を高めます

という流れで進める予定です。

最終的にはGraph化した情報として可視化され、意味の距離を取ることが理想です。

効果

この仕組みが実現できれば、以下のような効果が期待できます。

1. 変更された情報は履歴性能により変更が追跡されます
2. 変更された影響範囲は、LSP（あるいはGraphの伝搬）により把握されます
3. 把握した影響範囲に基づいて、要件の精査を行い、整合性をとります

これらが動的に処理されることで、自動更新すること、実装への連携を行うこと、の2つが実現可能になると考えています。

留意点

平たくいえば、開発言語のように定義された言語使用がない場所に、開発言語のような「仕様書言語」定義を持ち込もうとしています。

ただし、2つ大きな違いがあります。

1. ファイルシステム依存をなくすこと
2. 言語定義はC3L/Climptに移譲すること
   です。AI/LLM時代においては、全ての動的な変更追跡をAIに移譲すべきであろうと考えています。

開発言語はファイルシステムへの依存度が高いです。
全てのコードが管理され、構造が設計されて構築されます。import階層は重要な要素です。

一方で、意味的定義である要求表現には、ファイル定義は存在しません。この点を見失うことなく進めていく必要があります。
管理すべきは、要求を起点に得られる意味表現と、要求変更が及ぼす影響の範囲であり、それ以上ではありません。