エージェントは、ソース管理、ファイルシステム、状態の永続化に関する考え方を一変させてきました。開発者やエージェントはかつてないほどのコードを生成しています。今後5年間に書かれるコードは、プログラミングの歴史全体で書かれた量を超えると予想されており、この需要に応えるために必要なシステムの規模は桁違いに変化するでしょう。ここで特に苦戦しているのが、ソース管理プラットフォームです。これらは人間のニーズを満たすために構築されたものです。そのため、眠ることなく一度で複数の問題に取り組み、疲れ知らずのエージェントがもたらす10倍ものボリューム変化に対応するようには構築されていないのです。
私たちは新しいプリミティブの必要性を考えています。すなわち、何よりもエージェントのために構築され、現在構築されているタイプのアプリケーションに対応できる、分散型のバージョン管理ファイルシステムです。
私たちはこれをアーティファクトと呼んでいます。Gitを使用するバージョン管理ファイルシステムです。エージェント、サンドボックス、Workers、その他のあらゆるコンピューティングパラダイムと並行して、プログラムでリポジトリを作成し、通常のGitクライアントから接続することができます。
すべてのエージェントセッションにリポジトリを付与したいですか？アーティファクトなら可能です。すべてのサンドボックスインスタンスに？それもアーティファクトです。既知の正当な開始点から10,000のフォークを作成したいですか？ご想像の通り、それもアーティファクトです。アーティファクトは、REST APIとネイティブのWorkers APIを公開しており、Gitクライアントが適切ではない環境（つまり、あらゆるサーバーレス機能内など）向けに、リポジトリの作成、認証情報の生成、コミットを可能にします。
アーティファクトは有料Workersプランをご利用の開発者向けにプライベートベータ版として利用可能であり、5月初旬までにパブリックベータ版の公開を目指しています。
// Create a repo
const repo = await env.AGENT_REPOS.create(name)
// Pass back the token & remote to your agent
return { repo.remote, repo.token }
# Clone it and use it like any regular git remote
$ git clone https://x:${TOKEN}@123def456abc.artifacts.cloudflare.net/git/repo-13194.git
以上です。即座で作成されたすぐに使えるリポジトリ。それはどのGitクライアントでも操作可能です。
また、既存のGitリポジトリからアーティファクトリポジトリをブートストラップし、エージェントが独立して作業でき、独立した変更をプッシュできるようにしたい場合でも、.import()を使用すれば可能です。
interface Env {
ARTIFACTS: Artifacts
}
export default {
async fetch(request: Request, env: Env) {
// Import from GitHub
const { remote, token } = await env.ARTIFACTS.import({
source: {
url: "https://github.com/cloudflare/workers-sdk",
branch: "main",
},
target: {
name: "workers-sdk",
},
})
// Get a handle to the imported repo
const repo = await env.ARTIFACTS.get("workers-sdk")
// Fork to an isolated, read-only copy
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リポジトリであるかのように動作させることができたらどうでしょうか？かなりうまく機能することが分かりました。また、Cloudflare Worker、Lambda関数、Node.jsアプリなど、Gitを使用しないクライアント向けに、REST APIと（近日中に）言語固有のSDKを公開しました。これらのクライアントは、同型-Gitを使用することもできますが、多くの場合、よりシンプルなTypeScript APIの方が、必要なAPIサーフェスを減らすことができます。
人工的なGit APIは、ソースコントロールのためだけのものだと思われるかもしれません。しかし、Git APIとデータモデルは、あらゆるデータのフォークやタイムトラベル、状態を区別できる方法で状態を保持する強力な方法であることが判明しました.
Cloudflare内では、内部エージェントのためにアーティファクトを活用しています。ファイルシステムの現圢の状態とセッション履歴をセッションごとのアーティファクトリポジトリへ自動的に永続化します。これにより以下が可能になります。
ブロックストレージのプロビジョニング（および維持）を必要とせず、サンドボックスの状態を永続化します。
他のユーザーとセッションを共有し、「実際の」リポジトリ（ソース管理）へのコミットの有無に関係なく、セッション（プロンプト）状態とファイル状態の両方を過去にさかのぼることができるようにします。
何よりすばらしいのは、任意のポイントからセッションをフォークし、チームが共同Workerとセッションを共有し、その続きを同僚に引き継いでもらうことができます。何かをデバッグして、別の視点からの意見も必要ですか？URLを送信してフォークしてください。APIについて議論したいですか？同僚にフォークしてもらい、中断した箇所から作業を再開してもらいましょう。
私たちはさらに、Gitプロトコルはまったく要件でなくとも、セマンティックス（差し戻し、クローニング、差分）が要件である場合にアーティファクトを活用したいというチームとも話をしました。製品の一部として顧客ごとの設定を保存し、ロールバック機能を必要としていますか？アーティファクトはこれを表現できる好例です。
Gitに重点を置いたユースケースと同様、Git以外の用途でアーティファクトを検討しているチームが他にもあることを、とても楽しみにしています。
アーティファクトはDurable Objects上に構築されています。ステートフルで分離されたコンピューティングのインスタンスを数百万（または数千万）以上作成できる能力は、現在のDurable Objectsの動作に固有のものであり、それはまさに、1つのネームスペースにつき数百万の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、deltaエンコーディング/デコーディング、パックパーシング、完全なgitスマートHTTPプロトコルを、すべてゼロから実装しており、標準ライブラリ以外の外部依存関係は一切ありません。
Zigを使用すると、メモリ割り当てを手動で制御できます。このことは、Durable Objectsのような制約ある環境において重要です。Zigビルドシステムにより、WASMランタイム（本番設定）とネイティブビルド（libgit2を用いた正確性検証テスト）間でコードを簡単に共有することができます。
WASMモジュールは、軽量なコールバックインターフェイスを介してJSホストと通信します。具体的には、ストレージ操作用のホストインポート関数が11個（host_get_object、host_put_objectなど）、ストリーミング出力用の関数が1個（host_emit_bytes）です。WASM側は、分離して完全にテスト可能です。
内部で、アーティファクトはR2（スナップショット用）とKV（認証トークンの追跡用）も使用します：
Artifactsの仕組み（Workers、Durable Objects、WebAssembly）
Workerはフロントエンドとして機能し、認証&認可、主要なメトリクス（エラー、遅延）を処理し、各アーティファクトリポジトリ（Durable Object）をその場で検索します。
特に：
ファイルは、基盤となるDurable ObjectのSQLiteデータベースに保存されます。
DOには最大128MBのメモリ制限があります。これにより、（高速かつ軽量な）最新アプリケーションを生成することが可能ですが、その限界内で動作しなければなりません。
フェッチパスとプッシュパスの両方でストリーミングを多用し、未加工のWASM出力チャンクから構築された `ReadableStream<Uint8Array>` を直接返しています。
独自のGitデルタを計算することを避け、その代わりに未加工のデルタとベースハッシュは解決されたオブジェクトと並行して保持されます。フェッチにおいて、リクエストしたクライアントがすでにベースオブジェクトを持っている場合、Zigは完全なオブジェクトではなくデルタを出力するため、帯域幅とメモリを節約できます。
gitプロトコルのv1とv2の両方をサポートします。
さらに、git-notesをネイティブでサポートしています。アーティファクトはエージェントファーストであるように設計されており、メモにより、エージェントはGitオブジェクトにメモ（メタデータ）を追加することができます。これには、オブジェクト自体を変更することなく、リポジトリから読み取り/書き込みができるプロンプトやエージェント属性、その他のメタデータが含まれます。
大きなレポジトリ、大きな問題？それではArtifactFSをぜひ。
ほとんどのリポジトリはそれほど大きくなく、Gitはストレージ面で非常に効率的であるよう設計されています。すなわち、ほとんどのリポジトリはクローンにせいぜい数秒しかかからず、ネットワークのセットアップ時間、認証、チェックサム処理に占められています。これは、ほとんどのエージェントやサンドボックスのシナリオで実用的です。サンドボックスが開始して動作する際、リポジトリをクローンするだけで済みます。
しかし、マルチGBのリポジトリや、数百万のオブジェクトを含むリポジトリはどうでしょう？エージェントの数分間の動作を妨げず、コンピューティングを消費することなく、そのリポジトリを迅速にクローンするにはどうすればよいでしょうか？
人気あるWebフレームワーク（2.4GBで、長い歴史を持ちます！）は、クローン化に2分近くかかります。シャロ―クローンはより高速ですが、1桁秒にまで短縮できるほどではなく、履歴を省略したくない場合もあります（エージェントにとってそれは有用だからです）。
エージェントが動作するように、大きなレポジトリを10～15秒にまで短縮することは可能でしょうか？ええ、可能です。いくつか工夫すればですが。
アーティファクト登場の一環として、ArtifactFSはオープンソース化します。これは大きなGitレポジトリをできるだけ即時にスキャンするように設計されており、最初のクローンでブロックするのではなく、その場でファイルコンテンツをハイライトするよう設計されています。エージェントやサンドボックス、コンテナ、その他起動時間が重視されるユースケースに最適です。大規模なリポジトリごとにサンドボックスの起動時間を90～100秒短縮でき、月に10,000件のサンドボックスジョブを実行する場合、2,778時間のサンドボックス時間を節約することができます。
ArtifactFSは、「非同期のGitクローン」と考えることができます。
ArtifactFSは、gitリポジトリのコンテンツを含まないクローンを作成します。ファイルツリーと参照は取得しますが、ファイルコンテンツは取得しません。サンドボックス起動時に実行でき、それによりエージェントハーネスが作業を開始できるようになります。
バックグラウンドでは軽量なデーモンを介して、ファイルコンテンツのハイドレーション（ダウンロード）を同時に開始します。
エージェントが通常最初に操作したいファイル、つまりパッケージマニフェスト（package.json、go.mod）、設定ファイル、コードを優先し、可能な限りバイナリブロブ（画像、実行可能ファイル、その他の非テキストファイル）の優先順位を下げます。それにより、ファイル自体が読み込まれるにつれてエージェントがファイルツリーをスキャンできるようにします。
エージェントがファイルを読み取ろうとした際、それが完全にハイドレートされていない場合、ハイドレート完了まで読み取りはブロックされます。
ファイルシステムは、ファイルをリモートリポジトリに「同期」しようとはしません。何千、何百万ものオブジェクトがある場合、通常非常に時間がかかります。ここで話しているのはGitについてですので、同期の必要はありません。エージェントは、他のリポジトリと同様、コミットしてプッシュするだけです。新しいAPIを学ぶ必要はありません。
重要なのは、ArtifactFSが当社のアーティファクトだけでなく、あらゆるGitリモートと連携できることです。GitHub、GitLab、セルフホスト型Gitインフラストラクチャから大規模なリポジトリをクローンする場合でも、ArtifactFSを使用できます。
本日のリリースはベータ版のみです。しかし、すでに多くの機能に取り組んでおり、今後数週間のうちに提供を開始する予定です。
公開予定の利用可能なメトリクスを拡張中です。現在、ネームスペースごとの主要な操作数やリポジトリ、リポジトリごとの保存バイト数のメトリクスを提供しています。これにより、数百万ものアーティファクト管理が容易になります。
リポジトリレベルのイベント向けイベントサブスクリプションをサポート。これにより、プッシュ、プル、クローン、フォークのイベントをネームスペース内の任意のリポジトリへ出力できます。さらに、イベントの消費、Webhookの書き込み、それらのイベントを使ったエンドユーザーへの通知、製品内のライフサイクルイベントの駆動、ポストプッシュジョブ（CI/CDなど）の実行も可能です。
アーティファクトAPIと対話するためのネイティブなTypeScript、Go、PythonクライアントSDK
リポジトリレベルの検索APIやネームスペース全体の検索API。たとえば、「package.jsonファイルを持つすべてのリポジトリを探す」など。
また、Workers Builds向けAPIも計画しており、エージェント主導のワークフローでCI/CDジョブも実行できます。
アーティファクト導入はまだ初期段階ですが、エージェント規模で機能する価格設定を検討中です。リポジトリが数百万あっても、コスト効率がよくあるべきで、未使用（あるいはほとんど使用されない）のリポジトリが足かせになるべきではありません。さらに価格設定は、エージェントの持つ大規模なシングルテナントの性質と一致している必要があるると考えています。
また、リポジトリが使用されるかどうか、ホットかコールドか、そして/またはエージェントがそれを起動しようとしているかどうかを考える必要はありません。消費されたストレージと操作（例：クローン、フォーク、プッシュ＆プルなど）に対して課金されます。
| $/単位 | 含む |
|---|
操作 | 1,000回の操作につき$0.15 | 最初の1万件込み（1か月あたり） |
ストレージ | $0.50/GB-月 | 最初の1GB込み。 |
規模が大きく活発なリポジトリは、規模が小さく利用頻度の低いリポジトリよりもコストがかかるでしょう。それは1,000個、10万個、または1000万個であっても同じです。
ベータ版の進捗に合わせて、あーていファクトをWorkers Freeプラン（公正な制限あり）にも提供する予定です。この価格設定が変更された場合、料金の請求が行われる前に、ベータ期間中、随時情報を更新しお知らせします。
アーティファクトは現在プライベートベータ版として公開されています。5月初旬（念のため申し上げますが2026年です！）には、パブリックベータ版の準備が完了する予定です。お客様には今後数週間かけて徐々にご利用いただけるようにする予定です。直接、プライベートベータ版への関心をご登録いただくことも可能です。
また、アーティファクトについて詳しくは、以下をご覧ください。
Changelogをフォローして、ベータ版の進捗を追跡してください。