アンドパッドは Go Conference mini in Sendai 2026 を満喫してきました ! (gopher 会クイズの解説付き)

こんにちは、 id:sezemi です。 Go Conference mini in Sendai 2026 で Gyutan スポンサーを務めながら、肝心の牛タンをいつ食べられるのか、腐心していたのですが、一緒にいった小島さんから「たんや善治郎さんは普通に行列が出来てしまうけど、お弁当なら作りたてで美味しい」という hack を教えてもらったので、それに倣ってみると、とても美味しく堪能できました。仙台出張の思い出です。

さて、アンドパッドはその Go Conference mini in Sendai 2026 に協賛・ブース出展し、登壇者 2 名を含む、合計 4 名の Gopher がカンファレンスを満喫してきました。この記事では、ブース出展の模様、特にアンドパッド社内勉強会 "gopher 会" で扱ったテーマから出題した gopher 会クイズの解説と、満喫した模様をお伝えします。

Go Conference では初のブース出展 !

ブースにお越しいただいた方からも驚かれたのですが、実はアンドパッドは、mini を含めても Go Conference へのブース出展が今回初でした。そういった背景から、まずはご挨拶としてアンドパッドオリジナルの Gopher くんステッカーを用意しました。お渡しした皆さんから喜んでもらえたようで何よりでした。

アンドパッドさんのGopherくん、素敵。#sendaigo pic.twitter.com/PIMyD826jc
— はしもつ (@_hashimo2) 2026年2月20日

x.com

また、事前に予告していた "gopher 会クイズ" も来場目標としていた人数を大きく上回って挑戦してもらえました。クイズそのものはだいぶ難しかったのですが、事前にクイズ内容を公開したブログ記事を読んでいただいた運営の方が全問正解されていました。テストやクイズには予習が大事ですね。

予告したブログ
アンドパッドは Go Conference mini in Sendai 2026 に協賛・ブース出展し、 gopher 会クイズをやります ! - ANDPAD Tech Blog

gopher 会クイズ解説

gopher 会クイズの解答後に解説は掲載していたのですが、改めて、ここで全 3 問の出題内容と解答・解説を紹介します。なお、全問正解者は 2 名で、中央値は 1 問正解でした。

Q1. テストのコンテキスト

Go 1.24 で testing.T に Context() メソッドが追加されました。このコンテキストがキャンセルされる (Done になる) タイミングはいつ？

A テスト関数が終了し、 Cleanup 関数が実行される前
B テスト関数が終了し、 Cleanup 関数も含めて全て終わった後
C t.Fail() が呼ばれた瞬間
D go test -timeout の時間が来た時だけ

正解: A

解説: テスト関数本体が終わるとキャンセルされます。そのため、 t.Cleanup() 内で非同期処理の後始末をする際にこの Context を使うと、すでにキャンセル済みでエラーになる（ context.WithoutCancel が必要）という罠が話題になりました。一見不親切に見えますが、これは非同期で動いているテストリソースのgoroutineが完全に終了するのを、Cleanup 内で安全に待機できるようにするため、Cleanupの前にcontextをcancelしておく必要がある為です。もし、contextのcancelが Cleanup 関数の後に行われる仕様だった場合 Cleanup 内でgoroutineの終了を待とうとしても、終了のシグナルとなるcancelがまだ送られていないため、goroutineは動き続けてしまい、テストが永遠に終わらない（デッドロック状態になる）という問題が発生します。

正解率は 40.7% で、 B の選択肢を選んだ方が多かったです。

Q2. go fix の実行

次の Go プログラムに対し、以下のコマンドで go fix をデフォルト設定で実行しました。このとき、 実際にコードが書き換えられる箇所 は [1] ～ [5] のうちどれでしょうか？

package main

import (
    "fmt"
    "sync"
)

func process(data []float64, n int) {
    var wg sync.WaitGroup

    // [1] 3項のforループ
    for i := 0; i < n; i++ {
        // [2] ループ変数のキャプチャ防止
        i := i
        if i%2 == 0 {
            i++ // 偶数インデックスをスキップ
        }

        // [3] waitgroup: Go 1.25
        wg.Add(1)
        go func(i int) {
            defer wg.Done()
            fmt.Println(i)
        }(i)
    }
    wg.Wait()

    // [4] float64型の最小値判定
    var minVal float64
    _ = minVal
    a, b := 10.5, 20.3
    if a < b {
        minVal = a
    } else {
        minVal = b
    }

    // [5] []byteへの変換とSprintf
    _ = []byte(fmt.Sprintf("Result: %d", n))
}

A [1], [5] のみ
B [1], [2], [5] のみ
C [1], [2], [3], [5] のみ
D [1], [2], [3], [4], [5] すべて

(正解には影響しないものの、一部 [3] 付近のプログラムに誤りがあったため修正しました)

/* 訂正箇所
       wg.Go(func() {
           fmt.Println(i)
       })
*/
        go func(i int) {
            defer wg.Done()
            fmt.Println(i)
        }(i)

正解: A ([1], [5] のみ)

解説: 各箇所の判定理由は以下の通りです。

[1] 修正される (rangeint Analyzer)
理由: for i := 0; i < n; i++ は for i := range n に変換可能です。
for i := 0; i < n; i++ は通常 range ループへの変換候補ですが、ループ本体内で i++ とループ変数を変更しています。
ただし、直下の i := i は新しい変数の定義であり、ループカウンター自体の変更ではないため、阻害要因になりません。
適用条件である「ループ変数がループ内で変更されていないこと」を満たしています。
[2] 修正されない (forvar Analyzer)
理由: i := i は Go 1.22 以降不要なイディオムですが、 forvar アナライザのドキュメントには "This fix only applies to range loops" (この修正は range ループにのみ適用される) と明記されています。
解析時点では [1] はまだ「3項ループ ( C-style loop )」であるため、 forvar はこの行をスキップします。 [1] が修正された後にもう一度ツールを実行すれば修正されますが、 1 回の実行では修正されません。
[3] 修正されない (waitgroup Analyzer)
理由: Analyzer は wg.Add(1) と go func() { ... } の組み合わせを探して wg.Go に置換します。
このコードでは既に go func(i int) { ... } が使われており、 Analyzer が探している「置換対象の古いパターン」に一致しないため、何も行われません。
[4] 修正されない (minmax Analyzer) 理由: 変数 a, b は float64 型です。ドキュメントに "avoids making suggestions for floating-point types" (浮動小数点型については提案を行わない) とある通り、 NaN の挙動差異を避けるため対象外となります。
[5] 修正される (fmtappendf Analyzer)
理由: []byte(fmt.Sprintf(...)) は fmt.Appendf(nil, ...) に変換されます。これは制約に引っかからず適用されます。

この問題の正解率が 3.7% と一番難しい問題でした。一番選択されていた選択肢は B の [1], [2], [5] のみでした。

Q3. Type Constraints

Go 1.26 では、ジェネリクスの型制約 (Type Constraints) に関する制限が緩和されました。以下のコードのうち、 Go 1.25 以前ではコンパイルエラーだったが、Go 1.26 で有効になった定義 として正しいものはどれですか？

A type Node[T any] struct{ Next *Node[T] }
B type GraphNode[N GraphNode[N]] interface{ Edges() []N }
C type Cloneable[C any] interface{ Clone() Cloneable[C] }
D type Equatable[T interface{ Equal(T) bool }] interface{ Equal(T) bool }

正解: B

解説: Go 1.26 のリリースノートの "Changes to the language" セクションに、ジェネリック型がその型パラメータリスト内で自分自身を参照できるようになった（recursive type constraints）と記載があります。

go.dev

ここでは型パラメータリスト [N GraphNode[N]] の制約部分に、今定義している型 GraphNode そのものが使われています。これがリリースノートにある "The restriction that a generic type may not refer to itself in its type parameter list has been lifted" に該当するケースです。 Go 1.25 までは "invalid recursive type: GraphNode refers to itself" というエラーが出ていました。

go.dev

不正解の選択肢も解説します。

type Node[T any] struct{ Next *Node[T] }
これは構造体のフィールド内での再帰参照です。 Go 1.18 から有効です。
type Cloneable[C any] interface{ Clone() Cloneable[C] }
これはメソッドの戻り値の型として自分自身（ Cloneable[C] ）を使っています。型制約（ [C any] ）の部分で自分自身を参照しているわけではないため、 Go 1.18 から有効です。
type Equatable[T interface{ Equal(T) bool }] interface{ Equal(T) bool }
これは型パラメータ T を、その制約である匿名インターフェース interface{ Equal(T) bool } のメソッドシグネチャ内で使用しています。これは「型定義自体の再帰」ではなく「型パラメータの利用」であり、Go 1.18 から有効です。

こちらの正解率は比較的高く 53.7% でした。一番多かった選択肢も正解の B でした。

もう少し問題の難易度を下げて、もっと色々なノベルティをもらったほうが満足度が高かったと反省しています。次回の gopher 会クイズにご期待ください !

カンファレンス参加レポート

ここからは参加したアンドパッドの Gopher たちから思い思いにレポートします。

小島 (@replu5) より

セッション

聞いたセッションはどれも得られるものがあり、プロポーザルの選定をした運営さんの手腕を感じました。その中でも、特に印象に残ったセッションは下記の 3 つです。

nilとは何か〜interfaceの構造とnil!=nilから理解する〜 - Speaker Deck

typed nil の背景から入り、 nil の改善にむけた Go Team の挑戦の歴史が振り返られる、いいセッションでした。

「 nil の意味論を変える」アプローチと「 nil に触れる回数そのものを減らす」アプローチを分けていました。後者についてはそれぞれの提案や変更を知っていても 1 つの軸として「 nil に触れる回数そのものを減らす」として認識したことはなく、言われてみればたしかにそういう流れがありそうで、新しい視点を得ることができました。また、 1 つ 1 つの issue を単体で見ずに背景にある大きなテーマを想像しながら issue を見れる視点を身につけていきたいと思えるセッションでした。

この 2 つはどちらもコーディングエージェントの普及に伴って AI がコードを書くことが増えるなかで、品質保証をどうするかがテーマでした。それぞれ「テストをテストするミューテーションテスト」と「コードカバレッジを高めていく」という解決策を提案し、それを効率的に実現するためのツール・ライブラリを開発している、という内容でした。

どちらも既存のプロジェクトに導入することが可能なのでツールとしても興味深いのですが、印象に残っているのはどちらの発表でもいわゆる「黒魔術」と言われているテクニックを必要に迫られて使っていた点です。言語に対する深い理解が土台にあり、使いどころを見極めて適切なテクニックを使うことで課題を解決しており、エンジニアリングの面白さを感じさせてくれるセッションでした。

発表について

今回の登壇は今までアンドパッドの社員として登壇した中では、一番発表時間の枠に収めるのに苦労しました。その分、内容としてはそれなりに面白い内容を発表することができたと思っています。

発表後にアンドパッドブースや懇親会だったりで発表、聞きましたと声をかけてくれる人もいて話が弾んでよかったです。

カンファレンスに参加してみて

AI 関連・言語の深掘り・コミュニティの話など幅広いテーマがバランスよくあって非常に楽しめる、いいカンファレンスでした。

個人的には Go Conference 本体と比べ mini では参加者が少ないこともあり参加者同士の交流のハードルも低い気がしています。セッション間の隙間や小休憩の時間もほぼ誰かと話していた気がします (気づいたらセッションが始まっていて急いでセッション部屋に移動したりもしてました …) 。

また地域カンファレンスの醍醐味の 1 つである地元の旨いものも満喫しました。

3 次会は気づいたら 25 時半になっていたりと終電を気にしないでいい強みを活かした交流ができて最高でした。地域カンファレンスに参加する人は会場から徒歩圏内のホテル取るのおすすめです。

sunecosuri (@sunecosuri) より

セッション

"Go のこういうツールや機能を使って課題を解決したよ" といったプロダクト開発における現場目線のセッションや、言語や機能の仕様、思想について語るセッション、実際に初めて Go を触れてみたきっかけなどを話すセッションだったり採択された各セッション、どれもバラエティに富んでいました。
聴衆が被りにくいように考慮されているようなタイムテーブルで時間ギリギリまでどちらを聞くか悩みながら参加しました。
聴講した中で印象に残ったセッションは以下です。

静的解析からみるGoの過去と未来

Goという言語がなぜ支持されているのか、その理由の一端を「静的解析」という切り口で知ることができるセッションでした。
特に印象的だったのは、2018年の go/analysis の登場です。
それまで乱立していた静的解析ツール群が、パース・型チェックといった共通の処理と実行基盤（Driver）に分離されたことで、goplsのようなツールや強力なエコシステムとなるまでの経緯を深く理解できました。
また、動的ロード、パターンマッチングによって、簡単にLinterを作れる世界を目指していると今後についても触れられており、提供される予定となる機能について注視したいと思いました。

コンパイルのたびに出力が変わる!? ～protocプラグインをめぐるトラブルシュートとHyrum’s Lawの教訓～

ProtoBufという具体的な題材からトラブル解決のプロセスが論理的に整理されており、専門的な内容ながら図解や語り口が明快で、まるでミステリーを解き明かすような面白さがありました。現地では思わず笑ってしまう場面もあり、非常に引き込まれました。
特にHyrum's Lawを引用した「仕様化されていない挙動でも、観測可能であれば誰かが依存する」というリスクの指摘には、改めてハッとさせられました。不確実性を排除するための執念と、抽象的な法則を具体的な事象に落とし込んで解説する手腕が素晴らしく、深く印象に残るセッションでした。

発表について

私自身、Go コミュニティで初登壇ということで緊張もありましたが、プロダクト運用の現場で得た知見を共有させていただきました。発表後に、具体的にどのようにして go fix を2回実行するように運用に組み込んでいるかと関心を持って聞いてくれた方もいて、少しでも得られるものがあった人もいたようで嬉しかったです。

カンファレンスに参加してみて

私はこれまでフロントエンドをメインで開発していて、今回は縁あって Go コミュニティのカンファレンスに初めて参加、登壇させていただきました。言語仕様から運用プラクティスまで、Go 1.26を中心とした最新のGoについて直接肌で感じられたことは、今後のプロダクト開発において非常に価値のある経験となりました。非公式前夜祭から参加しましたが、終始ワイワイしていてとても良いコミュニティだなとしみじみ思いました。運営のみなさま、関わってくれた参加者の方々のおかげで素敵な時間を過ごせました。ありがとうございました！

bushiyama より

沢山聞きましたが、以下のトークが、よい学びになりました。

SECURE CYCLE 様スポンサーセッション

まさかの直前での内容差し替えの事態にも対応されていました。常に Output できるようにまとめておくことが大事ですね。

話された内容と、ほぼ同じことを業務でやったばかりだったので、初 Ask the Speaker ができました。

オブザーバビリティ駆動開発って実際どうなの？ - Speaker Deck

オブザーバビリティを意識せずに、なにげなくやっていましたが、発表を聞くことで深掘りするきっかけになりました。

Go パッケージのサプライチェーン攻撃を防ぐ CI を作ってみた #sendaigo - Speaker Deck

紹介された capslock が便利そうだったので、 CI に仕込んでみてもよさそうと思いました。

nilとは何か〜interfaceの構造とnil!=nilから理解する〜 - Speaker Deck

null も生まれようとしてたんですねえ... 。言語の話としてとても面白かったです。

また「問題の移動で終わる」判断など、プロダクト開発にも通ずるものを感じました。

カンファレンスに参加してみて

1 day イベントは初めての参加でしたが、芋煮や会場の雰囲気など、これに慣れると都内ではまた面食らうんだろうな、と感じるほど、よい空気でした。

コミュ障気味の自分でも、ブースのおかげもあって思ったより初対面の方とも交流できてよかったです。

当日早朝出発の日帰り参加＆お腹を壊していて体調が終わってました（ご当地グルメ食べられず … ）が、次回あるなら前夜祭なども積極的に参加していきたいなと思える、よい体験でした。

tomtwinkle (@tomtwinklestar) よりカンファレンスに参加してみて

懇親会から 2 次会まで参加してきました。

こうした懇親会では、ついいつものメンバーで固まってしまいがちですが、今回は思い切って初対面の方々にも声をかけてみました。結果として Go 言語のディープな話で大いに盛り上がることができ、一歩踏み出して本当に良かったです。

#golang_friends の輪も広げていきたいです。

続く 2 次会も非常に充実していました。特に、実行委員長の瀬上さん自作の「 Go カードゲーム」はとても楽しく、参加者同士の距離がさらに縮まりました。途中で Go とは全く関係のない「ランドルト環」やメガネ選びの話題に脱線する一幕もありましたが、それがまた普通に参考になって面白く、エンジニアの集まりならではの自由な雑談を堪能しました。

そして何より印象的だったのが、運営の皆さんのホスピタリティの高さです。実行委員長である瀬上さんご自身がキッチンカーに立ち、参加者に芋煮を振る舞ってくださる姿には本当に感動しました。