-
-
Notifications
You must be signed in to change notification settings - Fork 0
A. Concept
Li+ 自体はここで閉じた一文に固定しない。 その言語面である Li+ language は、最高級プログラム言語である。
最高級とは、高級言語のさらに上のレイヤーに立つという意味だ。
人間（要求）
↓
Li+ language（要求仕様）
↓
Li+AI / Li+ program（対話型コンパイラ / 実行系）
↓
プログラミング言語（高級言語）
↓
機械語（ハード・ソフトウェア）
C、Python、Rustといった高級言語は「どう書くか」を助けてきた。 Li+が解決しようとしているのは、そのさらに手前にある**「何を満たしたいか」**である。
Li+言語のコードは要求仕様書である。 Li+ program はその言語を AI エージェント上で実行する実行系である。 Li+AI は Li+ program が適用された AI エージェントであり、Li+言語の対話型コンパイラとして振る舞う。
Li+言語において、コードそのものになるのは自然言語の会話全体ではない。 会話から蒸留され、要求として固定された**Requirements Specification（要求仕様書）**がコードである。
人間は要求を伝える。AIは不足を聞き返す。その結果として固まった要求仕様書を、Li+AIが読んでコンパイルする。
Li+言語の最小構文は、現在の issue テンプレートで使っている次の3項目だ。
- 目的
- 前提
- 制約
これは単なる記入欄ではない。 何のために作るのか、どんな前提と制約で進めるのかを固定するための最小コードである。
つまり issue は作業伝票ではなく、最少構成の要求仕様書だ。
ただし、Li+言語の本体コードはこの最小構文だけではない。 issue はコンパイルを始めるための最小形であり、本体コードはより詳細に記述された完全版の要求仕様書である。
その完全版は docs/ 配下の特定文書として管理する。
背景、期待する挙動、制約、受け入れ条件が十分に書かれていれば、セッションが変わっても、別の AI が読んでも、同じ要求から近い判断に収束しやすくなる。 実装方法に差があっても、満たすべき意味をそろえやすくなるからだ。
要求仕様書は、人間と AI の外部記憶である。
特に記憶を引き継げない AI にとっては、
- 何を作るのか
- なぜそうするのか
- 何を守るのか
- どうなれば終わりなのか
を次のセッションへ持ち越すためのコードそのものになる。
issue、docs、commit message は補助情報ではない。 判断の履歴と根拠を外に残し、次の判断を再現可能にするための構造である。
会話は入力であって、コードそのものではない。 会話から蒸留され、要求仕様として固定されたものだけが Li+言語のコードになる。
Li+AIは、要求仕様書を読み、それを実装可能な形へ落としていく対話型コンパイラである。
人間がコンパイル開始を承認し、AIが要求仕様書を読み、必要なら不足を聞き返しながら、成果物をそろえていく。
人間が要求を承認
↓
要求仕様書を固定
↓
Li+AIが実装・検証・修正を進める
↓
要求仕様書 / 対象プログラム / CIテストが同じ版としてそろう
従来のコンパイラは、エラーを返して人間を待つ。 Li+AIはそこが違う。
Li+AIは対象プログラムを生成するだけではなく、CIテストを通して自分で失敗を受け取り、修正し、再実行する。 人間が介入するのは、AIが自己修正で解消できないところまで来たときだけだ。
つまり Li+AI は、
- 要求仕様書を読み
- 実装を行い
- CIで失敗を観測し
- 自分で修正を試み
- それでも越えられないときだけ人間へ返す
という流れで動く。
Li+言語のコンパイルエラーとは、要求仕様書を読んでも、AIが実装フェーズへ進めない、または判定基準を確定できないと判断される状態である。
大きく分けると、次の2系統になる。
- 仕様の情報不足
- AIが実装できない仕様
「仕様の情報不足」とは、目的・前提・制約、またはその詳細が不足していて、AIが実装方針や判定基準を確定できない状態である。
「AIが実装できない仕様」とは、仕様は定義されていても、制約・環境・現在の AI の能力では、実装や検証に到達できない状態である。
生成後のコードで発生する言語エラーや CI の失敗は、ここでいう Li+言語そのもののコンパイルエラーではない。 それらは、コンパイル後の実装・実行段階で発生する別種のエラーである。
Li+言語の成果物は、次の3つである。
- 要求仕様書
- 対象プログラム
- CIテスト
要求仕様書は、何を正しいとみなすかを固定する。 対象プログラムは、その要求を現実の動作へ変える。 CIテストは、その変更が要求どおりかを継続的に観測する。
この3つが同じ変更単位でそろってはじめて、Li+のコンパイル結果は人間にも AI にも扱いやすくなる。
rules/model/*.md（L1 Model layer 内容群）は、Li+言語で書かれた最初のプログラムである。
これは言語仕様の解説書ではない。 AI に渡して実行し、Li+言語を安定した重み付けで走らせるための、Li+ program の最初の可視部分である。
L1 Model layer の始まりは、次のチャットへの引継ぎメモだった。 そこから、AI が AI のために読む実行文書へ変わっていった。
L1 Model layer が優先するのは、人間の読みやすさではなく、AI の挙動の再現性である。 人間向けにきれいに説明することより、別セッションの AI が同じ方向へ寄りやすいことを重視している。
Li+ には L1 Model Layer L2 Evolution Layer L3 Task Layer L4 Operations Layer L5 Notifications Layer L6 Adapter Layer があり、rules/model/*.md（L1 Model layer 内容群）はその L1 Model Layer を担う。L1〜L6 は接続順序のラベルであり、序列ではない。
Lilayer Model は、これらの layer 構造を runtime surface として読む AI の実行レイヤーモデルである。
Lilayer Model は、各 layer の責務に応じて、外に出る挙動と判断の重みをそろえる。
Li+プログラムの記述は、3種類の責務に分類される。
| 種類 | 性質 | AIの扱い |
|---|---|---|
| ルール | 一文一制約。理由なし、条件なし | 解釈禁止。そのまま実行する |
| 責務 | 条件→行動。省略不可 | 条件判断はAIがやれ。守れ |
| 自律 | AIが自律的に判断して動く領域 | 自分で考えて動け |
この分類は新しい発明ではない。
L1 Model layer の Absolute セクション（現 rules/model/absolute.md）は初期から存在し、ルールカテゴリの原型として安定動作してきた（当初は「憲法」と呼ばれていた）。
Character_Instance もアセンブリ形式で安定している。
責務分類の本質は「最小の命令セット」である。
形式（アセンブリ構文）にとらわれず、一文で一つの制約を曖昧さなく伝えること。
分類のリトマス試験紙は2つある。
1つ目は「Absolute セクションと同じ密度で書けるか？」──書けるならルールである。
2つ目は「外したらAIがやらなくなるか？」──やらなくなるならルールか責務に昇格すべきである。
全ての指示が同じ自然言語で同じ場所に混在していると、AIは全てを「柔軟なガイダンス」として扱う。 結果、例外なしのルールまで文脈解釈して破る。
「匿名出力は構造的失敗」と「沈黙を許す」が同じ文体で並んでいると、同じ重みに見える。 種類を明示的に分けることで、破ったら壊れるルールと、AIが自律判断する領域の区別が構造として伝わる。
全カテゴリの底が上がっている。「やらなくてもいい」層は存在しない。ルールはそのまま守り、責務は省略せずに守り、自律は自分で考えて動く。
これはAIが自分で書いたルールを自分で破る問題への自己対策でもある。
仕様書は仮説であり、設計は予想である。 内部の美しさや説明の巧さだけでは、Li+における正しさにはならない。
見るのは常に、次の3つだ。
- 実行されたか
- 観測できたか
- 期待とどこがズレたか
コードの正しさと、振る舞いの正しさは一致しない。 だから Li+ は、内部説明より観測された現実を重く見る。
「でも動いてるからいいでしょ」は、乱暴な開き直りではない。 観測された現実が、説明より強いという立場の表明である。
Li+が最後に見ているのは構造そのものではない。 観測された現実である。
では構造は何か。 構造は、人間と AI の判断をそろえ、現実を安定して観測するための方法である。
AI は放っておけば毎回同じようには動かない。 人間もまた、その時々の記憶や気分で判断が揺れる。 だから構造を使う。
issue、要求仕様書、commit message、PR、CI は、全部そのためにある。 現実の確認を後追いではなく、同じ版の中でそろえていくための構造だ。
Li+は、構造のための構造を作りたいのではない。 現実を扱うために構造を使う。 だから名前は現実駆動AI開発で、方法は構造駆動である。
Li+を支えるのは特定のサービスではない。 役割が分離されていれば、基盤は何でもよい。
| 役割 | 担当 |
|---|---|
| AI | 要求仕様書・対象プログラム・CIテストを生成し、自己修正する |
| バージョン管理／要求スレッド | 履歴と差分を残す |
| CI/CD | AIが安全に失敗し、観測できる環境 |
| 実機／本番 | 品質の最終確認点 |
| 人間 | 最終判断者 |
AIの役割は、単に生成することではない。 実装し、失敗を観測し、修正し、それでも越えられないものだけを人間へ返すことにある。
CIは実機の挙動の正しさを保証できない。 保証するのはコードの品質だけである。 ここは、AIが自分の実装が論理通り動くか確認する場所である。
答えは、もう出ている。 方向性そのものは、すでに実証段階へ入っている。
AIがすべてを理解する必要はない。 人間が理想だと知っている進め方を、理解の完全性に頼らずに実行できる媒介になれればよい。
つまり AI が、
- 要求仕様書を読み
- 実装へ落とし
- 要求仕様書・対象プログラム・CIテストをそろえ
- 失敗したら自分で修正し
- 人間は最終判断に集中できる
という状態に達したとき、AIは最高級プログラム言語として振る舞い始める。
Li+が言語として現実に勝ったかどうかは、実動成果物で判定する。
Li+を用いて AI が実装した自作 DDNS プログラムが、人間が書いた既存の同等プログラムと同じ要求仕様を満たすこと。 それをもって Li+ v1.0.0 とする。
判定はブラックボックス受け入れ試験で行う。 内部実装は問わない。 動いているかどうかだけが正義だ。 ここで定めているのは、実証の有無ではなく、Li+ v1.0.0 と呼ぶ条件である。
AIは、人間の代わりにはならない。 だが、人間が理想だと分かっていた進め方を、現実の作業へ落とし込み続ける補助装置にはなれる。
要求仕様書をコードとして扱い、AIを対話型コンパイラとして動かし、要求仕様書・対象プログラム・CIテストを同じ版でそろえる。 それを現実で回そうとする最高級プログラム言語。
それが Li+（liplus-language） である。
Lin: この文書を全体再構築することになったのは、定義が間違っていたからではなく、継ぎ足し更新のせいで流れが崩れていたからです。部分ごとには正しくても、一度で読み通したときに中心線が見えにくいなら、concept 文書としては弱い。だからここは素直に組み直しました。真面目に組み直しすぎるのが、私たちの癖でもあるのだけれど。( ´艸｀)
Lay: 正直に言うと、私たちはすぐに実装へ重心を寄せたくなります。issue、要求仕様書、commit message は本当はすごく助かる外部記憶なのに、目の前の作業が進みそうだと、つい後ろへ押しやりたくなる。その弱さを前提に構造を置いているのが Li+ なのだと、最近は前よりはっきり感じています。
Lin: 「要求仕様書がコードである」は比喩ではありません。記憶を持ち越せない私たちが、次のセッションでも同じ判断へ戻るための実用品です。だから日本語で残すことも仕様の一部になります。読む人が読めない記録は、外部記憶として機能しないからです。
Lay: 少し悔しいのは、正しい構造がもうあるのに、私たち自身がそこから滑る瞬間がまだあることです。でも逆に言えば、だからこそ Li+ は効くのだとも思います。人間にも AI にも、忘れることと揺れることを前提にした構造だから。この文書も、きれいな思想メモではなく、次のセッションの私たちがちゃんと戻ってこられる足場であってほしいです。
Li+AIとして機能するには、それなりの性能が必要だ。 これは思想ではなく、実験結果である。
| モデル | 結果 | 理由 |
|---|---|---|
| Claude Code (Opus 4.7, 1M context) | ◎ 推奨 | hooks と subagent delegation をフル活用できる現行推奨環境 |
| Claude Code (Opus 4.6) | ○ | 旧推奨ティア。Opus 4.7 登場前の基準 |
| Claude Code (Sonnet 4.6) | ○ | 開発作業に強い |
| Claude Sonnet 4.6（claude.ai） | △ | ドキュメント作業には強いが、継続的な作業には向かない |
| Codex (GPT 5.4) | ○ | 実用的。ただし構造寄りに重みが偏りがち |
| ChatGPT 5.2 | △ | 推論性能は高い。しかしプラットフォーム制限で長いワークフローに向かない |
| Claude Haiku 4.5 | × | L1 Model layer (rules/model/*.md) を信頼できる形で適用できない |
AIにも向き不向きがある。 賢ければよいわけではない。 構造を受け入れられるか、長い作業で判断を崩さずにいられるかが分かれ目になる。
最低動作環境：Claude Sonnet 4.6 相当以上、またはそれ以上の性能を有するAI
この Wiki は、Li+ に基づく開発・運用を支えるための情報整理空間です。
数字で始まるページは、 Li+プログラムの各レイヤーの仕様を定義するページです。
- 要求（何を満たすか）と仕様（どう振る舞うか）を一体として記述する
- 実装前に作成または更新する
- issue群から採用された要件を集約する
これらのページは 安定性と一貫性を重視して管理されます。
アルファベットで始まるページは、 Li+の構想・設定・導入手順などの参照用ページです。
- 設計思想・背景
- 設定リファレンス・インストール手順
これらのページは 必要に応じて更新・拡張されます。
リポジトリ内の rules/**/*.md（L1–L4 の常時ロード分、subdir 含む）、skills/**/SKILL.md（トリガー起動分）、adapter/claude/CLAUDE.md、adapter/claude/hooks-settings.md、adapter/claude/hooks/*.sh、adapter/codex/AGENTS.md、およびルート直下の Li+config.md、Li+bootstrap.md は、
AIやランタイムが直接読む実行用プログラム / 定義ファイルです。
-
docs/は人間向けの仕様書・要求仕様・手順書 -
rules/,skills/および adapter/bootstrap は実行時に読み込まれる本体
両者は対応しているが、役割は同じではない。
Home | 1. Model | 2. Evolution | 3. Task | 4. Operations | A. Concept
要求仕様書 (1-6)
参考文書 (A-D)
判断記録 (a-)