- 著者は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 です。