ArFleetとは？ArweaveやAOを補完する一時ストレージ [DeepResearch]

本記事はDeepResearch結果を日本語に翻訳したものです。
deep-research-arweave

[PROMPT]

Please conduct a detailed technical investigation into **Arweave’s ArFleet**, specifically from the perspective of **Web3 developers** considering integration into real-world dApps.

### Information Source Prioritization (Only use primary sources published **after July 2024**):

1. GitHub (e.g., [`aoacc/arfleet-js`](https://github.com/aoacc/arfleet-js): codebase, README, examples)
2. Official documentation (ao/acc, Arweave core docs, Community Labs materials)
3. Developer blogs, walkthroughs, and hackathon demos
4. Developer posts on X (formerly Twitter) by ao/acc and Arweave core contributors
5. Publicly shared AMA transcripts, community calls, and presentations

## Output Structure (in Markdown)

### 1. Overview of ArFleet

- Project definition and primary use cases (specifically in the context of Web3 apps)
- Development entity (ao/acc Labs) and its relationship to AO and the Arweave core team
- Current release status (mainnet, alpha, testnet availability)

### 2. Technical Architecture and Integration Design

- System components relevant to developers (Actor-based flow, data handling scope)
- Architecture on AO: how Actors, Processes, and Executors are used
- Supported operations (store, fetch, delete)
- Integration points with Arweave (when and how data is persisted)

### 3. API, SDK, and Tooling

- Available SDKs and APIs (focus on `arfleet-js`)
- JS/TS usage examples (e.g., uploading ephemeral JSON, files)
- Deployment setup: how to install, configure, and start using ArFleet
- Testing options (local dev mode, AO testnet)

### 4. Integration & Usage Examples

- Real dApp integration patterns (e.g., AI agents, dashboards, ephemeral user data)
- Compatibility with other AO actors or external chains
- Supported data formats (binary, JSON, etc.)

### 5. Incentives and Payment Logic

- How developers and users are charged (via \$AO or \$AR)
- How to integrate billing into a dApp (user-pays, subsidized, hybrid models)
- Whether ArFleet has (or plans to have) a native token — and why \[mark as “TBD” if unknown]

### 6. Roadmap & Known Limitations

- Short- and mid-term development plans
- Current constraints (e.g., TTL duration, actor instance limits, storage quotas)

## Output Requirements

- Use **Markdown format**
- Include **reliable source links** in each section
- Include code snippets or diagrams where appropriate
- Clearly mark unknown or speculative information with `[TBD]` or `[To Be Confirmed]`
- State the date of the research clearly at the top (e.g., “As of July 2025”)

1. ArFleet の概要

プロジェクトの定義と主なユースケース（Web3 アプリケーション文脈）

ArFleet は、Arweave の新たな AO（Actor-Oriented）計算環境上に構築された、分散型の一時的ストレージプロトコルです。これは、従来の「永続的ストレージ」中心だった Arweave に対して、期間限定でデータ保存ができる選択肢を提供します。

この仕組みによって、Web3 アプリは以下のような一時的データの保存が可能になります：

• セッションデータ
• キャッシュファイル
• AI モデルの出力
• メッセージ下書き
• 一定期間のみ必要なユーザーデータ

開発者は、恒久的保存が不要なデータを安価に保存でき、Arweave 本来の「永遠性」の特性と補完関係を形成します。

開発主体：ao/acc Labs

ArFleet は ao/acc Labs によって開発されています。同団体は、Arweave の AO 計算レイヤーを活用した分散型アプリケーションの構築を牽引しており、Arweave エコシステムのコアメンバーと密接に連携しています。Sam Williams（Arweave 創設者）も ArFleet の発表を公式に支援しており、ArFleet は Arweave の中核構想「Fully Decentralized Stack（完全分散型スタック）」の重要構成要素として位置付けられています。

要するに、ArFleet は「AO ＝計算」「Arweave ＝永続ストレージ」に加え、「ArFleet ＝一時ストレージ」を組み合わせることで、あらゆるデータのライフサイクルに対応可能な完全分散型基盤を実現することを目的としています。

現在のリリース状況（2025 年 7 月時点）

• テストネット：ArFleet は 2024 年 8 月末に Alpha テストネット をローンチしました。

  • このフェーズでは、「Genesis Pass」と呼ばれる NFT を保有しているユーザーのみが、クライアントまたはストレージ提供者（プロバイダ）として参加可能でした。

• プロダクト更新：その後、テストネット版クライアントや Web UI（v0.1.2 など）が複数回アップデートされています。

• AO 本番稼働：AO 自体は 2025 年 2 月にメインネット稼働を開始し、$AO トークンの利用も可能になりました。

• ArFleet 本番移行：現在（2025 年 7 月）も本格的なメインネット統合が進行中であり、一部ユーザー・開発者はすでにメインネット上で ArFleet を利用しています。

つまり、ArFleet はまだフルローンチ前の段階にありつつも、AO メインネット上での実稼働が始まっているプロジェクトです。既存の開発者は、テストネットまたはメインネット上で、AR や AO トークンを用いた一時ストレージ操作をすでに試行可能です。

2. 技術アーキテクチャと統合設計

AO ベースのアクターアーキテクチャ

ArFleet は、Arweave の AO（Actor-Oriented）プロトコル上に構築されています。すべてのロジックは「アクター（プロセス）」として動作し、完全な非中央集権かつ検証可能な環境でストレージ契約を処理します。

ArFleet に関わる 2 つの主要な役割：

• クライアント：保存を依頼するユーザーや dApp
• プロバイダー：保存を引き受けるノード（ストレージ提供者）

これらの間の取引（Deal）は、AO 上のアクターによって管理され、オンチェーンで強制力を持ちます。

主要コンポーネント

Marketplace アクター

• 各プロバイダーは、グローバルなマーケットプレイスアクターにストレージ提供の広告（announce）を送信します。

• この広告には、次の情報が含まれます：

  • Arweave ウォレットアドレス（ID）
  • ネットワークアドレス（IP とポート）
  • 価格、最大保存期間、チャレンジ間隔

• クライアントはこのアクターを通じて、条件に一致するプロバイダーを検索します。

Deal アクター（プロセス）

• クライアントとプロバイダーの間でストレージ契約が成立すると、専用の AO プロセスが 1 つ立ち上がります。
• このアクターが取引のエスクロー（支払い＆担保）管理、検証、スラッシング（罰則）などを担います。
• すべてのアクターは AO の実行ノード（executor）によって動作し、そのすべての操作が Arweave 上に記録されます（＝ holographic state）。

データの流れと契約のライフサイクル

1. ストレージ要求の作成
   クライアントが保存したいデータと条件（サイズ、保存期間、複製数、報酬）を指定して、保存ジョブ（Assignment）を生成します。

2. プロバイダーの選定
   Marketplace アクター経由で候補プロバイダーを取得し、オフチェーンで接続して詳細確認（キャパシティ、通信可否など）を行います。

3. Deal の生成とアクター起動
   マッチング成立後、Deal アクター（プロセス）を新規に生成し、以下の情報を引き渡します：

   • 暗号化されたデータの Merkle root
   • 参加者の ID
   • 保存期間、報酬、担保 など

4. 支払い＆担保のエスクロー

   • クライアントは Deal アクターに報酬（例：AR）を送金します。
   • プロバイダーは担保資産をロックします（失敗時にスラッシュ対象）。

5. データのアップロード
   クライアントがプロバイダーにデータを暗号化してチャンク単位で送信します（オフチェーン通信）。

6. 契約の発効と保存期間開始
   両者が合意・資金ロック済みとなれば、Deal アクターが正式に保存契約の開始を宣言します。

7. 保存中の検証チャレンジ
   Deal アクターが**ランダムにプロバイダーへチャレンジ（検証リクエスト）**を発行します。

   • Merkle ツリーに基づいたチャンクの一部と証明を提出する必要があります。
   • 提出が不正または期限切れの場合、担保の一部または全額がスラッシュされます。

8. 保存期限の満了と契約終了

   • 保存期間（TTL）が終了すると、プロバイダーはデータを削除してよくなります。
   • Deal アクターは報酬をプロバイダーへ支払い、契約を完了状態にします。

ストレージの仕様と検証設計

• チャンク分割：ファイルは 8KB のチャンクに分割され、各チャンクに暗号化が施されます。
• Merkle Root 管理：チャンクのハッシュから Merkle ツリーを生成し、Root Hash が契約の基準となります。
• 多重暗号：RSA ベースの暗号化に加え、ユーザー任意で AES-256 暗号化も可能です。
• オフチェーン転送：ファイル自体は AO や Arweave には保存されず、プロバイダーのローカルに保存されます。
• オンチェーン記録：Deal アクターの状態（root hash、チャレンジ履歴など）は Arweave へ永続記録され、検証可能です。

3. API、SDK、ツール群の紹介

ArFleet は Web3 開発者向けに、複数の開発・運用ツールを提供しています。

ArFleet Web アプリ

• 概要：ブラウザ上で動作する非インストール型クライアント。Arweave ウォレットを接続すれば、誰でも簡単にファイルを一時保存できます。

• 用途：技術者でなくても簡単に ArFleet を試せるエントリーポイントです。手軽なテストやデモ用に最適。

• 制約：

  • ファイルサイズに制限あり（ブラウザ環境ゆえ）
  • アップロード中はタブを開いたままにする必要があります

• 支払い手段：テストネット時は**wAR（Wrapped AR）**を使用しており、Web UI 上で AR の変換や支払いが可能です。

ArFleet-JS（JavaScript SDK & CLI）

• 特徴：

  • Node.js ベースのローカルクライアント
  • CLI（コマンドラインインターフェース）とライブラリ両方を提供
  • より大きなファイルや自動処理、スクリプト連携が可能

• 用途：

  • dApp のバックエンドで ArFleet 操作を統合
  • ストレージの自動化、サーバー上での大量アップロード

• 使い方（CLI 例）：

  git clone https://github.com/aoacc/arfleet-js.git
  cd arfleet-js/backend && npm install
  cd ../frontend && npm install
  ./arfleet client store ./path/to/file.png
  

• ウォレット接続：

  • デフォルトではローカルに新しいウォレットを生成（~/.arfleet-client/wallet.json）
  • 既存の Arweave キーファイルを置き換えて利用も可能

• Genesis Pass 要件（※テストネット時のみ）：

  • テスト期間中は「Genesis Pass NFT」を持っているウォレットのみがクライアントまたはプロバイダーとして参加可能でした
  • NFT を自分のウォレットに送ればクライアント機能が有効になります

ArFleet-Erlang（Erlang 版クライアント）

• 特徴：

  • Erlang/OTP ベースの高性能クライアント
  • サーバー運用やスケーラブルなプロバイダーノード構築に最適

• 用途：

  • 高頻度の保存リクエストや大容量ストレージを想定するプロバイダー向け
  • 分散型インフラの一部として ArFleet を提供したい企業・サービス

• GitHub：aoacc/arfleet-erl

ストレージプロバイダー構築ツール

• arfleet provider を実行することで、ローカル環境でプロバイダーとして稼働可能

• 必要事項：

  • Arweave ウォレット
  • ストレージ容量・価格設定などの初期設定
  • マーケットプレイスへのアナウンス（＝プロバイダー広告）

開発・検証環境

• テストネット：開発者は AO テストネット上で ArFleet の試験運用が可能（Genesis Pass が必要な時期あり）

• メインネット：2025 年 2 月以降、AO メインネット稼働に伴い、順次 ArFleet もメインネットへ移行中

• ローカル開発：

  • AO 自体をローカルで動かすのは高度だが、将来的にはローカルノード環境の提供も期待されます

• 今後の課題：

  • SDK の API ドキュメント整備
  • UI/UX の向上（特に CLI エラーメッセージなど）
  • Web2 開発者向けガイドの充実

プログラムからの利用例（擬似コード）

const arfleet = require("arfleet-js-backend"); // 仮のモジュール名

await arfleet.init({ walletPath: "./wallet.json" });

const result = await arfleet.storeData(Buffer.from(JSON.stringify(myData)), {
  duration: 3600,
});

console.log("Stored TXID:", result.txid);

※現状は CLI を通じた操作が主ですが、将来的にはこのようなプログラマブルな統合も想定されています。

承知しました。以下は第 4 節「4. 統合事例とユースケース」の日本語訳です。

4. 統合事例とユースケース

ArFleet は、Web3 アプリケーションにおける**「分散型一時ストレージ」**の実現手段として、以下のようなさまざまなユースケースを開拓しています。

オンチェーン AI とエージェントメモリ

• AO の中心的ユースケースの 1 つはオンチェーン AI エージェントです。
• これらのエージェントは、プロンプト履歴、推論結果、一時的な文脈などの短命なデータを大量に扱います。
• ArFleet は、こうしたデータの一時保存先として、AI エージェントの「作業メモリ」的役割を果たします。
• 永続化が必要な成果物は Arweave へ、セッション中のみ必要なワークデータは ArFleet へ、という使い分けにより、「永続」と「一時」のストレージを組み合わせた設計が可能になります。

dApp の一時的 UI データやセッション管理

• ソーシャル dApp やダッシュボードなどでは、次のようなデータが一時的に必要になります：

  • 入力途中の下書き
  • セッションの状態（例：タブ間での共有）
  • 一時的な画像アップロードや通知バッファ

• こうしたデータを ArFleet で処理することで、Web2 的なユーザビリティを保ちつつ、バックエンドを分散化することが可能になります。

• 例：チャットアプリでは、投稿メッセージは Arweave で永続化、一時的な「入力中…」状態や 24 時間限定ストーリーなどは ArFleet で保存する、という設計が考えられます。

オラクルやリアルタイムフィード

• 高頻度で変化する価格情報やセンサー値などは、**「古くなったら無価値になる」**という性質があります。

• RedStone のようなオラクルプロトコルが ArFleet を活用すれば、以下のような設計が可能です：

  • 最新の価格やデータは ArFleet に保存し、素早く参照
  • 重要なスナップショットやイベントだけを Arweave に永続保存

• また、複数のプロバイダーに対して**冗長保存（例：3 つのノードにコピー）**することで、読み取りの高速化や地域分散も可能になります。

Web2 連携やクロスチェーン dApp

• ArFleet の保存対象はフォーマット非依存（JSON、画像、動画、バイナリなど）なので、Web2 との橋渡しにも有効です。

• 例えば：

  • DAO の「一時提案受付箱」（1 週間だけ公開される PDF を ArFleet で保存）
  • マルチチェーン dApp が、一時的データを ArFleet に置いて外部チェーンと連携

• AO のアクターはオフチェーンイベントやブリッジと連動可能なので、Ethereum などと連動するデータ中継アクターを通じて、ArFleet への保存がトリガーされるといった構成も実現できます（設計次第で高度な統合が可能）。

AO アクターとの直接統合

• ArFleet 自体が AO のアクターとして動作しているため、他の AO プロセスから直接メッセージ送信で呼び出し可能です。

• 例：

  • オンチェーンゲームの試合中データ（ログやスコア）を ArFleet へ保存
  • DAO の意思決定履歴を一時保存し、完了後に Arweave へ移行
  • エージェントが生成した AI プロンプトや一時ファイルをその場で ArFleet にアップロード

• AO ではアクターが将来の呼び出しもスケジュールできるため、「期限付き保存＋期限後に自動処理」といった自律的なストレージ管理も可能です。

取り扱い可能なデータ形式と暗号化

• ArFleet では、形式を問わず保存可能です（画像、バイナリ、テキスト、JSON 等）。
• デフォルトでは、データは 8KB 単位で分割・RSA ベースで暗号化された上で保存されます。
• Merkle ツリー構造により、部分的な検証やランダムチャレンジが可能です。
• オプションで、クライアント側によるAES-256 でのファイル全体の暗号化も推奨されています。
• 暗号化されたデータは、復号キー（AES キー）を知る者のみが読み取ることができます。これは Arweave 同様、**「誰でも取得可能・でも復号できない」**という情報公開の仕組みと一致します。

承知しました。以下は第 5 節「5. インセンティブと支払いロジック」の日本語訳です。

5. インセンティブと支払いロジック

ArFleet の経済設計は、Arweave と AO のトークンエコノミーを活かしつつ、一時的ストレージに特化した収益モデルを実現しています。

クライアントによる支払い（報酬）

• データを保存したいクライアント（dApp、ユーザー）は、保存期間とサイズに応じた報酬を支払います。

• 初期実装では、支払い通貨として**$AR（Arweave のネイティブトークン）が使用されており、今後は$AO**にも対応が拡大します。

• たとえば：

  • Arweave 本体で 1GB の永続保存に 0.75 AR かかると仮定した場合
  • ArFleet で 1GB を 1 ヶ月保存する場合は、その数分の一以下の価格で済む可能性があります（プロバイダーの提示価格による）

• 支払われた報酬は、Deal アクターによってエスクロー保管され、契約完了後にプロバイダーへ支払われます。

プロバイダーによる担保（スラッシング対象）

• プロバイダーは、報酬を受け取る代わりに、**担保（collateral）**を Deal アクターにロックする必要があります。

• 担保額は報酬額に比例し、一般的に報酬と同額以上が要求されます（たとえば 1GB の保存で 0.1 AR の報酬を得るには、0.1 ～ 0.2 AR を担保として預ける必要がある）

• プロバイダーが以下のような違反をした場合、担保は**一部または全額スラッシュ（没収）**されます：

  • チャレンジに失敗
  • 保存期限前にデータを削除
  • オフライン状態の継続

チャレンジと報酬支払いの仕組み

• Deal アクターは定期的に**チャレンジ（検証）**を行います。
• チャレンジに成功し続けると、保存期間終了時に担保が返却され、報酬が支払われます。
• チャレンジに失敗した場合、担保はスラッシュされ、報酬は焼却またはクライアントに返金される可能性があります（詳細仕様は今後変更の可能性あり）。

支払いトークンとマルチトークン対応

• ArFleet は、AO プラットフォーム上で動作しているため、あらゆる AO トークンに対応可能です。
• 初期段階では、$AR とそのラップド版（wAR）、そして$AO が主に使用されています。
• 今後は、プロバイダーとクライアントが合意すれば、USDC やプロジェクト独自トークンなどの使用も技術的には可能です（ただし要サポート追加）。

支払いモデルの選択肢

開発者は、ユーザーに直接支払わせるか、自身がコストを負担するかを選べます：

• ユーザー課金モデル：dApp 内でユーザーに小額支払いを求め、ファイル保存ごとに処理
• 開発者負担モデル：UX 向上のため、開発者自身が報酬を支払う（ガスレスと同様）
• ハイブリッド型：一定量までは無料提供、それ以上はユーザー課金

どのモデルでも、ArFleet クライアントは支払い処理を自動化しており、ユーザーまたは dApp 側が適切なウォレットに資金を保持していれば、保存操作は簡単に実行できます。

トークンエコノミーと将来的な展望

• 現時点（2025 年 7 月）で、ArFleet 独自のトークンは存在しません。
• 報酬や担保はすべて$AR または$AO で処理されており、新たなガバナンストークンやユーティリティトークンは発行されていません。
• このシンプルさにより、トークン設計の複雑さや投機的リスクを排除し、**純粋な「ストレージとしてのサービス提供」**が行われています。
• 将来的に DAO やガバナンス機能が追加される可能性はありますが、現段階では**[未定]（TBD）**です。

6. ロードマップと既知の制約

ロードマップ（短期～中期）

ArFleet は 2024〜2025 年を通じて急速に進化中のプロジェクトであり、以下のような段階的なリリースが予定・実行されています。

短期（2025 年後半）

• ArFleet Web アプリの一般公開
  v0.1.x 系は Genesis Pass 保有者限定でしたが、今後はすべての Arweave ウォレットユーザーが使えるバージョンに更新予定。
• $AO による支払い正式対応
  AO メインネットが 2025 年 2 月にローンチされ、$AO が移転可能になったことで、報酬・担保通貨としての実装が拡大中。
• プロバイダーネットワークの拡大
  初期は開発チーム・コミュニティ限定でしたが、今後は一般ユーザーによるストレージ提供も可能に。
• パフォーマンス改善
  v0.1.2 では暗号化処理の高速化、アップロード中断時の再試行などが追加され、今後も継続的に改善予定。
• 利便性向上機能の追加
  自動リニューアル、プロバイダー切り替え、ストレージ状況のモニタリング、GUI の洗練など。

中期（6〜12 ヶ月以内）

• 最大保存期間の拡張
  現在は数日〜数週間を想定しているが、ニーズに応じて 6 ヶ月や 1 年の保存も将来的には可能に。
• 分散インデックス/ディスカバリ機構の実装
  「どのプロバイダーがどのデータを持っているか？」という情報の分散型探索機能の強化。
• AR.IO ゲートウェイとの統合
  Arweave の既存ゲートウェイ（arweave.net など）を通じて、ArFleet のデータにアクセスできる仕組みの検討。
• セキュリティ監査とプロトコルの安定化
  スラッシング条件、RSA ＋ Merkle 設計の妥当性などに関する外部監査の実施と脆弱性修正。
• DAO/コミュニティによるガバナンス体制の整備（[未定]）

既知の制約

ArFleet は革新的である一方、まだ発展途上のプロジェクトであり、以下のような現時点での技術的・運用的制約があります。

テストネット/アルファ制限

• 現在までの利用は Genesis Pass 保有者に限定されていたため、実利用のテレメトリが限定的です。
• メインネット統合後も段階的に開放が進む予定です。

AO への依存

• ArFleet は AO のアクター上で動作するため、AO ネットワークの成熟度に影響を受けます。
• テストネットでは 130,000 以上の並列プロセスや数千万メッセージの処理が成功していますが、本番環境での耐障害性やスケーリングは継続的に評価が必要です。

保存期間・サイズ制限

• 初期のプロバイダーは短期間（数日〜数週間）の保存に限定する傾向があります。
• ファイルサイズにも制限あり（Web 版は数百 MB 以下、CLI では複数 GB まで可能だが上限はプロバイダー次第）。
• Merkle ツリーの巨大化などにより、**極端に大きなファイル（10GB 以上）**の保存は現時点では現実的ではありません。

冗長性の限界と自己修復の欠如

• 複数コピー（冗長化）による保存は可能ですが、途中でプロバイダーが離脱した場合、自動で再配置される仕組みは現時点で未実装です。
• 将来的には Deal アクターによる再レプリケーション機能の追加が期待されますが、現状はユーザー/クライアント側で対処する必要があります。

アクセス制御の未整備

• 現在の ArFleet ではファイルは基本的に誰でも取得可能です（復号できるかは別）。
• プライバシー保護にはクライアント側の AES 暗号化が必須です。
• 今後、Proxy Re-encryption や ZK 証明などによるアクセス制御機構が追加される可能性はありますが、現段階では未対応。

ツールと UX の粗さ

• CLI のエラーメッセージが不親切、ドキュメント未整備の箇所あり。
• テストネットでのウォレット接続や NFT の準備が煩雑。
• 一般開発者向けには、今後の改善とガイド整備が不可欠です。

トークンラッピングや資金管理の複雑さ

• AO 上では AR をそのまま使えず、wAR へのラッピングが必要な場合があります。
• 開発者やユーザーが混乱しないよう、ツール側でのラッピング支援や UX 改善が進められています。

プロセス数やプロバイダー同時処理の限界

• 現在のテストネットでは大規模なバッチ保存や並列プロセスに対して、プロバイダーが受け付けられる処理数に制限がある可能性があります。
• 一括アップロード時にはプロバイダーのキャパシティに注意し、フォールバックや再試行ロジックの実装が推奨されます。

---

---

【Arweave Japan とは】
Arweave Japan は Arweave / AO の日本語ビルダーエコシステム構築を目的とした分散型組織です。

【​Arweave / AO とは？】
​Arweave は無制限にスケール可能な分散型ストレージであり、AO は Arweave 上に構築された無制限にスケール可能な分散型スーパーコンピュータです。Arweave と AO を使って既存のブロックチェーンでは実現不可能であった実用的なプロダクトが開発できます。

イーサリアム L1 のリステーキングによってセキュリティが担保され、TVL はローンチ数ヶ月で 1000 億円近くまで上がり、今後数兆円規模の市場が期待されます。完全フェアローンチされた AO のトークン設計によって、この流動性は AO 上のプロジェクトが活用することができ、ビットコインと同じ半減スケジュールでミントされる AO トークンは開発者やプロジェクトが受け取れる仕組みとなっています。

​Web2 を置き換えるレベルで実用的なプロジェクトが構築できる唯一無二の分散型プロトコル AO で開発することはグローバルの第一線で活躍する非常に大きなチャンスとなっています。

【Social Links】

• Website
• X(Twitter)
• Discord Community
• Github

【Blog】

• Zenn Publication
• Note Magazine
• dev[.]to