2026 年 4 月 24 日、 GitHub のモデル学習ポリシー 個人向け Copilot プランについて変更されました。ユーザーがオプトアウトしない限り、GitHub は Copilot Free、Pro、Pro+、Max での対話を、入力、出力、コード断片、関連するコンテキストも含めて AI モデルの学習と改善に利用できます。Copilot Business と Enterprise のデータは、引き続き GitHub のデータ保護契約で保護されます。重要なのは、これが Copilot の対話データの話であって、GitHub 上に置かれたまま使われていないプライベートリポジトリの話ではないという点です。
同じ頃、別の理由から移行の議論が再燃しました。公開された自己ホスト型の Git インスタンスが、大量の自動化トラフィックを受け止めていたのです。Hacker News のある議論には、その問題に関する運用者の有用な報告が集まりました。 私にとって一つの時代の終わり: 自己ホストの git はもうやめる.
そこで「GitHub か自己ホストか」よりも役立つ問いが残ります。あなたが本当に解決したい懸念はどれでしょうか。
短いバージョン
答えは 3 つ。自分の状況に合うものを選んでください。
- A: オプトアウトして残る。Copilot の学習変更だけが懸念で、GitHub がまだチームの運用要件に合っているときはこれです。アカウント単位の設定を無効にして、仕事に戻りましょう。
- B: ハイブリッドで運用する。ネットワーク効果のため、公開 OSS は GitHub に残します。プライベートなコードは、VPN や IP 許可リストの内側にある自己ホストの Forgejo、Gitea、GitLab CE インスタンスへ移します。公開での広がりと非公開での管理が同時に必要なときはこれです。
- C: 完全に移行する。すべてを GitHub の外へ移します。規制、データ所在地、ガバナンス、または FOSS のみという方針で GitHub が選択肢から外れ、なおかつチームが運用コストを負担できるときはこれです。
読者の多くは立場 A か B です。立場 C を正当化するのは、より厳しいガバナンス、主権、価値観の要件であって、Copilot の設定だけではありません。
2026 年 4 月に実際に変わったこと
仕組みとしての変更は小さなものです。Copilot の設定で、個人の契約者は「Allow GitHub to use my data for AI model training」を Disabled にできます。GitHub は対象となる内容を、自社の機能やサービスとのやり取り、つまり入力、出力、コード断片、関連するコンテキストと説明しており、Copilot を一度も通っていないプライベートリポジトリの中身は含まれません。
Copilot Business と Enterprise にこのトグルは表示されません。これらのデータは GitHub のデータ保護契約で守られているからです。個人向けプランでは、設定を無効にすれば学習ポリシーへの懸念には対処できます。ただし、ベンダーが握るポリシーに依存すること自体への、より大きな異議までは解消しません。
Copilot の変更はきっかけにはなりますが、それだけで話が終わるわけではありません。チームはプラットフォームへの依存、GitHub に紐づいた ID、Actions を軸に組んだワークフロー、データ所在地、そして後でもう一度移りやすいかどうかも気にするはずです。これらは移行の問題であり、学習のトグルは設定の 1 つにすぎません。
この違いは重要です。オプトアウトはデータ利用の設定を 1 つ変えるだけですが、移行はホスティング、ID、連携、ポリシーを誰が握るかを変えます。2 つ目の決定のほうが、運用コストははるかに大きくなります。
3 つの立場を詳しく
この判断を 3 行に圧縮すると次のとおりです。詳細は下に続きます。
| あなたの懸念 | 答え | 何をすべきか |
|---|---|---|
| 自分の Copilot 対話データが学習に使われること | オプトアウトして残る（立場 A） | 設定を切り替えて、仕事に戻る |
| 米国ベンダーに置きたくないプライベートなコード + 隠したくない活発な OSS | ハイブリッド（立場 B） | プライベートリポジトリは VPN の内側で自己ホストし、公開 OSS は GitHub に残す |
| データ主権、規制業種、FOSS のみという原則、ベンダーからの完全な独立 | 完全移行（立場 C） | すべて移す。運用コストを予算に入れる |
立場 A: オプトアウトして残る
プライベートリポジトリを使う個人開発者や小規模チームで、不満が学習のデフォルト設定だけなら、答えはこれです。設定を切り替えるのは 1 分、1 回きり。一方の自己ホストは、少額の VPS 代、実際に試すバックアップ手順、GitHub 認証を前提にしていたせいで作り直す連携、そして最悪のタイミングで降ってくる時々のアップグレードや復旧作業を意味します。
自己ホストにはまだ価値がありえます。ただし、その繰り返し発生する作業が、本当に必要なものを買ってくれている場合に限ります。
最も強い反論はこうです。そのトグル自体もベンダーの決定である、と。GitHub は 2026 年に、この対話データを既定では学習に使わない状態から、既定で使う状態へ切り替えました。方針はまた変わりうるのです。
根っこにある懸念が「自分のコードについて米国のベンダーに一方的な決定をされたくない」なら、チェックボックスでは解決しません。あなたにとって立場 A は誤った答えです。立場 C まで飛んでください。
しかし懸念が具体的に「いまの自分の Copilot 対話データを学習に使われたくない」であり、次に何かが変わるまでは GitHub の設定を信じるつもりなら、立場 A が最も安上がりな正解です。安くて正しいことは、恥ずかしいことではありません。
立場 B: ハイブリッドモデルで運用する
ハイブリッドなホスティングは、公開での広がりと非公開での管理を切り分けます。
分け方はシンプルです。公開 OSS は GitHub に残します。ネットワーク効果、貢献者の流入、Dependabot、Actions のエコシステムは実質的な価値です。プライベートなコードは、VPN や IP 許可リストの内側にある自己ホストのインスタンスへ移し、公開インターネットからは決して到達できないようにします。
これが効くのは、脅威モデルの性質によります。Copilot の学習に関する懸念は、GitHub 経由で送った対話データにしか当てはまりません。AI スクレイパーによるトラフィックの問題（次節）は、公開されて到達可能なインスタンスにしか当てはまりません。非公開のハイブリッド構成は、その両方をかわします。
2〜10 人の非公開チームなら、Forgejo や Gitea には 2 vCPU と 4 GB RAM のほうが安全な出発点です。検索インデックス、パッケージ、CI が同じホストに同居するなら、さらに余裕を持たせてください。これは GitLab CE ではなく Forgejo/Gitea のサイジングとして扱ってください。 GitLab のシングルノード導入チュートリアル は、CI の負荷を除いても 8 vCPU と 7.2 GB のメモリから始まります。
Web UI を 80 番や 443 番でそのまま公開しないでください。ファイアウォール、プロキシ、VPN、メッシュネットワークのいずれかの層で制限します。CI ランナーは両側を担当できます。
プラットフォームの選択は、ハイブリッドモデルそのものより機能セットを大きく変えます。Forgejo と Gitea は軽めの非公開フォージに向き、GitLab CE は統合された CI/CD とレジストリのスタックも必要な場合により筋が通ります。
バックアップは手に負える作業ですが、git bundle 1 つで済ませないでください。 Forgejo の公式アップグレード手引き は、Forgejo が使うストレージ全体を同期の取れた時点でスナップショットしたものを信頼できるバックアップとし、それが現実的でない場合は forgejo dump に別途 PostgreSQL または MySQL のダンプを組み合わせる方法を挙げています。Forgejo でも Gitea でも、リポジトリ、データベース、設定、添付ファイル、LFS データはまとめて保持し、コピーをサーバー外に置き、復元を実際に試してください。
開発者のローカルクローンはコードなら復元できますが、イシュー、ユーザー、プルリクエストのメタデータ、添付ファイル、LFS オブジェクトのすべてまでは戻せません。プライベートなフォークを後から公開するなら、その時点で GitHub のミラーへ push してください。
立場 C: 管理権が要件になる場合の完全移行
完全移行が最もはっきり当てはまるのは、ベンダーからの独立が好みではなく要件になっている場合です。
際立つのは 3 つのグループです。監査、データ所在地、ベンダー管理のルールによって GitHub が使えない規制業種のチーム。主権要件が好みではなく方針として定められている公共部門や EU のチーム。そして Microsoft 傘下のインフラから離れたい FOSS のみの組織で、Linux サービスを運用できる人材をすでに抱えているところです。
コストは小さな VPS、継続的な保守、そして連携の喪失です。人が忘れがちなのはこの連携の喪失です。「Sign in with GitHub」で認証しているものはすべて、GitHub に残るか、別の ID プロバイダーが必要になります。
移行はリポジトリだけでなく依存関係を軸に計画してください。PR プレビュー、サードパーティ製 Actions、ボット、Webhook、パッケージレジストリ、「Sign in with GitHub」連携は、新しい認証情報、新しいワークフロー、あるいは代替サービスを必要とするかもしれません。スターやウォッチャーは新しいフォージのネイティブなレコードにはならないため、公開プロジェクトは既存の発見されやすさの一部も手放すことになります。
正式なリモートを切り替える前にドライランを行ってください。代表的なリポジトリを 1 つ移し、その連携を作り直し、イシューとプルリクエストの履歴を確認し、切り戻し手順を文書化します。プラットフォームの比較は、その依存関係の棚卸しの後です。
サーバーを自分で運用せずに非営利の統治を求めるチームには、Codeberg が検討に値します。
主権についての実務的なヒント。EU のデータ所在地を理由に自己ホストを選ぶなら、データセンターの場所が効いてきます。フランクフルトやアムステルダムのような拠点は、地味ですが正解です。バージニアで最も安い VPS は、あなたの DPA の助けにはなりません。
公開 Git ホスティングの運用コスト
公開での自己ホストは、インターネットに面したあらゆるアプリケーションを襲うのと同じ自動化トラフィックにフォージをさらします。違うのは、リポジトリのページに blame ビュー、アーカイブ、コミット履歴といった重い経路が含まれる点です。以下の報告は個々の運用者の経験であり、ベンチマークではありません。
先に触れた自己ホスト Git の議論では、ある運用者が 60 日間で cgit インスタンスに 37,212,377 件のリクエストがあり、その 99% 超がボットに分類されたと報告しています。
同じ議論の中で kstrauser は、Forgejo インスタンスへのリクエストを 1 日約 600,000 件からおよそ 1,000 件まで下げたと述べています。ただしそれは、標準的な対策の上に JavaScript とクッキーによるチャレンジを重ねて初めて実現しました。
ほかの運用者は fail2ban、GeoIP によるブロック、自律システム単位のブラックホール化、そしてリポジトリをホスティング型のプラットフォームへ戻すことを挙げました。これらの報告が示すのは起こりうる失敗の形であって、普遍的なトラフィックの基準値ではありません。
これが難しい仕組み上の理由はこうです。IP 単位の単純なレート制限は、住宅用プロキシを次々に切り替えるトラフィックには通用しないことがあります。スクレイパー群はリクエストを十分な数の IP に分散でき、どの 1 つのアドレスも乱用には見えないまま、それでもサーバーは合計で押しつぶされます。
JavaScript やクッキーによるチャレンジは、粗いスクレイピングを減らせます。ただし JavaScript を使わない利用者を締め出すこともあり、すべての経路に適用すると HTTPS 経由の Git を壊しかねません。CDN のキャッシュは繰り返しの読み取りには効きますが、アーカイブ、blame ビュー、コミットごとのページのような一意で重いエンドポイントにはあまり効きません。
チャレンジが変えるのは、その経済性です。 Anubis はフォージの前に立ち、サーバーが保護されたページを返す前に、クライアントにチャレンジ、たとえば小さなプルーフ・オブ・ワークの計算を完了させます。これにより大量クロールのコストが上がります。あくまで緩和策であって、保証ではありません。
ブラウザ向けチャレンジは選択的に適用してください。Git 操作用に SSH は使える状態のままにし、その経路を保護する前に HTTPS 経由の Git を試してください。Git クライアントに返されたチャレンジページは、役に立つ検証ではなく、失敗したクローンになります。
GitHub は、この種のトラフィックをホスティングサービスの一部として吸収しています。一方、公開された Forgejo や cgit のインスタンスは、容量計画、不正利用対策、キャッシュ、緩和策をすべてあなたに残します。移行判断で重要なのは、ソフトウェアの素の費用ではなく、この運用の肩代わりが移ることです。
ハイブリッドモデルが次善の策ではなく第一級の選択肢である理由がこれです。プライベートなコードは VPN の内側にあり、スクレイパーは到達できません。公開 OSS は GitHub にあり、ボットのトラフィックは GitHub の不正利用対策インフラが引き受けます。
それでも公開の自己ホスト型フォージが欲しいなら、ログ、レート制御、キャッシュ、ボット対策、監視、そしてブラウザチャレンジに依存しない検証済みの Git トラフィック経路まで予算に入れてください。スクレイパー対策は例外的な事態ではなく、通常運用の一部として扱いましょう。
OSS メンテナーにとってのネットワーク効果の問題
ここでは、かなり具体的な読者に向けて書いています。あなたは OSS プロジェクトのメンテナーです。コントリビューター 20 人、スター 200、そして活発なイシュートラッカー。そしてそれを GitHub の外へ移すことを検討している。
何と引き換えにするのか、正直になってください。コントリビューターに見つけてもらえること、github.com という暗黙の信頼の印、Dependabot、CodeQL、そして GitHub 認証を前提にしたサードパーティのエコシステムです。どれも他所で不可能ではありません。ただし、すべてが摩擦になります。
私なら、こんな目安を挙げます。プロジェクトの価値の大半がコードにあるなら、自己ホストは正当化しやすい。
コードは持ち運べます。しかしその価値の多くが、コントリビューター、イシュー、検索での見つけやすさ、そして github.com にまつわる信頼に依存しているなら、離れることは、プロジェクトを機能させている要素の一部を、メンテナーの気が晴れるものと引き換えにする行為です。理由が十分に大きければ正当な取引です。何かを主張するためだけにやるなら、割に合わない取引です。
Codeberg のプラットフォーム概要 は、非営利団体 Codeberg e.V. が運営する Forgejo ベースのサービスを説明しています。OSS メンテナーにとってこれは、フォージを自分で運用する保守負担なしにコミュニティ統治を得られるということです。
アップグレードの義務を負わずにコミュニティ統治を得たい OSS 寄りのチームにとって、これは公開フォージを自分で運用するより運用面の飛躍が小さくて済みます。SourceHut はワークフローをかなり意識的に変えるものなので、別途評価が必要です。
問題を解く最小の変更を選ぶ
リモートを切り替える前に、要件を 1 文で書き出してください。Copilot の対話データによる学習を止めたいのか、公開ホスティングと非公開ホスティングを分けたいのか、それとも GitHub をアーキテクチャから外したいのか。要件に名前を付けられないなら、まだ移行しないでください。
移行するなら、まず代表的なリポジトリ 1 つでパイロットを回してください。正式なリモートを切り替える前に、認証、Actions、Webhook、パッケージ公開、プレビュー環境、イシュー履歴、LFS データ、切り戻し手順を洗い出しておきます。
クラウドジーの ワンクリックの Forgejo デプロイ は、ハイブリッドモデルの非公開側を手早く用意する方法です。任意の Linux VPS 上に手動でインストールしても構いません。どちらの道を選ぶにせよ、Web UI は非公開に保ち、アプリケーションの状態をまるごとバックアップし、重要なリポジトリを移す前に復元を試してください。
root権限、NVMe、AMD EPYCのパワーを備えたLinux VPSで開発を。
Linuxプランを見る管理権が役に立つのは、それが要件を解決し、しかもチームが続けられる運用コストで収まっているときだけです。
よくある質問
Copilot の学習ポリシー変更を理由に GitHub から移行すべきですか。
自動的にそうなるわけではありません。懸念が Copilot の対話データをモデル学習に使われる点だけなら、アカウント単位の設定を無効にするのが最小で正しい対処です。移行が意味を持つのは、データ所在地、ガバナンス、ベンダー非依存、FOSS のみといったより強い統制も必要な場合です。
GitHub は自分のプライベートリポジトリすべてで学習しているのですか。
いいえ。ここで扱っているポリシー変更が対象とするのは、Copilot を通じて送信された該当の対話データ、つまり入力、出力、コード断片、関連するコンテキストです。GitHub に保存されているプライベートリポジトリがすべて自動的にモデル学習に使われる、という意味ではありません。
Git を自己ホストすれば必ずプライバシーは高まりますか。
そのように運用した場合に限ります。VPN や IP 許可リストの内側にある非公開フォージは露出を減らせますが、公開されて到達可能なインスタンスは、パッチ適用、監視、ボット対策、アクセス制御、バックアップという責任を増やします。ふだんは GitHub が引き受けている部分です。
自己ホスト型の Git プラットフォームはどれを選ぶべきですか。
軽めの非公開フォージが欲しいなら Forgejo か Gitea を選んでください。統合された CI/CD とパッケージまたはコンテナのレジストリが、より高いリソースと保守の要求に見合うほど重要なら GitLab CE を選びます。
小規模チームの場合、Forgejo や Gitea にはどのくらいの VPS が必要ですか。
2〜10 人の非公開チームなら、2 vCPU と 4 GB RAM のほうが安全な出発点です。検索インデックス、パッケージ、巨大なリポジトリ、CI ランナーが同じホストに同居するなら容量を足してください。GitLab CE はより多くのリソースを要するため、別途サイジングします。
正式なリモートを切り替える前に、何を確認しておくべきですか。
代表的なリポジトリ 1 つでパイロットを回してください。すべてを移す前に、イシューとプルリクエストの履歴、認証、Actions または代替の CI ワークフロー、Webhook、パッケージ公開、LFS データ、プレビュー環境、バックアップ、復元、切り戻し手順を確認します。
