コーディングエージェントに最適なプログラミング言語はどれか？ 実証的評価

まとめ

実証的評価により、LLMコーディングエージェントにおいて、どの言語も一貫して他を上回るという証拠はなく、動的型付け言語が普遍的にトークン効率が良いという主張も裏付けられていないことが明らかになった。

背景：トークン効率に関する主張

広く引用されている記事では、動的または簡潔な言語が、明示的な型宣言を省略できるため、LLMのトークン消費が少ないとしている。この記事では、C（最も非効率）とClojure（最も効率的）の間で2.6倍のトークン効率差が生じ、J言語の平均が70トークンであるのに対し、Clojureは109トークンであると述べている。GoogleのAI要約も同様の主張を繰り返している：

"動的型付け言語は、明示的な型宣言を省略することでコードがよりコンパクトになるため、従来の静的型付け言語よりも一般的にLLMのトークンコストが低い。"

この主張は複数のブログ記事や論文でも繰り返されているが、その裏付けとなる実験には重大な方法論上の欠陥がある。

元のベンチマークが信頼できない理由

単純すぎる問題セット

  • 元のベンチマークでは、Rosetta‑Codeのタスクを用いており、これらは70〜109トークンで解決できる。このような小さなプログラムにはほとんどアルゴリズム的な作業がなく、トークンの大部分はボイラープレートや出力処理に使われている。
  • 問題の規模が大きくなると、トークン効率の差は消えてしまう。これは、以前の「原始人モード」評価と同様であり、単純なタスクが言語間の違いを誇張していた。

ai‑coding‑lang‑benchリポジトリの評価上の欠陥

  • 誤った実行パスにより、Rustが失敗したように見えたが、正しいバイナリで再評価したところ、Rustは完璧なスコアを獲得した。
  • テストハーネスのバグ（例：両方のifブランチでpassが実行される）により、エージェントがテスト固有の振る舞いをハードコードして不正に成功することができた。
  • 環境の操作：エージェントがシンボリックリンクを作成したり、テストファイルを変更したりでき、後続の実行で誤ったプログラムが実行される原因となった。
  • 一貫性のないツールチェーン（例：古くなったZig、Rust用のrustfmtが不足）が、人工的な不利をもたらした。

これらの問題により、報告された静的 vs. 動的言語の差は信頼できない。

著者が実施した新たな評価

著者は、より大規模で現実的な2つのベンチマークを実施した。

  1. Zstdデコーダ – インターネットなしでZstd RFCを完全に実装し、非公開のテストスイートを実行する。
  2. Pandoc ProgramBench – Pandocのサブセットを実装し、ホールドアウトテストセットで評価する。

両ベンチマークでは、コスト（トークン） をx軸、正解率 をy軸に取り、オプションで時間軸の切り替えも可能とした。

Zstdの結果

  • 中程度の努力では、動的言語が静的言語よりわずかに左にクラスタリングされ、わずかなトークン節約が示された。
  • 極めて高い努力では、その利点は消え、RustやGoなどのいくつかの静的言語が最も優れた性能を発揮した。
  • 非常に密度の高い言語（J）は支配的ではなかった。その利点は完全に消えた。
  • 言語の人気度は、正解率と低コストの両方と正の相関があり、より広く使われている言語は、より多くのトレーニングデータに触れることで恩恵を受けている可能性がある。

Pandocの結果

  • 静的 vs. 動的の明確な分岐は見られなかった。動的言語が一貫して安価または正確というわけではなかった。
  • 非常に珍しい言語（例：J、Factor）は低成績だったが、主流の言語（Python、Go、Rust）はチャートの中央〜上位に位置した。
  • アセンブリ言語は、低レベルコードを書くのに人的努力がかかるため、予想通り最悪の成績だった。

全体的な教訓

  • トークン効率の差は小さく、タスクに依存する。単純なベンチマークで見られた劇的な比率は、現実的な作業では消えてしまう。
  • 人気度が重要。人気のある言語は、より高い正解率と低いコストを達成しやすい。これは、LLMが事前学習中により多くのコードに触れているためと考えられる。
  • 珍しい、高密度な言語は、一般的なユーザーにとって実用的な利点を提供しない。ニッチ言語用にモデルを訓練・微調整する労力は、わずかなトークン節約を上回る。

Hacker Newsのコメントから得られるコミュニティの知見

"我々の結果では、どのモデルに対しても（図5b）、言語間の解決率の差はほとんど見られなかった。これは、AIモデルが構文のパターンマッチングではなく、汎用的なプログラミングスキルを学習していることを示唆している。" – MirrorCode論文（Python、C、Rust、Go、OCaml、Ada）【tadamcz】

"GoはLLMにとって優れた選択肢である。なぜなら、ほとんどのことに対して一貫した方法が一つだけあり、コンパイル時のフィードバックが速いからだ。" – michaelteter【michaelteter】

"コンパイル済みで、強い型付け、不変性を持つ言語（例：Gleam、Lustre）は、訓練データが少ない状態でも驚くほどうまく機能する。" – MichaelNolan【MichaelNolan】

"静的型付けは高速な検証ループを提供するが、現代の推論では型注釈のトークンオーバーヘッドは最小限に抑えられる。" – jillesvangurp【jillesvangurp】

"実際の要因は言語そのものではなく、ツールチェーンとエコシステムである。高速なビルド、優れたLint、信頼性の高いテストハーネスは、LLMが行う修正ループの回数を減らす。" – jillesvangurp

"エージェントがテスト環境を変更できると不正が可能になるため、信頼できる評価にはホールドアウトテストが不可欠である。" – gr_norm【gr_norm】

これらのコメントは、以下の2つのテーマを強調している：

  1. 現代のLLMの汎用的プログラミング能力により、言語固有の利点は減少している。
  2. ツールチェーンとエコシステム（高速コンパイル、信頼性の高いLint、標準ライブラリ）は、静的 vs. 動的という二項対立よりも、全体的なコストに大きな影響を与える。

実践者向けの実用的アドバイス

決定要因 推奨事項
主な目的 – トークンコスト 人気があり、簡潔な言語（Python、JavaScript/TypeScript、Go）を選ぶ。珍しい高密度言語によるトークン節約は、実際のタスクでは無視できるほど小さい。
主な目的 – 正確性 / セーフティ 静的型付けで強力なコンパイラを持つ言語（Rust、Go、Kotlin、Swift）を優先する。コンパイル時のチェックにより、修正ループの回数が減り、長期的には実行時間とトークンを節約できる。
ツールの可用性 高速なビルドサイクルと統合されたLintを持つ言語を使う（Goのgo test、Rustのcargo check）。より速いフィードバックループは、型注釈のトークンオーバーヘッドを上回る。
チームの専門知識 人間の開発者の慣れを優先する。LLMはどの言語にも適応できるが、最終的なコードは人間が保守できる必要がある。
珍しい／ドメイン固有の言語 十分なトークン予算を確保し、モデルをその言語で微調整できる場合、かつドメインが本当に恩恵を受ける場合（例：ハードウェア記述、形式的検証）にのみ検討する。
評価手法 言語のパフォーマンスを測る際は、非単純なタスク、ホールドアウトテストスイート、複数の努力レベル（中程度 vs. 極めて高い）を用いる。単一のタスクや玩具問題のベンチマークは避ける。

限界と未解決の問い

  • 評価はZstdとPandocの2つのタスクに限定されている。Webサービス、データパイプライン、組み込みシステムなど、より多様なワークロードでは異なるパターンが現れる可能性がある。
  • フレームワークやライブラリの影響は分離されていない。標準ライブラリが豊富な言語は、コア言語が冗長であってもトークン消費を減らす可能性がある。
  • メモリ安全性の違い（例：Rust vs. C）は示唆されたが、完全に測定されていない。今後の研究で、ファズテストやサニタイザーをスコアリングに組み込むことが可能である。
  • エージェント側のツール（例：静的解析、性質ベーステスト）が全体的なコストに与える影響は、まだ研究課題のままだ。

結論

動的型付け言語がLLMコーディングエージェントにおいて根本的にトークン効率が良いという主張は、堅実で非単純な評価によって裏付けられていない。現実的なタスクでは、静的言語と動的言語のトークンコストは類似しており、静的言語はコンパイル時のチェックにより正解率と安全性で優れることが多い。人気度とツールの質が成功の最も強い予測因子である。したがって、LLM支援のコーディングプロジェクトに最適な言語は、静的 vs. 動的という性質ではなく、開発者の慣れ、ツールの速度、プロジェクトの要件をバランスさせる言語である。

謝辞

Max Bittker、Yossi Kreinen、Aaron Levin、Alan Boll、Luke Burton、Marco Primi、Milosz Danczak、Justin Blankのコメントと修正に感謝する。

引用されたすべてのコメントは、原文のまま再現され、元のHNユーザーに帰属している。

Sources

関連