こんにちは、Sreake事業部の岩塚(yura_builder)です。
2026年9月11日(金)に中野セントラルパークで開催されたGo Conference 2026に参加してきました。本記事では現地の様子や印象に残ったセッションについてご紹介します。
私自身、Sreakeの業務でGoを用いた開発に携わる機会が多く、日々の開発や技術選定に活かせる知見を得るために参加しました。
Go Conferenceとは
プログラミング言語「Go（Golang）」のユーザーやエンジニアを対象とした、国内最大規模のカンファレンスです。
Goエンジニアはもちろん、Goに関心を持つすべての人に向けて最新の知見や活用事例を共有する場となっており、技術セッションやワークショップに加え、企業スポンサーによるブース展示、オフラインならではの懇親会などが開催されます。
今年のプログラムでは、Goのランタイムから標準ライブラリ、テスト、可観測性まで幅広いセッションが並んでいました。
タイムテーブルの対象レベル（初心者〜上級者向け）と形式（Keynote / Long / Short）を見ながら、普段のアプリケーション開発業務との接点を踏まえて、聞きたいセッションを事前に選ぶことができました。
Keynote : Open Source, Open World
Kubernetes SIG Scheduling TL / Chairを務めるsanposhihoさんのキーノートから、Go Conference 2026はスタートしました。
本セッションでは、sanposhihoさんが5年間のOSS活動を通じて得たものや、活動を継続できた理由について語られました。
sanposhihoさんは、OSS活動によって得たものや活動を継続できた理由の一つとして、「仲間とのつながり」を挙げていました。
セッションを象徴していたのが、「Go Far, Go Together」というメッセージです。遠くまで進むためには、個人の技術力だけでなく、仲間とつながり、ともに活動を続けることが大切だという意味が込められているように感じました。AIがコードやさまざまなタスクを高速で処理する時代だからこそ、誰と何に取り組むのかを改めて考えさせてくれる、とても良いキーノートでした。
synctest時代のhttptest: Go 1.27で変わるHTTPサーバテストの裏側
LayerXのYoichiro ShimizuさんのセッションではGo 1.27で追加されたhttptest.NewTestServerでGoにおけるHTTPテストがどのように変化したのかをGoの内部実装を見ながら解説するセッションでした。
httptest.NewServerは実際にTCPコネクションを張って通信を行うため、synctestとは事実上併用できませんでした。
synctestは「バブル」という隔離実行環境で動いており、バブル内では独自の時間機構(fake clock)を持っており、「10分後にタイムアウトしたらPASS」のようなテストでも一瞬で終わらせることができます。
そこで問題なのは、このfake clockがいつ時間を進めるのかということです。
それは、バブル内のすべてのgoroutineが何もできない状態で止まった時です。例えば
- バブル内で作ったチャネルの送受信で停止
- time.Sleepで止まっている
などで、synctestはこの状態をdurably blockedと呼んでいます。
一方で、以下のような処理の待ち方はnon-durably blockedと呼ばれるものになります。
sync.Mutexのロック待ち- ネットワークI/Oの待ち
- システムコール
冒頭でも述べたとおり、httptest.NewServerはテスト用とはいえ、中身としては普通にHTTPサーバを立てており、ネットワークからリクエストが来るのを待ち続けます。そのため、ネットワークI/O待ちはnon-durably blockedとして扱われ、fake clockが期待どおりに進まない場合があります。その結果、テストが停止したり、想定した時刻に到達しなかったりする可能性があります。
Go 1.27で新たに追加されたhttptest.NewTestServerでは、OSのTCPソケットを使用しない、インメモリでバッファを経由してデータを擬似的に送受信するinternal/nettestを使用しています。
つまり、durably blocked と判定される操作だけで書かれているため、synctestと併用できるようになりました。
Goでアプリケーション開発をしている人にとって、非常に嬉しい機能だと思います。
私もGoでAPIを開発することが多いため、今後、タイムアウトやリトライなど時間経過を伴うHTTPテストでは、httptest.NewTestServerとsynctestを活用し、テストの高速化と安定化を図りたいと感じました。
標準パッケージに uuid が追加された背景から見る Go らしい意思決定
LayerXのconvtoさんのセッションでは、Go 1.27で追加されたuuidパッケージを通して、Goらしい意思決定や、広く使われるソフトウェアにおいてどのように判断がなされるのかが解説されました。
大前提として、広く使われるソフトウェアは、利用者が多いからこそ、数多くの依存関係を生みます。
Goには、Go 1で書かれたプログラムが将来のGo 1.xでも原則としてコンパイル・実行できることを目指す「Go 1互換性ポリシー」があります。
これは私たち利用者にとって大変嬉しい保証ですが、Goチームの立場では、十分に見合うリターンがなければ標準パッケージに追加しないという判断になるのも当然です。
uuidを標準パッケージに追加する提案は2018年ごろからありましたが、当時は判断材料が足りないという理由で却下されていました。エコシステムでの実績とuuid自体の仕様の成熟を理由にGo 1.27でようやく標準入りを果たしました。
標準入りするにあたって、設計の議論が様々な観点でなされており、一度公開したら簡単には変更できないという制約のもと設計がなされています。例えば、
- 生成API:
NewとNewV4は現状同じ挙動。それでも両方置くのは「versionを気にせず単にuuidが欲しい」ケースを意識してのこと。将来より良いデフォルトが出たらNewの挙動を変える余地も残す。 - 中身を覗けるべきか: version や timestamp の抽出APIは提供しない。「UUIDは不透明な値として扱うべき」という RFC の推奨に沿った判断。
Nil()とMax(): 当初は入れない意向（UUID{}で書けるため）。だがuuid.Nil()の方が意図が伝わるという議論があり、対称性のためuuid.Max()も含めて両方サポートする。
uuidという一見シンプルな機能に対して、広く使われるソフトウェアならではの制約を踏まえ、これだけ多くの設計判断や意思決定が重ねられていたことに驚きました。同時に、Goのシンプルで読みやすい言語仕様は、こうした慎重な意思決定のもとに生まれているのだと改めて実感しました。
また、私がほかのプログラムから利用されるソフトウェアを設計・実装する際にも、参考になる視点をこのセッションから得られました。規模はGoほど大きくないかもしれませんが、公開したAPIを簡単には変更できないことを前提に、必要最小限のインターフェースを提供することを意識したいと思いました。
標準ライブラリをどこまで信じるか — 900アプリを支えるプラットフォームへのファイルアップロード導入から学ぶ io・mime・multipart
株式会社ヤプリの坂本拓也さんのセッションでは、ファイルアップロード機能を新たに導入した実体験をもとに、標準ライブラリをどこまで信頼して技術選定を行うべきかが語られました。
ファイルアップロード機能を実装する際の論点として、メモリの逼迫、拡張子の偽装、HEICのようなOS固有のファイル形式などが紹介されました。そのうえで、各課題に対してどの標準パッケージを採用し、あるいは採用しなかったのかが解説されました。
例えば、Goのファイルアップロードでは、ParseMultipartForm(maxMemory)を使うことで、少ないコードで手軽に実装できます。
しかし、内部実装を見てみると、引数のmaxMemoryは受信サイズの上限ではなく、データをメモリ上に保持する上限です。上限を超えた部分は、os.CreateTempによって一時ファイルとしてディスクに書き込まれます。この仕様には、実行時間やディスク使用量の増加、OSに依存した失敗などのリスクがあります。そのため、MultipartReader()やNextPart()などを利用したストリーミング処理が選択されました。ほかにも、HEICへの対応や拡張子偽装へのセキュリティ対策について、使用するパッケージの検討過程が紹介されました。
標準ライブラリは非常に便利ですが、ビジネス要件や非機能要件、実行環境の制約によって、利用できる技術や最適なパッケージは変わります。そのことを改めて認識できました。
私自身、技術やライブラリを選定する機会が多いため、どのような観点を持ち、どこまで実装を確認して判断するべきかという点がとても参考になりました。GoはGo自身で実装されているため、各パッケージやランタイムの挙動を追いやすいのも良いところですよね！
おまけ
セッション以外にも、スポンサーブースや実際に手を動かすワークショップ、全セッション終了後には懇親会も開かれました！スポンサーブースでは様々な企業におけるGoの活用事例やAI活用事例などのお話を聞くことができました！
久しぶりのオフラインカンファレンスへの参加でした。会場の至るところで技術に関する会話が交わされており、飛び入りで会話に参加したり、たくさんの方と交流したりできました。会場の熱気を直接感じられるのは、やはりオフラインイベントの良いところだと改めて実感しました。
また、ランチセッションというものもあり、お昼時のセッションではお弁当が配られて食べながらトークを聞くことができました（とてもおいしかった！）
また、クロージングでは来年のGo Conference 2027の開催もアナウンスされ、とても嬉しかったです。詳しい日時や会場は随時公式Xで発表されるそうなので、今から待ち遠しいですね。
まとめ
Go Conference 2026では、セッションやスポンサーブース、参加者同士の交流を通じて、Goに関する最新の知見や各社の活用事例に触れることができました。
普段の業務では触れる機会の少ない領域の知見や考え方を得られたことで、エンジニアとしての視野が広がる1日になりました。今回得た知見を、今後のAPI開発や技術選定、ソフトウェア設計に活かしていきたいと思います。
Go Conference 2026を企画し、当日の円滑な運営を支えてくださったボランティア・運営スタッフのみなさま、本当にありがとうございました！