LLMファースト言語の最前線
AIが「書きやすい」を設計から作る言語たち

前回の記事で「PythonはLLMが最も得意、C/Rustは苦手」という実測を示した。では、最初からLLMが書くことを前提に設計された言語はどうなるか。Magpie・Aria・MoonBitという「LLMファースト言語」の設計思想と、訓練データ不在という最大の壁を整理する。

結論から: LLMファースト言語は実在し、2025年頃から複数登場している。設計思想は「曖昧さゼロの構文」「トークン効率」「即時フィードバック」「機械可読な仕様の埋め込み」の4点に収斂する。ただし訓練データが存在しないため現状のLLMは素では書けず、言語仕様をプロンプトに注入する運用が前提。実用はまだ先だが、「検証しやすさを言語レベルで設計する」という思想は既存言語の運用にも即応用できる。

1. 背景 — 言語によってLLMの成功率が20-30pt違う

前回の記事(C言語をLLMに書かせるベストプラクティス)で示した通り、同一LLMでも言語による成功率の差は大きい:

この差の原因は「訓練データ量」「型システム」「動くコードと正しいコードの距離」の3つ。ならばこれらを言語設計で最適化すれば、LLMの成功率を底上げできるはず — それがLLMファースト言語の発想。

2. 主要なLLMファースト言語

Magpie — 「AIエージェントのための最初の言語」

magpie-lang.com。「曖昧さを排除し、LLMが一発で完璧なコードを書ける」ことを目標に掲げる。ネイティブ速度・即時フィードバック・推測不要の設計。

Aria — トークン効率を極限まで削る

aria-lang.com。「生成コスト90%削減」を謳い、全ての構文決定がトークン最小化で決められている。ボイラープレートを言語機能で排除し、コンテキストウィンドウの消費を抑える。

MoonBit — WebAssembly × AIフレンドリー

moonbitlang.com。Wasm向け言語で、「AIへのコンテキスト提供のしやすさ」を設計思想に明記。構造化されたコードでスケールしやすく、AIが扱う単純なコンテキストで済むことを重視。

3. 設計思想の共通点 — 4つの原則

osada.blog「The Rise of LLM-First Languages」(2025-08)は、この波の背景として幻覚した依存関係・ロジックエラー・テストのごまかし・コンテキスト制限というLLMコード生成の4つの課題が言語設計の駆動力になっていると指摘している。

4. 最大の壁 — 訓練データが存在しない

ここが皮肉な部分。LLMの言語得手の最大要因は訓練データ量だが、新言語にはそれがゼロに近い。対策として現状は:

• 言語仕様をシステムプロンプトに丸ごと注入 — 小さな言語だからこそ可能(これ自体がトークン効率設計の副産物)
• コンパイラをループに組み込む — 生成→コンパイルエラー→自己修正。エラーメッセージの質がそのまま学習信号になる
• 既存言語へのトランスパイル — 実行基盤を既存エコシステムに依存し、ライブラリ不在を補う

5. 既存言語の運用に応用できること

LLMファースト言語が実用化されるのを待たなくても、その設計原則は今日の開発に転用できる:

1. 型を最大限書く — TS strict・Python type hints・Go interface。型はAIへの構造化コンテキスト
2. 書き方を1つに統一する — リンタ/フォーマッタで流派を潰すとAIの出力のブレが減る
3. ボイラープレートを減らす — スキーマからコード生成し、AIに書かせる面積を小さく
4. 検証を即時化する — コンパイル・テスト・サニタイザをエージェントループに組み込み、エラーを自己修正に使う

6. まとめ

LLMがコードを書く時代の言語選択は、「人間が書きやすいか」から「AIが正確に書けて、機械が即検証できるか」へ軸が移りつつある。新言語の成否はともかく、この設計圧力自体が既存言語の進化方向(より強い型・より良いエラー)を決めていくだろう。