- Go言語のシンプルさとコンパイル特性が、AIエージェントが生成するコードの安定性と実行効率を高める
- 静的型付けと高速なコンパイル速度により、エージェントはコードエラーを素早く検証し、反復作業を効率的に進められる
- 言語レベルの標準化されたツール（gofmt、テスト、ビルド）が、エージェントの一貫したコード生成を促す
- クロスプラットフォームバイナリのビルドが標準でサポートされており、バックグラウンドエージェントがさまざまなOSで同じコードを分散検証・実行できる
- これらの特性により、Goは生産性、シンプルさ、性能のバランスが取れた言語と評価され、AIエージェントベース開発における有力な選択肢として浮上している
Goがコンパイル言語である利点
- エージェントは大量のコードを生成するが、その多くは「もっともらしく見える」レベルにとどまるため、実際に動作するかどうかの検証が重要な課題となる
- コンパイル言語を使えば、強い型付け・静的型システムによって、誤った型や引数の使用など特定の種類のバグをコンパイル時点で排除できる
- コンパイルが成功すれば、少なくとも言語標準の範囲では構文的に正しいコードであることが保証される
- Rustと比べてGoがエージェントにより適している理由:
- Goの文法と概念はRustよりシンプル
- Goの型システムはRustほど精巧ではないため、生成されたコードがより慣用的な書き方に近く、人間にも理解しやすい
- Goのコンパイル速度はRustより速いため、エージェントのフィードバックループが短くなる
- RustよりGoコードのほうが学習データに多く含まれているため、モデルはよりよいGoコードを生成できる
Goのシンプルさ
- どのプログラミング言語でもある程度経験があれば、Goコードを読んですぐに動作を把握できるほど、言語自体がシンプル
- エージェントが大量のGoコードを生成しても、開発者がコードを追うのはそれほど難しくない
- エージェントがときどき奇妙な設計判断を下し、その方向に進み続ける場合でも、言語のシンプルさのおかげでエージェントがどこへ向かっているのか把握しやすい
- 12か月後にはコードを直接読む機会が減り、可読性やシンプルさの重要性が低下する可能性もあるが、必要なときにコードを直接確認できる選択肢には依然として価値がある
Goの標準化されたやり方
- Goは明確なガイドラインとツールを備えた opinionated な言語であり、テスト実行・コード整形・バイナリビルドに標準的な方法が存在する
- エラー処理の方式にも賛否はあるが、ひとつの確立されたパターンを提供することで、複数の人やエージェントが一緒に作業しやすい慣用的なコードを書くよう促す
- JavaScriptとの対比: JSプロジェクトは使うツールがプロジェクトごとに異なり、コード整形・パッケージ配布・ライブラリのインポート方法についての考え方も分散しているため、エージェントには非効率
- Goの標準化により、モデルは学習データに基づいて慣用的なGoコードを一貫して生成できる
- エージェントにJSコードの整形を頼むと新しいツールをインストールして設定しようとするが、Goでは単に
gofmt を実行すれば終わる
- ユニットテストの作成やバイナリビルドも同様に標準化されている
クロスプラットフォームバイナリビルド
- Goではクロスプラットフォーム対応が first-class citizen であり、CLIツールのように実行環境を制御できないソフトウェアに特に有利
- ユニットテストと統合テストを複数環境で同じコマンドにより実行し、既存機能が壊れていないか検証できる
- バックグラウンドエージェント活用時にも利点は最大化される:
- CursorをSlackメッセージでトリガーしたり、ローカルセッションをリモートに引き渡したりするなど、コードのビルド・実行環境を直接制御することから徐々に切り離される流れがある
- GoコードはLinux、Windows、macOSで同様にバイナリを生成でき、作業プロセス全体が環境間で標準化されているため、サンドボックス提供者が開発依存関係をサポートしているかを気にする必要がない
エージェントのGoコード生成品質
- 2026年初頭時点で、エージェントが有効なGoコードを一発で生成する割合は約95%（個人的な経験に基づく数値であり、公式データではない）
- PythonよりもGoでエージェントを使うほうが難しさが少ないという実感がある
- モデルはGoのライブラリ・パターン・ベストプラクティスを十分学習しており、方向性だけ示せば機能実装がほぼ容易に進むレベル
- Goの学習データ総量はPythonより少ないかもしれないが、Pythonでは同じ作業に20通りの異なる方法があるため、特定ライブラリ基準で見ればGoのほうが学習データ密度が高い効果がある
- モデル性能の向上と学習データの拡大に伴い、この利点は時間とともに薄れる可能性がある
BruinプロジェクトがGoを選んだ背景
- BruinはオープンソースのETLツールで、主にGoで書かれたCLIツール
- データエコシステムではPythonが主流だったが、Goを選んだ主な制約条件:
- データオーケストレーションツールとして並行処理が中核
- 言語ランタイムやデータプラットフォーム外部APIなど多様なシステムと相互作用するため、十分なエコシステムが必要
- CLIツールとしてVS Code拡張やローカルUIバックエンドに活用するための十分な性能が必須
- 多様なシステム統合のための予測可能なエラー処理が必要
- ユーザーのマシン上で実行されるため、多様なOS・アーキテクチャ対応のしやすさが求められる
- 主観的な要素として、主要コントリビューターが楽しく作業できる言語である必要もあり、小規模チームでは楽しさとエネルギーこそが最も希少な資源
- Pythonと比べて一部のデータライブラリ不足という欠点はあるものの、Goの**速度と開発者体験（DX）**の利点が長期的にはより大きな価値をもたらすという直感から決定した
結論: エージェント時代のGo
- プログラミング言語は人間が直接コードを書かない時代へ移行しつつある
- 今や、エージェントが効果的にコードを書けるよう支援するシステムが必要
- Goは使いやすさ、性能、汎用性のバランスにより、AIエージェントがコードを書いて実行するのに理想的な環境を提供する
- エージェントはGoでコンパイル、テスト、整形、多様なマシンへの配布が可能な高性能ソフトウェアを自動生成できる
- Goがエージェントにとって究極の言語になるのか、より適した言語が登場するのかは不確実だが、
現在のチームは生産性とソフトウェア品質で十分な成果を上げている
3件のコメント
とにかくビルドが速いのがいいです
Go言語は本当にコンセプトがはっきりしていて、その明確なコンセプトがうまく合う人にとっては良い選択肢になると思います。私もJSランタイムでバックエンドを作っていましたが、Goに移ってきて、性能と開発生産性の両方について、これなら十分満足できると自信を持って言えそうです。
Hacker News の反応
私は9か月以上コンサルティング業務をしてきて、Go が LLM のコード生成に非常に適していることをずっと確認している
Go は一貫したビルドシステム、フォーマッタ、静的型付け、そして C++ のような危険な部分がない CSP ベースの並行性を提供する
互換性を壊すバージョンが10年以上なく、フレームワークの変化もほとんどない
私が Sancho Studio でチームに agentic coding workflow を導入するよう助言するとき、Go は Claude や Codex で非常に安定した結果を出す
一方で Python や TypeScript はフレームワークと型アプローチがあまりに多様で、LLM が一貫した出力を出しにくい
実は Go を嫌っていた理由 ― 抽象化の限界 ― が、LLM にとっては利点として働く
Go 1.26 の新しい
go fixは AST レベルの自動リファクタリングをサポートし、コードベースを最新の状態に保つ以前 Zoom E2E Whitepaper プロジェクトで Go で PKI を構築したが、今では LLM が反復的なボイラープレートを代わりに処理してくれるので、Go のシンプルさが真価を発揮している
Java はより多くの学習データと、より強力な型システムを持っていて、LLM の出力検証にも有利だ
私はローレベル寄りの環境を好むが、Go の浅い抽象化スタックと予測可能な構造が気に入っている
結局のところ シンプルさと一貫性 が、LLM にも私のような開発者にも合っている
Go のような標準化された言語は結果を理解しやすいが、Ruby や C++ もかなり良い
Lisp や Bash は自由度が高く、結果がばらつく
Python と TypeScript を同じカテゴリにまとめるのは不正確だ
Python はバージョン断絶と遅い型導入のせいで LLM を混乱させるが、TypeScript はずっと一貫している
機会があれば Go vs TypeScript の ライブコード対決 をやってみたい
エージェント開発では、できるだけ多くの検証を コンパイル時 に移すのが良いと思う
Go も悪くないが、型システムは他の言語ほど強力ではない
Rust はコンパイラエラーを通過すればランタイムエラーがほとんどないという点で非常に有用だ
Haskell はおそらくさらに良いだろう
エージェントがソースを修正するとき、テストも一緒に更新する
他の言語ではテストを忘れやすい
私は Haskell の上に 依存型ベースのトイ言語 を作っているが、単純な文法のおかげで LLM が扱いやすい
内部的には safe/unsafe Rust のように動作する
私たちが直接書くわけではないのだから、少し不便でも構わない
TypeScript と一緒に SPA を作ったり、Tauri でマルチプラットフォームアプリを作ったり、Python のサイドカーを付けたりといった組み合わせができる
Bevy でゲームも試しているが、ECS 構造が気に入っている
複数言語の長所を集めつつ短所を避けられた
数日間、Gemini、Claude Code、Codex に「君たちが望む言語を設計してみて」とやらせてみた
結果は Forth スタイルの言語 で、強い型システムと契約、ネイティブテスト、fuzz テスト、Z3 ベースの制約ソルバを備えたものだった
Elixir でインタプリタを実装し、Cairn プロジェクト として公開している
150 コミットほどで作った言語がランタイムエラーなしに動作した
この実験は コンパイル時解析とテストツールの重要性 を示している
そうした情報は学習データになければ分からないはずだ
こういう言語のツール群を発展させるのは本当に楽しいだろう
私は今でも OCaml が最高の選択だと思っている
強力な型システム（GADT を含む）、純関数中心、高速なビルド速度、WASM/JS ターゲット対応など利点が多い
コードがファイル内の順序どおりに評価されるため、循環依存 を明示的に処理しなければならない点も堅実だ
何より人間が書いていても楽しい言語だ
以前は F# がその部分で先行していた
エージェントがうっかりバグを入れても大半は検出してくれる
PHP、Go、JavaScript、Python の中なら Go が良いが、それが「最高の言語」だという根拠としては弱い
Go のシンプルさと十分な型システムも魅力的だ
少し前に議論された "Why Elixir is the best language for AI" も参考になる
BEAM の ランタイムイントロスペクション 機能はエージェント環境で興味深いポイントだ
この文章は特に Go を批判している
Go にはコードとバイナリの脆弱性を静的解析する govulncheck ツールがある
公式チュートリアル のように Go エコシステムに深く統合されており、他の言語より高いレベルの統合性を持っている
govulncheck が実際のコードの脆弱性を解析するのかは疑問だ
呼び出し経路まで追跡する点は利点だが、Coverity のような本物の静的解析ツールとは異なる
Go では
golangci-lintのようなコミュニティ製ツール群のほうが近いと思う複数言語でプロジェクトを書き直してみたが、Python が Claude に最も合っていた
コードが小さくて理解しやすく、作業速度がずっと速かった
Go、Kotlin、JavaScript も試したが、最終的には Python に落ち着いた
Go は悪くない選択だ。学習データが豊富で API が安定しているため、LLM が扱いやすい
ただ Rust は型システムのおかげでより良いと思う
とはいえ Rust は変化が速く、LLM が最新 API を追うのは難しい
Haskell は変化の速度が遅く、安全なコードという点で LLM に最も有利だ
Python スクリプトも同じように読みやすい
毎日 AI コーディングエージェントと仕事をしている立場から言うと、「最高の言語」は エージェントの目的 によって変わる
Go のシンプルさと予測可能性は一般的な作業には良いが、TypeScript は Web 環境との連携で卓越している
Python はデータ/ML 分野で依然として独走状態だ
要は、LLM が得意な言語よりも、エージェントのドメインに合った言語 を選ぶべきだ