Go Conference 2026 参加記

はじめに

Go Conference 2026 に参加してきました！こういったテック系カンファレンスは初めてでしたが、自分のよく使うもののカンファレンスなだけあって、どのセッションも面白く聴かせてもらいました。

この記事では、とりあえず聴いたセッションの感想などをつらつらと書いていきます。(サブタイトル等は勝手に省略しています、ちょっと長い...) 後日アーカイブの公開等もあることでず。

スポンサー

僕の所属しているサークルがGo Conference 2026 のブロンズスポンサーになっていました。詳しくはサークルのブログで公開されているのでぜひ見てみてください:

traP は Go Conference 2026 に協賛します！

本記事はジョブボードに掲載する広告の代わりとして掲載しているものです！ SysAd 班班長の Takeno_hito と SysAd 班の ikura-hamu です。東京科学大学デジタル創作同好会 traP は Go Conference 2026 にブロンズスポンサーとして協賛いたします！本記事では協賛への思いなどを紹介させていただきます。協賛への思い本サークルは 2015 年に設立されたデジタル創作の総合サークルです。設立してからゲーム制作・イラスト・競技プログラミングなど様々な分野のメンバーが集まって進歩を続けており、現在のメンバー数は 812 名（2026/8/5時点）、11年間で traP に所属したことがあるメンバーの総数は 2509 名（2026/8/5時点）と、国内でも最大級のデジタル創作サークルとなりました。そんな本サークルでは、サークル内での内製の連絡ツール traQ を始めとした、メンバーを支える基盤システムの全てを 2017 年から現在に至るまで Go で開発しています。

https://trap.jp/post/2944/

僕は学生チケットで参加したので、そこで安くなった分をスポンサー金に充てよう、というノリで出資させてもらいました。会社名が連なってる中に大学のサークルが混ざってるのは何度見ても面白い、いいサークルです。

当日

ちゃんと起きるぞ、と朝7時に目覚ましをかけたんですが、見事に二度寝して最初のセッションをほとんど逃してしまいました...

最初のセッションなかなか気になっていただけに少し残念。悪いのは僕なんですが。

Twitterの投稿

Twitterで見る

Go Conference 受付前にあったパネル。札もあって色々な人が写真を撮っていました。夕方に僕もサークル周りの人と一緒に一枚撮りました。

海上で動くGoサーバー

セッション紹介

Go Conference 2026

海上で動くGoサーバー: goroutineとchannelでさばく航行データストリーム - タイムテーブル | Go Conference 2026

日本周辺では毎年1,700〜1,800隻規模の船舶事故が発生しており、その多くを小型船舶が占めています。事故を減らすには、操船者が周囲の船舶、位置、針路、速度、水深、風などを継続的に把握し、安全な航行判断につなげる仕組みが必要です。一方で、海上では通信が不安定で、クラウドや外部APIに常時頼れるとは限りません。このセッションでは、小型船舶や実験艇の船上で動くGoサーバーを想定し、船内や周囲から届く航行データをローカルで処理する設計と実装を紹介します。サーバーの入力として、AISとNMEA 0183を扱います。AISは、周囲の船舶がVHF帯の電波で送信する位置・針路・速度などの情報を受信する仕組みです。NMEA 0183は、GPS、電子コンパス、水深計、風向風速計などの船内機器が使うテキストベースの通信フォーマットです。これらをAIS受信機、シリアル接続、USB変換、複数の船内機器の信号をまとめる装置などを通じてGoサーバーへ取り込みます。これらのデータは形式、頻度、信頼度が異なり、値が古い、複数の情報源が矛盾する、といった状態も起こります。そのため、単に保存するだけではなく、欠損、遅延、古い情報、根拠含めて判断できる形に整える必要があります。 Goは、標準ライブラリによるI/O処理、goroutineとchannelによる並行処理、contextによる停止制御を組み合わせやすく、複数のリアルタイム入力を扱うローカルサーバーに向いています。AIS/NMEAのparser、複数入力をgoroutineとchannelでまとめる構成、最新状態の集約、古くなった情報の判定などをコードモ踏まえて説明します。この発表では、海事ドメインを題材にしながら、不完全でリアルタイムに流れ続けるデータをGoでどう受け、どう使い、どう繋げるかを扱います。IoT、設備監視など、複数の不完全な入力を扱うGoアプリケーションにも応用できる内容です。

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

先述の通り寝坊で途中からの聴講です。Room Bの方を見たかったんですが、立ち見でさえいっぱいだったのでこちらに来ました。応用系のお話で今回のセッションでは珍しい方で、面白かったです。

海上の航行を安全に行うために作成した、Go製の船舶位置情報管理システムのお話でした。

動画配信サーバーにおけるGC負荷低減の取り組み

セッション紹介

Go Conference 2026

株式会社ミラティブ: 動画配信サーバーにおけるGC負荷低減の取り組み - タイムテーブル | Go Conference 2026

動画配信サーバーでは、動画セグメントの処理ごとに、大きく短命なメモリ領域の高頻度な割り当てが発生します。こういったワークロードにおいて、Goランタイムからのメモリ割り当てではオブジェクト数とサイズが爆発し、GCのスキャンやGCアシストによる負荷が激増、結果的にスループットが低下します。上記の問題に対応するためにとっている、mmapによる手動メモリ管理の手法と類似する手法、それによるアプリケーションの性能向上について紹介いたします。

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

コンスタントに動き続ける必要がある動画配信ストリームで、GCによるSTWをいかに軽減させるか、というお話。 GCのSTWを避ける話はDiscordの方でも聞いたことがあります。もっともあちらはRustに移行することで解決していましたが。

配信サービスでは大きく短命なオブジェクトをよく使うためにGC負荷が高い、というのが主な原因らしい。そこで、メモリ割り当てをmakeからmmapを使った独自の実装に切り替えることで、GCの管理下からそれらを逃してしまえ、という発想。結果STWで起こる配信遅延のスパイクは軽減されたとのことです。

自分がよくやる巨大なjsonlの扱いとかでも役に立つかなぁと思ったんですが、どうやらスループットの改善はあまりないらしい。元の処理がCPU-BoundじゃないとGCがメインの処理を圧迫することもないためだそうです。 gzip圧縮されたファイルの読み書きはCPU-Boundなことを最近思い知っているので、そうなるとやっぱり試してみてもいいかもしれない？ OSSでパッケージがあるといいですね。後日探してみることにします。

GCのスパイクを気にするならDiscordよろしくRustでやってしまえばいいのでは、というのが正直なところですが、似た場面は動画配信に限らず多くあるでしょうし、Rust移行の一歩手前の策としては面白い対応だと思いました。 Goでもmmapってあって、しかもmmapってヒープでもスタックでもないんですね、そこが初耳だった。

Podは生きているのにGoだけが落ちる

セッション紹介

Go Conference 2026

株式会社エウレカ: Podは生きているのにGoだけが落ちる：GOGCとGOMEMLIMITで追うInvisible OOM Killの謎 - タイムテーブル | Go Conference 2026

【ショートセッション／中級者向け】我々が提供するペアーズの本番運用中のGo APIサーバーで、まれにtarget 5xxが発生しGoプロセスだけがpanic logなしに落ちる事象が続いていました。一方で、PodはOOMKilledにならず、同じコンテナ内のNginxは生き続けており、Kubernetes上の状態や通常のアプリケーションログだけでは原因を特定しづらい、いわゆる“Invisible OOM Kill”と呼べる状態でした。本セッションでは、この見えにくい障害を、Goランタイム・Kubernetes・コンテナ内の複数プロセスという複数のレイヤーから一つずつ紐解いていきます。なぜPodは生きているように見えたのか、なぜGoプロセスだけが落ちたのか、なぜメモリ使用量が少なく見えていたのにOOMが起きたのか。調査の過程で見えてきたGOGCとGOMEMLIMITの関係、Go以外のメモリを考慮した値決め、GCやレイテンシに与える影響について、実際のメトリクスと意思決定を交えて紹介します。最終的には、本番APIサーバーの安定性を高めながらmemory limitを8GBから3GBへ削減しました。その過程で得られた、Goアプリケーションをコンテナ環境で安全かつ効率的に動かすための監視・設定・ロールアウトの考え方を共有します。

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

コンテナで動かしていたGoアプリケーションがOOMで落ちて、尚且つコンテナは健康だしログはないしで奇妙な障害の対応のお話。

OOMに関する根本的な原因は、GoランタイムがGCを走らせる閾値よりも、コンテナがアプリを落とす閾値の方が低かったことが原因らしい。 Goの活用というより、実務でのトラブルを回避する方法という感じでした。なかなか気をつけないと同じような罠にハマりそうです。気をつけたいところ。

Go におけるコンソールゲーム開発最前線

セッション紹介

Go Conference 2026

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

# 概要 Go はサーバーサイドや CLI ツールで広く使われています。しかし、 Nintendo Switch や Xbox などのゲームコンソールには対応していません。そんな中、 Go の 2D ゲームエンジン「Ebitengine [1]」は Nintendo Switch 及び Xbox への対応を果たしました。 2026 年 5 月時点で、発売予定を含め 10 本以上のコンソールゲームに採用されています [2]。本セッションでは、本来非対応であるコンソール環境で、どのように Go ランタイムを動かしているのかを解説します。 Ebitengine の開発者であり、 Odencat 株式会社の CTO として実際にゲームをリリースし続けている立場から、その技術的な裏側と実装について詳しく説明します。 [1] https://ebitengine.org [2] https://ebitengine.org/ja/showcase.html # 主なトーク内容 * Go ランタイムの仕組みとコンソール対応の現実 * `-overlay` フラグを使ったシステムコールの書き換え * グラフィックスライブラリの対応 * プラットフォームごとの対応 * 開発からリリースまでの流れ * 今後の課題 # 対象聴衆 * Go のランタイムや低レイヤ、システムコールに関心がある方 * `-overlay` などのビルドオプションに興味がある方 * Go によるクロスプラットフォーム開発や、ゲーム開発の可能性を知りたい方

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

Goで作ったゲームエンジンを、Goが対応していないプラットフォーム(switchなど)で動かしたというお話。

まず、Ebitengineというフレームワークがあること自体初耳でした。そんな物好きがいたのか...

Goって標準ライブラリの上書きができるんですね。思えば「Goの標準ライブラリ」といって参照するものは形式的な関数宣言のようなものなので、コンパイル時に差し替える余地は確かにあるんでしょう。ただそれでも上書きできないものもあって、それを力技でUwagakiしてしまったという。

セッション全体を通して、秘伝のタレとか、力技とかかなり強引そうな部分がありました。その上にswitchで動く基盤があると思うと、恐ろしい執念です。

Goと一緒に育つCLI

セッション紹介

Go Conference 2026

Goと一緒に育つCLI — 9年のOSS保守で見た標準ライブラリとtestingの進化 - タイムテーブル | Go Conference 2026

標準入力を受け取り、チャットサービスへ通知する小さなGo製CLIを、約9年にわたって保守してきました。この発表では、そのCLIの実装と変更履歴を題材に、Go本体・標準ライブラリ・testingの進化が、小さなCLIの設計と保守をどのように変えてきたかを紹介します。初期の実装では、goroutine、channel、timer、signal handlingを手組みし、非同期処理のテストも `runtime.GOMAXPROCS(1)` や短い `time.Sleep` に頼っていました。また、ホームディレクトリ取得やエラーのwrapなど、今では標準ライブラリで自然に書ける処理にも外部パッケージを使っていました。そこから、`os.UserHomeDir`、Go 1.13のerror wrapping、`signal.NotifyContext`、`context.WithoutCancel`、`T.Setenv`、`T.Context()`、そして `testing/synctest` へと移り変わる中で、コードは少しずつ「外部依存や偶然に頼るもの」から「Goの標準機能で意図を表現できるもの」へ変わっていきました。特に中心に置くのは、非同期処理のテストです。かつてはruntime schedulerの挙動に依存していたテストが、`testing/synctest` によって、goroutineの停止状態を明示的に待てるテストへ変わった過程を、実際のコードの変遷をもとに紹介します。 Goの互換性と標準ライブラリの継続的な進化は、大きなプロダクトだけでなく、個人が長く保守する小さなCLIにも届いています。この発表では、ひとつのツールを9年保守してきた経験を通じて、Goと一緒に遠くまで進むとはどういうことかを具体的に示します。 ## 参加者が得られるもの * goroutine / channel / timerを含むCLI処理のテスト設計 * `runtime.GOMAXPROCS(1)` や `time.Sleep` に頼る非同期テストの問題点 * `testing/synctest` による非同期テストの改善例 * `signal.NotifyContext` を使ったCLI shutdown設計 * `context.WithoutCancel` を使うべき場面と、timeoutを戻す注意点 * `os.UserHomeDir` やGo 1.13 error wrappingなど、標準ライブラリの進化による外部依存削減 * `T.Setenv` / `T.TempDir` / `T.Context()` などによるテスト保守性の改善 * 小さなOSSや社内ツールを、Goの進化に合わせて長く保守していく考え方 ## 対象者 * GoでCLIや小さなツールを書いている人 * goroutine / channel / context を使った処理のテストに悩んだことがある人 * 社内ツールやOSSを長く保守している、またはこれから保守していきたい人 * Goの標準ライブラリやtestingの進化を、実例ベースで知りたい人 ## 対象レベル **中級者** goroutine、channel、context、testingの基本を知っていると理解しやすい内容です。ただし、個別のAPIは背景から説明するため、CLIやテスト改善に関心がある初級者にも役立つ構成にします。

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

標準出力をslackに流すCLIツールを保守しながら眺めてきた、Goの標準パッケージの紹介です。

後のセッションでも触れられましたが、Goの標準パッケージはかなり充実しています。このセッションではテスト用のパッケージを起点に、それらの紹介がされました。

goroutine同士が絡むテストを、現実の時間を待つようなflakyなものにする必要がなくなったのはありがたい。個人的には、synctestでSleepを仮想的にできる機能は好きです。あとはシグナルハンドリングをコンテキスト使ってかけるsignal.NotifyContextにもお世話になっています。

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

セッション紹介

Go Conference 2026

標準パッケージに uuid が追加された背景から見る Go らしい意思決定 - タイムテーブル | Go Conference 2026

Go 1.27 からは標準パッケージに uuid 実装が追加されることが予定されています。が、この uuid 実装の追加についてのプロポーザル自体は 2018 年ころから出ており、一度クローズされています。 https://github.com/golang/go/issues/23789 https://go.dev/doc/faq#x_in_std にもある通り、Go がある処理を標準パッケージとして実装するためには、それが標準パッケージたりうる理由を満たす必要があります。これらを説明しつつ、このプロポーザルがクローズされた理由に触れます。しかし Go 1.27 でリリース予定なことからわかる通り、その後別の uuid 実装のプロポーザルが再提案され、そちらは議論を経て accept されています。 https://github.com/golang/go/issues/62026 時を経てどのように状況が変化し標準パッケージで実装するに足る価値を示したのか、またどのような議論を経て accept され実装につながったのかを解説します。また、上記プロポーザルでは言及されていませんが、uuid に関するありがちな実装ミスとしては rand source の選択や利用方法の誤りがなど挙げられます。例えば著名なOSSである https://github.com/satori/go.uuid では過去に rand 処理の誤った利用に起因する CVE-2021-3538 が発生しました。この内容についても軽く触れ、セキュリティの目線でも標準ライブラリとして実装することの意義を補強することを試みます。実際に実装された処理群なども非常に Go らしい特徴を備えていて、主に uuid v4 および uuid v7 のサポートのみとなっています。これらについては実際の利用傾向などを踏まえてメンテ可能な必要最小限の仕様を実装するような議論がありました。関連する議論の流れやどのように意思決定したのかをご紹介できればと思います。総じて標準パッケージへの uuid の追加を例に取り上げながら、 Go が標準パッケージに価値ある処理群を実装していくための考え方などを紹介できればと思います。

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

Go1.27にはuuidパッケージが追加されたわけですが、それまでにどんな議論があったのか、というお話。

uuidに関しては Future さんのところの連載記事でも取り上げられていました。今回の内容ともかなり合致しています。ざっくり言えば、goはuuid標準パッケージの導入について具体的に必要になるものの構想がつくまではuuidを標準パッケージで提供することに渋っていた、というのが顛末です。

標準パッケージとするための用途収集のためにサードパーティのパッケージで動向を伺う、最終的なパッケージがある程度洗練された状態から始まる点では良いのですが、それまでに生まれる将来的に負債になりかねないコードが生まれてしまうのはちょっともやっとするところ。まぁそれよりも、実例よりは圧倒的に弱いissueの議論程度で導入されて、微妙なまま残ってしまうほうが嫌なんですけども。他の言語の用例を見たとしても文化が違うところであまり参考にならなさそう。トレードオフですね、難しいところです。

標準ライブラリをどこまで信じるか

セッション紹介

Go Conference 2026

標準ライブラリをどこまで信じるか — 900アプリを支えるプラットフォームへのファイルアップロード導入から学ぶ io・mime・multipart - タイムテーブル | Go Conference 2026

ユーザーが画像をアップロードできるようにする——ありふれた要件に見えて、いざ本番に載せようとすると不安は次々わいてきます。巨大なファイルでメモリは膨らまないか、拡張子を偽装されないか、見慣れない形式が来たら壊れないか。このセッションを通して伝えたいことは、こうした不安に対して「手軽な標準APIをそのまま信じるか、それとも一段下りて挙動を自分の目で確かめるか」をどう判断するか、という設計の勘所です。 io・mime・multipart の挙動を一つずつ読み解きながら、その判断の拠り所を一緒に考えていきます。題材は、900以上のアプリが同居するモバイルアプリ基盤に、ユーザーからのファイルアップロードを初めて導入した実装です。一つの実装をすべてのアプリが共有するため、どれか一つの考慮事項を見逃しても影響は全アプリに波及するため、その対応は自ずと慎重にならざるを得ません。ただ、扱う課題の多くはファイルアップロードを書いたことのあるGoエンジニアなら出会うものです。実装で向き合った勘所のうち3つを、要点を抜き出したサンプルコードを交えて共有します。 1. r.ParseMultipartForm() に丸投げしてよいか — メモリと向き合うストリーミング処理 ParseMultipartForm() は手軽で、多くのユースケースでは妥当な選択肢です。一方でリクエスト全体をメモリ／一時ファイルに展開するため、不特定多数からのファイルを受ける今回の要件では別の手段を選びました。代わりとして採用した、パートを1つずつストリーミング処理し、io.EOF を検知する前にサイズを累積チェックして上限超過を即座に弾く実装を紹介します。 2. ファイルの拡張子を信じてよいか — content sniffing による MIME 判定ファイル名の拡張子は攻撃者が自由に詐称できます。先頭512バイトのバイナリから実際の中身を判定する content sniffing（mimetype.Detect）の実装と、io.LimitReader での先頭読み出し、検証後に Seek(0, io.SeekStart) で位置を巻き戻す副作用の管理などを解説します。また、おまけ要素として拡張子を偽装したファイルをテストでどう弾いているかなども合わせて示します。 3. mime はどこまで面倒を見てくれるのか — HEIC が教えてくれた OS 依存の設計多様なアプリのユーザーが集まるプラットフォームでは、iPhone から送られてくる HEIC/HEIF は「例外的な形式」ではなく、日常的に受け止めなければならない入力です。ところが、この iPhone 標準フォーマットは Go 標準 mime パッケージの組み込みテーブルには登録されていません。調査を進める中で分かったのは、mime.ExtensionsByType が不足分を OS 上の MIME データベース（/etc/mime.types など）から補う設計になっていることでした。そのため、実行環境によっては同じ MIME Type に対して拡張子を解決できたりできなかったりします。これは欠陥ではなく、mime パッケージがどのように MIME 情報を管理するかという設計によるものです。本セッションではソースコードを追いながら、mime がどこから MIME 情報を取得し、なぜ環境によって結果が変わるのかを確認します。また、900以上のアプリが利用する共通基盤において、このような環境依存性をどのように評価し、どのような選択肢を検討したのかについてもお話しします。以上三章構成で、io・mime・multipart というベーシックな標準パッケージの挙動を一つずつ確かめていくという地味で実直な積み重ねが、900以上のアプリを持つプラットフォームを支える堅牢なファイルアップロードの基盤になるというお話を持ってきました。ファイルのアップロードについてはあくまで一例にすぎず、いかなる実装においても同様かと思いますが、便利な標準パッケージの関数やメソッドをそのまま信じるて使う前にその挙動を自分の手で確かめてみる姿勢によって、コードの品質が劇的に向上するかもしれません。このセッションが、あなたの次の実装を一歩堅牢に、かつ高品質にするヒントになれば嬉しいです。

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

標準ライブラリが豊富とはいえ、そのすべてを何も考えずに使うには少し危険だよね、というお話。

3つの例で説明がされていて、特に一つ目の例はメモリパフォーマンスに大きくかかわってきます。フォームデータの受信で、データの受信が終わってからじゃないと処理が始まってくれない、というのは確かに困ることもありそう。

...ほかの2つ、標準ライブラリの啓蒙というよりもHIECフォーマットの悪口では..?

range over func 2年間の軌跡

セッション紹介

Go Conference 2026

range over func 2年間の軌跡 — Issue #56413 はGoのエコシステムをどう変えたか - タイムテーブル | Go Conference 2026

「コレクションを走査する」という、どのGoコードにも存在する処理。なのに、filepath.Walk・sync.Map.Range・flag.Visitはすべてシグネチャが異なります。なぜGoには長年、統一されたイテレーション方法がなかったのか。そして2022年にGitHubに立てられたDiscussion#56413から始まった議論が、Go 1.23の range over func として結実するまでに何が起きたのか。本セッションでは、IssueとPRの議論を丹念に追うことで見えてくる「設計の決断」と、リリースから2年間でGo本体・標準ライブラリ・OSSエコシステムが実際にどう変化したかを、Before/Afterのコードで具体的に示します。業務でまだ使えていない方にこそ聞いてほしいセッションです。変化の全体像を知ることで、「自分のコードのどこに使えるか」が見えてくるはずです。【扱う内容】・Before: なぜ統一されたイテレーション方法がなかったか・設計の決断: なぜinterfaceではなく関数型になったのか・After(1): 標準ライブラリに加わったiter.Seq対応API ・After(2): OSSエコシステムの2年間の変化と現在地・実践: []T返しとiter.Seqの使い分け判断基準

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

iter.Seq の導入で見るGoのエコシステムの変遷のお話。

Goでイテレータというとgoroutineとチャネルを使った実装がぱっと思い浮かびますが、それだとbreakの処理に困るんですよね。開いたチャネルはいつ閉じるんですか？とかの問題が出ます。イテレータの導入を見越して変更になったパッケージのAPIがあったらしい、なかなかに大きい変更なんですね、イテレータ。

こういう次バージョン・将来を見越して一旦保留にしたり変更したりする機能ってありますね。 json/v2のformatタグとかもそう。typed struct tags を見越してformatタグが簡略化されています。

この format タグはGo1.27の標準APIからは外れます（#79071）。Go言語自体にtyped struct tagsを導入する提案（#74472）を見越し、パッケージ内に専用のDSLを持たせない方針への転換です。

フューチャー技術ブログ
Go1.27リリース連載：encoding/json/v2 | フューチャー技術ブログ
Go1.27で新たに利用可能になる encoding/json/v2 を取り上げます。
https://future-architect.github.io/articles/20260731a/