プロジェクトごとの「自然文な開発言語」を作る

発端

プロジェクトの特有の開発の文脈がある。
通常、これらは開発の設計書に落とし込んでいる。
しかし、Coding Agent は設計書の全てを理解することはできない。

そこで全てを理解することなく、言語や法則のように、一定の圧縮された情報から、重要なコンテキストを呼び出すことができたら良いのではないかと考えた。

具体的なイメージ

例えば、開発言語においてデータベースを操作するSQLと、情報を表示するMarkup言語と、アプリケーションを動作させる軽量なスクリプト言語とに分かれている。
通信のプロトコルも、1種の言語だとすると、この約束事を決めれば良いことになる。

この約束事を通して、プロジェクト専用の言語体系を作ることができたら良いのではないか。

プロジェクトにおける文脈とは

「データベースエラーが発生したため、調査をしてほしい」これは指示であり、かつ、プロジェクトの仕様を前提としている。プロジェクトに関与している人にだけ通じる前提や情報があるかもしれない。

これをプロジェクトの文脈だとしよう。

表現方法

仕様を説明するパターン：
「データベースエラーが発生したため、調査をしてほしい。データベースはPostgreSQLを利用しており、採用しているフレームワークはRuby on Railsである。」

仕様の在処を示すパターン：
「データベースエラーが発生したため、調査をしてほしい。仕様書 db.md に詳細の記載がある。」

こうした指示表現の工夫を、各自が実施しているのではないか。

しかし、どれほど工夫を凝らしても、
システムの大きさや複雑性に応じて、伝えるべき情報量は指数関数的に増えてしまう。LLMがコンテキスト量を拡大しても、文脈を取り出す効率の良さは必要だろう。

プロジェクトの開発言語の作り方（案）

圧縮→還元する

LLMは圧縮なので、要は圧縮すればいい。
つまり極限まで、言語定義を短縮化し、そこから得られる意図を理解すればよい。

たとえば

E=mc^2

が圧縮された状態であるとき、詳細情報はない。ところが、この式を理解できる状態にあるなら、詳細な説明へと還元できる。

ドメイン駆動設計のユビキタス言語から

平たく理解すると、要はビジネスにとって重要な言葉を定義すると、各所で共通し使えるということであろう。

ユビキタス言語からアイデアを借りて、
開発プロジェクト内に共通の言語体系を、開発言語として扱うことができれば良いと考える。

言語例

"research test code", "search client model", "build weekly price" と言ったら、何をすればいいのか？この構文は何か？得られる結果はどんなものか？

この圧縮された 3 words から、意味を理解できる情報を引き出せればよい。これを還元とする。

この 3words の羅列をプロジェクトに合わせて用意すれば、プロジェクトの開発に必要な文脈で、言語定義ができるのではないだろうか。

やってみる

Sub Agentsにも最適。Claude Codeから動的にプロンプト実行する CLI Prompt 管理ツール - Climptで、Climpt について書いた。
Climpt = CLI + Prompt 。

これによって、例えば

build weekly price --uv-date=2025-08-02 としたら、build weekly price を 2025-08-02 で実施するとわかる。
build weekly price なので、build daily price や、build monthly price もありそうだ。

つなげてみる

build weekly price. test db price. 
find recent price. make latest report.

結構、圧縮された。

このセンテンスは、プロジェクトのコンテキストでしか意味を持たない。プロジェクト外の人には、何をするのかイメージできないだろう。しかし、プロジェクトに関与する人の範囲では、明確な意図を持った指示となりえる。

プロシージャー型？

この順序を事前定義すると、手続き型になる。
しかし、この用語定義を使って、agent 側に判断を委ねると、

build weekly price. test db price.
retry last build.

という指示へ、変えてくれるかもしれない。

ありそう

用法まで定義することが叶えば、開発言語になりそうである。
AI出力コードを収束させる方法： ドメイン駆動設計 & 全域性 & テスト駆動 & Claude Code Company
で書いたのは「境界線」と「中心」の話だが、言語はプロセスを手がけられる可能性が高い。

ここにエントロピー増大と引力を加える（別次元の話で、説明は省略）ことで、結構いけるのではないか、という気がしてきた。