デジタル・オートノミー：なぜGitHubからForgejoへの移行が勢いを増しているのか

ソースコードをGitHubのような中央集権的なプロバイダーからセルフホストのインスタンスへ移行するという決定は、単一の障害やバグのある機能によるものであることは稀です。むしろ、それは所有権と制御に関する根本的な変化への反応であることが多いのです。オランダ政府が最近、政府のソースコード用にセルフホストされたForgejoインスタンスであるcode.overheid.nlを立ち上げたことは、デジタル・オートノミー（デジタルの自律性）の要件がもはや周辺的な懸念ではなく、法的かつ戦略的な必然性であることを示しています。

多くの開発者や組織にとって、Forgejoへの移行は単にダウンタイムを回避するためだけではなく、自らの知的財産を単一の企業の戦略的利益から切り離すためのものです。

GitHubの独立性の浸食

長年、GitHubに留まるための有力な議論は、Microsoftが適切な距離を保って維持しているというものでした。しかし、2025年の構造的な変化がこのダイナミクスを変化させました。2025年8月、GitHubは独自のCEOを持たなくなり、MicrosoftのCoreAI部門内のユニットとなりました。この部門は、エンドツーエンドのCopilotおよびAIスタックの構築を任務としています。

この統合は、プラットフォームの安定性とプライバシーに具体的な影響を及ぼします：

  • AI駆動の負荷: GitHubのCTOは、最近の主要な障害を「エージェンティックAIワークフローの成長」に起因すると述べており、AI駆動の負荷に対応するために容量を30倍に拡張する必要があると指摘しています。プラットフォームの信頼性は、現在、AI機能の積極的な展開と直接結びついています。
  • トレーニングデータの反転: 2026年4月、GitHubはプライバシー設定を変更し、Copilot Free、Pro、およびPro+ユーザーのインタラクションデータ（入力、出力、およびコードスニペット）を、デフォルトでAIトレーニング用にオプトインにするようにしました。極めて重要なのは、リポジトリレベルでのオプトアウトが存在しないことです。コントリビューターがCopilotを使用する場合、リポジトリのライセンスに関わらず、そのコードベースとのやり取りがトレーニング素材となる可能性があります。

管轄権の罠

企業のポリシーを超えて、国家法の現実が存在します。GitHubとMicrosoftは米国ベースの企業であるため、サーバーが物理的にどこに位置しているかにかかわらず、保持しているすべてのデータは米国の管轄権下に置かれます。

FISA Section 702やCLOUD Actといった法的枠組みは、米国の情報機関や法執行機関が、世界中のどこに保存されているデータであっても、米国企業に対してデータの提出を強制することを可能にします。2025年にMicrosoft自身の弁護士がフランス上院で証言したように、EUのデータレジデンシーは安心材料ではあっても解決策ではありません。欧州のデータセンターに保存されたデータが、米国の政府によるサイレントなアクセスから安全であることは保証できません。

なぜGitLabではなくForgejoなのか？

主権的なフォージ（forge）を選択する場合、選択肢はしばしばGitLab対Forgejoに絞られます。GitLabは強力で洗練されたツールですが、「オープンコア」モデルを採用しており、多くのプロダクションレディな機能が製品版のプロプライエタリなエンタープライズ・ティアに制限されています。

GiteaのフォークであるForgejoは、異なるアプローチを取ります：

  • 真のオープンソース: ForgejoはGPLv3+の下でライセンスされており、商業的な乗っ取りに抵抗し、コードベースがコピーレフトを維持するように明示的に設計されています。
  • 非営利のガバナンス: Forgejoは、メンバーが選出する理事会と公開予算を持つドイツの非営利団体（Verein）であるCodeberg e.V.によって管理されており、商業ベンダーには真似できないレベルのガバナンスの透明性を提供しています。

防御可能なセルフホスト環境の構築

フォージをセルフホストすることは比較的簡単ですが、CI/CDランナーのセキュリティを確保することが真の技術的課題となります。ランナーはライフサイクル・スクリプト（npm installなど）を実行するため、サプライチェーン攻撃の主要な標的となります。

Forgejoランナーのための堅牢な「防御層の深化（defense-in-depth）」アーキテクチャには、複数の隔離の層が含まれます：

  1. KVM Virtualization: KVM仮想マシン内でランナーを実行することで、ホストカーネルがジョブ環境と共有されないことを保証します。
  2. gVisor Runtime: VM内でDockerのランタイムとしてrunsc (gVisor) を使用することで、ユーザー空間でシステムコールをインターセプトし、コンテナ・エスケープがVMカーネルに到達することを防ぎます。
  3. 破壊的再構築 (Destructive Rebuilds): 週に一度のスケジュールでVMを破棄して新しいイメージから再構築することで、持続的な脅威が足場を築くのを防ぎます。
  4. Egress Filtering: nftablesを使用して、ランナーがローカルネットワーク（LAN）にアクセスすることをブロックし、必須のパブリックポート（80, 443, 22, 53）のみを許可します。
  5. Scoped Tokens: 管理者権限のトークンではなく、ユーザーまたは組織に限定されたスコープのトークンを使用することで、漏洩した認証情報の被害範囲を制限します。

移行のトレードオフ

GitHubから離れることにはコストがかかります。最も大きな障害は以下の通りです：

  • ソーシャルグラフ: GitHubはオープンソースの主要な発見エンジンです。これを軽減するため、多くのメンテナーはGitHubリポジトリをアーカイブし、READMEに新しい正規のホームへのリンクを貼ります。

  • Ecosystem Friction: Forgejo ActionsはGitHub Actionsとの親和性を目指していますが、GitHub Actionsとは100%互換性はありません。特定の権限ブロックが無視されることがあり、一部の公式GitHub actionsは、非GitHubランナーで動作させるために特定のフォークを必要とします。

  • Tooling Gaps: Dependabotのような機能は、Renovateのような代替手段に置き換える必要があります。これには追加の設定とセルフホストが必要です。

コミュニティの視点

この移行に関する技術的な議論は、分散化への欲求求と、利便性の現実との間の緊張関係をハイライトしています。一部の人は、Gitの精神は本質的に分散型であると主張し、現在の業界の執着は単一のホストに集中することであり、それがその核心的な原則からの逸脱であると述べています。

"Gitは常に分散型であるべきものでした。問題は、Git周辺のすべてのツールがGitHubに中央集権化されてしまったことです。GitHubは、単にコードをホストするためのもう一つの場所です。"

他の人々は、Tangled (AT Protocol上で構築) や Radicle のような、単なる一中央集権的なホストから別のセルフホスト環境へ移動するのではなく、真に分散化された未来への道筋として、新興の代替案を提示しています。

最終的に、Forgejoへの移行は、重要なインインフラストラクチャ―――、国家政府のソースコードや開発者の生涯の仕事であっても―――、プラットフォームの所有権こそが、自律性の唯一の真の保証であるという認識が広がりつつあることを表しています。

Sources