8月17日、GitHubで広範なサービス障害が発生し、同日、Cursorは有料ユーザーにOrigin early betaを開放した。コードリポジトリは継続的に動作するAgentに接続されており、既存の協業インフラは人間の作業ペースに最適化されている。研究によると、40.2%のリポジトリで重複するAgent PRが発生し、merge conflictの割合は41.7%に達している。Cursor OriginはAgentによる高頻度書き込みを想定して設計されており、単一リポジトリで22.6 commit/sをサポートし、リポジトリ、PR、checks、レビューを統合する。OriginはGitの上位制御層として位置づけられ、高頻度Agent協業プロセスを再設計している。マスク傘下のxAI、X、SpaceXおよびCursorは、完全なAI生産チェーンを形成しており、Colossusが計算リソースを提供し、Grokがモデルを提供し、Cursorがコードを実行し、Originがエンジニアリング状態を管理する。GitHubは人間の協業からAgentへの拡張を進めており、CursorはAgentの作業負荷に応じてforgeを再設計しており、両者の道筋の競争はますます激しくなっている。

記事執筆者、出典：雷峰網

コードリポジトリの所有者は、人間からエージェントへと変化しています。

8月17日、GitHubで大規模なサービス異常が発生しました。Web、API、Actions、Pull Requests、Git操作、Webhookなどのコアなリンクが順次影響を受け、一部の時間帯ではWebおよびAPIリクエストのエラー率が約20％に達しました。

同じ日の中で、Cursor はすべての有料プランに対して Origin early beta を段階的に開放し始めました。リポジトリ、PR、チェック、レビュー、マージ、およびオートメーションが同じシステムに統合され、Cursor は明確に「コードホスティングは『agent scale』のために設計され始める」と位置づけています。

面白いことに、この二つの出来事は同じタイミングで発生し、ある変化を際立たせました。コードリポジトリには、次第に多くの継続的に動作するエージェントが接続されつつありますが、従来のソフトウェア協業インフラは、人の作業リズムに長年適応してきました。

人間が数時間のコードを書くと、数回のコミットしか生み出せないかもしれないが、エージェントは数分以内に連続して変更を加え、プッシュし、チェックをトリガーし、その結果に基づいて次のラウンドを継続できる。コミットが速くなることは表面的な変化に過ぎず、より深い変化は、ソフトウェア生産システム全体の時間スケールが圧縮されていることである。

GitHubが直面する多くの新しい問題、Originが解決したい多くの問題は、おそらくここから始まる。

01 GitHubは突然老いたわけではありません

GitHubが誕生したとき、ソフトウェアの協力には安定した基本単位がありました：人。

エンジニアは数時間のコードを書いて1回のコミットを提出する；機能開発は数日かかり、1つのPRとなる；レビューは30分後に現れる場合もあれば、翌日になることもある；CIが数分かかるのは一般的であり、マージコンフリクトを少し遅らせても、システム全体の意味が失われることはない。

このリズムに沿って、GitHubはPull Request、Issue、Review、Actions、Webhook、および権限体系を構築しました。たとえ長年にわたり高頻度のコミットを維持するLinux Kernelのようなプロジェクトにおいても、このリズムは依然として明確な人間の時間スケールを備えています。

LWNの統計によると、Linux 7.0の開発サイクル全体で、2362人の開発者から14,251件のnon-merge commitが行われました。これらのコミットは、数週間にわたる開発サイクル中に、メールでの議論、メンテナーによるレビュー、サブシステムの統合、リリースサイクルを経て実施されました。

Cursorは、6月のOriginリリースデモで別の負荷形態を示しました：単一リポジトリで22.6 commit/s。

この数値は実際のデモデータであり、独立して再現された本番ベンチマークではないため、Originが本番環境で同等のスループットを長期的に維持できることを証明するものではありません。しかし、Originがどのようなワークロードを対象としているかを十分に示しています。つまり、多数のエージェントが同じコード状態に継続的に書き込むというものです。

人間の開発者は自然にレート制限を受ける。思考、コード作成、会議、休憩はコミット間で多くの空白時間を生み出すため、人間を中心に設計されたforgeは、多くのシステム負荷を時間に吸収させることができる。

エージェントにはこの制限はありません。

数十のエージェントが同じベースSHAから分岐し、近い時間に関連ファイルを変更して、同時にプッシュし、PRを開始し、チェックを呼び出し、レビューを読み取り、コードを修正して再度プッシュできます。1つのコミットは、インデックスの更新、権限チェック、Webhook、CI、コードスキャン、レビュー状態の更新、マージ可能性の計算を引き続きトリガーする可能性があります。

したがって、変化に耐える必要があるのはGitオブジェクトモデル自体ではなく、Git上のForgeコントロールプレーン：API、認証、バックグラウンドタスク、CIスケジューリング、Webhook、ブランチ保護、レビュー状態、マージキュー、およびこれらのコンポーネント間で形成されるカスケード負荷である。

7月にGitHub上のAgent PRを対象に行った研究では、このような並行形态が確認されています。この研究は2807のリポジトリに含まれる33596のAgent PRを分析し、40.2%のリポジトリで時間的に重複するAgent PRが発生していたことがわかりました。

サンプリング再現された並行修正において、エージェント間のPRでのテキストマージコンフリクトの割合は41.7%、同一エージェントが生成した並行PRでは19.8%であった。

マルチエージェント協調は、新たな並行制御の課題をもたらす。GitHubの今回の障害は、エージェントトラフィックが既存のインフラを超過したことを証明していないが、それは観察の窓口を提供している：ソフトウェア生産が低頻度のヒューマンイベントから高頻度のマシンイベントへと変化する中で、容量計画、キュー設計、ステートプロパゲーション、一貫性モデルは、別の種類のワークロードに直面している。

Originの設計もここから始まります。

02 Origin 修正協力コスト

OriginがGitリポジトリのホスティングエントリを追加するだけでは、GitHubがすでに築き上げた開発者関係、オープンソースエコシステム、企業権限体系、およびツールチェーンを動かすのは難しい。

その機会は、エージェントが協力コストを変化させたことに由来します。stacked PR はその典型例です。

人間の開発者は、通常、機能を比較的完成度の高いプルリクエストにまとめることを好む。1つのプルリクエストを分割するたびに、コンテキストが増加し、レビューの回数が増え、ブランチの依存関係も増える。1つの変更を数十のプルリクエストに分割すると、人々はこれらの関係の維持に多くの労力を費やしてしまう。

エージェントのコスト構造は異なります。数十のファイルにまたがる変更を行う際、どのステップでも失敗した場合、エージェントは広範なコンテキストを再理解する必要がある可能性があります。小さなchange setに分割すると、schema、service、UIなどの変更が明確な依存関係を形成し、各ノードを個別に検証でき、失敗した場合に関連する部分のみを処理すればよくなります。

小PRはそのためAgentのチェックポイントとなり、タスクに局所的な検証、局所的な再試行、依存関係の追跡機能を提供できます。

CursorによるGraphiteの買収も、ここで理解できます。Originの現在のearly betaは、Graphiteのスタックされたワークフローを完全には引き継いでいませんが、Graphiteが長期間にわたり投入してきたスタックされたPRとスタック認識型のマージキューは、Agentがコード生成速度を向上させたことで生じる後続のボトルネックと正好対応しています。

PR の数が増加すると、merge キューの負担も増します。Agent A と Agent B は同じ base SHA から同時に作業でき、それぞれの側でテストを通過できます。

A が main に先に進んだ後、B のテスト結果はコードが旧状態で動作することを示すだけで、新しい main に進んでも安全であることを証明できない。したがって、queue は変化し続ける main に応じて候補状態を再構築し、チェックを再実行し、PR 間の依存関係を処理する必要がある。

衝突は、人為的な中断から徐々にパイプライン内の回復可能なfailure stateへと変化させることもできます。Cursorはすでに/babysitのような機能を提供しており、PRのフィードバック、失敗したチェック、および衝突を継続的に処理しています。候補マージで問題が発生した場合、関連するコンテキストはAgentに再割り当てされ、隔離環境で修正され、再検証されます。

レビューも同時に構造化されます。人間の協力は自然言語とチームの経験に大きく依存していますが、エージェントが長時間実行されるには、どのチェックが失敗したか、どのスレッドが未解決か、どのポリシーが満たされていないか、現在のhead SHAが何かを明確に読み取る必要があります。

OriginはAPIを通じてリポジトリ、コミット、チェック、PRなどのオブジェクトを公開し、フォーマルレビューと通常のディスカッションを区別しています。

これらの構造化された状態は、その後直接 Automations によって消費されます。push、PR opened、または PR pushed が cloud agent をトリガーし、実行結果は checks と PR に書き戻され、失敗した場合は処理フローに進みます。MCP、hooks、および Agent API は、外部ツールが同じイベントチェーンに参加できるようにします。

“GitHubから分離”は移行パスを解決します。チームはまずGitHubリポジトリをミラーし、GitHubをソースオブトゥルースとして維持しながら、AgentワークフローをOriginに移行できます。安定して動作した後、同期を切断し、Originがリポジトリを独立して管理します。

これにより、Cursor はまず Agent、PR、レビュー、チェック、自動化を引き受け、徐々により多くのエンジニアリング状態を自社システムに残すことができます。

Originの製品ロジックはしたがって明確です：Gitは引き続きバージョン管理を担い、Originが再構築するのは、高頻度エージェントの協働を支えるGitの上位の制御層です。

03 老马正在整合一条AI生产链

過去1年以上にわたり、xAI、X、SpaceX、およびCursorの一連の動きは、より完全な上下流関係を形成してきました。

xAI が X を買収し、その後 SpaceX システムに統合される；Cursor が Colossus の計算リソースを獲得し、その後も SpaceX システムに統合される。一方で、Grok 4.6 がリリースされ、Origin の開放が開始される。

このアプローチは、マスクが過去にテスラで採用した垂直統合の考え方と類似しています：外部のプロセスで反復の摩擦が増加し始めた場合、サプライチェーンの上流および下流へとさらに拡張し、重要なインターフェースを同一のシステムに統合します。

エージェントが直面しているのはまさにこの問題です。モデルは推論を完了できますが、ソフトウェアタスクにはリポジトリへのアクセス、ファイルの変更、テストの実行、CIの処理、レビューの受信、コンフリクトの解決、そして失敗後の実行の復元が必要です。

これらのプロセスが複数のシステムに分散している場合、各タスクの実行ごとに権限、コンテキスト、状態を繰り返し同期する必要があり、インターフェースコストは継続的に実行されるAgentループ内で蓄積されます。

Colossus、Grok、Cursor、Origin はそれぞれこのチェーン上の異なるレイヤーに対応しています：Colossus は計算リソースを提供し、Grok はモデル機能を提供し、Cursor はコードエージェントと実行環境を提供し、Origin はリポジトリ、PR、チェック、レビューの状態を保存します。

コード生成により、モデルが判断を下し、Cursorがその判断を実際の変更に変換し、Originがプロジェクトの状態を保存して後続のコラボレーションを管理する一連の連鎖が形成されます。

これはGrok 4.6を評価する尺度も変える。モデルの能力は依然として重要だが、エージェントシステムの出力は実行環境とエンジニアリングインフラにも依存する。たとえコードの生成品質が優れていても、その後に手動でコピー、実行、チェック、再送信が必要であれば、モデルの能力は持続的に拡大できない。

モデルが利用可能なレベルに達した後、コードが迅速に実行、検証、マージプロセスに進むかどうかが、全体のシステムの生産性にますます影響します。

X はこのチェーンにおける位置づけはまだ明確ではありません。リアルタイムのコンテンツ、ユーザー関係、アイデンティティ、および配信ネットワークを有しており、今後はタスクの源泉や配信入口となる可能性があります。現在、Grok Bot は、皆が想像するような「受動的に質問を待つ単なるチャットボット」ではなく、継続的なタスク実行の層に近い製品形態をしています。

Cursor が Origin を必要とする理由は、コード生成後に、プロジェクトの状態を長期的に保存し、変更を調整し、結果を検証し、後続の実行と接続するシステムが必要だからである。この位置が常に外部に存在する場合、Agent ソフトウェア生産チェーンに重要な依存関係が生じる。

そしてOriginがこの層を補っています。

04 GitHub と Origin の違い

GitHubはスタックされたPR、マージキュー、REST APIを既に備えており、CopilotコーディングエージェントをIssue、Actions、PR、コードレビューに継続的に統合しています。機能一覧だけを見れば、両者の今後の機能はますます重複していくでしょう。

主な差異は設計の前提にあります。

GitHubは成熟した開発者ネットワーク上に構築されているため、Agentが既存のIssue、PR、Actions、およびブランチ保護システムに統合するのがより自然な道です。

Cursorは、高密度なエージェント協力を通じてこれらのコンポーネントを再設計できます。リポジトリで長期間にわたり数十のエージェントが実行され、PRの数が増加し、変更の粒度が細かくなり、状態の変化が速くなる場合、レビュー、チェック、マージ、および権限システムはマシンの行動に基づいて再構成する必要があります。

PRの役割も同時に拡大する可能性がある。これは主に人が読むためのコード変更から、diff、依存関係、テスト証拠、ソース、リスクレベル、承認状態を含むエンジニアリングタスクユニットへと徐々に進化することができる。

人的責任はより多くのルール層に移行する：どのディレクトリが自動変更を許可されるか、依存関係のアップグレードがどの程度のバージョン跨ぎを許可されるか、データベースマイグレーションに必要な検証は何か、認証および支払い関連のコードに必要な承認プロセスは何か、どのような状況でエージェントが停止しなければならないか。

その結果、Agent-native forgeの指標も変化します。22.6 commit/sは目立ちますが、commit数自体はソフトウェア生産性を示すものではありません。より意味のある指標は、タスクがシステムに投入されてからマージされるまでの所要時間、失敗後の局所的回復能力、ポリシー内で自動的に完了した変更の割合、受け入れられた変動幅の計算コスト、および高リスク変更に要する人的注意です。

Originが制御しようとしているのは、repository、checks、review、権限、およびeventsが統合されたソフトウェア生産制御面である。

したがって、GitHubとOriginの競争は、GitHubが成熟した人間の協力システムからエージェントへ拡張し、Cursorがエージェントのワークロードに基づいてforgeを再設計するという二つの道筋に収束していくことになる。

05 老馬は次の階にいます

ちなみに、Grok 4.6 のリリース後、外界は依然としてベンチマークをめぐってコード能力、推論スコア、価格を議論しがちだが、Colossus、Grok、Cursor、Origin を一括して見ると、この戦略はすでにモデルの先のソフトウェア生産チェーンにまで広がっている。

Colossusが計算リソースを提供し、Grokが推論を担当し、Cursorがモデルの能力をコードの変更に変換し、Originがその後のリポジトリ状態、PR、チェック、レビューを引き継ぎます。モデルの能力が向上すれば、その恩恵は実行チェーンを通じて直接伝播します。たとえ単一世代のモデルに明確な差が生じなくても、後続のインフラは引き続き蓄積を続けられます。

したがって、Grok 4.6 が今日あるランキングでどの位置にいるかは、一時的な結果に過ぎない可能性があります。より長期的な課題は、モデル、実行環境、ソフトウェアエンジニアリングの状態を一貫して運用される生産システムとして整理できるのは誰かということです。

誰かがこのラウンドのモデルがどれほど賢いかを争っている間に、老馬はすでに次の階層に到達している。