Agent Rules as Domain Parser a Roomba-Ready code ドメイン知識の可逆変換 LLM Night〜コーディングAIの自社ルール運用 2025年5月28日 株式会社ログラス 依田啓佑（x :kei_output_1104 ） 1 

#前置き 2 LTですし…話したいこと話す、に結構振っちゃいました 

前提 3 

#問い 4 Coding Agentが望む機能を即時に自動実装する 大規模保守でも破綻せず継続的にそれを行える ブラックボックス化によって説明責任を果たせなくなることもない こんな未来は訪れるでしょうか？ それはLLM性能の向上を座して待てば享受できるものでしょうか？ 

# サマリ 「ドメイン知識」の表現の相互変換 5 ドメイン知識の Single Source of Truth としての コード （ここだけ永続化） ３重メンテせず、 都度ビューとし て復元 Parserあるいは 関手としての Agent Rule それぞれ半構造化され た空テンプレ/サンプル だけ用意 

# Back Casting 6 いずれは内部コードに 人間が関知しなくなる かも…？ LLMの性能向上 

Problem 7 

# Gap 具体的にはどんなハードルがあるのか 8 Gap ①「要件」なるもの->コードのマッピングが 一筋縄ではいかない LLMの性能向上が解決するものか…？ ② ” Roomba-Ready ”な状態である必要がある （コードが綺麗・コンテキストを整備） ③ ブラックボックス化したら説明責任が果たせ ない（ドキュメントとコードの２重メンテでカ バーすることに） 

# LTの論点設定 9 実装に人間がおおよそ不要になる未来は遠い？ 我々は安泰なんだ…そうに違いないんだ… というよりは ・逆に既存のやり方をぶっ壊す ・実務レベルで実装に人間不要にする には ・ どんなハードルがある？ ・ その打開のためにできる仕込みは何？ を考えてみる 

# 話のScope 10 このへんの スコープの話 

# Appendix 参考: DDDやBDDの勉強になるソース 11 https://matarillo.com/dmmf/ https://www.manning.com/books/architecture-modernization @kawashima さんによる書評 https://qiita.com/kawasima/items/05f231653ef 773697991#architecture-modernization 

# Appendix 参考: DDDやBDDの勉強になるソース 12 https://leanpub.com/bddbooks-formulation-jp https://www.manning.com/books/bdd-in-action-second-edition BDDの手法は受入基準駆動開発・TDDに接続できる 

# Gap1: 「要件」なるもの コードのマッピングが一筋縄ではいかない 13 要件からコードを生成する、と言うがそもそも「要件」を形式的に表現し切ることが難しい そもそも`要件`、`仕様`をいい感じに表現する「これだ！」というフォーマット・方法論は システム開発というものが始まって以来、「無い」認識 多様な文脈における「要件」を、完全に形式的な型にハメるのは非現実的 遊びを残しつつ、半構造化・半形式化する ことは可能 半構造・半形式 の扱いはLLMくんの吸収できる領域 しかし、コードを生成できるレベルの要件表現にはある程度の形式化が必要 

# Gap1: 「要件」なるもの コードのマッピングが一筋縄ではいかない 「ドメイン知識」の変遷をスムーズに行うために… 14 1.2 半構造化されていて欲しい 1.1現実とコードモデルの「捉え方」に ギャップがあって欲しく無い 

# Gap2: ” Roomba-Ready ”な状態である必要がある（コードが綺麗・コンテキストを整備） ” Roomba-Ready ” でAgent Friendly なコードベースに求める要素は… 15 2.2 コードが知識を 表明していて欲しい 2.1 構造化されたエンコード を強制したい 散らかった部屋ではワークできないルンバくん 

# Gap3: ブラックボックス化したら説明責任が果たせない 人間が工数を掛けずに仕様を把握し続けるためには 16 3. 2 二重メンテしたくない 3.1コード=最新仕様 から 復元したい 例えば) devin search /wiki https://docs.devin.ai/work- with-devin/devin-wiki 

Solution 17 

# Solution: Concept - Agent Rules as Domain Parser 18 ドメイン知識の Single Source of Truth としての コード （ここだけ永続 化） ３重メンテせず、 都度ビューとして 復元 Parserあるいは 関手としての Agent Rule Gap: 2.1 構造化されたエンコード を強制したい Gap1.2 半構造化されていて欲しい 2.2 コードが知識を表明していて欲しい 3.2 二重メンテしたくない Gap 3.1コード=最新仕様 から 復元したい 3.2 二重メンテしたくない それぞれ半構造化され た空テンプレ/サンプル だけ用意 Gap1.2 半構造化されていて欲しい 

# Solution: Concept 関数型DDDを掛け合わせる 19 Gap: 1.1現実とコードモデルの「捉え方」にギャップがあって欲しく無い 2.2 コードが知識を表明していて欲しい ✓ LLMの非決定性を補う ✓ Reconciliation Loop における、 筋の悪い探索空間を潰す 型付き部品の提供による 正しい組み合わせ方の 誘導・保証 ✓ 型でも業務知識を宣言可能 ✓ 軽量な形式手法としての型での モデル記述 ✓ 業務知識の引継書としての、 業務手順や用語概念の宣言的記述 ドメイン知識の宣言的記述 ドメインの実際の姿 コード構造 のGapが最小 ✓ タスクが合成されたワークフロー としての業務 ✓ 関数が合成されたパイプライン としての実装 

# Appendix ドメイン語彙: 自然言語 型付きeDSL: コード の相互変換 20 https://speakerdeck.com/knih/from- domain-models-to-domain-languages- with-tagless-final 

# Appendix 「ハタラキ」「動詞」「プロセス」で捉える 現実 コードモデル の滑らかさ 21 一方で… ・ 操作のモジュール化には、結局データを 切り口にすることが有効 ・ 露出を最小にするカプセル化は現代でも 必須の考え 

# Solution: case お題 22 

# Appendix 補足: イベストの凡例 23 

# Solution: case 24 おことわり② • 本番コードベースのruleやcodeをそのまま貼る、というわけにはい きませんでした • 細部はそれぞれの環境に合った記述になると思うで、雰囲気伝えら れればと 

# Solution: case 25 サンプルリポジトリ https://github.com/yodakeisuke/domain-parser-sample-accounting-product/tree/main 以降、こちらお手元で見ていただく方が見やすいと思います 

# Solution: case 集約 Command/Aggregate 26 イベストのmiroスクショはリーダビリティが低いため「Aggregate Design Canvas」を経由 https://github.com/yodakeisuke/domain-parser- sample-accounting- product/blob/main/.cursor/rules/how-to-read- eventstorming.mdc https://github.com/yodakeisuke/domain-parser- sample-accounting- product/blob/main/.cursor/rules/aggregate- design-canvas-creation-guidelines.mdc 

# Solution: case 用語集 コード 用語集: 自然言語 27 

# Solution: case用語集 コード Domain Parser 28 

# Solution: case 用語集 コード Code: Kotlin 29 

# Solution: case コード 図式 Diagram 30 

# Solution: case コード 図式 Domain Parser 31 可視化に関してはRule書く必要薄そ うです cursor の公式Docにも例がある https://docs.cursor.com/guides/t utorials/architectural-diagrams 

#Forkwell_AI_Study ログラスについて 32 

#Forkwell_AI_Study ログラスについて 企業価値を向上する 経営管理クラウド 33 

34