Artifacts：Gitに対応するバージョン付きストレージ | Cloudflare

claudejamodel: claude-haiku-4-5

Artifacts: Gitを話すバージョン管理されたストレージ

2026-04-16 Dillon Mulroy Matt Carey Matt Silverlock 9分で読める

この記事はDeutschとEspañolでも利用可能です。

エージェントがソース管理、ファイルシステム、状態の永続化についての考え方を変えた

開発者とエージェントはこれまで以上に多くのコードを生成しています。今後5年間に書かれるコードは、プログラミング史全体で書かれたコードよりも多くなるでしょう。これはこの需要を満たすために必要なシステムの規模に1桁の変化をもたらしています。

ソース管理プラットフォームは特にここで苦労しています。それらは人間のニーズを満たすために構築されたもので、決して眠らず、複数の問題に同時に取り組むことができ、疲れることのないエージェントによって駆動される10倍の量の変化には対応していません。

私たちは新しいプリミティブが必要だと考えています。エージェント第一に構築された分散型バージョン管理ファイルシステムで、今日構築されているアプリケーションの種類に対応できるものです。

これをArtifactsと呼んでいます。Gitを話すバージョン管理ファイルシステムです。

Artifactsの概要

エージェント、サンドボックス、Workers、またはその他のコンピュートパラダイムと並行してプログラムでリポジトリを作成し、通常のGitクライアントから接続できます。

エージェントセッションごとにリポジトリを作成したい？ Artifactsでできます。
すべてのサンドボックスインスタンス？ Artifactsでもできます。
既知の良好な開始点から10,000個のフォークを作成したい？ご想像の通り、Artifactsです。

ArtifactsはREST APIとネイティブWorkers 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リポジトリからインポート

エージェントが独立して作業し、独立した変更をプッシュできるように、既存の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 })
  },
}

なぜ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リポジトリでファイルシステムの現在の状態とセッション履歴を自動的に永続化しています。これにより、以下が可能になります。

ブロックストレージをプロビジョニング（および保持）する必要なく、サンドボックス状態を永続化します。
セッションを他のユーザーと共有し、「実際の」リポジトリ（ソース管理）へのコミットがあったかどうかに関わらず、セッション（プロンプト）状態とファイル状態の両方を時間遡行できるようにします。
最高：任意のポイントからセッションをフォークし、チームメンバーとセッションを共有し、そこから引き継ぐことができます。

何かをデバッグしていて、別の視点が必要ですか？URLを送信してフォークしてください。APIについてリフしたいですか？同僚にフォークさせて、あなたが中断したところから引き継がせてください。

また、Gitプロトコルが要件ではないが、セマンティクス（元に戻す、クローン、差分）が必要な場合にArtifactsを使用したいチームとも話しました。

顧客ごとの設定を製品の一部として保存し、ロールバック機能が必要ですか？Artifactsはこれの良い表現になります。

Gitフォーカスのものと同じくらい、Artifacts周辺の非Git使用例を探索するチームを見るのに興奮しています。

内部動作

ArtifactsはDurable Objectsの上に構築されています。数百万（または数千万以上）のステートフルで分離されたコンピュートインスタンスを作成する機能は、Durable Objectsの現在の動作方法に固有のものであり、それはまさに名前空間ごとに数百万のGitリポジトリをサポートするために必要なものです。

メジャーリーグベースボール（ライブゲームファンアウト用）、Confluence Whiteboards、および独自のAgents SDKは、Durable Objectsを大規模で使用しており、本番環境に長時間置かれているプリミティブの上に構築しています。

しかし、必要だったのは、Cloudflare Workers上で実行できるGitサーバー実装でした。小さく、できるだけ完全で、拡張可能（ノート、LFS）で、効率的である必要がありました。

そこで、Zigで構築し、Wasmにコンパイルしました。

なぜZigを使用したのか？

3つの理由があります。

完全なGitプロトコルエンジンはピュアZigで書かれており（libc不要）、約100KBのWASMバイナリにコンパイルされます（最適化の余地あり！）。SHA-1、zlib inflate/deflate、デルタエンコーディング/デコーディング、パック解析、完全なGit Smart HTTPプロトコルを実装しており、すべてゼロから、標準ライブラリ以外の外部依存関係なしで実装されています。
Zigはメモリ割り当てに対する手動制御を提供します。これはDurable Objectsのような制約のある環境で重要です。
Zig Build Systemにより、WASMランタイム（本番環境）とネイティブビルド（libgit2に対する正確性検証テスト）の間でコードを簡単に共有できます。

WASMモジュールはシンコールバックインターフェース経由でJSホストと通信します。ストレージ操作用の11個のホストインポート関数（host_get_object、host_put_objectなど）と、ストリーミング出力用の1つ（host_emit_bytes）です。WASM側は完全にテスト可能です。

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

Artifactsの動作方法

Workers、Durable Objects、WebAssemblyの図

Workerはフロントエンドとして機能し、認証と認可、主要なメトリクス（エラー、レイテンシ）を処理し、各Artifactsリポジトリ（Durable Object）をオンザフライで検索します。

具体的には：

ファイルは基盤となるDurable ObjectのSQLiteデータベースに保存されます。 Durable Objectストレージの最大行サイズは2MBなので、大きなGitオブジェクトはチャンク化され、複数の行に保存されます。同期KV API（state.storage.kv）を使用しており、これはSQLiteによってサポートされています。
DOsには約128MBのメモリ制限があります。 これは数千万個をスポーン（高速で軽量）できることを意味しますが、これらの制限内で動作する必要があります。
フェッチとプッシュの両方のパスでストリーミングを多用します。 生のWASM出力チャンクから構築されたReadableStream<Uint8Array>を直接返します。
独自のGitデルタを計算することを避けます。 代わりに、生のデルタとベースハッシュは解決されたオブジェクトと並行して永続化されます。フェッチ時に、リクエストするクライアントがベースオブジェクトを既に持っている場合、Zigは完全なオブジェクトの代わりにデルタを発行し、帯域幅とメモリを節約します。
Gitプロトコルのv1とv2の両方をサポートします。 ls-refs、シャロークローン（deepen、deepen-since、deepen-relative）、have/wantネゴシエーションを含む増分フェッチなどの機能をサポートしています。
Gitクライアントとlibgit2サーバーに対する適合性テストを含む広範なテストスイートがあります。 プロトコルサポートを検証するための検証テストが設計されています。
ネイティブサポートgit-notes。 Artifactsはエージェント第一に設計されており、ノートはエージェントがGitオブジェクトにノート（メタデータ）を追加できるようにします。これにはプロンプト、エージェント属性、およびオブジェクト自体を変更することなくリポジトリから読み書きできるその他のメタデータが含まれます。

大きなリポジトリ、大きな問題？ ArtifactFSに会いましょう

ほとんどのリポジトリはそれほど大きくなく、Gitはストレージの点で非常に効率的になるように設計されています。ほとんどのリポジトリはクローンするのに数秒しかかかりません。ネットワークセットアップ時間、認証、チェックサムが支配的です。ほとんどのエージェントまたはサンドボックスシナリオでは、これは機能します。サンドボックスの開始時にリポジトリをクローンして作業を開始するだけです。

しかし、マルチGBリポジトリや数百万のオブジェクトを持つリポジトリはどうでしょうか？エージェントが数分間作業を開始できないようにブロックされ、コンピュートを消費することなく、そのリポジトリを迅速にクローンできますか？

人気のあるWebフレームワーク（2.4GBで長い履歴を持つ）はクローンするのに約2分かかります。シャロークローンはより高速ですが、1桁の秒に達するのに十分ではなく、常に履歴を省略したいわけではありません（エージェントはそれを有用と考えています）。

大きなリポジトリを約10～15秒に短縮して、エージェントが作業を開始できるようにできますか？

はい、いくつかのトリックで可能です。

Artifactsの起動の一部として、ArtifactFSをオープンソース化しています。これは、大きなGitリポジトリをできるだけ迅速にマウントするように設計されたファイルシステムドライバで、初期クローンをブロックする代わりにファイルコンテンツをオンザフライで水和します。エージェント、サンドボックス、コンテナ、および起動時間が重要なその他の使用例に最適です。

大きなリポジトリごとにサンドボックスの起動時間を約90～100秒削減でき、月に10,000のサンドボックスジョブを実行している場合、2,778のサンドボックス時間が節約されます。

ArtifactFSは「Gitクローンだが非同期」と考えることができます。

ArtifactFSの動作方法

ArtifactFSはGitリポジトリのbloblessクローンを実行します。ファイルツリーとrefsをフェッチしますが、ファイルコンテンツはフェッチしません。サンドボックスの起動中にそれを実行でき、その後、エージェントハーネスが作業を開始できます。

バックグラウンドでは、軽量なデーモン経由で同時にファイルコンテンツを水和（ダウンロード）し始めます。エージェントが通常最初に操作したいファイルを優先します。

パッケージマニフェスト（package.json、go.mod）
設定ファイル
コード

バイナリブロブ（画像、実行可能ファイル、その他のテキスト以外のファイル）を優先度を下げて、エージェントがファイル自体が水和されるときにファイルツリーをスキャンできるようにします。

エージェントが読み取ろうとしたときにファイルが完全に水和されていない場合、読み取りは水和されるまでブロックされます。

ファイルシステムはファイルをリモートリポジトリに「同期」しようとしません。数千または数百万のオブジェクトでは、それは通常非常に遅く、Gitを話しているため、必要ありません。エージェントはコミットしてプッシュするだけで、任意のリポジトリと同じです。新しいAPIを学ぶ必要はありません。

重要なことに、ArtifactFSは独自のArtifactsだけでなく、任意のGitリモートで動作します。GitHubやGitLab、または自己ホストGitインフラストラクチャから大きなリポジトリをクローンしている場合でも、ArtifactFSを使用できます。

Artifacts: versioned storage that speaks Git

要約

Summary

Key Points

翻訳