Skip to content
Published on

モダンGo 2026 — Go 1.24 / Echo / Gin / Fiber / Huma / Encore / sqlc / Templ / Bubble Tea 徹底解説

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — なぜ再びGoなのか、2026年に

Goは2009年に公開された。2026年5月で満16歳になる。10年あまりの時間で「退屈な言語」というアイデンティティを崩さなかったことが最大の強みだった。JavaScript陣営が1年で3度ビルドツールを総取っ替えする間、Rustがborrow checkerを精緻に磨く間、Pythonが毎年型システムを描き直す間、Goは「1.0の互換性の約束」を破らずに小さな改善だけを積み上げてきた。しかし2026年の春に改めてGoを見ると、その小さな改善が積もって作った景色は決して小さくない。

3つの変曲点がある。

第一に、言語そのものの成熟だ。2024年2月のGo 1.22がfor-loop変数キャプチャの罠を終わらせ、2024年8月のGo 1.23がrange-over-funcを正式機能として取り込み、2025年2月のGo 1.24がGenericsを「実戦でちゃんと使える道具」にした。同時にtoolディレクティブが追加されてtools.goトリックを終わらせ、weak.Pointerがキャッシュ実装を変えた。

第二に、エコシステムの分化だ。かつては「標準のnet/httpだけで十分」という合意があったが、いまではGinが市場シェア1位を保ったままEcho・Fiber・Chi・Humaがそれぞれの席を取った。ORMもGORM一辺倒ではなく、sqlc(クエリ優先)・ent(スキーマ優先)・GORM(学習曲線)・Bun(クエリビルダー)が4つに分かれた。

第三に、新しいスーパーパワーだ。Templが登場してhtmxとともに「JSなしフルスタック」という道を開き、Encoreは「Go向けバックエンドプラットフォーム」というカテゴリを新たに作った。CharmbraceletのBubble Tea・Lipgloss・GlamourがターミナルUIのルネサンスを牽引し、WailsはElectronの代わりにGo + Webviewでデスクトップアプリを書く道を固めた。

この記事はこの3つの流れを一気に整理する。Go 1.22〜1.24が何を終わらせたか、ウェブ・データベース・フルスタック・CLI・デスクトップの各カテゴリの現在のチャンピオンは誰か、日本・韓国の大手企業が実際にどう使っているか、そして2026年に新規プロジェクトでGoを選ぶべきケースと選ぶべきでないケース。

この記事の数字とバージョンは2026年5月16日時点だ。Goそのものの変化速度は遅いが、エコシステムのライブラリは速い。構造的な意思決定フレームは半年後も有効なように書いてある。

1章 · Go 1.22 (2024.2) — for-loopの罠の終焉と range over int

Goを初めて学んだ人が最も頻繁にハマる罠がfor i := range slice { go func() { use(i) }() }パターンだった。すべてのゴルーチンが最後のiの値をキャプチャするあの罠。2024年2月のGo 1.22がこの挙動を変えた。いまは反復ごとに新しい変数が作られる。互換性の約束を破れないGoチームがこれを通すまでに丸10年かかった。go.modのgo 1.22宣言が新しい挙動を有効にする — つまり古いモジュールは古い挙動を維持する。

同じバージョンで**range over int**も入った。for i := range 10がfor i := 0; i < 10; i++と同じ意味になる。些細に見えるが、テストコードとベンチマークで可読性が目に見えて上がる。

// Go 1.22以前 — 反復ごとに同じiをキャプチャ
for i := range items {
    wg.Add(1)
    go func() {
        defer wg.Done()
        process(items[i]) // 危険: iは全ゴルーチンで共有
    }()
}

// Go 1.22以降 — 各反復で新しいi
for i := range items {
    wg.Add(1)
    go func() {
        defer wg.Done()
        process(items[i]) // 安全
    }()
}

// range over int (Go 1.22+)
for i := range 10 {
    fmt.Println(i) // 0..9
}

net/httpのServeMuxも1.22でメソッド別・パスパターンマッチングを正式サポートし始めた。mux.HandleFunc("GET /users/{id}", handler)でchiやginなしでも基本的なルーティングが可能になった。単純なAPIなら外部依存なしで出発できる余地ができた。

2章 · Go 1.23 (2024.8) — range over func、イテレータの正式入りt

2024年8月のGo 1.23のシグネチャ変更はrange over funcだ。ある関数がfunc(yield func(T) bool)の形なら、その関数自体をfor v := range fのように回せる。コレクションライブラリのAPIが統一されるという意味だ。

// Go 1.23+ イテレータパターン
func Filter[T any](s []T, pred func(T) bool) func(yield func(T) bool) {
    return func(yield func(T) bool) {
        for _, v := range s {
            if !pred(v) {
                continue
            }
            if !yield(v) {
                return
            }
        }
    }
}

// 使用
for v := range Filter(nums, func(n int) bool { return n%2 == 0 }) {
    fmt.Println(v)
}

標準ライブラリにiter、slices、mapsパッケージが満ちた。slices.All・maps.Keys・maps.Valuesがいまはすべてイテレータを返す。RustのIteratorトレイトやJavaScriptのgeneratorのように、コレクション処理の標準語彙ができたわけだ。

structsパッケージのHostLayout型はcgoやsyscallコードで構造体レイアウトを明示的に保証する。システムプログラミングで頻繁にぶつかるパディング問題を整理する道具だ。

互換性の約束のため、新機能はすべてオプトインだ。go.modにgo 1.23を書いたモジュールだけが新しい挙動を使う。これがGoの最大の資産だ — 16年前のコードもいまもビルドできる。

3章 · Go 1.24 (2025.2) — Genericsの成熟、Tool deps、Weak pointers、omitzero

Go 1.24が2025年2月に出た。Genericsを初めて導入した1.18以降、最も意味のあるリリースと評価される。中核の変更は4つ。

(1) Genericsの型エイリアス。1.24から型エイリアスに型パラメータを付けられる。type Set[T comparable] = map[T]struct{}のように。1.23以前はgeneric aliasを作れず、コードのあちこちにボイラープレートが溜まった。

(2) Toolディレクティブ。go.modにtoolディレクティブが追加された。これまでtools.goファイルに_インポートを書いてビルドツールをつなぎ止めていたトリックを終わらせる。

// Go 1.24 — go.mod
module example.com/myapp

go 1.24

require (
    github.com/spf13/cobra v1.10.0
)

tool (
    github.com/golangci/golangci-lint/v2/cmd/golangci-lint
    github.com/sqlc-dev/sqlc/cmd/sqlc
)

いまはgo tool golangci-lint runが動き、go installを別途しなくていい。CIパイプラインが綺麗になる。

(3) Weak pointers (weak.Pointer)。キャッシュ実装に大きな影響。大きな値をキャッシュしたいがメモリ圧迫が来たらGCが回収するに任せたいときに使う。JavaのWeakReferenceやRustのWeak<T>に似た概念。

import "weak"

type Cache struct {
    mu sync.Mutex
    m  map[string]weak.Pointer[Bitmap]
}

func (c *Cache) Get(key string) *Bitmap {
    c.mu.Lock()
    defer c.mu.Unlock()
    if wp, ok := c.m[key]; ok {
        if b := wp.Value(); b != nil {
            return b
        }
    }
    b := load(key)
    c.m[key] = weak.Make(b)
    return b
}

(4) omitzero JSONタグ。長く頭痛の種だった問題 — omitemptyはzero valueを空と見なす。すなわちintの0、boolのfalse、time.Timeのzeroがすべてシリアライズで落ちる。これは常に望む挙動ではない。1.24のomitzeroは正確にzeroのときだけ落とす。より精密。

type Event struct {
    Name     string    `json:"name"`
    Count    int       `json:"count,omitempty"`    // 0なら落ちる
    Active   bool      `json:"active,omitempty"`   // falseなら落ちる
    StartAt  time.Time `json:"start_at,omitzero"` // Zero timeのときだけ落ちる
}

このほかruntime/traceがより軽くなり、FIPS 140-3認証の暗号化モジュールが入り、crypto/mlkem(post-quantum KEM)が標準ライブラリに合流した。PQCがGoの標準ライブラリに入ったのが印象的だ。

1.24は「1.18のGenericsを本当に使えるものにしたバージョン」だ。1.18〜1.20は使い勝手の問題が多くてライブラリ作者しか使わなかった。1.24以降は一般のアプリケーションコードでもgenericsを気楽に使う。

4章 · ウェブフレームワーク — Gin / Echo / Fiber / Chi / Huma

2026年春、Goのウェブフレームワーク市場は「Gin優位 + 4つ巴」の構図だ。表はおおよその印象であって絶対シェアではない。

フレームワーク星哲学強み
Gin約84k速くて慣れている例・ブログ・ミドルウェアが最多
Echo約32k標準に近い綺麗なAPI、整理されたドキュメント
Fiber約36kExpressを真似たfasthttpベース、JS出身に親しみやすい
Chi約19knet/httpの薄いラッパー標準互換、小さくて堅い
Huma約3.5kOpenAPI優先スキーマからハンドラを生成

Gin — 市場で最も使われるフレームワーク。理由は単純。最初に検索したときに最も多くの答えが出てきて、最も多くのミドルウェアがある。短所はnet/httpパターンから少し外れて自前のgin.Contextを使うこと。2026年に新規プロジェクトを始めるなら、チームにGoに慣れている人が多くないときはGinが最も安全な選択。

// Gin
r := gin.Default()
r.GET("/users/:id", func(c *gin.Context) {
    id := c.Param("id")
    c.JSON(200, gin.H{"id": id})
})
r.Run(":8080")

Echo — Ginとほぼ同等の知名度。APIが少しだけ綺麗だという評価が多い。ミドルウェアの記述が直感的で、ドキュメントが整理されている。WebSocket・HTTP/2・gRPCサポートも自然。

// Echo
e := echo.New()
e.GET("/users/:id", func(c echo.Context) error {
    id := c.Param("id")
    return c.JSON(200, map[string]string{"id": id})
})
e.Logger.Fatal(e.Start(":8080"))

Fiber — Express.jsを真似たAPI。fasthttpベースなのでベンチマークで速い。だがfasthttpはnet/httpではないので一部の標準ミドルウェアが使えず、HTTP/2サポートが弱い。JS出身の開発者がGoに移るときに馴染みやすくて人気。

// Fiber
app := fiber.New()
app.Get("/users/:id", func(c *fiber.Ctx) error {
    return c.JSON(fiber.Map{"id": c.Params("id")})
})
app.Listen(":8080")

Chi — net/httpに薄く乗せたルーター。gorilla/mux時代の精神的後継者。小さく、標準互換で、ミドルウェアが軽くて強力。モノリスよりマイクロサービスに合う。Go 1.22 ServeMuxの登場後もChiが魅力的な理由は豊富なミドルウェアとsub-routerパターン。

// Chi
r := chi.NewRouter()
r.Use(middleware.Logger)
r.Get("/users/{id}", func(w http.ResponseWriter, r *http.Request) {
    id := chi.URLParam(r, "id")
    w.Write([]byte(id))
})
http.ListenAndServe(":8080", r)

Huma — OpenAPIを一級市民として扱うフレームワーク。ハンドラ関数の型とタグを見てOpenAPIスキーマを自動生成する。Chi・Gin・Echo・Fiberの上に乗せて使えるのが特異点。APIドキュメントを自動生成しながら検証・シリアライズ・ルーティングまで終わらせる。

// Huma
type GetUserInput struct {
    ID string `path:"id" doc:"User ID"`
}
type GetUserOutput struct {
    Body struct {
        ID   string `json:"id"`
        Name string `json:"name"`
    }
}

api := huma.New("My API", "1.0.0")
huma.Get(api, "/users/{id}", func(ctx context.Context, in *GetUserInput) (*GetUserOutput, error) {
    out := &GetUserOutput{}
    out.Body.ID = in.ID
    out.Body.Name = "Alice"
    return out, nil
})

何を選ぶか — 新規チームでGoに慣れた人が少なければGin。綺麗さが欲しければEcho。JS出身が多ければFiber(ただし標準ミドルウェアの制約を知った上で)。標準に近く行きたければChi。APIスキーマ優先ならHuma。

5章 · データベース — sqlc / ent / GORM / Bun

データベースツールの選択はGoチームの二番目に大きな論争だ。4つの道がある。

sqlc — クエリからコード生成 SQLを直接書く。するとsqlcがそのSQLを読んで型安全なGo関数を自動生成する。ORMではない。「SQL優先」アプローチ。

-- queries/users.sql
-- name: GetUser :one
SELECT id, name, email FROM users WHERE id = $1;

-- name: ListUsers :many
SELECT id, name, email FROM users ORDER BY id;

これでsqlcは次のように生成する。

// 生成されたコード
type GetUserRow struct {
    ID    int64
    Name  string
    Email string
}

func (q *Queries) GetUser(ctx context.Context, id int64) (GetUserRow, error) {
    row := q.db.QueryRowContext(ctx, getUser, id)
    var i GetUserRow
    err := row.Scan(&i.ID, &i.Name, &i.Email)
    return i, err
}

SQLをそのまま保存し、型安全性はcodegenで確保。マイグレーションがSQLそのままなのでDBAが読みやすい。短所は動的クエリが面倒なこと — 条件が多くつく検索画面に弱い。

ent — スキーマ優先ORM (Meta) Facebook(現Meta)が作ったグラフベースORM。Goコードでスキーマを宣言すると、entがマイグレーション・クエリビルダー・関係ロードコードを生成する。

// schema/user.go
func (User) Fields() []ent.Field {
    return []ent.Field{
        field.String("name"),
        field.String("email").Unique(),
    }
}

func (User) Edges() []ent.Edge {
    return []ent.Edge{
        edge.To("posts", Post.Type),
    }
}

// 使用
user, err := client.User.
    Create().
    SetName("Alice").
    SetEmail("alice@example.com").
    Save(ctx)

posts, err := user.QueryPosts().All(ctx)

生成されたAPIが非常に型安全。複雑な関係が多いドメインに強い。学習曲線がsqlcより急。

GORM — 最も使われるORM RailsのActiveRecordの影響を受けた動的ORM。最も多くの例とチュートリアルがある。だが性能オーバーヘッドとマジックが短所。

type User struct {
    gorm.Model
    Name  string
    Email string `gorm:"unique"`
}

db.AutoMigrate(&User{})
db.Create(&User{Name: "Alice", Email: "alice@example.com"})
var user User
db.First(&user, 1)

素早いプロトタイピングにはいい。大きなトラフィックが流れるプロダクションではsqlcやentに移すチームが多い。

Bun — クエリビルダー go-pgの後継。SQLに近いクエリビルダー。ORMではなくビルダーなので明示性が高い。

err := db.NewSelect().
    Model(&users).
    Where("active = ?", true).
    OrderExpr("id ASC").
    Limit(10).
    Scan(ctx)

何を選ぶか — チームがSQLに長けてコントロールを望むならsqlc。グラフ型ドメイン(ソーシャル・マルチテナントSaaS)ならent。素早いプロトタイプならGORM。SQLに近いがビルダーパターンを好むならBun。2026年のトレンドはsqlcとentがGORMの席を侵食する流れ。

6章 · Encore — Go向けバックエンドプラットフォーム

Encoreは2024〜2025年にカテゴリを新しく定義した道具だ。「Go用バックエンドフレームワーク + クラウド配備 + インフラコード自動生成」を一気にやる。コードを見るとEncoreがどんな道具かが直感的にわかる。

//encore:service
type Service struct {
    db *sqldb.Database
}

func initService() (*Service, error) {
    db := sqldb.NewDatabase("users", sqldb.DatabaseConfig{
        Migrations: "./migrations",
    })
    return &Service{db: db}, nil
}

//encore:api public method=GET path=/users/:id
func (s *Service) GetUser(ctx context.Context, id string) (*User, error) {
    var u User
    err := s.db.QueryRow(ctx, "SELECT id, name FROM users WHERE id = $1", id).
        Scan(&u.ID, &u.Name)
    if err != nil {
        return nil, err
    }
    return &u, nil
}

//encore:apiコメント1行でAPIエンドポイントが定義される。Encore CLIはこのコメントを静的にパースしてOpenAPIスキーマ、クライアントSDK、トレーシング設定、IAMルール、マイグレーションを自動生成する。encore runならローカルでPostgresとともに動く環境が自動で立ち上がる。encore deployならGCP/AWSに自前のインフラがデプロイされる。

利点は明白だ — バックエンドのセットアップ時間がほぼ0。マイクロサービス間呼び出しが型安全なRPC。トレーシング・ロギング・モニタリングがデフォルト。

短所も明白だ — Encoreは自前のランタイムを強制する。一般のGoプロジェクトと互換性はあるが、Encoreの外に出るには仕事が多い。そしてクラウドのlock-inがある程度ある。

Encoreは「Go版Vercel」に近い。小さなチーム・スタートアップに魅力的。大企業が自前のK8sに張り付いているなら負担だ。

7章 · Templ + htmx — JSなしフルスタック

2025年春、Goコミュニティで最も熱い組み合わせがTempl + htmxだ。意図は「JSビルドツールなしでもインタラクティブなウェブアプリ」。

Templは型安全なHTMLテンプレートエンジン。.templファイルを書いてtempl generateでGoコードを作る。静的解析が可能で、コンポーネントが関数。

// hello.templ
package main

templ Hello(name string) {
    <div class="greeting">
        <h1>Hello, { name }!</h1>
        <p>It is { time.Now().Format("2006-01-02") }</p>
    </div>
}

// 使用
func handler(w http.ResponseWriter, r *http.Request) {
    Hello("Alice").Render(r.Context(), w)
}

html/templateより安全で速く、IDEサポートがいい。

htmxはHTML属性でAJAX・WebSocket・SSEを扱うライブラリ。JS 13KB。中核アイデア — すべてのインタラクションをHTMLフラグメントのやりとりで表現する。

<button hx-post="/like/123" hx-swap="outerHTML">Like</button>

サーバーは/like/123へのPOSTを受け、新しいHTML片を返す。htmxがそれをDOMに差し込む。SPAの複雑さなしに部分更新を実現する。

Go + Templ + htmxスタックの意味は明確 — Reactを知らないバックエンドエンジニアがフルスタックを書ける。Webpackも、Viteも、NPMもなしに。短所は非常に複雑なインタラクション(リアルタイム協調エディタ、3Dレンダリング)には足りないこと。

// Echo + Templ + htmx
e := echo.New()
e.GET("/", func(c echo.Context) error {
    return Hello("World").Render(c.Request().Context(), c.Response())
})
e.POST("/like/:id", func(c echo.Context) error {
    id := c.Param("id")
    return LikeButton(id, true).Render(c.Request().Context(), c.Response())
})

2026年にサイドプロジェクトや社内adminを作るなら真剣に検討する価値がある組み合わせ。Hugo風サイト、SaaS admin、ブログビルダーがこのスタックで素早く作られる。

8章 · Charmbracelet — Bubble Tea / Lipgloss / GlamourのTUIルネサンス

Charmbraceletは2020年代中盤のターミナルUIルネサンスを牽引した会社だ。彼らのライブラリ群が事実上GoのTUIの標準になった。

Bubble Tea — Elmアーキテクチャをベースにしたフレームワーク。Model、Update、Viewの3つの関数で構成される。

type model struct {
    counter int
}

func (m model) Init() tea.Cmd {
    return nil
}

func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {
    case tea.KeyMsg:
        switch msg.String() {
        case "+":
            m.counter++
        case "-":
            m.counter--
        case "q":
            return m, tea.Quit
        }
    }
    return m, nil
}

func (m model) View() string {
    return fmt.Sprintf("Counter: %d\n[+/-] adjust, [q] quit\n", m.counter)
}

func main() {
    tea.NewProgram(model{}).Run()
}

状態変化が明確で、テスト可能で、コンポーネント合成が自然。GitHub CLI(gh)の一部のインタラクティブ画面、glow(マークダウンビューア)、lazygit系の道具がすべてBubble Teaの引力圏にある。

Lipgloss — CSSにインスパイアされたスタイルライブラリ。ボックスモデル、パディング、ボーダー、色。

style := lipgloss.NewStyle().
    Bold(true).
    Foreground(lipgloss.Color("#FAFAFA")).
    Background(lipgloss.Color("#7D56F4")).
    Padding(1, 2).
    Border(lipgloss.RoundedBorder())

fmt.Println(style.Render("Hello, World!"))

Glamour — ターミナルでマークダウンを綺麗にレンダリングするライブラリ。AI CLIツールがモデル応答を見せるときにほぼ標準で使う。

Wish — SSHサーバーをGoで作るライブラリ。ssh chess.example.comで接続するとチェスが指せるようなデモが可能。

Charmbraceletエコシステムは「ターミナルがまた楽しい」という情緒を作った。AI CLI時代にこのエコシステムの価値はさらに上がった。

9章 · Cobra — CLIの標準

GoでCLIを作るときの事実上の標準がCobraだ。Kubernetes・Hugo・Helm・GitHub CLIなどがすべてCobraベース。コマンド・サブコマンド・フラグ・自動補完を一貫した方法で扱う。

var rootCmd = &cobra.Command{
    Use:   "myapp",
    Short: "An example CLI",
}

var serveCmd = &cobra.Command{
    Use:   "serve",
    Short: "Run the server",
    Run: func(cmd *cobra.Command, args []string) {
        port, _ := cmd.Flags().GetInt("port")
        fmt.Printf("Serving on :%d\n", port)
    },
}

func init() {
    serveCmd.Flags().IntP("port", "p", 8080, "Port to listen on")
    rootCmd.AddCommand(serveCmd)
}

func main() {
    rootCmd.Execute()
}

姉妹ライブラリのViperは設定管理(env、JSON、YAML、TOML、etcd、Consul) — Cobraとともによく使われる。

代案としてurfave/cliがある。APIが少し違ってより簡潔だが、Cobraほど広範ではない。2026年の新規CLIはほぼ100%Cobraから始まる。

10章 · Wails — Go + Webviewデスクトップ

Electronの重さが負担に感じる人にとってWailsは魅力的な代案だ。Goがバックエンドを担当し、Webview(macOSのWebKit、WindowsのWebView2、LinuxのWebKitGTK)がフロントエンドを描く。結果バイナリはElectronよりはるかに小さい — 10MB台。

// app.go
type App struct {
    ctx context.Context
}

func (a *App) Greet(name string) string {
    return "Hello " + name
}

func main() {
    wails.Run(&options.App{
        Title:  "MyApp",
        Width:  1024,
        Height: 768,
        Bind:   []interface{}{&App{}},
    })
}

フロントエンドはReact・Vue・Svelte何でも使える。Go関数をJSから呼び出し可能。小さなデスクトップツール、Markdownエディタ、ローカルデータベースのGUI、ミニマルなIDEのような用途によく合う。

短所はOS別のWebviewの差。Safari・Chromium・Edgeの微妙なレンダリング差を気にする必要がある。それでもElectronの100MB+のChromiumを束ねなくていいのは大きな利得。

代案としてFyne(純Go GUI)がある。Webviewなしで直接描く。モバイルも一部サポート。だがデザインの自由度が低い。

11章 · golangci-lint v2 (2024) — 設定の書き直し

Goプロジェクトの基本リンターであるgolangci-lintが2024年にv2をリリースした。最大の変更は設定ファイルの書き直しだ。

v1は10年間積もったオプションが乱雑に積まれていた。v2は構造を綺麗に再定義した。

# .golangci.yml — v2
version: "2"

run:
  timeout: 5m
  go: "1.24"

linters:
  default: standard
  enable:
    - errcheck
    - govet
    - staticcheck
    - revive
    - gosec
    - bodyclose
    - errorlint
  disable:
    - lll

linters-settings:
  revive:
    rules:
      - name: exported
      - name: unused-parameter

formatters:
  enable:
    - gofumpt
    - goimports

default: standardでベストプラクティスの束を一度に有効化する。フォーマッタ(gofumpt・goimports)がリンターから分離された — 別カテゴリ。v1からv2へのマイグレーションはgolangci-lint migrateコマンドでほぼ自動。

CIでは次のパターンが標準だ。

# .github/workflows/lint.yml
name: lint
on: [push, pull_request]
jobs:
  golangci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-go@v6
        with:
          go-version: "1.24"
      - uses: golangci/golangci-lint-action@v7
        with:
          version: v2.0

Go 1.24のtoolディレクティブと組み合わせるとgo tool golangci-lint runだけで終わる。別途インストール不要。

12章 · Pulumi Go / gRPC-Go / Wasmtime-Go — その他の重要な道具

Pulumi Go — IaCを本物のプログラミング言語で書く道具。TerraformがHCLという自前のDSLを使う反面、PulumiはTypeScript・Python・Go・C#で書く。Goユーザーに魅力的なのは型安全性と標準のツールチェーン。

// main.go
func main() {
    pulumi.Run(func(ctx *pulumi.Context) error {
        bucket, err := s3.NewBucket(ctx, "my-bucket", &s3.BucketArgs{
            Acl: pulumi.String("private"),
        })
        if err != nil {
            return err
        }
        ctx.Export("bucketName", bucket.ID())
        return nil
    })
}

pulumi upならAWSにバケットができる。Terraformより学習曲線が急だが、大きなインフラを管理するときに抽象化の力が光る。

gRPC-Go — GoogleのRPCフレームワーク。proto3定義からGoコードを生成。マイクロサービス間呼び出しの標準。HTTP/2の上に多重化・ストリーミング・メタデータ。

// user.proto
service UserService {
    rpc GetUser(GetUserRequest) returns (GetUserResponse);
    rpc StreamEvents(EventRequest) returns (stream Event);
}

protocでGoコードを作り、サーバー・クライアントを埋める。Connect-Go(Buf社が作った)がgRPCにHTTP互換性を加えた代案として浮上した。ブラウザからもそのまま呼び出せる。

Wasmtime-Go — Bytecode AllianceのWebAssemblyランタイムをGoから呼ぶ。ユーザーコードを隔離して動かすプラグインシステムが必要なときに有用。Envoy・Linkerdのようなプロキシで使うWASMフィルタパターンも増えた。

import "github.com/bytecodealliance/wasmtime-go/v22"

engine := wasmtime.NewEngine()
module, _ := wasmtime.NewModuleFromFile(engine, "hello.wasm")
store := wasmtime.NewStore(engine)
instance, _ := wasmtime.NewInstance(store, module, nil)
run := instance.GetExport(store, "run").Func()
result, _ := run.Call(store)
fmt.Println(result)

もう一つ触れる道具がNATS Goクライアントだ。NATSはGoで書かれた軽いメッセージング。Kafkaより軽くて運用が易しい。マイクロサービス間pub/sub・request/replyに魅力的。

13章 · 韓国 / 日本 — Toss / カカオ / メルカリ / サイバーエージェント / LINEヤフー

Toss(トス) 韓国でGoを最も積極的に使うフィンテック。マイクロサービス時代に移る過程で一部のサービスをGoで書いた。技術ブログ(toss.tech)にGo関連の記事が継続的に上がる — gRPCベースの社内通信、K8s上のGoワークロード、決済処理のレイテンシ最適化。Kotlin・JVMが依然メインだが、「超低遅延が必要なコア決済経路」にGoが埋め込まれたパターン。

カカオ (Kakao) カカオとカカオエンタープライズでGo採用が継続的に出る。社内クラウドコンポーネント、CI/CDツール、運用自動化にGoが多用される。K8s運用経験とGoがよくセットで採用される。

メルカリ (Mercari) 日本で最も有名なGo企業。マイクロサービスアーキテクチャがほぼGoで書かれている。メルカリエンジニアリングブログにGo関連記事が圧倒的に多い — gRPC、K8s、分散トレーシング、性能チューニング。社内に「Go委員会」のような組織があって標準を立てると知られている。

サイバーエージェント (CyberAgent) 日本の広告・ゲーム・メディア大企業。ABEMA・AmebaTV・ゲームバックエンドでGo使用。サイバーエージェントの子会社AbemaTVはライブ配信インフラにGoを広範囲に使う。Go Conference東京の常連スポンサー。

LINEヤフー (LINE Yahoo) LINEとヤフージャパンの合併で作られた巨大企業。LINE時代からGoを多用し、ヤフージャパンは一時Java中心だったがGoも増やした。合併後のインフラ統合過程でGoの役割がさらに大きくなったという報告。社内メッセージング・検索・広告バックエンドにGoコンポーネントが入っている。

東アジアの大手ビッグテックで共通したパターン — Goは「マイクロサービス + K8s + gRPC」束のデフォルト言語。Java/Kotlinと共存しつつ、「超低遅延バックエンド」と「DevOps・プラットフォーム道具」で席を固めた。

14章 · 誰がGoを選ぶべきか — マイクロサービス / CLI / DevOps / システム

長い記事の最後に短い意思決定フレームを置く。

Goが合うケース。

  1. マイクロサービスバックエンド — 速いビルド、小さなバイナリ、明確な並行性。gRPCと組み合わせれば標準アーキテクチャ。
  2. CLI / DevOps道具 — 静的バイナリ1つで配布終わり。Kubernetes・Terraform・Docker・Hugo・Cobraがすべて Goなのは偶然ではない。
  3. ネットワークプロキシ / インフラサービス — Caddy・Traefik・Envoy(C++)の席。並行性・メモリ効率。
  4. データパイプラインの中核コンポーネント — Vector・Bento・NATS。Rustほど速くないが十分速くて学びやすい。
  5. JSなしフルスタック社内道具 — Templ + htmxスタック。
  6. ターミナル道具 — Bubble Teaエコシステム。

Goが合わないケース。

  1. データサイエンス / MLモデル学習 — Python・Juliaが圧倒。GoはML推論サーブに一部使われるだけ。
  2. システムプログラミングの最下層 — カーネル・組み込み・リアルタイム。Rust・Cの方が合う。GCのせい。
  3. 複雑なドメインモデル — 代数的データ型、パターンマッチング、sum typeが切実ならRust・Scala・Haskell・OCaml。
  4. 単純なスクリプト — コンパイル・ビルドサイクルが煩わしい。Python・Bash・JavaScriptが速い。
  5. 高性能ゲームエンジン — GCポーズが負担。

言語選択の意思決定ツリー。

  • 「マイクロサービスバックエンド?」→ Go
  • 「DevOpsツールを1バイナリで?」→ Go
  • 「型安全なORMが必要なSaaSバックエンド?」→ Go (ent) または TypeScript (Drizzle)
  • 「JSなし社内フルスタック?」→ Go + Templ + htmx
  • 「AIエージェントのハーネス?」→ Goは良い選択だが Python・TypeScriptも活発
  • 「リアルタイムゲームサーバー?」→ Rust・C++が優先、Goは次善
  • 「数値計算?」→ Python・Julia・Rust

Goの16歳は「退屈さが検証された」という意味だ。他の言語が新しい構文を毎年入れる間、Goは小さな改善だけを加えた結果、2026年には最も安定的で最も予測可能な選択肢になった。1.24のGenericsの成熟が最後の大きな変更になるだろうという観測が多い。その先は本当に「巨大な標準ライブラリと安定したツールチェーン」の時代だ。

15章 · 参考 / References

Discuss on Twitter • View on GitHub