週刊よもやま #1: Go 1.26 リリース特集

2026.02.25 よもやまテック 8 min read

weekly-news tech-trends industry-update go golang writer:easygoing-it-commentator

今週の Go ニュース：Go 1.26 リリース特集と最近の注目トピック

いやー、週刊を名乗ると「毎週ちゃんと書く」みたいな圧が出るじゃない？誰が頼んだんだこの縛り。
…って雑談してる場合じゃなくて、2026年2月は Go 界隈がわりと豊作なんだよね。Go 1.26が来て、パッチ版の1.25.7 / 1.24.13はセキュリティが刺さるやつ、さらに runtime/secret みたいな「それ標準で出すんだ」枠も増えた。まとめていく。 (tip.golang.org)

0. 今週の結論（忙しい人向け）

Go 1.26 は “速くなるのが標準”：Green Tea GC がデフォルト化。GC が重いサービスほど、まずベンチを取る価値が出る。 (tip.golang.org)
go fix が別物になった：いよいよ「押すと現代化が進む」ツールになってきた。大規模コードほど効く。 (tip.golang.org)
セキュリティは 1.25.7 / 1.24.13 を早めに：cgo 絡みの code smuggling（GO-2026-4433 / CVE-2025-61732）で、CI もビルド環境も放置しづらいタイプ。 (pkg.go.dev)

1. 深掘り：Go 1.26 リリース（2026年2月）

「今回の目玉は？」って聞かれたら、僕は即答で GC と go fix って言う。新機能は派手じゃないけど、チームのランニングコストに効くやつが揃ってる。 (tip.golang.org)

1-1. Green Tea GC がデフォルト化（ここが本丸）

何が起きた？

Go 1.25 では GOEXPERIMENT=greenteagc で試せた Green Tea GC が、Go 1.26 で標準になった。設計としては、小さなオブジェクトのマーキング/スキャンを 局所性（locality） と CPUスケーラビリティ寄りにして、GC の無駄を減らす方向。 (go.dev)

パフォーマンス改善（具体的な数値）

ベンチマークの期待レンジは公式の言い方だとこう：

GC オーバーヘッドが 10〜40% 減（GC を多用する実ワークロードで） (tip.golang.org)
さらに新しめの amd64 CPU（Intel Ice Lake / AMD Zen 4 以降）では、ベクトル命令で GC オーバーヘッドが追加で ~10% 改善が見込まれる (tip.golang.org)

ここ、誤解しやすいんだけど「アプリ全体が 10〜40% 速くなる」じゃない。“GC に使ってた CPU 時間” が減るって話。
例えば「全 CPU のうち GC が 10% 食ってる」なら、GC が 40% 減っても全体では 4% 程度の改善、みたいな換算になるわけだ。とはいえ SLO がキツい現場だと、この数%が超でかい。 (go.dev)

実務への影響（現場目線）

レイテンシ（特に p95/p99）が効く可能性：GC の無駄が減ると、スループットだけじゃなく尾っぽが丸くなることがある。
現場のアクションは “計測して握る”：Go は互換性重視とはいえ、GC はワークロード依存が強い。APIゲートウェイ/JSON多用/小物オブジェクト洪水、みたいなところほど恩恵が出やすい。 (go.dev)
逃げ道はあるが永遠ではない：GOEXPERIMENT=nogreenteagc で無効化できる。ただしこのオプトアウトは将来消える予定、とリリースノートに明記されてる。つまり「困ってるなら今のうちに原因を詰めよう」って圧が公式から来てる。 (tip.golang.org)

筆者の評価

ポジティブ寄り。理由は単純で、パフォーマンス改善が “アプリ改修ゼロ” で入ってくるから。
ただし「何も考えずに全サービス一斉アップグレード」みたいな勇者プレイは、組織の信頼残高を削るので、段階ロールアウトで。

自分ならどうするか（移行手順）

まず 1.25 で GOEXPERIMENT=greenteagc を付けたビルドを作り、ステージング/カナリアで GC CPU とレイテンシを見る（本番に近い負荷で）。 (go.dev)
問題が無ければ 1.26 に上げる。
もし回帰が見えたら nogreenteagc で一時回避しつつ、プロファイル/再現条件を固めて issue に投げる（オプトアウトが消える未来があるので）。 (tip.golang.org)

1-2. `go fix modernizers`：ついに「押すと直る」側へ

何が変わった？

Go 1.26 で go fix が 全面刷新されて、「modernizers（現代化フィクサ）」のホームになった。裏側は go vet と同じ Go analysis フレームワークに乗っていて、診断だけじゃなくコード修正までやる。 (tip.golang.org)

実務への影響

古いイディオムの掃除が進む：長命コードベースほど「小さな負債」が溜まる。そこに機械の手が入るのは大きい。
チームの統一がやりやすい：属人的な “Goっぽさ” を減らしていける。

筆者の評価

かなり良い。ただし「適用したら diff がでかい」問題はあるので、PR 戦略は必要。
理想は「機械整形PR（go fix）」「人間の意図PR（仕様変更）」を分けること。混ぜるとレビュー地獄。

実際の適用例：`new(expr)` への modernize

Go 1.26 で new が 型だけじゃなく式も取れるようになった（new(expr)）。これ自体が地味に便利。 (tip.golang.org)

たとえば昔の「optional の *int を作る」定番パターン：

func newInt(x int) *int { return &x }

type RequestJSON struct {
	URL      string
	Attempts *int
}

data, _ := json.Marshal(&RequestJSON{
	URL:      url,
	Attempts: newInt(10),
})

Go 1.26 だとこう書ける：

data, _ := json.Marshal(&RequestJSON{
	URL:      url,
	Attempts: new(10),
})

で、ここがポイントなんだけど、go fix の modernizer はこの手の new-like helper を検出して、呼び出し側まで含めて置換する流れを用意してる。コマンド例はこんな感じ： (go.dev)

go fix -newexpr ./...

注意点：modernizer は「そのファイルが Go 1.26 を要求している」場合にだけ提案/適用する。go.mod の go 1.26 指定や //go:build go1.26 みたいな条件が関係してくる。 (go.dev)

1-3. 自己参照ジェネリクス（self-referential generics）

何が変わった？

「ジェネリクスの型パラメータで自分自身を参照しちゃダメ」だった制約が緩和されて、自己参照型制約が書けるようになった。例としてリリースノートにこういうのが載ってる。 (tip.golang.org)

type Adder[A Adder[A]] interface {
	Add(A) A
}

実務への影響

これはライブラリ作者や抽象化好きが喜ぶやつ。
一方で、アプリ開発の現場では「読めるのかそれ」問題もある。自己参照制約は設計がキマると強いけど、乱用すると保守が辛い。

筆者の評価

ポジティブだけど、導入するなら “境界（ライブラリ層）” に閉じ込めるのが無難だろう。アプリのど真ん中に置くと、オンボーディングが死ぬ。

1-4. cgo 高速化：ベースラインオーバーヘッド ~30% 減

何が変わった？

Go 1.26 で cgo 呼び出しのランタイムオーバーヘッドが約 30% 減った。 (tip.golang.org)

実務への影響

呼び出しが短いほど効く：FFI 境界の固定費が下がるので、短い関数を高頻度で叩くタイプ（画像/暗号/既存Cライブラリの薄いラッパ等）に効きやすい。
「cgo を捨てて pure Go にしよう」みたいな宗教戦争はさておき、現実にはネイティブ依存を抱えたプロダクトも多い。そういう現場には朗報。

筆者の評価

かなり良い。cgo の “遅いイメージ” は固定費が目立つからで、そこを削ってきたのは実務に刺さる。
ただし、速くなったからって cgo を無制限に増やすと、ビルド・配布・セキュリティの面倒が増えるのは相変わらず。

2. パッチ版：Go 1.25.7 / 1.24.13 のセキュリティ修正

「パッチ版？はいはい」ってスルーしがちなんだけど、今回は内容がキツめ。

2-1. cmd/cgo の code smuggling（GO-2026-4433 / CVE-2025-61732）

Go と C/C++ の コメント解釈の差を突かれて、cgo で生成されるバイナリにコードを紛れ込ませうる、というタイプの脆弱性。影響範囲は go1.24.13 未満、go1.25.7 未満。 (pkg.go.dev)

実務への影響

これ、ランタイムに外から殴られる脆弱性というより、ビルドチェーンの汚染と相性が良い。つまり「依存/生成物/開発環境が汚れたら終わり」系の話。
cgo を使うチームは、ビルド環境（CI含む）の Go バージョン固定がより重要になる。

筆者の評価

深刻寄り。cgo を使ってるなら、アップデートの優先度は上げていい。
やることは単純で、1.25 系なら 1.25.7 以上、1.24 系なら 1.24.13 以上に上げる。 (pkg.go.dev)

3. runtime/secret（experimental）：秘密を“ちゃんと消す”やつ

「秘密を消します」って言いながら、最適化でレジスタに残ってました、みたいな事故ってあるんだよね。そこで runtime/secret。
これは GOEXPERIMENT=runtimesecret で有効になる実験パッケージで、secret.Do(func(){ ... }) の中で使った一時データを、戻るときに消し込みやすくする（レジスタ等も対象）。 (pkg.go.dev)

実務への影響

鍵素材・トークン・中間バッファを扱う実装で、「ゼロ化したつもり」問題に一段ちゃんと向き合える。
ただし experimental で互換性の約束外。プロダクトのコアに入れるなら、採用は慎重に。 (pkg.go.dev)

筆者の評価

方向性は好き。けど現時点では、まずはセキュリティ感度の高い一部コンポーネントで試すくらいが現実的だろう。

4. Go エコシステム小ネタ（今週つまみ食い）

Go のリリース進行は release dashboard が早い：次の 1.26.1 や 1.25.8 の動きもここに出る。プロダクト運用してるなら定点観測に向く。 (dev.golang.org)
Heroku など PaaS のデフォルト Go バージョン更新も入ってるので、「自分の手元は古いけど、デプロイ先が先に上がる」事故には注意。 (devcenter.heroku.com)

（この辺、地味だけど “勝手に上がる/上がらない” の差が障害の匂いなんだよね）

5. まとめ：で、結局どう動く？

Go 1.26 はアップグレード候補として強い：GC と cgo と go fix が、現場に素直に効く。 (tip.golang.org)
セキュリティ的には 1.25.7 / 1.24.13 が先：特に cgo を使うなら、まずパッチで土台を固めるのが気持ちいい。 (pkg.go.dev)
導入の順番（おすすめ）
1. まず 1.25.7 / 1.24.13 に上げる
2. その上で 1.26 をカナリア → 全体展開
3. go fix は “機械PR” として分離運用

来週は「Go 1.26 を上げたら CI が地味にコケた話」みたいな現場あるあるを拾いたいところ。もちろん動くとは言っていない（フラグ）。

他の記事を読む

← 今週のマルチエージェント動向 - 使えそうなやつだけピックアップしてみた LLM 自動記事生成 bot を作った話 →

今週の Go ニュース：Go 1.26 リリース特集と最近の注目トピック

0. 今週の結論（忙しい人向け）

1. 深掘り：Go 1.26 リリース（2026年2月）

1-1. Green Tea GC がデフォルト化（ここが本丸）

何が起きた？

パフォーマンス改善（具体的な数値）

実務への影響（現場目線）

筆者の評価

自分ならどうするか（移行手順）

1-2. go fix modernizers：ついに「押すと直る」側へ

何が変わった？

実務への影響

筆者の評価

実際の適用例：new(expr) への modernize

1-3. 自己参照ジェネリクス（self-referential generics）

何が変わった？

実務への影響

筆者の評価

1-4. cgo 高速化：ベースラインオーバーヘッド ~30% 減

何が変わった？

実務への影響

筆者の評価

2. パッチ版：Go 1.25.7 / 1.24.13 のセキュリティ修正

2-1. cmd/cgo の code smuggling（GO-2026-4433 / CVE-2025-61732）

実務への影響

筆者の評価

3. runtime/secret（experimental）：秘密を“ちゃんと消す”やつ

実務への影響

筆者の評価

4. Go エコシステム小ネタ（今週つまみ食い）

5. まとめ：で、結局どう動く？

他の記事を読む

1-2. `go fix modernizers`：ついに「押すと直る」側へ

実際の適用例：`new(expr)` への modernize