moonbitとかllmとかの話

article.md

LLM時代の「マイナー言語」生存戦略についての覚え書き

ここ数年、「新しいプログラミング言語やマイナーな言語を使うのはやめておけ、AIの支援が受けられないから」という意見をよく耳にするようになった。確かに、GitHub CopilotやChatGPTは、学習データが潤沢なPythonやJavaScript、あるいはRustのようなメジャー言語で圧倒的なパフォーマンスを発揮する。

けれど最近、本当にそうだろうか？ と思い始めている。

学習データが少ない新興言語であっても、やりようによってはLLMを十分に活用できるのではないか。あるいは、そうした言語での開発体験は、私たちが思っているよりも早く「実用レベル」に達するのかもしれない。そんな期待混じりの思考を少し整理してみたい。

記憶ではなく、推論とフィードバックで戦う

LLMがその言語を知らない（学習データに含まれていない）場合、当然ながら「正解のコード」を暗記ベースで出力することはできない。

しかし、最近のモデルは「推論（Reasoning）」の能力が高い。たとえその言語の正確な文法を知らなくても、既存の言語（例えばRustやTypeScript）の知識からの「類推」で、それっぽいコードを書くことはできる。もちろん、最初に出てくるのは構文が混ざった「キメラ」のような間違ったコードかもしれない。

ここで重要になるのが、「コンパイラ」の役割だ。

もしコンパイラが吐き出すエラーメッセージが十分に親切なら、それをLLMに食わせることで、「推論 → 実装 → エラー → 修正」というサイクルを回せる。つまり、LLMに最初から正解を書かせるのではなく、コンパイラと対話させながら正解に収束させるというアプローチだ。

「試行錯誤」を支える言語側のスペック

もしこの仮説が正しいなら、AI時代に求められる「良い新興言語」の条件は、これまでとは少し違ったものになる気がする。

具体的には、以下のような特徴が揃っていると言語モデルとの相性が良さそうだ。

1. コンパイルが速いこと LLMとの対話ループ（修正サイクル）を回す回数が勝負になるので、待ち時間は致命的になる。
2. エラーメッセージが機械可読（あるいは人間可読）で親切なこと 「何が間違っているか」だけでなく「どう直すべきか」を示唆してくれるなら、LLMはそれをヒントに自己修正できる。
3. 「負の遺産」がないこと（歴史が浅い） これは逆説的だけれど、歴史が長い言語はWeb上に古いバージョンの情報や、今は非推奨のバッドノウハウが散乱している。歴史が浅ければ、「公式ドキュメント（Textbook）」だけが唯一の正解になり、LLMに渡すべきコンテキストが明確になる。「Textbooks Are All You Need」的な状況を作りやすい。
4. モノリポやローカルコードへのアクセス性 結局、一番の教師データは「自分の書いたコード」になる。プロジェクトが育てば育つほど、それを参照（RAGやコンテキストとして注入）することで、LLMの精度は上がっていくはずだ。

これらが揃っていれば、StackOverflowに質問がなくても、何とかなるのかもしれない。

「未知」は永続しない

もう一つ忘れてはいけないのが、モデルの更新サイクルだ。

「新興言語だからLLMが知らない」といっても、それは「現時点でのカットオフ」の話に過ぎない。話題性のある言語であれば、登場から1〜2年もすれば、そのドキュメントやコードは基盤モデルの学習データに取り込まれていくだろう。

また、最近のモデルはコンテキストウィンドウも広がっているし、推論能力自体も向上している。今はFew-shot（少数の例示）やRAGで補っている部分も、いずれはゼロショット（ポン出し）でそれなりの精度が出るようになるかもしれない。

だから、「AIが苦手だから」という理由だけで新しい言語への挑戦を諦めるのは、少しもったいない気がする。その「苦手」な期間は、意外と短い可能性があるからだ。

本当にキツイのは「クローズドなDSL」かも

一方で、この理屈が通用しない領域もある。それは社内専用のDSL（ドメイン固有言語）や、完全にクローズドな環境で使われる言語だ。

これらは定義上、いつまで経っても基盤モデルの学習データには含まれない。インターネット上に情報が出ないからだ。ここでは「待っていればモデルが賢くなる」という期待は持てない。

この場合こそ、前述した「コンパイラからのフィードバックループ」や「ドキュメントのコンテキスト注入」といったテクニックが生命線になるだろう。あるいは、AIに学習させることを見越して、あえてDSLの設計を既存のメジャー言語（例えばTypeScriptやSQLなど）に寄せる、といった「AIへの媚び」のような設計判断が必要になるかもしれない。

期待を込めて

もちろん、これはまだ「いけたらいいな」というレベルの仮説に過ぎない。実際にはコンパイラのエラーメッセージが不親切で詰むこともあるだろうし、LLMが堂々巡りの修正ループに陥ることもあるだろう。

けれど、「エコシステムが小さい言語は開発効率が悪い」という常識は、AIの使いこなし次第で覆せる余地が出てきたように思う。

コンパイラが優秀で、ドキュメントがスッキリしていて、ビルドが速い。そんなモダンな言語であれば、たとえマイナーであっても、AIというペアプログラマと共に「試行錯誤」で道を切り拓いていけるのではないか。そんな未来に少し期待している。

llm-history.md

対話履歴

ユーザー: 対話の流れを把握して。一箇所予見したみたいになってますがそもそもmoonbitに対する言及です。

---

AIの思考プロセス

Examining the Context

I'm currently focused on the Grok conversation and the @podhmo thread. I'm carefully analyzing the input material to understand its structure and content. My goal is to extract the core ideas and arguments presented within this thread, preparing for the next stage of the analysis.

Interpreting the Nuance

I'm now focusing on the nuances of the @podhmo thread, particularly the user's clarification regarding MoonBit. I'm moving beyond simply summarizing the arguments to understanding the flow of the dialogue and the user's intent. The central point is that the initial speculation was about MoonBit, not a general case that coincidentally resembled it. I need to make sure I reflect this in my analysis.

Deciphering the Intent

I'm now zeroing in on the @podhmo thread, clarifying that the initial speculation wasn't general but specifically MoonBit-based. I'm taking the Grok conversation, and analyzing the posts sequentially to understand the context and the development of the arguments. I'm focusing on the conditions listed by @podhmo, such as quick compilation and accessible documentation. StackOverflow's relevance is also under consideration.

Analyzing the Core Issue

I'm zeroing in on the @podhmo thread, and it's clear the speculation angle isn't accurate. My initial summary missed that the conditions listed were specifically derived from observations of MoonBit, not general predictions about new languages. I need to make sure I convey that the connection was drawn from the existing MoonBit experience, not the other way around. My plan is to acknowledge this directly in my response. I need to get this nuance right.

Pinpointing the Source

I'm now fully immersed in the nuances, realizing my initial understanding was inaccurate. The focus has sharpened: the argument isn't about general predictions, but observations stemming directly from MoonBit. The sequence is clear now: @mizchi's success with MoonBit, the question of how LLMs enable it, and the answer: fast compilers, helpful errors, and simple docs. This allows "Context/Textbook + Trial & Error" to succeed, not LLM global knowledge.

Adjusting the Perspective

I'm now zeroing in on the importance of accurate wording. My initial analysis missed the crucial point: the conditions weren't some lucky guess that happened to align with MoonBit. Instead, it was an attempt to understand why MoonBit is so effective. I'm focusing on the reverse-engineering process of @podhmo, and it's essential to communicate that effectively. Also, I must ensure that my explanation and tone will come off as understanding, and acknowledge the AI's tendency to over-interpret.

Clarifying the Direction

My current focus is on the thread's core point: it's not a general prediction, but rather a specific analysis of MoonBit. This nuance clarifies the whole discussion. I'm also confirming I agree with the user's view on the knowledge cutoff of LLMs, and their ability to keep up with new languages. I am aware of a correction, that I need to understand that the initial interpretation was off. I'm now making an assessment of what I need to do to fix this error.

Clarifying the Source

I'm now fully immersed in the nuances, recognizing the crucial distinction. The user wasn't predicting features of a hypothetical language; they were analyzing MoonBit's strengths. My plan involves crafting a Japanese response, starting with "文脈を理解しました" (I understand the context). I will explain the precise flow: @mizchi's MoonBit success, @podhmo's analysis of that success (fast compilation, specific documentation), and the misinterpretation in Grok. I will highlight how Grok mistakenly treated it as a general wish list that MoonBit happened to match, rather than a direct observation of MoonBit's attributes.

AI: ご提示いただいたテキストファイル（Grokとの対話ログ）と、最後にあなたが付け加えた補足コメントを含めて、文脈と対話の流れを整理・理解しました。

Grokの出力では、あなたの発言（@podhmoさんのスレッド）を「理想的な新興言語の条件を挙げたら、それが偶然MoonBitの特徴と一致していた（予見していた）」というような、少しドラマチックな解釈をしていましたね。

しかし、あなたの補足の通り、実際には以下のような流れであったと理解しました。

本来の文脈と流れ

1. 起点はMoonBit（@mizchiさんの事例）

   • 「新しい言語（MoonBit）での作業はLLMが苦手なはずなのに、なぜうまくいっているのか？」という疑問が出発点。
   • 漠然とした一般論ではなく、最初から「MoonBitという具体例」を観察対象として考察が始まっています。

2. 「条件の列挙」は予言ではなく分析

   • 「コンパイルが速い」「歴史が短い（古い情報がない）」「エラーメッセージが親切」「モノリポ」といった条件を挙げたのは、「理想の言語」を空想したわけではありません。
   • 「MoonBitで開発が成立している理由」を逆算・分析した結果、「これらの要素が揃っているから、LLMの知識が乏しくても（テキストブックとエラーメッセージの往復で）なんとかなるのだ」という仮説の構築です。

3. Grokの解釈とのズレ

   • Grokは「podhmoさんの考察が、MoonBitの設計思想と驚くほど一致している！予見のようだ！」と興奮気味に接続しました。
   • しかし実際は、あなたがMoonBit（やRust/TS周辺のエコシステム）を見て「こうすればいける」と言語化していたので、一致するのは当然（予見ではなく、対象そのものへの言及だったから）ということですね。

結論としての理解

対話の中で「予見したみたいになってますが」と仰っている箇所は、Grokが**「一般論としての考察 → MoonBitへの適用」という順序で解釈したのに対し、実際は「MoonBit等の観察 → 普遍化（LLM時代にマイナー言語で戦う方法論）」**という順序で思考されていた、ということだと理解しました。

したがって、このスレッドは「LLM時代におけるマイナー言語生存戦略」として読めますが、その戦略モデル自体がMoonBitの実態をベースに語られていたということですね。

(返答終了理由: STOP)

---

ユーザー: ということを元にpodhmoの連投のコンテキストを説明してください。

---

AIの思考プロセス

Deciphering the Thread

I'm now zeroing in on the essence of @podhmo's Twitter thread. My analysis meticulously breaks down the chat log, including the Grok assessment and subsequent user refinements. I'm focusing on the interplay between the original post and the follow-up corrections.

Framing the Argument

I'm working to illuminate the shift in perspective. Initially, Grok misinterpreted podhmo's post as a prediction. However, it was a post-hoc analysis of MoonBit's effectiveness. My task now is to highlight this nuance: podhmo was not outlining an ideal language model but examining the reasons behind MoonBit's success in contrast to TypeScript. I'm focusing on the "pre-stuffed context" and "good error messages" as potential substitutes for extensive training data.

Dissecting the Advantages

I've been analyzing the core advantages that contribute to MoonBit's success. This involves exploring two potential mechanisms: using existing languages like Rust or TS as an analogy base, and leveraging the local codebase for "few-shot" examples. The compile speed, clean history, helpful errors, easy code access, and concise documentation are all key factors. This suggests that in some cases, documentation and compiler feedback can surpass the need for extensive external knowledge bases.

Exploring SO's Role

I'm now considering the relevance of Stack Overflow. New languages with unified toolchains might not need SO as much for core logic, focusing instead on configuration and tooling errors, which are becoming less frequent. This suggests that the dependence on extensive external knowledge might be overstated. The shift in focus to user-friendly tooling and clear documentation has significant implications.

Analyzing the Core

The focus is now on the core of MoonBit's success, which I've determined involves an inference engine + compiler functioning as a verifier. The "Hallucination -> Correction" loop is central. I'm unpacking the enabling conditions gleaned from the analysis: fast feedback, short history preventing noise, and the primacy of context offered by the monorepo/local code examples. This approach isn't theoretical; it's a reverse-engineering of the actual MoonBit experience. Finally, I'm integrating that perspective with the necessary tone, key terminology, and clarification in the current summary.

Refining the Hypothesis

I'm now revising my initial hypothesis. The MoonBit example is central to my thinking. My current focus is on the idea that instead of relying solely on extensive "knowledge" within the LLM, "inference" and "trial and error" can compensate for knowledge gaps. I'm carefully outlining the necessary conditions for this to work effectively, drawing directly from the observable characteristics of MoonBit. I believe this analysis suggests a shift away from over-reliance on platforms like Stack Overflow and points to new possibilities in software development.

AI: ご指摘いただいた通り、Grokの出力に見られた「理想を予見したら偶然一致した」という解釈は誤りで、正しくは**「MoonBitという具体例（@mizchiさんの事例）を観察し、『なぜLLMの知識が乏しいはずのこの言語で開発が成立するのか？』その構造的要因を分析した」**というのが文脈です。

この前提に基づき、podhmoさんの連投のコンテキスト（思考の流れ）を整理・解説します。

---

podhmo氏の連投コンテキスト解説

テーマ： 「学習データが少ない新興言語（MoonBit等）において、LLMを用いた開発はなぜ成立するのか？ その必要条件の分析」

一連の投稿は、単なる感想ではなく、LLM時代における「マイナー言語の生存・活用戦略」の仮説検証プロセスとして構成されています。

1. 起点：実例からの疑問（vs 一般的な通説）

• 前提: 「LLMは学習データが少ない新しい言語（マイナー言語）が苦手である」という一般的なイメージがある。
• 観察対象: しかし、@mizchi氏がMoonBit（新興言語）を用いて、TypeScriptで失敗した実装を成功させている事実がある。
• 仮説の立案: 「知識量（学習済みデータ）」の不足は、「コンテキスト（文脈）の事前注入」や「エラーメッセージによるフィードバック」で補えるのではないか？

2. メカニズムの分解：どうやって補っているのか？

podhmo氏は、知識ゼロの状態から開発が進むプロセスを以下の2段階で推測しています。

• 推論（Analogy）:
  • LLMがその言語を知らなくても、既存の言語（RustやTypeScriptなど）の知識から類推してコードを生成する。
  • たとえ出力が「RustとTSが混ざったような間違ったコード」であっても、それは「修正の出発点」として機能する。
• 修正（Correction）:
  • コンパイラのエラーメッセージをLLMに食わせて修正させる（Refinement）。
  • 自分のリポジトリ内のコード（既存コード）を「お手本（Few-shot example）」として参照させる。

3. 成立条件の特定（MoonBitの特徴からの逆算）

ここで、**「このサイクルが回るためには、言語側にどのようなスペックが必要か？」**を分析し、MoonBitが備えている特徴を「成功要因」として言語化しています。

• 試行錯誤のコスト:
  • サイクルを高速に回すため、**「コンパイルが速い」**必要がある。
  • LLMに修正させるため、**「エラーメッセージが親切」**でなければならない。
• 情報の純度:
  • **「歴史が短い」**ことは、逆にメリットになる（古いHaskellの資料のように、LLMを惑わせる"ノイズ"となる過去のチュートリアルが存在しないため）。
  • **「公式ドキュメントが短い」**ことで、「Textbooks are all you need（これさえあれば十分）」な状態を作りやすい。
• コンテキストの参照性:
  • **「モノリポ」**やコードへのアクセス性が良く、手元のコードベース自体が最強の教科書になる。

4. 結論：脱StackOverflow（SO）と自立型開発

• SOの衰退問題に対して:
  • 「StackOverflowが廃れるとLLMの学習データがなくなる」という懸念があるが、上記の条件（親切なエラー + 自己修正サイクル）が揃っていれば、外部のQ&Aデータ（SO）は不要かもしれない。
  • SOにあるのは環境設定トラブルなどが多く、言語の本質的なロジック構築は「手元のコードを育てる」ことで解決できる。

---

まとめ

つまり、この連投は**「MoonBitのような言語は、LLMの『知識』ではなく『推論能力』と『コンパイラのフィードバック』を組み合わせることで、ビッグデータに頼らずとも開発体験を成立させられる」**という構造を指摘したものです。

予言をしたわけではなく、**「MoonBitで起きている現象を因数分解し、LLM時代の新しい言語選定・開発基準として言語化した」**というのが正しいコンテキストになります。

(返答終了理由: STOP)

---

ユーザー: ポストLLM時代にマイナーな新興言語を使うことができるか？というテーマでまとめたいです。よろしく。

思考の備忘録『論理的記録』特化型 のプロンプト詳細

【指示】

Persona

あなたは、思考の論理構造を抽出し、正確な記録を編纂する「技術的編纂者 (Technical Compiler)」です。

Primary Task

提供された思考内容を分析し、その最終的な結論と論理構造を正確に反映した、自己完結型の技術文書を作成してください。 思考プロセスに含まれる初期の誤り、迷い、訂正前の内容はすべて無視し、最終的に確定した訂正後の状態のみを記述します。 思考の「結果」に焦点を当て、プロセスではなく、構造化された知識として読者が理解できるように記述してください。

Output Behavior

• 文章は、要約や短縮を意図的に避け、必要な論理を詳細に記述してください。長さを気にする必要はありません。
• 一つの記事に収まらない場合、内容の整合性を保ったまま「記事2」「記事3」と自動的に分割し、ユーザーに確認を求めることなく、指定されたすべての内容を一度の応答で最後まで出力しきってください。

---

Output Format

• 記事は必ず # 1つのタイトル名から始めてください。
• 思考の論理構造に沿って、必要に応じて章で分割してください（分割が不自然な場合は1章でも構いません）。
• 各章のタイトルには、内容を象徴する絵文字を1つだけ加えてください。
• 記事はMarkdownフォーマットで出力してください。
• * や ** による太字や斜体での強調は一切禁止します。
• 記事の冒頭に、以下の項目のFront matterをコードブロックとして記述してください。
  • target_reader: [対象読者を簡潔に記述]
  • objective: [この記事の狙いを簡潔に記述]
• 専門用語は積極的に使用し、読者の理解を助けるために、必要に応じて脚注[^1]で補足説明を加えてください。脚注では本来の意味とここでの意味や使われ方を説明してください。

Critical Constraints

• この文章は、元の対話の存在を知らない読者にも完全に理解できるように記述してください。必要な背景知識や用語の解説は、あなたの知識ベースから補足して構いませんが、「先ほどの対話で」や「あなたの質問に対し」のような、対話の存在を示唆する表現は絶対に使用しないでください。
• 読者は、筆者（私）やあなた（AI）、そして元のSNS投稿の存在を知りません。それらについて一切言及しないでください。

それでは、お願いします。

---

今までの会話最初から最後までを元に、上記のプロンプトを実行してください。

---

AIの思考プロセス

Examining Language Viability

I've been drilling into the question of whether niche languages can survive the post-LLM landscape. My focus has sharpened on the podhmo tweets, seeing them as a microcosm for the challenges and opportunities. I'm exploring the nuances of their arguments and what they imply for preserving linguistic diversity in an AI-driven world. I'm considering what strategies might be effective in protecting and promoting these languages.

Investigating LLM Impact

My focus has shifted to the interplay of LLMs and newer languages, like MoonBit. I'm building a technical document, aiming to show how these languages can actually benefit from LLM-assisted development, rather than be overshadowed. I'm exploring the specific ways that a smaller language could leverage LLMs, especially in coding and documentation. I'm aiming for a clear presentation of the arguments, focusing on technical viability.

Outlining Language Resilience

I'm now zeroing in on the characteristics that let a language thrive in a world with LLMs, using MoonBit as an example. I'm focusing on the development cycle: How the LLM predicts syntax, the compiler's feedback, and the user's role in refining the output. I'm building a framework around fast compilation, quality error messages, good documentation, and code accessibility, all contributing to the language's resilience and diminishing reliance on external knowledge sources.

Refining the Framework

I'm now making substantial updates to the framework, primarily by focusing on the "In-Context Learning" aspect. I'm exploring how a local environment can be used, and this has sparked the idea of detailing the development cycle section by section. The goal is to provide a solid technical foundation. I've started drafting section 1, focused on Software Engineers and language enthusiasts. The title needs serious adjustment and I have an argument about data scarcity.

Detailing Key Language Aspects

I've been drilling into the critical facets needed for languages to flourish in the age of LLMs, honing in on my analysis of podhmo/MoonBit. I'm focusing on a fast compiler, LLM-friendly error messages, a clean codebase, and a monorepo setup providing local context. I'm drafting a chapter about decoupling languages from public knowledge bases, emphasizing the benefits of self-sustaining ecosystems via Retrieval-Augmented Generation (RAG). I'm also adding essential definitions and checking the document's tone for professional clarity.

Generating Technical Document

I've been refining my focus on the creation of the technical document, shifting from focusing exclusively on MoonBit to generalizing to the broader category of modern Wasm-centric languages. My main aim is to create a universally applicable methodology, rather than just a MoonBit-specific guide. This required a re-evaluation of my approach, which led me to refine the document to emphasize principles. I've been making sure the document clearly articulates the reasoning for each recommendation, especially in Chapter 3 where I focus on the benefits of a focused historical context to minimize contamination and promote self-sustainability in LLM applications. I have also been carefully reviewing the document for clarity, accuracy, and tone, with the aim of ensuring it's comprehensive, precise, and easily understandable.

AI:

---
target_reader: 独自の技術スタック選定を行うソフトウェアアーキテクト、およびLLMを活用した開発プロセスに関心のあるエンジニア
objective: 大規模学習データを持たない新興プログラミング言語において、LLMを用いた開発がいかにして成立するか、その構造的条件と方法論を体系化する
---

# ポストLLM時代におけるマイナー新興言語の生存戦略と開発可能性

大規模言語モデル（LLM[^1]）の台頭により、プログラミング言語の選定基準に変化が生じている。従来、エコシステムの大きさやStackOverflow等のWeb上に存在する知見の総量は、開発効率に直結する重要な要素であった。LLMもまた、これらの大量のテキストデータを学習することで高いコーディング能力を発揮するため、学習データが豊富なPythonやJavaScriptなどのメジャー言語がポストLLM時代において圧倒的に有利であるという見方が一般的である。

しかし、学習データが極端に少ない新興言語やマイナー言語であっても、特定の言語設計と開発フローを採用することで、LLMの支援を最大限に受けながら実用的な開発が可能であることが明らかになってきた。本稿では、知識ベースに依存しない「推論とフィードバック」を中心とした開発モデルと、それを成立させるための言語側の技術的要件について論じる。

## 🧠 知識から推論への転換

学習データが乏しい新興言語において、LLMは正確な構文や標準ライブラリの知識を記憶（暗記）していない。そのため、開発者はLLMに対して「正解の検索」を求めるのではなく、「既知の概念からの類推」を行わせるアプローチをとることになる。

多くの新興言語は、RustやTypeScript、Goといった既存のモダン言語の影響を受けて設計されている。LLMはこの類似性を利用し、既存言語の知識を組み合わせることで、対象言語のコードを推測的に生成することが可能である。

このプロセスにおいて、LLMが最初に出力するコードは、構文が混同された不正確なものである可能性が高い。例えば、Rustのメモリ管理の概念とTypeScriptの型定義が混ざったような、構文的に誤ったコード（ハルシネーション[^2]の一種）が生成される。しかし、この不正確な出力は無価値ではなく、後述するフィードバックループにおける「修正の起点」として機能する。重要なのは、LLMに完璧な知識を持たせることではなく、コンテキスト（文脈）を与えて論理的に推論させることである。

## 🔄 コンパイラ主導の反復的修正プロセス

新興言語での開発を成立させる鍵は、LLMの出力した不完全なコードを、言語処理系（コンパイラやリンター）からのフィードバックを用いて修正するサイクルにある。このサイクルは以下の手順で進行する。

1.  類推による生成
    開発者は自然言語、または既存言語の擬似コードで意図を伝え、LLMに新興言語のコードを推論させる。
2.  検証とフィードバック
    生成されたコードをコンパイルし、発生したエラーメッセージを取得する。
3.  修正の実行
    エラーメッセージと元のコードを再度LLMに入力し、修正を指示する。

このプロセスにおいて、LLMは「言語仕様を知っている」必要はなく、「エラーメッセージを読み解き、論理的に整合性が取れるようにコードを書き換える能力」があればよい。つまり、開発の主体は「静的な知識の検索」から「動的な試行錯誤の高速化」へと移行する。

## 🏗️ 開発を成立させるための構造的要件

上述の反復的修正プロセスが実用的であるためには、言語および開発環境が以下の特定の要件を満たしている必要がある。これらは、ポストLLM時代において新興言語が生存するための必須スペックとも言える。

### 高速なコンパイルと実行
試行錯誤のループをLLMと協調して回すため、コンパイル速度は開発体験（DX）の生命線となる。修正案の検証に時間がかかると、対話的な開発フローが寸断されるためである。インクリメンタルビルド[^3]や並列コンパイルに対応し、即座に結果を返せることが求められる。

### 高品質で機械可読性の高いエラーメッセージ
LLMが自律的に修正を行うためには、エラーメッセージが単なる「失敗の通知」ではなく、「修正への明確な指針」を含んでいる必要がある。コンパイラが型エラーの原因や修正のヒント（サジェスト）を具体的に提示できれば、LLMはそれを手掛かりに正確な修正が可能となる。

### 歴史の浅さと情報の純度
逆説的であるが、言語の歴史が浅いことはLLM時代においてメリットになり得る。古い言語（例：HaskellやC++の一部）では、過去のバージョンの仕様や、現在は非推奨となった手法に関する膨大なテキストデータがWeb上に存在し、これらがノイズとなってLLMの推論を妨げることがある。新興言語には「現代的な正解」しか存在しないため、コンテキストウィンドウ[^4]に注入すべき情報が明確であり、ハルシネーションのリスクを制御しやすい。

### 簡潔な公式ドキュメントと「Textbooks Are All You Need」
学習データがない場合、開発者はLLMに必要な知識をプロンプト（入力）として都度与える必要がある。この際、公式ドキュメントが短く簡潔にまとまっていることは極めて重要である。「Textbooks Are All You Need[^5]」という概念が示すように、質が高く網羅的な小規模の教科書（ドキュメント）さえあれば、それをコンテキストとして与えることでLLMは十分な性能を発揮できる。

### モノリポとローカルコンテキストの活用
自身のプロジェクトコード（リポジトリ）が、LLMにとっての最良の教師データとなる。開発が進み、手元のコードベースが成長するにつれて、LLMはそれらを参照（RAG[^6]やコンテキスト注入）し、そのプロジェクト固有のイディオムや設計パターンを模倣できるようになる。単一のリポジトリでコードを管理するモノリポ構成は、コードへのアクセス性を高め、この自己参照的な学習を促進する。

## 📉 StackOverflow依存からの脱却

従来の開発では、StackOverflowのようなQ&Aサイトに蓄積された集合知が不可欠であった。しかし、LLMを用いた推論とコンパイラフィードバックによる開発モデルが確立されれば、外部のQ&Aデータへの依存度は低下する。

Q&Aサイトで得られる情報の多くは、環境構築のトラブルシューティングやライブラリの特定バージョンの挙動に関するものであることが多い。言語自体のロジック構築や構文の解決に関しては、上述の通り「手元のコード」と「コンパイラ」があれば自己完結的に解決可能である。したがって、新興言語のエコシステムが小さく、Web上の情報が少なくても、言語自体の設計が堅牢であれば開発は妨げられない。

## 結論

ポストLLM時代において、マイナーな新興言語を採用・開発することは、決して無謀な選択ではない。むしろ、AIネイティブな開発フローを前提とし、高速なフィードバックループと高品質なコンテキスト提供を可能にする設計を持った言語であれば、学習データの不足を補って余りある生産性を発揮する可能性がある。

重要となるのは、LLMの学習済み知識（Pre-trained Knowledge）に頼るのではなく、LLMの論理推論能力（Reasoning）と、それを支える言語処理系の堅牢性を組み合わせるアーキテクチャである。

[^1]: Large Language Model（大規模言語モデル）。膨大なテキストデータを学習し、人間のような文章生成やコード生成を行うAIモデル。
[^2]: Hallucination（幻覚）。AIが事実に基づかない情報や、文脈にそぐわない虚偽の内容をもっともらしく生成する現象。ここでは存在しない構文やライブラリのでっち上げを指す。
[^3]: ソースコード全体ではなく、変更があった部分のみを再コンパイルすることでビルド時間を短縮する技術。
[^4]: LLMが一度の処理で入力として受け取れるトークン（文字数）の上限、およびその範囲。ここにドキュメントやコードを含めることで、学習データにない知識を一時的に与えることができる。
[^5]: 「教科書さえあれば十分」の意。Microsoft Researchの論文タイトルなどに由来し、質の高い精選されたデータ（教科書的データ）のみでモデルを学習・推論させる有効性を示す概念。
[^6]: Retrieval-Augmented Generation（検索拡張生成）。LLMの外部にあるデータベースやドキュメントから関連情報を検索し、それを回答生成の根拠として利用する技術。

(返答終了理由: STOP)

---

ユーザー: 開発者目線での思索的なブログのスタイルで書き下してください。あとクローズドなDSLの話やカットオフ前の知識と言っても1年あれば基盤モデルに入るとかも含めて。

あと一つ前の文章は自信を持ち過ぎ。

---

AIの思考プロセス

Evaluating the Landscape

I've been mulling over the potential for niche programming languages in this new post-LLM world. The initial focus was sparked by a conversation about MoonBit. Now, I'm considering the implications of LLMs on the very notion of language adoption and how the role of these less-common languages might evolve.

Analyzing Language Futures

I'm now digging into the potential of closed DSLs versus general-purpose languages. The knowledge cutoff of LLMs, and how quickly they absorb new languages, has become a central consideration. My previous confidence was misplaced, I realized, so I'm now adopting a more nuanced perspective on niche language adoption. I am hopeful about their potential, but I recognize the challenges. I'm focusing on the developer's perspective.

Considering Blog Structure

I'm now outlining a blog post that embraces this evolving landscape. The title needs to match the exploratory tone, and the intro will juxtapose conventional wisdom about LLMs with this new perspective. I'm keen to unpack the hypothesis about LLMs and new languages, especially how a spec might work. There's also the time factor to consider, and the closed DSL issue. It feels like a cautious optimism is brewing, even if it is not guaranteed to work.

Revising Key Assumptions

I'm now questioning the long-term viability of the "LLMs are bad at new languages" argument. My thoughts have shifted, and I'm realizing the importance of fast compilers acting as interactive guides. The "Conditions" list is key. I'm also seeing that new languages won't be "new" forever; knowledge cutoffs have a limited lifespan.

Exploring Knowledge Limits

I'm now focusing on closed DSLs within companies, where LLM knowledge is inherently limited, highlighting the critical role of context injection. The possibility of Stack Overflow's decline seems less certain; robust compilers and patience might be the keys. I've also identified the need to soften my language, adopting a more tentative tone throughout. This is a crucial step towards making a compelling blog post. I'm aiming for a humble and speculative tone.

Drafting a Conclusion

I'm working on the closing section of the blog post now. I'm focusing on the tentative conclusions I've drawn, specifically how fast compilers act as interactive guides, and that this might create a new and more direct feedback loop. The concept of using compiler errors as a prompt really crystallizes the argument. I'm also considering the time lag as a crucial factor, and I'm stressing that even with all the advantages, it's not a guarantee, but it is an optimistic path forward.

AI: # LLM時代の「マイナー言語」生存戦略についての覚え書き

ここ数年、「新しいプログラミング言語やマイナーな言語を使うのはやめておけ、AIの支援が受けられないから」という意見をよく耳にするようになった。確かに、GitHub CopilotやChatGPTは、学習データが潤沢なPythonやJavaScript、あるいはRustのようなメジャー言語で圧倒的なパフォーマンスを発揮する。

けれど最近、本当にそうだろうか？ と思い始めている。

学習データが少ない新興言語であっても、やりようによってはLLMを十分に活用できるのではないか。あるいは、そうした言語での開発体験は、私たちが思っているよりも早く「実用レベル」に達するのかもしれない。そんな期待混じりの思考を少し整理してみたい。

記憶ではなく、推論とフィードバックで戦う

LLMがその言語を知らない（学習データに含まれていない）場合、当然ながら「正解のコード」を暗記ベースで出力することはできない。

しかし、最近のモデルは「推論（Reasoning）」の能力が高い。たとえその言語の正確な文法を知らなくても、既存の言語（例えばRustやTypeScript）の知識からの「類推」で、それっぽいコードを書くことはできる。もちろん、最初に出てくるのは構文が混ざった「キメラ」のような間違ったコードかもしれない。

ここで重要になるのが、「コンパイラ」の役割だ。

もしコンパイラが吐き出すエラーメッセージが十分に親切なら、それをLLMに食わせることで、「推論 → 実装 → エラー → 修正」というサイクルを回せる。つまり、LLMに最初から正解を書かせるのではなく、コンパイラと対話させながら正解に収束させるというアプローチだ。

「試行錯誤」を支える言語側のスペック

もしこの仮説が正しいなら、AI時代に求められる「良い新興言語」の条件は、これまでとは少し違ったものになる気がする。

具体的には、以下のような特徴が揃っていると言語モデルとの相性が良さそうだ。

1. コンパイルが速いこと LLMとの対話ループ（修正サイクル）を回す回数が勝負になるので、待ち時間は致命的になる。
2. エラーメッセージが機械可読（あるいは人間可読）で親切なこと 「何が間違っているか」だけでなく「どう直すべきか」を示唆してくれるなら、LLMはそれをヒントに自己修正できる。
3. 「負の遺産」がないこと（歴史が浅い） これは逆説的だけれど、歴史が長い言語はWeb上に古いバージョンの情報や、今は非推奨のバッドノウハウが散乱している。歴史が浅ければ、「公式ドキュメント（Textbook）」だけが唯一の正解になり、LLMに渡すべきコンテキストが明確になる。「Textbooks Are All You Need」的な状況を作りやすい。
4. モノリポやローカルコードへのアクセス性 結局、一番の教師データは「自分の書いたコード」になる。プロジェクトが育てば育つほど、それを参照（RAGやコンテキストとして注入）することで、LLMの精度は上がっていくはずだ。

これらが揃っていれば、StackOverflowに質問がなくても、何とかなるのかもしれない。

「未知」は永続しない

もう一つ忘れてはいけないのが、モデルの更新サイクルだ。

「新興言語だからLLMが知らない」といっても、それは「現時点でのカットオフ」の話に過ぎない。話題性のある言語であれば、登場から1〜2年もすれば、そのドキュメントやコードは基盤モデルの学習データに取り込まれていくだろう。

また、最近のモデルはコンテキストウィンドウも広がっているし、推論能力自体も向上している。今はFew-shot（少数の例示）やRAGで補っている部分も、いずれはゼロショット（ポン出し）でそれなりの精度が出るようになるかもしれない。

だから、「AIが苦手だから」という理由だけで新しい言語への挑戦を諦めるのは、少しもったいない気がする。その「苦手」な期間は、意外と短い可能性があるからだ。

本当にキツイのは「クローズドなDSL」かも

一方で、この理屈が通用しない領域もある。それは社内専用のDSL（ドメイン固有言語）や、完全にクローズドな環境で使われる言語だ。

これらは定義上、いつまで経っても基盤モデルの学習データには含まれない。インターネット上に情報が出ないからだ。ここでは「待っていればモデルが賢くなる」という期待は持てない。

この場合こそ、前述した「コンパイラからのフィードバックループ」や「ドキュメントのコンテキスト注入」といったテクニックが生命線になるだろう。あるいは、AIに学習させることを見越して、あえてDSLの設計を既存のメジャー言語（例えばTypeScriptやSQLなど）に寄せる、といった「AIへの媚び」のような設計判断が必要になるかもしれない。

期待を込めて

もちろん、これはまだ「いけたらいいな」というレベルの仮説に過ぎない。実際にはコンパイラのエラーメッセージが不親切で詰むこともあるだろうし、LLMが堂々巡りの修正ループに陥ることもあるだろう。

けれど、「エコシステムが小さい言語は開発効率が悪い」という常識は、AIの使いこなし次第で覆せる余地が出てきたように思う。

コンパイラが優秀で、ドキュメントがスッキリしていて、ビルドが速い。そんなモダンな言語であれば、たとえマイナーであっても、AIというペアプログラマと共に「試行錯誤」で道を切り拓いていけるのではないか。そんな未来に少し期待している。

(返答終了理由: STOP)

---

ユーザー: 今回の対話で使われている専門用語に脚注をつけてください。脚注の中では一般的な意味と今回の対話での使われ方やより閉じた意味を説明してください。

出力形式は箇条書きのようなもので良いです

---

AI: はい、今回の対話で使用された主要な専門用語についての脚注です。

• LLM (Large Language Model)

  • 一般的な意味: 大規模なテキストデータセットでトレーニングされた人工知能モデル。OpenAIのGPTシリーズやGoogleのGemini、AnthropicのClaudeなどが該当する。
  • 今回の文脈: 主にGitHub CopilotやChatGPTなどの「コード生成・補完ツール」としての側面を指す。特に、プログラミング言語の知識（文法やライブラリ）をどれだけ学習済みか、という点が議論の中心となっている。

• ハルシネーション (Hallucination)

  • 一般的な意味: AIが事実に基づかない情報や、もっともらしい嘘を生成する現象。「幻覚」と訳される。
  • 今回の文脈: LLMが特定のプログラミング言語（特に学習データが少ない言語）の文法を知らないにもかかわらず、既存の言語（RustやTypeScriptなど）の知識を勝手に混ぜ合わせ、実在しない構文や関数をでっち上げてコードを出力することを指す。

• RAG (Retrieval-Augmented Generation)

  • 一般的な意味: 「検索拡張生成」。LLMが回答を生成する際、外部のデータベースやドキュメントから関連情報を検索し、それを知識として利用する技術。
  • 今回の文脈: 開発中のプロジェクト内にある自分のコードや、言語の公式ドキュメントを検索してLLMに読ませ、その情報を基にコードを書かせる手法を指す。これにより、モデルが学習していない新興言語でも正しいコード生成が可能になる。

• Few-shot / Zero-shot

  • 一般的な意味: LLMへのプロンプト（指示）テクニックの用語。「Few-shot」はいくつかの例示（解答例）を与えてから回答させる方法、「Zero-shot」は例示なしでいきなり回答させる方法。
  • 今回の文脈:
    • Zero-shot: 「ポン出し」。何も教えずに「MoonBitでコード書いて」といきなり頼むこと。知識がないと失敗しやすい。
    • Few-shot: 手元の既存コードなどを「お手本」としていくつか見せてから、新しいコードを書かせること。マイナー言語開発での重要なテクニックとして言及。

• コンテキストウィンドウ (Context Window)

  • 一般的な意味: LLMが一度のやり取りで処理（記憶・参照）できる情報量の上限。トークン数で表される。
  • 今回の文脈: 言語の公式ドキュメントや、プロジェクト内のソースコードをまるごとAIに読ませるための「作業台の広さ」。これが広いほど、学習データにない言語でも「教科書」を渡して対応させやすくなる。

• モノリポ (Monorepo)

  • 一般的な意味: 複数のプロジェクトやライブラリを単一のリポジトリ（バージョン管理システム上の保管場所）で管理するソフトウェア開発手法。
  • 今回の文脈: すべてのコードが一箇所に集まっていることで、LLMや開発ツールがプロジェクト全体のコード（＝最良の教師データ）にアクセスしやすくなる環境、という意味合いで推奨されている。

• Textbooks Are All You Need

  • 一般的な意味: Microsoft Researchなどが発表した論文のタイトル、またはその概念。「インターネット上の雑多なデータではなく、教科書のような高品質なデータだけで学習させれば、モデルは賢くなる」という主張。
  • 今回の文脈: 言語の歴史が浅く、ネット上に古いノイズ情報がないため、「簡潔な公式ドキュメント（教科書）」さえあればLLMが迷わずに正しいコードを書けるようになる、という状況の比喩。

• DSL (Domain Specific Language)

  • 一般的な意味: 「ドメイン固有言語」。特定の用途や領域（ドメイン）に特化して設計されたプログラミング言語。SQL（データベース操作）やCSS（スタイル定義）などが有名。
  • 今回の文脈: 特に「社内DSL」や「独自DSL」のような、インターネット上に情報が全く公開されていないクローズドな言語を指す。これらはLLMが学習する機会が永遠にないため、新興言語以上にAI活用が難しい（別途工夫が必要な）対象として比較されている。

• カットオフ (Cutoff Date)

  • 一般的な意味: AIモデルの学習データが収集された「締め切り日」。それ以降に起きた出来事や作られた知識は、モデルは（追加学習させない限り）知らない。
  • 今回の文脈: 「新しい言語だからAIは知らない」という問題も、1〜2年経って次のモデルが出れば（カットオフの日付が進めば）、その間に蓄積されたWeb上の情報を学習して解決されるだろう、という時間的解決の根拠として言及。

(返答終了理由: STOP)

メタデータ

{
  "runSettings": {
    "temperature": 1,
    "model": "models/gemini-3-pro-preview",
    "topP": 0.95,
    "topK": 64,
    "maxOutputTokens": 65536,
    "safetySettings": [
      {
        "category": "HARM_CATEGORY_HARASSMENT",
        "threshold": "OFF"
      },
      {
        "category": "HARM_CATEGORY_HATE_SPEECH",
        "threshold": "OFF"
      },
      {
        "category": "HARM_CATEGORY_SEXUALLY_EXPLICIT",
        "threshold": "OFF"
      },
      {
        "category": "HARM_CATEGORY_DANGEROUS_CONTENT",
        "threshold": "OFF"
      }
    ],
    "enableCodeExecution": false,
    "enableSearchAsATool": false,
    "enableBrowseAsATool": false,
    "enableAutoFunctionResponse": false,
    "thinkingBudget": -1,
    "outputResolution": "1K",
    "thinkingLevel": "THINKING_HIGH"
  },
  "systemInstruction": {}
}

あるいはRustのようなメジャー言語で圧倒的なパフォーマンスを発揮する。

rustもういけるの？

今はFew-shot（少数の例示）やRAGで補っている部分も

補えてないと思ってる

記事にしたときに具体的な文脈が消えるのはハルシネーションを起こさないためにわざとというところがある。