「退屈な言語」がAIエージェントと相性がいい理由:GoとRust、Railsに学ぶ低分散エコシステムの勝利

なぜ「退屈な言語」がAIエージェントに選ばれるのか 2026年5月、Jacob Young(Sancho Studio創業者)が発表した “Use Boring Languages with LLMs” がHacker Newsで話題を集めている。その主張はシンプルだ。「LLMは訓練コーパスの分散が低い言語で圧倒的に良いコードを生成する。逆に分散が大きいエコシステムは、エージェントの出力品質を著しく低下させる。」 この論文はHNで203ポイント・293コメントの議論を巻き起こし、Goコミュニティを中心に「AIエージェント時代の最適言語」を巡る活発な論争を引き起こした。本稿では、この論文の核心的な主張をコード例を交えて解説し、日本におけるAIエージェント言語選定の一助とする。 低分散エコシステムとは何か Youngの主張を一言で言えばこうだ。 LLMは一貫性のある技術スタックを増幅し、断片化した技術スタックを静かに劣化させる。 「低分散エコシステム」とは以下の特徴を持つ言語・ツールチェーンのことを指す。 訓練コーパスの分散が小さい — 言語の書き方が一貫しており、LLMの学習データにおける表現のばらつきが少ない 「唯一の正しい書き方」が存在する — Convention over Configurationの原則が浸透している ツールチェーンが強固 — フォーマッター、リンター、静的解析が標準装備 依存関係の選択肢が限定的 — フレームワークやライブラリの「迷い」が少ない 後方互換性が長期にわたって維持される — 言語自体が頻繁に破壊的変更を行わない この条件を最もよく満たす言語として、YoungはGoを第一候補に挙げる。次いでRailsに代表されるRuby、そしてある程度はRustも該当する。逆に最もスコアが低いのはJavaScript/TypeScriptエコシステムとPythonだ。 GoがAIエージェントに最適な5つの理由 1. シンプルな並行処理モデル GoのgoroutineはチャネルベースのCSP(Communicating Sequential Processes)モデルを採用している。これは訓練コーパスにおいて極めて一貫性のある表現を持つ。 results := make(chan string, len(urls)) for _, u := range urls { go func(u string) { resp, err := http.Get(u) if err != nil { results <- err.Error() return } defer resp.Body.Close() results <- resp.Status }(u) } for range urls { fmt.Println(<-results) } このコードは「これがGoでの標準的な並行処理の書き方」として確立されており、LLMが何度も見てきたパターンだ。対照的にJavaScriptのasync/awaitやPromise.all、Pythonのasyncioやconcurrent.futuresは複数の書き方が混在しており、LLMがどのパターンを選ぶべきかを推論するコストが増加する。 2. 包括的な標準ライブラリ Goの標準ライブラリはHTTPサーバー、暗号化、JSON/XML処理、テンプレートエンジン、SQLデータベース等、商用アプリケーションに必要な大部分をカバーする。これによりサードパーティへの依存判断が最小限で済む。 package main import ( "fmt" "net/http" ) func main() { http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, "ok") }) http.ListenAndServe(":8080", nil) } このHTTPサーバーのコードはGoの訓練コーパスに無数に存在する。エージェントは「どのフレームワークを使うか」を判断する必要がなく、標準ライブラリの範囲内でコードを生成する。 ...

May 28, 2026 · 18 min · 3595 words · Appwright

AIがコードを書く時代に、なぜPythonなのか? — HNで150コメントを集めた議論を分析する

2026年4月、Noah Mitchem が Medium に投稿した「If AI Writes Your Code, Why Use Python?」という記事が Hacker News で話題になった。150近いコメントが寄せられ、現在も議論が続いている。 この記事では、その議論をベースに「AI時代のプログラミング言語選択」を考察する。 問題の整理:なぜPythonなのかという問い 従来のプログラミング言語選択において、Python と TypeScript は「人間の生産性」という軸で優位に立ってきた。書きやすく、ライブラリが豊富で、チームの生産性を最大化できる。C++ や Rust のような「ハードな言語」は実行性能は高いが、開発速度が犠牲になる——これが長年のトレードオフだった。 しかし、AI コーディングエージェントがこのトレードオフを根本から変えつつある。AI は Rust や Go のような強力な型システムを持つ言語で、むしろ高い品質のコードを生成する。そして、そのコードはコンパイル時に多くのバグを検出できる。 つまり、「書く」コストがAIによって劇的に下がった今、「実行する」コストが再び重視されている。 2026年前半に実際に起きたこと 抽象論ではなく、具体的なプロジェクトを見てみよう。 プロジェクト 言語移行 成果 TypeScript 7.0 beta(Microsoft) TSコンパイラを Go に移植 TypeScript 6.0比で約10倍の高速化 Rue(Steve Klabnik) Claudeで新言語を開発 7万行のRustを2週間で実装 Ladybird JSエンジン(Andreas Kling) C++ → Rust(Claude/Codex) 2.5万行、バイト単位の互換性、ゼロリグレッション Cコンパイラ in Rust(Nicholas Carlini/Anthropic) 16並列のClaudeエージェント 10万行のRust、Linux 6.9をx86/ARM/RISC-Vでブート PyTorch 依然Python優勢 深層学習研究の約85%を占有 Anthropic の Nicholas Carlini による C コンパイラの事例は特に衝撃的だ。16の Claude エージェントを並列動作させ、10万行の Rust コードを生成。x86、ARM、RISC-V の3アーキテクチャで Linux 6.9 をブートし、QEMU、FFmpeg、SQLite、PostgreSQL、Redis のコンパイルに成功。総コストは約2万ドル、約2,000セッションだった。 ...

May 12, 2026 · 13 min · 2590 words · Appwright