GoコードをGitHubに依存させるな
原題: Don't couple your Go code to GitHub
なぜ重要か
ベンダーロックイン対策は依存ライブラリだけでなくパッケージ命名規則にも及ぶことを示す、Go開発組織が見落としがちな構造的リスクの指摘。
GoはパッケージのインポートパスにホスティングURLを使う仕様のため、GitHubからGitLabへ移行するだけでコード全体の修正が必要になる。エンジニアのIain Cambridge氏が2026年9月27日に公開したブログ記事で、`go.uber.org`のようなカスタムドメインを使うことでホスティング依存を断ち切る方法を解説。Nginx設定とHTMLメタタグのサンプルも公開した。
Goのインポートパスは`github.com/user/repo`のようにホスティング先のURLをそのまま使う設計になっている。シンプルで便利な反面、致命的な副作用がある。ホスティングを変更すると、すべての依存パスを書き換えなければならない。
Cambridge氏は実例を挙げる。ある企業がGitLab・GitHub・Azure DevOpsの3つを同時に運用していた。パッケージの移行コストが膨大すぎて「時間がない」と判断し、3サービスの料金を払い続けることを選んだ。コードの命名規則が、ビジネスの意思決定を縛ってしまった格好だ。
解決策はカスタムドメインの活用だ。`go.iain.rocks/boneclone`のようなドメインを用意し、実際のリポジトリへのマッピングをサーバー側で管理する。GitHubからGitLabへ移っても、エンドユーザーが使うインポートパスは一切変わらない。`go.uber.org`や`go.mongodb.org`などの大手OSS プロジェクトがすでにこのパターンを採用している。
実装はシンプル。Nginxでリクエストを捌き、`?go-get=1`クエリを含むGoツールからのリクエストには`go-import`メタタグを持つHTMLを返す。人間がブラウザでアクセスした場合は301でGitHubへリダイレクトする。Let's EncryptでSSLを設定すれば完成だ。
Cambridge氏は「商用ソフトウェアを開発するすべてのGoチームが社内ライブラリにカスタムドメインを使うべき」と断言する。なお同氏は、この問題への対処として複数Gitホスティング間でスケルトンコードを同期するツール「Boneclone」も開発している。