この記事の面白いところは、GitHub離れの理由を「最近よく落ちるから」にしていない点です。
もちろん、GitHubの障害は実際に起きています。記事では2025年5月〜2026年4月の間に257件のincident（障害・トラブル）があり、そのうち48件が重大だったと紹介されています。これは正直、なかなかの数字です。
でも著者は、そこを本題にしていません。
本当の理由はもっと根っこにある。つまり、
「そのサービスは、結局だれのものなのか」
という話です。
GitHubは見た目こそ開発者向けの便利な場所ですが、著者から見ると、今はもう「自分のコードを安心して置いておける中立地帯」ではない。
ここが記事の核心で、個人的にもかなり納得感がありました。
サービスの使い勝手が良いことと、長期的に信頼できることは別問題なんですよね。
著者は、自分のコードをGitHubからForgejoへ移しました。
しかも単なる試し置きではなく、self-hosted、つまり自分でサーバーを用意して運営する形です。
記事によると、著者の新しいGitホストは code.jorijn.com。
Forgejo v15 LTS を、ハードニングされたNUC（小型PCを安全寄りに固めた構成）で動かしているそうです。
ここでいう LTS は “Long Term Support” の略で、長めに保守される安定版という意味。
要するに、「新機能モリモリの実験版」ではなく、長く安心して使うための堅実な版です。
さらに、GitHub Actions相当の仕組みも使っていて、KVMで隔離された週次再構築のrunnerを運用しているとのこと。
細かい部分は専門的ですが、ざっくり言うと、
という感じです。
こういう設計を見ると、「ただGitHubをやめました」ではなく、かなり本気で自分で守れる形に寄せているのがわかります。
著者は、GitHubの障害を無視しているわけではありません。
ただし、障害はあくまで表面に出ている症状で、本質はそこではないと見ています。
記事では、GitHubの大規模障害として、たとえば次のような話が出てきます。
数字だけ見ると、たしかに「うわ、しんどいな」と思います。
でも著者の言い分は、もっと冷静です。
大規模システムは壊れる。
問題は、GitHubがその壊れ方を引き起こしている背景に、AIへの強い傾倒があることだ。
つまり、障害そのものよりも、会社の方向性が気になっているわけです。
GitHubは今、AI機能をどんどん押し進めていて、その負荷がシステム全体に重くのしかかっている、と著者は見ています。
ここ、かなり重要です。
「壊れたから別のサービスへ」なら話は簡単ですが、「サービスの進みたい方向が、自分の価値観とズレてきた」なら、移行は思想の問題になります。
著者はまさにそこを重視しているのだと思います。
記事では、GitHubのCEOがいなくなったことも大きな転換点として扱われています。
以前はGitHubに独立したCEOがいて、Microsoft傘下とはいえ、ある程度はGitHubとしての意思決定がありました。
でも2025年8月にCEOが退き、その後GitHubはMicrosoftのCoreAI部門に組み込まれました。
CoreAIは、Copilotを含むAIスタック全体を作る部署です。
つまり今のGitHubは、ざっくり言えば
「開発者向けの道具箱」より、「MicrosoftのAI戦略の一部」
になっている、という見方です。
これはかなり大きい変化です。
なぜなら、ユーザーがGitHubに預けているのは単なるファイルではなく、ソースコード、Issue、レビュー、履歴、開発の文脈そのものだからです。
著者は、これをもはや「中立な保管場所」とは見ていません。
個人的にも、この感覚はすごくわかります。
サービスの看板が同じでも、内部の意思決定が変わったら、別物だと思ったほうがいい場面はあります。
ここはかなりセンシティブなポイントです。
記事によると、GitHubは2026年4月24日から、Copilot Free / Pro / Pro+ のユーザーがやりとりしたデータを、AIモデルの訓練・改善に使う設定をデフォルトでオンにしました。
つまり、何もしないと使われる。
使われたくないなら、ユーザー側で止める必要がある。これが opt-out です。
これの何が嫌かというと、著者の立場では、
という点です。
たとえば、あなたがあるオープンソースプロジェクトの保守者だったとしても、
「このリポジトリの中ではAI学習に使わないで」とまとめて言えない。
それはかなり気持ち悪い、というのが著者の感覚です。
ここは賛否が分かれるでしょう。
「便利なAIの改善のためなら仕方ない」と考える人もいるはずです。
でも著者のように、自分のコードや文脈を、他人のAI戦略に吸われたくないと考える人にとっては、かなり重い変更です。
さらに著者は、データの置き場所だけでは安心できないと指摘します。
GitHubもMicrosoftも米国企業なので、米国法の対象になる。ここで出てくるのが FISA Section 702 や CLOUD Act です。
難しい法律名ですが、かなり雑に言えば、
という理解でだいたい足ります。
つまり、データセンターがEUにあっても、「会社が米国企業である」限り、法的リスクは消えない。
これが厄介なんです。
記事では、Microsoftの弁護士がフランス上院で、「EU内のデータが米国政府からの静かなアクセスから安全だとは保証できない」と証言した件にも触れています。
この発言、かなり重いです。
企業側がそこを断言できないなら、ユーザー側は「大丈夫だろう」と楽観するわけにはいかないですよね。
個人的には、ここが一番“地味だけど本質的”な論点だと思います。
UIが良いとか、障害が少ないとかより、法の支配がどこにあるかのほうが、長期的にはずっと大きいからです。
著者が自分の移行を正当化するうえで、かなり強調しているのがオランダ政府の判断です。
オランダでは「Open, tenzij」（原則公開、ただし例外あり）という方針があり、公費で作られたソフトウェアは、原則としてオープンソースで公開する必要があります。
そのため、政府は自分たちが本当に管理できる場所にコードを置く必要がありました。
そこで選ばれたのが、code.overheid.nl の Forgejo です。
ここが面白いのは、選択肢がGitLabではなくForgejoだったこと。
GitLabにも self-hosted の実績がありますが、著者によれば、Forgejoは
という点で評価されています。
この「デジタル主権」という言葉、最近よく聞きますが、簡単に言えば
重要な仕組みを、他社や他国の都合で勝手に動かされないようにすること
です。
政府がそこを真剣に考えた結果Forgejoを選んだ、というのは、かなり象徴的です。
著者が「自分だけの変わった選択ではない」と感じたのも自然でしょう。
著者はGitLabも真剣に検討したと書いています。
正直、ここはかなり現実的な比較です。GitLabは機能が多く、企業向けでは成熟しています。UIも洗練されている。
一方で、著者はForgejoを選びました。
その理由は大きく2つ。
GitLabは open core 型です。
つまり、基本部分は無料でも、欲しい機能の一部は有料の上位版に入っていることが多い。
著者のように「将来も含めて自由度を確保したい」と考える人には、ここが引っかかる。
Forgejoは、以前のGiteaから分岐した経緯があり、コミュニティのコントロールを守る方向に進んできました。
さらに、ライセンスも GPLv3+ に切り替えています。
これはざっくり言うと、コードを閉じ込めにくくするライセンスです。
Forgejoは Codeberg e.V. という非営利団体のもとで運営されています。
ここがけっこう大事で、単に「オープンソースです」ではなく、誰が意思決定しているのかが見える。
Gitのホスティングサービスは、便利なだけに「気づいたらプラットフォームに支配されていた」ということが起きやすいです。
だから、運営主体が非営利で、コミュニティ主導というのは、思想としてかなり筋が通っています。
私はここ、かなり好きです。
この記事の本質は、GitHub批判そのものではありません。
著者はたぶん、GitHubが開発者にとって便利なサービスであることも認めているはずです。
ただし、それでもなお、
という理由で、「ここに長く依存するのは怖い」と判断したわけです。
これは、個人や組織にとってかなり示唆的です。
“無料で便利”なサービスほど、依存するときの代償は見えにくい。
そしてその代償は、ある日いきなり「設定変更」や「組織再編」や「利用規約改定」という形で見えてくる。
正直、かなり現代的な怖さです。
著者の移行は、単なるツール変更ではありません。
むしろ、どこまでを他社に預け、どこからを自分で持つのかという、現代の開発者にとっての主権の話です。
Forgejoは、派手さではGitHubに負けるかもしれない。
GitLabのほうが見慣れている人も多いでしょう。
でも著者は、長期的な安心感とコントロールを重視してForgejoを選んだ。
しかも、それがオランダ政府の判断とも重なっている。これはなかなか象徴的です。
個人的には、こういう移行は今後もっと増えるのではないかと思います。
便利だから中央集権プラットフォームを使う、でも大事なものは最終的に自分で握りたい。
その折り合いをどうつけるか。
この記事は、その悩みをかなり正面から、しかも実務的に示しているのが良かったです。
参考: Why I'm leaving GitHub for Forgejo | Jorijn Schrijvershof
