GoコードをGitHubに依存させるな
원제: Don't couple your Go code to GitHub
왜 중요한가
GoのimportパスをGitHubに直結するのはコミュニティの慣習だが、それがベンダーロックインを生む構造的リスクとなっている点を具体的コストで示した。
Go言語はパッケージのimportパスにホスティング先URLを使う仕様のため、GitHub等のプロバイダーに直接依存する構造になりやすい。エンジニアのIain Cambridge氏が2026年9月27日に公開したブログ記事では、カスタムドメインを使うことでこの依存を断ち切れると解説。実際にある企業がこの問題で3つのGitホスティングを並行運用し、余分なコストを払い続けた事例も紹介された。
GoはパッケージをURLベースのimportパスで管理する。例えば `github.com/user/repo` と書けばGoツールが自動でfetchする便利な仕組みだが、裏を返せばコードがGitHubというホスティングプロバイダーに直接結びついてしまう。GitLabやAzure DevOpsへ移行しようとすると、importパスを全面的に書き換える必要が生じ、実際には移行できないまま塩漬けになるケースがある。
Cambridge氏は、ある企業がこの問題を放置した結果、GitHub・GitLab・Azure DevOpsの3サービスを同時に契約し続けるという本末転倒な状況に陥ったと報告している。移行コストが大きすぎて「時間がない」と後回しにし続けた末の判断だという。
解決策はシンプルだ。`go.uber.org` や `go.mongodb.org` のように、自社カスタムドメインをimportパスとして使う。ドメインの向き先を変えるだけでバックエンドのGitホスティングを自由に切り替えられる。氏は自身のNginx設定とHTML（`go-import` metaタグ）のサンプルも公開。`?go-get=1` パラメータの有無でGoツールからのアクセスと人間からのアクセスを振り分けるシンプルな構成で実現できる。
Cambridge氏はGoを使う商用開発チームであれば、内部ライブラリに対してカスタムドメインを使うべきだと明言している。なお同氏は、この問題への対処として複数Gitホスティング間でスケルトンコードを同期するツール「Boneclone」も開発・公開している。