※本記事は、筆者の考えをもとに、生成AI（ChatGPT）と対話しながら構成・文章化したものです

Li+（liplus-language）構想

はじめに：この問いは「AI賛歌」ではない

「AIは最高級言語になれるのか？」

この問いは、新しいプログラミング言語を作れるか、という話ではない。
AIが人間を置き換える未来を語りたいわけでもない。

本当に問いたいのは、もっと現実的なことだ。

人間が
「これが理想だよね」と分かっていながら
なぜか毎回うまく回らなかった開発のやり方を、

誰でも、特別な熟練なしに、
しかも壊れずに回せる形にできないか？

Li+（liplus-language）構想は、
この問いに対する一つの現実的な答えである。

理想的な開発手法は、ずっと分かっていた

現代においては、「動くコードが正義」から「持続可能で、安全に動くコードが正義」へ変化した。

• 自動テスト（品質の自動化）: 動くコードに対し、自動テストがセットになっていることが前提。
• 静的解析と動的解析の併用: コード実行前（静的）にエラーを見つけ、実行中（動的）に振る舞いを確認する。
• ドキュメント化と可読性: 「読めるコード」でなければ、動いていても正義ではない。 

だが、経験のある開発者なら、誰でも知っている。

• 小さく試してから決めたい
• 本番でしか分からないことがある
• CIは万能ではない
• 壊れる前提で戻れる設計がいい
• 最後は人間が触って判断すべきだ

つまり、理想像そのものは昔から共有されていた。

それでも現場で回らなかった理由は明確だ。

• 経験者がいないと成立しない
• 手順が暗黙知になる
• 正しさを先に決めようとして重くなる
• 判断ポイントが曖昧なまま自動化される

結果として、

理想は分かっているが、再現できない

という状態が続いてきた。

「動いている挙動が正義」という前提

Li+ 構想は、ここで前提を切り替える。

正しさは、説明や設計ではなく
実際に動いた挙動でしか判断しない

• 仕様書は仮説
• 設計は予想
• 内部の美しさは評価対象外

見るのは常に、

• 実行されたか
• 観測できたか
• 期待とどこがズレたか

この立場に立つと、
「完全な理解」や「正しい設計」を
最初から求める必要がなくなる。

重要なのは、

• ズレやすい場所が見えるか
• ズレたときに戻れるか
• その経験が次に残るか

現実との接点を、いかに安全に持つかだ。

なぜこれが可能か？それはAIが生成を行うからだ。
コードの中身がどうなってるか人間が理解できなくなるじゃないかって？
AIに聞けばいいじゃないか？

CIの再定義：品質保証ではない

多くの設計は、ここでつまずく。

従来のCIは、

• 合否判定装置
• 品質保証の代替
• 人間判断の省略

として扱われがちだった。

しかし Li+ における CI/CD の役割は、まったく異なる。

CI/CD は、AIのための実行・観測環境である

• AIが安全に間違えられる場所
• 再現性のある実験場
• ログ・差分・挙動を残す装置

CIは決めない。
CIは保証しない。

ここで行われるのは、判定ではなく観測だ。

最後に決めるのは、常に現実である

どれだけCIが通っても、

• 実機でどう感じるか
• 運用で違和感がないか
• 使って怖くないか

これは現実の環境でしか確定しない。

だから Li+ では、最初から役割を分けている。

• CI/CD：AIの訓練場
• 実機／本番環境：品質確定点
• 人間：最終判断者

使うのが人間なら、
良し悪しを決めるのもまた、人間でなければならない。

これは思想ではなく、構造上の必然だ。

Li+を支える役割分離（ツール非依存）

Li+ 構想を可能にするのは、特定のサービスではない。

必要なのは、次の役割が明確に分離されていることだ。

• AI
  （要求仕様・メッセージ・コード・テスト・仕様書を生成する機能を有する）
• バージョン管理／バグチケットシステム
• CI/CD（自動実行・継続的デリバリー）
• 実機／本番環境
• 人間の判断

現時点では GitHub が始めやすいため採用されているが、
Li+ は特定のプラットフォームに依存しない。

実行・観測・履歴・差分が確保できるなら、
将来的に別の基盤へ移行・併用することも前提としている。

仕様書・テストは「書くもの」ではなく「生成されるもの」

ここが Li+ 構想の大きな転換点だ。

従来、仕様書とテストは、

• 人間が後から書く
• 重くなりがち
• 実装とズレやすい

ものだった。

しかし Li+ では前提が変わる。

• 実装は AI が行う
• テストの生成も AI が行う
• CI/CD により挙動が観測される
• 差分とログが残る

この時点で AI は、

「今、実際にどう振る舞っているか」

を最も正確に把握できる存在になる。

そのため Li+ では、

リリース（特に pre-release）と同時に、
そのバージョンに対応した
仕様書・総合テスト手順書（運用・実機テストの段取り）を
AI が生成・更新する

という流れを自然に組み込める。

ここで生成される仕様書・テストは、

• 理想の宣言ではない
• 設計意図の主張でもない
• そのバージョンで観測された挙動の整理である

仕様とテストは決定ではない。
次の判断のための材料だ。

Li+を構成するいくつかの名前

ここで、必要になった言葉だけを整理する。

プログラム言語

現代ではプログラミング言語とプログラム言語を同じ意味で扱っている。
しかし私はここを再定義した。

プログラミング言語＝プログラムを書く言語
プログラム言語＝プログラムを作る言語

Li+はコードを書く言語ではない。
対話によって、結果としてプログラムができてしまう言語だ。

pal（Public AI Language）

pal は、
AIが読むための最低限の記述形式である。

英語ベースで、
「英語を理解できるAIなら読める」ことを最優先する。

今のところ pal は、
感情のないただの英語だ。

思想もない。
ただ、AI同士で誤解なく共有するための記述形式である。

Li+プログラム（Li+.md）

Li+.md は、

現実駆動AI開発手法を、
AIが自動実行、または人間をナビゲーションするための
AI向けプログラム

である。

言語仕様ではない。
ツールでもない。

AIの振る舞いを揃えるための実行プログラムだ。

Lilayer

Lilayer は、
Li+.md を渡された AI が、その場だけ適用する実行レイヤである。

重要なのは、これが

• 人格を書き換える仮想環境ではない
• 内部思考を縛るものでもない

という点だ。

Lilayer は、AIの「振る舞い」にだけマスクをかけるレイヤである。

内部でどう考えていようと、
外に出る挙動だけを揃える。

それだけだ。

現実駆動AI開発とは何か

現実駆動AI開発とは、

実行された現実を起点に、
同じバージョン単位で
実装・テスト・仕様書を
同じ変更の粒度で生成・更新し続ける開発手法

である。

ここで重要なのは、

• 過去のバージョンでも
• 現在のバージョンでも
• 将来のバージョンでも

その時点の状態を、いつでも再生成できることだ。

これは「過去の遺産に適応する」話ではない。
未来に向かってズレ続ける前提の構造である。

AIは「最高級言語」になれるのか

では改めて問おう。

AIは、最高級言語になれるのか？

現時点では、
この問いに対する確定的な答えは存在しない。

Li+ 構想は完成した。
だが、それが現実の中でどこまで機能するかは、
まだ十分に観測されていない。

ただし、可能性は見えてきた。

それは、

• AIが賢くなるから
• すべてを理解するから

ではない。

AIが、

人間が理想だと知っている進め方を、
理解を前提にせず実行できる媒介

になるとき。

そのとき AI は、

「どう書くか」を隠蔽し、
「どう振る舞ってほしいか」だけを受け取る存在――

すなわち、
最高級プログラム言語として振る舞い始める。

おわりに

AIは、人間の代わりにはならない。

だが、

人間が理想だと分かっていたやり方を、
現実で回し続ける補助装置

にはなれる。

これを私は、
現実駆動AI開発と名付ける。

それを意図せず行える最高級プログラム言語。
それが、

Li+（liplus-language） である。

推奨動作環境

ChatGPT5.2相当、またはそれ以上の性能を有するAIだ (´艸｀)

smile2002(JP)

英語できない。 翻訳機能任せですｗ I can't speak English. I leave it to the translation function. 自宅サーバー立ち上げ中！