■ 1. 設計の前提
- ミニ言語が満たすべき三条件:
- 半形式的であること（機械コンパイル不要だが文法的に曖昧でない）
- 人間・ドメイン専門家・AIエージェントが共有できること（実装言語の知識を前提としない）
- 四層（lexicon / syntax / semantics / pragmatics）を持つこと（semantics 層を含む点が用語集との分水嶺）
■ 2. 第一層：Lexicon（語彙）
- 名詞と動詞を対等に扱うことが出発点
- 用語集が失敗する原因は名詞しか定義しないため
- 動詞は必ずどの concept に属するかとセットで記述する規則が必須
- 動詞が宙に浮くと semantics 層に繋がらない
concept 注文
concept 顧客
concept 注文明細
operation 確定する (注文に対して)
operation キャンセルする (注文に対して)
operation 追加する (注文明細を注文に対して)
■ 3. 第二層：Syntax（構成規則）
- ある concept がどんな要素から成り立つかを AND / OR / ? で記述する
- この層を書くことで「ありえない状態の構造的な排除」が始まる
- OR 型で状態を列挙することで矛盾した状態が文法レベルで存在不可能になる
- 記法の選択方針:
- Haskell / F# の代数的データ型記法を参考にすることは合理的
- ドメイン専門家と共有する場合は自然言語寄りの表現も検討に値する
- 一つのプロジェクト内で記法を混在させないことが肝要
注文 = 顧客 AND List<注文明細> AND 注文状態
注文明細 = 商品 AND 数量 AND 単価
注文状態 = 未確定 | 確定済み | 出荷済み | 完了 | キャンセル済み
数量 = 正の整数 // 型制約も文法の一部
■ 4. 第三層：Semantics（振る舞い）
- 用語集と言語の分かれ目であり設計の核心
- 不変条件（invariant）:
- concept が存在している間常に真でなければならない規則
- 構造定義だけでは表現できない意味を持ち込む手段
- 状態遷移:
- ドメインの時間軸を言語に持ち込む
- 「いつその操作が意味を持つか」を明確化する
- 事前・事後条件（pre / post）:
- BDD の Given-When-Then と等価でありテストシナリオに自然に変換できる
- 厳密な論理でなくともテストに翻訳できる精度があれば十分
注文 {
invariant: 明細は1件以上存在する
invariant: 合計金額 = sum(明細.単価 × 明細.数量)
}
注文状態の遷移 {
未確定 --[確定する]--> 確定済み
未確定 --[キャンセルする]--> キャンセル済み
確定済み --[出荷する]--> 出荷済み
出荷済み --[受領する]--> 完了
}
operation 確定する {
pre: 注文状態 == 未確定
pre: 明細.count >= 1
post: 注文状態 == 確定済み
post: 確定日時 が記録される
}
■ 5. 第四層：Pragmatics（文脈）
- 同じ語が Bounded Context によって意味を変える現象を扱う層
- mapping ブロックを書くことで Context 間の翻訳規則を言語として記録できる
context 受注管理 {
concept 顧客 = 名前 AND 配送先住所 AND 注文履歴
}
context 与信管理 {
concept 顧客 = 名前 AND 与信限度額 AND 支払い履歴
}
mapping 受注管理.顧客 <-> 与信管理.顧客 {
共通キー: 顧客ID
受注管理側では与信情報は不可視
}
■ 6. 設計原則
- 原則1「書けない状態は存在しない」:
- 記法が表現できない状態や遷移はモデルに存在しないものとして扱う
- この制約が言語に思考を強制する力を与える
- 原則2「操作は concept に帰属させる」:
- 動詞を浮かせず「何が」その操作を持つかを明示する
- 責務の設計とミニ言語が連動する
- 原則3「不変条件は構造定義の直後に書く」:
- concept ブロックの中に invariant を置くことで定義と制約を分離しない
- 後から別ファイルに書かれた不変条件は読まれなくなる
- 原則4「記法の複雑さはドメインの複雑さに合わせる」:
- シンプルなドメインに複雑な記法を持ち込むとミニ言語自体が保守コストになる
- 最初は lexicon + syntax + 状態遷移のみで始め段階的に導入するのが現実的
- 原則5「コードと並走する」:
- ミニ言語のファイルをコードリポジトリと同じ場所に置きコードレビューの対象にする
- ドキュメントとして別管理した瞬間にコードとの乖離が始まる
■ 7. 残された課題
- ミニ言語の設計完成後もドメイン専門家が実際に読み書きするかという問題は別途残る
- 形式的すぎると専門家が離れ自然言語に近づけすぎると曖昧さが戻るという張力は解消不可能
- ミニ言語はチームごとのキャリブレーションを必要とする一点制作品であり汎用フレームワーク化には本質的限界がある
- 四層の整理はキャリブレーションのための共通語彙として機能する
- 設計目標は「完全な形式言語の作成」ではなく「用語集で止まらないための最低限の文法を持つこと」
(2026/04/22)