Blocklet Server から ARC へ：なぜ『所有する』ことは『生成する』ことより難しいのか

AI によって、ソフトウェアを作ることの意味は大きく変わった。かつて、自分のブログや店、あるいは自分の暮らしだけのための小さなツールを欲しいと思った人が、まず考えたのは機能ではなかった。開発者を頼むべきか、サーバーをどう用意するか、その後は誰が保守するのか。いまでは、ますます多くの要望を Agent に直接伝えられる。ここでいう Agent とは、要望を理解し、ソフトウェアの生成、実行、保守を支援できる AI アシスタントのことだ。ソフトウェアは、急に遠い存在ではなくなったように見える。

しかし、ソフトウェアを生成できることと、それが自分のものになることは別だ。

アプリケーションをデモ環境で動かすことは、人を興奮させやすい。だが、それが自分のデータ、人間関係、履歴、日々の仕事を抱え始めたとき、問題はようやく始まる。データはどこに置かれるのか。誰がアクセスできるのか。端末を替えたらどうなるのか。サービスが壊れたあとに復旧できるのか。友人と共有するとき、それは単にリンクを渡すことなのか、それともまた別のプラットフォームに自分を縛り付け直すことなのか。これまで本当に厄介だった部分は、「デプロイ」「運用」「アカウントシステム」といった言葉の後ろに隠されてきた。率直に言えば、それはソフトウェアを長期的にアクセスできる場所に置き、使い続けられるようにし、誰がログインして使えるかを管理することだ。

だからこそ、私たちは ARC を構築している。ARC は Agentic Realm Computer の略称だ。Agent に従来型のコンピュータをもう一台与え、Linux の管理、パッチ適用、ログの確認をユーザーの代わりにさせるだけのものではない。私たちが作りたいのは別種の計算基盤である。ユーザーは Agent の助けを借りて必要なソフトウェアを手にできる一方、アイデンティティ、データ、長期的なコントロールまでを単一のプラットフォームに明け渡す必要はない。

ソフトウェアを生成できることと、それが自分のものになることは別だ

ArcBlock は、Blockchain、分散型アイデンティティ、アプリケーション基盤に取り組んできた会社だ。私たちは長く、分散型アプリケーションの開発とデプロイが難しすぎる、という現実的な問題に取り組んできた。Blocklet Server と初期の Blocklet の仕事は、アプリケーションを一台のマシンにデプロイすることだけではなかった。アイデンティティ、ユーザー管理、ドメイン、アプリケーションのデプロイといった共通部分をあらかじめ整え、開発者が自分の事業に集中できるようにすることだった。

DID の仕組み、複数の Blockchain への接続と利用、支払いのサポート、そして PageKit や DiscussKit のようなコンポーネントは、そのプラットフォームの重要な部分だった。これらにより、ユーザーや開発者は、Web の画面でアイデンティティを扱い、サイト、ディスカッション、支払いに関する機能をインストールし組み合わせられた。毎回、ゼロから一式のサービスを組み立てる必要はなかった。

これらの能力には ARC の中でも対応する基盤がある。ただし、同じ完成度でも、同じモデルでも現れるわけではない。アイデンティティ、既存の台帳、支払いレイヤーの能力は引き継げる。チェーン側の AFS 接続、オンチェーン決済、そしてそれらを ARC で統一的に担う方法は、なお構築中である。旧来の能力をいったん白紙にし、純粋に未来だけの概念で置き換える、と語るべきではない。これらは今も、ARC が役に立つための土台である。

当時の判断が誤っていたわけではない。以前の私たちは、自分たちを明確に開発者プラットフォームだと捉えていた。十分な数の開発者が十分な数のアプリケーションやコンポーネントを作れば、一般のユーザーもそれらをインストールし、組み合わせ、使えるようになる。Blocklet Store と一連の Kit は、その考え方から生まれた。今日でも、こうしたツールを必要とする開発者は多い。

しかし後に、私たちは一つの現実を認めざるを得なかった。コンポーネントがあったとしても、インストール、設定、保守という作業は、ほとんどの一般ユーザーをなお入口の外に置いてしまう。ソフトウェアパッケージは、それだけで誰かが長く所有できるアプリケーションになるわけではない。SaaS が広く使われる理由もそこにある。こうした面倒をできるだけユーザーの目から隠してくれるからだ。

変化は、AI が「誰がソフトウェアを作れるのか」という境界を大きく外へ押し広げたことにある。専門の開発者にならなくても、「自分のサイトが欲しい」「この資料を集めて整理したい」「家族だけのための小さなアプリを作りたい」と言える。けれども、Agent がアプリケーションを書いてくれたとしても、データ、デプロイ、その後の運用がなお専門家にしか分からない塊のままなら、得られるのは美しいデモに近く、自分のソフトウェアではない。

「ホスティング型のオンラインサービス、つまり SaaS をそのまま使えばよい」と言う人もいるだろう。それはもっともな考えだ。プラットフォームがアプリケーションを実行し保守すれば、すぐに使えること、運用を共有できること、多くの人にとっての日常的な便利さが得られる。そして今後も、多くの場面で適している。ARC は、全員を再びシステム管理者にするためのものではないし、すべてのサービスを自宅に戻すよう求めるものでもない。スマートフォンを買うとき、誰もそれが「セルフホスト」かを先に問わない。ただ、自分のものだと感じる。私たちが変えたいのは別のことだ。あるアプリケーションが本当に生活の一部になったとき、それを所有することが技術的な敷居のせいで不可能になってはならない。

ARC は Agent に従来のコンピュータをもう一台与えたいわけではない

従来のサーバー、仮想マシン、隔離された実行環境でも、Agent に仕事をさせることはできる。だが、それらには従来型コンピュータの荷物が付いてくる。バージョン更新、アクセス権、障害対応、そして互いに独立した大量の管理画面だ。Agent に操作させれば、一般ユーザーが自ら扱うより多少はよい。しかし複雑さは別の誰かが背負うだけで、消えてはいない。

ARC は AFS から始まる。AFS は Agentic File System の略称だ。従来のファイルシステムを名前だけ変えたものではない。「ファイルシステム」を統一的な抽象として用い、人と Agent のどちらにも、データ、利用可能なサービス、現在のコンテキストを理解し操作できるようにする。共同の作業台だと考えるとよい。ユーザーが明示的に許可し、関連するデータやサービスがすでに接続されているときにだけ、アプリケーションは資料を見つけ、権限を理解し、許可されたサービスを使える。一般ユーザーがこの抽象を目にする必要はない。しかしそれは、異なる環境にあるものを、一つの理解しやすい場に載せられるかどうかを決める。

AFS の上には AOS、Agentic Operating System がある。両者がともに ARC のランタイム、すなわちアプリケーションを実際に動かす基盤環境を構成する。ARC はすでに、ローカルおよびクラウドの実行環境で、Blocklet の実行とデータ接続を検証している。今後もさらに多くの環境へ広げていく。異なる環境は ARC の土台となる場所にすぎず、ユーザーが自ら管理すべき何台ものマシンではない。ここで本当に重要なのは、いくつのプラットフォームを支えるかではない。Agent が向き合うシステムが、互いに見知らぬ箱の寄せ集めではなくなることだ。

要するに、私たちは「ユーザーがソフトウェアを所有できるよう支える」ことを、「ユーザーの代わりに一台のサーバーを上手に管理すること」だとは捉えていない。ユーザーが本当に気にするのは、自分のものが残っているか、使い続けられるか、問題が起きても回復できるかだ。マシンそのものは、ユーザーが自ら世話をしなければならない対象ではなく、ますます交換可能な道具になっていくべきだ。

大切なものは、一度きりの実行に縛られるべきではない

ここは、ARC と ArcBlock がこれまで積み重ねてきたものがつながる場所でもある。

アイデンティティの層にあるのが DID、Decentralized Identifier だ。これは、継続して使え、検証できるアイデンティティ識別子だと捉えればよい。ArcBlock は長く、アイデンティティをあるプラットフォームが一時的に発行するアカウントではなく、システムの基盤だと考えてきた。人、デバイスなど、識別される必要のある存在は、それぞれ自分の DID を持てる。ARC はこの基盤を引き継いでいる。既存のユーザーがアーキテクチャの更新を理由にアイデンティティを作り直さなくて済むことが、私たちの目標だ。この連続性は重要である。システムを替えるたびに「自分が誰か」からやり直さなければならないなら、そのアップグレードは疑わしい。

データの層にあるのが DID Spaces だ。これは、ユーザーが自ら保守しなければならないクラウドストレージではなく、個人データが本来持つべき居場所である。私たちの設計目標は、ARC のランタイムを再構築でき、アプリケーションを入れ替えられるようにしながら、本当に長期的に重要なデータ、履歴、認可関係には独立した継続性を持たせることだ。アプリケーションや端末を替えても、ノート、認可、履歴までが一度のインストールとともに消えるべきではない。これは、データが今後決して失われないことや、ユーザーがバックアップをまったく不要にできることを意味しない。永続データと一回の具体的な実行を分け、同期、バックアップ、復旧の対象を明確にするべきだ、という意味である。

Blockchain も放棄されたわけではない。ただ、もはやスローガンとして掲げるものではない。検証可能な記録、資産に関わる場面、そして将来の支払い能力にとって、ARC アーキテクチャの重要な連続性であり続ける。ユーザーにとって重要なのは、まず「Blockchain」という言葉を聞くことではない。検証が必要な場面で、単一プラットフォームのログへの依存を減らすことが私たちの目標だ。具体的にどの行為が検証可能かは、すでに接続されているアイデンティティと台帳の能力によって決まる。チェーン側の AFS 接続とオンチェーン決済はまだ構築中であり、方向が明確だからといって、すでに提供済みであるかのように語ることはできない。

これらの層がそろって初めて、私たちのいう「所有」が成立する。ユーザーが所有するのは、ある一台のマシンや一回のデプロイではない。アイデンティティ、データ、認可関係、そして実行に問題が起きた後にも復旧・移行できる可能性である。これは「データはあなたのもの」という広告文句ではなく、アーキテクチャ上の役割分担だ。ランタイムの交換可能性は、このアーキテクチャが実現しようとする目標である。アイデンティティは継続し、データには帰属先があり、重要な行為には検証可能な記録が必要だ。各要素が異なる製品でどう実装されるかは、実際の製品によって少しずつ証明される必要がある。

Blocklet の変化は、実際の製品で試されなければならない

Blocklet は ArcBlock が早くから生み出した名称だ。旧来の Blocklet は、完全な実行環境を抱えたままインストールするソフトウェアパッケージに近かった。その価値は一貫して明確である。アプリケーションを、インストール、再利用、組み合わせができる部品にすることだ。

ARC では、この考え方は失われていない。ただし、実装モデルは変化している。ARC 時代の Blocklet は、宣言的なアプリケーション定義へ向かっている。アプリケーションは必要な能力を宣言し、ARC が共通の実行、アイデンティティ、データ、インタラクションの基盤を提供する。かつて Blocklet Server や各 Kit にまとめられていた DID、チェーン、支払い、サイト、ディスカッションの能力も、ARC では引き継ぐ必要がある。ただし、必ずしも以前と同じインストールモデルでは現れない。この世代のモデルはしばしば「Blocklet 2.0」と呼ばれるが、最終的な外部向けの名称は製品に合わせて決まる。

これは意図的なトレードオフであり、現実的な代償もある。旧モデルでは、複雑なアプリケーションは自らの完全な実行環境を持ち込めた。この新しいモデルの方向性では、アプリケーションの記述は任意の実行可能プログラムを含めず、一般的な能力は ARC が統一して提供する。まれな特別要件には、それに対応する Provider を別途実装し、明示的にマウントする必要がある。技術読者は、この境界を AFS Provider として理解できる。言い換えれば、私たちは「何でも一つのソフトウェアパッケージに詰め込める」自由の一部を手放し、より明確なセキュリティ境界と、個々のアプリケーションが背負う実行上の負担の軽減を得ようとしている。

インターフェースも同じ発想に立つ。AUP、Agentic UI Protocol は、画面の意味と重要な操作を、特定のフロントエンド実装の内部だけに隠さず、記述できるようにする。これは「Agent がすでに任意の UI を操作できる」という約束ではない。人、アプリケーション、Agent の間に、より明確な共通言語を築くためのものだ。

技術読者は、これを抽象境界の引き直しと見てもよい。一般ユーザーがこれらの用語を覚える必要はない。私たちが最終的にユーザーに感じてほしいのは、データ、認可、アプリケーション能力に移行の条件が備わっているなら、端末や実行環境を替えても、アプリケーションが突然まったく別の見知らぬものにならない、ということだ。

もしユーザーが一つのアプリケーションを使う前に ARC の講義を受けなければならないなら、私たちはおそらく順序を取り違えている。

このアーキテクチャは、最終的には実際のアプリケーションで検証されなければならない。しかし、それを成立させるために、事前にいくつもの製品名を発表する必要はない。ユーザーが気にするのは、自分のサイトを作れるか、ディスカッションを運営できるか、アイデンティティを管理できるか、支払いを扱えるか、安全に自分の資料を保存できるかだ。ARC は、アイデンティティ、データ、実行、Agent の協働という複雑さを裏側で引き受けるべきであり、すべてのユーザーが理解しなければならないブランド上の負担になってはならない。

旧プラットフォームですでにこうした具体的な能力を扱ってきたからこそ、ARC は一枚のきれいなアーキテクチャ図でそれらを置き換えてはならない。新しいモデルは、これらのことを Agent とユーザーの協働により適した形で起こせるようにするべきであり、ユーザーに再びインストール、設定、運用を突き付けるものではない。

だから私たちは、より複雑なアーキテクチャ図を一枚描くだけでは足りないと考える。以前、私たちは開発者向けのアーキテクチャ図でこうしたコンポーネントを説明してきた。それらには今も価値がある。しかし将来の ArcBlock は、一般ユーザーをコンポーネント名の前で足止めすべきではない。ARC は新たな主軸であり、Blocklet、DID、Blockchain は失われていない土台だ。本当の試験は図の中にはない。ユーザーが必要なソフトウェアを自然に所有できるかどうかにある。

この仕事はまだ終わっていない。ARC も、一篇の記事を書いたからといって自動的に成立するわけではない。これから私たちは、製品、コンテンツ、そして公開された構築の過程を通じて、このアーキテクチャを一層ずつ証明していく必要がある。ただし、まず方向を明確にしたい。AI がソフトウェアをより容易に生み出せるようにした次に来るべきなのは、より多くのソフトウェアを生成することだけではない。より多くの人がそれを本当に所有できるようにすることだ。

付録：本文に出てくる用語の早見表

これは ArcBlock の完全な用語集ではなく、この記事のための読書地図にすぎない。正式な戦略と製品の境界は今後も進化する。そのため、表中の「構築中」は曖昧にするための表現ではなく、すでに使える基盤と、なお検証を要する部分を意図的に区別するためのものだ。