なぜAI時代にGoが最適な言語なのか

はじめに

本記事では、GoogleのGolang Product ManagerのCameron Balahanと、Google Cloud Chief EvangelistのRichard Seroterによって投稿された、「Why Go is an Ideal Language for AI-Assisted Software Engineering」
を和訳するとともに、私の感想を少し書こうと思う。

また、本記事は元記事の著者の一人である、Cameron Balahanさんに翻訳と公開の許諾を得ております。
快く快諾していただき、本当にありがとございました！！

注意：一言一句和訳はしません。大事な部分やある程度意訳を含みます。気になる方は原文を読んでください。
また、翻訳には一部AIを使用していますが和訳の正当性などは厳格にチェックしております。
また、本記事は人間の手によって書かれています。

忙しい人のためにこの記事を要約したものを以下に書いておく。

要約 ： なぜAI時代のソフトウェアエンジニアリングにおいてGoが最適なのか

原文の主張としては 「AI時代で人間がコードを書かなくなったからこそ、言語選定の重要性は増している」 というものだった。
Goは標準ライブラリだけである程度の開発ができることに加えて、コンパイラやテスト、依存関係管理や脆弱性の検査までを標準ツールチェーンとして装備していることにより、単なるプログラミング言語ではなく、ソフトウェアエンジニアリングのプラットフォームだと位置付けている。 それによってAIエージェントが自分の出力を検証し、自分で修正するLoop Engineeringの足場を揃えることができる。
また、人間がコードを書かない現代において、書式の統一や読みやすさを優先した（書きやすさではなく）言語設計はレビュー負荷軽減に寄与している。

AIの行動を制御するガードレールとしてはLLMのツール内に閉じる話が多いが（SkillsやHooksなど）、Goはそれ自体がAIエージェントのガードレールとして機能する——というものだった。

冒頭にも書いたが、この原文はGoogleメンバーによって書かれたものなのでポジショントークありきなのも念頭におきながら、同意できる部分と引っかかった部分は訳文のあとに書いていく。

【翻訳】Why Go is an Ideal Language for AI-Assisted Software Engineering

From Writing to Reviewing

コーディングエージェントが 数秒で構文も正しいコードを数百行、数千行生成できるようになった現代において、重要なことは コードを書くことではなく、コードをレビューし、検証し、保守することである。
また、AIエージェントを我々人間のチームメイトとしてどのように協働していくかが重要である。

Go is for Software Engineering

大前提としてソフトウェアエンジニアリングとプログラミングは同じものではない^[1]。

プログラミング： コードを書いて実行することによって問題を解決する手段
ソフトウェアエンジニアリング： 他者と協働し、持続可能な堅牢なシステムを設計・実装する行為。

つまり、プログラミングはただのソフトウェアエンジニアリングの一部にすぎない。

その上で、Goは「ソフトウェアエンジニアリング全体の問題解決をする言語設計」に焦点を当てた。
すなわち、言語そのものだけではなく、ソフトウェア開発のライフサイクル全体をカバーするツール群を備えたプラットフォームとして機能をするように。
Goでは、チーム全体で同じ方法でコードを構成し、フォーマット、テストを行い、何十年先も 「良いコード」 であり続けるための互換性、依存関係管理のエコシステムを可能とする機能を提供しており、AIにとってこの共通基盤の重要性はかつてないほど高まっている。

Go is a Platform

Goは単なる言語でなく、プラットフォームである。
Go プラットフォームは、フォーマッター、テストフレームワーク、依存関係管理、そして高度なセキュリティツールを標準で提供しており、そのすべてが標準ツールチェーンから直接利用できる。

この統合されたツール群によって、エコシステム全体の一貫性がもたらされている。
Go開発者のほとんどが同じツール群を使用することによって、コミュニティ全体が足並みを揃えてランタイム、IDE、パッケージエコシステムの言語拡張を行うことが可能になっている。
これにより構造的な均一さがもたらされ、それは人間にとって開発・保守がしやすいだけではなくLLMにとってもより構造化・整理された学習データを得ることができ、品質にブレのないコードを生成することを可能にしている。

Go is Readable

Goは書きやすさよりも読みやすさを優先した言語だ。
AI駆動開発時代において「読むことを第一に考える」思想はとても大きな力を発揮する。
AIエージェントや人間が検証ループを回す中で必要なのは、予測可能性・明示性・厳格な構造であり、Goはこれを一貫性のある言語仕様によって提供をしている。

結局のところ、人間にとって明快な言語は、AIにとっても本質的に明快である。
AIが生み出すコードの量やスピードが加速し続ける中で、Goの言語仕様はシステムを理解し、検証し、安全に保守する能力を失わずにスケールさせることを可能にする。

Go is Reliable

Goは読みやすいだけではなく、壊れにくく、安全で、負荷がかかっても予測可能である。

静的型システム

Goは静的な型システムを提供しており、エージェントが書くコードに一定の安全網を強制できる。
動的型付けで起きるような構造の不整合や、存在しないプロパティへの参照、表面化しないバグなどをGoでは事前にコンパイラが防ぐことができる。
それだけではなく、Goのコンパイル速度の速さはAIエージェントの効率的な自己修正ループへと寄与しており、我々人間がレビューする頃には、構文的に正しいコードが届けられる。

batteries-included哲学

Goは包括的な標準ライブラリを提供しているため、外部依存なしで最適化され、安全で、公式にメンテナンスされたパッケージを利用することが多い（AIもそれを利用するし、レコメンドしてくる）。
他言語の場合だと、古くメンテナンスされていない（あるいは悪意のある）サードパーティへの依存関係を提案することもしばしばある。

また、外部依存が必要になった場合でもGoのプラットフォーム基盤が完全性を保証する仕組みが整っている。
（こちらの詳細な仕組みの解説は省きます。）

テストとファジング

Goの組み込みのテストフレームワークとネイティブなfuzz testingツールなどを使用して堅牢なテストを書き、実行できる。AIもそれらのツールを使用することで自動的に境界条件などに潜むバグを反復的に修正し、高い信頼性を提供する。

Go is Maintainable

AIエージェントが高速で実装をする今、数日で数百件のPRを出し、サービス全体をドラスティックにリファクタリング可能になることでコードベースの変化速度とアーキテクチャの逸脱の可能性が飛躍的に高まる。

これに対してGoは後方互換性を決して壊さないことを約束しているため（Go 2.0は決してリリースされない！！）、何十年後もGoのコードが壊れることはない。これにより長期的な耐久性を実現している。
また、アーキテクチャの逸脱への対策としてGoは組み込みで決定論的にリファクタリング・モダナイズするためのツール（go fix）を提供している。

Conclusion

開発者が書くコードの量が減っていくなかで、プログラミング言語の選択がこれまで以上に重要になるというのは、直感に反するように思えるかもしれない。しかし、コード生成がAIに委ねられると、ソフトウェアエンジニアリング上のボトルネックはコードを書くことから、レビュー・検証・保守の厳密さへと移行する。
ゆるやかなプロトタイピングや巧妙かつ暗黙的な近道を重視して発展してきた言語は、断片的なエージェント出力の重みのもとで安定性を保つことに苦労するだろう。
対照的に、Goの読むことを第一に据えた明快さ、本番環境への適合性、プラットフォーム全体としての一貫性は、AIのガードレールとして機能するだろう。

筆者の感想

以上が原文の大まかな内容と主張である。ここからは私の感想を書いていく。

全体として、AIがコードを書くようになってから「これからもっとGoの良さが出てくるはずだ」と漠然と思っていたことを、きれいに言語化してもらえたというのが率直な感想だ。

ボトルネックの移行とGoのプラットフォームとしての完成度

AIエージェントによって、ソフトウェアエンジニアリングのボトルネックが「コードを書くこと」から「レビュー・検証」などに完全に移行してきたことは言わずもがなみんな感じていることだ。
そしてAIを制御するためのガードレールとして、これまでさまざまな方法論が提示されてきた。SkillsやHooksを使ったHarness Engineering、Loop Engineeringといったものだ。ただ、その議論のほとんどはツールやワークフローの層で行われていて、言語そのものをガードレールとして捉える視点はあまり語られてこなかったように思う。

正直モデルの性能が上がりすぎてAIが生成するコードはどれも正しいかのように思えるが、同じロジックに対していくつも表現方法があったりする場合はこの時代においてはノイズになると思っている。
その点においてGoの言語仕様やツール周りのエコシステムの良さというのは選択肢が一つに絞られるという点でガードレールとしてある程度機能するだろうと思う。

Goの安全性の限界

コンパイラが拾うのは型や構文レベルのものなので高レベルのものまでは拾えないことに注意した方がいいだろう。
例えばGoroutineリークや、contextの伝播漏れ、業務要件にあったコードかどうかまではチェックできない。そこの部分はSkillsやrulesなどである程度良いコードやチェック観点みたいなものを持たせるとカバーできたりするだろう。
とはいえ、裏を返せば「人間が気をつけて見るべきなのはだいたいこの辺り」と当たりをつけられるということでもある。レビューの負荷が上がり続けている今、見なくていい範囲がはっきりしているだけでもかなりありがたい。

ソフトウェアエンジニアリング ≠ プログラミング

Software engineering is not the same thing as programming. Where programming is about solving a problem by writing code and then running it, software engineering is the act of collaborating with others to design and implement a durable system that evolves over time. Programming is a part of software engineering, but just a part.

この部分はとても良い話だと思った。
AI時代の話とはあまり関係ない部分ではあるが、全体俯瞰してソフトウェアエンジニアリングしようぜ。というメッセージを感じた。

おわりに

Googleチームによる「AI時代のGo言語の良さ」みたいなものを和訳してみました。
Goの良さをつらつらと書いており、私はとても好きな文章でした。

ただ、あくまで現状の話をしており今のLLやAIの進化のスピードを考えるとどうなんだというのが正直な気持ちです。
というのも現状のレビューというのは「責任の所在」をどこにするかという役割も果たしており、今は人間がそれを担っていると思っています。
正直言ってAIはほとんどの人間より頭が良いし、潜在的なバグや気づかないレビュー観点まで抽出してくれるのでこの責任の問題が技術や仕組みの変化で対処できるとまた別の関心へと移っていくんだろうなという印象です。

根本的な変化がまた起こった時、その時のソフトウェアエンジニアリングはどんなものでしょうか。我々エンジニアは生き残れるのだろうか。

脚注

1. 出典：research.swtch.com/vgo-eng（"Software engineering is not the same thing as programming."）