抽象の問題

あらゆるコンピューティング時代は、最終的に一つのコア抽象を確立します。メインフレームにはジョブがありました。Unix にはファイルがありました。Web には URL がありました。モバイルにはアプリがありました。それぞれの抽象が、人間と機械がシステムとどのようにやり取りするかを定義し、その時代の支配的なアクターによって形作られました。

今、支配的なアクターが変わりつつあります。AI エージェントがコンピューティングシステムにおけるファーストクラスの参加者になりつつあります — 読み、書き、推論し、行動します。しかし、私たちは別の時代のために設計された抽象を通じてそれらを動かしています:REST API、SQL データベース、メッセージキュー。これらのインターフェースは人間のプログラマーが接続するために構築されたもので、AI にとっては不透明です。

エージェンティックファイルシステム(AFS)は私たちの答えです:普遍的な抽象としてのファイルシステムへの回帰、ただし AI と人間の両方がアクターである世界のために再設計されたものです。

なぜファイルなのか

ファイルシステムは、人間と AI の両方がネイティブに理解している唯一の抽象です。

人間はファイルを理解しています。ファイルの作成、整理、読み取り、共有に関する数十年にわたる筋肉の記憶があります。すべてのオペレーティングシステムが初日からこのメタファーを教えています。

AI もファイルを理解しています。大規模言語モデルはファイルで訓練されています — コードファイル、ドキュメント、設定ファイル、データファイル。AI エージェントがシステムの状態を理解する必要があるとき、ファイルを渡すことが最も自然なインターフェースです。

他の抽象にはこの特性がありません。データベースにはクエリ言語が必要です。API にはドキュメントが必要です。メッセージキューにはプロトコルの知識が必要です。しかしファイルは?ファイルは自明です。

すべてはファイル、ビュー、コンテキスト、アイデンティティ

AFS は Unix の「すべてはファイル」という哲学を4つのプリミティブで拡張します:

ファイル — ストレージと意味の基本単位。ディスク上のバイトだけでなく、あらゆるアドレス可能なリソースです:ドキュメント、設定、データセット、モデル、会話履歴。

ビュー — 特定の消費者に向けたファイルの射影。同じ基盤データが異なるアクターに異なるビューを提示できます。データベーステーブルはアプリケーション向けの構造化ビューです。自然言語の要約は人間向けのビューです。JSON スキーマは AI エージェント向けのビューです。ビューは AFS の魂です — 生データを消費可能な意味に変換します。

コンテキスト — ファイルがどのように解釈されるかに影響する環境情報。誰が読んでいるのか?どのタスクを実行しているのか?どの権限を持っているのか?コンテキストはファイルシステム全体に自動的に流れるため、すべてのアクセスがコンテキスト化されます。

アイデンティティ — システム内のすべてのアクターが分散型アイデンティティ(DID)を持ちます。ファイルは誰が作成し、誰が変更し、誰が読んでいるかを知っています。アイデンティティは後付けではありません — ファイルシステム自体に織り込まれています。

ビューは魂である

AFS で最も重要な概念はビューです。従来のファイルシステムはデータを保存し、解釈は消費者に委ねます。AFS はこれを反転させます:システムが各消費者に適切にデータを提示する方法を知っています

人間がプロジェクトステータスファイルを開くと、フォーマットされたダッシュボードが表示されます。AI エージェントが同じファイルを開くと、セマンティックアノテーション付きの構造化データが表示されます。監査人が開くと、アイデンティティ属性付きの完全な変更履歴が表示されます。

同じファイル。異なるビュー。それぞれがそのオーディエンスに最適化されています。

これはレンダリングのトリックではありません。根本的なアーキテクチャの選択です。ビューレイヤーは AI ネイティブエンジニアリングとシステム設計が交差する場所です — システムが自身の状態を可読にすることに能動的に参加します。

パスはプロトコルである

AFS では、ファイルパスは単なるアドレスではなく、プロトコルです。パス構造が意味をエンコードします:

  • /agents/booking-agent/config — エージェントの設定
  • /agents/booking-agent/state/current — エージェントの現在の状態
  • /agents/booking-agent/logs/2026-02-10 — エージェントのアクティビティログ

人間でも AI でも、あらゆるアクターがこの構造を直感的にナビゲートできます。パスは発見可能で、階層的で、自己文書化されています。/agents/booking-agent/state/current に何が含まれているかを理解するために API リファレンスは必要ありません。

これにより、AFS は本質的に検査可能です。何か問題が起きたとき、専用のデバッグツールは必要ありません。ファイルシステムをブラウズするだけです。

AFS-UI:ファイルはインターフェースである

AFS-UI はファイルシステムのメタファーをユーザーインターフェースに拡張します。すべてのアプリケーション状態がファイルであり、すべてのファイルにビューがあるなら、UI はファイルシステムの視覚的な射影に過ぎません。

これは、AFS 上に構築されたアプリケーションには、従来の意味での分離された「フロントエンド」と「バックエンド」がないことを意味します。ファイルシステムが唯一の真実のソースであり、UI はそのビューの一つです — API ビュー、エージェントビュー、監査ビューと並列に存在します。

ArcSphere は AFS-UI のリファレンス実装であり、AFS ベースのシステムを非技術ユーザーにもアクセス可能にするビジュアルレイヤーを提供します。

学術的検証

AFS アーキテクチャは 2026年国際ソフトウェアアーキテクチャ会議(ICSA)での発表が採択されました。査読プロセスにより、いくつかのコア主張が検証されました:

  • ファイルシステム抽象が人間の開発者と AI エージェントの両方の認知オーバーヘッドを削減する
  • ビューベースの射影がデータの重複なしにマルチアクターシステムを実現する
  • アイデンティティ対応のファイル操作が外部ログインフラなしに監査可能性を提供する

私たちはこの学術的検証が重要だと考えています — 資格としてではなく、これらのアイデアが厳密な審査に耐えるという証拠としてです。

AFS で構築する

AFS は単独の製品ではありません。AIGNE(エージェントフレームワーク)、Blocklet Server(デプロイメントプラットフォーム)、ArcSphere(ユーザーインターフェース)をつなぐ抽象レイヤーです。ArcBlock テクノロジースタックのすべてのコンポーネントが AFS をネイティブに使用します。

AI ネイティブアプリケーションを構築するなら、AFS は検査可能で、コンポーザブルで、アイデンティティ対応の基盤を提供します — コンピューティングの歴史で最も成功した抽象であるファイルシステムのシンプルさを犠牲にすることなく。

AFS を探索する

エージェンティックファイルシステムと、それが AI ネイティブアプリケーションをどのように支えるかについて詳しくご覧ください。

ドキュメントを読む | GitHub で見る


おすすめの記事