過去1年間、私たちは皆、魔法のような「1つのプロンプトから任意のアプリを構築する」というデモを見てきました。ランディングページや汎用の足場としては素晴らしいものです。しかし、もし巨大で複雑なビジネスシステムを反復的に構築・維持するようLLMに依頼したことがあるなら、その現実を知っています：コンテキストウィンドウがいっぱいになり、AIが誤ったアーキテクチャを幻視し、リポジトリが手に負えないスパゲッティコードに変わる。
ReactとJavaの膨大なファイルをエージェントに書き直させ続けるのにはうんざりしていたので、別の道を選びました。
私は、フルスタックのビジネスシステムを生成するために明示的に設計されたオープンソースのAIネイティブDSLファミリであるLojを構築しました。
中核の賭け: AIの焦点を絞る
LLMsは狭く安定した、スキーマ検証済みのドメイン言語を扱うのが非常に得意ですが、長期間にわたって50,000行にも及ぶ命令型UI状態とバックエンドのボイラープレートを管理するのは悪名高く不得意です。
AIに大規模なフレームワークのコードベースを直接操作させる代わりに、Lojはより小さく、構造化されたセマンティック表面を提供します。あなた（またはあなたのAIエージェント）は、.web.loj、.api.loj、.rules.loj のような極めて密度の高いファイルを用いてビジネスの意図を書きます。
そして、私たちの決定論的コンパイラがその狭い意図を標準的で実運用に耐えるフレームワークコードへ展開します。現時点では、1つのLojプロジェクトが以下を生成できます：
- フロントエンド: React / TypeScript
- バックエンド: Spring Boot (Java) または FastAPI (Python)
現実世界のエッジケースを100%網羅するDSLはないことを私たちは知っているので、Lojは明示的なエスケープハッチを採用しています。“もう二度とコードを書かない”と装う代わりに、手書きのコードをはるか小さく、よりクリアなエッジへ押し出し、コンパイラがそれをきれいに結線します。
消え去る橋: フルスタック・ワークフローの原子性
従来のスタックで「チケット承認」フローを実装すると、通常は同じロジックを4か所に書くことになります：
-
バックエンド:
if status == 'PENDING' && role == 'ADMIN'を確認するインターセプター。 - フロントエンド: 「承認」ボタンの表示/非表示を条件付きでレンダリングします。
-
API: 専用の
/approveエンドポイント定義。 - 状態管理: 呼び出し後にリストを手動で更新したり、リダイレクトしたりします。
Lojでは、その「橋となる」コードは単純に消えます。
あなたはtransition: approve を.flow.lojに単一定義します。Lojのコンパイラは見えない織機のように機能し、可視性ロジックをあなたのReactコンポーネントへ、セキュリティインターセプターをSpringまたはFastAPIのコントローラへ同時に注入します。
エンジニアには、最初はこれはほぼ“直感に反する”と感じられるかもしれません。なぜなら私たちは手動のif文を探す訓練を受けているからです。しかし、ビジネスロジックの原子性を受け入れると、.flow.lojは実質的に「フルスタック憲法」であることが分かります。
もし憲法が遷移を許すなら、UIボタンからデータベースへの書き込みまで、全てのスタックが無条件に従います。それは、UIがアクションを許可してもバックエンドが403を返す、古典的で苛立たしいバグのカテゴリーを排除します。
なぜ単なる別のAIアプリビルダーを使わないのか？
現在のAIツールの多くは、視覚的なウェブサイトか生のコード操作向けに最適化されています。それは便利ですが、私が解決すべき問題ではありませんでした。
私は、予約プラットフォーム、購買トラッカー、内部承認ワークフロー、顧客ポータルなどの、重厚なビジネス系システムを重視しています。これらのシステムは「創造的なUI」が必要だから難しいわけではなく、構造化されたドメインモデル、厳格な適格性ルール、画面間およびバックエンド状態間の複雑な引き渡しに大きく依存しているから難しいのです。
LojでフォームやAPIエンドポイントを定義すると、意図は密度を保ちます。運用時のバグが発生した場合、曖昧で生成された不透明な Blob を修正することはありません。バグを予測可能な .loj ソースや、明示的なネイティブエスケープハッチに辿ります。これによりAI生成へのトレーサビリティが戻ってきます。
フライト予約の概念実証
これが玩具に過ぎないことを証明するため、現在のリポジトリにおける標準的な例はフルスタックのフライト予約システムです。検索フロー、メンバー履歴、選択に基づく引渡し、複雑なリードモデルを含みます。
DSLが実際に役割を果たしているかを知るため、私は「意味的エスケープ」を数理的に追跡します。現在の予約検証では、フロントエンドとバックエンドの意味的エスケープの総和は概ね1%です。
つまり、約1,390行のLoj DSLが概ね11,000〜13,000行の生成済みReactとSpring Bootコードへ展開され、モックデータと特注配線のためのネイティブ手書きのエスケープコードは極めてわずかです。
Lojは何に長けていて、何に長けていないか
これは過大評価したくありません。Lojは非常に意見がはっきりしたツールです。
特に優れているのは:
- バックオフィスの管理パネル
- ワークフロー重視の CRUD＋システム
- フロントエンドとバックエンドの連携が難解な、ルール主導のトランザクション型アプリ
向いていないもの:
- ブランド力が高く、視覚的に特注のマーケティングサイト
- 深く対話的な3D/Canvasアプリ
- 高度にカスタムなリアルタイムコラボレーションツール（Figmaクローンのようなもの）
実際に試してみる（AIに作業を任せる）
AIエージェントを構築するか、Windsurf/Cursor のようなツールを使っている場合、loj-authoring スキルバンドルをインストールできます。これにより、あなたのLLMにDSLの書き方を正確に教えます。構文ハイライト付きのβ版VSCode拡張機能も利用可能です。
CLIをインストール:
npm install -g @loj-lang/cli
loj --help
# Or without global install: npx @loj-lang/cli --help
AIオーサリングスキルのインストール（Codex/Agents用）:
npx @loj-lang/cli agent add codex --from https://github.com/juliusrl/loj/releases/download/v0.5.0/loj-authoring-0.5.0.tgz
コードを確認:
リポジトリは github.com/juliusrl/loj に公開されています。
ちょっと覗いてみてください。アーキテクチャについてのご意見をお聞かせください:
- 「DSLファースト」アプローチは、長期的なAI生成の管理においてより堅牢に感じますか？
- 直接的なAIリファクタリングよりも明示的なエスケープハッチを好みますか？
コメントで教えてください！
