.jpeg){kind=small}
Share
Embed
Slide 1
Slide 1 text
go directiveを
最新にしすぎないでほしい話
id:arthur-1 株式会社はてな
2026-02-25 Go 1.26 リリースパーティ
Slide 2
Slide 2 text
Arthurと申します
株式会社はてな Mackerel開発チーム
サブディレクター・テックリード
𝕏: @Arthur1__
好きなGoの公式パッケージは
net/http/httptest
2
Slide 3
Slide 3 text
Mackerel: an Observability Platform
3
Slide 4
Slide 4 text
MackerelではGoを使ってます
● 時系列データベースや外形監視クローラーなど
のサブシステムの実装
● Go製のOSSの提供
○ 監視エージェントやプラグインといったバイナリ
○ APIクライアントといったライブラリ
4
Slide 5
Slide 5 text
MackerelではGoを使ってます
● 時系列データベースや外形監視クローラーなど
のサブシステムの実装
● Go製のOSSの提供 ←今日の話題
○ 監視エージェントやプラグインといったバイナリ
○ APIクライアントといったライブラリ
5
Slide 6
Slide 6 text
Go 1.26リリース 🎊
6
Slide 7
Slide 7 text
最新は最高
Go 1.26で追加された機能を確認して、早速使いた
いですよね？
7
var answer *int
- answer = ptr.To(42)
+ answer = new(42)
- go 1.25.0
+ go 1.26.0
Slide 8
Slide 8 text
OSS開発者としての私の今の気持ち
まだ新しいnewを使うことはできないなあ……
でも、Go 1.25で新しく増えたtesting/synctest
packageが使えるようになった！嬉しい！！
8
Slide 9
Slide 9 text
問題
● なぜ私は、Go 1.26がリリースされたタイミング
で、半年遅れのGo 1.25のリリース内容に言及し
ているのか？
● なぜまだGo 1.26の新機能を使おうとしないの
か？
今日の発表を聞いたらわかるはず
9
Slide 10
Slide 10 text
ここでみなさんに質問
10
Slide 11
Slide 11 text
質問
あなたがメンテナンス/利用している、公開された
Goモジュールのgo directiveの値は？
11
A) 1.26.0 C) 1.25.0
B) 1.25.1~7 D) 1.25.0未満
Slide 12
Slide 12 text
質問
あなたがメンテナンス/利用している、公開された
Goモジュールのgo directiveの値は？
12
A) 1.26.0 C) 1.25.0
B) 1.25.1~7 D) 1.25.0未満
Slide 13
Slide 13 text
私の主張
13
Slide 14
Slide 14 text
go.modのgo directiveは
1つ前のメジャーリリースより
新しくしないでほしい
14
Slide 15
Slide 15 text
具体的にはどうなっていてほしいか
Go 1.26がリリースされた現時点で、go directive
の値は新しくても高々1.25.0であってほしい
15
A) 1.26.0 C) 1.25.0
B) 1.25.1~7 D) 1.25.0未満
Slide 16
Slide 16 text
具体的にはどうなっていてほしいか
Go 1.26がリリースされた現時点で、go directive
の値は新しくても高々1.25.0であってほしい
16
A) 1.26.0 C) 1.25.0
B) 1.25.1~7 D) 1.25.0未満
これだとどう困る？
Slide 17
Slide 17 text
go directive
> The go directive sets the minimum version
of Go required to use this module.
https://go.dev/ref/mod#go-mod-file-go
ビルドできる最小の言語バージョンを定義する
17
Slide 18
Slide 18 text
Goのリリースポリシー
> Each major Go release is supported until there
are two newer major releases.
https://go.dev/doc/devel/release#policy
サポート対象のメジャーリリースは2つ分
【例】現在なら1.25と1.26がサポート下
18
Slide 19
Slide 19 text
go directiveが新しすぎる弊害
go directiveを1.26.0にしてしまうと、そのモ
ジュールはGo 1.25.xではビルドできない
（まだGo公式でサポートされているものなのに）
19
Slide 20
Slide 20 text
OSSがサポートするGoバージョン
Goがサポートしている2つのメジャーバージョンを、
そのままOSSとしてのサポート対象にする事例はそこ
そこある：
> OpenTelemetry-Go ensures compatibility with the current
supported versions of the Go language
https://github.com/open-telemetry/opentelemetry-go/blob/
main/README.md#compatibility
20
Slide 21
Slide 21 text
依存するGo Modulesの影響を受ける
依存先のモジュールでgo directiveが1.26.0になって
いるなら、依存元でもgo directiveを1.26.0以上にし
なければならない：
21
go ≧ 1.26.0
go 1.24.0
go 1.26.0
my-library
some-3rd-party-library
another-3rd-party-library
require
Slide 22
Slide 22 text
ライブラリじゃないなら大丈夫？
モジュールは公開しているけれど、公開パッケージ
はmainだけで、関数や型は全てinternal配下に置い
ている
バイナリ提供が目的で、他のモジュールからimport
される利用を想定していないから、go directiveは
最新でOK！
22
Slide 23
Slide 23 text
ライブラリじゃないなら大丈夫？
モジュールは公開しているけれど、公開パッケージ
はmainだけで、関数や型は全てinternal配下に置い
ている
バイナリ提供が目的で、他のモジュールからimport
される利用を想定していないから、go directiveは
最新でOK！ →そうとも限らない！！！
23
Slide 24
Slide 24 text
依存するGo Toolsの影響を受ける
利用しているGo Toolでgo directiveが1.26.0になって
いるなら、そのモジュールのgo directiveを1.26.0以
上にしなければならない：
24
module my-library
go 1.26.0 // go >= 1.26.0
tool some-3rd-party-tool // go 1.26.0
Slide 25
Slide 25 text
具体的にはどうなっていてほしいか
Go 1.26がリリースされた現時点で、go directive
の値は新しくても高々1.25.0であってほしい
25
A) 1.26.0 C) 1.25.0
B) 1.25.1~7 D) 1.25.0未満
これだとどう困る？
Slide 26
Slide 26 text
なぜ1.25.XのXは0であってほしいか
特定のマイナーリリース以上に上げることを強制する
ことは難しい：
● バグが含まれている可能性がある
● セキュリティFIXにより挙動が変わる可能性がある
基本的には、ユーザーの必要に応じて古いマイナーリ
リースも選択できる余地を残したほうがいい
26
Slide 27
Slide 27 text
GoのProposalにも書かれている
「Proposal: all, x/build/cmd/relui: automate go directive
maintenance in golang.org/x repositories」より引用：
> Another option would be to always use the latest 1.(N-1).X,
updating all the x repos each time a new minor Go release
comes out. That forces everyone to update to that new minor
release in order to incorporate any new x repo changes, which
seems too aggressive.
https://go.googlesource.com/proposal/+/HEAD/design/69095-x-repo-co
ntinuous-go.md#why-not-bump-on-each-minor-release
27
Slide 28
Slide 28 text
1.(N-1).Xから1.(N-1).0に戻した事例
https://github.com/google/pprof/issues/983
28
Slide 29
Slide 29 text
go directiveを1.N-1.0
にする弊害と対応策
29
Slide 30
Slide 30 text
すぐに最新の言語機能を使えない
go 1.25.0と書いたままでは、そのモジュールでGo
1.26の新しい言語機能は利用できない
なぜなら、Go 1.25でビルドできないから
古いGoのバージョンもサポートしたいなら、これは諦
めるしかない
30
Slide 31
Slide 31 text
GitHub Actionsのsetup-goで困る？
GitHub Actionsのsetup-goで以下のようにgo.modの
go directiveを読ませてGoのバージョンを決めている
CIで使われるGoツールチェーンが古くなってしまう？
31
- uses: actions/setup-go@v6
with:
go-version-file: go.mod
Slide 32
Slide 32 text
setup-goでも困らない
setup-goのv6から、toolchain directiveも読んでGo
のバージョンを決定してくれるようになった
cf.) https://github.com/actions/setup-go/pull/460
go.modにtoolchain directiveも記述すればOK
32
go 1.25.0
toolchain go1.26.0
- uses: actions/setup-go@v6
with:
go-version-file: go.mod
Slide 33
Slide 33 text
ここまでのまとめ
OSSなど他人が使う可能性があるモジュールにおいて、
少なくともGo公式でサポートされている最新2つのメ
ジャーリリースはそのままサポートされていてほしい
Goでは前方/後方互換性を大事にする文化がありそう
そのために、go directiveを1.(N-1).0にしてほしい
（Nは最新のメジャーリリース番号）
33
Slide 34
Slide 34 text
今日のテーマ
34
Slide 35
Slide 35 text
Go 1.26リリース 🎊
35
Slide 36
Slide 36 text
この話題、Go 1.26に
関係ある？
36
Slide 37
Slide 37 text
あります！
37
Slide 38
Slide 38 text
go directiveを
最新にしすぎないでほしい話
──あるいは、Go 1.26からgo mod initで
作られるgo directiveの値が変わる話
id:arthur-1 株式会社はてな
2026-02-25 Go 1.26 リリースパーティ
Slide 39
Slide 39 text
Arthurと申します
株式会社はてな Mackerel開発チーム
サブディレクター・テックリード
𝕏: @Arthur1__
好きなGoの公式パッケージは
net/http/httptest
39
Slide 40
Slide 40 text
Go 1.26 Release Notesより
> go mod init now defaults to a lower go version in
new go.mod files. Running go mod init using a
toolchain of version 1.N.X will create a go.mod file
specifying the Go version go 1.(N-1).0.
https://go.dev/doc/go1.26#go-command
40
Slide 41
Slide 41 text
go mod initとは？
カレントディレクトリをルートとする新しいモジュール
を作るコマンド
具体的にはgo.modファイルを生成する
41
$ go mod init demo
go: creating new go.mod: module demo
$ ls
go.mod
Slide 42
Slide 42 text
元々の挙動
手元のGoのバージョンがそのままgo directiveに設定さ
れる：
42
$ GOTOOLCHAIN=go1.25.7 go mod init demo
go: creating new go.mod: module demo
$ grep go ./go.mod
go 1.25.7
Slide 43
Slide 43 text
Go 1.26以降の挙動
手元のGoのバージョンより1つ前のメジャーリリースの
バージョン※である1.(N-1).0が設定される：
43
$ GOTOOLCHAIN=go1.26.0 go mod init demo
go: creating new go.mod: module demo
$ grep go ./go.mod
go 1.25.0
※あくまでgo mod initを実行しているツールチェーンのバージョン基準。現時点でサポー
トされているバージョンを取りに行くとネットワーク接続が必要になってしまうから
Slide 44
Slide 44 text
なぜ変わったのか？
Goがサポートしているバージョンと互換性のあるモ
ジュールの作成を奨励するため
> This is intended to encourage the creation of
modules that are compatible with currently
supported versions of Go.
https://go.dev/doc/go1.26#go-command
44
Slide 45
Slide 45 text
実は賛否ある
この変更を元に戻そうとするProposalが出ている：
https://github.com/golang/go/issues/77653
45
Slide 46
Slide 46 text
議論が足りなかった？
go mod initのgo directiveの値を変更するIssue
https://github.com/golang/go/issues/74748 におい
て、「We will do this for Go 1.26.」とされるまでの
スレッド投稿数は計7件
一方、これを元に戻したいとするIssue
https://github.com/golang/go/issues/77653 のス
レッド投稿数は（本資料執筆時点で）計38件
46
Slide 47
Slide 47 text
In my opinion……
Goチームが「サポートされているメジャーリリースと互換性のあ
るモジュールにしたほうがいい」という指針を表明してくれたこ
とは嬉しい
go directiveが新しすぎて依存に困るケースが減ったらいいな
一方で、go mod initで生成されるgo directiveの値を変えるべき
だったかどうかはなんとも言えない
initしたあとgo directiveを変えてもいいので、レールとしては
中途半端。得られるメリットと比較して影響がでかそう
47
Slide 48
Slide 48 text
まとめ
48
Slide 49
Slide 49 text
まとめ
Go 1.26から、go mod initで作られるgo.modのgo
directiveの値が古くなり1.(N-1).0となった
現在GoがサポートしているGoのバージョンと互換性のある
モジュールの作成を推奨するための変更
公開モジュールを開発する人にとっては嬉しいが、そうでな
い人にとっては面倒でやや驚きのある挙動なため、リバート
されるかもしれない
49
Slide 50
Slide 50 text
おしまい
50