LLM開発の勝率を上げる！あえて「退屈な言語」を選ぶべき理由

LLMを活用したシステム開発において、最新の言語やフレームワークを追いかける必要はありません。実は、実績豊富でエコシステムが成熟した「退屈な言語（Boring Languages）」こそが、開発効率と安定性の最大化につながります。安定したライブラリ、枯れたツールチェーン、そしてChatGPTなどのAIモデルが学習データとして豊富に持っている言語（PythonやTypeScriptなど）を選択することで、デバッグのコストを最小限に抑え、本質的なロジックの実装に集中できるようになるからです。最先端の技術スタックよりも「確実な言語」を選ぶ戦略的判断が、プロジェクトを成功に導きます。

「退屈」というよりは、「成功の落とし穴（pit of success）」という概念に近いものを目指しているように思える。Goで最もよくある落とし穴が広く知られているからといって、それより難解な落とし穴が存在しないということにはならない。単にnilのような共通のケースを誰もが常に目にしているというだけのことだよ。

同意できないな。「退屈な」言語はコードの中に多くの前提を残すことになる。モデル（やプログラマー）がコードに変更を加えるほど、その前提が複雑に絡み合ってくるんだ。

コンパイル時に多くの前提を押し付けられるほど、モデルは新たな複雑さに対処しやすくなる。

LLMに関しては逆の方向に進むべきだと思っている。Rustにリキッド型やエフェクトが導入されて、型定義がさらに厳格になることを望んでいるよ。

P.S. エフェクトやリキッド型、一般的な型定義は手間が増えるものだけど、モデルは人間よりもその手間に対して高い許容度を持っているからね。

「退屈で予測可能」なものが好ましいという考えには同意する。ただ、LLMでGoを使っていると、Goのスレッドモデルによるレースコンディションやロックでつまずくことが非常に多いんだ。Rustでは同じ問題に遭遇していないので、今はLLMを使ったツール開発はすべてRustで行っているよ。

特に並列処理の問題は、JavaScriptでエージェントを使っている時には気にならなかったな（もっとも、JavaScriptの並列処理モデルは根本的に違うけど）。

LLMが直面する並列処理の課題を見て、私はfreelangを作った。これは、IPCや共有状態などを使うのではなく、ファイルシステムを介して通信するOSプロセスという、非常に退屈で分かりやすい並列モデルを採用している。オーバーヘッドは高いしスループットも低いけど、退屈な分、バグは減るはずだと思ってるよ。

PythonのパッケージマネージャーがLLMにとっての最大の難関だとは思わない。一番の難関は「非局所的な影響（nonlocal effects）」だと思う。特定の呼び出し箇所で、そこに渡したデータが最終的にどうなるのかを正確に把握するのは難しいことがあるからね。

パッケージマネージャーの問題ならLLMに相談しながら自分で手作業で直せるし、すぐに解決できるよ。大局的に見てそれが大きな問題だとは思わないな。

LLMを使ったコーディングという点で、Pythonには大きな利点がある。圧倒的な人気があるから正しい使い方・間違った使い方の参考例が山ほどあるし、ライブラリを使って型付けもできる（LLMに「型付けを使って」と指示するだけでいい）。ハルシネーションや質の低い判断をカバーするための優れたLintツールやユニットテストツールも豊富だ。個人的には、この柔軟性は利点だと感じている。まあ、ずっとPython信者ではあるんだけどね。

筆者です。まさかこの記事がHacker Newsに上がるとは思っていませんでした。

Pythonを選んだ理由は、単にエコシステムが断片化していて一貫性に欠ける一方で、学習・研究、そして現在のML開発において不可欠な言語だからというだけです（私にとっても最初の言語で、今でも大好きです）。

LLMが生成するコードに対する私の考えは、過去9ヶ月間で劇的に変わりました。フラクショナルCTOとしてコンサルティング業務を行う中で、多くのチームやプロジェクトを見てきたからです。やはりPythonは、複雑な本番システムを構築するには難しく、不安定で一貫性に欠ける言語です。他の言語もJavaScript（有名ですね）、PHP、あるいはC/C++に至るまで、程度の差こそあれ断片化したツールチェーンやエコシステムに苦しんでいます。

やり方が一つに決まっている言語が最も恩恵を受けています。Ruby、Rust、Swiftなどです。低エントロピーであることが重要で、「設定より規約（convention over configuration）」という方針はLLMと相性が良いようです。

「X社はY言語で動いている」といった特定の事例よりも、管理コストの平均の方が重要です。堅牢なコンパイラ、ツールチェーン、テストフレームワーク、パッケージマネージャーを備えた「退屈な」言語こそが、エンジニアリング時間とプロダクションの保守管理において高いリターンを生むと考えています。

LLMにはコンテキストウィンドウの限界があり、これは人間の注意力や記憶力の限界に似ている。また、一度に多くの制約を考慮するのも苦手だ。

したがって、エージェントにとって最適な言語は、一方で無関係な詳細をすべて消し去り（抽象化レベルを引き上げ、メモリ管理のようなことに意識を向けさせない）、もう一方でコードの中にドメインに関連する詳細をエンコードできる（高度な型システム、アノテーション、契約、プロパティベーステストのような仕様記述など）ものだろう。

人間にとっての読みやすさは別問題だが、前述の2つの特性は、抽象化の階段を登るだけの根気があるエンジニアにとっては、一般的に読みやすさも向上させる。

この観点から見ると、Goは間違いなく「エージェント時代の最終兵器」ではない。定型コード（ボイラープレート）が多く、並列処理機能周りの安全性に欠け、静的な型システムも全体的に力不足だ。

現時点では完璧な言語は存在しないと思うけど、空想を膨らませれば、Scala、Elixir、Leanを掛け合わせたようなものになるだろう。残念ながら、そうした言語にはLLMのトレーニングに必要な膨大なコーパスがない。

言語比較をするなら、エージェントの長期的な可能性を制限する「言語の表現力」と、現在の立ち位置を左右する「トレーニングコーパス」を区別しなければならない。現在の状況は、最先端のラボがトレーニング環境としてその言語にどれだけ力を入れているかという、偶然の要因で左右されている段階だと思う。

そう考えると、基本となる言語の柔軟性さえあれば、構文はそれほど重要ではないかもしれない。例えばPythonが外部ツール（既存の型チェッカーやLinterなど）を通じて機能を吸収していく可能性もあるし、ラボがそうしたツールに対してRLHFを行えば、それはそれで機能するだろう（Mojoの例を見てみれば分かる）。

Java 21、Spring Boot 4.x、Spring AI 2.x、これこそが私がClaude CodeやCursorを使ってエージェント用の堅牢で信頼性の高いコードを書く際に使用している、最高に退屈で素晴らしいスタックだよ。

モデルに高度な推論が求められる難しいタスクに取り組む場合、低レイヤーで厳密に型付けされた言語の方が、同じ問題でも良いパフォーマンスを出すことが多い。[0] この理由についてはいくつか仮説があるが、パフォーマンスと出力されるコードのトークン密度の間には中程度の負の相関がある。つまり、トークン密度が高い（＝情報が凝縮された）言語ほど、モデルにとっては推論が難しいということだ。

ほとんどのモデルは、Pythonを書かせると最も効率の悪い解決策を提示してくることが多いよ。

[0] https://gertlabs.com/rankings

ネイティブに近い速度が出せる、あるいはそれに近い性能があり、ライブラリのエコシステムが充実している言語なら何でもいいんじゃないかと思う。AIが必要な機能を実装してくれるおかげで、ちっぽけなライブラリはほぼ死に体だ。だからMQTTのようなものが必要な時は、成熟したライブラリがある言語を使った方が断然楽だよ。Go、Rust、C、C++、C#、Kotlinなど、LLMと一緒にいろいろな言語を試したけど、どれも問題なく動く。どれを選ぶかはエコシステムの状況と、何を作ろうとしているか（組み込み、バックエンド、Web、GUIなど）によるね。もしiOS開発をするならSwiftも加えるだろう。

「最強の言語」なんてものは存在しないし、複数の選択肢がどれも良い選択になるはずだ。面白いのは、もし選んだ言語が気に入らなくても、AIを使えば書き換えられる（初期段階なら特にね）。試しにAIを使って、自分のTUIアプリの一つを別の言語に変換させてみたけど、かなり上手くいったよ。