AI時代の開発にGoが最強な理由：なぜエンジニアは今、Goを選ぶべきなのか？

AI支援によるソフトウェアエンジニアリングが主流となりつつある現在、Go言語がなぜこのパラダイムシフトにおいて「理想的な言語」であるのか、その理由を考察します。シンプルで静的型付けされたGoの特性は、AIがコードを生成・解析・保守するプロセスと極めて高い親和性を持っています。AI開発のパートナーとしてGoが選ばれる理由を深掘りしていきましょう。

この記事には完全に同意。NetflixではGo言語ギルドを率いているんだけど、AIエージェントが他の言語よりもGoのコードを上手に書くっていう報告や、他の言語よりGoを優先するプロジェクトが増えているという報告をよく耳にするようになったんだ。付け加えるなら2つある。1つ目は、Goには「https://go.dev/doc/effective_go 」や「https://google.github.io/styleguide/go/ 」といった最高のリソースが揃っていること。追記：言い忘れたけど、こうしたリソースをAIエージェントに与えると、さらに優れたGoコードを生成してくれるようになる。2つ目は、言語チームにとってGoは夢のような存在だということ。「go fix」のツール群やAST/SSAパッケージ、go.mod（go mod editなど）の読み書きのしやすさといった「プラットフォーム」としての特徴のおかげで、大規模なGoコードの修正が他の言語に比べて圧倒的に楽なんだ。

それが何か関係ある？言語はツールだし、LLMもツール。自分がやろうとしていることに最適なものを使えばいいだけだろ。WebレイアウトをするならGoよりCSSがいいし、最小限のWASM成果物を出力するならZigの方がいい。iOS特有の開発ならSwiftの方がいいし、OSのスクリプトならBashの方がいいに決まってる。自分が何をやっているかを考えて、適切に選ぶんだ。これはLLMが登場する前から変わらない真理だよ。楽しみたいならLISPでも選んでおけば？

Goは好きだけど、エージェントの規模感や一般的な利用パターンを考慮すると、この「利点」のいくつかは帳消しになる気がする。Goは読みやすく保守しやすいというのは事実。低マジックな言語だからプロジェクト間で似たようなコードになりやすく、依存関係のソースコードを確実に理解できるのは素晴らしい。ツールチェーンも世界トップクラスだし、そこは本当に愛している。ただ実際、複数のチームでモノレポを扱っていると、チーム間の可読性を優先しないコントリビューターがとにかくコードを量産してしまう。ビジネスロジックに関しては、たとえコードを1行ずつ読めたとしても、全体像を理解していなければ、どこか遠くで何が起きているのか把握できず、意味がないこともある。エージェント導入前は、自分の頭の中に収まるコードベースが、いつの間にか原型をとどめないほど書き換えられていくのを目の当たりにしてきた。今はエージェントがいて、彼らは依然として大規模なソフトウェアエンジニアリングは苦手だから、意図的な対策を講じないとコードベースの知識負債（もちろん技術的負債も）は10倍速で蓄積していく。Goが読みやすいという特性は、その問題の本質的な解決にはならない。

Goは「パレート最適」のフロンティアにはいないと言いたいね。プログラミング言語の属性をどう評価しようが、公平に判断すればGoが選ばれることは絶対にない。簡単な例を挙げると、言語の人気を重視するならGoは一番人気じゃない。エラーを検知する型システムを重視するなら、Goは他の言語より検知能力が低い。属性をどう重み付けして合計しても、Goが選ばれることはない。それが僕の主張だ。

こういう言語ごとの主張をよく見かけるけど、正直うんざりだし未熟さを感じるよ。僕はZigでLLM支援コーディングを楽しんでいるし、仕事で使っている一般的なTypescript/Reactと比べても遜色ないと感じる。シンプルさや優れた言語設計が利益をもたらすのは疑わないけれど、LLM時代の魔法の杖なんてものは存在しないはず。辻褄が合わないんだよ。Erlang、Gleam、Lisp、C、Rust、Go、TypeScript、Pythonなど、みんな自分の好きな言語ばかり持ち上げている。特にGoを少し突っつかせてもらうと、GoにはLLMにとって特別有利なユニークな性質があるとは思えない。コンパイラの機能を活用して、より厳格な正当性を保証する他のモダンな言語の方が、まだそう主張する余地があるんじゃないかな。

この記事がやろうとしてる手品の類には笑っちゃうね。「Goは書いてて楽しくないけど、今はAIがやってくれるから関係ない！」だってさ。そうやって過去20年間ずっと微妙だったわけ？このブログの主張は、Goはソフトウェアエンジニアリング全体としては優れているから、プログラミング言語としての弱点は最小限で済むってことだよね。自分も以前、コーディングエージェントのおかげでエンジニアリングの他の側面に負荷が移るって似たような議論をしたことはあるけど。でもさ、みんなGoogleが何をしようとしてるか分かってるでしょ？彼らはルールが変わったと宣言して、Goの弱点を強みに変えようとしてるわけだ。悪いけど、自分は納得できないね。

同意できないな。LLMはかなり単純なケースですら、バグのない並行処理コードを書くのに失敗する。Golangには優れた抽象化を構築する能力が欠けているし、それ以前に、本格的なマイクロサービスに必要なツールやライブラリの無法地帯ぶりといったらひどいものだ。LLMによって、質の低いGolangコードがより速く生成されるようになるなんて危険信号でしかないよ。これは、Golangでつまらない問題を解決するために必要な、膨大な量のコードをレビューできるだけのエンジニアを雇える企業にとっては最適化になるんだろうけどさ（他のまともな言語やフレームワークなら最初から組み込まれている機能なのにね）。LLMを使うなら、適切な言語を選ぼう。それがGolangのケースもあるだろうけど、十中八九C#、Java、Python、Ruby、あるいはPHP（それかRust、C、Dなど）の方がいいはずだ。

これ、Go言語の生みの親以外の人間が言ってたならもっと信用できたんだけどな。個人的にはLLM用としてはRustの方に傾いてる。あの小うるさいコンパイラと、コンパイル時にエラーを浮かび上がらせる仕組みが、LLMにとっては理想的だと思ってる。トークンを浪費してコンパイルを繰り返す方が、実行時にどこで落ちるか推測してテストで補足しようとするよりずっとマシな戦略だよ。トークンは安いけど、実行時のトラブルは高くつくからね。だからこそ、超厳格なコンパイラが欲しいんだ。次のステップとしてLean4も見てみたけど、LLMを十分にうまく誘導できる自信がないな。

同意するよ。自分のメディアサーバーも今やほとんどAIが書いたGoコードだけど、すごくうまく動いてる。AIが登場する前から「やり方は一つ」っていうのがGoの一番好きな機能だったんだけど、今ではAIを使いつつ自分のプロジェクトを理解し続けるのがずっと楽になった。https://github.com/SteveCastle/loki

結局みんなバイアスがかかってるんだよね。自分も含めてだけど。個人的には、Goの並行処理モデルが一番の懸念点かな。使うのをためらう理由だよ。メモリ管理がされていて、シングルスレッドで、Lintが豊富でツールも充実している環境。自分がコードをレビューする前に自信を持てるのは、そういう環境だと思う。もっとも、Golangの標準ライブラリがすごく優秀なのは認める。それは大きなポイントだよ。