AI時代に業務で使うのは「Go」が一番いいかもしれない

はじめに

業務では主に Kotlin / Spring を使っている。 Kotlin は好きだし、書いていて楽しい言語だと思っている。

ただ、AI でコードを書くことが当たり前になった今、業務で選ぶ言語としては Go がかなり強いのではないか、と感じている。

Kotlin の好きなところ

Kotlin には明確な良さがある。

• 短くシンプルに書ける
• 書いていて楽しい
• Spring を使うと必要なものが揃っていて、素早くリリースできる
• ドメインを表現しやすい

特に Spring のエコシステムは強力で、初速を出しやすい。

一方で、いろいろなものが揃っていることは、ブラックボックスが増えやすいということでもある。便利さの裏側で、依存解決や運用の難しさを抱え込みやすい。

運用のつらさが積み重なる

業務で日々使っていると、つらさも積み重なっていく。

• Gradle を含めた依存解決が難しい
• CI/CD が遅くなりやすい
• ビルドが重い
• JVM / Spring 特有のインフラ運用でハマりやすい
• リリース時に CPU が跳ねるなど、アプリケーションコード以外の問題に時間を取られる

これらは一度だけの問題ではない。 デプロイが安心してできないと、リリースに怯える日々が続く。

AI 時代には Kotlin のメリットが薄くなっている

以前は「短く楽しく書ける」「ライブラリが揃っている」「表現力が高い」ことに大きな価値があった。

でも今は、そもそもコードの多くを AI に書いてもらっている。 ライブラリが多少足りなくても、AI に書かせればよい場面が増えた。 なければ作ってしまえばよい。

ドメイン表現についても、人間が細かくコードを書かないなら、過剰な表現力よりも、人間が読める範囲でシンプルに書かれていることの方が重要になる。

重要なのは、AI が安定して読めて、直せて、安全にリリースできることになっている。

Go の退屈さは AI 時代の強み

Go は誰が書いても似たようなコードになりやすい。 これは人間にとっては退屈に見えるが、AI にとっては大きなメリットだと思う。

• 書き方の自由度が低い
• コードが読みやすい
• 出力がブレにくい
• ビルドが速い
• 型安全
• デプロイしやすい
• 運用時の見通しがよい

アウトプットが気に入らない AI でも、Go ならある程度同じようなコードに収まりやすい。 書けるコードの幅が狭いことが、むしろ品質の下限を支える制約になっている。

観測と修正のサイクルを速く回せる

Go は pprof のような標準のプロファイリング機能が強く、OpenTelemetry などの観測エコシステムとも相性がよい。

問題を観測できれば、検知して、AI に修正させて、すぐに安全にリリースする流れを作りやすい。

このサイクルを回すうえで、ビルドや CI/CD が遅いことは致命的になる。 AI で改善速度を上げられる時代だからこそ、デプロイまでのリードタイムの短さがより重要になる。

他の言語との比較

TypeScript / Node は速くて扱いやすい。 個人開発なら Hono + Cloudflare のような構成はかなり強い。

ただ、業務ではインフラの自由度が高く、信頼性や型安全性、コードの自由度の制限を重視したくなる。 その場合、自分なら Go を選びたくなる。

Rust はメモリ安全性が高いが、ビルド時間や学習コストが重い。 高度な計算処理、暗号化、メディア処理、エッジデバイス、極端にメモリ制約が厳しい環境でもない限り、多くの業務では Go の方が現実的に見える。

いま感じている不満

正直、これを書いた背景には Kotlin / Spring のプロジェクトで CI/CD が安定せず、遅いことへの不満がある。

しかも、すぐに解決できない。 それなりの労力を割いても、根本的にビルドが遅いので改善幅には限界がある。

AI で改善のサイクルをどんどん回せるはずなのに、ビルドやデプロイの遅さでそれが止まるのは歯がゆい。

まとめ

Kotlin は好きだし、面白い言語だと思っている。 ただ、業務で自分が新しく選ぶなら、今は Go を選ぶ可能性が高い。

AI 時代に重要なのは、気持ちよくコードを書くことよりも、AI が安定して生成し、読み、修正し、素早く安全にリリースできること。

その意味で、退屈で、制約があり、ビルドが速く、運用しやすい Go はかなり AI フレンドリーな言語なのではないか。

反論があるならぜひ聞いてみたい。教えて欲しい。 Kotlin は好きだし面白い言語だけど、運用を考えたら、正直いまの自分では選ばないと思っている。