DSLはLLMの信頼性の高い使用を可能にする

DSLはLLMの信頼性の高い使用を可能にする LLMはコードを信じられないほど速く生成しますが、意図したとおりに生成されることを保証するには、明確な境界が必要です。抽象化とドメイン固有言語（DSL）は、LLMを最初から正しく導く強力なハーネスを提供します。分散システム動作を説明するためのドメインモデルとDSLであるTickloomの例は、LLMをDSLを反復的に構築するパートナーとして、またそれを使用するための自然言語インターフェースとしてどのように使用できるかを示しています。このようなDSLは、LLMの世界におけるソフトウェアシステムの主要な真実の情報源として機能します。 14 7月 2026 Unmesh Joshi Unmeshは、インドのプネを拠点とするThoughtworksのDistinguished Engineerです。彼はPatterns of Distributed Systemsの著者です。 目次 アップフロント仕様の限界 実装を通じて発見されるデザイン ドメイン抽象化とDSL なぜDSLはLLMとうまく機能するのか 例: LLMを使用して図が豊富なPowerPointプレゼンテーションを生成する セマンティックモデルの構築 例: Tickloom — 分散システムのためのセマンティックモデル たとえ良い抽象化でも役立つ — DSLなしで 例: 分散システムシナリオのテストのためのDSLの構築 LLMとの2つのフェーズ DSLとしての真実の情報源 最新のLLMは信じられないほどの能力を持っています。それらは、高レベルの自然言語の説明から、大量のコード、時にはシステム全体を生成できます。ここでの重要な仮定は、構築する必要があるものの「意図」が、LLMがコーディングのビルディングブロックにマッピングできる正確な言葉を使用して、明確に表現されているということです。しかし、注目すべき重要な点が2つあります。アップフロント仕様の限界、そしてデザインがいかに実装を通じて発見されるかです。 アップフロント仕様の限界 大規模システムの構築には、非常に多くの小さな設計上の決定が含まれます。これらはすべて事前に知られているわけではなく、高レベルの仕様から完全に駆動されるわけではありません。仕様はせいぜい最初の仮説です。実際の制約、トレードオフ、およびエッジケースは、実装を進めるにつれて反復的に発見されます。私たちは以前の記事でこれを詳細に議論しました。そこではそれをアップフロント仕様の不可能性と呼びました。ポイントは、仕様が無価値だということではなく、最初の仕様は改訂されるべき仮説であり、完成した設計図ではないということです。自然な応答は反復することです。仕様を洗練し、コードを生成し、返されたものをレビューし、学んだことを次のラウンドにフィードします。各ラウンドが小さくレビュー可能な変更を生成する場合、そのループはうまく機能します。 実装を通じて発見されるデザイン コードのレビュー、特にデザインをまだ発見している間は、コードを書くこととは異なります。生成されたコードをレビューしている間、私たちはチャンクをレビューし、それが私たちの意図にマッピングされているかを確認し、潜在的な落とし穴を探します。しかし、レビューがデザイン上の決定と格闘することを強制することはめったにありません。対照的に、コードを書くことは、責任がどこに属するか、またはデザインを拡張するためにどの境界を公開すべきかといった具体的な決定を徹底的に考えさせることを強制します。デザインが最も完全に明らかになるのは、それらの決定を下すことです。私たちがコーディングするプログラミング言語とパラダイムは、私たちが得るデザインの洞察を形作ります。関数型デザインアプローチまたはオブジェクト指向デザインアプローチは、パラダイムに自然なイディオムやパターンとともに、デザインの異なる側面を明らかにします。 では、LLMはどこに収まるのでしょうか？私はLLMが2つの役割を果たすと見ています。それらは、デザインとその語彙を形成する際に非常に役立ち、デザインスペースを探索し、適切な抽象化を発見するのを助けるブレインストーミングパートナーとして機能します。語彙が確立されると、LLMはそれに対する優れた自然言語インターフェースとして機能します。 ドメイン抽象化とDSL これをフレーム化する有用な方法は、ドメイン駆動設計（DDD）を通してです。その中心的な洞察は、ドメインの共有概念モデルをコードで構築し、そのモデル（DDDがユビキタス言語と呼ぶもの）を使用してコードベースを進化させ、チームに思考とコミュニケーションのための語彙を与えることです。多くの場合、そのモデルの上にドメイン固有言語（DSL）を構築することは非常に効果的です。それは、ドメインの概念と操作を表現するための制約された構文です。このように見ると、ほとんどの開発はドメインモデルを構築し、それを使用してシステムを進化させるプロセスです。LLMは、ドメインモデルが既に存在するかどうかに応じて、2つの異なる役割を果たします。この記事では、ドメイン固有言語（DSL）がLLMとどのように機能するかを中心に説明します。 なぜDSLはLLMとうまく機能するのか DSLがLLMとうまく機能することは一般的な経験です。PlantUML、Mermaid、Graphvizは視覚モデリングのためのドメイン固有言語です。SQLはデータベースをクエリするためのDSLです。Kubernetes YAMLはクラウドインフラストラクチャを記述するためのDSLです。これらは汎用プログラミング言語ではありません。それらは意図的に制約されており、1つのドメインで狭い範囲の概念を表現するように設計されています。そして、LLMがプレーンな英語の説明からMermaid図、SQLクエリ、またはKubernetesマニフェストを生成するのに驚くほど優れていることは驚くことではありません。私の観察では、DSLはLLMがコンテキスト内のいくつかの例によく応答するため、LLMをより信頼性の高いものにします。Javaのような汎用言語は、同じ意図を表現するための多くの有効な方法を提供します。DSLはバリエーションを排除します。モデルにいくつかの例を与えることは、正しい構文を確実に生成するのに十分です。最前線のモデルは、トレーニング中にPlantUMLやJavaの流暢なインターフェースに既に大きくさらされているため、ゼロから始まっているわけではないことに注意する価値があります。真に新しいDSLをタスクとする、より小さく、より制約されたモデルがどのようにパフォーマンスを発揮するかを見るのは興味深いでしょう。 エージェント（単一ショット生成ではなく、自律的な生成とチェックのループで実行されるLLM）の場合、さらに利点があります。DSLはほぼ常に決定論的なバリデーター（パーサー、JSONスキーマ、型チェッカー、またはコンパイラ）を同梱しています。エージェントは候補を生成し、バリデーターを実行し、エラーから修復することができます。すべて人間の介入なしに。決定的に、エラーはドメインのレベルで表現されます。「クライアントを選択する前にアクションを選択することはできません」—生成されたコードの奥深くに埋め込まれたスタックトレースではなく。DSLのツールセット自体が優れたハーネスとして機能します。以下のTickloomの例で具体的に見ますが、DSLの文法はホスト言語のコンパイラによって強制され、結果の実行は自動的にチェックされます。これは万能の解決策ではないことに注意することが重要です。DSLが小さく制約されたままで、コンテキスト内のいくつかの例で使用法を伝えることができる限り、この利点は持続します。また、言語とそのセマンティックモデルの設計と保守には、実際の初期コストがかかります。したがって、ペイオフは、バリデーターによってバックアップされた、適切にファクタリングされた、真に制約されたDSLに集中します。 例: LLMを使用して図が豊富なPowerPointプレゼンテーションを生成する LLMはカスタムツールを構築することを非常に簡単にします。分散システムを教える際、クラスター内の分散操作を説明する図を主に含むプレゼンテーションを頻繁に作成する必要があります。UMLシーケンス図はそれに役立ちましたが、クラスターを通過するメッセージフローを示しながら完全なシーケンス図を表示することはあまり役立ちませんでした。PowerPointプレゼンテーションでステップバイステップでシーケンス図を表示するツールが必要でした。LLMの助けを借りて、プレゼンテーション構造を記述したYAMLを処理し、PlantUML図への参照を含み、PowerPointプレゼンテーションを生成するツールを構築することができました。PlantUML図はステップでマークされており、ツールは各ステップに個別のスライドを生成します。これにより、図が豊富なプレゼンテーションを簡単に作成できました。 3つのノードathens、byzantium、cyreneのクラスターを示すPlantUMLシーケンス図を生成します。クラスターをマークするためにボックスを配置します。アクターAliceがメッセージ「title」、「After Dawn」をathensに送信します。Athensは自分自身にメッセージを送信します。状態「title: After Dawn」を示す注釈を配置します。Athensはbyzantiumにメッセージを送信しますが、失敗します。Athensはcyreneに送信します。注釈を配置します。