次のGitHubをつくるのは誰か。コード、AI、プラットフォームの力

GitHubは、ソフトウェアを保存し、共同で開発し、公開するためのプラットフォームです。その基盤にあるのがバージョン管理ツールのGitです。ファイルの変更を記録し、並行した開発ブランチを扱い、別々の作業結果を統合するのを助けます。Gitが技術的な土台を担い、GitHubが不具合報告、議論、プルリクエスト、自動化された処理などの協働機能を加えています。

Gitは2005年、Linuxカーネルの開発から生まれました。GitHubは2008年に設立され、2008年4月10日に一般公開されました。10年後、Microsoftが75億米ドルで買収し、2018年10月26日に買収完了を発表しました。開発者の居場所だったサービスが、ソフトウェア世界の中核インフラになったのです。Git、GitHub、Microsoft

2026年の今、従来の開発者ではない人まで、誰もがGitHubアカウントを持ち始めたように感じます。小さなアプリ、個人用ダッシュボード、リポジトリ接続を求めるAIツール。これは意図的に大げさにした私の実感で、非開発者についての統計ではありません。それでも、ソフトウェアをつくる敷居が下がり、下のインフラに新たな負荷がかかっているという変化は重要です。

だからこそ、次のGitHubを誰がつくるのかが気になります。Anthropicは社内のバージョン管理を再構築し、Cloudflareは新しいGitプラットフォームの構成要素を提供しています。同時に、GitHubの信頼性も公に問われています。争点は使いやすいマージボタンだけではありません。ソフトウェアが生まれ、検証され、本番へ進む場所を誰が握るかという話です。

利用者がソフトウェアのつくり手になる

この変化は今年より前から始まっています。GitHubのOctoverse 2025では、すでに1億8,000万人超の開発者と、年間3,600万人超の新規利用者が報告されました。新規開発者の約80%が最初の週にCopilotを使ったとも述べています。ベンダー自身の調査であり、成長のすべてをAIが生んだ証拠ではありません。しかし、GitHubへの参加とAIツールがいかに結びついているかは分かります。

以前は小さなツールでも、役立つ出発点に到達するまで相応のプログラミング学習が必要でした。今はアイデアを説明し、コーディングエージェントと段階的に実現できます。データ、権限、本番システムを扱うほど専門知識は不可欠です。それでも、発想から最初に動くプログラムまでの距離は短くなりました。

オープンソースにも大きな可能性を感じます。ドキュメントを分かりやすくする、テストを増やす、不具合を調べる、インターフェースを理解する、放置したアイデアを再開する。AIが開発を速める具体例です。ただし、どのプロジェクトも品質が向上したという意味ではありません。リポジトリが増えても保守されるソフトウェアとは限らず、プルリクエストが保守担当者の負担を増やすこともあります。

私は生成行数より、どれだけ理解し、検証し、維持できるかに関心があります。コードが速く生まれるほど、残す変更を判断する人と仕組みにボトルネックが移ります。

ステータスページのクリスマスツリー

ヘッダー画像はMarek Šuppa氏のThe Missing GitHub Status Pageです。2026年10月15日の画面には、90日間で65件のインシデント、プラットフォーム稼働率93.70%とあります。一方、Git Operationsは99.55%です。その画面の数字であり、私が新たに測定した現在の可用性ではありません。

この非公式ページは公開ステータス報告から時間帯を再構成し、重なる障害区間を統合します。全体値は複数サービスをまとめたものです。各インシデントでGitクローン、プルリクエスト、Actionsが全利用者に同時停止したことを意味しません。93.70%を、そのまま「6.30%の時間GitHub全体が完全停止」とは読めません。意味は集計方法と対象インシデントによります。

それでも画像は痛いところを突いています。バージョン管理プラットフォームは生産工程の一部です。レビュー画面に入れない、ビルドが止まる、APIに障害があるだけで、コードが完全にローカルにあってもリリースは遅れます。その工程にとっては、連鎖全体が動くことが重要です。

この図は、AIが障害を起こした証拠でもありません。代替サービスが注目される理由は説明しますが、個々の原因は対応する障害報告で判断する必要があります。

GitとGitHubを分けて考える理由

GitHubの障害だけでGitのデータモデルが間違っているとは言えません。完全なローカルコピーがあれば、変更の記録、過去バージョンの比較、ブランチ作業を続けられます。事業者が常に到達可能である必要はありません。この独立性はGitで特に価値を感じる性質です。

リポジトリの周囲に組み立てたサービスは別です。承認、テスト、成果物、デプロイがプラットフォーム依存なら、ローカルコピーだけで全工程は続けられません。コードは分散していても、作業工程は強く集中している場合があります。

つまり課題は二つです。プラットフォームの信頼性と、データ量や作業方法に合うバージョン管理。ホスティングを変えてもすべてのスケール問題は解決しません。逆に、プラットフォームの不調だけでGit全体の置き換えが正当化されるわけでもありません。

Anthropicが特殊な規模のために開発したScion

Anthropicによると、2026年5月の日次マージは約2,500件、9月には3万件超になりました。主ブランチの履歴は約100GB、圧縮作業コピーは25GB超、CIだけで1日約2,500万回のチェックアウトを行います。記載された1日600PB超の転送量は、単純に毎回全データを取得した場合の試算で、実測トラフィックではありません。

その答えがScionです。Anthropicは、レビュー用のAntiqueや周辺インフラも含め、5か月で移行したと説明しています。Scionは常時接続のクライアントを前提に、バージョン操作をサーバーへ移します。ファイルは必要時に取得し、多くの問い合わせをAPIで直接処理するため、ジョブが質問のたびにローカルリポジトリを持つ必要がありません。

同社自身が示す限界が重要です。Scionは一般的なGit代替でも、万人向けに発表された公開GitHubでもありません。巨大なモノレポと自社のエージェント負荷に特化しています。既存のGitエコシステムへ知見を共有する意向もあります。「Anthropicが次のGitHubをつくる」は、せいぜい技術的な方向転換の表現で、すでに使える競合製品の意味ではありません。

小さなクライアントが大きな差を生む理由

この考え方はAnthropic規模でなくても理解できます。自動処理が、二つのバージョン間で特定の設定ファイルが変わったかだけを確認するとします。必要なのは限定的な答えです。大きなローカル環境の準備に、確認自体より多くの資源を使うかもしれません。

単発なら目立たなくても、短命な環境が大量にあると、繰り返す準備、転送、片付けが資源を大きく消費します。必要なデータだけを返すサービスは、その計算を変えます。これは設計上の比較であり、すべての小さなリポジトリに中央サーバーが必要な証拠ではありません。

代償は、接続先サービスへの依存です。サーバーへ仕事を移すほど、障害、権限、復旧、処理能力の限界を真剣に扱う必要があります。ローカルデータを減らす利便性は、遠隔サービスが応答しなくなると裏返ります。

慣れた前提を問い直す姿勢は好きです。ただし、普遍的な推奨にはしません。小規模プロジェクトでは、完全なローカルGit履歴が簡単さ、速さ、独立性の適切な釣り合いを与えることもあります。

CloudflareはGitを保ち、リポジトリをプログラム可能にする

CloudflareのArtifactsは別の道です。4月に紹介された、Git互換インターフェースを持つバージョン付きストレージです。APIでリポジトリを作成、取り込み、フォークでき、通常のGitクライアントも使えます。プロジェクト、タスク、エージェントセッションごとに分け、コードと文脈を版管理する利用法を示しています。各リポジトリを永続的な職場として手作業で準備するのではなく、基盤をプログラムから用意できます。

Git互換性には戦略的価値があります。既存ツールや慣れた工程が導入を容易にします。新製品は、全く新しいプロトコルまで同時に広める必要なく、協働の問題に集中できます。

10月には有料Workersプラン利用者向けのオープンベータを発表しました。新しい連携はWorkers Buildsやプレビュー環境につながります。イベントで自動レビューを起動でき、リポジトリ単位のトークンでアクセスを絞れます。CloudflareはWorkersとArtifactsの上で次のGitプラットフォームをつくるよう他社や開発者を明確に招いています。プラットフォームへの野心を持つ基盤ですが、同等の社会的・組織的生態系を備えた完全なGitHubではありません。

興味深いのは、境界の違いです。Anthropicは自社の巨大な開発システムを最適化し、Cloudflareは他者の製品の土台を提供します。人とエージェントと共同判断の接点は、依然として独立した製品課題です。

企業がこの場所を欲しがる理由

Anthropicが直接説明している理由は、自社のボトルネックです。研究や製品開発がバージョン操作を待つと、時間と計算資源を失います。Scionが公開製品にならなくても、社内基盤の改善には価値があります。

さらに私は、長い工程全体でエージェントを役立てる戦略的関心もあると見ます。関数を書けるモデルは有益です。プロジェクトを理解し、検証可能な変更を準備し、既存インフラと連携するエージェントなら日常業務へもっと深く入れます。これは私の経済的解釈で、Anthropicが確認したScion販売計画ではありません。

Cloudflareはインフラ事業との関係がより直接的です。アプリがWorkersで動き、開発データがArtifactsにあれば、同じ基盤へより多くの仕事が集まります。Artifactsは操作量と保存データ量による課金と説明されています。エージェントが増えると、リポジトリ、アクセス、計算も増え得ます。個々の工程の採算は実際の利用量次第です。

統合は定着も生みます。Gitリポジトリ単体の移動は比較的簡単でも、専用API、エージェント工程、イベント、権限、プレビュー、デプロイをまとめて移すのは大変です。便利に連動するほど、事業者を変える実務負担は増えます。

こうした動機と技術的利益は矛盾しません。現実の問題を解決しながら、提供者の立場を強めることはできます。だからこそ、快適な連携が疑問視されない依存になる前に、両面を見たいのです。

コードにはプログラム本文以上のものがある

そして、学習データもこの議論に入ります。潜在的な戦略利益として注目すべきですが、すべての新Gitプラットフォームをそれだけで説明するのは安易です。

リポジトリは現在の解答以上を含みます。履歴には最初の試み、失敗したテスト、レビューが拒否した理由、最終的に受理された修正が残り得ます。コーディングシステムの開発では、課題、試行、フィードバック、検証可能な結果が結びつくことに価値がありそうです。

架空の例で考えます。エージェントが日付計算の不具合を直します。初案は既存テストに通りますが、追加した年越しテストに落ちます。レビュー担当が誤った前提を説明し、次の修正で解消します。学習価値は完成コードだけでなく、もっともらしい失敗から理由のある解答へ至る道にもあります。事業者が実際に利用するか、利用する権利があるかは別問題です。

生成が安くなってもコードの価値は消えません。信頼できる要件、記録された判断、良いテスト、保守経験、実証済みの連動動作には今も労力が要ります。生成ファイルの山では置き換えられません。提案が無限に出るほど、本当に問題を解決した証拠の価値が上がります。

これは経済的・技術的可能性についての私の評価です。取り上げた発表は、AnthropicがScion経由で他者の非公開リポジトリを集める証拠でも、Cloudflareが自社コーディングモデルを学習させるためArtifactsを運営する証拠でもありません。

学習の話で本当に区別すべきこと

開発データへのAIの関心は単なる想像ではありません。GitHubは2026年3月、4月24日から一部個人向けCopilotプランの対話データを、拒否設定がない場合に学習へ利用すると説明しました。能動的なCopilot利用時のデータと、保存されている非公開リポジトリの内容は区別し、後者を一律に読み出すものではないとしています。Copilot BusinessとEnterpriseは異なる保護対象です。GitHub Copilot

一方Anthropicは、商用製品の入出力を既定ではモデル学習に使わないと説明しています。任意のフィードバックや明示参加のプログラムは別の扱いになり得ます。これはあらゆる個人プランや設定への一律の約束ではありません。Anthropic

新サービスなら、何を保存するだけなのか、何を応答のため処理するのか、何を改善や学習に使うのかを知りたいです。別々の処理です。エージェントがコードを扱うために処理する必要があっても、モデルへ恒久的に取り込む許可が自動的に生じるわけではありません。

オープンソースという呼び名も、利用上のすべてを解決しません。公開閲覧、ライセンス、機密情報、サービス規約は分けて考える必要があります。分かるデータ利用方針は、使えるAPIと同じく製品の一部です。

次のGitHubには、より良い判断を可能にしてほしい

最も都合のよい未来像は、無数のエージェントが無限にコードを生成し、別のエージェントが全部承認するプラットフォームでしょう。私は納得していません。同じ誤った前提を共有するシステムが互いに賛成しても、独立した証拠にはなりません。

役立つ基盤には、変更が果たす依頼、出発点の版、実行した検査、受け入れの責任者を示してほしいです。並行した変更が単独では正しそうでも、組み合わせると壊れることがあります。高速なマージでこの問題は消えません。

エージェントの文脈にも境界が要ります。タスク記述、ログ、設定に、どんなリポジトリや外部実行環境にも渡してよいとは限らない情報が含まれます。セッションの保存は開発支援だけでなく、新しいデータ集合も生みます。アクセスと保存期間を意識して設計すべきです。

オープンソースでは、人間の側面も欠かせません。保守担当への信頼、理解できる議論、何年も世話をする意思。高速なホスティングは支援できますが、自動活動の増加だけでは代替できません。

GitHubへの挑戦は始まったが、後継は未定

基礎的なツールまで問い直すのは健全だと思います。AIがソフトウェアをつくる人を増やすなら、その仕事に従来の基盤が合うかを問うのも当然です。

Anthropicは特殊な内部再構築を示し、Cloudflareは新製品へ基盤を開きます。GitHubには今も成熟したエコシステムがあり、代替者はそれを置き換えるか有意義に補う必要があります。新しい保存設計だけでは競争は決まりません。

私にとっての問いは、追跡可能性、独立性、データの管理権を失わずに、より多くの人とエージェントが生産的に協力できるようにするのは誰か、です。それが次のGitHubの基準であり、おそらく事業価値の大きな部分もそこにあります。

それではまた、
Joe