GoはAIエージェントに最適な言語か

getbruin.comが「Go Is the Best Language for AI Agents」という記事を投稿し、HNで300件以上のコメントがついた。核心の主張と反論をRubyist視点で整理する。

原文の核心主張

AIエージェントが大量にコードを生成する時代。エージェントが作るコードは大半が「それらしく見える」レベルなので、実際の動作検証が核心課題。

Goはこの検証に有利だというのが原文の要旨：

コンパイル言語の利点 — 静的型付けで誤った型/引数使用をコンパイル時に除外。コンパイルが通れば最低限構文的に正しいコードという保証がある。Rubyの「本番でTypeError発見」がなくなる。

Rustよりgo — Goの文法がRustより単純でLLMがより慣用的なコードを生成。GoのコンパイルがRustより速くエージェントのフィードバックループが短縮。学習データにGoコードが多い。

標準化ツール — gofmt、go test、go buildが標準。JSのような「このプロジェクトはPrettier、あちらはESLint」という混乱がない。

クロスプラットフォームバイナリ — GOOS=linux go buildで完了。Rubyの「このgemはWindowsで動かない」問題がない。

Rubyistが読むと刺さる部分

Rubyの弱点が正確に指摘される。

PythonとRubyの問題：同じ作業に20通りの方法がある。Net::HTTP vs Faraday vs HTTParty vs RestClient。エージェントがどのライブラリを使うか予測不能。Goはnet/http一つでほぼ解決。

エージェントがGoコードを一発で有効に生成する割合が約95%（著者体感）。Ruby/Pythonはランタイムでやっとエラー発見。この差はエージェントワークフローで大きい。

HNの反論

「Javaも同じ理由で適合」 — 正しい。より多い学習データ、より強力な型システム。Javaに言及しないのは若干偏向的。

「Rustの方がいい」 — コンパイラエラーを通過すればランタイムエラーがほぼない点で正しい。ただしRustは変化が速くLLMが最新APIについていけないという反論も。Rustのテストがソースファイル内にあるのでエージェントが修正時テストも一緒に更新するのは良い指摘。

「OCaml/Haskellが最高」 — 強力な型システム（GADT含む）、純粋関数、高速ビルド。理論的には正しいが学習データが不足。

「Pythonの方が良かった」 — 複数言語でプロジェクトを書き直した人がPythonがClaudeに最も合ったと主張。コードが短く理解しやすい。

「言語よりドメインが重要」 — 最も現実的な意見。TypeScriptはWeb、PythonはData/ML、GoはCLI/インフラ。「最高の言語」はエージェントが何をするかによる。

Rubyistはどうすべきか

Rubyがエージェントコード生成に不利なのは事実。動的型付け、フレームワーク断片化、ランタイムエラー依存。構造的弱点だ。

でもRailsアプリをGoで書き直すべきか？いいえ。原文も認めるように「12ヶ月後にはコードを直接読む機会が減る可能性」がある。現在の言語別長短所はLLM性能向上とともに意味が薄れうる。

実用的アプローチ：Rubyでビジネスロジック、Goでパフォーマンスクリティカルな部分。SidekiqワーカーをGoに転換、CLIツールをGoで作る。すでに多くのチームがこうしている。

この記事の本当の教訓は「Goが最高」ではなく、コンパイル時検証＋標準化ツール＋単純な文法がエージェント時代に価値が上がるということ。Rubyがこの方向に進化できるかがRubyistにとってより重要な問いだ。