著者はGitHubからself-hostedのForgejoへ移行した
理由は「障害が多いから」ではなく、自分のコードの主導権を取り戻したいから
GitHubは今やMicrosoftのAI組織の一部になっており、昔のような「独立したGitHub」ではない
Copilotのデータ利用が**opt-out（拒否しない限り利用）**に変わり、利用者の操作データがAI学習に使われうる
さらに、米国法の管轄という問題があり、EUにデータを置いても安心とは言い切れない
著者は、同じような理由でオランダ政府がForgejoを採用したことを重く見ている
Forgejoは、完全オープンソースで、コミュニティ主導の運営という点が魅力

「GitHubを離れる」って、ただの気分の話じゃない

この記事の面白いところは、GitHub離れの理由を「最近よく落ちるから」にしていない点です。
もちろん、GitHubの障害は実際に起きています。記事では2025年5月〜2026年4月の間に257件のincident（障害・トラブル）があり、そのうち48件が重大だったと紹介されています。これは正直、なかなかの数字です。

でも著者は、そこを本題にしていません。
本当の理由はもっと根っこにある。つまり、

「そのサービスは、結局だれのものなのか」

という話です。

GitHubは見た目こそ開発者向けの便利な場所ですが、著者から見ると、今はもう「自分のコードを安心して置いておける中立地帯」ではない。
ここが記事の核心で、個人的にもかなり納得感がありました。
サービスの使い勝手が良いことと、長期的に信頼できることは別問題なんですよね。

著者が移った先はForgejo

著者は、自分のコードをGitHubからForgejoへ移しました。
しかも単なる試し置きではなく、self-hosted、つまり自分でサーバーを用意して運営する形です。

記事によると、著者の新しいGitホストは code.jorijn.com。
Forgejo v15 LTS を、ハードニングされたNUC（小型PCを安全寄りに固めた構成）で動かしているそうです。

ここでいう LTS は “Long Term Support” の略で、長めに保守される安定版という意味。
要するに、「新機能モリモリの実験版」ではなく、長く安心して使うための堅実な版です。

さらに、GitHub Actions相当の仕組みも使っていて、KVMで隔離された週次再構築のrunnerを運用しているとのこと。
細かい部分は専門的ですが、ざっくり言うと、

自動処理をする作業用マシンを
本体から分離し
毎週作り直して
変なものが残りにくいようにしている

という感じです。
こういう設計を見ると、「ただGitHubをやめました」ではなく、かなり本気で自分で守れる形に寄せているのがわかります。

理由1: 障害よりも「自分のものじゃない」ことが問題

著者は、GitHubの障害を無視しているわけではありません。
ただし、障害はあくまで表面に出ている症状で、本質はそこではないと見ています。

記事では、GitHubの大規模障害として、たとえば次のような話が出てきます。

ある日、merge queueの不具合でマージ済みのコミットが戻るような事故があった
その影響が多数のrepositoriesとpull requestsに及んだ
別の日には、検索やIssue、Packagesが6時間以上落ちた
2025年10月には、macOS runnerの長時間障害もあった

数字だけ見ると、たしかに「うわ、しんどいな」と思います。
でも著者の言い分は、もっと冷静です。

大規模システムは壊れる。
問題は、GitHubがその壊れ方を引き起こしている背景に、AIへの強い傾倒があることだ。

つまり、障害そのものよりも、会社の方向性が気になっているわけです。
GitHubは今、AI機能をどんどん押し進めていて、その負荷がシステム全体に重くのしかかっている、と著者は見ています。

ここ、かなり重要です。
「壊れたから別のサービスへ」なら話は簡単ですが、「サービスの進みたい方向が、自分の価値観とズレてきた」なら、移行は思想の問題になります。
著者はまさにそこを重視しているのだと思います。

理由2: GitHubはもう“昔のGitHub”ではない

記事では、GitHubのCEOがいなくなったことも大きな転換点として扱われています。

以前はGitHubに独立したCEOがいて、Microsoft傘下とはいえ、ある程度はGitHubとしての意思決定がありました。
でも2025年8月にCEOが退き、その後GitHubはMicrosoftのCoreAI部門に組み込まれました。

CoreAIは、Copilotを含むAIスタック全体を作る部署です。
つまり今のGitHubは、ざっくり言えば

「開発者向けの道具箱」より、「MicrosoftのAI戦略の一部」

になっている、という見方です。

これはかなり大きい変化です。
なぜなら、ユーザーがGitHubに預けているのは単なるファイルではなく、ソースコード、Issue、レビュー、履歴、開発の文脈そのものだからです。

著者は、これをもはや「中立な保管場所」とは見ていません。
個人的にも、この感覚はすごくわかります。
サービスの看板が同じでも、内部の意思決定が変わったら、別物だと思ったほうがいい場面はあります。

理由3: Copilotのデータ利用が“デフォルト許可”になった

ここはかなりセンシティブなポイントです。

記事によると、GitHubは2026年4月24日から、Copilot Free / Pro / Pro+ のユーザーがやりとりしたデータを、AIモデルの訓練・改善に使う設定をデフォルトでオンにしました。
つまり、何もしないと使われる。
使われたくないなら、ユーザー側で止める必要がある。これが opt-out です。

これの何が嫌かというと、著者の立場では、

リポジトリ単位で止められない
各コントリビューターが個別に設定しなければならない
プライベートリポジトリでも、編集時の断片や文脈が対象になりうる

という点です。

たとえば、あなたがあるオープンソースプロジェクトの保守者だったとしても、
「このリポジトリの中ではAI学習に使わないで」とまとめて言えない。
それはかなり気持ち悪い、というのが著者の感覚です。

ここは賛否が分かれるでしょう。
「便利なAIの改善のためなら仕方ない」と考える人もいるはずです。
でも著者のように、自分のコードや文脈を、他人のAI戦略に吸われたくないと考える人にとっては、かなり重い変更です。

理由4: 米国法の問題は、EUに置いても消えない

さらに著者は、データの置き場所だけでは安心できないと指摘します。
GitHubもMicrosoftも米国企業なので、米国法の対象になる。ここで出てくるのが FISA Section 702 や CLOUD Act です。