Cloudflare Artifacts がおもしろい

ゼンクエンジニアのすぎもとです。

今日は Cloudflare Artifacts について書きたいと思います。これ、発表自体は4月なので、記事にするにはいまさらという感じではあるのですが、10/1にオープンベータが発表され、そろそろ試せそうなので記事を書いておこうと思い立ちまして、筆を執ってます（筆を執るって言葉久しぶりに使ったな）

Cloudflare Artifacts は、簡単に言えば 「ファイルやコードを履歴付きで保存し、Gitの操作で読み書きできるストレージ」 です。アプリケーションからリポジトリを作成し、そのURLをエージェントや開発ツールに渡して使えます。公式ドキュメントでは、ユーザー、プロジェクト、エージェントのセッションなど、細かな単位でリポジトリを持つ用途が紹介されています。Artifactsの概要

最初見た時は「Cloudflare が GitHub みたいなサービスを始めるの？」みたいな印象だったんですけど、全然違ってました。個人的にはかなりおもしろいなとおもってます。

たとえば、AIがWebサイトを修正するサービスを考えてみます。実行環境を立ち上げるだけでは、「どのファイルを変更したか」「変更前に戻せるか」「別の修正案と比較できるか」は解決しません。こうしたサービスに、ファイル一式と変更履歴を保存する場所を組み込む、というのがArtifactsの使い方です。

AI Agent に履歴付きの環境を与えるためにみんな知ってる Git の意味論がちょうどよかったので、それを実装した環境を提供することにした、みたいな感じ。Git は「ある時点のファイル一式を記録できる仕組み」で AI もツールとして既に知識をもっているのでその概念をそのまま使いやすいわけですね。

Git のデータモデルを使えば、ソースコードだけでなく、設定ファイル、生成した文書、エージェントが作業を再開するための情報なども、ファイルとしてバージョン管理できます。たとえば「顧客Aの設定を昨日のコミットに戻す」「同じ開始状態から二つの修正案を試す」といったアプリケーションを設計できます。ここで大事なのは、単体の履歴付きファイルってことじゃなく、ワークスペースごとコミット単位で履歴管理を行えるというところですね。

なんでこんなものが必要だったのかというと、エージェントに与える情報として、リポジトリそのものをエージェント・セッション・タスク単位で生成するべき、っていう思想があるんだとおもいます（実際、このサービスにおいてリポジトリ数は現在の制限では Unlimited となっている）最近 OpenAI の Dots のようにエージェントごとに環境を用意する流れが加速してますが、ただのコンテナでは足りず、ファイルシステムがこうなっていればもっと効率的なはずです。いやあ、確かにそうです。すごい。

というわけで、いま注目している Cloudflare Artifacts の紹介でした。

具体的なサービスの細かい内容については AI にまとめてもらったのでそれを紹介しておきましょう。まあこれは読まなくてもいいです。あいかわらずAIにやらせると冗長だな。

では、また。

↓ここからAIによるまとめ

具体的な Artifacts の仕組み

Artifactsでは、リポジトリがGitの履歴、参照、URL、トークン、削除などのライフサイクルを持つ独立した単位になります。同じリポジトリに、次の三つの入口からアクセスします。Repositories

APIで作ったリポジトリにGitで接続できるので、管理する側と作業する側が同じ道具を使う必要はありません。Workerが作業場所を用意し、コンテナ内のエージェントが通常のGitコマンドで編集結果を保存する、といった組み合わせができます。

リポジトリはnamespaceの中に作成します。名前空間は、prodとstagingのような環境別、顧客別などにリポジトリをまとめる入れ物です。リポジトリ名は名前空間内で一意にします。名前空間は明示的に作成できるほか、最初のリポジトリ作成時に自動作成される仕組みもあります。Namespaces

認証は入口ごとに異なります。Workers bindingは設定したバインディングを利用し、REST APIはCloudflare APIトークン、Gitはリポジトリ専用トークンを使います。Git用トークンのreadは読み取り操作、writeは読み取りとpushを許可します。アプリケーションは、利用者を認証し、その作業用リポジトリへのアクセス権を確認したうえでトークンを渡します。Authentication

内部アーキテクチャ：小さなGitサーバーをリポジトリごとに持つ

図1：内部構成は2026年4月16日の公式発表に基づきます。上段のAPIから内部への経路は概念表現で、実際のすべての呼び出し経路や複製先を表したものではありません。

Workerが入口を受け持ち、Durable Objectが状態を持つ

初回発表では、入口のWorkerが認証・認可、メトリクスの記録、対象リポジトリに対応するDurable Objectの検索を行う構成が示されています。Gitの状態を持つ側にはDurable Objectsを使い、認証トークンの追跡にはWorkers KV、スナップショットにはR2を使っています。初回発表の「Under the hood」

Durable Objectは、固有の識別子を持ち、計算処理と永続ストレージを組み合わせた仕組みです。世界のどこからでも同じオブジェクトへ要求を送れ、必要に応じて起動し、アイドル時には停止します。データは処理の終了後も残ります。What are Durable Objects?

Artifactsの公式説明では、一つのリポジトリを、どの地域からでもルーティングできる一つの論理インスタンスとして扱っています。利用者から見ると、作業ごとに独立したGitサービスを用意する形です。How Artifacts works

GitエンジンはZigからWebAssemblyへ

Gitプロトコルを処理するエンジンはZigで実装され、WebAssemblyにコンパイルされています。初回発表時のバイナリサイズは約100KBで、Gitのpack処理や圧縮・差分の処理などを担います。GitオブジェクトはDurable ObjectのSQLiteに保存し、大きなオブジェクトは分割します。fetchとpushではストリーミングを使い、メモリにデータ全体を抱え込むことを避けています。初回発表の実装解説

図中の「SQLite」と「認証用KV」は役割が異なります。リポジトリのファイル内容を保持するストレージと、認証トークンを追跡するサービスを分けて読むと、データの保存先を取り違えずに済みます。

永続性と、リポジトリ数のスケールを分けて考える

リポジトリのデータは複数のデータセンターへ同期複製し、オブジェクトストレージやスナップショットへ非同期でコピーする、と公式ドキュメントは説明しています。一つのプロセスやデータセンターが動き続けることに依存せず、複製やフェイルオーバーの管理をサービス側が担います。Durability

この構成は、独立した作業場所をたくさん作るモデルとして理解できます。ただし、「リポジトリを多数作れること」と「一つのリポジトリの容量や処理量が無制限であること」は区別する必要があります。後述する上限も、名前空間単位とリポジトリ単位に分かれています。

エージェントごとにforkするワークフロー

図2：複数のエージェントが並行して作業するアプリケーションの設計例です。レビューと採用の判断は、Artifactsを利用する側で実装します。

同じコードから「不具合修正」「文書更新」「別の実装案の検討」を同時に始めたい場合、作業ごとにリポジトリをforkできます。fork先は元の履歴を出発点にしつつ、独自のトークン、参照、ライフサイクルを持ち、その後は独立して変更されます。Forkの基本モデル

設計例としては、次の順序になります。

1. レビュー済みの開始状態を用意し、比較の基準となるコミットを記録する。
2. タスクごとにforkし、対応するリポジトリのトークンを発行する。
3. エージェントがSandboxなどでclone・編集・commit・pushする。
4. アプリケーションが基準からの差分を比較し、テストとレビューを行う。
5. 採用する結果をGitで統合し、不要になった作業リポジトリを整理する。

公式のベストプラクティスも、エージェントやセッションを独立した作業単位にし、共通の基準からforkする方法を勧めています。ブランチを使う方法は、共同作業者が同じリポジトリとライフサイクルを共有する場合に向いています。Best practices for Artifacts

作業場所を分離しても、最終的なマージ時の競合は起こり得ます。また、同じ開始状態で比較したいなら、forkの間に基準リポジトリが更新されない運用も必要です。タスクの割り当て、比較対象の管理、採用する変更の判断はアプリケーションの仕事になります。

エージェントの実行情報をコミットと結び付けたい場合は、git notesも使えます。プロンプトや実行IDなどをコミットに付記し、作業ツリーとコミット本体を変更せずに周辺情報を保存できます。notesは別の参照に保存されるため、他のシステムと同期するときはrefs/notes/*も明示的に送受信します。実行情報とgit notes

コードで見る「作業場所を用意して渡す」流れ

以下は、既存の基準リポジトリreviewed-templateから作業場所を作る説明用の例です。APIの形は調査時点のWorkers bindingリファレンスに合わせています。Cloudflareへの接続動作は未検証です。

Wrangler設定に名前空間のバインディングを追加します。

[[artifacts]]
binding = "ARTIFACTS"
namespace = "agent-workspaces"

Worker側では、認証・認可を済ませた処理から次の関数を呼ぶ想定です。Envはwrangler typesで生成した型を使います。

async function prepareWorkspace(env: Env) {
  using template = await env.ARTIFACTS.get("reviewed-template");
  const workspace = await template.fork(`job-${crypto.randomUUID()}`, {
    readOnly: false,
  });

  using taskRepo = await env.ARTIFACTS.get(workspace.name);
  const access = await taskRepo.createToken("write", 3600);

  return {
    repository: workspace.name,
    remote: workspace.remote,
    token: access.plaintext,
    expiresAt: access.expiresAt,
  };
}

get()の戻り値は、リポジトリを操作するハンドルです。usingでハンドルを解放してもリポジトリ自体は削除されません。createToken()の戻り値は構造化されており、Gitに渡す文字列はplaintextです。公式資料ではArtifactsの型生成やローカルでのremote binding利用にWrangler 4.145.0以降を案内しています。ハンドル・トークン・型の仕様

エージェント側は、受け取ったURLとトークンでGitを使います。次の環境変数には関数の戻り値を渡す想定です。URLを手作業で組み立てず、返されたremoteをそのまま使います。

# ARTIFACTS_REMOTEとARTIFACTS_TOKENは起動側から渡す
git -c http.extraHeader="Authorization: Bearer ${ARTIFACTS_TOKEN}" \
  clone "${ARTIFACTS_REMOTE}" workdir

cd workdir
# ファイルを編集した後
git add --all
git commit -m "Apply task changes"
git -c http.extraHeader="Authorization: Bearer ${ARTIFACTS_TOKEN}" \
  push origin HEAD

この方法はトークンをGitのremote URLに含めず、コマンドごとのHTTPヘッダーで渡します。writeトークンは作業リポジトリへのpushを許可し、レビューだけならreadを使います。トークンが期限切れになったら、起動側で再発行する設計にします。Git protocol

R2、Artifacts、GitHubでは何が違うのか

図3：主に何を管理するサービスか、という観点での比較です。機能や性能の優劣を示す図ではありません。

R2は、images/photo.pngのようなキーでオブジェクトを扱うストレージです。/でフォルダのように見せることはできますが、内部のキー空間はフラットです。ファイルを保存する機能を基に、プロジェクトの履歴や分岐をどう表現するかは利用側で設計します。R2 Objects、R2の概要

Artifactsを選ぶ動機は、「ファイルの集合をGitの履歴と一緒に扱い、プログラムから作業場所を増やす」という要件です。一方、GitHubはGitのホスティングに計画、レビュー、テスト、デプロイなどの機能を組み合わせた開発プラットフォームです。What is GitHub?

10月1日のCloudflareの発表でも、Artifactsを土台に、エージェントの協調、レビュー、マージの体験を開発者が構築する方向を示しています。Artifactsを利用するだけで、GitHubのIssueやPull Requestと同じ画面や運用が揃う、と解釈するのは避けるべきでしょう。Gitプラットフォームを構築するという公式の位置付け

組み合わせの例としては、共有・レビュー済みのコードをGitHubで管理し、エージェントの作業用コピーをArtifactsに作り、大きな画像や動画をR2に置く構成が考えられます。これは用途から考えた設計例で、製品間の同期や採用結果の戻し方は別途実装する必要があります。

ArtifactFS：ファイルの取得を後回しにして作業を始める

Artifacts本体と関連するものに、ArtifactFSがあります。これはGitリポジトリをローカルのファイルシステムとしてマウントするドライバーです。Artifactsのremoteに加え、ほかのGitリポジトリでも利用できます。ArtifactFS

図4：待ち時間が発生する場所の違いを示した模式図です。枠の長さは実測時間を表していません。

ArtifactFSは最初にblobless cloneでコミット、tree、参照を取得し、FUSEで作業ツリーをマウントします。ファイルの内容は非同期に取得し、まだ取得していないファイルを読んだときに、その取得を待ちます。取得済みの内容はローカルキャッシュから読めます。ArtifactFSの動作

つまり、すべての内容の取得を開始前に待つ代わりに、必要な内容の取得待ちを読み取り時へ移せます。FUSEが使えるSandbox、コンテナ、VMなどで、初期取得が作業開始を妨げる場合に検討する機能です。小さなリポジトリは通常のcloneの方が運用を単純にできます。

この説明から、Artifactsに任意の大きさのリポジトリを保存できるとは言えません。ArtifactFSが他のGitサービスでも動くことと、Artifacts本体の保存上限は分けて判断します。また、実際の所要時間はファイル構成、ネットワーク、どのファイルを最初に読むかなどで変わるため、このドラフトでは高速化率を示しません。

保存した変更から、レビューやデプロイにつなげる

Artifactsはリポジトリの作成、fork、pushなどに対するイベントを発行します。イベントを購読し、Workerからレビューやビルドの処理を起動する仕組みを組み込めます。たとえばpushイベントには、対象の参照と変更前後のコミットが含まれるため、レビューする変更を特定する材料になります。Event subscriptions

Workerを通常の手順でビルド・デプロイする場合は、Workers BuildsとArtifactsを接続する方法があります。本番ブランチへのpushをデプロイにつなげ、ほかのブランチではWorker Previewsを作成できます。独自のCIが必要なら、Workflowsと@cloudflare/ciでチェックやビルド、デプロイの手順を定義します。Build and deploy Artifacts repos

前のワークフローに当てはめるなら、「エージェントがpushした」という保存側の出来事を、実行側のテストやレビューの開始条件にできます。保存先だけを用意する段階から、自分のサービスの作業フローへ組み込む段階へ進める接点です。

料金と利用上限

2026年10月6日に確認した料金ドキュメントでは、利用にはWorkers Paidプランが必要です。Artifactsの課金軸は操作数と保存容量で、リポジトリ数そのものを料金単位にした表ではありません。Pricing

保存容量はリポジトリ全体で集計され、複製データによる追加のストレージ課金はありません。リポジトリは明示的に削除するまで保存されます。作業終了後の整理も、コストと保存期間を考えるうえで設計に含めます。

利用上限は次の通りです。Limits

この上限を踏まえると、大きなファイルを含む一つのリポジトリへ作業を集約する設計より、必要な粒度で作業を分ける設計を検討しやすくなります。「数の上限なし」であっても保存容量と要求数の制約は残るため、実際のデータ量や操作頻度を見て判断します。

データの保存・処理場所を制限したい場合は、名前空間の作成時にjurisdictionを指定できます。調査時点の対応はEUと米国で、作成後は変更できません。日本を指定できるという記載はありません。Data localization