ハクソク

世界を動かす技術を、日本語で。

LLMはDSL設計者にとって興味深い課題を提起する

2025年6月18日原文(kirancodes.me)

概要

  • LLM時代 におけるプログラミング言語設計の課題と変化
  • DSL（ドメイン特化言語） の意義とLLMによる影響
  • Pythonなどの一般言語 でのLLM性能の高さとDSLへの影響
  • LLMとDSLが 共存・協調 するための新たな設計方向性
  • 今後の 言語設計の発展と課題 の整理

LLM時代のプログラミング言語設計：平凡への回帰か？

  • Programming Language（PL） Design の魅力は、特定ドメインに合わせた 直感的なインターフェース の提供にあり
  • DSLによる 高レベルな記述 で、冗長なAPI呼び出しを排除し、 バグや認知負荷の低減 を実現
  • 「正しさの保証」 を言語自体で担保する設計思想
  • しかし、 LLMの台頭 で「なぜDSLを作る必要があるのか？」という疑問が生じている現状
  • LLMの普及により、 DSL設計の意義や将来性 が再考される状況

LLMの課題：Pythonで全てが簡単になる時代

  • LLMの学習データ はPythonやJavaScriptなど一般的な言語に偏重
  • 研究によると、 低リソース言語やニッチなDSL ではLLMの性能が著しく低下
  • DSLを使う場合、 LLMによるコード生成の恩恵を受けにくい という問題
  • DSL設計の コスト増大 と、利用者がLLMの利便性を失うリスク
  • 今後、 DSL開発の停滞や障壁の増加 が懸念

言語設計の新たな方向性：LLMとDSLの共存

  • LLM時代における 言語設計の進化 を模索する必要性
  • 以下の3つの方向性が有望

1. Pythonを介したLLMへのDSL知識伝達

  • DSLの 構文や意味論 は既存言語と大きく異なるため、LLMが理解しにくい
  • 研究例：「 Verified Code Transpilation with LLMs」では、LLMにまず Pythonで記述 させ、後でDSLに変換する手法
  • Pythonを 中間言語 として活用し、DSL向けコード生成の精度向上
  • DSL設計フレームワークに LLMフレンドリーなPython記述 を自動生成・検証する仕組みの提案
  • DSL実装からPython表現を自動抽出 し、LLM活用を容易にする可能性

2. LLMによるインフォーマルとフォーマルの橋渡し

  • LLMは「 スクリプト生成」など、非定型的な作業で特に有用
  • 例：ユーザーが 高レベルな仕様 を自然言語で指示し、LLMが「つなぎコード」を生成
  • フォーマル（厳密なコード）とインフォーマル（自然言語指示）の ハイブリッドな開発フロー
  • DSLにおいても、 自然言語による仕様記述と連携 できる設計が求められる
  • DSLの型・解析情報から 自然言語仕様を自動生成 するアプローチの可能性

3. 検証可能なLLM合成のための言語設計

  • LLMによるコード生成を 検証言語 （例：Dafny, Boogie等）で保証する研究が活発化
  • LLMが生成したコードの 正しさを検証 するための 仕様記述言語の設計
  • LLMと検証技術の 連携による信頼性向上
  • 仕様記述とコード生成を 統合的に扱う新しいDSL設計 の可能性

今後の展望と課題

  • LLMの発展とともに、 言語設計の役割や価値 が問われる時代
  • DSLの意義 を再定義し、LLMと 協調可能な設計手法 の模索が不可欠
  • LLMの得意領域とDSLの強みを 補完し合うアプローチ の重要性
  • 開発者・研究者間の議論とフィードバック を通じた、言語設計の新たな展開への期待

Hackerたちの意見

最近、ロボットフレームワークのDSLを使うことになったんだけど、あんまり好きじゃないな。ビジネスユーザーにとって、命令型コードよりも読みやすいとは思えないし。どのDSLも新しいAPIを覚えなきゃいけないし、だいたいは落とし穴だらけだよね。直感的な使いやすさは見る人によるって感じ。俺がやりたいのは、命令型コードを自然言語でテスト内容を説明する形に変換して、エイリアスとかの設定を加えることかな。

└

DSLって一様じゃないよね。MiniZincを考えてみて。これはすごくクールで、制約解決問題を書くのに役立つし、いろんなバックエンドソルバーで実行できるんだ。中間言語やバイトコード（LLVM自体も含めて）は、よく定義されたプリミティブを使って低レベルの操作を表現するための便利なDSLだよ。コード生成DSLも特定のアプリケーションには素晴らしいし、特にカスタムボイラープレートを作るのに役立つ。シナリオに特有のことをDSLで書いて、テンプレートベースのコード生成が提供されたデータを使ってターゲット言語のコードを生成するっていうのは、すごく柔軟なアプローチだね。これは言語指向プログラミング（LOP）のいくつかのタイプのうちの一つに過ぎない。

└

DSL（ドメイン特化言語）全般には懐疑的じゃないけど、ロボットフレームワークについては同意するよ。HTMLの出力フォーマットは結構いいと思うけど、テストケースのタグの使い方には不満があるし、非トリビアルなものを書くのはイライラする。Pythonの拡張を書くのは簡単だから、結局「ビジネスロジック」以外のロジックはほとんどPythonで書いちゃった。一般的にはそうするべきなんだろうけど、その時点で全部Pythonか好きな言語で書いた方が良さそうだね。

もっと多くの人がこの話をしてるのを見るのはいいね。6ヶ月前にこれについて書いたんだけど、LLMの使い方が多くの人を古いプログラミング言語やフレームワーク、基本的なデザインに戻らせてるのに気づいたんだ。正直、これは必ずしも悪いことじゃないと思うけど、新しいDSLやフレームワークに対して抑圧的な影響があるのは確かだね。これは解決不可能な問題じゃないと思うけど、特に今は人気のあるコーディングエージェントがカスタムドキュメントコンテキストを持つMCPサポートを提供してるからね。でも、LLMにはトレーニングデータが一番多いランタイムやフレームワークにユーザーを引き寄せる強い力が常にあると思う。

└

それは素晴らしいブログ記事だし、非常に興味深いポイントだね。うん、LLMが既存の言語のフレームワークにどう影響するか考えてなかったけど、既存のものを強化して革新を抑える似たような効果があるのは納得できる。DSLのこの影響を解決するのはフレームワークよりも少し難しいかもしれないと思う。なぜなら、DSLは意味が全然違ったりするから（例えば、Prologのような論理プログラミングDSLと、Haskellのような関数型DSLを想像してみて）。だから、MCPの枠組みにうまくはまらないかもね。でも、解決不可能ではないと思うし、もっと研究が必要だね。

└

今日、これに関するいい投稿を見たよ…

└

言語学や言語の歴史に詳しい人たちへ：印刷機が普及するにつれて、話し言葉の進化が遅くなる現象が観察されてるって知ってる？それと、「国際英語」って、似たような現象の観察なのかな？

└

スカイネットはCで動くよ。

└

自動翻訳ツールがこれを緩和する手助けになるかもしれないと思う。もしかしたら、PythonやJavaなどから新しい言語に翻訳するための別のニューラルネットワークを訓練するのもありかもね。

└

健全だと思うよ。だって、高度な抽象化の塔を作ることに対抗する流れを生むからね。それが大きな問題なんだ。スタックが深くなって、より「スイスアーミーナイフ」みたいな言語を作ることになる。そうすると、私たちにとっては便利だけど、他の誰かが後で世代ごとの「溶岩層」を解読しなきゃいけなくなる。市場のトレンドが変わって、新しいものが古いものに取って代わるときにね。新しいやり方としては、スイスアーミーナイフの代わりに使い捨てのジグを作ることだ。LLMを使えば、DSLとして十分に機能するプロンプトを与えて、プレースホルダーコードを立ち上げられる。そこにシニア開発者のタッチが必要な重要な要素を補えばいい。結果的にコードは原始的に見えるし、原始的な動作をするけど、最初は多くの不一致を生む。でも、長期的にはメンテナンスには問題ないよ。原始的なコードは抽象コードに「収穫」しやすいけど、その逆は簡単じゃないからね。

└

新しいフレームワークだけじゃなくて、新しい機能もあるからね。例えば、iOS 26の機能を使ったコードを書くためにLLMを使うのは難しいと思う。単にLLMに機能についてのドキュメントを注入させるだけじゃうまくいかないんじゃないかな（誰かがこれを研究したかもしれないけど）。彼らが「よく知られた」ことを上手にやれるのは、実際の例がたくさんトレーニングされているからなんだよね。

└

これ、Coders at Workの第13章、フラン・アレンの抜粋を思い出すな。セイベル: 最後にプログラミングしたのはいつだと思う？ アレン: ああ、かなり前だね。Cが出たときにやめちゃったんだ。それが大きな打撃だった。最適化や変換でかなりいい進展があったのに、次々と素敵な問題を解決していってたんだ。Cが出たとき、SIGPLANのコンパイラ会議で、Cを支持するベル研究所のスティーブ・ジョンソンと、当時自動最適化のプロジェクトに取り組んでいたビル・ハリソンの間で議論があったんだ。その議論の核心は、プログラマーが最適化を気にしなくてもよくなるというスティーブの主張だった。Cのデザインの動機は、高水準言語では解決できなかった三つの問題だったんだ。一つは割り込み処理、もう一つはリソースのスケジューリング、そして三つ目はメモリの割り当て。高水準言語ではそれができなかったから、Cの言い訳になったんだ。セイベル: Cをオペレーティングシステムのカーネルに限定して使うのは合理的だと思う？ アレン: ああ、それはいいと思うよ。実際、専門家が大きなボトルネックなしに微調整できる何かが必要だからね。それが解決すべき重要な問題なんだ。1960年には、リスプ、APL、フォートラン、COBOL、Algol 60といった素晴らしい言語がたくさんあった。これらはCよりも高水準なんだ。Cが発展してから、私たちは本当に後退してしまった。Cは自動最適化や自動並列化、高水準言語を機械にマッピングする能力を奪ってしまった。これが、コンパイラが大学であまり教えられなくなった理由の一つだよ。

Hacker Newsで議論の続きを見る