アーティファクト：Git と連携するバージョン管理付きストレージ

2026 年 4 月 16 日 | 約 9 分間で読めます

エージェントは、ソースコード管理、ファイルシステム、および永続化される状態（ステート）のあり方を変えてしまいました。開発者と AI エージェントがこれまで以上に多くのコードを生成しており、今後 5 年で書かれるコード量は、プログラミング史全体で作られたコード量を超える見込みです。この需要に応えるために必要なシステムの規模も、桁違いに変化しました。特にソースコード管理プラットフォームはここで苦労しています。これらは人間のニーズを満たすために設計されたものであり、決して眠らずに複数の課題を同時に処理し、疲れ知らずで動作するエージェントによる 10 倍ものボリューム増加に対応するためには不適切だったからです。

私たちは新たな「原素（プライミティブ）」の必要性を感じています。それはまずエージェントを第一義的に想定した、分散型のバージョン管理ファイルシステムであり、現在構築されているようなタイプのアプリケーションも支えられるものです。私たちはこれを「Artifacts」と呼んでいます。これは Git を理解するバージョン管理ファイルシステムです。プログラムによりリポジトリを作成し、エージェントやサンボックス（sandbox）、ワーカー（Worker）、または他のあらゆるコンピューティングパラダイムと並行して利用でき、通常の Git クライアントからアクセスすることができます。

すべてのエージェントセッションにリポジトリを割り当てたいですか？Artifacts で実現可能です。すべてのサンボックスインスタンスでも同様です。既知の良好な出発点から 10,000 つのフォークを作成したいのでしょうか？それはまた Artifacts です。Artifacts は REST API とネーティブなワーカー用 API を提供しており、Git クライアントが適さない環境（つまり、サーバーレス関数などのケース）でもリポジトリの作成、認証情報の生成、コミットの操作が可能です。

Artifacts は現在、有料ワーカープランを持つ開発者向けにプライベートベータ版で利用可能です。また、私たちは 5 月の早い時期までにこれをパブリックベータ版として公開する予定です。

// リポジトリを作成する
const repo = await env.AGENT_REPOS.create(name)
// トークンとリモートアドレスをエージェントに返す
return { repo.remote, repo.token }

# それをクローンして、通常の Git リモートとして使用します
$ git clone https://x:${TOKEN}@123def456abc.artifacts.cloudflare.net/git/repo-13194.git

これで完了です。すぐに使用できるようになった裸のリポジトリで、あらゆる Git クライアントが操作可能です。さらに、既存の Git リポジトリから Artifacts リポジトリを初期化し、エージェントが独立して作業を行えるようにし、変更をプッシュできるようにすることも

.import()

interface Env {
  ARTIFACTS: Artifacts
}

export default {
  async fetch(request: Request, env: Env) {
    // GitHub からインポートする
    const { remote, token } = await env.ARTIFACTS.import({
      source: {
        url: "https://github.com/cloudflare/workers-sdk",
        branch: "main",
      },
      target: {
        name: "workers-sdk",
      },
    })

    // インポートされたリポジトリへのハンドルを取得する
    const repo = await env.ARTIFACTS.get("workers-sdk")

    // 読み取り専用となる隔離されたフォークを作成する
    const fork = await repo.fork("workers-sdk-review", {
      readOnly: true,
    })

    return Response.json({ remote: fork.remote, token: fork.token })
  },
}

開始するにはドキュメントをご覧ください。あるいは、Artifacts の使用方法、構築方法、および内部構造については以下のセクションを読んでください。

なぜ Git なのか？バージョン管理ファイルシステムとは何か

エージェントは Git を知っています。多くのモデルのトレーニングデータに深く組み込まれているためです。エージェントにとってハッピーパスもエッジケースもよく知られており、コード最適化されたモデル（および/またはハネス）は特に Git の活用において優れています。さらに、Git のデータモデルはソースコード管理だけでなく、状態の追跡、タイムトラベル、そして大量の小さなデータの永続化に最適なものです。コード、設定、セッションプロンプト、エージェント履歴：これらはいずれも、「オブジェクト」として小さなチャンク（コミット）で保存し、必要に応じて元に戻す（履歴）ことが望ましいもの들 です。私たちは完全に新しい専用プロトコルを発明することもできたでしょう……しかし、その場合「ブートストラップ問題」が生じます。AI モデルがそれを知らないため、スキルを分布させたり、CLI を配布したり、ユーザーがあなたのドキュメント MCP に接続されることを願ったりする必要があり、すべて ذلك には摩擦が発生します。

では、エージェントに認証済みで安全な HTTPS Git リモート URL を提供し、それが Git リポジトリであるかのように動作させるだけで十分でしょうか？これは意外によく機能することが判明しました。Git を話すことのできないクライアント（Cloudflare Worker、Lambda 関数、または Node.js アプリなど）に対しては、REST API と（近いうちに）言語固有の SDK を提供しています。これらのクライアントも isomorphic-git を使用することもできますが、多くの場合、より単純な TypeScript API は必要な API シアスを削減できます。

ソースコード管理専用ではない

Artifacts の Git API はソースコード管理用であるように思えるかもしれませんが、実際には Git API とデータモデルは、データのフォーク、タイムトラベル、および状態の差分計算を可能にする強力な方法で状態を永続化するためのものです。Cloudflare 内部では、我々のエージェントに Artifacts を使用しています。これはセッションごとの Artifacts リポジトリにおいて、ファイルシステムの現在の状態とセッション履歴を自動的に永続化するためです。これにより以下のことが可能になります：

• ブロックストレージの provisioning（準備）および保持を必要とせず、サンボックスの状態を永続化できます。
• セッションを他の人と共有し、セッション（プロンプト）状態とファイル状態を時間旅行して遡ることができます。「実際の」リポジトリ（ソースコード管理）へのコミットがあってもなくても同様です。
• 最も良い点として、セッションを任意の時点からフォークでき、チーム内でコワーカーとセッションを共有し、そこから引き続き作業を行うことができます。何かをデバッグしていて別の目に見たい場合は、URL を送信してフォークしてください。API のriff（議論・考察）をしたい場合は、コワーカーがフォークして続きの作業を引き継ぎましょう。

また、Git プロトコル自体は要件にならない場合でも、意味論（元に戻す、クローンする、差分を計算するなど）は必要であるというケースでも Artifacts を使用したいというチームと話し合う機会がありました。製品の一部としてカスタマー別の設定を保存し、ロールバックできる能力が必要なら、Artifacts が良い表現となります。Git 中心のユースケースだけでなく、Artifacts 周りの非 Git 系ユースケースを探求するチームを見ることに興奮しています。

内部構造（Under the hood）

Artifacts は Durable Objects を基盤として構築されています。状態ありの隔離コンピューティングインスタンスを数百万（あるいは数千万）個作成できる能力は、現代の Durable Objects の仕組みに内在しており、それがまさに名前空間あたり数百万の Git リポジトリをサポートするために必要だったものです。主要リーグ野球（ライブゲームのファンアウト）、Confluence ホワイトボード、そして我々自らの Agents SDK も大規模なスケールで内部構造として Durable Objects を使用しており、したがって私たちはすでに生産環境で運用している原素の上にこの構築を行っています。

しかし、私たちが本当に必要としたのは Cloudflare Workers で動作する Git 実装でした。それは小さく、できるだけ完全で、拡張可能（メモ、LFS など）、そして効率的である必要がありました。そこで我々は Zig で実装し、それを Wasm にコンパイルしました。なぜ Zig を使用したのかという理由は以下の 3 つです：

1. 完全な Git プロトコルエンジンが純粋な Zig で書かれており（libc なし）、約 100KB の WASM バイナリにコンパイルされます（最適化の余地あり！）。SHA-1、zlib インフレイト/デフレイト、デルタエンコーディング/デコード、パック解析、そして完全な Git スマート HTTP プロトコルをすべてゼロから実装しており、標準ライブラリ以外の外部依存関係は一切ありません。
2. Zig はメモリ割り当てに対して手動制御を提供し、Durable Objects のような制約された環境で重要です。Zig ビルドシステムにより、WASM ランタイム（生産）とネイティブビルド（libgit2 に対する正しさを検証するためのテスト）間でコードを簡単に共有できます。
3. WASM モジュールは、薄いコールバックインターフェースを通じて JS ホストと通信します：ストレージ操作のための 11 つのホスト導入関数（host_get_object, host_put_object など）と、ストリーミング出力用の 1 つ（host_emit_bytes）。WASM 側は完全に孤立してテスト可能です。

内部構造では、Artifacts は R2（スナップショット用）と KV（認証トークンの追跡用）も使用しています：

• ファイルは下の Durable Object の SQLite データベースに保存されます。
• Durable Object ストレージには 2MB の最大行サイズがあるため、大きな Git オブジェクトはチャンク化されて複数の行にわたって保存されます。
• 下の SQLite を基盤とした同期 KV API（

  state.storage.kv

  ）を使用しています。
• DO には約 128MB のメモリ制限があり、これは数十百万個のものをスポーンできる（速く軽量だが）ことを意味しますが、その制限内で動作する必要があります。
• フetch とプッシュパスの両方でストリーミングを広く使用しており、生ワASM オブジェクトチャンクから構築された

  ReadableStream<Uint8Array>

  を直接返しています。
• Git デルタを自分で計算するのではなく、生のデルタとベースハッシュは解決されたオブジェクトの隣に永続化されます。フェッチ時に要求クライアントがすでにベースオブジェクトを持っている場合、Zig はフルオブジェクトではなくデルタを出力し、帯域幅とメモリの節約になります。
• Git プロトコルのバージョン 1 とバージョン 2 の両方をサポートしています。ls-refs、浅いクローン（deepen, deepen-since, deepen-relative）、have/want ネゴシエーションによるインクリメンタルフェetch などを含む機能をサポートしています。
• Git クライアントとの適合性テストおよび libgit2 サーバーに対する検証テストを含む広範なテストスイートを持っています。
• これに加え、ネイティブな git-notes に対応しています。Artifacts はエージェントファーストとして設計されており、notes を使用することでエージェントは Git オブジェクトに注釈（メタデータ）を追加できます。これはプロンプト、エージェント帰属、オブジェクトそのものを改変せずにリポジトリから読み書きできるその他のメタデータを含みます。

大きなリポジトリ、大きな問題か？ArtifactFS と出会う。

多くのリポジトリはそれほど大きくなく、Git はストレージ効率の面で極めて効率的に設計されています：ほとんどのリポジトリをクローンするには数秒しかかかりません。これは主にネットワーク設定、認証、チェックサムで支配されます。ほとんどのエージェントまたはサンボックスシナリオではこれは許容可能です：サンボックスが開始するときにリポジトリをクローンしてすぐに作業に取り掛かればよいのです。しかし、マルチ GB のリポジトリや/または数百万のオブジェクトを含むリポジトリの場合はどうでしょうか？ agents が作業に入ることを何分もブロックしたりコンピューティングリソースを消費したりすることなく、それを迅速にクローンするにはどうすればよいでしょうか？人気のある Web フレームワーク（2.4GB で長い歴史を持つ！）をクローンするには近々 2 分かかります。浅いクローンは高速ですが、単位数秒以下には到達せず、必ずしも履歴を省略したいわけではありません（エージェントはそれを有用と感じています）。大きなリポジトリを約 10〜15 秒に短縮して agent が作業に入ることは可能でしょうか？さて、はい：いくつかのトリックで可能です。

Artifacts のローンチの一部として、我々は ArtifactFS をオープンソース化しています。これは大きな Git リポジトリを可能な限り迅速にマウントするように設計されたファイルシステムドライバであり、初期クローンにブロックされる代わりにファイル内容をオンザフライでハイドレート（充填）します。起動時間が重要なエージェント、サンボックス、コンテナなどのユースケースに最適です。大きなリポジトリの場合のサンドボックス起動時間から約 90〜100 秒を削ぎ取ることができ、月に 10,000 つのそのようなサンボックスジョブを実行している場合：これは 2,778時間のサンボックスが保存されます。

ArtifactFS を「非同期な Git クローン」と考えることができます：

• ArtifactFS は git リポジトリの blobs なしクローンを実行します：ファイルツリーと refs をフェッチしますが、ファイルコンテンツはフェッチしません。それはサンボックス起動中にそれを果たすことができ、その後 agent ハネスが作業を開始することを可能にします。
• 背景では、軽量なデーモンの通じてファイルコンテンツのハイドレート（ダウンロード）を並行して開始します。
• エージェントが最初に関心を持つファイルを優先します：パッケージマニフェスト（package.json, go.mod）、設定ファイル、およびコードで、バイナリ blobs（画像、実行ファイルなどテキストファイルではないもの）は可能な限り後回しにして、エージェントがファイル自体がハイドレートされている間にファイルツリーをスキャンできるようにします。
• エージェントがファイルを読み取ろうとした時にファイルが完全にはハイドレートされていなければ、読み取りはブロックされます。
• ファイルシステムはファイルをリモートリポジトリに「同期」しようとしないことは重要です：数千や数百万のオブジェクトの場合、それは通常非常に遅く、Git を話しているので必要ありません。エージェントは通常のリポジトリで行うようにコミットとプッシュするだけです。学ぶ必要がある新しい API はありません。
• 重要なのは、ArtifactFS は我々の Artifacts のだけでなく、任意の Git リモートと動作することです。GitHub、GitLab、またはセルフホストされた Git インフラストラクチャから大きなリポジトリをクローンしている場合でも、ArtifactFS を使用できます。

今後どのようなことが予定されていますか？

今日のリリースはベータ版のみであり、すでに来数週間にランドする機能をいくつか開発中です：

• 公開する利用可能な指標の拡張。現在、名前空間あたりキーオペレーションカウント、リポジトリごとの保存されたバイト数を shipping しているため、数百万の Artifacts を管理するのが辛くありません。
• リポジトリレベルイベントに対するイベントサブスクリプションのサポートにより、プッシュ、プル、クローン、およびフォーク時に namespaces 内の任意のリポジトリにイベントを発信できます。これにより、イベントを消費し、Webhook を書き込み、エンドユーザーを通知するか、製品内のライフサイクルイベントを駆動するか、またはプッシュ後のジョブ（CI/CD など）を実行することもできます。
• Artifacts API と対話するためのネイティブ TypeScript、Go、および Python クライアント SDK。
• リポジトリレベルの検索 API と名前空間全体での検索 API、例えば「package.json ファイルを持つすべてのリポジトリを見つける」。

また、Workers Builds 用の API を計画しており、任意のエージェント駆動ワークフロー上で CI/CD ジョブを実行できます。

費用はどうなるのでしょうか？

Artifacts はまだ初期段階ですが、私たちはエージェントスケールで価格設定を機能させたいと考えています：数百万のリポジトリを持つかどうかはコスト効果があり、未使用（または稀に使用される）リポジトリが重荷にならないようにし、価格設定はエージェントのマスーシングタンテント特性と一致する必要があるためです。また、リポジトリが使用されるかどうか、ホットかコールドか、エージェントがそれを目覚めさせるかどうかを考慮する必要はないはずです。我々はあなたが消費するストレージと各リポジトリに対する操作（クローン、フォーク、プッシュ＆プルなど）に対して課金します。

大きな忙しさのあるリポジトリは、小さく頻繁に使用されないリポジトリよりも費用がかかります。リポジトリが 1,000、100,000、または 1000 万個であっても同様です。また、ベータが進むにつれて Artifacts を Workers フリープランにも持ち込み（一部の公平な制限付き）予定しており、価格設定の変更に応じてベータを通じて更新を提供し、使用量に対する請求の前にそれを行います。

どこから始めますか？

Artifacts はプライベートベータで導入され、パブリックベータは 2026 年の早い時期（確認のために！）に準備される予定です。今後数週間にわたりお客様を順次許可し、プライベートベータへの関心登録を直接行うことができます。その間には、Artifacts のことを学べる方法は以下の通りです：

• ドキュメントの getting started ガイドを読むこと。
• Cloudflare ダッシュボードを訪問すること（Build > Storage & Databases > Artifacts）。
• REST API 例を読み通ること。
• Artifacts が内部でどのように動作するかを知るために学ぶこと。
• ベータが進むのを追跡するために変更ログを追うこと。

Cloudflare のコネクティビティクラウドは、企業全体のネットワークを保護し、顧客が効率的にインターネットスケールのアプリケーションを構築するのを助けるだけでなく、あらゆるウェブサイトやインターネットアプリを加速させ、DDoS 攻撃を防ぎ、ハッカーから守りつつ、Zero Trust への旅にもご支援できます。あらゆるデバイスから 1.1.1.1 を訪れて、無料アプリでインターネットをより速く安全にしましょう。私たちのより良いインターネットを構築するためのミッションについて詳しく学びたい場合は、ここから始めてください。新しいキャリア方向を探している場合は、公開职位をチェックしてください。

#AgentsWeek #Agents #GitHub #CloudflareWorkers #Storage #DeveloperPlatform