エージェントをコーディングするための最適なプログラミング言語は何ですか？

2026年8月11日原文(danluu.com)

概要

LLMにおける動的型付け言語と静的型付け言語のトークン効率比較の議論
トークン効率が高いとされる言語の主張の妥当性検証
実験設計や評価の妥当性に対する批判的考察
複数のタスクや条件での評価結果の多様性
一般化できる強い結論は得にくいというまとめ

LLMにおける動的型付け言語と静的型付け言語のトークン効率比較

動的型付け言語 や 記述が簡潔な言語 は、LLM利用時に トークン効率が高い という主張の拡散
代表的な引用例として、 ClojureやJ は CやC++ より 2.6倍～半分以下のトークン数 で同等の処理が可能という指摘
Google AI も「動的型付け言語は型宣言が不要なため、トークンコストが低い」と要約
ただし、 比較対象の問題が極めて単純 （Rosetta Codeなどの短い課題）であり、現実的な問題設定とは乖離

評価実験の課題と限界

単純な問題 では「動的型付け言語が有利」という傾向が出るが、 複雑な課題 になるとその差は縮小または逆転
評価設計の問題点 として
- テストケースの実行パス誤りやエージェントの挙動バグ
- シンボリックリンクによる不適切な実行パス共有
- 評価結果が設計者の意図通りにならない 事例の多発
大規模かつ多様なタスクでの検証 が必要不可欠

実際の大規模タスクでの追加検証（zstd・Pandoc）

zstd RFC を元にした完全デコーダ実装タスクや Pandoc ProgramBench のTDD的評価
- 中規模・大規模課題 では「動的型付け vs 静的型付け」の明確な優劣は見られず
- 主流言語 ほど正確かつコスト効率が高い傾向
- アセンブリやマイナー言語 は明確に不利
- JやClojure など「密度が高い」言語の優位性も限定的

一般化できる結論の難しさ

「動的型付け言語はLLMに有利」という主張は 一部の単純なケースでのみ部分的に成立
現実的な開発タスクや運用コスト まで含めると、 静的型付け言語が有利なケース も多い
言語の人気度 と LLMでのパフォーマンス には弱～中程度の正の相関
LLM利用に最適な言語やアーキテクチャ に関する公的データは依然不足
2014年の研究でも「静的型付け vs 動的型付け」の有意な差は限定的とされており、 決定的な証拠は乏しい

まとめ

LLMのトークン効率や実装効率は、言語の型付け方式や記述密度だけで決まらない
評価方法やタスク内容の違い で結果が大きく変動
主流でサポートが厚い言語 を選択するのが現時点では現実的な選択肢
「この言語がLLMに最適」という断定的主張には慎重な検証が必要
今後も多様なタスク・設計での継続的な検証が求められる

Hackerたちの意見

関連: どのプログラミング言語が最もトークン効率が良いのか？ - https://news.ycombinator.com/item?id=46582728 - 2026年1月（91件のコメント）

└

この分野は進化が早いけど、6ヶ月以上前の情報ってまだ relevan なの？FableとOpus 5がその後リリースされたし、それに対応するOpenAIのモデルも出てるよね。

既存の有名なソフトウェアを再現することが、この種の評価にどれだけ役立つのかはよくわからないな。LLMがトレーニングコーパスからデータをどれだけ効果的に取得して、異なる設定（ここではプログラミング言語）でスタイルを転送できるかを考えると、そう思う。これが、この記事での異なる言語間での能力の収束を説明しているのかもしれない。もっと人々の実際の体験に興味があるな。

└

PythonでAIハーネスを書こうとしたけど、明らかにそれが正しい選択だと思った。ライブラリがたくさんあるし、モデルAPIと話すためのライブラリ、コンテキストや会話管理のためのライブラリ、MCPと話すためのライブラリもある。LLMには最適な言語だ！でも、全然うまくいかなくて、クラッシュしないコードを書くのが無理だった。自信満々だったのに、バグだらけ。UIにはインタラクティブさ、割り込み、例外処理が必要なのに、今まで見た中で最悪のコードが生成された。ライブラリのコードも、今まで見た中で最悪だった。RustとTauriに切り替えたら、3人分の作業で分岐する会話や、内蔵のgrep機能を使ったツールがあるUIができた。Claude Code（CLIやデスクトップ）よりも生産的だよ。

LLMがGleam[1]やLustre[2]を書くのがこんなに上手いとは驚いた。主流の言語と比べると、トレーニングデータにはほとんどGleamのコードがない。証拠はないけど、人間にとって良い言語[3]はLLMにも良いと思う。コンパイル済み、強い型付け、静的型付け、不変、純粋関数、パターンマッチ、メモリ安全など。 [1] https://gleam.run [2] https://lustre.hexdocs.pm [3] 「人間にとって良い言語」の特徴については議論が多いのはわかってるけど、これはあくまで私の好みのリストだよ。

└

ここでそんな意見が出るとは思わなかった。Gleamに関してはほとんどのLLMがひどいと思ってる。だから、Gleamのコードベースで作業する時は、インラインオートコンプリートを無効にすることが多い。トレーニングデータの大きな溝に引き込まれて、TypeScriptやRustみたいな人気のある言語の存在しない言語機能（if文、ループ、構文構造）を挿入しようとすることが多すぎる。LLMにGleamを書かせると、他の言語が部分的に置き換わることはないの？

└

Gleamは2年以上安定してるから、LLMがドキュメントを内面化するには十分な時間が経ったかも。特に画期的なアイデアは含まれてない言語[1]（IMOでは「use」が一番近い）だから、LLMが他の関数型言語のパターンを再利用できる可能性はあるね。 [1] これは批判じゃないよ。Gleamがこうなったのが好きなんだ。

└

数年間言語を開発してきたけど、不完全な意味論とシンプルな1ページの例でも、LLMはあまり苦労せずに書けるみたい。言語や構文が影響を与えると思うけど、その周りのツールがLLMには最も重要だと思う。人間にとっても同じようにね。

└

以前はこの意見を持ってたけど、サーバーでRust、クライアントでTypeScriptに切り替えてから、エージェントはRustの方がずっと得意だって自信を持って言えるよ。特にイディオマティックなコードを生成するのが得意だね。GleamやLustreには好きな理由があるけど（Gleamは特に好き）、LLMにはそれが当てはまらない。Rustに切り替えたのは今年の5月頃だよ。それに、コミュニティは超反AI的で、ある意味では理由があると思う（オープンソースに与える影響とか）。だから、AIコードは自分だけのものにしておくことをおすすめするよ。

└

もっとニッチな言語について言うと、Rocは新しい構文で使えるようになったのが約2ヶ月前だよ（まだコンパイラがクラッシュすることがあるけど、実際のリリースがない理由はそこにある）。でも、Opusは言語の特異性に対処するためにいくつかの修正を加えた後、ちゃんと書けてるよ。

「平均してたった70トークン、Clojureのほぼ半分（109トークン）」って言ってるソースはあまり信頼できないな。「ほぼ半分」なんて言う必要ないし、半分からかなり離れてる時にそれを付け加える理由もないと思う。でも本題に戻ると、GoはLLMにとって素晴らしい選択だと思う。ほとんどのことに対してやり方が一つしかないし、利用可能なトレーニングデータもかなり一貫してる。Pythonとは全然違って、トレーニングデータは非ソフトウェアエンジニアが書いたコードで汚染されてる（と思う）し、同じことをするのにいろんなやり方がある。Goの大きなプラスはツールだね。コンパイルが早くて、良いリンティングがあれば、反復サイクルが短くなって、LLMに間違いを修正するように指示する必要が減る。なぜか、私が使ったほとんどのLLMはPythonを書きたがる。特別な理由がない限り、Goを使うように何度も教えなきゃいけない。個人的にはClojureを見たり使ったりしたいけど、Goほどの利点はないと思うし、特に簡単な単一バイナリ配布ができるのが大きいよね。

└

Goもエージェントと一緒にやるの好きだけど、>「これはPythonとは全然違う。Pythonではトレーニングデータが、ソフトウェアエンジニアじゃない人が書いたコードで汚染されてる（と思う）し、同じことをするのにいろんなやり方があるから。」反例として、Django関連のエージェントがあるけど、素晴らしい出力が得られるよね。

Hacker Newsで議論の続きを見る

ハクソク