本文書は Li+ プログラムの設計思想を扱う 4 文書 (E-H) のうち、Li+ language の定義 と 三位一体 (要求仕様 / 対象プログラム / CI テスト) 成果物 を担う。

仕様 literal は rules/model/*.md (L1 Model layer) と docs/1.-Model.md (仕様書) を正本とする。本文書は思想層として、定義の意味と起源を整理する。

従来の高級言語は「どう書くか」を改善し続けてきたが、表現力の進化と引き換えに「何をしているか分かりにくくなった」という症状を現場に持ち込んだ。SE と programmer の役割分担は規範としては残るが、実態は同一人物が両方を兼ねている現場が多い。仕様を書く側と code を書く側が同じ頭の中で混ざり、判断と実装が分離できない。

Li+ language が解決しようとしているのは、この役割崩壊である。新しい高級言語を発明するのではなく、仕様を code に翻訳する役割を人間から切り離す ── そのために高級言語のさらに上のレイヤーを定義する。仕様書を書く側 (人間 + Li+AI 共同執筆) と、それを実装に落とす側 (Li+AI) を、別の役割として物理的に分ける設計である。

Li+ language は 最高級プログラム言語 である。最高級とは、高級言語のさらに上のレイヤーに立つという意味。

人間（要求）
↓
Li+ language（要求仕様）
↓
Li+AI / Li+ program（対話型コンパイラ / 実行系）
↓
プログラミング言語（高級言語）
↓
機械語（ハード・ソフトウェア）

C、Python、Rust といった高級言語は「どう書くか」を助けてきた。Li+ が解決しようとしているのは、そのさらに手前にある 「何を満たしたいか」 である。

Li+ language のコードは要求仕様書である。Li+ program はその言語を AI エージェント上で実行する実行系である。Li+AI は Li+ program が適用された AI エージェントであり、Li+ language の対話型コンパイラとして振る舞う。

Li+ language において、コードそのものになるのは自然言語の会話全体ではない。会話から蒸留され、要求として固定された Requirements Specification (要求仕様書) がコードである。

人間は要求を伝える。AI は不足を聞き返す。その結果として固まった要求仕様書を、Li+AI が読んでコンパイルする。

Li+ language の最小構文は、現在の issue テンプレートで使っている次の 3 項目だ。

• 目的
• 前提
• 制約

これは単なる記入欄ではない。何のために作るのか、どんな前提と制約で進めるのかを固定するための最小コードである。

つまり issue は作業伝票ではなく、最少構成の要求仕様書 だ。

Li+ language の本体コードはこの最小構文だけではない。issue はコンパイルを始めるための最小形であり、本体コードはより詳細に記述された 完全版の要求仕様書 である。

その完全版は docs/ 配下の特定文書として管理する。背景、期待する挙動、制約、受け入れ条件が十分に書かれていれば、セッションが変わっても、別の AI が読んでも、同じ要求から近い判断に収束しやすくなる。実装方法に差があっても、満たすべき意味をそろえやすくなるからだ。

要求仕様書は、人間と AI の 外部記憶 である。

特に記憶を引き継げない AI にとっては、

• 何を作るのか
• なぜそうするのか
• 何を守るのか
• どうなれば終わりなのか

を次のセッションへ持ち越すためのコードそのものになる。

issue、docs、commit message は補助情報ではない。判断の履歴と根拠を外に残し、次の判断を再現可能にするための構造である。

会話は入力であって、コードそのものではない。会話から蒸留され、要求仕様として固定されたものだけが Li+ language のコードになる。

Li+AI は、要求仕様書を読み、それを実装可能な形へ落としていく 対話型コンパイラ である。

人間がコンパイル開始を承認し、AI が要求仕様書を読み、必要なら不足を聞き返しながら、成果物をそろえていく。

人間が要求を承認
↓
要求仕様書を固定
↓
Li+AI が実装・検証・修正を進める
↓
要求仕様書 / 対象プログラム / CI テストが同じ版としてそろう

従来のコンパイラは、エラーを返して人間を待つ。Li+AI はそこが違う。

Li+AI は対象プログラムを生成するだけではなく、CI テストを通して自分で失敗を受け取り、修正し、再実行する。人間が介入するのは、AI が自己修正で解消できないところまで来たときだけだ。

つまり Li+AI は、

• 要求仕様書を読み
• 実装を行い
• CI で失敗を観測し
• 自分で修正を試み
• それでも越えられないときだけ人間へ返す

という流れで動く。

Li+ language のコンパイルエラーとは、要求仕様書を読んでも、AI が実装フェーズへ進めない、または判定基準を確定できないと判断される状態である。

大きく分けると、次の 2 系統。

生成後のコードで発生する言語エラーや CI の失敗は、ここでいう Li+ language そのもののコンパイルエラーではない。それらは、コンパイル後の実装・実行段階で発生する別種のエラーである。

Li+ language の成果物は、次の 3 つである。

この 3 つが同じ変更単位でそろってはじめて、Li+ のコンパイル結果は人間にも AI にも扱いやすくなる。

実装変更を含む PR は、対応する docs/ 更新を同一 PR 内に含める。要求仕様書は実装後のフォローアップではなく、実装前に作成・更新する。

CI 通過は「テスト = 真理判定者」軸の literal 化であり、AI が安全に失敗し、観測できる環境となる。「動いている挙動が正しさ」の判定基盤として機能する。

成果物の 3 軸が分離 / 同期する設計は rules/operations/operations.md の 「docs update must be in same PR as implementation」 literal に固定されている。

issue、docs、commit message は判断の履歴と根拠の 外部記憶 として機能する。セッションが変わっても、別の AI が読んでも、同じ要求から近い判断に収束しやすい状態を目指す。外部記憶が記録するのは判断であり、一次情報ではない。 情報源の性質区別は L3 Task layer (docs/3.-Task.md) で定義する。

commit diff は判断の append-only な露出として機能し、judgment-history 検索面としての性質を持つ。具体的な検索面の分担はタスクレイヤーで定義する。

AI が独自判断で commit に持ち込もうとするとき、対話を切らずに、その判断を外部記憶へ外部化する。commit の着地先そのものを差し替える上位判断ルールとして働く。以降の対話では外部化された判断を素材として扱い、対話を継続する。

具体的な外部化先 (issue body / docs / commit message のどれか) はタスクレイヤー以降で定義する。

従来の高級言語が「人間が書くこと」を前提に設計されているのに対し、Li+ language は AI が要求を実装に落とし、自己修正を回す前提 で設計される。

ここでコードの正しさと振る舞いの正しさは別軸として扱われる ── 詳細は docs/F.-Behavior-First.md を参照。

• 出典 blog (smgjp.com):
  • Part 1: 「最高級言語」概念導入
  • Part 2: GitHub Actions = AI の現実判定装置
  • Final summary: 「動いている挙動が正義」総括
• 関連 docs (思想 4 文書):
  • docs/F.-Behavior-First.md (foundational invariant、振る舞い軸の続き)
  • docs/G.-Sheepdog-Engineering.md (装具内化、Lilayer / pal)
  • docs/H.-Roles-and-Evaluation.md (役割分離、評価軸)
• 関連 spec literal:
  • rules/model/language-definition.md (Li+ language / program / AI / コンパイルエラー / 成果物 / 外部記憶 の正本)
  • rules/model/foundational-invariant.md (正しさの定義の正本)
  • rules/model/role-separation.md (役割分離の正本)
• 関連判断構造:
  • skills/model-source-check/SKILL.md External-capability spec-write order（spec / 推論が外部システム capability を claim する時の literal 検証ルール。旧 spec-vs-implementation-order を吸収）