【Go Conference 2026】参加レポート

こんにちは、BBSakura Networksの篠田です。

9/11に開催されたGo Conference 2026に、普段からGo言語で開発をしているBBSakuraのエンジニア9名が参加しました！

今年度のGoConでは、BBSakuraは昨年に引き続きブロンズスポンサーをしており、早坂（@takemioIO）が「When Goroutines Are Not Enough: Runtime Locality in High-Throughput Go」というテーマで登壇しました。

BBSakuraは、明日から開催される「Go Conference 2026」にブロンズスポンサーとして協賛しています！ 当日は、メンバーが画像のTシャツを着て参加しました。 会場で見かけたら、ぜひ気軽に声をかけてください！ #BBSakura #gocon https://t.co/EfkccTqioJ

— BBSakura Networks, Inc. (@bbsakuranet) September 10, 2026

本ブログでも、BBSakuraの若手メンバーを中心に、セッションやワークショップでの学びや会場の様子をレポートします。

目次

• 印象に残ったセッション
• 印象に残ったワークショップ
• まとめ

印象に残ったセッション

When Goroutines Are Not Enough: Runtime Locality in High-Throughput Go

When Goroutines Are Not Enough: Runtime Locality in High-Throughput Goでは、高スループットなデータ処理におけるgoroutineへの仕事の分担方法と、性能が不足した際の調査・改善の進め方について紹介されました。

speakerdeck.com

まず、goroutineを用いたストリーム処理について、データの特性に応じて並列化の単位を決めるという基本的な設計の考え方が説明されました。 続いて自作のpacket capture tool「bpf-ninja」を題材に、具体的な性能調査と改善の過程が紹介されました。計測によってボトルネックを絞り込み、pprofなどの結果から仮説を立て、非同期プリエンプションやコピー処理、CPU配置などを一つずつ検証することで、スループットを0.54 Mppsから4.287 Mppsへと約8倍まで改善していきます。 最後はpacket captureでの知見をPrometheus Remote Writeなどのストリーム処理へ展開し、「仕事の分担」「受け渡し相手」「処理内容」「実行場所」という4つの観点から性能問題を切り分ける考え方へ一般化されていました。

個々のチューニングテクニックも興味深かったのですが、特に印象に残ったのは一般的な設計の考え方から入りeBPFによるpacket captureという具体例で計測・仮説・検証を行い、最後に再び一般的なストリーム処理へ落とし込むという発表全体の構成です。「まず観測し、仮説を立て、検証する」という性能改善の基本姿勢が一貫しており、低レイヤーな話題を扱いながらもとても理解しやすい発表でした。今後開発で性能問題に直面した際にも、この進め方を意識したいと思いました。（樂野）

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

本セッションについて、Go初心者の視点から、Webサーバーや非同期処理のテストを便利にする2つの仕組みと、最新バージョンでの進化をまとめてみます。私自身、普段はGoを使わない知識はほぼゼロの状態でセッションを聴いたのですが、まずGoには、テストを助けてくれる仕組みとして httptest と synctest というパッケージがあることを知りました。

httptest はHTTP通信のテストを行うためのツールで、単体テストコードが手軽に書けるのが特徴です。テスト用サーバーが裏側でノンブロッキング（メイン処理を止めない形）で起動するため、リクエストの送信テストをスムーズに行えて便利です。

一方の synctest は、時間や並行処理のテストを行うための仕組みです。テスト対象を「バブル」と呼ばれる独立した空間に入れて動かすのが特徴で、バブル内では時間が独立して流れており、処理が完全に停止した状態（durably blocked）を検知できます。

HTTP通信や非同期処理は他言語でも標準的にある仕組みですが、Goにおいてもバージョンが上がるにつれて、これらのテスト機能もより便利に使えるよう進化しています。synctest は Go 1.24 で導入され（Go 1.25で正式化）、テスト中の待ち時間を大幅に短縮できるようになりました。そして Go 1.27 からは NewTestServer が登場し、クライアント/サーバー間通信の擬似実現が可能になりました。これは実際のOSやネットワークを介するのではなく、サーバー側のメモリの中で通信を再現する仕組みです。そして、この NewTestServer と synctest は一緒に使うことで、 「本番と同じURLのまま、非同期なHTTP通信のテストが一瞬で終わる」という真価を発揮することが分かりました。

本セッションを通して、Go 1.27のアップデートにより、手軽でコントロールしやすいテスト実行が可能になったことが理解できました。テストをシンプルに扱えるような進歩は、Go初心者にとっても非常に頼もしい進化だと感じます。（光山）

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

多くのGopherが標準ライブラリにuuidパッケージ欲しいなと思いながら、google/uuidを使用していたことと思います。この発表では、Go 1.27でuuid実装が標準パッケージに追加された経緯や、標準パッケージはどういったポリシーで管理されているのかについて紹介されていました。 個人的な印象ですが、2024年にUUIDv7がRFC9562として標準化されて以降、2025年にPostgreSQL18でUUIDv7の生成関数がサポートされるなど、着実にUUIDv7が普及してきているように感じます。 uuidパッケージのAPIの中でちょっと面白いのが、NilとMaxを関数で実装しているところです。google/uuidではuuid.Nilという変数でNilを実装していたのに対し、標準ライブラリのuuidパッケージでは、Nil()関数が実装されました。 Ask the Speaker で@convto さんにお聞きしたところ、パッケージ変数にすると、勝手に書き換えられる可能性があるという議論があったという経緯を教えていただきました。constの機能が他言語よりも弱いGo側が悪いなと思いつつ、標準ライブラリの設計の意思決定に非常に興味を持つことができました。（石井）

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

Goでファイルアップロード機能を実装するにあたって、標準ライブラリをそのまま使うのではなく、実装や仕様まで掘り下げながら、一つひとつ挙動を確認していった発表でした。

特に印象に残ったのは、HEIC対応で標準ライブラリが期待した結果を返さなかった際に、単に別のライブラリに置き換えるのではなく、Goの実装まで読み進め、OSのMIME DBに依存しているところまで調査していた点です。

今はAIに聞くことで、実装方法だけでなく「ここが怪しそう」といった調査のヒントまで得られるようになっています。一方で、実際の挙動が本当に想定どおりなのかを疑い、自分で動かしながら地道に確認していく作業は、やはり必要なんだなと感じました。

自分は普段そこまで開発をすることがなく、コードを書くとしてもAIに頼れば十分な範囲であることが多いです。ただ、今後しっかり開発に関わる機会があれば、AIやライブラリの情報をそのまま信じるのではなく、挙動に疑問を持ち、必要に応じて実装を読んだり、実際に動かして確かめたりする姿勢を意識したいと思いました。（松下）

OpenTelemetry eBPF Instrumentationの舞台裏

「OpenTelemetry eBPF Instrumentationの舞台裏」を聞いてきました。 OBI（OpenTelemetry eBPF Instrumentation） は OpenTelemetry に寄贈されて生まれたツールで、アプリのコードを一切変えずに、カーネル側から eBPF で割り込んで HTTP や gRPC のトレースを取ります。

Go のスタックは動くので出口を取る定番の uretprobe を使うとアプリごと落ちる、Go 1.17 からレジスタ渡しになったので C の規約で読む汎用ツールは黙って別の値を返す、gRPC の内部フィールドの位置はバージョンごとに動くのにずれてもクラッシュせず「それらしく動く」、goroutine をまたぐと context.Context を追えない、という4つの難所が順に紹介され、どれも Go を速く書きやすくする設計の裏返しだと整理されていました。

私はeBPF に興味はあったものの触った経験がなく、この難所4つは会場で聞いている最中はほとんど追いきれませんでした。 冒頭に「uprobe を説明できるか」「Go の可動スタックを知っているか」といった会場アンケートがあったのですが、どの質問にもほとんど手が上がらず、私も同じでした。おかげで基礎ダイジェストから丁寧に始まったのはありがたかったです。それでも印象に残ったのは、defer があるとソース上の return は1つでも機械語の RET は2つになる、という実演です。自分の書いたコードがバイナリとしてどう見えているのかを、あまり意識してこなかったことに気づかされました。

山口さんは今回の内容を基礎から含めた解説本を Zenn で公開しているそうなので（zenn.dev/ymotongpoo/books/go-ebpf-primer）、そちらで補いつつ後で読んでみようと思います。（平山）

Go Context Wallなど

昨年のGoConではSwiss Tablesの仕組みやtesting/synctestなどGoの標準化機能を深掘りする登壇が多かった印象でした。一方、今年度はGoコミュニティでの機能が標準化されるまでの議論の過程や実務でのトラブルシューティングを扱うセッションが多かったように感じました。

聞いた中でもこれらのセッションが、コミュニティ活動や機能の標準化に触れていました。

• range over func 2年間の軌跡 — Issue #56413 はGoのエコシステムをどう変えたか

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

• Open Source, Open World

コミュニケーションスペースにもさまざまな企画が用意されていました。なかでも、Go Context Wallや各スポンサーブースで展示されているアンケートから、最近のGoの機能やトレンドを知れるのがとてもよかったです。

あとは、他の方の感想にもありましたが、最近だとhttptest.NewTestServer がとても便利とのこと。（外山）

Go Context Wall

印象に残ったワークショップ

TDDを通じてGoらしいテストを体験しよう！

「TDDを通じてGoらしいテストを体験しよう！」というワークショップに参加したので、その感想を書きます。

TDDでは、最初に実装をすべて考えるのではなく、まずTodoリストに全体像を書き出します。ただし、そこに書いたことは一旦忘れて、対応する項目を1つだけ選ぶのがポイントだと教わりました。そして、実現したい振る舞いをテストで定義し、まだ実装されていないためテストが失敗する状態（Red）を確認します。その後、最短の実装でテストを通し（Green）、最後にコードを整理する（Refactor）という流れです。Redは意図的にエラーを作ることが目的ではなく、テストによって仕様と実装の差分を確認するための段階です。

今回教わった流れを、FizzBuzzを例に図にまとめました。（図はOpenAIの画像生成ツールを利用して作成）

Test-Driven DevelopmentとTable-Driven Testsのイメージ

これまでテストは実装の後に書くことが多かったので、先にテストを書いてから実装するのが新鮮でした。テストを実行するとコードの動きがすぐに分かるので、楽しみながら取り組めたと思います。

題材も初学者が取り組みやすいシンプルなコードで、運営のみなさんのサポートも手厚かったです。参加者全員がいい感じに手を動かせていた印象でした。

2つ目の演習であるFizzBuzzの実装では、ペアプログラミングにも取り組みました。ペアプロは1台のマシン・1つのキーボードを共有し、「ドライバー」（実装する人）と「ナビゲーター」（一歩引いて設計や間違いに気づく人）を交代しながら進めるプラクティスです。ペアの方とキーボード配列などが違っていたため、ドライバーを交代するたびに少し戸惑わせてしまう場面もありましたが、TDDのサイクルを一人で回すのと違い、Redになった瞬間や実装方針をその場で相談しながら進められるのは新鮮で面白かったです。

また、FizzBuzzの実装ではテーブル駆動テストも体験しました。テーブル駆動テストは、入力値と期待値を表にまとめるための書き方です。ただ表に並べるだけではなく、「3の倍数ならFizzを返す」「5の倍数ならBuzzを返す」といった、確認したい振る舞いが分かる名前を付けて管理します。テストケースを追加しやすく、何を確認しているのかも分かりやすくなります。Goらしいテストの書き方を実際に試せたのもよかったです。

実際には、次のようにテストケースをスライスにまとめ、t.Runでケースごとにテストを実行します。

tests := []struct {
    name     string
    input    int
    expected string
}{
    {"3の倍数ならFizz", 3, "Fizz"},
    {"5の倍数ならBuzz", 5, "Buzz"},
    {"3と5の倍数ならFizzBuzz", 15, "FizzBuzz"},
    {"どちらの倍数でもなければ数字", 2, "2"},
}

for _, tt := range tests {
    t.Run(tt.name, func(t *testing.T) {
        got := fizzbuzz(tt.input)
        if got != tt.expected {
            t.Errorf("got %q, want %q", got, tt.expected)
        }
    })
}

TDDを実際に体験してみて、テストを先に書くことで実装のゴールが明確になり、小さな単位で動作を確認しながら進められることが分かりました。

楽しく参加できたので、今後の開発でも小さな機能からTDDを試してみたいと思います。（篠田）

TinyGoで遊んでみよう！TinyGo Keeb Workshop

本ワークショップでは、TinyGo（組み込み向けGo言語）を使って、キーボードや基板へのプログラム書き込みを体験しました。

会場では4種類のハードウェアから選ぶことができ、私は「zero-kb02」という小型キーボードを選択。具体的な導入や動かし方は、GitHubのREADMEを読みながら進めていきました。

zero-kb02

私自身、Goの知識はほぼゼロで、最初はパソコンに TinyGo をインストールする段階からうまく環境が整わず焦ってしまいました。ですが、スタッフの方がとても親切・丁寧に進め方を教えてくださり、つまずきを1つずつ解消して進めることができました。事前知識がない状態だったため、こうした手厚いサポートは本当にありがたかったです。

最終的には、無事に TinyGo を導入し、キーボードへ送るGoプログラムのコンパイルから接続・書き込みまでの一連の流れをやり切ることができました。

体験を通して感じたこと

• 画面上の処理だけでなく、キーボードという「ハードウェア」を通して自分の実装成果を確認できる体験がとても新鮮だった。
• TinyGoの知識がなくても、丁寧なサポートと用意された実行手順に沿って進めることで、組み込み開発を体験することができた。

最初は難しそうな印象でしたが、実際に自分の手で触って動かしてみると初心者でも楽しく学びきることができ、非常に貴重な体験となりました！（光山）

Let’s Play Go: The Card Game

本ワークショップで、Go言語をテーマにしたカードゲームを体験してきました。想像以上に白熱して楽しかったです！

ゲームは2〜4人対戦で、ツール・バグ・コードカードを駆使して全6枚の「機能カード」完成を目指す、ソフトウェア開発を再現したルールです。最終的にカードの獲得ポイントが最も高い人が勝者となります。会場では各テーブル4人で予選を行い、1位通過者による決勝戦が開催されました。優勝者には賞品としてこの「Goカードゲーム」が贈られるそうです（私は残念ながら予選敗退でした…）。

Goの詳しい知識がなくても気軽に遊べるうえ、コードカードを並べると実際のプログラムが完成する工夫がとても面白かったです。ゲームを通して参加者のGo経験レベルを問わず自然と会話が弾み、Go開発への良い入口になる素晴らしいツールだと感じました。

オンラインでも遊べるそうなので、気になる方はぜひプレイしてみてください！（光山）

Goカードゲーム 公式ガイドブック

まとめ

当日は700名を超えるGopherが集まり、セッションやスポンサーブース、ワークショップなど、さまざまな企画が行われていました。

セッションで新しい知識を得られたのはもちろん、ワークショップで実際に手を動かしたり、会場で他の参加者やスタッフの方と交流したりできたことで、Goをより身近に感じられる一日になりました。

今回学んだことを今後の開発にも活かしつつ、来年もまたGo Conferenceに参加したいと思います。