Go Conference 2026 に参加した

中野で開催。SRE Kaigi とかやってるところ。

go 使ってるので参加してみた。

会場の感想

いつもどおり使い易い。メインのルームが広いのと、sub room とワークショップもあって盛況。

スポンサーブースの紹介が中継であるなど、スポンサーを盛り上げる工夫もあった。去年はわりとスポンサーブースすいていたイメージだったが、今年は盛況。 絶妙にスポンサーブースが盛り上がりやすい配置だったと思う。スポンサーブースやってた元同僚は、ずっと人がスポンサーブースにいたからトーク聞きにいく暇がなかったと言っていた。

セッションの感想

Open Source, Open World

https://gocon.jp/2026/timetable/keynote/

Key note @sanposhiho

k8s やってる人。OSS 楽しいよー、っていうエモいトーク。

海上で動くGoサーバー: goroutineとchannelでさばく航行データストリーム

by Atsuki Seo

船で取れるセンサーのデータを集計して衝突検知とかするシステムを go で書いたという話。弓削商船の教員やってるという方。

データを streaming で扱うのに channel 使えるから go 便利だよー、という以上の技術的なトピックはなくて、普通に事例紹介という感じ。

golang は普通のウェブサービスの事例紹介とかだともはやトークとして新しみがないので、こういう事例が出るのかな? 適用範囲が広くて良いことですね。

エムスリー株式会社: 更なる可用性を求めて、5年間運用したKotlinのアプリケーションをGoでリプレイスする話

by 田口 健介

これは、kotlin 使ってサービスやってたけど暖気運転とかがめんどくさいから go にしたよって話。 

それもあるだろうが、、実は kotlin 流行ってないから辞めたいとか、spring boot の学習コストが高いから辞めたいとか、IDEA めんどくさいとか、そういうのも本音ではあるのかなぁ、と思ったけど、、 終始ポジティブな話にまとめていた印象。

ビルド速度が速くなって暖気運転いらなくなったから快適で良い、という話で、まぁそれはそうだよなぁ、と。

AI 時代なので、AI でやったら移植もそんなに大変じゃないよーっていう話もあったりで今ふう。

request を istio で mirroring して検証しながら移行を進めたとのこと。このへんはよくみる構成か。

Go におけるコンソールゲーム開発最前線 〜非対応環境でランタイムを動かす技術〜

by Hajime Hoshi

go で switch や xbox のゲームを開発するという話。ebitenjin。

最終的に C++ の compiler/linker を各社提供しているという前提があるっぽかった。

go を wasm target でビルドして、それを C++ に変換するという形で当初やっていたが、これだとビルドが遅いし GC かかるとプチフリしてしまうという問題があった。

そこで、今回は go の c-archive ターゲットで出すようにしたとのこと。c-archive ターゲットで出したものを普通にリンクすることによって、素直にビルドできるようになってビルド速度が向上したとのこと。

Goと一緒に育つCLI — 9年のOSS保守で見た標準ライブラリとtestingの進化

by catatsuy

もともと頑張って気合で書いてたようなコードが go 本体の進化によって良い感じにかけるようになっていったよー、っていう話。いい傾向だなぁ。

バージョンアップごとにあんだけ熱心にブログ記事書かれるプログラミング言語って今や少ないかも。

synctest時代のhttptest: Go 1.27で変わるHTTPサーバテストの裏側

by budougumi0617

いっこ前の catatsuy さんの話に近い内容ではあるが、もうちょい中身に踏み込んだ内容、という感じ。

標準パッケージに uuid が追加された背景から見る Go らしい意思決定

by convto

エモよりかな〜なんか実際どんなもんかなーと思ってたけど、思ったより uuid モジュールのどのメソッドがどういう経緯で入ったか入らなかったかを異常に詳しく issue 追ってるっぽくて良かった。

OpenTelemetry eBPF Instrumentationの舞台裏

by ymotongpoo

このトークを見た数人と懇親会で話したけど、「これは本番で使うのは気をつけた方が良いかもね」という感じ。

eBPF 使えばたしかにできるだろうけどやりすぎている感じがある。トランポリン挟んだり、レスポンスの byte 列を横から書き換えたりと危ないことを結構やっている。また、ライブラリの各バージョンごとの構造体のオフセットを JSON でデータで持っておいて、それを元に取得したりしている(これは DWARF つけてれば使われないらしいけど)。 moznion とかが言うところの「異常な努力」でできている感じ。

気軽にライブラリをバージョンアップしたら動かなくなるとかそういうリスクもありそうなので自分だったら SDK 計装とかコンパイラ計装を使うかな。

低レイヤーの話は好きなんで、話としては面白かった。

【ここからは懇親会で聞いた話】

ymotongpoo さん自身も「今は SDK 計装もコンパイル時計装もあるので、そっち使えるならそっち使った方がよい」とのこと。それはそう。

そのリトライ、死んだコネクションを使い回していませんか ── GoのHTTPクライアントとHTTP/2を実プロダクト障害から学び直す

https://gocon.jp/2026/timetable/1264230/

by Yusa Matsuda

HTTP/2 の PingTimeout/SendPingTimeout を AI の言う通りに雑に設定したら困ったよという話。

HTTP/2 だと PingTimeout/SendPingTimeout という値が設定可能。

    // SendPingTimeout is the timeout after which a health check using a ping
	// frame will be carried out if no frame is received on a connection.
	// If zero, no health check is performed.
	SendPingTimeout time.Duration

	// PingTimeout is the timeout after which a connection will be closed
	// if a response to a ping is not received.
	// If zero, a default of 15 seconds is used.
	PingTimeout time.Duration`

pooling された HTTP2 Connection の死活監視を行う機能ということになる。

この値を createHttpClient() のような関数で指定していた。両方 10 seconds.

さて、実際のクライアントの呼び出し側では context の timeout を 10 seconds として設定して呼び出していた。そこがエラーになるので retry 機構も用意したが、 retry してもよくなることがなかった。

PingTimeout=10sec は前回の request から 10sec ということなので、実質的に ping 機構が効いてないのが問題だった、という話だった。

そして教訓として、PingTimeout + SendPingTimeout < Request Timeout とすることが良いという話になっていた。一理あるけど ping まみれになってしまう気もする。

IdleConnTimeout を短くしちゃうというのも手かなという気はしつつ。コードの全体像が見えなかったのでなんとも。

これはシステムとして課金系ということだったと思うので、リクエストが断続的っていうところがそういう状況になった原因の一つかも。

このへんの設定として気をつけなきゃいけないこととしては、http.Client を作る createHttpClient というような共通メソッドを作ることは多々あると思うのだが、そこには実際の呼び出し時にどれぐらいの timeout が設定されるかというナレッジなしに AI は書くから妥当ではない値が設定されてしまうケースは多そうということ。コンテキストを意識する必要がある。

Published: 2026-09-14(Mon) 12:57