6.5 KiB
1.4. WIPの概念と適用範囲
WorldspaceとObject
WIPは、任意のデジタル環境を、ObjectのTreeであるWorldspaceとして公開する。Tree上に配置され、Pathで到達できるObjectをエントリと呼ぶ。Objectとエントリは、別のスキーマではない。
各Objectは、短いdescription、Interfaceへの参照、必要に応じてrefを公開できる。Tree上では子Objectを持つこともできる。本文やmetadataなどのドメインデータは常時公開するのではなく、Operationを通して取得・操作することを基本とする。
Pathは、現在のWorldspace上の配置位置を表す。同一Objectが複数のエントリとして現れてもよいため、PathをObjectのidentityとはみなさない。Hostは、同じ主体に公開した一つのWorldspace内での同一性を、optionalなrefによって示せる。
Treeの親子関係は所有・内包を表す。所有関係にない意味的な関連には、その関連を表す名前付きOperationを使い、関連エントリのpathを返す。これらの関連を、Treeの親子関係へ無理に押し込まない。
InterfaceとOperation
ObjectはOperation定義を直接埋め込まず、0個以上のInterfaceを参照する。実装コード上のInterface Declarationから、機械可読なInterface Descriptorを生成する。各Interfaceに宣言された関数の集合が、再利用可能なcapability unitになる。
複数のObjectが同じInterfaceを共有でき、一つのObjectも複数のInterfaceを組み合わせて公開できる。Operation callでは、対象Objectが現在公開している集合から一つのInterfaceを明示して実行する。
Operationには、名前や型に加え、用途を判断するための短い説明を任意で添えられる。長文documentationや大量のドメインデータをInterfaceへ埋め込むことは想定しない。Objectも、受動的なJSON recordとしては扱わない。本文の取得、検索、状態変更はいずれもOperationとして表す。
ClientとHost
Hostは、主体に応じたWorldspaceを公開し、Operationを実行する。Clientは、Hostから得たObjectとInterfaceを、View、Tool、APIなどとして利用者へ提示する。同じモデルを使っても、どの情報をどの順序で表示するか、どの取得を先行して行うかは、用途に応じて選べる。
Protocolの基本的なinteractionは、Objectを観測するobserve、Interface Descriptorを取得するfetch_interface、Operationを実行するcall_operationである。これらの具体的なrequest / responseは3. Protocol、上位の提示やcacheの責務は4. クライアントに従う。
AI向けのtree / inspect / invokeは、Clientが提供する上位インターフェースであり、Protocol interactionをそのままTool名にしたものではない。他のClientが同じ呼び出し構文を使う必要はない。
発見と既知世界
Clientは、発見して取得したエントリをKnown Spaceとして保持できる。既知のエントリをClient側で辿り、Operation結果から得たエントリを追加すれば、さらに探索を進められる。
ただし、保持したエントリすべてを、機械的な広域探索の対象にするわけではない。Hostがindexableとして公開した親子関係を観測して得た範囲を、Discoverable Spaceとして扱う。Operationから発見したpathだけを根拠に、Treeの親子関係を追加しない。
この分離によって、大量の検索結果や動的Objectが自動的に探索indexへ流入するのを防ぐ。HostはWorldspace全体を事前にmaterializeせず、必要な範囲を動的に公開できる。
Operation Resultと再観測
RAG検索のResult群や、Agentへの問い合わせで得られたConversationは、Operation Resultから発見できる。Resultは型付きの値であり、Interface Descriptorのentry型として、未観測だったエントリのpathを返せる。
一方、OperationがHost背後の環境を変更しても、その状態遷移や変更差分がClientへ同期されるわけではない。変更後の状態が必要なら、Clientは返されたpathを取得するなどして改めて観測する。
観測したことと、現在の操作が許可されることも別である。Operationのauthorizationと実行条件は、Hostが実行時に評価する。
Narrow Waist
Filesystem、GitHub、RAG、DBを同じWorldspaceへ投影しても、それらの内部APIまで一つにする必要はない。WIPは、発見・観測・Operation実行という小さなInteraction Modelを共通化する。
Host内部のAPI、DB、RPC、永続化方式は規定しない。TransportもProtocolのlogical data modelから分離する。人間向けの画面、AI向けのTools、プログラム向けのAPIと、Host内部の実装の間に、共通の対象・操作モデルを置く。
状態管理の非目標
Known SpaceとDiscoverable Spaceは、過去の観測から構成されたcacheである。Host上の現在状態を同期したreplicaではなく、HostにClientのcache状態を追跡・更新することも要求しない。
WIPは、Host上の任意状態をClientへ同期するdata store protocolではない。Object propertyのreplication、change feed、reactive subscription、分散transaction、domain event deliveryは、Core Modelの規定対象外とする。
Post-trainingとの仮説
共通の操作モデルをAIへ提示することには、学習上の仮説もある。Tool Useが事後学習の対象になるなら、個別Tool名の使い方に代えて、Worldspace上でのinteraction policyを学習できる可能性がある。
- 既知の世界を探索する。
- 対象の意味とOperationを理解する。
- 必要ならOperationから未知のエントリを発見する。
- Operationを実行する。
- 必要ならOperation Resultやentry pathをもとに対象を再観測する。
この探索の仕方を学習できれば、未知のToolを使うだけでなく、未知のDigital Environmentを探索できるモデルを作れるのではないか。ただし、これは学習に関する仮説であり、WIPを採用しただけで得られる能力の保証ではない。人間・AI・システムに共通の操作モデルを提供するという目的は、この仮説の成立を前提にしない。