はじめに

この記事は、現状のWebアーキテクチャの問題点を示し、それを解決せんとするムーブメントをまとめたものです。 私はPortable WebというWebアーキテクチャを作りましたが、本稿はPortable Webを説明するための序章として書きます。 そのため、本ブログの他の整理記事とは多少異なります（独自の解釈があったり、オピニオンが入っていたりします）。

既存のWebアーキテクチャに対する問題意識と目標

イントロ:「ElonMuskが狂ったらどうなる？」

Twitterは数億人が利用するWebサービスですが、そのWebサービスの命運がたった１人によって握られているというのは異常な事態と言えるでしょう。 しかし、社会はTwitterが使いやすいという理由でTwitterを捨てません。 社会はTwitterに依存してしまっているのです。

ElonMuskがTwitterを買収してから、次世代Webの必要性を世間の人々が納得してくれ易くなりました。 次世代Webの必要性が伝わるために実際にWebが崩壊していくことが必要であるというのは、とても皮肉なことで、最近は喜ばしいのか悲しいのかよく分からない気持ちになります。 例えるなら、システムが攻撃された後にセキュリティ対策を施すようなものです。

ここで私は説明の簡易性のためにElonMuskを例に出している　―Twitterを媒介（メディア）としている―　だけであって、Twitterに限らずWeb全体がこのような状況です。 Web全体、つまり現状のWebアーキテクチャに問題があるです。 本稿では、その問題と解決策を考えていきます。

コラム：単一の主体

ここでの単一の主体とは、個人のみならず株式会社やDAO（Decentralized Autonomous Organization）を含みます。 というのは、株式会社やDAOであっても、最終的に投票などによって意思決定はA/Bのどちらか１つに決まるためです。 複数の主体というのは、互いに独立に外部に影響を与える、複数の意思決定者です。 主体の数は、その主体の内部的な意思決定構造には関係なく、外部に影響を与える意思決定者の数です。 例えばタケノコとキノコがあった時に、ある個人がタケノコを選んだことと、ある会社がタケノコを選んだことは場からタケノコが１つ減ったという点では同じです。

Web2の問題点、それは解決できるか

現在のWebアーキテクチャ（Web1~Web2）におけるWebサービスは「単一の主体が提供する、ブラウザを通じてアクセスできるアプリケーション」と定義できます。 さらにアプリケーションは、「何らかの目的を持った機能の集合体」と定義できます。 例えばFacebookは１つのWebサービスであり、単一の提供者はMeta社です。 しかし、新しい技術（Fediverse等）の登場によって、必ずしもこの定義が当てはまらくなってきています。 つまり、Webサービスが進化しているのです。 本稿では、後で新たにWebサービスを定義しますが、それまでは上の定義を利用します。

Web2の問題点は、利用者、延いては社会がWebサービスに依存してしまっていることです。 その原因としてデータロックインがあります。 なぜWebサービスがデータロックインするかというと、利用者の流出を防ぎたいためです。 利用者数が収益に直結することを考えるとそのような戦略になるのが自然だと思います。 例えば、毎日Facebookの投稿をしたり、いいね！を押したり、知り合いと繋がりを持ったとして、それを数年繰り返すと膨大な量のデータになります。 Webサービスを乗り換える際はそれらのコンテンツを移行することに加えて、全ての知り合いが同時に乗り換えてくれなければ、移行先のWebサービスの効用は減ります。 全ての知り合いが一斉に乗り換えるというのは理論上は可能でも現実的に不可能であって、それ故にデータロックインは強さを持つし、利用者はWebサービスに依存してしまうのです。 ただし、もしデータが一部しか移行できないとしても移行先のWebサービスの効用が高いという（とても珍しい）状況では、利用者は依存を振り切って移行するでしょう。

さて、Webサービスへの依存は利用者にとって悪い（ここでの「悪」は、あくまでも私の考える「悪」です）ことでしょうか？ 上述の定義では、悪いことになります。 というのも、単一の主体が提供するものとして定義されているため、Webサービスの利用者はその単一の主体に隷属してしまうためです。 実際、Twitterに生息している感受性の高いネットユーザーはElonMuskに隷属している　―ElonMuskの意思決定次第でアカウントがBANされる可能性もある（実際に起きている）し、目に触れるツイートも違ってくる（つまり考えに影響を及ぼす）―　と感じるのではないのでしょうか。 もし単一のWebサービスが複数の主体から提供されている場合、利用者には提供者を選択する自由があり、それによって提供者に対する隷属から逃れられるかもしれません（私は逃れられると考えています）。 したがって、Webサービスに依存することが悪いというより、むしろWebサービスを提供する主体に依存することが悪いのです。

この悪（=提供者への隷属）を解決するための動向としては、「体制による反体制的な活動」と「無名の人々による反体制的な活動」に大別できます。 前者は、例えばEUのデジタル市場法（後述します）があります。 法律は自律した国民が選出した代理者が強制力のある法律を制定することによって、強制的に社会を変革するという発想です。 後者はというと、例えばFediverse（後述します）などの新たなアーキテクチャです。 アーキテクチャは、技術者（自律した個人・組織）が新たなシステムを作り、それが人々にとってより良いものであるなら、自然とそのシステムに移り変わるだろうという発想です。

私はアーキテクチャの観点から考えています。 法律は施行された時から社会に対し強制力を持ちますが、アーキテクチャは社会に対しオプション（選択可能性が確保される）になります。 そのため、できることならアーキテクチャの方が良いと考えます。 しかし、アーキテクチャで独占を変えられない地点まで行ってしまった場合は法律を作る正当性があると考えます。

理想（目的）は、利用者がWebサービスの提供者に隷属している状態から脱却し、ある提供者の一存で利用者が右往左往されるのではなく、Webサービスの主権を利用者が持つことです。 そのためには、誰でも提供者になることができ、かつ利用者が提供者を自由に選択できることが必要です。 ここでの「自由に」というのは、利用者が乗り換える際に、その乗り換え先から同等以上の効用を得ることができるということです。 データを伴わない移行などで、効用が下がった場合、それは不自由な選択です。 例えるなら、居場所のない女性がDV彼氏に依存してしまう状況から、たくさんの男性がその女性にアプローチする状況が生まれ、より大切に扱ってくれる男性の所へ行くという感覚です。 したがって、依存の原因であるデータロックインを回避し、誰でも特定のWebサービスを提供でき、かつ利用者（社会）が特定のWebサービス提供者に依存しないWebアーキテクチャを構築するのが目標になります。

コラム：法律とアーキテクチャ

法律とアーキテクチャの関係についてさらに詳しく知りたい方には、アーキテクチャと法がオススメです。 数年前に興味で購入しました。 読みやすいため、今でもたまに気軽に開きます。 買ってよかったと思える書籍です。

コラム：データの種類

データロックインでロックされるデータはWebサービスに保存される全てのデータです。 それは、以下の２種類に大別できます。

  • アカウント（フォロー関係のネットワークを含む）
  • コンテンツ（投稿・いいね等）

コラム：IT反体制と反体制

新しい技術を作ることで反体制的な活動をしている人々を、ここではIT反体制と呼ぶことにします。 つまりIT反体制とは、新たなシステムを作ることによって確立されたシステムに反抗することです。 IT反体制の人々は技術決定論的な立場をとり、ITによって社会を変革できると信じています。 例えばWinny、Bitcoin、Web3、FediverseはIT反体制です。

IT反体制は反体制に含まれます。 そもそも反体制的な活動というのは、ガンジーのように政治的な権力に抗うことや、Bitcoinのように既存の金融システムに抗うことなどがあります。 ただし、後者はIT反体制で、前者はそうではありません。 また、自分のサイト内でブログ記事を投稿することによって反体制的な活動を行うのは、IT反体制ではありません（Cyber-dissidentとは異なる、ということです）。

私はIT反体制でありたいと思っています。 かと言って、全ての権威を否定したいわけではありません。 この世界はとても複雑なので、権威というシグナルがなければ成り立ちません。 ただ私は、私が認めない権威を、私が認める権威を頼りつつ否定したいのです。 そしてこれを社会に生きる全ての個人が行うことによって、より良い社会になると思うし、これが民主主義の真髄だと思うのです。

体制による反体制的な動向：法律など

体制による反体制的な動向というのは、政府という体制がWebサービスという体制に対し、反体制的な活動を行うということです。 私はアーキテクチャ派なので、ここでは軽く紹介だけしておきます。

EU

EUは法規制が進んでいて（歴史的な背景があるのでしょうが、すごいなと思います）、DMA（Digital Market Act）やGDPR（General Data Protection Regulation）などがあります。 DMAはデジタル市場の独占や寡占に、GDPRはデータとプライバシーに焦点を当てた法律です。 ここではDMAを取り上げます。

DMAでは、消費者と事業者を仲介する役割を持った巨大なWebサービスをゲートキーパーと見なします。 ゲートキーパーと見なされた企業に対しては、色々な規制がかかります。 その中には相互運用性やデータポータビリティへの対応などがあります。

DMAの具体例としては、AppStoreの開放があります。 現在スマホのOSはAndroidとiOSが双璧をなしています。 AndroidではWebからアプリをダウンロードできるため、アプリ市場は比較的自由なマーケットになっています。 一方、iOSはApple社の方針で、AppStore以外のストアからのアプリのダウンロードは不可能です。 これは、アーキテクチャではどうすることもできません。 というのも、OSレベルでAppStoreの独占が組み込まれているためです。 そのため、私は法律によるAppStore開放義務付けなどは正当であると考えています。 日本もAppStore開放義務付けを進めるらしく、DMAの後を追尾しています（DMAの影響力、すごいです）。

DMAについて、より詳しくは法律事務所によるまとめがいくつかあります。

日本

日本の現状は基本的に、AppStore等の規制法はEUの動向を踏まえています。 日本発ものとして、DFFT（Data Free Flow with Trust）があります。 日本が2019年にG20サミットでDFFTを宣言してから、政府はそれ関連のWG（Working Group）をいくつか立ち上げています。 そのなかで提案された、

  • PDS（Personal Data Store）
  • Trusted Web

は注目すべき概念ではないでしょうか。 これらは法律というより、アーキテクチャです。 特にPDSのデータのキャッシュというアイディアについては、目標にとって必要だと思います。 ここではPDSをざっくりと紹介し、Trusted Webは目標にとっての重要性は低いため割愛します。

PDSと情報銀行

画像はAI、IoT 時代におけるデータ活用ワーキンググループ 中間とりまとめの概要 より引用

PDSは、利用者はデータをクライアントまたはサーバーにキャッシュし、利用者がキャッシュしたデータを他のWebサービスに送信することによって、データの自由な流通を実現しようとしています。 クライアントにデータをキャッシュするのは、データを送信する前にブラウザ内に保存することで実現できます。 サーバー（PDS事業者）にデータをキャッシュするのは意味があるのかと思われるかもしれませんが、これは情報銀行という概念があるためです（多分）。

情報銀行というのは、Webサービスに送信するデータを代わりに情報銀行に預けておき、利用者が承諾することによって、そのデータを他のWebサービスに送信できるというものです。 情報銀行によってデータ取引の市場が形成され、データの取引は活発になると思いますが、それでも私は基本的には情報銀行の意義をあまり感じません。 というのも、情報銀行はSPoF（単一障害点）になりますし、結局データロックインする主体がWeb2のWebサービスから情報銀行（というWebサービス）に変わるだけではないかと考えるためです。

クライアント型のPDSのみが、目標達成にとって筋道が立ちます。 ただし、PDSのみでは目標を達成できません。 PDS以外にも、必要な技術要素があります。

PDSについては、データ流通 | 政府CIOポータルに詳しいです。 また、余談ですがTrusted Webについては専用のサイトができたようです。

無名の人々によるIT反体制的な動向：アーキテクチャ

Webサービスの提供者はアーキテクチャや法的な制約がなければ、提供者間の競争で優位に立つために、利用者をロックインする方向に向かいます。 ここではIT反体制的な動向として、Web3とFediverseを紹介します。 次世代Webの代表例として取り上げられることのあるWeb3ですが、実は目標に対してアーキテクチャ的な進歩がないことを示します。 また、Fediverseにはそれがあること、そしてFediverseが抱える問題を示します。

Web3とは？

Web3とは技術的なムーブメントの一種で、数年前からホットワードになっています。 どんなムーブメントなのかと言うと、Webを分権化し、SPoFを取り除くというものです。 しかし今ではマーケティングの言葉として広く使われすぎているため、どんなムーブメントかを定義するのも困難です（しかし、ブロックチェインを使うという点においては一致することが多いです）。

ここでは、「以前のWeb3は『分散型Web』という意味で使われており、Web2を刷新すると考えられていたが、最近はWeb2に付加価値を付けた『分散型アプリケーション』という意味で使われている」という解釈をします。 付加価値をつけるというのは、つまり現在のWebアーキテクチャ（Web2）に内包されつつ、既存のWebサービスと差別化を図るということです。 例えば、NFTマーケットプレイスやDEX（Decentralized Exchange）はここでの解釈におけるWeb3に当てはまります。 ちなみに、付加価値をつけるという文脈では、Trusted Webと似ています（ただし、Trusted Webは既存のWebサービスとの差別化というより、既存のWebサービス上を流れるデータに信頼性を付与しようとしています）。

Web3

Web3のアーキテクチャは、上図のようなものです。 ブロックチェイン上にデプロイされたコントラクトまでを１つのWebサービスと捉えます（層が増えて深さが増したという認識）。 Web3のアプリケーションはプロトコルという言葉を用いることがありますが、それは主に、ブロックチェイン上のコントラクトとして表現されています。 そしてそのプロトコルにアクセスするための手段として、Webというインターフェイスがあります。 取引はコントラクト上で実行され、そのデータはブロックチェイン上に保管されることによって、データの透明性と検証可能性が実現できます。 WebサービスAで取引してブロックチェインに書き込んだものは、WebサービスBでも参照可能なわけです。

Webがコントラクトという新たな武器を手にしたことで、既存のWebサービスに付加価値をつけることが可能になった、そしてそれがWeb3の正体だと言えるでしょう。 付加価値の代表例がNFTで、ディジタルデータにトークンによって一次元的な価値基準（ものさし）を与えることに成功しています。 またDEXは、今まではネット証券会社で為替取引を行う際に証券会社に対し信頼が必要だったのに対し、DEXのコントラクトを誰でも検証でき、利用者が実際に検証することによって提供者に対する信頼が不要となりました。 つまり、検証可能性による信頼という付加価値が加わったのです。

しかし、Web3は「依存の原因であるデータロックインを回避し、誰でも特定のWebサービスを提供でき、かつ利用者（社会）が特定のWebサービス提供者に依存しないWebアーキテクチャを構築する」という目標は達成できないと考えます。 というのも、Web3のアーキテクチャでコントラクトまでを１つのWebサービスと捉えたときに、「誰でも特定のWebサービスを提供でき」ず、また「利用者（社会）が特定のWebサービスに依存」してしまう事があるためです。 Web3のアプリケーションは、データがブロックチェイン上に保管されているので、どこからでもデータを検証できます。 しかし、メール送信などといったコントラクトが対応できない範囲の処理や、GAS代の関係でコントラクトで行うのに適していない処理は、Webインターフェイス上で行います。 Webインターフェイスで行う必要のある処理があれば（または意図的にWebインターフェイスを介する必要があるように仕向けていれば）、それはWeb2に深さが増しただけで、利用者はWebサービスに依存します。

一方、Uniswapなど、コントラクトを直接的に呼び出せばWebインターフェイスが不要なアプリケーションもあります。 コントラクトのみを使用する場合は、Webサービスというより（スマートコントラクトの）アプリケーションというのが適切です。 ただし、コントラクトのみの場合でも、ある条件を満たせば、現在のWebサービスと同じような状況が起こり得ます。 その条件は、単一の主体が開発・提供しており、その主体がコントラクトの動作に影響を与えられることです。 というのも、単一の主体の意思決定が、そのアプリケーションに直接的な影響を及ぼすためです。 これは、例えば開発者のアドレスからしか受け付けない処理（アップデート等）があるコントラクトなどが当てはまります。

以上をまとめると、Web3は

  • 既存のWebアーキテクチャに付加価値をつけたアプリケーションで、付加価値までを１つのWebサービスと捉える（基本的なWebアーキテクチャは変わっていない）
  • 利用者が特定のWebサービスに依存することもある

と言えるでしょう。

Fediverseとは？

Fediverseはfederation（連合）とuniverse（宇宙、あるいは世界）の造語です。 FediverseのWebサービスとWeb2のWebサービスはアーキテクチャ的に別物で、FediverseとWeb2は並行世界的な関係です。 そのため、このuniverseは「宇宙」よりも、「世界」と訳すほうがしっくりきます。

Fediverseを紹介する前に、Webサービスの定義を拡張　―私はFediverseが登場してから、Webサービスの定義が拡張されたと考えています―　しておきます。 最初はWebサービスを「単一の主体が提供する、ブラウザを通じてアクセスできるアプリケーション」と定義しましたが、Fediverse登場以降のWebサービスは「１人以上の主体が自律的に提供する、ブラウザを通じてアクセスできる全体として１つのアプリケーション」と定義します。 この定義で大事なのは、複数の主体が提供できるが、１つのアプリケーションとして成り立つということです。

どういうことでしょうか？ 図にすると以下のようになります。 Fediverse

Fediverseでは、独立したサーバー同士が通信し、自分のサーバーと他のサーバーの利用者が繋がれます。 つまり、サーバー間での相互運用性があるのです。 FediverseのWebサービスは、サーバー側のソフトウェアがOSSで公開されることが多いです。 OSSで公開することによって、サーバーを立てたい主体がフォークし、改変し、デプロイできます。 サーバーの提供者はそれぞれ自律的な主体ですが、プロトコルによって相互運用性が実現しているため、全体として１つのアプリケーションと解釈できます。 例えば、Mastodonという１つのWebサービスは、複数の自律した主体が構成するサーバー群から成り立っています。 なお、ここでいうプロトコルはソフトウェア独自の規格でも構いません（現実にはW3Cで規格化されたActivity Pubが使われることが多いです）。

以上をまとめると、Fediverseのアーキテクチャ的な革新性は

  1. 複数の主体が全体として１つのWebサービスを作るということ
  2. 誰でもWebサービスを改変できるようになったこと

です。

Fediverseは「依存の原因であるデータロックインを回避し、誰でも特定のWebサービスを提供でき、かつ利用者（社会）が特定のWebサービス提供者に依存しないWebアーキテクチャを構築する」という目標を、部分的に達成しています。 Fediverseでは、サーバーとクライアントは一対多の関係で、サーバー同士は多対多という関係があります。 つまり、利用者は１つのサーバーを利用し、サーバー側が多数のサーバーと通信するという形です。 利用者が利用している以外のサーバーでも投稿等のデータを参照したり反応したり出来るという点で、データポータビリティが確保されており、データロックインを回避しています。 その反面、データポータビリティの範囲が限られます。 例えば、MastodonやMisskeyといった主要なFediverseソフトウェアではActivity Pubが採用されていますが、Activity Pubの関知しない部分についてはデータポータビリティが実現できていません。 実際に、それらのソフトウェアでは公開鍵認証が導入されておらず（2023年7月27日時点）、アカウントのデータポータビリティが確保できていません。

現状のFediverseはデータポータビリティの柔軟性に欠けていると考えます。 ActivityPubはSNS用に最適化されたプロトコルですが、SNS以外のWebサービスでもデータロックインはあります。 例えばAmazonやメルカリ等のフリマサービスです。 そのようなサービスでもデータポータビリティが確保されてほしいです。 付け加えると、利用者主権なWebサービスでは、ソフトウェアの発展に伴って誰でもデータポータビリティの範囲をも拡張できるべきだと考えます。

また、Web2と比較して、２つのインセンティブの問題があります。 第１にFediverseソフトウェア制作者のインセンティブです。 Fediverseのソフトウェア制作者は、同じ規模のWeb2的なWebサービスを制作するよりも儲かりません。 というのも大抵のプロジェクトが、OSSにして寄付を受け付けるというモデルのためです。 第２にFediverseソフトウェアをホストする人のインセンティブです。 Fediverseソフトウェアをホストする場合、他のホストからデータを受け取ったり、他のホストへデータを送ったりすることに、Web2のWebサービス以上のコストがかかります。 つまり、従来の広告やサブスクリプションモデルでは、アーキテクチャの特性によって利用者あたりの利益の割合が低くなります。 従ってWeb2と比較して、Fediverseのソフトウェア制作者やホストは少なくなります。

Portable Web

私は、Fediverseが最も最適な解決策に近いと思っています。 しかし上述の問題があります。 そこで、それらの問題を解決したアーキテクチャとそれを実現するためのソフトウェアを作りました。 それがPortable Webで、いつか公開する必要があると思っています。 ちなみに、概要は既に公開されています。