数百の Agent が同時にコードを書くとき、どう連携すべきか？Cloudflare が促す次世代 Git プラットフォームの構築

Artifacts はリポジトリをプログラマブルなインフラへと変え、独立タスクの割り当て、コンテキストの保持、レビューやデプロイへの接続を実現します。真に設計すべきは、これら並行する変更をいかに統合するかです。

著者：Cloudflare10-01 · 約12分

コードを書くとなると、多くの人がGitHubを思い浮かべるでしょう。過去十数年にわたり、多くの開発コラボレーションツールは「人間のプログラマー」を中心に構築されてきました。コードをひと通り書き終えたらコミット（Commit）として記録し、並行するブランチ（Branch）を切って新機能を試し、最終的にプルリクエスト（Pull Request、PR）を作成して同僚にコードレビュー（Code Review）を依頼し、問題がなければメインのコードベースにマージする、という流れです。

このモデルは人間同士のコラボレーションの時代には極めてうまく機能していました。しかし、現在コードを書く主力担当が人間ではなく、同時にタスクを処理する何百、何千ものAI Agentになったとしたら、既存のGitHubは依然として通用するでしょうか？

Cloudflareはこの問いに対して独自の答えを提示し、AI向けに特別設計されたGitインフラストラクチャ「Artifacts」が正式にパブリックベータに入ったことを発表しました。同時に、全世界の開発者に向けて「Cloudflareの基盤能力を活用し、複数のAgentが同時に開発する際にどのようなコラボレーションプラットフォームが必要とされるかを探求する」というチャレンジを開始しました。

端的に言えば、Artifactsは標準的なGit操作をサポートし、プログラムによるリポジトリ管理とファイルの履歴バージョン保持が可能なクラウドファイルシステムです。Agentのコラボレーションに向けたコード基盤として機能し、開発者はプログラムを通じて各Agent、セッション、タスクごとにオンデマンドで独立したリポジトリを作成し、コードとAgentのタスク背景や説明などのコンテキストを保持できます。その主な機能・特徴は以下のとおりです：

Workerコードからリポジトリを直接制御：専用のバインディングインターフェースにより、プログラムロジック内からリポジトリの作成やフォーク（fork）、コンテキストファイルの読み込み、コミットの検査、リポジトリスコープのGitトークン発行を直接行い、これらのリポジトリ操作をタスクフローに組み込めます。
Workersビルドとブランチプレビューの統合：リポジトリをビルドサービスに関連付けることで、本番ブランチへのプッシュは自動的にビルドとデプロイをトリガーし、他のブランチへのプッシュは独立したプレビュー環境を自動生成するため、本番公開前に変更を安全にテストできます。
リポジトリイベントの購読：リポジトリの作成、フォーク、削除、プッシュ、プルなどのイベント監視をサポートし、コード変更後に後続のフロー（コードレビューAgentの起動、CIタスクの実行、デプロイなど）を自動トリガーできます。
データ保存・処理リージョンの選択：ネームスペース作成時にデータ保存・処理リージョン（米国やEUなど）を指定でき、その空間下のすべてのリポジトリが対応するリージョン制限に自動的に従います。
リポジトリ運用メトリクスの確認：コンソール上で各リポジトリの総操作数、プル数、プッシュ数、エラー率を確認または直接クエリでき、リポジトリの実際の呼び出し状況の監視や異常の迅速なトラブルシューティングに役立ちます。

複数の Agent が一緒にコードを書くとき、難点は調整とレビューへとシフトする

Cloudflareがなぜこれを行うのかを理解するには、まず既存の開発モデルが膨大なAIに直面した際にどのような不都合に直面しているかを見る必要があります。

従来のソフトウェアチームでは、コミット、レビュー、マージは人間同士のコラボレーションを中心に展開されており、人間のエネルギーと注意力は極めて希少なリソースでした。コードをむやみに変更することはできず、変更リスクを制御するためにレビューが必要でした。

しかし現在、さまざまなコーディングAgentの爆発的な増加に伴い、状況は一変しました：

並行規模の爆発：以前は1つのプロジェクトを10人でメンテナンスしていましたが、今後は1つのプロジェクトで数百のAgentが同時にバグ修正、新機能の追加、テストケースの補完、依存関係のアップグレードを行う可能性があります。変更が絶えず増加する中で、人間はどれを優先してレビューすべきか、複数の提案をどう比較すべきかを把握する必要があります。
コードの競合とコラボレーションの混乱：数十のAgentが同一コードベースの異なるロジックに変更を加えているとき、他のAgentが何を修正しているかを誰が把握できるでしょうか？2つのAgentが同じファイルを修正した場合、誰が仲裁するのでしょうか？
「なぜ変更したのか」は「何を変更したのか」以上に追跡が困難：変更された数行（Diff）を見るだけでは、タスクの背景、制約、トレードオフを把握できない場合があります。これらのコンテキストも同様に保存し、後続の引き継ぎを容易にする必要があります。

Cloudflareの見立てでは、人間向けのコラボレーションモデルは、大量のAgentによる同時開発にさらに適応していく必要があります。

中核となる基盤：Artifacts とは何か？

多くの人が真っ先に抱く疑問は、「Cloudflareはウェブ版のUIを作ってMicrosoftのGitHubとユーザーを奪い合おうとしているのか？」ということかもしれません。

決してそうではありません。Cloudflareが取り組んでいるのは、より低レイヤーの基盤です。

今年初め、Cloudflareは「Artifacts」と呼ばれる基盤サービスを発表しました。簡単に言えば、これはバージョン管理能力を備え、Git操作をサポートし、Cloudflareによれば百万規模のリポジトリにまで拡張可能なクラウドファイルシステムです。

プログラムから呼び出し可能なリポジトリ操作を提供します：

プログラムによるリポジトリの作成やフォーク：開発者は各タスク、セッション、ユーザー、Agentごとにリポジトリを作成でき、並行作業に独立したバージョン履歴を持たせることができます。
コードだけでなく、Agentの思考コンテキストも保存：ソースコードの履歴バージョンを保存するだけでなく、Agent実行時のプロンプト、対話ログ、コンテキスト背景もあわせて永続化して保持できます。
Git構文とのネイティブ互換性：Agentは派手な新しいインターフェースを学ぶ必要はなく、もともと使い慣れている git clone、git push、git fetch などの操作を、Artifactsはネイティブですべてサポートしています。

これまでの期間にも、多くのAIプログラミングツール（自然言語を通じてAIにプロジェクトを生成させるVibe-codingプラットフォームを含む）が、ユーザーが作成したプロジェクトを保存したり、複数のAgentを相互に隔離された独立リポジトリで同一の起点から別々に試行させ、最後に結果を比較したりするためにArtifactsを使用してきました。

そして最新のパブリックベータ版において、Cloudflareはこの基盤にいくつかの極めて重要なピースを追加しました。

コードプッシュ後、本番ブランチはデプロイされ、他のブランチはプレビューを生成

コードをリポジトリに入れた後は、実際の動作結果を確認するためにビルドとデプロイを行う必要があります。

現在、Artifactsはリポジトリ接続を通じてWorkers Buildsに接続できます：

本番ブランチの自動リリース：あなたやAgentが本番ブランチ（Production Branch）にコードをプッシュするだけで、Cloudflareが自動的にビルドを完了し、更新されたWorkerをオンラインにデプロイします。
フィーチャーブランチでの独立プレビュー自動生成（Workers Previews）：Agentが一時ブランチで開発している場合、コードプッシュ後にシステムが専用のプレビュー環境を自動的に作成または更新します。この環境には独立した専用アクセスリンクが付与され、正式リリース前に変更をテストするために使用されます。人間が直接開いて確認できるだけでなく、テストを担当する他のAgentも直接そのリンクにアクセスして検証できます。

Cloudflare Worker プロジェクト作成画面に統合された Artifacts のエントリ — Workerプロジェクト作成パネルには、従来のGitHubやGitLabと並んで「Continue with Artifacts」オプションが直接提供されている。

新規プロジェクトを直接Artifactsに保存する場合でも、既存のWorkerをリポジトリにバインドする場合でも、開発からリリースまでのパイプライン全体がGitプッシュという1つのアクションに高度に圧縮されます。

Worker 内でコードを使って Git リポジトリを直接操作

この能力により、タスク割り当てにおけるリポジトリ操作をプログラムに組み込むことができます。

Cloudflare Workersは、アプリケーションや自動化コードを実行するプラットフォームです。WorkerでArtifacts Binding（環境バインディング）を設定すると、開発者はWorkerスクリプト内でバインディングオブジェクトを通じてリポジトリインターフェースを直接呼び出せます。

例えば、以下の公式サンプルコードは、システムが新しいタスクを受け取った際に、Agent用の独立環境を自動的に割り当てる方法を示しています：

// 1. 获取主项目仓库
using project = await env.ARTIFACTS.get("my-project");
const { defaultBranch } = await project.info();

// 2. 为当前任务分叉（Fork）出一个独立仓库
const workspace = await project.fork(`task-${crypto.randomUUID()}`);

// 3. 读取主分支里的说明文件（给 AI 看的指令）
using repo = await env.ARTIFACTS.get(workspace.name);
const instructions = await repo.readFile({
  ref: defaultBranch,
  path: "AGENTS.md",
});

// 4. 将仓库地址、鉴权 Token 和任务指南准备成任务信息
const agentTask = {
  remote: workspace.remote,
  token: workspace.token,
  instructions: instructions ? await instructions.text() : null,
};

このプロセスを分かりやすく説明すると、以下のようになります：

独立した作業スペースの確保：メインプロジェクトはそのまま保持し、Workerがランダムに生成されたタスクIDを用いて新しいリポジトリ（workspace）を直接フォークします。Agentはその中で自由に大幅な変更を加えることができ、仮に破綻しても元のコードには一切影響を与えません。
コンテキスト情報の抽出：Workerはリポジトリの奥深くに直接アクセスして AGENTS.md を読み込み、AI向けに書かれたプロジェクト仕様や背景の指示書を取り出します。
リポジトリアクセス認証情報の提供：フォークされたリポジトリのGitアクセス認証情報（Token）とリモートアドレス（Remote）を取得し、コードとタスク説明をまとめてAgentに渡します。

上記のリポジトリ操作はコードで完結できます。agentTask は準備されたタスク情報にすぎず、実際にAgentを呼び出すステップは開発者が連携させる必要があります。

すべての変更を監視し、AI コードレビューを自動起動

Agentがコード変更を終えてリポジトリにコードをプッシュし直したとき、後続のフローはどのように接続されるのでしょうか？

Artifactsにはイベント購読メカニズム（Event Subscriptions）が組み込まれています。リポジトリに変更が発生した際——リポジトリの作成、フォーク、削除であれ、プッシュ、クローン、フェッチの実行であれ——システムは自動的にイベントメッセージを外部へブロードキャストします。

これらのメッセージを受信するための専用Workerを記述できます。例えば、公式からは「コードがプッシュされたら自動的にReviewをトリガーする」例が示されています：

export default {
  async queue(batch, env) {
    for (const message of batch.messages) {
      const event = message.body;
      
      // 只关注“代码被推入仓库”的事件
      if (event.type !== "cf.artifacts.repo.pushed") continue;

      // 自动启动一个后台审查工作流（Workflow）
      await env.REVIEW_WORKFLOW.create({
        params: {
          namespace: event.source.namespace,
          repo: event.source.repoName,
          ref: event.payload.ref,
          commit: event.payload.after, // 最新提交的 Commit 哈希值
        },
      });
    }
  },
};

このコードは、「プッシュ」を「レビュープロセスの起動」に接続しています。Workerはプッシュイベントをフィルタリングし、ネームスペース、リポジトリ、ブランチ参照、および新しいコミットを REVIEW_WORKFLOW に渡します。レビュープロセスはこれに基づいて、どのバージョンを検査すべきかを把握します。

レビューAgentをどのように呼び出し、テストを実行し、競合を処理し、マージを承認するかについては、開発者が自身のWorkflow内で実装します。イベント購読が提供するのは、トリガーと連携の能力です。

リポジトリのデータリージョンを選択し、操作エラーを監視する

開発フローに加えて、エンタープライズ開発で最も重視される2つの事項は「データがどこに置かれるか」と「リポジトリ操作が失敗していないか」です。

1. データ保存・処理リージョン（Data Jurisdiction）

多くの企業（特に欧州企業）は、国外へのデータ持ち出しに対して厳格な法的制限を設けています。現在、APIを通じてネームスペースを作成する際、データリージョンパラメータ（例："jurisdiction": "eu"）を指定するだけで、その空間下に作成されるすべてのコードリポジトリが、対応する米国またはEUのデータ保存・処理制限を継承します。

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/artifacts/namespaces" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{"namespace":"my-eu-namespace","jurisdiction":"eu"}'

2. リポジトリメトリクスの可視化モニタリング

数百のAgentが絶え間なくコードをプル・プッシュしているとき、人間の目でコマンドラインを監視し続けることには限界があります。Cloudflareはコンソール内にメトリクスパネルを直接組み込み、各リポジトリの総操作量、プル（Pulls）、プッシュ（Pushes）、エラー数、エラー率を表示します。

Artifacts リポジトリメトリクス監視ダッシュボード — Cloudflareコンソールに表示されるリポジトリ監視ダッシュボード。操作統計、プルとプッシュの頻度、およびエラー率の追跡を提供する。

開発者はウェブ上でグラフを確認できるだけでなく、APIを介してこれらの監視メトリクスを直接取得し、自チームのアラートダッシュボードに統合することも可能です。

商用化と 2.5 万ドルのプラットフォーム利用枠リワード：「次世代の GitHub」を共に設計する

パブリックベータの展開に伴い、商用化計画も明確になりました。Artifactsの課金は、リポジトリの操作回数（Operations）および実際のデータ保存量に基づいて行われます。この請求は10月中旬に正式に有効化されます。

しかし、最も注目を集めているのは、Cloudflareが同時に立ち上げた開発者チャレンジです：

目標：Cloudflare WorkersとArtifactsを用いて、あなたが考える「AI時代のGitプラットフォーム」を構築すること。
必須要件：主催者側は、応募作品が単に既存のGitHubモデルにAgentを追加しただけのものであることは望まないと明言しています。プロジェクトは少なくとも複数のAgentによるコードの同時並行変更を支えられる必要があります。その上で、リポジトリ、ブランチ、マージ競合、意思決定コンテキスト保持のあり方を再考することが求められます。
応募方法：5〜10分のデモ動画、オープンソースライセンス（MIT、Apache、またはBSD）に基づく完全なソースコード、および実行・デプロイガイドを提出すること。応募締め切りは10月中旬です。
賞：選出された上位3チーム（各チーム最大2名）はサンフランシスコに招待され、Cloudflare Connectカンファレンスのステージでプレゼンテーションを行う機会が与えられます。優勝チームには25,000ドルのCloudflareプラットフォーム利用枠と、Connect月曜日のVIPスピーカーディナーへの招待が贈られます。

現在、Workers Paid有料プランを利用中のユーザーは、コンソールから直接Artifactsのパブリックベータ体験を有効化できます。公式ブログの末尾には、開発者が自身のコーディングAgentにArtifactsリポジトリの自動初期化とコードプッシュを行わせるための、ワンクリックでコピーできるプロンプトへのリンクも用意されています。

基盤は整った、コラボレーションのルールこそが開発者の作るべきプロダクトである

Artifactsは、プログラム可能なリポジトリ、バージョンストレージ、イベントトリガー、デプロイ連携を提供します。開発者はこれらを活用してセッションのコンテキストを保持し、複数のAgentを同一の起点から別々に変更させ、その結果を比較することができます。

真に設計が求められているのは、それらの結果をどのように統合するかという点です。タスクをどう割り振るか、変更をどうレビューするか、競合をどう処理するか、そしてなぜ特定の案を選択したのか。リポジトリをフォークすることは変更を隔離できますが、チームのためにこれらのコラボレーションの課題を自動で解決してくれるわけではありません。Cloudflareのコンテストは、まさにこのレイヤーを構築するよう開発者に呼びかけています。

出典

We want you to build the next Git platform on CloudflareDina Kozlov、Dillon Mulroy、Zebulon Piasecki·原文を見る

↑ 本文ここまで

✓ この記事は全文無料です

メンバーは全文 Markdown のコピー・保存に加え、自分の AI に購読・質問させることができます。

年額で購読 $59 特典を見る →

原文を読む ↗

📮 新着解説をメールでいち早く

役に立ちましたか？メールを登録すると、新着解説を公開と同時にお届けします。解除はいつでも。

ログイン