LLM時代の言語選定――こんな時代だからこそGolang?!
前置き
この記事は、当初『LLM時代にどの言語を選定すべきか?』というタイトルで書き始めました。
書いている途中でインパクトに欠けると感じ、今のタイトルに落ち着きました。
しかし、主張の本質はあくまで「LLMの進化と普及を踏まえ、改めて言語選定のあり方を問い直すべきではないか？」という点にあります。本記事では、そのような時代に合致した言語の条件を考え、最も現実的な選択肢の一つとしてGolangを提案します。
惰性の言語選定に一石を投じたい
「俺の財宝か？欲しけりゃくれてやる。探せ、この世の全てをそこにおいてきた」
世は！正に！大LLM時代！！
...ということで、エンジニアを取り巻く環境は大きく揺れ動いてる昨今です。
「人間がハンドルを握りAIがアシストする開発」から「AIがハンドルを握り人間がアシストする開発」へとシフトしつつあります。
そんな時代に、惰性の言語選定で大丈夫でしょうか？
「これまでxx言語を使ってきたから、特に何も考えず次もxx言語で行こう」、そんな調子でいいのでしょうか？
今、言語の学習や置き換えにかかるコストがLLMによって劇的に下がっています。
慣れていない言語でもLLMを使えば比較的簡単に実装できます。新しい言語を学ぶときに直面する壁も、今では隣にLLMという強力なサポーターがいるおかげで、ぐっと越えやすくなりました。
また、既存のよく知っているコードを投げて「△△の言語に置き換えて」と頼むと、LLMはかなり高い精度で変換してくれます。
つまり、学習コスト・移行コストは今までにないほど低くなっているのです。
そこで改めて、LLM時代にどの言語を選定すべきか、問い直すときが来ています。
これまでとは違った言語を選んでみてもいいのでは?
LLM時代に適した言語へと移行する選択を検討してみてもいいのでは?
では一体、LLM時代に求められるプログラミング言語の条件とはなんでしょうか。
LLM時代に適した言語の3条件
個人的に思う、LLM時代に適した言語の条件は以下の3つです。
- 静的型付け言語であること
- 読みやすさを重視すること
- ビルド・コンパイル速度が高速であること
順番に述べていきます。
1. 静的型付け言語であること
LLMにコードを書かせる際に最も重要なのは「良質なコンテキスト」です。
静的型は、LLMにコンテキストを明示する優れた仕組みとして機能します。
例えば「引数の型は〇〇で、戻り値の型は△△」と指示するだけで、LLMは要件に即した高品質な関数を書いてくれます。
我々は型を通じてAIに曖昧さのない意図を伝達することができるのです。
また、型があればLLMは自らの出力をそれに照らして自己修正できます。
例えば、ClaudeにTypeScriptのコードを書かせると、Claude自身が書いたコードの型エラーを認識し、勝手に直してくれます。
これがJavaScriptの場合だと、Claudeは自らのミスに気づかず、誤ったコードを「タスクが完了しました」と言って提出してくることも少なくありません。
世の中には「LLMの登場によって静的型付けは不要になる」という意見もありますが、自分はこのような理由からむしろ「LLMの時代には静的型付けが一層役に立つ」と考えています。
2. 読みやすさを重視すること
AIがコードを書く時代において、もはや「書きやすさ」よりも「読みやすさ」が重要です。
人間はコードを書くよりも、レビュー・保守・理解といった“読み手”として関わる機会が増えています。そのとき、コードの明確さや意図の伝わりやすさが、開発の生産性を大きく左右します。
かつて、一部では「コードは短く書くのがスマート」という美学が支持されていました。RustやGoのようなやや冗長な記述を嫌厭する人も少なくなかったと思います。
しかし、今やLLMがあるので、書くことの苦労は大きくありません。そうなると、多少長くても意図がはっきりと読み取れるコードの方がむしろ価値が大きくなります。
AIが“書く側”を担う時代において、人間は“読む側”として、コードの意味や背景を正確に汲み取ることが求められます。
その意味で、読みやすさを重視した言語設計やコーディングスタイルは、AIとの協調開発を前提とするこれからの時代において、より重要な選定基準になるはずです。
3. ビルド・コンパイル速度が高速であること
LLMの導入によって、コードの生産スピードはかつてないほど向上しました。
しかしその結果、次に浮かび上がってきたのがCI/CDの実行速度やビルド時間といった「出荷側」のボトルネックです。
PRの数は増え、テストは頻繁に走り、リリースを待つ行列は詰まりやすくなりました。
この状況では、ビルドが速いかどうかはもはや開発者体験だけの問題ではなく、チーム全体の開発スループットに直結する構造的な課題になってきます。
これは、開発フローにおける大きなパラダイムシフトです。
以前は「実装」が最も時間のかかる工程でした。
しかしその工程がAIによって圧縮された今、新たなボトルネックは“いかに素早く本番に出すか”に移っているのです。
たとえるなら、レストランに自動調理ロボットを導入して、どんな料理も高速で仕上がるようになったようなものです。しかしホールスタッフが相変わらず1人なら、カウンターには出しきれない料理が山積みになり、提供が追いつきません。
実際の開発現場でも、リリース頻度の向上により「AチームもBチームもCチームも今日リリースです」といった状況が来るかもしれません。
安全のために業務時間外にリリースを行うと、ビルドにかかる時間が長ければ、Cチームのリリースは21時スタート…なんてことになりかねません。
半分冗談のような話ですが、現実になる可能性も十分にあります。
それでも私たちエンジニアがやることは、いい意味で変わりません。
何かを作って、それを人に届け、フィードバックを受け取る。
この開発サイクルをなるべく速く、気持ちよく回すためには、ビルドやコンパイルをボトルネックにしてはいけない。
私はそう思います。
ではどの言語が適切なのか
サーバーサイドの言語として、近年、人気が高まっているのはやはりRustとGoでしょう。
どちらも非常に優れた言語で、個人的にどちらも好きです。
この2つの言語を詳しくみていきたいと思います。
Rust
Rustは、Null安全・メモリ安全・型安全という3拍子揃った唯一無二の言語です。
それでいて並外れた実行速度を持ち、理想的な言語だと感じます。
反面、欠点は「学習コスト」と「コンパイル速度」です。
ただし、LLMによって前者は大幅に軽減され、以前より容易に学べるようになりました。
しかし、後者は依然として課題です。
「コンパイルやビルドが高速であること」の重要性が増していく今、この欠点がRustの持つ安全性と厳密さのメリットと比較しても、個人的には受け入れ難いものだと感じています。
Golang
一方、Golangは、Rustに比べると柔らかい言語です。
安全性と厳密さにおいて、正直、Rustに劣ることは否めません。
しかし、その代わりにビルドが非常に高速です。
プロジェクトの初期ビルドは瞬時に完了し、増分ビルドも安定して速く、CI/CDにおいても安定性と速度を併せ持っています。このことは、LLMが書いたコードを即座に検証・反映したい現代の開発サイクルにおいて大きなメリットです。
これからやってくる時代は、
- コードが頻繁に更新される
- 新しい機能が次々にリリースされる
- CIが1日に何十回も回る
そんな時代かもしれません。
そう考えたとき、Goの持つ安全性とスピードは、時代にマッチします。このような理由で、Rustほどの厳密さはありませんが、実用的でバランスの取れた言語としてGoを推してみたいです。
LLMと共に働く現代の開発環境において、Goは“即時性”と“実用性”を兼ね備えた言語として、もっと脚光を浴びてもいいのではないでしょうか。
まとめ
本記事では生成AIの時代の開発言語選定について書きました。
最後に余談になりますが、私は普段Kotlinでサーバーサイド開発をしています。
Kotlinは良い言語です。DDDを実践しやすく、強力な型システムも備えています。
ただ、Gradle＋JVMというビルド環境の重さ、初動の遅さが気になっています。
そんな「待ち時間がネックになるかもしれない」という想いが、本記事を書くきっかけになりました。
なので、最近はCloud Run Functionsなどの部分で、アプリケーションの中核ではないところから、実験的にGoを取り入れています。LLMと一緒にGoを書くのは楽しいです。
そして、結局のところ、開発言語の選定に絶対の正解はありません。
しかし、何を重視するか、何を許容するかを言語の性質に照らして考えるヒントとして、本記事が誰かの参考になれば嬉しいです。
最後までお読みいただきありがとうございました。
Discussion