はじめに
こんにちは、検索基盤部の倉澤です。ZOZOTOWNの検索機能のバックエンドの開発を担当しています。検索基盤部の一部システムではGoを採用しています。
2026年2月21日（土）にGo Conference mini in Sendai 2026が開催されました。本記事では、会場の様子や個人的に印象に残ったセッション・LTについて紹介します。また、私もLT枠で登壇したため当日話しきれなかった内容もあわせて紹介します。
目次
Go Conference mini in Sendai 2026とは
Go Conferenceは、プログラミング言語Goに関するカンファレンスです。今回は「東北から広がるGoコミュニティ」というテーマで仙台にて4年ぶりに開催されました。18セッション（20分）と12のLT（5分）によって構成され、Goに関するさまざまなテーマについて発表されました。参加者は117人と大盛況のうちに終わりました。
会場の様子
会場は仙台市青葉区にあるアーバンネットビル仙台中央 カンファレンスルームでした。ワンフロアにスポンサーブースと2部屋のセッションルームがあり、同時に発表が行われました。
スポンサーブースでは、参加者向けのさまざまなコンテンツが用意されていました。
株式会社UPSIDERさんのブースでは、「Goの挑戦Goっそり教えて！」をテーマに意見が募られていました。「TinyGoを使って何かを作ってみたい」等の声があり、TinyGoへの関心の高さがうかがえました。
株式会社SODAさんのブースでは、「あなたのやらかしエピソードや懺悔したいことを教えてください」をテーマに意見が募られていました。生成AIが書いたコードによってやらかしたエピソードが昨今の開発事情を表していて面白いなと思いました。また、SODAさんのブースではGopherの16タイプに分ける診断を実施しておりました。
私は、「数学的な賢者」でした！
会場では参加者全員にステッカーなどのノベルティが配布されており、どれもとても可愛らしいデザインでした。
また、ネームタグの裏側には「すぐに使える仙台弁」が記載されており、参加者同士の会話のきっかけになっていました。仙台開催ならではの遊び心が感じられる演出でした。
さらに登壇者にはTシャツが配布され、登壇の良い記念になりました。運営の皆さまのお心遣いに感謝です。
セッション
AI時代のGo開発2026 爆速開発のためのガードレール
こちらのセッションでは、生成AIにおける開発の「速さ」と「治安（コード秩序やルール）」をいかに両立させるのかについて紹介されています。
課題
- 生成AIの発達・普及により実装速度が飛躍的に向上した一方で、アーキテクチャのルール違反などコードの治安が悪化しやすくなっている。
対策
- Rules/Skillsのような非決定的な制約（ソフト制約）だけに頼るのではなく、決定的な制約（ハード制約）をガードレールとして整備することが重要。
紹介されているハード制約の例
- Goの
internalパッケージによるアクセス制御 - depguard等のLintによる依存ルールの強制
- Fuzzing testやMutation testによるテスト品質の担保
- Goの
個人的に気になった点
アーキテクチャの依存ルールを生成AIに守らせるという観点で、Goのinternalパッケージを用いるというのは面白い発想だと思いました。一方で、ドメイン単位でパッケージを分割するPackage by Featureだからこそ威力を発揮する一面もあるのかなと思いました。私が携わっているプロジェクトでは、アーキテクチャの技術的な役割（レイヤー）毎にパッケージを分割するPackage by Layerを採用しています。internalパッケージの配下に各レイヤーのパッケージを切る構成が一般的です。この場合、internalが守れるのは外部モジュールからのアクセスであり、internal内部のレイヤー間の依存方向までは防げません。
発表後に登壇者の方へ質問したところ、Package by Layerでもinternalパッケージが活きるケースを共有していただきました。各層でしか使わない関数を他の層から使われないように守るという観点です。例えば、presentation層でレスポンスに対して処理する関数をinternalに配置すれば、他の層からの誤った利用を防げるとのことでした。レイヤー間の依存方向の制御とは別に、各層の内部実装の隠蔽という観点でinternalが有効に機能するというのは納得感がありました。
Go パッケージのサプライチェーン攻撃を防ぐ CI を作ってみた
こちらのセッションでは、Goパッケージのサプライチェーン攻撃をCIで防ぐ取り組みについて紹介されています。
課題
typosquatting（タイプミスを狙った攻撃）やslopsquatting（AIのハルシネーションを狙った攻撃）により、悪意のあるパッケージの混入リスクがある
対策
- Googleが公開している
capslockを活用し、パッケージがアクセスし得る特権的操作（ファイルシステム操作、ネットワーク通信など）を静的解析で検知 - PRで新しいパッケージが追加された際に、
mainブランチとのCapabilityの差分をCIで検出 - その結果をClaude Code Actionに読み込ませることで、セキュリティリスクを診断する仕組みを構築
- Googleが公開している
個人的に気になった点
こちらのセッションは、昨年開催されたGo Conference 2025の「サプライチェーン攻撃に学ぶmoduleの仕組みとセキュリティ対策」に続く内容だと感じました。昨年の発表では、Goのパッケージ管理システムを利用したサプライチェーン攻撃が3年以上見つからず、その根本的な対策も難しいという話がありました。本発表はLT枠で5分と短かったですが、昨年のGo Conferenceで発表された課題に対して対策を検討し、同じくGo Conferenceで発表するという流れにとても感心しました。
発表内容で気になったのは、新しく追加されたパッケージのCapabilityから悪意の有無をClaude Codeがどう判断しているかという点です。登壇者の方に質問したところ、依存先パッケージのメソッド名や周辺の実装をもとに判断していると考えられるとのことでした。また、サードパーティの公式パッケージを追加した際にも、依存先パッケージでCapabilityの警告が出るケースもあったそうです。ただし公式パッケージである以上、対処は難しく、まだ改善の余地があるとのことでした。
Go 1.26 で生まれ変わった go fix をプロダクト開発の運用に乗せる
こちらのセッションでは、Go 1.26で大幅に刷新されたgo fixコマンドをプロダクト開発の現場にどう組み込むかについて紹介されています。
運用フローの設計
- 「検知」と「適用」を分けて考えるのがポイント
- 検知（毎PR）：
golangci-lintのmodernizeを有効化し、CIで古い書き方を常時警告する - 適用（Goバージョン更新時）：
go fix ./...を2回実行して既存コードを一括変換する
go fixに関する3つのアプローチと使い分け
modernize：組み込みルールによるコードのモダン化。go fixを実行するだけSuggestedFix：自作Analyzerに修正提案を追加し、プロジェクト固有のパターンを自動修正するgo:fix inline：非推奨関数に//go:fix inlineを付与し、利用者側でgo fixを実行するだけでAPI移行を自動化する
個人的に気になった点
先日公開された公式ブログ「Using go fix to modernize Go code」を読んでおり、最近私もgo fixを実行した経験がありました。そのため、運用観点の話はとても興味深い内容でした。特に気になっていたのは、go fixの「2回実行が必要」という点の仕組み化です。あるmodernizeルールの適用が別のルールの適用機会を生むため、公式ブログでも2回の実行が推奨されていますが、これを仕組み化するのは難しいと感じていました。登壇者の方に質問したところ、以下のような回答をいただきました。
- まだ完全な仕組み化はできていないが、pre-commitフックでコミット前に
go fixを実行する方法を検討している - ただしpre-commitの導入はチームにより意見が分かれるため、Claude CodeのSkillsで実行させるのも有効ではないか
生成AIのSkillsは、こうした「毎回やるべきだが柔軟さも求められるルール」の適用に向いているという点に納得感がありました。また、golangci-lintのmodernizeリンターについても質問しました。内部的にはgo fixと同じmodernizeアナライザが動いているため、こちらも同様に複数回の実行が必要とのことでした。
encoding/json/v2のUnmarshalはこう変わった ~内部実装で見る設計改善~
私も今回LT枠で登壇いたしました。このセッションでは、Go 1.25で実験的に追加されたencoding/json/v2パッケージのUnmarshal関数を取り上げました。従来のencoding/jsonパッケージが抱えているパフォーマンス上の課題と、v2での改善点を内部実装の観点から紹介しました。
v1での課題点
- パッケージの構成：1つのパッケージに「JSONを解析する処理」と「Goの構造体に変換する処理」がすべて混在しており、変更時の影響範囲も広かった
- エラーメッセージ：JSONのパース（解析）に失敗したとき、どの項目でなぜ失敗したのかがエラーメッセージから読み取りにくかった
- メモリの使い方：Unmarshalを呼ぶたびに内部で使うオブジェクト（Decoder）を毎回新しく作成しており、高頻度で呼び出すとメモリ確保やGC（ガベージコレクション）の負担が大きかった
- データの読み取り方：JSONデータを読み取るたびに内部でコピーが発生しており、メモリ効率が悪かった
v2での改善点
- パッケージの分離：「JSONの解析」を担う
jsontextパッケージと「Goの型へのマッピング」を担うjsonパッケージに分離し、それぞれの役割を明確にした - 構造化されたエラー：エラー情報にJSONのどの位置で、どんなJSON型が原因で失敗したかを含めるようにし、原因の特定が容易になった
- オブジェクトの再利用：sync.Poolパッケージを使い、一度作った
Decoderを使い回すことで、メモリ確保の回数とGCの負担を大幅に削減した - 効率的なバッファ管理：1つのバッファ（データを一時的に保管する領域）を論理的に分割して管理することで、データのコピーなしに必要な部分へアクセスできるようになった
- パッケージの分離：「JSONの解析」を担う
このテーマを選んだきっかけ
普段の業務ではREST APIを実装する機会が多く、encoding/jsonパッケージを利用する場面も多くありました。しかし、encoding/jsonには以前から課題が多く、golang/go#71497でも長期にわたって議論が続いています。そんな中、Go 1.25で実験的にv2が追加されました。go-json-experiment/jsonbenchのベンチマーク結果を見ると、v2のUnmarshal関数は以下の点で大きく改善されていることがわかります。
- 大幅な速度改善：具象型で2.7〜10.2倍、RawValue型では最大21.1倍と、v1から劇的に高速化されている
- 安全性を犠牲にしていない：
unsafeパッケージを使用せず、UTF-8の検証や重複キーの拒否などRFC準拠の正確性も向上している - ストリーミング対応：v1では非対応だった
Unmarshalのストリーミングにも設計当初から対応している
速度・正確性・安全性のいずれも改善されているという結果から、「なぜこれほど改善できたのか？」を内部設計から理解したいと思い、アドベントカレンダーの記事で調査しました。その調査がきっかけとなり、今回プロポーザルを提出しました。
さいごに
今回LT枠ではありますが、初めてGo Conferenceにプロポーザルを提出し、採択していただきました。発表後には「あと20分くらい聞きたかった」や「よく5分でまとめましたね」などとても温かいお声をいただきました。登壇を機に、さまざまな方と繋がれたことは非常に貴重な経験でした。アウトプットがきっかけで生まれる繋がりの大切さを改めて実感しました。また、登壇を機に初めて仙台へ行きました。牛タンやずんだ餅など仙台グルメも堪能でき、カンファレンスと合わせて充実した思い出となりました。
最後に、このような素晴らしい場を作ってくださった運営の皆さまに心から感謝いたします。準備から当日の進行まで、細やかな配慮が行き届いており、登壇者・参加者いずれの立場でも安心して楽しむことができました。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
