解決できる課題 事業紹介トップ 経営データ分析基盤 Claude / MCP 導入 AI 業務アプリ 複雑な SaaS を専用 UI に Shopify Plus 移行・拡張 生成AI 活用(Multi AI) SEO / AIO / 広告運用 顧問・アドバイザリ インフラ構築 自社メディア投資・開発
Claude Claude / MCP 総合 Claude Cowork Claude Code 導入支援 Claude Code 使いこなし支援 Claude Design MCP 開発・サーバー構築
Shopify Plus Shopify Plus トップ EC-CUBE からの移行 大手カートからの移行 Shopify 通常プラン EC サイト構築
実績
業界ニュース 業界ニュース トップ AI ニュース └ Claude └ ChatGPT・Codex └ Gemini └ その他 Shopify ニュース SaaS ニュース お知らせ(自社発信)
会社情報 相談する
2026.09.26

Go Conference 2026 参加レポート:freee新卒エンジニアが語るGC・range over funcの学び

記事のサマリー(TL;DR)

  • 2026年9月11日、中野セントラルパークカンファレンスでGo Conference 2026が開催。参加者700人超、19セッション
  • 「Invisible OOM Kill」セッションでは、GOGC/GOMEMLIMIT の誤設定でGoプロセスだけが無音で落ちる障害の原因と対策を解説
  • タイムテーブル全体でAI・LLMを主題にしたセッションがゼロ。GC・ランタイム・標準ライブラリに終日集中した稀有な構成

freee・Go利用企業の運用エンジニアが押さえておくべき「Invisible OOM Kill」の実態

Go を本番運用している組織にとって、今回のカンファレンスで報告された「Invisible OOM Kill」は他人事ではありません。NginxとGoが同一コンテナで動く構成は、歴史的な経緯でそうなっているケースが国内でも少なくなく、Kubernetes 上でPodのステータスに「OOMKilled」が出ないまま5xxエラーが続発するという障害は、ログを追っても原因が掴みにくい類のものです。

特に GOGC=500(デフォルト100に対して5倍緩和)のような設定は、CPUコスト削減を目的とした最適化として一定の合理性がありますが、Goランタイム自体がコンテナのメモリ上限を認識しない点を見落とすと、GCが動く前にOOM Killerに先を越される状態になります。GOMEMLIMIT でGoにメモリ上限を明示し、GOGC=off でGCのトリガーをGOMEMLIMIT一本に絞る対策は、Go 1.19 以降であれば今すぐ適用できる内容です。kintone や Salesforce の API をバックエンドで呼び出すGoサービスなど、バースト的にメモリが増減する構成では特に有効です。


詳細

Go Conference 2026 概要

  • 開催日: 2026年9月11日(木)
  • 会場: 東京・中野セントラルパークカンファレンス
  • 規模: 参加者700人超(オンライン含む)、セッション19本、スポンサー55社、スタッフ51人
  • freeeの立場: シルバースポンサーとして協賛、ブース出展

freee でエージェント開発を担当する新卒エンジニアがGoを書き始めたのは入社後。Go Conference も今回が初参加という立場から、特に印象に残った2セッションを中心にレポートをまとめています。


セッション①「Podは生きているのにGoだけが落ちる:GOGCとGOMEMLIMITで追うInvisible OOM Killの謎」

登壇者: 株式会社エウレカ / Takeshi Watanabe 氏
形式: ドリンクセッション(昼食時間帯・15分)

障害の概要

  • 数日に一度、5xxエラーが大量発生した後、何事もなかったように復旧
  • panicログなし、PodステータスにOOMKilledなし、Goプロセスだけが消える

原因の構造

歴史的な経緯で NginxとGoが同一コンテナ 内で動作していた。Linuxの OOM Killer はコンテナのメモリ上限超過時に「最もメモリを消費しているプロセス」を選択して終了させる。今回のケースでは:

  1. 終了したのはPID 1ではないGoプロセス
  2. PID 1(Nginx)は生き残るのでコンテナ自体は落ちない
  3. どこにもOOMの記録が残らない → 「Invisible」OOM Kill

なぜメモリが増えすぎたか

Goには GOGC(ガベージコレクションのトリガー比率)という設定があり、デフォルト値は100(= live heapの2倍でGC発動)。このチームはCPU負荷軽減のために GOGC=500(= live heapの6倍)に設定。さらに重大な点として、Goランタイムはコンテナのメモリ上限を自分では認識しない。その結果、GCが発動する前にOOM Killerがプロセスを終了する状態に陥っていた。

採られた対策(3点)

対策 内容
コンテナ分離 NginxとGoを別コンテナに切り分ける
GOMEMLIMIT 設定 GoランタイムにコンテナのメモリUpper boundを明示
GOGC=off GCトリガーをGOMEMLIMIT一本に集約し、管理を単純化

15分のセッションでありながら、GoのGC設計・Linuxのメモリ管理・Kubernetesコンテナ境界という3層の知識が一度に整理される内容でした。


セッション②「range over func 2年間の軌跡 — Issue #56413 はGoのエコシステムをどう変えたか」

登壇者: 國分 竜二 氏(合同会社DMM.com)
形式: 20分セッション

背景

Goにはコレクションを走査する統一的な書き方が長らく存在しなかった。

  • filepath.Walk
  • sync.Map.Range
  • flag.Visit

これらはいずれもコレクションを反復処理するメソッドだが、呼び出し方も戻り値の形もバラバラ。この非一貫性を解消したのが Go 1.23 で正式導入された「range over func」 です。

設計の決断

セッションの核心は「なぜ interface で解決しなかったのか」という問いへの回答でした。Goチームが最終的に選んだのは、言語仕様そのものに組み込む方針。2022年のDiscussion #56413から2年間の議論を追う構成で、Issueトラッカーの議論を時系列で読み解きながら、言語設計がどう合意形成されるかを可視化した内容でした。


参加ハードルの低さ

カンファレンスの間口の広さがレポート全体で強調されています。具体的な配慮は以下の通りです。

  • 難易度ラベル: 全セッションに「初心者向け / 中級者向け / 上級者向け」を付与
  • ワークショップ: 6本中5本が初心者向け
  • 参加費: 学生1,500円〜、一般5,000円〜、学生支援制度あり
  • オンライン: 無料視聴可能。アーカイブ公開も予定

ドリンクセッション(昼食時間帯の15分枠)にエウレカのセッションが入っていたように、最も気軽な枠に実務直結の内容が配置される設計でした。


Go Context Hall:歴史の年表

会場には「Go Context Hall」と名付けられたホワイトボードが設置され、2007年の設計開始から以下の節目が年表化されていました。

  • 2012年:Go 1.0リリース、「互換性の約束」
  • Go 1.7:context パッケージ標準化
  • Go 1.18:ジェネリクス導入

参加者は付箋で自分の記憶を貼り足すことができ、「GOPATHなつかしい」「Russ Coxが手動修正に疲れてgofixを投入」といったコメントが並んでいました。一人で来場しても気まずくならない、会話しなくても「参加している感」が生まれる工夫です。


TinyGoワークショップとスポンサーブース

  • ワークショップは事前予約制。freeeメンバーの一人はTinyGoワークショップで実際の基板を触れた
  • スポンサーブースのビンゴカードで、初めて話す企業のブースにも足を運びやすい導線を設計
  • freeeブースでは「freeeがGoを使っているって知ってた?」というアンケートで来場者と対話

AIセッションゼロという特徴

タイムテーブルを最初から最後まで確認しても、AIやLLMを主題としたセッションは1本も存在しませんでした。2026年という時点で、あらゆる技術カンファレンスにAIトークが混入しがちな中、Go Conference 2026は GC・ランタイム・標準ライブラリの話で終日を埋める という方針を維持しました。流行ではなく言語の本質を深掘りできる場として機能した点が、参加者から評価されています。


クロージングで示された規模データ

項目 数値
パートナースポンサー 55社
Gopher スポンサー 23人
スタッフ 51人
セッション数 19本
スポンサーブース 18
参加者(オンライン含む) 700人超

当日の全セッション資料は、Koya IWAMURA 氏がZennにまとめています。アーカイブ動画の公開も予定されているため、当日参加できなかったセッションも後から確認できます。