なぜ、「LLM AI専用のプログラミング言語を作ったらいいのでは？」という誤解をする人が多いのか？

はじめに

近年、大規模言語モデル（LLM: Large Language Model）がプログラミング支援において強力な力を発揮するようになり、AIによる自動コード生成やリファクタリングが一般化してきました。その一方で、「AI専用のプログラミング言語を新しく作るべきではないか」という主張を耳にすることもあります。しかし、こうした考え方は多分に誤解に基づいており、現実のエコシステムやAIの仕組みを踏まえると妥当性を欠いています。本稿では、なぜそのような誤解が生まれるのかを、技術的・心理的・歴史的な観点から整理し、LLMとプログラミング言語の関係を俯瞰的に論じます。

「AIは新しい計算パラダイム」という誤解

誤解の第一の源泉は、「AIはこれまでのCPUやGPUと並ぶ新しい計算資源である」という錯覚にあります。歴史的に、新しい計算対象が登場すると専用言語が作られてきました。データベースにはSQL、並列計算にはCUDA、WebにはJavaScriptといった具合です。その流れに従えば「AIにも専用言語が必要ではないか」と考える人が出るのは自然なことです。

しかし、LLMは新しい計算パラダイムではありません。あくまで確率的にテキストを生成するモデルであり、既存の計算資源（GPU上の行列演算）を用いて動作するにすぎません。専用言語を作ったところで行列計算そのものが変わるわけではなく、既存の高水準言語とライブラリの枠組みのほうが合理的です。

データ駆動型モデルへの理解不足

LLMの得意・不得意は「学習素材の多さ」と「目的の一意性」に依存します。英語や中国語、PythonやJavaScriptのように大量のデータが存在する領域ではLLMは高い性能を示します。一方、低リソース言語や未開拓の領域では不得意になります。そのため「AI専用言語」を新しく作っても、学習素材が存在しなければ得意になる理由はありません。

また、将棋や囲碁のように「勝敗」という明確な報酬が存在する分野ではRL（強化学習）のみで学習可能ですが、自然言語やソフトウェア開発は評価基準が曖昧でRL単独では成立しません。そのため、人間によるフィードバック（HF）やRLHFが必須となります。結局、AIの得意分野は「人間が既に得意で、大量のアウトプットを残してきた分野」と重なるのであり、専用言語の創出が得手を広げることにはつながらないのです。

曖昧さを消したいという願望

人間がLLMに指示を与える際、自然言語の曖昧さゆえに結果が不安定になることがあります。そこで「専用言語を設計して曖昧さを排除すれば、AIがもっと正確に動作するのではないか」と考える人が出ます。これは一見もっともらしいですが、実際には誤解です。

曖昧さの解消は、専用言語を作ることではなく、人間がロジカルシンキングを通じて自然言語を整理することで達成できます。プロンプト作成は単なるテキスト入力ではなく、前提・論点・制約・期待する出力を論理的に順序立てて書く行為です。AI専用言語に逃げるのではなく、論理的な記述力を磨くことこそが本質的な解決策なのです。

「新しい言語」に惹かれる文化的背景

プログラマ文化には、「新しい言語を作れば世界を救える」という幻想が周期的に現れます。過去にはLISPやPrologといったAI志向言語も登場し、それらが一定のインパクトを与えた歴史もあります。そのため「AIといえば専用言語」という思い込みが根強く残っているのです。

しかし現代のLLMは、そうした言語設計の系譜とは異なる文脈で進化してきました。LLMの強みは自然言語と高水準コードを大量に学習している点にあり、既存の言語資産を活かすほうが圧倒的に有利です。文化的なノスタルジーが専用言語待望論を生み出しているにすぎず、技術的合理性は乏しいのです。

低レベル言語と「人間の意図からの距離」

もう一つの誤解は、「AIに低レベルなコードを書かせれば精密で便利だろう」という発想です。しかし、抽象度の低い言語ほど人間の意図から遠くなり、指示と生成物の間に齟齬が生じやすくなります。アセンブリやCはCPUに近いですが、人間の要求（アルゴリズムや業務要件）とは乖離しています。LLMにそれを直接書かせるのは非合理であり、むしろエラーを増やすことになります。

現実的には、「人間の言語 → 高水準言語 → 低水準コード」という多段変換が最適です。LLMが担うべきは人間の意図と高水準コードの橋渡しであり、低水準の変換はコンパイラや専用エンジンに任せるのが理にかなっています。

ツールチェインの重要性

実際のAIプログラミングはLLM単体で完結するものではありません。むしろ以下のような後段ツールチェインが本質的に重要です。

• Thinkingエンジン：結果を検証し、再度LLMにフィードバックを与えるループ
• Webスクレイパーや検索：GitHubやStack Overflowから実例を取得
• ビルド＆実行エンジン：コードを試しに走らせ、エラーや出力を返す

これらが連携することで初めて「人間が実際に開発しているような反復的プロセス」に近づきます。専用言語を作るのではなく、自然言語と既存の言語を通じてツール群を連携させる仕組みの方が圧倒的に効果的です。

自然言語とロジカルシンキングの役割

結局のところ、LLMにとっての「最適な言語」は人間の自然言語です。大量の学習データが存在し、人間にとっても直感的に書け、さらにAIにとっても学習済みで解釈しやすいからです。ここで重要なのは、自然言語を雑に書くのではなく、ロジカルシンキングを通じて論理的に整理することです。

プロンプトエンジニアリングとは、専用言語を設計することではなく、人間の思考を論理的に翻訳して自然言語に落とす訓練にほかなりません。AI時代においてロジカルライティングが一層重要になるのはこのためです。

まとめ

「LLM専用プログラミング言語を作るべきだ」という発想は、多くの誤解と願望に支えられています。AIを新しい計算資源と錯覚する誤解、データ駆動型モデルの性質を理解していない誤解、曖昧さを専用言語で取り除けると信じる誤解、新しい言語に惹かれる文化的ノスタルジー、低レベル言語に精密さを期待する誤解、そしてツールチェインの存在を軽視する誤解です。

実際には、LLMは人間の自然言語と高水準言語との間をつなぐ役割こそが本質であり、低水準領域は既存のコンパイラやツールが担うべきです。AI専用言語を作る必要はなく、むしろ自然言語を論理的に扱う能力こそが重要になります。

この視点に立つと、「LLM専用言語待望論」は時代錯誤的である一方で、人間側の論理的記述力の重要性を再発見させてくれる契機とも言えます。AI時代における真の課題は新言語の設計ではなく、人間とAIの間に横たわる「思考と言語の翻訳」をいかに磨くかにあるのです。