2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

2025年、Go言語に1年間向き合って分かった「運用コストで勝つ」本当の意味

Last updated at Posted at 2025-12-24

挨拶

デフエンジニアの会アドベントカレンダーに参加しています。

過去記事
中途失聴エンジニアとして世の中を良くしたい!
https://qiita.com/Chihiro_0808/items/8f01e386b6a922b3060e(2022)

Pythonで時計アプリを作ってみた
https://qiita.com/Chihiro_0808/items/d978a671358fcaf859bb(2023)

今年はGo言語で仕事をするようになったので、
この1年間、Go言語と向き合う中で感じたこと、考えたことを、技術的な側面だけでなく、開発者としての視点からまとめてみたいと思います!

Go言語が220万人の開発者に選ばれる理由

2025年、Go言語は誕生から16年目を迎えました。
2025年のGo開発者調査によると、世界中で220万人のプロフェッショナル開発者がGoを使用しており、全開発者の11%が今後1年以内にGoを導入予定だそうです。
また、2024-2025年のStack Overflowサーベイでは、Go言語は「学びたい言語」ランキングで7位程度に位置していると書いてありました。
また、使用している開発者からの満足度(称賛度)ではRust、TypeScriptに次ぐ3位と非常に高い評価を得ています。
Go言語ってPythonとかよりも名前がそこまで知られていないと思うのに、なんでだろうと思いました。
でもその理由は調べてみて分かりました。

「シンプルさ」という設計哲学の勝利

Go言語に触れて最初に感じたのは、シンプルだなということ。

他の言語を触ってきた経験から言うと、多くのモダン言語は「表現力」を追求します。
Rustの所有権システム、TypeScriptの高度な型システム、Pythonの柔軟性...。
それぞれ素晴らしい特徴ですが、同時に「学習コスト」という代償を払う必要があります。

(学習コスト・・・便利で強力な仕組みほど理解して扱えるようになるまで時間と頭のエネルギーを消費するという意味です。)

言語 すごいところ 代償(学習コスト)
Rust 超安全 & 高速 所有権・借用・ライフタイム理解
TypeScript 強力な型安全 & 安心開発 複雑な型システム理解
Python 自由で柔軟 & 爆速開発 設計力・規律が必要

一方、Goは違いました。

// Goのエラーハンドリング
result, err := doSomething()
if err != nil {
    return err
}

Goのエラーハンドリングは毎回明示的にチェックして書く必要があるから、最初は面倒くさく感じました。
JavaやPythonみたいに例外投げてcatchする方が短く書けるんじゃない?と思いました。

しかし、プロジェクトが大きくなり、チームメンバーが増えるにつれて、この「冗長さ」の価値が見えてきました。

  • 誰が書いても同じコードになる
  • エラーハンドリングが明示的で見落としにくい
  • デバッグが容易

特に印象的だったのは、3ヶ月ぶりに自分のコードを見返したときです。他の言語では「これ、何やってたんだっけ?」となることが多いのですが、Goでは「ああ、そういうことか」とすぐに理解できました。

これが、Goの開発者満足度93%という数字につながっているのだと実感しました。

「運用コストで勝つ」という新しい価値観

2025年の技術記事で印象的だったのが「Golangは運用コストで勝つ言語」という表現です。

つまり、

Goは学習曲線や機能の派手さで勝負する言語じゃない。
運用・保守・チーム開発・長期稼働の現場で圧倒的に強い=結果として【総コストが安い】
そこが武器の言語だ

ということだそうです。

Go言語は

① 言語仕様があえてシンプル

機能が少ない(でも必要なものは揃ってる)
複雑なメタプログラミングなし
書き方の流派が生まれにくい

👉 誰が書いても似たようなコードになる
👉 新人が入っても学習コストが低い
👉 時間が経っても"読める"コードが残る

これは現場でめちゃくちゃ強いです。

② 運用がめちゃくちゃ楽

単一バイナリにコンパイル → そのまま配布できる
ランタイム不要(PythonやJVMみたいな依存環境管理が軽い)
クロスコンパイル楽勝
コンテナとの相性抜群

👉 デプロイが雑に強い
👉 トラブルが減る
👉 本番環境で"壊れにくい"

③ 性能が"安定して良い"

GCあるのに軽い
Cほどじゃないけど十分高速
しかも パフォーマンスが安定
スレッドじゃなく goroutine という軽量並行処理

👉 サーバ・API・マイクロサービスとの相性最強
👉 インフラ費用も抑えやすい

④ 公式ツールが"現場特化"

go fmt → コードスタイル戦争終了
go test
go vet
標準ライブラリ充実

👉 「文化」で揉めない
👉 「ツール」で片付く
👉 チームの精神衛生に良い(これ大事)

というふうに、Goは作る瞬間の楽しさより、動かし続ける現場の楽さで勝つ言語と言われているらしいです。
納得しました。

コードレビューの時間が半分になった話

Go言語はコードレビューでも楽になれる、と言われています。その具体例を挙げます。
前に、あるプロジェクトで、PythonからGoへの移行を経験しました。

Python時代のコードレビュー

# このコード、どう書くべきか議論が分かれる
# - リスト内包表記を使う?
# - map()を使う?
# - 普通のfor文?
# - どれが「Pythonic」?

Go移行後のコードレビュー

// 選択肢がほぼ一つしかない
for _, item := range items {
    result = append(result, transform(item))
}

結果として、コードレビューの時間が約半分になりました。議論が「どう書くか」から「何を実現するか」に変わったのです。

go fmtの衝撃

$ go fmt ./...

このコマンド一つで、プロジェクト全体のコードフォーマットが統一される。

当たり前のようですが、これが標準で組み込まれていることの意味は大きいです。

  • Prettierの設定ファイルは不要
  • ESLintのルールで揉めることもない
  • 「スペース2つ派 vs 4つ派」の不毛な議論もない

「合意形成の速さ」が、プロダクト開発の速度に直結することを実感しました。

2025年のGo言語アップデート:進化の方向性

Go 1.24/1.25で見えた設計思想

今年リリースされたGo 1.24と1.25を触ってみて、Goの進化の方向性が見えてきました。

1. testing/synctest:テストの革新

// Go 1.25の新機能
func TestConcurrent(t *testing.T) {
    // 並行処理のテストが仮想時間で書ける
    // もうtime.Sleepで待つ必要はない
}

これまで並行処理のテストは、実時間での待機が必要で不安定でした(Flaky Test)。

Go 1.25のtesting/synctestにより、この問題が根本的に解決されました。

つまり、

「testing/synctest」これは 「仮想時間で並行処理をテストできる仕組み」 です。

物理時間(実世界の時計)ではなく、テスト専用の時間 を Go が管理して進める。
sleep も timeout も 「時間が進んだことにする」 だけ

だから、

・速い
・安定する
・何回やっても同じ結果
・並行処理でも 完全に再現性のあるテストが書ける

つまり、
並行処理を「安全に使える」だけでなく「安全に検証できる」段階にしたということ。

これは、

Goは言語だけじゃなく運用まで含めて設計する

・コードを書く
・動かす
・長期間運用する
・テストする

ここまで含めて「プロダクション言語」と捉えている。

「並行処理が得意な言語」として、テスト環境も並行処理に最適化される。この一貫性に、Goチームの設計思想を感じました。

まとめると、

Go 1.25 の testing/synctest は、
「並行処理は得意だけどテストは辛い」という矛盾を壊し、
並行処理言語として "設計〜運用〜テストまで一貫して強い" 方向へ進化した証拠

つまり、

「Goは並行処理が得意です!」
だけじゃなく「Goは並行処理を安心して現場で使い続けられる言語です」

ここまで踏み込んだ、という話です。

2. tool directives:開発体験の向上

// go.mod
tool github.com/sqlc-dev/sqlc/cmd/sqlc
tool github.com/golangci/golangci-lint/cmd/golangci-lint

Go 1.24で導入されたtoolディレクティブは、地味ですが開発体験を大きく変えました

新しいチームメンバーが参加したとき

以前

# READMEを読んで...
make setup  # これが動くかわからない
# ツールのバージョンが違う
# 「動かないんですけど」

つまり、開発現場ではありがちなこの地獄がありました。

・README読んで手作業でツール入れる
・brew install xxx
・go install …@latest
・人によって違うバージョンが入る
・CI だけ落ちる/新人だけ動かない

「え、私の環境では動きますが?」戦争勃発

つまり環境構築で半日 or 1日溶ける・・・本質じゃないところで疲れるということがありました。

現在

go mod download  # これだけ
# すべてのツールが正しいバージョンで準備される

「環境構築で半日消費」という悪夢から解放されました。
これは、

・余計な make setup
・手作業インストール
・README職人芸
・ツールのバージョンずれ

全部消えて、 「コードと同じように、ツール環境も宣言して共有できる世界になった」ということ。

Go言語と並行処理:改めて感じる設計の美しさ

goroutineの「当たり前さ」が異常

// これだけで並行処理
go doSomething()

他の言語での並行処理と比較すると、Goの「軽さ」が際立ちます。

Node.js(async/await)

// 色がつく(async/await地獄)
async function main() {
    await doSomething();
}

Python(asyncio)

# イベントループを意識する必要がある
import asyncio
await asyncio.gather(...)

Go

// ただ書くだけ
go doSomething()

この「当たり前さ」が、マイクロサービス時代に強い理由だと実感しました。

チャネルの美しさ

// データの受け渡しが直感的
results := make(chan Result)
go worker(results)
result := <-results

最初は「チャネルって何?」と戸惑いましたが、使ってみると並行処理の考え方自体が変わりました

ロックやミューテックスで「守る」のではなく、チャネルで「流す」。

「メモリを共有して通信するのではなく、通信によってメモリを共有する」というGo Proverbsの意味が、ようやく腹落ちしました。

クラウドネイティブ時代の最適解

コンテナとの相性

FROM golang:1.24 AS builder
WORKDIR /app
COPY . .
RUN go build -o main .

FROM scratch
COPY --from=builder /app/main /main
ENTRYPOINT ["/main"]

最終イメージサイズ:約10MB

Pythonアプリケーションの500MB、Node.jsアプリケーションの200MBと比較すると、この軽さは衝撃的です。

コンテナ起動時間、イメージプル時間、ストレージコスト...すべてが改善されます。

AIツールとの組み合わせ

2025年の開発環境調査では、70%以上がAIアシスタントを使用しているとのこと。

実際、GitHub CopilotやCursorでGoを書くと:

// コメントを書くだけで...
// HTTPサーバーを起動してJSONを返す

// ↓生成される
func main() {
    http.HandleFunc("/api", func(w http.ResponseWriter, r *http.Request) {
        json.NewEncoder(w).Encode(map[string]string{"status": "ok"})
    })
    http.ListenAndServe(":8080", nil)
}

Goのシンプルさとパターンの少なさが、AI生成コードの品質向上につながっています。

複雑な言語ほどAIが「変なコード」を生成しがちですが、Goではその心配が少ないです。

Go言語と他言語の使い分け:2025年の視点

Goを選ぶべきケース

実際のプロジェクト経験から、Goが最適だったケース

  1. マイクロサービスのバックエンド

    • 高いスループット
    • 低レイテンシ
    • コンテナとの親和性
  2. CLI ツール

    • シングルバイナリ配布
    • クロスコンパイル
    • 高速な起動
  3. インフラツール

    • Kubernetes Operator
    • カスタムコントローラー
    • 監視エージェント
  4. 長期運用するシステム

    • 保守性の高さ
    • バージョンアップの安全性
    • チーム変更への強さ

Goを選ばない方が良いケース

正直に言うと、Goが最適解でないケースも多いです。

  1. プロトタイピング

    • Pythonの方が速い
    • ライブラリの豊富さで有利
  2. 機械学習

    • エコシステムがPython一強
    • Goで無理に書く必要はない
  3. 複雑なドメインロジック

    • DDDにはあまり向かない
    • 表現力で他言語に劣る場合も
  4. フロントエンド

    • TypeScript/Reactが主流
    • Wasmも発展途上

AIとGoの未来:2025年以降の展望

AI開発における位置づけ

AI・機械学習の世界では、Pythonが圧倒的です。

しかし、AI推論基盤では、Goの出番があります。

// モデルサービングのAPI
func serveModel(w http.ResponseWriter, r *http.Request) {
    // 高速なリクエスト処理
    // 低レイテンシ
    // 高スループット
}

OpenAI、AnthropicなどのAPI基盤でもGoが使われています。

Google ADK-Go:AIエージェント開発

2025年にリリースされたGoogle ADK-Goは興味深いです。

// Goの並行処理を活かしたAIエージェント
agent := adk.NewAgent(...)
go agent.Run(ctx)

AIエージェントの制御ロジックに、Goの並行処理が活きる。

これは新しい可能性だと感じました。

個人的な結論:Goは「良い」言語か?

2025年、Go言語に1年間向き合って出した結論は

Goは「最高」ではないが、「最適」な選択肢が多い言語

「最高」ではない理由

  • 表現力では他言語に劣る
  • エコシステムの広さではPythonやJavaScriptに負ける
  • 先端技術(機械学習等)では主役になれない

「最適」な理由

  • チーム開発での生産性が高い
  • 長期運用のコストが低い
  • クラウドネイティブ時代にマッチ
  • 学習コストと実用性のバランスが良い

そして何より、書いていて楽しい

この「楽しさ」は、冗長さや制約の中にある明快さから来ています。

おわりに:Goと共に歩む2026年へ

2025年、Go言語は16歳になりました。

人間で言えば、まだ高校生。
これからさらに成長していく年齢です。

Go 1.26、1.27...と進化を続けるGo言語と共に、自分も成長していきたい。

そして、「シンプルであること」の価値を、これからも追求していきたい。

この記事が、Goに興味を持つ誰かの役に立てば幸いです。

Happy Coding with Go! 🎉


参考資料

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?