Go Conference mini in Sendai 2026 : Goに新機能を提案し実装されるまでのフロー徹底解説

Goの新しい機能やAPIは、どのようなプロセスを経て標準に組み込まれていくのでしょうか？
GitHub上の [golang/proposal](https://github.com/golang/proposal) で全体の流れは説明されていますが、実際にどのような議論が行われ、どんな観点で「採用」や「却下」が判断されているかを具体的に知る機会は多くありません。

本セッションでは、直近の実例3件を題材に、Goのプロポーザルプロセスを徹底的に追いかけます。
各提案がどんな課題意識から生まれ、どのような議論を経て、どの時点で「Accept」され、実装に至ったのか。
実際のやり取りをもとに、コミュニティが重視する視点や、説得力ある提案の作り方を明らかにしていきます。
これを知ることで、将来あなた自身の提案がGoに取り込まれるための具体的なヒントが得られるかもしれません。

Transcript

1. Goに新機能を提案し 実装されるまでのフロー徹底解説 〜Issueで繰り広げられる議論の裏側にある哲学〜 Go Conference mini in Sendai 2026 / pooh
2. 自己紹介 名前 pooh 所属 メルコイン 取締役CTO SNS @t_yamatoya Go本体へのProposal経験はまだありません。過去に PrometheusへのContributeが採用された経験あり。今 回はGoのIssueを眺める中でProposalプロセスに興味を 持ち、調べた内容をまとめました。 2
3. 今日お話しすること Goの意思決定メカニ ズム 02 実例3件の議論を解剖 実名で追う議論の様子 03 あなたが採用される 戦略 「使う人」から「作る 人」への招待 01 多数決ではない「納得 感」の追求 3
4. 問いかけ あなたが日々感じる 「なぜGoにはこれがないんだ？」 その疑問こそが、提案の種になる Issueで繰り広げられる議論の裏側を知ろう 4
5. このセッションで得られること Proposalプロセスを知ると、Goとの向き合い方が変わる 🔍 設計思想の理解 なぜその仕様なのか 裏側の意図がわかる 💬 議論の作法を学ぶ 世界レベルの 技術議論の進め方 🚀 提案への第一歩 自分のアイデアを Goに届ける方法 5
6. Go Projectの意思決定メカニズム Go Teamは多数決で決めない 一人の強い反対（特に互換性や哲学に関するもの）があれば、納得いくまで議論を 止める "We don't vote. If someone has a strong objection, especially about compatibility or philosophy, we stop and discuss until everyone can live with the decision." 合意形成 全員が納得できるまで 長期視点 10年後も後悔しない判断 透明性 全議論がGitHubで公開 6
7. プロポーザルプロセスの全体像 週次のProposal Review Meetingで進捗をチェック。最終的にAcceptまたはDeclineが 決定される Issue作成 `Proposal:` タイ トル Triage ラベル付与 議論 フィードバック 収集 Review 週次Meeting 決定 Accept/Decline 7 1 2 3 4 5
8. Goが大切にしていること Go 1 互換性の約束 "Go 1 で書かれたプログラムは、Go 1 の 仕様が続く限り、コンパイル・実行され 続ける" GODEBUGによる段階的移行 破壊的変更もGODEBUG設定で旧挙動を 維持可能 慎重な変更プロセス 一度入ったAPIは削除できない。v2パッケ ージで進化 シンプルさの維持 「少ない機能で多くを実現」の哲学 — Go 1 Compatibility Promise 8
9. Section 02 実例3件の議論を解剖 実名で追う議論の様子 9
10. 事例 1：スピード採用の裏側 go/token: add File.End method Issue #75849 | 2025/10/10 提起 → 2025/11/12 Accept（33日） 「APIの対称性」と「抽象化の完成度」が決め手 10
11. 事例1: 起票者の主張 Alan Donovan（Goチーム、goplsリード） "`File.Base()`（開始位置）はあるのに、なぜ `End()` がないのか。 AST解析で全範囲を特定するために毎回 `f.Pos(f.Size())` と書くのは冗長だ。" Before（煩雑） end := token.Pos(f.Base() + f.Size()) 内部実装の知識が必要、間違えやすい After（シンプル） end := f.End() 意図が明確、間違いようがない 11
12. 事例1: 採用の決め手 Robert Griesemer（Go言語共同設計者） "ユーザーが `Base + Size` という内部の計算方法を知らないと使えない設計は、API として不完全だ。" 追加コード（たった5行） func (f *File) End() Pos { return Pos(f.base + f.size) } 決定打：3つのポイント 5行 追加コード量 33日 議論→採用 Go 1.26 導入ver 学び: 小さな提案ほど採用されやすい。既存APIの非対称性を見つけることが鍵 「ヘルパー関数を自前で書けば？」との声に対し... 12
13. 事例 2：設計思想の衝突 net/http: client connection API Issue #75772 | 2025/10/06 提起 | Damien Neil（Goチーム net/http メンテナー） 「自由度」vs「将来の変更可能性」— 濃密な設計議論 13
14. 事例2: 技術的論点 - The Conflict 背景: Damien Neil（Goチーム）が2025年10月に起票。コネクションごとのTLS状態やIPア ドレスの監視ニーズに応える提案 近年のHTTPクライアントは、コネクションレベルの詳細情報へのアクセスが必要になって いる。 コミュニティ側の主張 "`http.Response` から生の `net.Conn` を取 り出させてほしい" 接続の詳細情報にアクセスしたい Damien Neil（Goチーム）の反論 "HTTP/2やHTTP/3のマルチプレクシング構 造と矛盾する" 将来の最適化ができなくなる 14
15. 事例2: 合意形成のプロセス 1 提案者が要件を再定義 — 漠然とした「生の接続が欲しい」→「TLS状態とIPが知り たい」へ、自ら要件を具体化 2 Goチームが代替設計を逆提案 — インターフェースで抽象化しContextから取得する 設計を提示 3 双方がトレードオフを明示して合意 — 提案者「ユースケースは満たせる」× Goチー ム「HTTP/3でも互換性維持」 反論 ≠ 否定。要件を再定義するきっかけと捉え直すことで、より良い設計に到達した 15
16. 事例2: 妥協と洗練 - The Solution 着地点 「接続そのもの」を渡すのではなく、 「接続情報を提供するインターフェース」をContext経 由で取得する設計へ type Transport struct { GetConn func(ctx context.Context, req *http.Request) (*Conn, error) PutConn func(conn *Conn) } type Conn struct { Conn net.Conn LocalAddr net.Addr TLSState *tls.ConnectionState } 「自由度」よりも「将来の変更可能性」を優先 — Goの設計思想が如実に出た議論 16
17. 事例 3：信頼を築く16ヶ月 runtime/trace: flight recording Issue #63185 | 2023/09 提起 → 2025/01 Accept（16ヶ月） Go Teamメンバーでも、runtime変更には膨大な検証が必要 17
18. 事例3: 課題と背景 課題 本番環境で「たまに遅くなる」問題を追うのは至難の業。常にトレースを回し続 け、異常時に「直前の5秒間」をガバッと抜き出したい。 （飛行機のブラックボックスのような機能） Before 問題発生を予測してトレース開始 常時トレースはオーバーヘッド大 再現困難な問題は調査不能 After (Flight Recording) 常にバックグラウンドで記録 問題発生時に直近のデータを取得 低オーバーヘッドで本番運用可能 18
19. 事例3: 議論の最大の壁 `runtime` は聖域 トレース記録のメモリ確保が、GC（ガベージコレクション）に悪影響を与えない か？ なぜ検証に16ヶ月もかかったのか 初回ベンチマークで「GCへの影響データが不十分」と差し戻し ベンチマーク手法自体にも議論（ 「どの条件で測るべきか」 ） ロックフリーなバッファ構造を設計 → マルチコアでの競合テストも要求 各ラウンドごとにGoチームのレビュー待ち（数週間〜数ヶ月） "Go Teamメンバーの提案でも、runtime変更はデータで証明しなければ通らない" 19
20. 事例3: 16ヶ月の歳月 1年半の歳月は、信頼を築くための時間 Go 1.25での実装は、コミュニティの長年の悲願達成 2023/09 Issue起票 2024前半 設計議論 2024後半 ベンチマーク 2025/01 Accept! 20 1 2 3 4
21. 事例3: 採用の決め手 "This proposal has been open for a year and a half with mass community support. The implementation is ready and has been tested." （この提案は1年半にわたって多くのコミュニティの支持を得てきた。実装は完了 し、テスト済みだ） — Proposal Review Comment 16ヶ月 長期間の議論で懸念点を クリア 実装完了 テスト済みのCLが準備済 み 先行事例 Java Flight Recorderで実用 化済み。 「前例がある」が 信頼の根拠に 21
22. 傾向分析と3事例の比較 Go 1.18〜1.25 のAcceptされたProposalを類型別に分類 42% 類型A: スピード採用 小さな変更、1-3ヶ月で決着 33% 類型B: 設計思想の洗練 議論で設計が進化、3-6ヶ月 25% 類型C: 長期信頼構築 言語仕様・runtime変更、1-3 年 事例 類型 期間 影響範囲 決め手 go/token A 33日 メソッド1個 API対称性 net/http B 約4ヶ月 Transport拡張 設計の洗練 runtime/trace C 16ヶ月 runtime変更 ベンチマーク 変更の影響範囲と検証の難しさが議論期間を決める 22
23. Section 03: あなたが採用される戦略 「使う人」から「作る人」への招待 あなたのアイデアをGoに届けるために 23
24. なぜGoユーザーがProposalを出すのか？ 自分の提案がGoに取り込まれる — これほどワクワクすることはない 🌍 自分のコードが 世界中で動く 💬 言語設計のプロから 直接レビュー 💡 日々の不満が 改善の原動力 出さない理由はない。Declineでもフィードバック自体が最高の学び 24
25. 提案前のセルフチェック＋小さく始める 「ヘルパー関数を自前で書けば？」と言われ る前に 1自前実装で間違える余地があるか？ 2 同じ実装がエコシステムに散らばっていな いか？ 3将来の内部実装変更で壊れるか？ 4godocで発見できないと困るか？ 難易度で始める場所を選ぶ 始めやすい（類型A） 既存APIへのメソッド追加 便利な定数の追加 ドキュメントの改善 難易度: 高 言語仕様の変更 runtime/compilerの変更 言語仕様を変えるのではなく、 net/http や os など周辺ライブラリの改善提案から入る のが成功の近道 25
26. Proposalを出すのは迷惑？＋ネタの探し方 5,900件+ 20% 外部開発者比率 70% Go Teamは15%のみ Go Teamは「ノイズ」とは考えていない。Declineでも設計思想を学べる貴重な経験 類型A（Accept率42%）のネタ探し 1 「毎回書くヘルパー関数」を探す — 3回書 いたら標準化のサイン 2 「APIの非対称性」を見つける — Base()は あるのにEnd()がない穴 3「godocで見つからなくて困った」経験 4 「新機能の応用提案」を探す — ジェネリ クス・イテレータが今ホット Proposal Issue 総数 2024年だけで778件 Accept率（累計） 1,203件 / 5,943件 26
27. ProposalからPR・マージまでの流れ Proposalが Accept された後、実際のコードはどうやって取り込まれるのか？ 1Gerrit で CL（Change List）を作成 GoはGitHubのPRではなく go.googlesource.com のGerritを使用。 git codereview change でCLを作成 2コードレビュー（Goチームメンバー） パッケージのOWNERSがレビュー。テスト・ベンチマーク・APIドキュメントの品質を確 認 3TryBot + マージ 全プラットフォームのCIが通ればマージ。次のGoリリース（半年サイクル）に含まれる 始め方: go.dev/doc/contribute ｜ Tips: Issueに「実装もやりたい」と記載 27
28. まとめ：3つのTakeaways 1 Goは「納得感」の文化 2 変更の重さが議論の長さを決める 3 あなたの疑問は、未来のGoの改善案 多数決ではなく、全員が納得するまで議論を続ける 5行の変更は33日、runtime変更はGoチームメンバーでも16ヶ月 小さく始めて、Goの設計哲学に沿った提案をしよう さあ、あなたもIssueを書いてみませんか？ 28
29. ご清聴ありがとうございました さあ、あなたもIssueを書いてみませんか？ 質問があればどうぞ！（Appendixに想定Q&Aあります） @t_yamatoya 29
30. Appendix 想定Q&A / 実際のIssue文 / 参考リンク
31. 事例1: 実際のProposal Issue文 Issue #75849 — go/token: add File.End method | Alan Donovan | 2025/10/10 Proposal: go/token: add File.End method // End returns the position of the end of the file. func (f *File) End() token.Pos { return Pos(f.Base() + f.Size()) } I found at least 16 places in x/tools where we compute this expression manually. 注目ポイント: 提案が簡潔。コード例 +「16箇所で手動計算している」という具 体的な根拠だけ 提案のコツ: 「エコシステム内で同じコー ドが散らばっている」数を示すと説得力 が増す 31
32. 事例2: 実際のProposal Issue文 Issue #75772 — net/http: client connection API | Damien Neil | 2025/10/06 This is a proposal to add the ability to create client connections to net/http. The http.Transport type is "a low-level primitive for making HTTP and HTTPS requests". A Transport contains a pool of client connections. Most HTTP client users are well-served by the current Transport, which automatically manages creating connections [...]. However, some users may wish to manage connections directly rather than using the Transport's pool. 注目ポイント: 既存設計(Transport)を尊重 した上で、不足する機能を具体的に指 摘。 「ほとんどのユーザーには十分」と認 めつつ提案 提案のコツ: 大きなプロジェクト(#67810) の一部として位置づけ、文脈を明確にし ている 32
33. 事例3: 実際のProposal Issue文 Issue #63185 — runtime/trace: flight recording | Michael Knyszek | 2023/09/24 # Proposal: runtime/trace flight recording "Flight recording" is a technique in which trace data is kept in a conceptual circular buffer, flushed upon request. The purpose of this technique is to capture traces of interesting program behavior, even when one does not know ahead of time when that will happen. The Java ecosystem has had this for years through Java's flight recorder. Once the JVM's flight recorder is enabled, the JVM can obtain a trace representing the last few seconds of time. 注目ポイント: 背景(Background)で既存技 術(Java Flight Recorder)の先行事例を示 し、実現可能性の根拠にしている 提案のコツ: runtime変更のような大きな 提案は、Design Docレベルの詳細な設計 文書が必要 33
34. 実例: 「毎回書いていたコード」が標準に 着眼点1に該当するAccept済みProposalの実例 strings.Cut Go 1.18 標準ライブラリ内で77%の Index 呼び出し が「Cutで書ける」とRuss Coxが分析 cmp.Or Go 1.22 if x != "" { return x } のゼロ値フォ ールバックを1関数で解決 sql.Null[T] Go 1.22 NullInt64, NullString... 型ごとのNullable型を ジェネリクスで統一 slices.Concat Go 1.22 append(append(a,b..),c..) のネストを Concat(a,b,c) 一発で いずれも「よく書くパターン」の発見 → 類型A（スピード採用）で短期間にAccept 34
35. Goの最新動向: 2021年以降の変化 イテレータ革命 v2パッケージの先例 `math/rand/v2` がGo 1.22で登場。後方 互換性を保ちつつAPIを刷新するモデル ケースに ジェネリクスの標準ライブラリ浸透 `slices`, `maps`, `sync.OnceFunc/OnceValue` など。Go 1.21以降、ジェネリクス活用APIが急増 GODEBUGによる段階的移行の定着 loop変数スコープ変更(#60078)では go.modゲートを採用。Google社内検証で 「バグ修正20:壊したケース1」の実績 Go 1.22で実験的導入、Go 1.23で正式に 言語仕様化。`iter` パッケージも追加。 標準ライブラリ全体がイテレータベース に移行中 35
36. 参考リンク Proposalプロセス github.com/golang/proposal Go 1 互換性の約束 go.dev/doc/go1compat go/token #75849 File.End method（33日採用） net/http #75772 Connection API（設計思想の衝突） runtime/trace #63185 Flight Recording（16ヶ月の議論） Weekly Proposal Review github.com/golang/go/issues（Proposalラ ベル） 36
37. Q&A (1/5) Q1. Proposal Committeeの議事録はどこで見られるか？ GitHub上の `golang/go` リポジトリで `Proposal` ラベルが付いたIssueから追跡でき ます。毎週水曜のミーティング後、各IssueにCommitteeのコメントが記録されま す。golang/go の Discussions にもまとめが投稿されることがあります。 Q2. Flight recordingのGCオーバーヘッドの具体値は？ Issue #63185 の議論では、ベンチマーク結果が複数回提示されています。ロックフ リーなリングバッファ構造の採用により、常時記録時のCPUオーバーヘッドは低く抑 えられていますが、具体的な数値はワークロードに依存するため、Issue上のベンチ マーク結果を直接確認することを推奨します。 37
38. Q&A (2/5) Q3. OSSの議論で感情的にならないコツは？ Goチームの議論を観察すると、常に「提案」と「提案者」を分離しています。反論 は設計への指摘であり、人格への否定ではありません。 「この設計にはこういう懸念 がある」というフォーマットを意識し、反論を「より良い設計へのフィードバック」 と捉え直すことが重要です。 Q4. メソッド追加レベルの提案でAcceptまでの期間見込みは？ 100件の調査結果から、類型A（小さな変更）の平均議論期間は1-3ヶ月です。事例1 の `File.End()` のように、既存APIの対称性補完であれば1ヶ月程度で決着するケース もあります。ただし、APIの設計に議論が生じれば6ヶ月以上になることもありま す。 38
39. Q&A (3/5) Q5. 日本語話者として英語でIssueを書くハードルは？ GoのIssueは技術的な内容が中心なので、コード例が伝わればOKです。テンプレート に沿って「Background / Proposal / Rationale」の構成で書けば、英語の流暢さよりも 内容の明確さが評価されます。既存のAcceptされたIssueを参考にするのが最も効果 的です。 Q6. Goチームメンバーと外部でレビュー厳しさに差はないか？ 外部開発者の提案もGoチームメンバーの提案も同じProposal Committeeの審査を受 けています。事例3のようにGoチームメンバー（Michael Knyszek）でも、runtime変 更では16ヶ月の検証が求められました。提案者の所属よりも、変更の影響範囲と検 証の質が審査基準です。 39
40. Q&A (4/5) Q7. Declineされた後の再提案は可能か？ 可能です。ただし、前回のDecline理由を踏まえた新しい根拠やアプローチが必要で す。 「状況が変わった」 「新しいデータがある」 「設計を根本的に見直した」などの理 由があれば、新しいIssueとして再提案できます。前回のIssueへのリンクを貼り、何 が変わったかを明示しましょう。 Q8. Genericsのような大きな変更とstdlib変更のプロセスの違いは？ 基本プロセスは同じですが、言語仕様変更は Design Doc の作成が求められ、複数の Proposal Committeeミーティングで段階的にレビューされます。Genericsは10年以上 の議論を経ており、類型Cの中でも最長クラスです。stdlib変更は比較的軽量なプロ セスで進みます。 40
41. Q&A (5/5) Q9. golang.org/x パッケージへの提案は同じプロセスか？ 基本的に同じGitHub Issueベースのプロセスです。ただし、golang.org/x は標準ライ ブラリほど互換性の制約が厳しくなく、実験的なAPIの導入がしやすい側面がありま す。実際に `golang.org/x/exp` で試された後に標準ライブラリに昇格するケース （`slices`, `maps` など）もあります。 Q10. 最初の一歩として何をすべきか？ まずは `golang/go` のIssueを読むことから始めましょう。特に `Proposal` ラベルの 付いたIssueの議論を追うと、Goチームの判断基準が見えてきます。次に、日々のコ ーディングで感じる不便さを `Discussion` に書いてみてください。いきなり Proposalを書く必要はありません。 41