制約という洞察
すべての重要なソフトウェアアーキテクチャは、その核心において制約システムです。コンテナはプロセスを制約します。サンドボックスはコードを制約します。権限モデルはユーザーを制約します。これらのシステムの価値は、許可するものにあるのではなく — 阻止するものにあります。
Blocklet アーキテクチャを設計したとき、私たちはこの洞察から出発しました。解決すべき問題は:信頼できないアクターが共有インフラ上でソフトウェアコンポーネントを構築・デプロイしながら、環境を壊さないようにするにはどうすればよいか?
2018年において、その信頼できないアクターは人間のエンジニアでした。
2026年において、その信頼できないアクターは AI エージェントです。
アクターは変わりました。アーキテクチャはゼロから作り直す必要はありません — 進化する必要があるのです。
Blocklet が正しく行ったこと
Blocklet は Blocklet Server 内で動作する自己完結型のソフトウェアコンポーネントです。最初から、アーキテクチャは以下を強制しました:
- 分離 — 各 Blocklet は独自の名前空間で、定義されたリソース境界の中で動作
- 宣言的なケイパビリティ — Blocklet は必要なもの(ネットワークアクセス、ストレージ、アイデンティティサービス)を明示的に宣言し、プラットフォームがそれを許可または拒否
- ライフサイクル管理 — インストール、起動、停止、更新、ロールバックはアドホックなスクリプトではなくプラットフォーム管理のオペレーション
- アイデンティティ統合 — すべての Blocklet が分散型アイデンティティを持ち、すべてのユーザーインタラクションが DID で認証
これらは偶然の設計選択ではありません。組織が自身のインフラ上でサードパーティのソフトウェアコンポーネントを安全に実行できるようにするための意図的な制約です。
キーワードは安全です。便利ではなく。速くではなく。安全です。自分のサーバーで他人のコードを実行するとき、安全が第一の要件だからです。
スキャフォールドパターン
Blocklet Server は、現在スキャフォールドパターンと呼んでいるものの最初の実装です:内部で動作するコンポーネントに構造、制約、サービスを提供するプラットフォームです。
スキャフォールドはコンポーネントに何をすべきかは教えません。何をしてはいけないかを教え、それ以外のすべてを完了するために必要なサービスを提供します。コンポーネントは境界内で自由ですが、境界は交渉の余地がありません。
このパターンは AI エージェントについての私たちの考え方に直接マッピングされます:
| 人間の時代 (Blocklet) | AI の時代 (Chamber) |
|---|---|
| エンジニアがコードを書く | AI エージェントがコードを生成・実行 |
| コードは分離された Blocklet 内で動作 | エージェントは分離された Chamber 内で動作 |
| プラットフォームがリソース制限を強制 | プラットフォームがリソース制限を強制 |
| DID が開発者を認証 | DID がエージェントを認証 |
| プラットフォームがライフサイクルを管理 | プラットフォームがライフサイクルを管理 |
構造は同じです。アクターが変わったのです。
Chamber の登場
Chamber は AI のためにアップグレードされた Blocklet です。Blocklet アーキテクチャのすべての制約とケイパビリティを継承し、AI エージェントが特に必要とするものを追加します:
モデルアクセス制御 — Chamber はアクセスが必要な AI モデルを宣言し、プラットフォームがそのアクセスを仲介します。エージェントは任意の外部サービスに直接アクセスできません。プラットフォームを通じて動作します。
プロンプトとツールの境界 — Chamber はエージェントが使用できるツールとプロンプトを定義します。これは Blocklet のケイパビリティ宣言の AI 版です。ファイルの読み取りは許可されているが書き込みは許可されていないエージェントは、自身の権限を昇格できません。
オブザベーションと監査 — Chamber 内で AI エージェントが行うすべてのアクションが、完全なアイデンティティコンテキストとともに記録されます。何が起きたかだけでなく、誰がそれを認可し、どのモデルが決定を生成し、どのコンテキストが提供されたかまで記録されます。
リソース計量 — AI ワークロードは従来のソフトウェアとは異なるリソース特性を持ちます。トークン消費、モデル API コール、計算時間が Chamber レベルで追跡・制約されます。
AIGNE フレームワークは Chamber の上に構築されています。AIGNE エージェントをデプロイすると、Blocklet Server 上の Chamber 内で動作します。フレームワークがエージェントロジックを処理し、Chamber が制約の実行を処理します。
AINE は Blocklet の完成形である
AI ネイティブエンジニアリング(AINE)が ArcBlock の Blocklet の伝統からの離脱を表すという意見があります。これは正しくありません。
AINE は Blocklet を否定するものではありません。AINE は Blocklet の完成形です。
Blocklet アーキテクチャは常に一つのことに関するものでした:完全には信頼できないアクターのコンポーネントを安全に実行すること。2018年に、信頼できないアクターが AI モデルになるとは予測できませんでした。しかし私たちが確立したアーキテクチャ原則 — 分離、宣言的ケイパビリティ、アイデンティティベースのアクセス、プラットフォーム管理のライフサイクル — はまさに AI エージェントに必要なものです。
私たちは AI のために Blocklet を設計したのではありません。信頼できないアクターを制約するという普遍的な問題のために Blocklet を設計しました。AI エージェントは、今日におけるこの問題の最も重要なインスタンスに過ぎません。
前進する道
Blocklet から Chamber への進化はマイグレーションではありません。既存の Blocklet は今日と全く同じように動作し続けます。Chamber は拡張です — スキャフォールド内のコンポーネントが従来のアプリケーションではなく AI エージェントである場合にアクティベートされる新しいモードです。
この後方互換性は意図的なものです。すでに Blocklet Server に Blocklet をデプロイしている組織は、何も再構築する必要がありません。既存のアプリケーションの隣に AI エージェントをデプロイする能力を、同じインフラ、同じアイデンティティシステム、同じ運用モデルで得られます。
エージェンティックファイルシステムは、人間の時代の Blocklet と AI の時代の Chamber をつなぐ共有抽象レイヤーを提供します。両方が AFS を通じて読み書きします。両方が DID で識別されます。両方が Blocklet Server によって管理されます。
プラットフォームは進化しました。原則は揺るぎません。
おすすめの記事
- AIGNE フレームワーク:AI ネイティブソフトウェアの構築 — Chamber アーキテクチャの上に AI エージェントを構築するオープンソースフレームワーク。
- AFS:AI 時代のシステム抽象を再考する — Blocklet と Chamber をつなぐファイルシステム抽象。
- なぜ AI エージェントに分散型IDが必要なのか — DID が人間と AI のアクター双方に信頼レイヤーを提供する仕組み。