こんにちは!バックエンドエンジニアをしているもぎです。 「Go Conference 2025」に、弊社からバックエンドエンジニア3名が参加しました。この記事では、その参加レポートをお届けします。
イベントでは、普段の業務ではなかなか触れることのない書き方やアプローチを知ることができ、視野が広がる良い機会となりました。
また、多くの Go エンジニアと直接交流できたことで、改めてコミュニティの熱量を感じました。
弊社も今回、ブロンズスポンサーとして本イベントを応援させていただきました。
素晴らしいカンファレンスを運営してくださったスタッフ・登壇者の皆さまに、この場を借りて感謝いたします。
それでは、3人それぞれが参加して印象に残ったセッション・感想について紹介していきます。
山下(@pyama86)
こんにちは、カンファレンスにおける飲み会発生機ことP山です。今回は登壇がなかったため、純粋に参加者としてカンファレンスを楽しみました。 私からは2セッション紹介します。
encoding/json/v2で何が変わる? - v1からv2への変化を徹底比較
Ubie社のglassmonekeyさんによるセッションです。
encoding/json v1の問題点を踏まえ、v2での改善点を具体的に解説していただきました。話を聞く中で、v2にあげたいけど、それなりに破壊的変更がありそうだなぁと不安になっていたのですが、さすがのGoチーム、互換性を保つオプションを用意してくれていました。
https://x.com/pyama86/status/1971816796522230084
https://x.com/pyama86/status/1971821715216126469
またUbie社における移行検証についても紹介されており、即日対応できたとのことで、後方互換のオプションを入れると少ない工数で移行できて良さそうだなという印象を得ました。 ベンチマークの結果も概ねv2の方が高速で、メリットも大きそうです。
コード生成なしでモック処理を実現!ovechkin-dm/mockioで学ぶメタプログラミング
このセッションは聴講していなかったのですが、懇親会で皆さん話していたので資料を拝見しました。 今回会場提供をしてくださいった、CA社のkaramaruさんによるセッションです。
ポイントとしては下記です。
- Goのreflectパッケージは関数は動的に定義できるが、メソッドは動的に定義できない
- 引数、返り値はレジスタで管理されている、ただし配列などの引数はスタックで管理される
- メソッドのコール時に関数が呼び出されるようにメモリを書き換えて、メソッドの引数はスタックを遡って参照することで、メソッドの動的定義を実現している
このような実装でした、「お前は何を言っているんだ?」と思う方もいるかもしれませんが、私もそう思いました。
ただ私自身もovechkin-dm/go-dynoの実装を読んでみたのですが、資料で書かれているようなスタックを遡るような実装を理解できず、シンプルに呼び出しの規約に合わせてレシーバーとフレームポインタをセットしているように見えたのと、それを関数に渡すと余分な引数が2つあるので読み飛ばしてるだけのように見えたので、セッションを聞いておけばよかったと後悔しました。
ジェリー
こんにちは、バックエンドエンジニアのジェリーです。 二回目の参加となる Go Conference では、analysis パッケージの仕組みを活用したツール開発に関するセッションが特に印象に残りました。
[WorkShop] †開発を加速させる黒魔術講座†
初めてパソコンを持ち込んで、ワークショップ形式のセッションに参加しました。 前半は unsafe パッケージや go build の -overlay・-toolexec オプション、Goアセンブリ実装など、普段の業務では触れる機会の少ない内容を実例を交えて解説いただきました。 後半はグループごとにテーマを選び、実際に手を動かしてコードを書きながら理解を深める形式でした。
私が選んだ選んだテーマは「Go Suggested Fix ツールの作成」でした。
- Step 1: Inspector を使用したインターフェース型の検出
- Step 2: 空のインターフェースの判定
- Step 3: SuggestedFix による自動修正の追加
AST解析や SuggestedFix の仕組みを体験でき、普段の業務ではなかなか触れない内容に触れられたのが良かったです。 用意されたドキュメントが Google Codelabs のように丁寧に作られており、業務で手順書を作成する際の参考になりました。
analysis パッケージの仕組みの上でMulti linter with configを実現する
弊社でも普段から使わせて頂いている runn と tbls の作者、k1LoWさんのセッションです。
analysis パッケージを用いて Effective Go, Go Style, Go Code Review Comments などの原則をチェックする OSS ツールの紹介がありました。 解析ツールについてはある程度理解しているつもりでしたが、より具体的な方法を知ることができ、理解が深まりました。
もぎ(@manattan_me)
自分は初めての Go Conference への参加となりました。AIがたくさんコードを書いてくれる時代で、言語について理解する意味を再認識することができました。
Goのビルドシステムの変遷 / The history of Go's build system
このセッションは、Go が OSS 化してからビルドシステムについてどういう歴史を歩んできたかについて詳細に解説されていました。自分は、Go Modules が対応してからしか Go 言語に触れてこなかったので、それ以前がどういう状況だったのかを深く知ることができました。
特に印象に残った点としては、コミュニティが依存管理ツールを試行錯誤し、その議論の結果として標準化されていった一連の流れです。Go の成長は、エコシステムを共に育ててきたコミュニティの存在に強く支えられていると感じましたし、自分も色々な場面でエコシステムに寄与していきたいと思いました。
GoのinterfaceとGenericsの内部構造と進化
Go の型、interface、Generics 周りの内部実装についてのセッションでした。src/runtime/**.go の例を取り上げながら、interface / any 値の内部表現(_type / eface / itab 構造)、Generics の辞書‐型パラメータ展開方式などが詳細に解説されていました。
正直自分は何を言っているのかよくわからなかったのですが、runtime の実装などについてより理解を深めることが正しい実装になるということを感じました。Effective Go などを読みながら、内部理解を深めた上で適切なコードを書いていきたいと感じました。
ちなみに、後日登壇者の@turbofishさんが解説記事を出してくださっています。この記事は Go を少し書いている人なら理解できる資料で、非常に助かりました。
https://turbofish.hatenablog.com/entry/2025/09/29/233434
さいごに
これまでの技術的な進化から OSS 活動、そして将来の展望まで幅広く学べたのが Go Conference 2025 の魅力だったと感じます。
今回得た知見を社内やプロダクト改善に活かし、今後は聴講だけでなく登壇や OSS 活動にも挑戦していきたいです!