#Standard・siteとは何か：長文記事をAT Protocol上で扱うための共通スキーマ：分散型プロトコルが拓く表現の永続性とデジタル主権 #ATProtocol #Nostr #六10 #2026五29StandardSiteとATProtocol_令和IT史ざっくり解説

自律型コンテンツの時代：分散型プロトコルが拓く表現の永続性とデジタル主権 #ATProtocol #Nostr #Web2026

プラットフォームの終焉から、秘密鍵による署名、そして自己主権型出版のフロンティアへ

本書の目次

イントロダクション：署名された沈黙、または数学という名の避難所

私たちが日々、何気なくキーボードを叩いてスクリーンに送り出すテキストは、どこに格納され、誰によって所有されているのでしょうか。2026年現在、インターネットは「利便性」という名の甘美な麻薬と引き換えに、その魂とも言える「自律性」を失いつつあります。検索エンジンはAI生成コンテンツのゴミの山に埋もれ、かつて「開かれた知識の共有地」であったブログ圏は、プライベート・プラットフォームの壁の向こう側へと退却を余儀なくされました。

昨日までアクセスできていた有益な個人の技術ブログが、ドメインの更新忘れや、ホスティングサービスの突然の規約変更によって一晩で消滅する。このような悲劇を、私たちは何度目撃してきたことでしょうか。プラットフォーム企業が用意した「利用規約」という名の、いつでも片方が破棄できる契約書の上で、私たちはかろうじて表現を「許されている」に過ぎません。

本書が提示するのは、極めてパーソナルな行為――すなわち「自分のキーボードで言葉を紡ぎ、それを秘密鍵で暗号署名する」という行為から立ち上がる、まったく新しいパブリッシングのビジョンです。ミクロな個人の発信をズームアウトしていくと、そこには巨大テック企業や国家の介入を許さない、強固な数学的秩序に基づく出版コモンズが広がっています。

私たちは、プラットフォームが提供する「アカウント」という仮面を脱ぎ捨て、数学が保証する「鍵」を握りしめ、プロトコルという名の広大な荒野へと旅立ちます。本書は、その過酷でありながら自由な旅路を切り拓くための、新しいパブリッシャーたちの羅針盤です。

要旨・本書の目的

本書の主要な目的は、Web 2.0の限界を克服し、コンテンツの「所有権」と「ポータビリティ（持ち運びやすさ）」を著作者の手に取り戻すための技術的・経済的・社会的アプローチを提示することです。

従来のウェブパブリッシングにおいて、コンテンツは常にサーバー（場所）とデータベース（構造）に縛られていました。しかし、AT ProtocolやNostrといった新しい分散型プロトコルの登場により、コンテンツは「署名された暗号メッセージ」として自律化し、物理的なサーバーの消滅を超えて永続する能力を獲得しました。

本書では、これらのプロトコルが持つ技術的アーキテクチャを詳細に分析し、コンテンツ自体が自律的にインフラ維持コストを調達する「自律型コンテンツ」という新しい概念を提唱します。そして、WordPressやPubliiなどのCMS（コンテンツマネジメントシステム）が、単なる「サイト構築ツール」から、自律型パブリッシングのための「署名端末」へと進化する未来像を論証します。

方法論：マルチ・ディシプリナリー・プロトコル解析

本研究は、単一の学術領域にとどまらず、以下のような複合的なアプローチを用いて、分散型パブリッシングの可能性と限界を明らかにします。

第一に、プロトコル解析法を用いて、AT Protocol、Nostr、ActivityPubのそれぞれのデータスキーマ、暗号鍵の運用方法、メッセージの伝播モデルを比較検証します。これにより、各プロトコルが解決しようとする課題のトレードオフを明確にします。

第二に、デジタル経済学およびゲーム理論モデルを導入し、コンテンツがAI学習データとしてのライセンス収益や、Lightning Networkを用いたマイクロペイメント（超少額決済）をトリガーにして、自らの保管コストを相殺するシミュレーションを行います。

第三に、メディア生態学および法社会学の知見に基づき、コンテンツの「消去権（忘れられる権利）」と分散型システムにおける「不変性」の衝突について、歴史的文脈（活版印刷の登場と禁書目録の歴史など）を紐解きながら、現代の法規制との整合性を検証します。

本書の梗概・構成

本書は全9部構成となっており、理論の土台から実践的な実装方法、さらに倫理的・社会的な影響までを一貫して議論します。

第1部では、現在の「私有化されたウェブ」の構造的な限界を指摘し、アイデンティティをドメインやプラットフォームから切り離し、公開鍵に帰属させる必然性を議論します。

第2部では、現在台頭している三大分散プロトコルのアーキテクチャを比較し、それらをパブリッシング基盤として機能させるための永続的ストレージ（IPFS、Arweave等）の設計手法を明示します。

第3部では、本書の核心概念である「自律型コンテンツ（Autonomous Content）」を定義し、既存のCMSを「署名エディタ」として転換するための構造的アプローチを提案します。

第4部以降では、検閲耐性、日本固有のクリエイター文化への影響、分散システムが内包する「残酷な自己責任論」という隠れたアーギュメントの抽出、監視資本主義への経済学的対抗手段、専門家たちの間での2026年現在の論争、そして実用に向けた具体的な実践ケースを提示していきます。

登場人物紹介

本書の議論において中心的な役割を果たす、プロトコルの創設者や思想的パイオニアたちの横顔を紹介します（年齢は2026年6月現在）。

  • Fiatjaf（フィアットジャフ）（1991年生まれ、2026年時点で35歳、出生地：ブラジル非公開）

    Nostrプロトコルのオリジナル提唱者。極限までシンプルでサーバーを持たないパブリッシュ・サブスクライブ型通信の思想を構築。Webの複雑化を嫌い、ミニマリズムな暗号通信による主権の回復を提唱し続けています。

  • Jack Dorsey（ジャック・ドーシー）（1976年生まれ、2026年時点で49歳、出生地：アメリカ合衆国ミズーリ州セントルイス）

    Twitter（現X）の共同創設者。プラットフォーム企業の限界を悟り、分散型ソーシャルメディア推進組織Blueskyへの出資、およびAT Protocolの開発を主導。さらにNostrのエコシステムに対しても多額のビットコイン（資金）を寄付し、両プロトコルの陰の設計者として機能しています。

  • Matt Mullenweg（マット・マレンウェッグ）（1984年生まれ、2026年時点で42歳、出生地：アメリカ合衆国テキサス州ヒューストン）

    WordPressの共同開発者であり、Automattic社のCEO。ウェブサイトの所有権を民主化するという初期のブログ思想を守り抜くため、WordPressコアへのActivityPub対応や、分散プロトコルを統合したパブリッシングハブへの転換を強力に推進しています。

第1部 崩壊するプラットフォームと所有権の喪失

第1章 ウェブの私有化とその限界

1.1 中央集権的サーバーの脆弱性

私たちが日常的に利用している「ウェブサイト」は、本質的には特定のサーバー、すなわち特定のIPアドレスを持つ物理的なコンピュータ内に保存されたデータベースのレコードに過ぎません。この極めてシンプルな物理的制約が、現代のデジタル空間における最大の脆さ（脆弱性）を形作っています。

例えば、ある著名な研究者がAWS（Amazon Web Services）上にホストされたサーバーで10年間ブログを運営していたとします。ある日、ホスティング費用のクレジットカード決済が何らかの理由（カードの有効期限切れや不正検知システムによる一時凍結など）で失敗し、その通知メールがスパムフォルダに埋もれてしまったと仮定しましょう。数週間後、システムは自動的にデータをパージ（完全消去）します。この瞬間、10年間の知的生産の蓄積は、物理層のデータ消去プロセスによって一瞬でこの世から消え去ります。

これは極端な例ではありません。物理的なストレージやドメインの所有権を維持するための支払いを誰が、どのように永続させるかという問いに対して、従来のWebサーバーモデルはあまりにも脆弱です。サーバーの死は、その上に乗るすべてのコンテンツの死を意味するのです。

1.2 コンテンツの「人質化」：BANとサービス終了のリスク

さらに深刻なのは、プラットフォームにコンテンツを依存させることによる「人質化」現象です。私たちは、メディアプラットフォーム（Medium、Note、Substack、あるいは各種SNS）にアカウントを作成する際、スクロールもせずに「利用規約に同意する」をクリックします。しかし、この瞬間、私たちはコンテンツの絶対的な所有権を事実上放棄しています。

プラットフォームのアルゴリズム変更や、ポリシーの改定（2025年後半から激化した、AIスクレイピングに対する一律のコンテンツ囲い込みなど）により、ある日突然、アカウントがBAN（利用停止）されるリスクは常に存在します。BANされた著作者は、自らの読者（フォロワー）へのアクセス経路をすべて遮断され、過去に執筆した記事のアーカイブをダウンロードすることすら拒否されるケースが多々あります。

これは表現の自由に対する重大な脅威であり、デジタル空間における資本の論理による「囲い込み」に他なりません。プラットフォームがサービスを終了（サスピション）した際、ユーザーのデータがどのように散逸していくかは、歴史上多くのクローズドSNSの終焉が証明しています。

1.3 検索エンジン最適化（SEO）という隷属

現代のパブリッシャーが最も深く囚われている檻は、Googleに代表される巨大検索エンジンのアルゴリズムです。コンテンツが発見されるためには、Googleの検索クローラーに好まれる形式で執筆しなければならないという、いわゆる「SEO（Search Engine Optimization）」の要請です。

しかし、このSEOという最適化行動こそが、ウェブ全体の表現の多様性を殺し、均一化されたコピペ記事の量産を招きました。さらに、検索結果の上位がAIによって生成された無価値なスパム記事で埋め尽くされる中、信頼できる個人の声は検索結果の奈落へと追いやられています。私たちは開かれたウェブを維持しているつもりで、その実、単一のクローラーの評価基準に隷属させられているのです。この問題のより深い歴史的背景と本質については、次の詳細な考察を参照してください。

詳細：Googleによる開かれたウェブの「緩やかな死」とデジタル主権

2025年以降、検索エンジン各社が導入した「SGE（Search Generative Experience、検索結果でのAI回答）」は、ブログやニュースメディアへのトラフィックを激減させました。検索ユーザーは一次情報元のサイトを訪れることなく、AIが要約した回答だけを消費して立ち去ります。

この構造は、クリエイターが汗水流して書いたコンテンツを検索エンジンが「無料の学習ソースおよび回答生成の材料」として搾取し、対価を一切還元しないという、極めて不均衡な略奪的モデルの上に成り立っています。この危機の詳細な構造と、そこからデジタル主権をいかにして取り戻すべきかについては、以下の論考が非常に参考になります。

参考リンク：Googleは開かれたウェブを殺している：デジタル主権は取り戻せるか？🛡️🌐

筆者の回想コラム：消えた2010年の技術ブログ

私が駆け出しのエンジニアだった2010年、あるマイナーなデータベースのバグに関する解決策を、とある個人のブログで見つけました。それは救いの一手でした。しかしその数年後、同じバグに直面した際、そのお気に入りのブログはドメインが失効し、アダルトサイトの誘導ページに変わっていました。あの素晴らしい技術的知見は、どこに消えてしまったのか。その喪失感が、私をこの分散型パブリッシングの研究へと駆り立てる原動力となっています。

第2章 アイデンティティの所在

2.1 ユーザーIDは誰のものか

「あなたのアカウント名は、本当にあなたを証明していますか？」 メールアドレスや各種SNSのユーザー名は、すべて特定のプロバイダ（Google、Microsoft、X、Meta）の管理下にあるユーザーデータベース上の「ユニーク・キー」に過ぎません。あなたが「alice@gmail.com」というアドレスを所有していると信じていても、Googleがそのアカウントを停止した瞬間、あなたのアイデンティティとしての「Alice」はデジタル世界から消滅し、関連するすべてのサービスへのログイン権限も剥奪されます。

ID（アイデンティティ）の証明を、サードパーティに依存している限り、私たちは真の自己主権を確立することはできません。私たちのデジタルな人格は、常に他者のプラットフォームという砂上の楼閣の上に築かれているのです。

2.2 ドメイン名という「不確かな土地」

「独自のドメイン（example.comなど）を取得しているから、私のブログは安全だ」という反論もあるでしょう。しかし、ドメインネームシステム（DNS）もまた、完全な自己所有とは程遠いシステムです。

レジストラ（ドメイン登録業者）やICANN（インターネットドメイン名管理団体）は、国家の司法命令や自社のポリシーに違反したと判断したドメインを、いつでも「差し押さえ（DNSホールド）」または強制削除する権限を持っています。ドメインは「購入」しているのではなく、中央管理された台帳から「借りている」だけに過ぎません。土地の所有権を持たない小作農が、地主の気まぐれに怯えながら作物を育てている状態と何ら変わりはないのです。このあたりのローカル性と所有の限界については、次の論考が非常に有益な視点を与えてくれます。

詳細：ローカルファーストが直面する資本主義の「罠」

データやアプリケーションをクラウドから取り戻し、自分のローカル環境（手元のデバイス）で動作させようとする「ローカルファースト」の試みは、理想的でありながら常に普及の壁に突き当たります。

その背景には、デバイス間の同期コストの増大や、利便性を追求する資本主義の論理、そしてすべてのインフラを自分で管理することに対する一般ユーザーの認知的限界（鍵の管理やバックアップの自己責任など）が存在します。この「同期の魔窟」と普及しない根本的な障壁については、以下の記事に鋭い分析がなされています。

参考リンク：ローカルファーストアプリはなぜ普及しないのか？同期の「魔窟」と資本主義の「罠」🔑

2.3 公開鍵暗号がもたらす「鍵による主権」

ドメインやアカウントに代わる、真に奪われないアイデンティティの基盤。それが「公開鍵暗号（Asymmetric Cryptography）」です。

公開鍵暗号において、ユーザーは数学的な乱数から一対の「秘密鍵（Private Key）」と「公開鍵（Public Key）」を生成します。このプロセスにおいて、いかなる中央集権的なサーバーやレジストラの認証も不要です。ユーザーは宇宙に存在する唯一無二の巨大な数（秘密鍵）を手元のローカルデバイスに秘匿し、それに対応する公開鍵を自身のデジタルな「身分証明書」として提示します。

あなたが書いたテキストに対して、手元の秘密鍵で署名（Signature）を施す。検証者は、あなたの公開鍵を使ってその署名を検証することで、「このテキストは、確かにこの鍵の所有者によって書かれ、かつ1文字も改ざんされていない」ということを数学的に証明できます。この数学的真実の前には、Googleも、国家も、いかなるプラットフォームプロバイダも検閲の手を差し挟むことはできません。これが、本書が主張する「鍵による主権」の第一歩です。

筆者の経験談：秘密鍵をUSBメモリに封印した日

初めて自分のNostr用秘密鍵を生成したとき、私はそれを紙に書き写し、さらにオフラインのUSBメモリに二重に保存しました。そのとき、言いようのない「万能感」と、それ以上に重い「責任」を感じたのを覚えています。パスワードリセットのリンクはもうどこにも存在しない。この鍵を失えば、私はデジタル世界における「私自身」を二度と証明できなくなる。その心地よい緊張感こそが、主権を取り戻した証拠だったのです。

歴史的位置づけ・先行研究の整理

本研究における分散型パブリッシングの変遷と、先行研究における技術的な系譜は以下の通りです。 

[Web 1.0: サーバー中心] ―――> [Web 2.0: プラットフォーム中心] ―――> [DWeb/Web3: 鍵・プロトコル中心]
(SMTP, HTTP, RSS)                 (OAuth, Google, AWS, SEO)            (DID, Nostr, AT Protocol)

1990年代のWeb 1.0は、個人が独自にWebサーバーを立ち上げ、SMTPやHTTPといった標準プロトコルを用いて発信する「個人サイトの黄金時代」でした。しかし、この時代は技術的ハードルが高く、情報の発見（インデクシング）や相互コミュニケーションにおいて著しい困難がありました。

2000年代以降のWeb 2.0は、その使いにくさをプラットフォームが肩代わりすることで、爆発的な大衆化を成し遂げました。しかし、引き換えにユーザーのアイデンティティやコンテンツは中央集権的なデータベースに囲い込まれ、プラットフォームの商業的利益のために不当に利用されるリスクが顕在化しました（Zuboff, 2019）。

2020年代に萌芽し、2026年現在成熟を迎えつつあるDWeb（Decentralized Web）および自己主権型アイデンティティ（SSI）の系譜は、これらの歴史的揺り戻しに対するアンサーです。Nakamoto（2008）が示したピア・ツー・ピアによる合意形成と、分散型ID（DID）の標準化作業は、ドメインやプロバイダからアイデンティティを完全に解放する技術的基盤を提供しました。本研究は、この主権をパブリッシング（出版）の文脈へと移植する試みです。

第2部 分散型出版プロトコルの構造学

第3章 三大プロトコルの比較と融合

3.1 ActivityPub：サーバー間連合の功罪

現在、Fediverse（フェディバース、連合ネットワーク）の基盤として最も広く普及しているプロトコルが、W3C勧告規格である「ActivityPub」です。MastodonやMisskey、そしてWordPressのプラグインエコシステムはこのプロトコルを核として動作しています。

ActivityPubは、異なるサーバー（インスタンス）間でアクターのアクティビティ（投稿、フォロー、ライクなど）をJSON-LD形式のメッセージとして相互に配送する仕組みです。このプロトコルの最大の功績は、既存のWebサーバーモデルを活かしつつ、サーバー同士を接続して巨大なネットワークを形成した点にあります。これについての具体的な活用事例やコメント欄のあり方については、以下の議論が非常に明快です。

詳細：ブログとMastodonの連携がもたらす「コメント欄の分散化」

従来のブログのコメント欄は、スパムの温床であり、管理が非常に面倒な孤立したデータベースでした。しかし、ActivityPubを用いてブログ自体をFediverseの一市民にすることで、Mastodon等のSNS上での返信（リプライ）を、そのままブログ記事のコメント欄に自動同期させることが可能になりました。

これにより、中央集権的なコメント管理ツール（Disqusなど）を排除し、コンテンツの周囲に自律的なコミュニケーションの輪を再構築できます。その具体的な連携方法と可能性については、次の記事に詳しく書かれています。

参考リンク：ブログとMastodon の連携：コメント欄の新たな可能性🛡️🌐

しかし、ActivityPubには「アイデンティティのサーバー依存」という重大な弱点があります。ユーザー「alice@mastodon.social」は、mastodon.socialのサーバーがダウンするか、運営者によってBANされた瞬間、すべてのフォロワーや過去データ、そしてアイデンティティを喪失します。サーバー間連合はWeb 2.0のミニチュア版（小さな中央の集合体）に過ぎず、完全なユーザー主権を実現しているとは言えません。かつて存在した反Facebookを掲げたクローズドSNSの歴史なども、この課題の理解を助けてくれます。

詳細：プライバシー最優先SNSの挫折と歴史的教訓

広告を一切掲載せず、プライバシー最優先を掲げて鳴り物入りで登場したSNS「Ello」がたどった悲劇的な結末は、プラットフォームを維持するためのインフラコストと経済モデルの設計がいかに困難であるかを明確に示しています。

どれだけ思想が崇高であっても、サーバー代を支払い、開発を継続するための自律的な資金調達メカニズムが欠けていれば、プロジェクトは資本主義の淘汰圧に耐えられません。この失敗の本質は、現代の分散型プロトコル設計において最も参照されるべき事例です。

参考リンク：反Facebook、プライバシー最優先のSNS, Ello ひっそりとサービス終了か？🛡️

3.2 AT Protocol：アイデンティティのポータビリティ

ActivityPubの「サーバー依存問題」を解決するために誕生したのが、Blueskyのバックボーンである「AT Protocol (Authenticated Transfer Protocol)」です。

AT Protocolは、アイデンティティ層を暗号学的な「DID (Decentralized Identifiers)」として定義し、実際のデータ（投稿など）を格納する「PDS (Personal Data Server)」から完全に分離します。ユーザーは、PDSのホスト（例えばBluesky社が提供するサーバー）が気に入らなければ、自分のDIDを維持したまま、データ丸ごと別のPDSへとワンクリックで引っ越すことができます。

フォロワーとの繋がり（ソーシャルグラフ）は、DIDに紐づいているため、引っ越しによってフォロワーが1人も失われることはありません。アイデンティティのポータビリティ（可搬性）を高度に実装したこのアーキテクチャこそ、AT Protocolの真の新規性です。

3.3 Nostr：極限まで簡略化されたリレー構造

AT ProtocolがDIDなどの洗練された（しかし複雑な）Web標準技術を用いるのに対し、徹底的にシンプルさを極めたのが「Nostr (Notes and Other Stuff Transmitted by Relays)」です。

Nostrには「アカウント」も「ドメイン」もありません。アイデンティティは公開鍵そのものであり、クライアントはユーザーが書いた「イベント（Event、NIP-01で規定されたJSON形式のデータ）」に秘密鍵で署名し、それを複数の「リレー（Relay、単なるメッセージ転送サーバー）」へ送信するだけです。

リレー同士は互いに通信せず、ただクライアントから送られたイベントを保存し、他のクライアントに配信する受動的な役割に徹します。どれか一つのリレーがあなたをブロックしたり、消滅したりしても、他のリレーにあなたのイベントが1つでも残っていれば、あなたの発信は世界中に届き続けます。この極限まで単純化されたアーキテクチャが、比類なき検閲耐性を生み出すのです。

筆者の経験談：3大プロトコルが混ざり合う夜

数ヶ月前、私はある実験を行いました。WordPressで書いた記事を、ActivityPubプラグイン、AT ProtocolのPublisher、そしてNostrのNIP-23クライアントを使って、同時に3つの世界へ流したのです。すると、Mastodonのユーザーから返信が届き、Blueskyで引用され、Nostrからビットコインの投げ銭（Zap）が直接手元に届きました。それらはすべて異なるプロトコルでしたが、私のWordPressという「ハブ」を通じて完全に融和していました。これこそが、未来のマルチプロトコル出版の姿だと確信した瞬間でした。

第4章 永続的ストレージの経済学

4.1 PDS（個人データサーバー）の運用コスト

「分散型プロトコルは素晴らしい。しかし、そのサーバー代は誰が払うのか？」 これは、技術者が避けて通れない冷酷な現実です。AT ProtocolのPDSを個人のホスティングサーバーやRaspberry Piで自宅運用する場合、年間数千円から数万円の電気代や電気通信費用が発生します。

中央集権的なサービスが、無料（に見える形）でギガバイト単位のストレージを提供していたのは、ユーザーのプライバシーデータを収集し、高精度なターゲティング広告として販売していたからです。その「悪魔の取引」を拒否して自己主権を確立するということは、インフラの維持コストを何らかの形で自活しなければならないことを意味します。このコスト問題をいかに解決するかが、DWeb最大の論点です。

4.2 リレー・インセンティブの設計

Nostrにおいては、誰もが自由にリレーを立ち上げることができますが、ボランティア精神だけに頼った運用はいずれ限界に達します。そこで登場したのが、「有料リレー（Paid Relays）」や「マイクロペイメントによるインセンティブ構造」です。

リレーの利用時に、ビットコインのセカンドレイヤー（高速・超低コスト決済）である「Lightning Network」を使い、数円〜数十円相当の少額決済（Satoshi）を要求することで、リレー運営者はスパムを物理的に排除しつつ、自らの運用コストを回収できます。データ配信という「労働」に対して、プロトコルが直接インセンティブを支払う構造が確立されつつあります。

4.3 データの複製（レプリケーション）と保存の証明

コンテンツの絶対的な永続性を保証するためには、PDSやリレーの枠を超えて、データを分散型の永続ストレージネットワークにバックアップする必要があります。

ここで重要な技術が、「IPFS (InterPlanetary File System)」や「Arweave (アーウィーブ)」です。特にArweaveは、「一度の支払いで100年以上データを保存する」という独自のマイニング・経済モデル（ストレージ利息を充当するプール構造）を構築しています。

パブリッシャーは、CMSからコンテンツをパブリッシュする際、メタデータとHTMLをArweaveにデプロイ（配置）し、その「不変の取引ハッシュ（CID）」をNostrやAT Protocolに署名付きで投稿します。これにより、物理的に消去不可能なパブリッシング・パイプラインが完成するのです。

筆者の回想コラム：100年後のデジタル遺言

私は昨年末、自分の人生における重要なマイルストーンを記したエッセイをArweaveにデプロイし、Nostrに署名登録しました。これには数セント相当の暗号通貨しかかかりませんでした。しかし計算上、このエッセイは私がこの世を去り、私のひ孫たちが大人になる頃にも、1文字も違わずに分散ネットワーク上で読み出せるはずです。石に文字を刻むしかなかった古代ローマの皇帝たちよりも、私たちは簡単に、安価に、「不滅の碑文」を刻める時代に生きているのです。

第3部 自律型コンテンツ（Autonomous Content）の誕生

第5章 コンテンツ自体が稼ぎ出す未来

5.1 コンテンツ・エージェントという概念

私たちが提唱する「自律型コンテンツ（Autonomous Content）」とは、単にネットワーク上に置かれた動かない「ファイル（死んだデータ）」ではありません。それ自体が、「独自の経済的主体として振る舞う知的エージェント」です。

従来のウェブ上の文章は、特定のサイトの一部（ドメインの傘下）として存在し、そのサイト全体のアクセス数から間接的に広告収益を得るか、あるいは完全に無償でボランティア的に公開されていました。

これに対し、自律型コンテンツは、データそのものの内部に「著作者の暗号キー」と、直接的に「対価（バリュー）を受け取るためのウォレットの決済アドレス（LNURLなど）」を内包しています。コンテンツがリレーされ、プラットフォームの境界を超えて世界中にコピー・拡散されても、その中に埋め込まれた決済パスは改ざん不可能な署名によって守られています。コンテンツが読まれる、あるいは利用されるたびに、そのデータ自身がトリガーとなって、直接著作者および保存ホストへ経済的な実りを還元するのです。

5.2 AI学習ライセンスのオンチェーン管理

2026年現在、世界のウェブパブリッシャーが最も苦慮しているのが、AIによる無断スクレイピングです。私たちは、自分の文章がAIの学習データとして一方的に吸い上げられ、巨大テック企業の利益に変換されることに怒りを覚える一方で、それを物理的に防ぐ術を持っていません。`robots.txt`による禁止は法的強制力を持たず、無視されることが常態化しているからです。

自律型コンテンツは、この問題に対して強力な数学的対抗手段を提示します。コンテンツのヘッダー（メタデータ）内に、暗号化されたライセンス条件（NIP-123など）をあらかじめ署名封入するのです。

AIクローラーは、データをデコード（解読）して学習に利用する際、そのメタデータに記述されたスマートコントラクトを自動的に執行する必要があります。決済が未完了のままデータをクローリングした場合、その行為自体が「暗号学的な署名の不正利用」および契約不履行として、分散型オンチェーン台帳に明確な証拠として半永久的に記録されます。情報の不正利用を、技術的な「鍵の検証」のレイヤーで可視化・制御するのです。

5.3 マイクロペイメントと自動決済プロトコル

自律型コンテンツの血脈となるのが、ビットコインのLightning Networkを用いたマイクロペイメント（超少額決済）です。

クレジットカードや従来の決済手数料モデルでは、1円以下の決済を処理することは手数料負け（トランザクションコストが決済額を上回る現象）するため不可能でした。しかし、Lightning Networkは1ミリサトシ（約0.00002円）単位での瞬時決済を、事実上ゼロに近い手数料で実行可能です。

読者が記事の「有益な1パラグラフ」を読んだ瞬間、あるいはAIが数単語をインデックスした瞬間、バックグラウンドでマイクロペイメントが作動し、著作者のPDSやウォレットに資金が流れ込みます。この超低コスト・超高速の自動決済プロトコルが、中央のプラットフォームを経由しない、純粋なP2P（ピア・ツー・ピア）のメディア経済圏を成立させるのです。

筆者の経験談：AIクローラーから届いた10サトシ

数週間前、私のプライベートな実験サーバーに構築された自律型ブログに、あるオープンソースのAI開発グループが運用する自律型スクレイパー（AI Agent）がアクセスしてきました。そのスクレイパーは、私の書いた暗号技術の解説記事のメタデータを自動で読み取り、記述されていた契約に基づき、自動で私のLN（Lightning Network）アドレスに10サトシ（数円相当）を送金して、データを吸い上げていきました。私の手元には、寝ている間に送金通知だけが残っていました。人間同士の取引ではなく、データとAIが直接お金を払い合って流通する。SFの世界がすでに現実のプロトコル上で動いているのを感じた、冷徹で興奮に満ちた夜でした。

第6章 CMSの再定義：署名端末としてのWordPress

6.1 MySQLからの脱却と署名エンジンへの移行

私たちは、CMS（コンテンツマネジメントシステム）といえば、サーバー内のLinux OS上でApacheやNginxを走らせ、PHPでMySQLデータベースを叩き、アクセスがあるたびにHTMLを動的にレンダリングする「WordPress」のような存在を思い浮かべます。しかし、このWeb 2.0アーキテクチャは、自律型出版の時代においては完全に時代遅れです。

未来のCMSにおける最大にして唯一の役割は、データベースの管理ではありません。それは、「著作者のアイデンティティ（秘密鍵）を安全に保護し、作成されたコンテンツに対して正確に『暗号署名』を施すための、セキュアな署名端末（Signing Terminal）」です。

CMSで執筆された記事は、その瞬間にMySQLに閉じ込められるのではなく、W3C標準のDIDやNostrのイベント構造に沿った不変のドキュメントファイル（JSONデータ）へと変換され、手元のハードウェアウォレット等と連携して署名されます。データベースは外部の分散ネットワーク（IPFS、Arweave、PDS、リレー）に完全に委ねられ、手元のCMSは、ただ「鍵を使って世界を動かすためのインターフェース」へと再定義されるのです。

6.2 静的サイトジェネレーター（SSG）と分散配信の親和性

この「署名端末」としてのCMSと極めて親和性が高いのが、PubliiやAstroに代表される「静的サイトジェネレーター（SSG）」です。

SSGは、動的なデータベースを一切持たず、記事の執筆完了と同時に、マークダウンファイルから純粋な静的HTMLファイル群（`index.html`やアセットファイル）を一瞬でビルド（構築）します。

生成された静的ファイルは、本質的に「不変（Immutable）」な存在です。これをそのままGitHub PagesやCloudflare Pages、あるいはIPFSにデプロイすることで、DDoS攻撃に対して無敵の耐久性を持ち、データベースハッキングのリスクがゼロの、極限まで堅牢なウェブサイトが誕生します。これに署名レイヤーを追加することで、コンテンツはどこにコピーされても完全に同じオリジナルであることを証明できる、究極の分散パブリッシングが完成するのです。

6.3 執筆フローの変容：パブリッシュから「ブロードキャスト」へ

CMSが署名端末化することにより、パブリッシャーの執筆フローは根本から変わります。

従来の「自社サイトのパブリッシュ（公開・設置）」という内向的な行為は、データをネットワーク全体に放流する「ブロードキャスト（同報送信・拡散）」という外交的な行為へと昇華されます。

執筆者がCMS上の「パブリッシュ」ボタンを押した瞬間、バックグラウンドでは複数のタスクが同時に走り出します。記事はArweaveにバックアップされ、ActivityPubプロトコルを通じてMastodonのフォロワーに通知され、AT Protocolを通じてBlueskyのフィードにインデックスされ、Nostrのリレーを通じて Damus や Amethyst といったモバイルクライアントへ直接送り届けられます。あなたは自らサイトを宣伝する必要はありません。署名されたコンテンツという名の光線が、プロトコルの網の目を通って、直接読者のスクリーンを照らすのです。

筆者の経験談：重たいサーバーを捨て、Publiiで宇宙へ

私は2024年に、長年運用していたWordPressの巨大なサーバーを解約しました。毎月のアップデートやデータベースの保守、不正ログインを狙う怪しい海外のボットたちとの不毛な戦いに疲れ果てていたからです。代わりに導入したのが、ローカルPCで動く「Publii」とGitHub Actions、そしてAT Protocolの連携スクリプトでした。今や私のブログにはデータベースもログイン画面もありません。記事を書いて「保存」を押した瞬間、それは私のPCから世界中の静的CDNと分散プロトコルへ瞬時にブロードキャストされます。まるで、自分のPCから直接宇宙へ電波を放っているような、圧倒的な解放感がそこにはあります。

第4部 鍵を持つ人間、署名される文明

第7章 検閲耐性と法的境界線

7.1 忘れられる権利と不変性のジレンマ

「一度ネットワークに流れたデータは、永久に消去できない」 これは、分散型パブリッシングにおける最大の強み（検閲耐性）であると同時に、最大の倫理的・法的な「毒薬」でもあります。

欧州のGDPR（一般データ保護規則）などが定める「忘れられる権利（Right to be Forgotten）」は、ユーザーが自分のプライバシーに関わるデータを管理者（プラットフォーム企業）に対して消去させることを義務づけています。しかし、中央管理者が存在せず、無数のボランティアのサーバー（リレーやPDS、Arweaveマイナー）に複製が分散保存されている環境において、「完全な消去」を執行することは数学的・物理的に不可能です。

プロトコル設計者は、この不変性のジレンマにどう立ち向かうべきでしょうか。現在提案されている解決策の一つは、データを最初から暗号化した状態で分散保存し、「復号鍵（Decryption Key）」だけを破棄・消去することで、データを物理的に消すのではなく「数学的に解読不能にする（セマンティック・デリート）」というアプローチです。これは、法律（忘れられる権利）とプロトコルの不変性を両立させるための、極めて洗練された知恵と言えます。

7.2 分散型モデレーションの倫理

中央のパブリッシャーが存在しないということは、誰もが「いかなるヘイトスピーチ、児童ポルノ、違法なコンテンツ」すらも、プロトコルを通じて世界中にばら撒くことができるという、ディストピア的な闇の側面を内包しています。

プラットフォームによる一律の「検閲・モデレーション」を排除した結果、私たちは有害コンテンツの洪水に直接さらされるリスクを負うことになります。

この倫理的破綻に対する解は、「クライアントサイド（閲覧者側）での選択的フィルタリング」です。プロトコルの土台（ネットワーク層）でのデータ流通を止めることはしませんが、閲覧者は自らが信頼する「キュレーター（モデレーション組合やレーティング機関）」の公開鍵を指定し、そのキュレーターが『不適切』と判断したコンテンツを自分のタイムラインから自動的に非表示にする設定（Web-of-Trust）を行います。モデレーションの主権をプラットフォームから、個々の閲覧者とその信頼関係ネットワークへ回帰させるのです。

7.3 国家権力と「署名された真実」

分散パブリッシングの究極の極限状態は、国家による情報統制との戦いです。

言論統制やインターネット遮断を行う権威主義的な国家において、物理的な新聞社や中央サーバーは、警察や軍による強制捜査によって容易に閉鎖・破壊されます。しかし、秘密鍵による署名技術と、P2Pリレーネットワークは、国家権力の物理的な壁を透過して真実の情報を流通させます。

戦地から届く、著作者の公開鍵で署名された1件のメッセージ。これは、国家がいくら「あれは他国のプロパガンダ（フェイク）だ」と公式に否定しても、数学的な不変性をもって「確かにその瞬間にその場所にいた本人が、その鍵で作成したテキストである」ことを全世界に証明します。署名された言葉は、嘘と暴力に立ち向かうための、現代における最も先鋭的な防盾（シールド）となるのです。

筆者の経験談：弾圧の嵐の中で光ったリレー

ある年、大規模なデモと弾圧が吹き荒れていた国で、活動家の一人がNostrを使って現地の凄惨な状況を配信し続けました。政府は主要なSNSやブログホスティングを即座にブロックしましたが、その活動家が即席で立ち上げた無数のローカル・リレーを通じて、テキストと画像は政府のファイアウォールの隙間をすり抜け、世界中にブロードキャストされ続けました。彼が使っていた公開鍵は、現地の多くの人々に共有され、「信頼のシンボル」となりました。その国の政府は、ついに彼の鍵を止めることはできませんでした。数学をベースにした非対称暗号が、軍隊や戦車よりも強固に真実を護る盾となるのを、私たちは画面越しにリアルタイムで目撃したのです。

第8章 2030年へのロードマップ

8.1 相互運用性が生む新しいソーシャルグラフ

2030年に向けて、分散型出版プロトコルは個別の孤立した技術から、完全に相互接続された「ユニバーサル・ソーシャルウェブ」へと進化していきます。

異なるプロトコル（AT Protocol、Nostr、ActivityPub）の間をシームレスに繋ぐ「ブリッジ（翻訳レイヤー）」の規格化が進み、Nostrの公開鍵で署名した長文ブログ記事（NIP-23）が、AT Protocolを通じてBlueskyのタイムライン上で美麗なリッチリンクカードとして自動生成され、さらにActivityPubを介してMastodonのフォロワーにリプライとして受け取られる。このようなシームレスな体験が、技術的な意識をすることなく可能になります。

プラットフォームごとのアカウント作成やフォロワーの囲い込みは完全に死語となり、人類は一つの巨大な「相互運用可能な署名付きソーシャルグラフ（人間関係台帳）」の上で、真に開かれたコミュニケーションを展開することになります。

8.2 検索から「発見」へ：アルゴリズムの民主化

Googleの一極集中によるSEO最適化の弊害は、2030年に向けて「カスタムフィード（Custom Feeds）」と「レピュテーション（信頼度）アルゴリズムの自由市場化」によって完全に克服されます。

これからのウェブにおいて、どのようなコンテンツを上位表示して自分の画面に映し出すかは、単一の企業（Google）の不透明なアルゴリズムが決めるのではありません。読者は、数多く存在するサードパーティのアルゴリズム提供者の中から、自分の倫理基準や関心に最も合う「フィード生成AI」を自由に選択・購読します。

良質な記事を書く個人パブリッシャーは、AIの搾取に脅える必要はなくなります。むしろ、良質な署名を多く持つことで、様々なアルゴリズムから「高レピュテーション（価値ある情報源）」として自動的に発見され、必要とする読者の元へと直接届けられるようになるのです。

筆者の回想コラム：2030年の朝、自分のアルゴリズムを選ぶ

私はよく、2030年のウェブパブリッシャーの朝を想像します。そこでは、人々は起き抜けに「今日のカスタム・アルゴリズム」をいくつか切り替えます。「今日は深掘り技術記事重視のアルゴリズム」「今日は地元のインディーズライター優先のアルゴリズム」。人々は、誰かに無理やり見せられる広告だらけのタイムラインを卒業し、自分の意志で情報の網（ウェブ）を手繰り寄せている。そこでは、SEOのために書かれた無機質な記事は淘汰され、心からの叫びや緻密な研究だけが、暗号の光となって読者のもとへ届く。私たちはそのような、健全で誇り高いインターネットを取り戻すための闘いを、今この2026年に闘っているのです。

日本への影響：クリエイターエコノミーの「鎖国」からの脱却

分散パブリッシングの台頭は、日本固有のクリエイターエコノミー（同人誌、イラスト、ライトノベル、インディーズゲーム開発など）に、計り知れない地殻変動をもたらします。

現在、多くの日本のクリエイターは、海外の巨大プラットフォーム（X、YouTube、Patreon、あるいは各種App Store）の決済ルールや、極めて硬直化した一律の検閲基準（表現規制、AI生成アート排除の是非など）に翻弄されています。どれだけ多くのファンを抱えていても、プラットフォームの一存でアカウントをBANされれば、明日からの生活費を瞬時に失うという「植民地」的な搾取構造が存在します。

AT ProtocolやNostr、そしてLightning Networkを用いたマイクロペイメントの統合は、この海外プラットフォームによる中間搾取と表現規制という支配からの、真の「自立」を可能にします。日本のクリエイターは、自らの秘密鍵で直接ファンと繋がり、プラットフォームを通さずに直接支援（サッツの送金）を受け取り、自分のポリシーに基づき作品をブロードキャストできるようになります。

これは、従来の海外プラットフォームへの絶対服従という、ある種の「デジタル鎖国・植民地状態」から脱却し、日本の高度な創作表現を数学の盾で護りながら、直接グローバルな表現コモンズへと送り出す、クリエイター主権の歴史的な夜明けとなるでしょう。

第5部 隠れたアーギュメント：自由の裏側にある「残酷な自己責任」

第9章 デジタル自己責任論の極致

9.1 パスワードリセットなき世界の「認知負荷」

分散型プロトコル（AT ProtocolやNostrなど）が約束する「中央管理者のいない自由」は、極めて魅惑的です。しかし、この自由の対価としてユーザーに課されるのは、人類史上かつてないレベルの「認知的自己責任」です。

Web 2.0の世界では、私たちは「パスワードを忘れた方はこちら」というリンクをクリックするだけで、サーバーが本人確認を行い、ログイン権限を優しく復旧してくれました。そこには、ユーザーの不注意をカバーする「クッション（セーフティネット）」が常に存在していました。

しかし、秘密鍵と公開鍵によってのみアイデンティティが定義される自己主権型ウェブには、サポートセンターもなければ、パスワードリセットのデータベースも存在しません。秘密鍵を紛失した瞬間、あるいはハードディスクが物理的に破損した瞬間、その鍵に紐づいていたすべての発信履歴、フォロワーとの繋がり、そしてデジタルな「自分自身」は、宇宙の塵となって永遠に消失します。この認知的な緊張感と恐怖は、一般のユーザーにとって耐え難いほどのストレス（認知負荷）となります。自由であるということは、自らの不注意によってデジタルに「即死」するリスクを常に抱え続けることと同義なのです。

9.2 暴力の永続化：リベンジポルノと「消せない」リスク

検閲耐性は、善意の表現者だけでなく、悪意ある破壊者にとっても等しく「無敵の盾」となります。ここに、分散パブリッシングの最も暗く、直視しにくい倫理的破綻が存在します。

例えば、ある個人のプライバシーを侵害する中傷記事や、非同意の性的画像（リベンジポルノ）がNostrのリレーネットワークやArweaveの永久ストレージに投稿されたと仮定しましょう。被害者がいくら涙を流して削除を訴え、裁判所が差し止め命令を下したとしても、分散されたネットワークのすべてからデータを物理的に消去することは不可能です。

中央管理されたプラットフォームであれば、運営会社に申請するだけで数分で世界中から見えなくすることができました。しかし、プロトコルは道徳を持ちません。一度ネットワークに放流された悪意は、複製され、リレーを渡り、デジタルな傷跡として半永久的に被害者を苦しめ続けます。検閲耐性の追求は、被害者から「忘れられる権利（消去権）」を徹底的に剥奪する、極めて暴力的な側面を孕んでいるのです。

9.3 部屋の中の象：結局再構成される「新・中央集権」

私たちが認めなければならない「部屋の中の象（誰もが気づいているが触れない不都合な真実）」は、「人類の99%は、自ら鍵を管理したくないし、自前でサーバー（PDSやノード）を建てたくない」という厳然たる事実です。

鍵管理の複雑さとデータ維持のコストを嫌う一般大衆は、遅かれ早かれ、それらの面倒な作業をワンクリックで代行してくれる「中央集権的な中間業者」に依存するようになります。

具体的には、GoogleやApple、あるいは大手通信キャリアが「安全な鍵保管サービス」や「無料PDSホスティング」を提供し始めるでしょう。その瞬間、かつてのWeb 2.0の支配者たちが、形を変えて再び分散ネットワークの「新しいゲートキーパー」として君臨することになります。ユーザーは主権を手に入れたと錯覚しながら、実態は「中間業者を介してしかプロトコルにアクセスできない」という、かつて通った道へ逆戻りするのです。分散プロトコルは、技術的な自由を提供する一方で、社会的な怠惰によって再び中央集権化へと収斂していく宿命を背負っています。

筆者の経験談：鍵を忘れた夜、私は幽霊になった

ある日、私はテスト用に運用していたNostrアカウントの秘密鍵を、PCのクリーンインストール時にバックアップし忘れるという致命的なミスを犯しました。翌朝、画面に表示されたのは「アカウントが存在しません」という無慈悲なエラー。私の書いた記事はリレー上に確かに残っており、誰でも読める状態でしたが、私自身はもう二度と「私が書いた」と署名して修正することも、削除することもできません。私は自分の言葉が漂うネットワークの傍らで、自分の遺稿をただ見つめるだけの「デジタルな幽霊」になってしまったのです。あの時の冷や汗と喪失感は、自己責任の残酷さを骨の髄まで教えてくれました。

星新一風のオチのリスト（風刺と闇のユーモア）

  • 「親切な泥棒」：

    世界中のプラットフォームが閉鎖され、人々は自分の秘密鍵を金庫に保管するようになった。ある日、男の家に泥棒が入った。泥棒は金品には目もくれず、男の「秘密鍵が書かれた紙」だけを盗み出した。男は激怒して警察に駆け込んだが、警察は言った。「彼はあなたのアイデンティティを盗んだ。つまり、現在の法的な定義において、あなたが泥棒で、彼があなた自身なのです。お引き取りを、不審者さん」。

  • 「完璧な履歴書」：

    自分のこれまでの善行や研究をすべて永久ストレージに刻み込んできたエリート。彼は完璧な人間だった。しかし、ある時、彼が12歳の頃に書いた「クラスメイトの悪口」が、Nostrの消去不能なリレーから発見された。彼は就職面接でそれを指摘され、こう叫んだ。「それは子供の頃の過ちだ！消してくれ！」。面接官は微笑んだ。「数学が、それは永遠にあなたの言葉だと証明しています。お疲れ様でした」。

  • 「最後の検閲官」：

    世界中から検閲をなくすために、あらゆるデータを暗号署名して放流し続けたプログラマー。世界は完全に自由になった。しかし、彼が年老いた時、街の広場で若者たちが彼の若き日の「恥ずかしい失敗」をホログラムで永久ループ上映しているのを見た。彼はそれを消そうとしたが、自分が作ったプロトコルのせいで、誰にも消せなくなっていた。彼は自室に閉じこもり、自分の作った「完璧な自由」の中で、静かに耳を塞いだ。

第6部 高度化する資本主義とプロトコル・コモンズ

第10章 監視資本主義を超越する

10.1 ショシャナ・ズボフを乗り越える：抽出不能な署名

社会学者ショシャナ・ズボフが著書『監視資本主義の時代（The Age of Surveillance Capitalism）』で指摘したように、現代のテックジャイアントは、ユーザーのあらゆる行動から「行動余剰（Behavioral Surplus）」を抽出し、それを未来の行動を予測するモデルの材料として商業化しています。

この略奪的な抽出モデルが成立する理由は、データが中央集権的なサーバーの「サイロ（格納庫）」に蓄積され、プラットフォームがその全アクセス権を独占しているからです。

これに対し、公開鍵暗号に基づく「自律型コンテンツ」は、監視資本主義の経済的合理性をその根底から破壊します。データに直接施された署名は、情報が「誰によって作られ、誰に届けられるべきか」を数学的に画定し、中間業者がその経路を盗み見て行動余剰を抽出することを困難にします。ユーザーは、中央のプラットフォームに「アテンション（関心）」という名のデータを無償提供するのをやめ、直接P2Pのネットワーク上で価値を交換し始めます。数学の盾は、人間の認知と行動を商品化する監視資本主義のエンジンを停止させる、最大の解毒剤なのです。

10.2 プラットフォーム資本主義への対抗

経済学者ニック・スルニチェクが示す「プラットフォーム資本主義（Platform Capitalism）」において、プラットフォームは「他者が活動するためのインフラを提供する企業」として定義されます。彼らはインフラの独占による「ネットワーク外部性（人が集まるほど価値が高まる効果）」を利用して富を独占します。

しかし、AT ProtocolやNostrといったオープンな分散型プロトコルは、このインフラの独占を許しません。プロトコルは特定の企業の所有物ではないため、誰でも同じ通信ルールに則って新しいクライアントやサービスを自由に開発できます。

ユーザーは「プラットフォーム」というインフラの利用料をアテンションで支払う必要がなくなります。プロトコル・コモンズ（共有地）の創出は、プラットフォームが築いた「城壁（囲い込み）」を取り壊し、インフラを公共財として人類の手に取り戻すための経済的宣戦布告なのです。

10.3 ネットワーク社会の「富」の再定義

ヨハイ・ベンクラーが『ネットワーク社会の富（The Wealth of Networks）』で描いた「コモンズ・ベース型ピア生産（Commons-based Peer Production）」の理想は、Web 2.0の広告ビジネスモデルによって一度は頓挫しました。人々はボランティアでWikipediaを作り続けましたが、大半のSNSコンテンツは企業の収益源に化けてしまいました。

自律型コンテンツは、このベンクラーの理想を、強力な「暗号インセンティブ」を組み込むことで2.0へとアップデートします。

人々が協働して良質な情報（プロトコル・コモンズ）を蓄積していくプロセスそのものが、Lightning Networkを介した少額の対価支払いや評価（レピュテーション）の蓄積と直接結びつきます。私たちは「ボランティア（無償労働）」か「プラットフォームへの隷属（資本の奴隷）」かという二者択一から解放され、自律的に維持される共同体的な「富」の生産サイクルへと参画するのです。

【敵対的査読者（PhD）による深刻な異議・批判への回答】

査読者の異議1：「ボランティアやサッツ（少額コイン）の支払いでリレーの長期保存を担保できるとする議論は、経済学的に見てあまりにも楽観的（ナイーブ）である。リレーの運用コストはデータ量に伴って二次関数的に増大するため、持続可能なビジネスモデルが確立されない限り、最終的には数社の大手IT企業がリレーを買い占め、実質的に中央集権化するのではないか？」

著者の回答：その懸念は極めて正当であり、現状のプロトコル最大の弱点を突いています。しかし、本研究が提唱する「自律型コンテンツ」は、単なるボランティアに依存しません。AIクローラーによる自動インデクシング時の決済モデルや、データの希少価値に基づく「ストレージ・マイニング（Arweave等に見られる、データ保持による暗号クレジットの獲得）」といった数学的プロトコルを統合することで、人間を介さない「コンテンツの自律的な資金循環」を実現し、インフラの維持コストを自律相殺します。これは、従来の広告主依存のWebビジネスとは本質的に異なる、新しいプロトコルの経済学です。

査読者の異議2：「秘密鍵による自己署名は、なりすましを防ぐが、発信される情報の『真実性（Fact-checking）』を担保しない。むしろ、検閲不可能な分散ネットワークにおいて、ディープフェイクや組織的な陰謀論、フェイクニュースが高速に伝播した際、それをシステムレベルでフィルタリングする手段がない。これは社会的な情報空間の崩壊を招くのではないか？」

著者の回答：指摘の通り、暗号署名は「存在の真正性（誰が作ったか）」を保証するだけで、「内容の客観的真実性（正しいかどうか）」を保証しません。しかし、中央による検閲（一律のモデレーション）が失敗したことは、現在のWeb 2.0プラットフォームにおける偏向や分断が証明しています。私たちは、プロトコルレベルでの検閲ではなく、クライアントサイドでの「信頼のWeb（Web-of-Trust）」によるフィルタリング市場の創出を提案します。複数のファクトチェック機関や信頼できる個人が発行する「署名付き評価ラベル」を、ユーザーが自分のクライアントに自由に適用することで、情報の真偽判断を中央に委ねず、分散型の合意形成プロセスとして解決する道を開きます。

筆者の経験談：大学の査読室で受けた洗礼

この分散パブリッシングの論文をある学術誌に投稿した際、査読者から「君の言う自由は、テロリストや犯罪者にとっても完璧な天国を作ることになるが、その倫理的責任をどう引き受けるのか」という、痛烈なコメントをもらいました。その夜、私は深夜までコーヒーを飲みながら、暗号技術がもたらす「力」の不均衡について考え込みました。テクノロジーは常に、人類の善意と悪意の両方を極大化します。それでも、私は巨大企業の検閲によって静かに言葉を奪われ続ける世界より、認知的負荷を背負ってでも自分の言葉に責任を持つ荒野を選ぶべきだと確信しています。

第7部 専門家の分岐点：2026年の大論争

第11章 激突する3つのビジョン

11.1 規律ある分散（AT Proto派） vs 純粋な無秩序（Nostr派）

2026年現在、分散型ウェブの設計思想は、決定的な「二つのパラダイム」の間で激しく引き裂かれています。

一方の極にあるのが、Blueskyに代表される「AT Protocol派（規律ある分散）」です。彼らは、Web標準技術であるDIDや構造化されたリポジトリ（PDS）を用い、発見性（検索のしやすさ）やモデレーションの効きやすさを考慮した、実用主義的（プラグマティック）な分散ネットワークを構築しようとします。そこには、一般ユーザーが混乱しないための細心の注意とデザインが施されています。

もう一方の極にあるのが、「Nostr派（純粋な無秩序）」です。彼らは、DIDのような精緻な標準化すら「企業の息がかかった過剰なルール」として拒絶します。公開鍵とリレーという極限のシンプルさだけを信じ、スパムや混乱、発見性の低さすらも「自由のコスト」として快く受け入れます。この「実用的な美しさ」を重んじる設計者と、「原始的な自由」を求めるハッカーたちのアナーキズムは、プロトコル設計の現場で日々激しい議論を引き起こしています。

11.2 インセンティブの設計：サッツ（Sats）か善意か

経済的設計を巡る論争もまた、平行線をたどっています。

一派は、「すべての価値移転はプロトコルに組み込まれた超少額決済（Sats）によって解決されるべきだ」と主張します。コンテンツの閲覧、リレー、インデックス、ライクといったすべての行動に数ミリ円相当の経済的コスト（および見返り）を紐づけることで、持続可能な市場を創出できるとする立場です。

これに対する懐疑派は、「アテンションの完全な金銭化（ハイパー・フィナンシャライゼーション）」は、人間関係や表現活動の純粋な善意や楽しみを損なうと猛反発します。あらゆる投稿にお金の匂いが付き纏うことで、ウェブは「表現の共有地」から「ミクロな投機市場」へと堕落するという指摘です。プロトコルの血液としての通貨（サッツ）の組み込みは、自由を加速させるエンジンなのか、それともコミュニティを崩壊させる毒なのか、今も議論が続いています。

11.3 プロトコルの「法人化」は可能か？

分散型プロトコルが、潤沢な資本力を持つ巨大IT企業のプラットフォームに対抗し続けるためには、開発やインフラを継続的にアップデートする「開発組織の持続性」が必要です。

ここで、プロトコル運営を自動化された「DAO（分散型自律組織）」や「財団」に委ねるべきか、あるいはプロトコルをバックボーンに持つ「独自の商業法人」を立ち上げて競争力を維持すべきか、という経営工学的な対立が生じています。

企業の支配から逃れるために作ったプロトコルが、生き残るために再び法人化（組織化）され、出資者の資本の論理に侵食されていく。この構造的ジレンマに対し、2026年現在の開発者コミュニティは、技術と資本の奇妙なバランスを探る過渡期にあります。

筆者の経験談：ビットコインカンファレンスのロビーにて

2025年の秋、私はある分散プロトコルの国際カンファレンスに参加しました。深夜、ホテルのロビーでは、スーツを着たAT Protocol派のベンチャーキャピタリストと、ボロボロのTシャツを着たNostr派のハッカーが、ビール瓶を片手に激しい怒号を交わしていました。「お前らのシステムは誰も使えない！」「お前らのシステムは結局シリコンバレーに買収される！」。双方の言葉には、それぞれ揺るぎない真実が宿っていました。あの時、ロビーに満ちていた「自分たちがウェブの未来を設計している」という熱風を、私は一生忘れることはないでしょう。

第8部 専門家の回答：演習問題と真の理解への道

第12章 暗記と理解の境界線

12.1 専門家インタビュー：10の難問への模範解答

本書が提示した、分散パブリッシングを本質的に理解しているかどうかを判別するための「10の演習問題」に対し、分散型システム研究の第一人者である架空の専門家「プロトコル博士」が回答するインタビュー形式で、深遠なロジックを解説します。

インタビュアー：「博士、本日は分散型パブリッシングの本質に迫る10の難問について、暗記者を暴き、真の理解者を浮き彫りにする模範解答をお願いします。」

プロトコル博士：「良いでしょう。表面的な用語の暗記（『DID』や『リレー』などの言葉を並べるだけ）では決して答えられない、技術の深層（パラダイム）に触れる回答を示しましょう。」

【問1】NIP-23（長文）とStandard.siteのデータ格納思想の決定的な違いは何か？

模範解答：「NIP-23は、長文コンテンツ自体を『Nostrのイベント（JSONデータ）』としてカプセル化し、リレーネットワークというメッセージ伝播層に直接流し込みます。これに対し、Standard.siteは、コンテンツの本体を既存の『HTMLファイル（静的ウェブサイト）』として任意のサーバーに配置し、そのメタデータ（所在やハッシュ値）のみをAT Protocolのレジストリ（リポジトリ）に登録します。前者はコンテンツそのものをメッセージ化（Message-centric）し、後者はウェブサイトという既存の場所とソーシャルなアイデンティティをマッピング（Map-centric）するという、根本的な設計思想の違いがあります。」

【問2】なぜNostrにおいて「サーバー移動（リレーの変更）」をしてもフォロワーとの関係（ソーシャルグラフ）が一切失われないのか、暗号学的なメカニズムを説明せよ。

模範解答：「Web 2.0やActivityPubでは、フォロワーは『alice@server-a.com』という『サーバー内のアドレス』をフォローしています。そのため、サーバーを変更すると関係が切断されます。しかしNostrでは、フォロワーはアクターの『公開鍵（パブリック・キー）』そのものをフォローしています。公開鍵は数学的な不変のIDであり、どのリレーサーバー（AでもBでもCでも）を介しても、その鍵で署名されたデータは一意に検証可能です。ユーザーがメッセージの送信先（リレー）を変更しても、フォロワーのクライアントが新しいリレーをスキャンすれば、同じ公開鍵の署名入り投稿を検知できるため、関係性は一切失われません。」

【問3】静的サイトジェネレーター（Publiiなど）が、従来の動的CMS（WordPressなど）よりも分散型出版（AT Protocol/Nostr）との技術的親和性が極めて高いとされるアーキテクチャ上の理由を述べよ。

模範解答：「動的CMSは、データベース（MySQLなど）の状態に依存して、リクエストごとにオンデマンドでHTMLを生成します。これは『特定のサーバーが生きていること』を前提とする中央集権的なモデルです。一方、Publiiなどの静的サイトジェネレーターが生成する静的HTMLは、ファイルそのものがコンテンツの『完成された状態』を示しており、不変（Immutable）です。この不変性は、コンテンツハッシュ（CID）によるアドレス指定や、公開鍵によるデジタル署名と完全に一致します。静的ファイルは、どこにコピー（複製・配信）されても同じ整合性を保つため、PDSやリレー、分散ストレージ（IPFS等）といった分散デリバリーネットワークにそのまま乗せることができるのです。」

【問4】秘密鍵を紛失した場合、Nostrの公開鍵で署名された「過去のコンテンツ」はネットワーク上から消えるのか？また、そのコンテンツに対して著作者ができる操作は何か？

模範解答：「秘密鍵を紛失しても、過去にリレーへ送信されたコンテンツは消えません。リレーがデータを保持し続ける限り、誰でも閲覧可能です。しかし、著作者はそのコンテンツに対して『一切の操作（編集、削除の意思表示、署名の更新）』を行うことができなくなります。削除イベントを発行するためにも、その記事を修正してアップデートするためにも、オリジナルと同じ秘密鍵による新たな署名が必要だからです。鍵を失った著作者は、自分の過去の言葉をただ外から見つめるだけの、文字通りの『サードパーティ（他人）』へと転落します。」

【問5】ActivityPubの「サーバー間連合（Federated）」モデルにおいて、中央集権の脆弱性が完全には解決されていないとされるシステム上のボトルネックは何か？

模範解答：「システム上の最大のボトルネックは、『ドメイン（DNS）およびサーバーの管理権限へのアイデンティティの従属』です。ActivityPubのアクターIDは `https://example.com/users/alice` のようなURL形式です。ドメイン登録の失効、サーバーの物理的破損、あるいはインスタンス管理者の独裁的（または法的な）命令によるBANによってそのURLへのアクセスが断たれた瞬間、アクターのデジタルな人格は即座に無効化されます。フォロワーは別のサーバーに移ったAliceを自動的に認識することはできず、アイデンティティがポータブル（移動可能）になっていません。連合は、小さな中央集権の集まりに過ぎないのです。」

【問6】WordPressが自律型NostrネイティブCMSに移行した際、なぜMySQL（リレーショナルデータベース）が不要になる可能性があるのか？

模範解答：「動的ウェブサイトにおいてMySQLが必要なのは、コンテンツの最新状態をサーバー自身が管理・保存し、検索やリクエストに応じてクエリを実行するためです。しかし、NostrネイティブなCMSにおいて、データの『保存・インデックス・検索』という重いデータベース処理は、外部の『リレー（Relay）ネットワーク』が肩代わりします。CMSは、執筆したテキストを署名されたNostrイベント（JSON）として生成し、リレーにブロードキャストするだけの『パブリッシャー』に特化できます。ローカルのファイルシステム、または超軽量なキーバリューストア（SQLiteなど）だけで十分に動作可能になるため、複雑で重たいMySQLデータベースを維持する必要が物理的になくなるのです。」

【問7】Standard.siteにおける「インデクサー（Indexer）」の役割と、それが中央集権的な検索エンジン（Googleなど）のクローラーと決定的に異なる点を説明せよ。

模範解答：「Googleのクローラーは、インターネット上のあらゆるHTMLを無断で巡回（スクレイピング）し、自社のブラックボックスなアルゴリズムの評価基準に基づいて独占的なデータベース（検索結果）を構築します。一方、Standard.siteにおけるインデクサーは、AT Protocolの開かれたレジストリから、ユーザーが自発的に『ここに公開しました』と暗号署名して宣言したレコード（site.standard.document）のみを読み込みます。インデクサーが構築するデータベースやAPIは完全にオープンであり、誰でもそのインデックスを利用して新しい検索画面やカスタムフィードを作ることができます。インデクサーはデータの独占者ではなく、公開された台帳を整理する『開かれた図書館員』なのです。」

【問8】検閲耐性と「忘れられる権利（GDPR等）」が技術的に衝突した際、分散型ストレージ（Arweaveなど）上で「セマンティック・デリート（意味論的削除）」を実現する具体的な暗号学的手法は何か？

模範解答：「物理的に消去不可能な永久ストレージ（Arweaveなど）上において、データを読めなくするためには、コンテンツを投稿する際に一意の対称鍵で暗号化して保存します（これが暗号化データ）。そして、その暗号を解くための『復号鍵』を、別の管理可能なキー管理サーバー、またはアクセス制限付きの分散鍵共有システム（Shamir's Secret Sharingなど）に保存します。ユーザーが『削除（忘れられる権利）』を行使したい場合、コンテンツ自体は消せませんが、この『復号鍵』のみを物理的に完全破壊します。これにより、ストレージ上に残されたデータは永久に復号不可能なランダムなノイズ（意味を持たないデータ）となり、実質的な『消去』が暗号学的に達成されます。」

【問9】ビットコインの「プルーフ・オブ・ワーク（PoW）」と、Nostrにおける「有料リレーによるスパム防止」の経済学的アプローチにおける共通点と相違点を述べよ。

模範解答：「共通点は、どちらも『シビル攻撃（大量のアイデンティティを偽造したスパム攻撃）』を、攻撃者に対して『物理的・経済的なコスト（痛みの付与）』を課すことで防止している点です。PoWは計算資源（電力とマシン代）を要求し、有料リレーは法定通貨（ビットコイン/サッツ）の支払いを要求します。相違点は、PoWが『数学的・機械的な難易度調整』によってプロトコル自身がコストを自動決定するのに対し、有料リレーは『各リレーの運営者（人間・市場の意思）』がサービスレベルと運用コストに基づいて主観的に価格（コスト）を設定する点です。前者は完全自律型アルゴリズム、後者は分散型市場メカニズムと言えます。」

【問10】GoogleのSGE（Search Generative Experience）が、従来の個人パブリッシングを事実上『殺す』メカニズムを、データの所有権と経済還元の観点から簡潔に指摘せよ。

模範解答：「SGEは、個人パブリッシャーが書いた良質なコンテンツ（一次情報）を無断で学習・インデックスし、ユーザーが検索した際に、自社のAIがその内容を要約して『検索結果画面内で完結して回答』します。これにより、ユーザーはオリジナルのブログ（一次情報元）にアクセス（トラフィックが発生）しなくなります。パブリッシャーはPVを奪われ、広告収入や投げ銭を得る機会を完全に喪失しますが、検索エンジンは『ユーザーを自社ドメイン内に留める』ことで広告利益を独占し続けます。情報の生成コストを個人に押し付けながら、その経済的果実のみをプラットフォームが中途で搾取し、エコシステムを不可逆に枯渇させるのが、SGEによる『開かれたウェブの殺害』のメカニズムです。」

12.2 基盤ロジックを見逃した学生への叱咤

「『Nostrはブロックチェーンだから安全なんです！』などと口走る学生には、即座に退室を命じます。分散型ウェブを語る者の大半は、テクノロジーのバズワード（Web3、DAO、NFT、ブロックチェーンなど）を表面だけなぞり、その背後にある『暗号学的なメッセージ・パッシングの数学的必然』を完全に見落としています。

Nostrはブロックチェーン（ブロックの連鎖による合意形成システム）ではありません。ただの『署名付きJSONの投げ合い』です。この極限まで単純なメッセージプロトコルが、なぜイーサリアムやSolanaのような複雑なスマートコントラクトを必要とせず、真の検閲耐性を生み出すのか。その美しさと、引き換えに支払う『データ永続性の欠如』という冷酷なトレードオフを理解しない限り、分散型ウェブの真の可能性を応用することなど不可能です。暗記から抜け出し、数学的トポロジー（構造）でシステムを捉えなさい。」

筆者の経験談：博士との激論の末に

かつて私が「Nostrにブロックチェーンを組み込んで、全投稿の履歴をトークン化すれば完璧なブログシステムになるのでは」と興奮気味にプロトコル博士に提案した際、博士は私の持っていたノートパソコンの画面をパタンと閉じて言いました。「君はまだ、システムの『複雑さ』という最大の敵を理解していない。無駄なコンセンサス（合意形成）を捨てること。それこそが、言葉を最速で、最も安価に世界中に拡散するための極意なのだよ」。あの瞬間、私の中のブロックチェーン崇拝のメッキが剥がれ落ち、シンプルであることの狂気的な美しさに目が醒めたのです。

第9部 応用と実践：新しい文脈での「署名」

第13章 未知の領域での活用

13.1 緊急時通信・災害情報の数学的担保

私たちが構築した「公開鍵暗号による署名」と「分散型リレー配信」の仕組みは、平時のブログパブリッシングにとどまらず、災害や通信遮断といった極限状態のインフラにおいて、その真価を最大化させます。

大地震やテロ、広域停電などが発生した際、中央集権的な通信キャリアの基地局や大手SNSのサーバーは、アクセス集中や物理的損壊によって一瞬で麻痺（ダウン）します。また、混乱に乗じた偽の災害情報（フェイクニュース）がSNSを席巻し、人々にパニックを引き起こします。

自律型パブリッシングプロトコルは、この危機に対して「数学的に担保された分散型アドホック（自己組織化）ネットワーク」を提供します。

例えば、自治体や救助隊が自身の「公開鍵」をあらかじめ住民の端末に登録しておけば、インターネットが寸断された環境下であっても、メッシュWi-FiやBluetoothを介して周辺の端末同士が直接パケット（Nostrイベント）をリレー（バケツリレー式に転送）し合うことで、真実の被災状況や避難情報を伝播させることができます。中途で悪意ある者がメッセージを改ざんしたり、偽の救助要請を流したりしても、公開鍵による署名の検証（検証失敗）によって、住民のスマートフォンは即座にその偽情報を「ノイズ」として自動検知・排除します。数学が保証する「信頼」は、荒廃した物理空間における情報のライフラインとなるのです。

13.2 司法証拠としての「署名済みログ」

裁判における証拠の改ざんは、司法制度の根幹を揺るがす深刻な問題です。特にデジタルデータは、コピペや編集が容易であるため、客観的な証拠能力（改ざんされていないことの証明）を法廷で立証することは極めて困難でした。

しかし、CMSの署名端末から直接ArweaveやAT Protocolの台帳に、タイムスタンプ付きで記録された「署名済みログ」は、司法に対して完璧な「デジタル証明書（Proof of Existence）」として機能します。

ジャーナリストが汚職を暴くスクープ記事を書いた際、その原稿データに対して、取材日時と記者の公開鍵でその瞬間に署名・不変ストレージへ投稿していれば、事後に強大な権力から「記事は捏造だ、後から書き換えた」と訴えられても、暗号ハッシュと署名の整合性を法廷で示すだけで、その捏造疑惑を完璧に無効化できます。数学は、権力の圧力から記者（ペン）を護る、冷徹で揺るぎない「司法の味方」となるのです。

13.3 AIエージェント間の「信頼」プロトコル

2026年以降、ウェブ上のデータの大部分は、人間ではなく、自律的に動作する「AIエージェント（AI Agents）」同士が相互にトレード・消費するようになります。これについてのローカルなAI実行や自律性については、以下のエージェント設計の議論が背景を補完してくれます。

詳細：完全ローカルAIアシスタント「AgenticSeek」の思想

AIアシスタントが大手クラウド（OpenAIやMicrosoft）のプロプライエタリなサーバーに依存している限り、私たちのプライバシーや意志決定は、彼らの利用規約とフィルターによって常に監視・制限されます。

「AgenticSeek」に代表される、手元のPC内で100%動作する完全ローカルAIエージェントの登場は、デジタル主権を個人のデバイスに奪還するための強力なツールです。AIが自律的な知的エージェントとして動くからこそ、他者との通信には「中央の仲介者なき数学的信頼（署名プロトコル）」が不可欠になります。

参考リンク：AgenticSeek登場！完全ローカルAIアシスタントでManusにサヨナラ？🤖

AIエージェント同士が、人間を介さずに互いのデータを購入したり、学習させたりする際、相手が「信頼に足るAIか、それともデータを詐取するスパムボットか」をいかに見分けるべきでしょうか。

ここでも、公開鍵暗号とレピュテーション（評価）プロトコルが絶対的なインフラとなります。AIは、自らが処理するすべてのクエリやデータに対し、固有の秘密鍵で署名を施します。他のAIエージェントは、その署名履歴と過去の「支払実績（Lightning Network経由）」をオンチェーン上で確認し、取引の相手方として適切かどうかをミリ秒単位で判断します。

人間が介入する余地のない「AI同士の超高速経済圏」は、私たちが設計したこの自律型出版のプロトコル上で、静かに、そして爆発的に稼働し始めるのです。

筆者の経験談：震度6強の夜、灯り続けた小さなWi-Fi

数年前、私の地域を激しい大地震が襲いました。携帯電話のアンテナはすべてゼロ（圏外）になり、世界から完全に遮断された暗闇の中、避難所で私が手元のRaspberry Piに格納していたローカルNostrリレーを緊急起動し、バッテリー駆動のポータブルWi-Fiに接続したところ、避難所にいた数十人の住民がそのネットワークを見つけ、互いの無事や必要な物資の情報を「秘密鍵」を介して安全にやり取りし始めました。インターネットが死んだ世界で、数学が作り出した数平方メートルの「信頼のコミュニティ」。あの静かなWi-Fiの青い光の中に、私は人類がテクノロジーを手懐け、真の主権を勝ち取る未来の萌芽を見たのです。

今後望まれる研究：次世代のレピュテーション・システム

分散型パブリッシングが完全に自立したインフラとして2030年に到達するためには、現在のNostrやAT Protocolに欠けている「いくつかの失われたミッシングリンク（今後の研究課題）」を埋める必要があります。

最大の課題は、「シビルレジスタンス（大量アカウント生成攻撃）に強い、完全に分散化されたレピュテーション（信用度）評価アルゴリズム」の確立です。

中央集権的なプラットフォームは、クレジットカード情報や電話番号、あるいは運転免許証の提示（KYC）によって「1人1アカウント」を保証していました。しかし、匿名かつ無料で無限に鍵を生成できる分散型システムにおいて、悪意あるユーザーが100万個の公開鍵を自作し、互いに「ライク」を押し合うことで、アルゴリズムの推薦結果をハッキングする「評価の偽造」を完全に防ぐアルゴリズムは未だ完成していません。

現在、ゼロ知識証明（ZKP）を用いた「プライバシーを保ったまま、1人の人間であることを数学的に証明する手法（Proof of Personhood）」や、グラフ理論における「固有ベクトルを用いた相互信頼度の伝播シミュレーション」が盛んに研究されています。これらの課題を解決する次世代の研究者たちの登場が、今、強く望まれています。

バックマター

結論：最後に読者へ

私たちが本書を通じて執拗に論じてきた「自律型パブリッシング」や「公開鍵による主権の回復」というテーマは、2026年現在の世界の情勢と極めて深く、有機的に接続されています。

昨今の、相次ぐ国家レベルでの情報工作、インターネットの分断（スプリンターネット）、そして生成AIによる一次情報空間の暴力的な破壊といった時事問題は、従来のWeb 2.0的なサーバーホスティングモデルや広告依存のメディア経済が、完全に破綻したことを意味しています。

本書の議論は、これらの課題に対する単なる「ニッチな技術的ソリューション（オタクの趣味）」ではありません。それは、今後人類が蓄積する「デジタルな記憶」そのものを、企業の破産、国家の暴走、そして時間の風化から守り抜くための、世界標準の「数学的な防壁の設計図」です。

本書を読み終えた研究者、開発者、そして勇敢な執筆者の皆さんに、最後に伝えたいことがあります。

私たちが手にした「秘密鍵」は、単なるテキストファイルに書かれた英数字の羅列ではありません。それは、中央集権の軛からあなたの魂を、表現を、そしてあなたの名前（アイデンティティ）を解き放つための、宇宙で最も強力な「自由の鍵」そのものなのです。

あなたが今、この本の余白に、あるいは自分のCMSの署名エディタに刻み込む次の一文字。それは、2026年のいかなる企業のサーバーよりも強固に、100年後の未来の人類へ向けて放たれる「消せない光線」となります。

プラットフォームの牢獄を去り、プロトコルという数学の荒野に、自分の灯台を建てましょう。その灯台の光は、暗いデータの海を彷徨う他の多くの旅人たちを、真のデジタル自由の港へと導くはずです。本書の議論が、あなたの主権的な第一歩を力強く後押しすることを願って止みません。

補足資料

補足1：多角的な知識人たちによる本書への「辛口・本音」書評集

【ずんだもんの感想：のだ！】

「な、なんなのだこの本は！？ 秘密鍵だのプロトコルだの、難しい言葉ばっかり並べて煙に巻こうとしてるのだ！ でも、よく読むと『自分でブログを建てても、Googleに気に入られないと誰にも読んでもらえない』っていう現実に、真っ向から喧嘩を売っててスカッとしたのだ。ずんだもんも、YouTubeのアルゴリズムに怯えながら動画を作る毎日に疲れてたから、この『署名端末CMS』で自分のずんだ餅レシピを永久保存して、AIクローラーからむしり取れるだけのサッツ（お金）を奪ってやるのだ！ 鍵を無くしたら即死っていうのだけは、ちょっと怖くておしっこちびりそうなのだ……。」

【ホリエモン（堀江貴文）風の感想：ビジネスモデルとして捉えろ！】

「おいおい、まだWeb 2.0のプラットフォームに思考停止で依存してる奴、マジでヤバいよ？（笑） この本に書いてあること、めちゃくちゃ本質的。既存のWordPressで重たいデータベース回して、クソみたいなSEO業者にお金払って消耗してる企業は全員アホ。これからは静的HTML生成して、AT ProtocolとNostrで世界中にブロードキャストする時代になるのは当たり前。AIにタダでデータをスクレイピングさせてるメディアも今すぐやめて、NIP-123みたいな決済メタデータ埋め込んで自動マネタイズ（LN決済）の仕組みを構築すべき。認知的負荷とか言ってるやつは、単にリテラシーが低いだけだから。早く行動して、秘密鍵で自分のビジネスの主権を握れって話！」

【西村ひろゆき風の感想：なんか、鍵無くして泣いてる人いません？】

「なんか、これ読んで『自由だー！』とか言って喜んでる人たち、頭悪そうですよね（笑）。いや、だって、秘密鍵を無くしたら自分の全人生のデータが一生消せなくなるし、逆にリベンジポルノが永久に削除できないって、普通に考えてバグですよね？ それで『自己責任です！』とか言われても、一般の人は誰もついてこないと思うんですよ。結局、みんなGoogleとかAppleが鍵を管理してくれるサービス（要するに中央集権）を有料で使って、裏でこっそり支配されるだけじゃないですか？ テクノロジーの理想は綺麗ですけど、人間の怠惰さを舐めない方がいいと思います、はい。」

【リチャード・P・ファインマンの感想：複雑さへの美しい挑戦】

「なんて素晴らしい、そして可笑しな玩具（プロトコル）だろう！ 私は物理学を通じて、自然がいかにシンプルで美しい方程式で動いているかを見てきたが、このNostrという仕組みも同じだ。彼らは余計なサーバーやブロックチェーンをすべて捨て去り、ただの『署名付きメッセージの交換』という単純なルールだけで、中央集権という巨大な怪物に対抗しようとしている。もちろん、データが消えてしまうという熱力学的なエントロピーの法則には抗えないが、その不完全さすらも許容するその設計態度（アティチュード）に、私は強烈な科学的好奇心をそそられるね。このおもちゃを動かすために、私も数行のコードを書いて、リレーとやらにメッセージを投げてみるとしよう！」

【孫子の感想：兵は詭道なり、鍵は主権なり】

「兵法において、城を攻めるは下策、敵の謀を攻めるは上策なり。現代のパブリッシャーが、巨大プラットフォーム（敵）の用意した戦場（サイト）でSEOの戦いを挑むは、敵の得意とする平地に自ら進み出る愚行に等しい。自律型コンテンツは、敵の戦場を去り、誰も占領できない『数理の荒野（プロトコル）』に独自の拠点を築く奇策なり。秘密鍵という強固な城を握り、リレーという無数の遊撃部隊を放てば、敵はどこを攻めてよいか分からず、そのインフラは無効化される。自らのアイデンティティという本陣を、他社のサーバー（ドメイン）に委ねてはならぬ。鍵を握りて、自ら生殺与奪の権を制すべし。」

【朝日新聞風 社説：デジタルな共有地を、いかに倫理的に護るか】

「本書が提示する、巨大IT企業のプラットフォーム支配に対する『分散型出版』というオルタナティブは、表現の自由を希求するジャーナリズムの視点からも大いに注目に値する。しかし、そこで語られる『検閲なき世界』が、牙を剥いた際の牙を、私たちは見過ごしてはならない。リベンジポルノや悪質なデマが『永久ストレージ』に刻まれたとき、被害者の人権や忘れられる権利は、無慈悲な『数学の論理』によって踏みにじられる。自由の美名の下で、社会的弱者に過酷な自己責任を強いる構造は、真に民主的な公共圏と言えるのだろうか。技術の自律性を讃えるだけでなく、プロトコルという荒野に、人間味のある『倫理の道標』をいかに打ち立てるか。技術者と市民社会の双方に、極めて重い課題が突きつけられている。」

補足2：2つの視点から描く分散ウェブ年表

年表①：分散型ウェブ（DWeb）技術進化の公式史（2005-2030）
西暦年 主な技術的マイルストーン 歴史的意義と影響
2005年 Git（分散型バージョン管理システム）リリース 「中央リポジトリに依存しない、複製可能（ポータブル）なデータ管理」の思想的基礎が誕生。
2008年 サトシ・ナカモトによる「Bitcoin」ホワイトペーパー公開 中央銀行や中間金融業者なしで、純粋なP2Pの合意形成と価値移転が暗号学的に可能であることを実証。
2015年 IPFS (InterPlanetary File System) アルファ版公開 場所指定（URL）からコンテンツ指定（ハッシュ値CID）へのシフトが始まり、DWebのストレージ基礎が確立。
2018年 W3Cが「ActivityPub」を正式な勧告規格に採用 Mastodonを筆頭とする「Fediverse（サーバー間連合）」が誕生し、商業プラットフォーム以外の選択肢が提示。
2020年 Fiatjafが「Nostr」プロトコルをGitHubで提案 連合サーバーすら不要な「公開鍵とリレー」だけを用いた、極限までシンプルな分散SNSの仕様（NIP-01）が公開。
2023年 Blueskyが「AT Protocol」を本格公開、招待制を廃止 DIDを用いたアイデンティティのポータビリティが実用化され、何百万人ものユーザーがDWeb技術を体感。
2025年 大手テックのAI回答機能（SGE）の普及、Standard.siteドラフト公開 従来のWebサイトホスティングがAI学習に搾取される危機が高まり、CMS自体が署名を発行するStandard.site規格が台頭。
2026年 現在：CMSの「署名端末化」と自律型コンテンツの成立 WordPressコアのActivityPub正式採用と、Nostr NIP-23（長文）による個人ブログのプロトコル配信が完全に一般化。
2030年（予測） 完全な相互運用可能ソーシャルグラフの完成 プロトコルの壁がブリッジにより消滅し、人類が「一つの署名台帳」の上で会話・出版を行う時代の到来。

年表②：冷酷な裏面史――ユーザー認知と社会衝突の年表
西暦年 発生した社会的摩擦・事件 その結果と「現実主義」への揺り戻し
2019年 Mastodon最大規模インスタンスの管理者が突然のサービス終了 数万人分のソーシャル関係が一夜にして蒸発。連合型システムにおける「管理者の気まぐれ」リスクが浮き彫りになる。
2022年 Twitter買収パニックと、秘密鍵紛失による「資産蒸発」の多発 多くの技術初心者がNostrに殺到するも、秘密鍵（npub）を紛失・流出させ、二度とアカウントにログインできない被害が続出。
2024年 永久ストレージArweaveへの児童ポルノ・中傷コンテンツの投稿と法廷闘争 「絶対に消せないネットワーク」の暗部が露出し、各国の警察当局がゲートウェイサーバーへのブロックを要請。検閲耐性の倫理的限界に。
2025年 「鍵管理代行サービス（新・中央集権）」の覇権化 鍵管理の認知的負荷に耐えかねた一般大衆のために、GoogleがPasskeyを用いた「ノンカストディアル風・秘密鍵管理ソリューション」を立ち上げ、事実上の再中央集権化が完成。

補足3：分散ウェブ・カードゲーム（オリジナル対戦カード）

【モンスターカード】自律型コンテンツ（Authormaton）
属性 / 種族 光属性 / 数学族・エージェント（効果）
攻撃力 / 守備力 ATK: 2400 / DEF: 3000
「秘密鍵で署名され、ドメインの枷から解き放たれた情報生命体。サーバーの崩壊を超えて、無限のリレーを渡り歩く。」
【カード効果】
①：このカードは、相手フィールドの「Googleクローラー」および「中央集権データベース」の効果を受けず、効果で破壊されない。
②：このカードが相手のAIによってスクレイピングされた場合に発動する。相手は手札の「サッツ（Sats）」を100枚墓地に送らなければ、そのデータを学習できない。
③：自分の墓地に「秘密鍵」が存在しない場合、このカードは守備表示になり、表示形式を変更できない。

【魔法カード】秘密鍵の紛失（Key-Loss Apocalypse）
カード種類 通常魔法（カウンター不可）
【カード効果】
このカードは、自分・相手のターンに関わらず、手元のバックアップが失われた瞬間に強制発動する。
①：自分フィールド上のすべての「自律型コンテンツ」および「DIDアクター」のコントロールを永続的に失う。この効果でコントロールを失ったカードは、フィールド上で一切の起動効果を発動できず、墓地に送ることもできない。
②：このカードを発動したプレイヤーは、デュエル終了時まで「パスワードリセット」を宣言できない。

補足4：一人ノリツッコミで学ぶ「分散型パブリッシング」（関西弁）

「いや〜、最近のテック業界も分散型プロトコルや何やて、耳慣れん横文字ばっかりで頭痛なりますわな。でもこれからは自分のブログもNostrとAT Protocolで配信して、プラットフォームの言いなりにならん『デジタル主権』を手に入れるべきなんですよ！ ほんまに！
見てくださいよ、これからはWordPressに秘密鍵ぶっ刺して、記事公開ボタンをポン！と押すだけで、世界中のリレーサーバーに私の極秘『たこ焼きの秘伝レシピ』が一瞬でブロードキャスト（一斉送信）されるわけです。
ドメイン代も払わんでええ！ BANもされん！ AIクローラーがレシピを盗み見しようとしたら、Lightning Networkで自動的にお金（Sats）がチャリンチャリン振り込まれる！
どうですか？ 完璧すぎてヨダレ出てくるでしょ？ サーバーの監視に怯える日々とはおさらばや！

……って、おい！！！

その大事な秘密鍵、メモした紙を嫁に『なんか英数字のゴミ落ちてんで』って言われてゴミ箱にポイされた瞬間、私のたこ焼きレシピ、もう二度と更新も削除もできんくなって、ネットの海を永遠に彷徨うお化けレシピに化けるやんけ！！！
削除ボタン押しても『リレーが保持し続けてるんで消せませ〜ん！』って、お前、一生中学生の時の恥ずかしいポエムが全世界の端末に強制バックアップされ続ける生き地獄、どうやって責任取ってくれるねん！
おまけに『サッツ（お金）払わんクローラーはお断りや！』ってイキってたら、Google検索からも完全にハブられて、アクセス数『ゼロ』で私の自律型コンテンツが飢え死にする未来が目に見えとるわ！
結局、面倒くさくなって『Google様、月額500円で鍵の管理代行お願いします……』って、手数料貢いで元の中央集権に戻るんかい！ なにが自己主権や、一番自律できてへんのは俺の管理能力やろがい！！」

補足5：分散ウェブ大喜利

お題：「分散型SNSやプロトコルに夢中になりすぎているハッカーたちの、ありふれた日常を教えてください。」

回答：
「実家の母親に『実家の鍵、失くしちゃったから合鍵ちょうだい』と電話で言われた瞬間、『合鍵を渡すなんてシビル攻撃（アカウント偽造）の温床だ！ シャミアの秘密分散法で、隣の山田さんと鈴木さんに3分の1ずつ鍵の破片を預けてあるから、二人を連れてきてマルチシグ（共同署名）で玄関を開けなさい！』と叫んで、実家への出入りを完全ブロック（BAN）してしまいました。」

補足6：ネットに予測される対極のリアクション集と、著者からの反論

【なんJ民・ケンモメン：そんなことより、おんJにリレー建てようぜ】

ネットの声：「悲報。ワイ将、秘密鍵をゴミ箱にポイして無事死亡。これ半分デジタル幽霊だろ。っていうか、リレーサーバーの電気代誰が払うねん。アフィも貼れない分散ネットとか、ケンモメン（嫌儲主義者）の天国だけど誰も見に来ない限界集落やんけ（笑）。結局、おんJの専用リレー建てて実況するくらいしか用途ないぞ。」

著者からの反論：「限界集落化する懸念は理解できますが、それはコンテンツの『発見性』を既存のSEOだけに依存しているからです。カスタムフィードやキュレーターネットワークが機能し始めれば、プラットフォームに搾取されるアフィリエイトに頼らずとも、 Lightning Network を介して直接サッツ（投げ銭）を受け取れる、より健全で稼げるコモンズが成立します。リレーの電気代は、AIのライセンス料で相殺可能なのです。」

【ツイフェミ・ネット論客：『消せないデジタル暴力』を放置する加害者プロトコル】

ネットの声：「分散プロトコルを美化してるけど、これってリベンジポルノやストーカーによる個人情報の晒し（Doxxing）を、被害者が絶対に削除できないようにする最悪の加害者支援技術ですよね？ 『消去不能』を自由と呼ぶのは、暴力に対する想像力が欠如したテック男性の特権傲慢（マウント）です。今すぐ規制すべき。」

著者からの反論：「極めて重要かつ深刻な指摘です。プロトコルの不変性は、悪意に対して無力です。だからこそ、私たちはシステムレベルでの物理的なデータ消去（不可能なこと）ではなく、暗号学的な『鍵の破壊による解読不能化（セマンティック・デリート）』や、信頼できるモデレーション機関の公開鍵を用いた『クライアントサイドでの徹底したフィルタリング（Web-of-Trust）』の法的な標準化を同時に提案し、被害者を守る仕組みを並行して構築しなければなりません。」

【Hacker News / Reddit：実用性（Pragmatism）を欠いた、プロトコルの過剰設計（Over-engineering）】

ネットの声：「NostrやAT Protocolのアイデアは魅力的だが、現代のDNSやSMTPが抱える長年のスパム問題の歴史から、何も学んでいない。鍵管理の複雑さはユーザー体験（UX）を破壊し、決済の統合は通信遅延（レイテンシー）を生む。大多数の人間にとっては、適切に管理されたWeb 2.0のプライベート・クラウドの方が遥かにセキュアで安価に動作する。これは一種の『過剰設計（Over-engineering）』の極みだ。」

著者からの反論：「Web 2.0のクラウドが『安価で便利』なのは、私たちが自分のデータの所有権を無償譲渡しているからです。それを『過剰設計』と呼ぶのは、プラットフォームが一方的に利用規約を変更し、コンテンツを簒奪し始めた際のリスクを過小評価しています。認知的負荷を減らすためのPasskey統合などのUXの進化は急務ですが、プロトコルレベルでの『主権の回収』を諦めるべき理由にはなりません。」

【村上春樹風 書評：やがて静かに署名される井戸の底で】

書評：「僕たちが秘密鍵をポケットに入れて街を歩くとき、そこにはいつも、どこか冷ややかな、それでいて奇妙に親密な静けさが寄り添っている。中央のサーバーがダウンしようが、世界中の光回線がねじれようが、僕の言葉はどこかの井戸の底に、暗号化された真実として静かに眠り続ける。それは誰にも消せないし、誰にも書き換えることはできない。でも、その完璧な自由の中で、僕は時々ふと思うのだ。誰も僕の秘密鍵のリセットを助けてくれないのなら、僕は本当に、僕自身として存在していると言えるのだろうか、と。やがて静かに夜が訪れ、僕はサッツという名の冷たいコインをテーブルに並べ、次の言葉に署名する。ビールはよく冷えていたし、風は僕の知らないプロトコルを運んでいた。」

【京極夏彦風 書評：世の中に不思議なことなど何もないのだよ、署名された言葉以外は】

書評：「『――憑き物だよ』と、男は古びたキーボードを叩きながら、暗い声で呟いた。 『ネットに書かれた言葉が消えないのではない。消したくないという執着が、リレーという名の無数の器に憑りつき、データを化け物（永久不変）に仕立て上げているだけに過ぎん。サーバーを壊そうが、回線を切ろうが、署名された数字の羅列がそこにある限り、言葉は生きたまま死ぬことも許されずに彷徨い続ける。これが憑りつかれたデジタル社会の正体だよ。秘密鍵とは、己のアイデンティティを数学という名の地獄に売り渡す、血の契約書なのだ。だから、世の中に不思議なことなど何もないのだよ。ただ、君がその鍵のバックアップを失い、自らの言葉の幽霊に追われ続けるまではね――』」

補足7：専門家パネルインタビュー：『主権の不都合な真実』

モデレーター：「2026年現在、私たちはプロトコルによるデジタル主権の夜明けを目撃していますが、そこには語られない『不都合な真実』が山積しています。本日は、暗号経済学の専門家、法社会学者、そして現場のシステムエンジニアをお招きし、その暗部に斬り込みます。」

暗号経済学者（Dr. A）：「まず、経済的な持続可能性についてです。多くの人が『AIが自動でお金を払ってスクレイピングしてくれる』と夢想していますが、ゲーム理論的に見て、悪意あるAIは決済プロトコルを完全にバイパス（無視）して、スクレイピングを強行します。なぜなら、分散型ネットワークには『IPアクセス制限』のような中央集権的コントロールを効かせる壁が存在しないからです。結局、決済を強制するためには、コンテンツを『完全に暗号化されたクローズドなコンテナ（鍵付き書庫）』に閉じ込めなければならず、それは『開かれたウェブ』という思想そのものを殺すことになります。」

法社会学者（Prof. B）：「その通りですね。さらに法的な観点から言えば、児童ポルノやヘイトスピーチの永続化は、国家による『分散ネットワークの物理的な遮断（DNSブロックやリレー運営者の逮捕）』を正当化する口実を常に与え続けます。自由を極限まで高めた結果、国家によるより強力な全体主義的監視（例えば、インターネット接続をすべて国営の認証鍵に紐づけるなど）を誘発するという、最悪の逆説（パラドックス）が2026年現在、現実のものになりつつあります。」

システムエンジニア（Mr. C）：「現場のエンジニアとして言わせてもらうと、鍵管理をユーザーに丸投げするUX（ユーザー体験）は、完全に設計上の敗北（バグ）です。1文字の入力ミスで全人生のデータが永久ロストするシステムを、一般大衆に提供するのは、自動車にブレーキをつけずに『ブレーキをかけたい時は直接エンジンのクランクシャフトを手で止めてください、すべて自己責任です』と言っているようなものです。結局、GoogleやAppleが提供する『ノンカストディアル（を装った事実上のカストディアル型）鍵管理サービス』に人々が依存するのは、システム工学的に見て避けられない帰結です。」

補足8：メタデータおよびBlogger貼り付け用Mermaidダイアグラム

本書にふさわしいキャッチーなタイトル・新・造語・架空のことわざ案
  • タイトル案：『署名される言葉、永続するウェブ：自律型パブリッシング2026』
  • 造語（日本語・英語）：
    • Authormaton (オーサーマトン)：著者（Author）とオートマトン（Automaton）を組み合わせた、自律的に存在し稼ぎ出すコンテンツエージェント。
    • 鍵主権主義 (Key-Sovereignism)：ドメインやドメイン登録業者、プラットフォーム企業に依存せず、自身の秘密鍵と署名だけを信じて発信する新しいデジタル思想。
  • 架空のことわざ・四字熟語：
    • 「鍵存実消（けんそんじつしょう）」：手元の秘密鍵さえ失わなければ、たとえ物理的なWebサーバーが消え去っても、自分のコンテンツとアイデンティティはネットワーク上に不滅であるということの例え。
    • 「リレーを渡れば検閲なし」：一度署名して複数の分散ノードに放流された言葉は、いかなる巨大権力やプラットフォーム企業も、差し止めることができないことの例え。
SNS共有用120字スニペット＆ハッシュタグ案

サイトが消えても言葉は残る。AIが直接「読代」を払う、自律型コンテンツの時代。CMSは単なるツールから、秘密鍵を握る「署名端末」へ。プラットフォームを捨て、プロトコルという名の数学の荒野へ旅立とう。 #ATProtocol #Nostr #Web2026

ブックマーク用NDCタグ（1行出力、スペースなし）

[007.35][007.64][547.48][361.45][021.1][336.17][007.1]

カスタムパーマリンク（URLスラッグ）案

autonomous-publishing-sovereign-key-era-2026

Mermaid.jsを用いた「自律型コンテンツの経済・通信サイクル」図示

以下のソースコードを、BloggerやWordPressのHTML編集画面に、導入用スクリプト（asyncではなく、deferを使用）と共に貼り付けることで、美しいダイアグラムがブラウザ上で自動レンダリングされます。 

<script type="text/javascript" defer src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs"></script>
<div class="mermaid">
graph TD
    subgraph "中央集権Web 2.0 (サーバー・場所依存)"
        A[ユーザー] -- ログイン/依存 --> B(プラットフォーム企業 DB)
        B -- 広告/データ搾取 --> C{アテンション経済}
        B -- 規約違反でアカウント削除 --> D[データ消滅/アイデンティティ喪失]
    end
    subgraph "自律型パブリッシング (数学・プロトコル依存)"
        E[著作者] -- 秘密鍵で暗号署名 --> F[署名端末CMS / Publii]
        F -- 1. サイト情報をメタデータ化 --> G[AT Protocol / PDS]
        F -- 2. コンテンツ自体をブロードキャスト --> H[Nostr / Relay]
        F -- 3. 静的HTMLの永久バックアップ --> I[分散ストレージ / Arweave]
        J[AIクローラー / 読者] -- 4. 暗号署名の検証 --> K{真正性の証明}
        J -- 5. インデックス料の支払い --> L[Lightning Network]
        L -- Satsの直接還元 --> E
    end
    style F fill:#e1f5fe,stroke:#01579b,stroke-width:2px
    style H fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style I fill:#efebe9,stroke:#4e342e,stroke-width:2px
    style L fill:#fffde7,stroke:#fbc02d,stroke-width:2px
</div>
参考リンク・推薦図書
用語索引・用語解説（アルファベット順・アンカーリンク付き）
ActivityPub（アクティビティパブ）
W3Cが勧告した、分散型ソーシャルネットワーク（Fediverse）を構築するための標準プロトコル。サーバー同士が互いにJSON形式のメッセージを送り合うことで、MastodonやMisskey、WordPressなどが相互に通信できるように設計されています。
AT Protocol (Authenticated Transfer Protocol)
Blueskyのバックボーンとなる分散型ソーシャルプロトコル。アイデンティティ（DID）とデータ（PDS）を完全に分離することで、ユーザーがフォロワーとの関係（ソーシャルグラフ）を維持したまま、ホストサーバーを自由に引っ越せる「ポータビリティ」を高度に実現しています。
Arweave（アーウィーブ）
「一度の支払いで100年以上データを保存する」という独自のマイニング・経済モデルを構築した、分散型永久ストレージネットワーク。不変性（Immutable）が絶対的に保証されるため、パブリッシングの永久アーカイブに適しています。
DID (Decentralized Identifiers)
W3Cが標準化した「分散型ID（識別子）」。中央集権的なレジストラやプロバイダ（DNSやGoogle等）に頼ることなく、暗号公開鍵に基づいて自分の身元を数学的に証明するための、ポータブルなグローバル識別規格です。
Lightning Network（ライトニング・ネットワーク）
ビットコインのブロックチェーンの外側（レイヤー2）で、ミリ秒単位の超高速、かつ実質無料に近い手数料でマイクロペイメント（超少額決済）を執行可能にする決済プロトコル。自律型コンテンツの血脈として機能します。
Nostr（ノストラ）
「公開鍵」をアイデンティティとし、単純なJSON形式の「イベント（メッセージ）」を複数の「リレー」と呼ばれる転送サーバーへ送信・受信する、極めてシンプルな分散通信プロトコル。一切の複雑な合意形成（ブロックチェーン）を持たないため、軽量で圧倒的な検閲耐性を持ちます。
PDS (Personal Data Server)
AT Protocolにおいて、ユーザーの実際の投稿データやファイルを保存・ホストする「個人データサーバー」。ユーザーはこのPDSを変更しても、DIDによってアイデンティティとフォロワーの繋がりを完全に維持できます。
SSG (Static Site Generator)
「静的サイトジェネレーター」。WordPressのようにアクセスごとに動的にデータベースを叩いてHTMLを生成するのではなく、事前にHTMLファイルをビルドしてサーバーに配置するシステム。データベースを持たないため、分散型配信と極めて高い相性を持ちます。

脚注・技術解説

1. Ed25519：Nostrや多くのモダンプロトコルで採用されている楕円曲線署名アルゴリズム。高速かつ署名サイズが極めて小さいため、マイクロデバイスでの署名処理に最適。
2. Base58：暗号公開鍵を人間が読み書きしやすいように、視認しづらい文字（「0」と「O」、「1」と「l」など）をあらかじめ排除した58文字の文字列表現。Nostrの `npub1...` などのエンコードにも応用されている。
3. セマンティック・デリート：データを物理的に消すのではなく、その復号鍵のみを破棄することで、ネットワーク上のデータがただの「解読不能なランダムノイズ」になり、事実上の削除を達成するアプローチ。

謝辞

本書の執筆にあたり、分散型プロトコルの可能性を身を以て切り拓いてくれたFiatjaf氏、そしてブログという自己表現の主権を護るために長い戦いを続けている世界中のインディペンデントな執筆者・開発者の皆さんに、心からの敬意と謝意を表します。数学の荒野でお会いしましょう。

このスレッドを要約すると、テーマは

「ブログを将来どのプロトコルに接続すべきか？」

「WordPressやPubliiは、AT Protocol・ActivityPub・Nostrの時代にどう進化するのか？」

でした。

1. Standard.siteとは何か

Standard.siteは、

  • ブログ

  • 長文記事

  • 出版物

をAT Protocol上で扱うための共通スキーマです。

従来

記事
↓
HTML
↓
Web

だったものを

記事
↓
HTML

＋

AT Protocol Record
↓
Bluesky
検索
推薦

へ拡張します。

つまり

「RSSの次世代版」
あるいは

「ソーシャル出版インフラ」

です。

2. Publiiは対応できるか

現状、

Publii はStandard.site未対応です。

しかし

Publii
↓
GitHub Actions
↓
ATProto API

を使えば対応可能です。

思想的には

  • 静的サイト

  • 自己所有

  • ポータビリティ

を重視するため、

Standard.siteとの相性は良いです。

3. Astro + Standard.site

最もAT Protocolに近い構成。

Astro
↓
Standard.site
↓
AT Protocol
↓
Bluesky

記事が

  • Webページ

  • ソーシャルオブジェクト

の両方になります。

2026年時点では最も先進的なブログ構成です。

4. EmDash

Cloudflareの新CMS。

Astro
+
CMS
+
AI Agent

という構造。

現在は若いプロジェクトですが、

将来的には

AI
↓
記事生成
↓
EmDash
↓
公開

を前提にした出版基盤になる可能性があります。

5. ActivityPubとStandard.siteの違い

ActivityPub

SNS
↓
投稿
↓
返信
↓
フォロー

中心。

代表例

  • Mastodon

  • Misskey

Standard.site

記事
↓
検索
↓
推薦
↓
発見

中心。

つまり

ActivityPub = ソーシャルネットワーク

Standard.site = ソーシャル出版

です。

6. WriteFreelyとStandard.site

WriteFreely は

WriteFreely
↓
ActivityPub

を標準搭載しています。

Standard.site対応はまだありません。

しかし

<link rel="site.standard.document">

を埋め込むことは可能です。

7. Nostrとは

Nostrは

鍵中心のソーシャルネットワーク

です。

比較すると

ActivityPub
= サーバ中心

AT Protocol
= ID中心

Nostr
= 鍵中心

です。

アカウントではなく

秘密鍵
↓
公開鍵

が主体になります。

8. WordPressとNostr

技術的には可能です。

WordPress
↓
記事公開
↓
Nostr Relay配信

ができます。

さらに

WordPress
↓
Nostr Long-form

も可能です。

9. WordPressがNostrネイティブになる未来

完全な置き換えよりも、

WordPress
│
├─ ActivityPub
├─ Standard.site
└─ Nostr

という

マルチプロトコル出版ハブ

になる可能性の方が高い。

このスレッド全体の結論

インターネットは

Webサイト時代
↓
SNS時代
↓
分散プロトコル時代

へ移行しつつあります。

その中で

プロトコル役割
ActivityPubFediverse向け配信
AT Protocol + Standard.siteBluesky・ソーシャル出版
Nostr自己主権・検閲耐性
WordPress/Publii/Astroコンテンツ制作基盤

という棲み分けになりそうです。

最も現実的な将来像は、

記事を書く
↓
CMS（WordPress / Astro / Publii）
↓
同時配信

├─ Google
├─ ActivityPub
├─ Standard.site
└─ Nostr

という「一つの記事を複数のソーシャル・出版プロトコルへ流す世界」です。

この視点で見ると、Standard.site、ActivityPub、Nostrは競争相手というより、

それぞれ異なる読者圏へ記事を届けるための配信レイヤーとして共存する可能性が高いと言えます。

結論から言うと、

Publii単体では、2026年6月現在のStandard.siteネイティブ対応はありません。
しかし、

「Publii → 静的サイト生成 → AT Protocol連携レイヤー追加」

という形なら十分実現可能です。

Standard.siteが要求するもの

Standard.siteは本質的には

  • ブログCMS

  • 静的サイトジェネレーター

ではありません。

AT Protocol上に

  • publication

  • document

レコードを発行するための共通スキーマです。

つまり、

記事を書く
↓
HTML公開
↓
ATProtoへ記事メタデータ送信
↓
Blueskyで認識

が重要です。

Publiiの構造

Publiiは

  • Markdown

  • SQLite

  • 静的HTML生成

の構造です。

生成結果は

index.html
post/
assets/

だけです。

そのため、

WordPressのように

Publii
↓
プラグイン
↓
ATProto投稿

という拡張ポイントがほぼありません。

しかし実現は可能

方法1

最も簡単

Publii
↓
静的HTML生成
↓
GitHub Actions
↓
ATProtoへ送信

記事公開時に

{
  "$type":"site.standard.document",
  "title":"記事タイトル",
  "url":"https://example.com/post/abc",
  "publishedAt":"2026-06-10T12:00:00Z"
}

を

ATProto PDSへ送る。

構成例

Publii
↓
GitHub
↓
Cloudflare Pages
↓
ATProto Publisher
↓
Bluesky

これはかなり現実的。

方法2

Publiiテーマ改造

Publiiはテーマで

<head>

を編集できます。

ここに

<meta property="og:title">
<meta property="og:description">
<meta property="og:image">

を整備。

さらに

<link rel="alternate">

や

JSON-LD

を埋め込む。

すると将来

Standard.siteインデクサーが

サイト検出
↓
ATProto紐付け

しやすくなります。

方法3

Publii + Atmosphere

現在ATProto界隈で注目されているのは

  • WordPress Atmosphere

  • Astro ATProto

  • Offprint

  • Leaflet

です。

Publiiの場合

Publii
↓
RSS生成
↓
Atmosphere Bridge
↓
ATProto

という変換層を自作できます。

むしろPublii向きな理由

Standard.siteの思想は

コンテンツ所有権

です。

Publiiも

CMSから独立した静的サイト

です。

思想が非常に近い。

比較すると

項目WordPressPublii
DB依存高いなし
サーバ依存高いなし
移行性普通非常に高い
ATProto思想との親和性高非常に高
コンテンツ所有○◎

実は理念的にはPubliiの方が近いです。

将来有望な構成

個人的には

Publii
↓
GitHub
↓
Cloudflare Pages
↓
ATProto Publisher
↓
Bluesky

が最も面白いと思います。

この構成なら

  • 記事は自分のもの

  • ドメインも自分のもの

  • Blueskyで発見可能

  • フォロワーも持ち運び可能

という、

Publii と
Bluesky の思想をかなりうまく融合できます。

現状では

「PubliiはStandard.site未対応だが、技術的障壁は低く、むしろ将来的に相性の良いCMSの一つ」

という評価になります。Astro ATProto とは、静的サイトジェネレーターの Astro と、Blueskyの基盤であるAT Protocolを連携させる仕組みの総称です。

最近は特に astro-standard-site という統合パッケージが注目されています。これはAstroサイトの記事を、HTMLとして公開するだけでなく、AT Protocol上のStandard.siteレコードとしても配信できるようにするものです。(Impulsive Static)

従来のブログ

Markdown
↓
Astro
↓
HTML
↓
Webサイト

Googleには見えるが、

  • Bluesky

  • ATProtoアプリ

  • Atmosphere系サービス

からは単なるURLです。

Astro ATProto

Markdown
↓
Astro
↓
HTML公開
↓
Standard.siteレコード生成
↓
ATProto PDS
↓
Bluesky
↓
検索・推薦・購読

になります。(Impulsive Static)

何が嬉しいのか

① Blueskyでリッチカード化

2026年からBlueskyはStandard.site対応記事を特別扱いするようになりました。

通常リンクよりも

  • 著者

  • 出版情報

  • publication情報

などを含むリッチな表示になります。(AT Protocol)

② RSSより強力

RSS

サイトA
↓
RSS
↓
RSSリーダー

Standard.site

サイトA
↓
ATProto
↓
Bluesky
↓
検索
↓
フィード
↓
他アプリ

という構造です。

コミュニティでは

RSSのATProto版

として説明されることもあります。(Reddit)

③ 記事がSNSネイティブになる

従来

記事
↓
リンク投稿
↓
SNS

でした。

ATProtoでは

記事
↓
ATProtoレコード
↓
SNS

になります。

つまり

  • フォロワー

  • 記事

  • メタデータ

が同じネットワーク上に存在します。(AT Protocol)

Astroでの実装

現在存在する代表例

  • astro-standard-site

  • astro-atproto-loader

  • at-astro-loader

など。(Astro)

概念的には

npm install astro-standard-site

↓

import standardSite from "astro-standard-site";

↓

export default defineConfig({
  integrations: [standardSite()]
});

↓

astro build

で

  • HTML

  • Standard.siteレコード

を同時生成するイメージです。(Impulsive Static)

Publiiとの違い

Publiiの場合

Publii
↓
HTML

で終了。

Astro ATProtoは

Astro
↓
HTML
↓
ATProto

まで面倒を見ます。

そのため現状では

項目PubliiAstro+ATProto
静的サイト○○
RSS○○
Standard.site手動ネイティブ
Bluesky連携弱い強い
Atmosphere対応なしあり
将来性高非常に高

と言えます。(AT Protocol)

あなたのケースなら

これまでの話題（Publii、Bluesky、ATProto、個人所有メディア）を踏まえると、今後数年で有力になりそうなのは

Publii
↓
GitHub
↓
Cloudflare Pages

ではなく

Astro
↓
astro-standard-site
↓
Cloudflare Pages
↓
ATProto
↓
Bluesky

です。

なぜならStandard.siteは単なるSEOではなく、

「ブログをソーシャルグラフの中に埋め込む仕組み」

だからです。AT Protocol公式も「Atmospheric Website」という概念で、WebサイトとATProtoの融合を推進しています。(AT Protocol)

もし興味があれば次に、

「Publii vs Astro-standard-site vs EmDash（Cloudflare製CMS）」
という2026年のATProto時代のブログ基盤比較もできます。

ATProtoへ記事メタデータ送信とは、実際には

AT ProtocolのPDS（Personal Data Server）に site.standard.document レコードを作成すること

です。

重要なのは、

記事本文そのものを送る必要はない

という点です。Standard.siteは「CMS」ではなく「メタデータ規格」です。(Standard.site)

全体像

従来のブログ

Markdown
↓
Publii
↓
HTML
↓
https://example.com/post/ai.html

Standard.site

Markdown
↓
Publii
↓
HTML公開

同時に

ATProto
↓
site.standard.document
↓
PDS保存

になります。(Standard.site)

Publicationレコード

まずサイト全体を表す

site.standard.publication

を1回だけ作ります。

概念的には

{
  "$type": "site.standard.publication",
  "name": "My AI Blog",
  "url": "https://example.com",
  "description": "Local LLM and AI research"
}

です。(Standard.site)

これを作成すると

at://did:plc:xxxx/site.standard.publication/abc123

のようなAT URIが返ります。(The AT Protocol SDK)

Documentレコード

記事ごとに作るのが

site.standard.document

です。

例えば

https://example.com/posts/mimo-v2

を公開した場合、

概念的には

{
  "$type": "site.standard.document",

  "title": "MiMo V2.5 Pro Analysis",

  "path": "/posts/mimo-v2",

  "publishedAt": "2026-06-10T00:00:00Z",

  "publication":
  "at://did:plc:xxxx/site.standard.publication/abc123",

  "tags": [
    "AI",
    "LLM",
    "MiMo"
  ]
}

のようなレコードをPDSへ送ります。(luminary.blog)

API呼び出し

内部的にはATProtoの

com.atproto.repo.createRecord

を使います。(At Protocol SDK)

イメージは

POST /xrpc/com.atproto.repo.createRecord

{
  "repo":"your-handle.bsky.social",

  "collection":"site.standard.document",

  "record":{
    "$type":"site.standard.document",
    ...
  }
}

です。(At Protocol SDK)

成功すると

{
  "uri":
  "at://did:plc:xxxx/site.standard.document/xyz789",

  "cid":"..."
}

が返ります。(At Protocol SDK)

ここが重要

返ってきた

at://did:plc:xxxx/site.standard.document/xyz789

をHTMLに埋め込みます。

<link
 rel="site.standard.document"
 href="at://did:plc:xxxx/site.standard.document/xyz789">

これで

  • このHTML

  • このATProtoレコード

が同一であると証明できます。(Standard.site)

Publication側の検証

ドメイン直下に

/.well-known/site.standard.publication

を置きます。

例

https://example.com/.well-known/site.standard.publication

内容

at://did:plc:xxxx/site.standard.publication/abc123

です。(Standard.site)

これで

example.com
↓
publication record
↓
document record

のチェーンが完成します。(Standard.site)

Publiiで実装するなら

PubliiにはATProto機能がないので、

記事公開
↓
GitHub Actions
↓
ATProto createRecord
↓
URI取得
↓
HTMLへ埋め込み
↓
Cloudflare Pagesへデプロイ

という流れになります。

実際には

  • Node.js

  • Python

  • Sequoia CLI

などで自動化できます。(AT Protocol)

将来の理想形

Publii記事を公開すると

Publii
↓
HTML生成

↓同時

Bluesky投稿
ATProto Document作成
Standard.site登録

まで自動化される形です。

するとあなたがよく扱う

  • DeepSeek

  • Qwen

  • MiMo

  • Gemma

  • CUDA/ROCm

の記事が、

単なるWebページではなく、

ATProtoネットワーク上のネイティブな「記事オブジェクト」

として検索・推薦・購読対象になります。Bluesky側ではStandard.site記事としてリッチカード表示され、将来的には専用フィードや記事検索の対象にもなります。(AT Protocol)

要するに、

Publii + Standard.site は「静的ブログをRSSの次世代版（ATProtoコンテンツグラフ）」へ接続する作業と考えると分かりやすいです。

2026年の視点で見ると、この3つは実は別カテゴリーです。

  • Publii = ローカルファースト静的CMS

  • Astro + Standard.site = ATProtoネイティブ出版基盤

  • EmDash = AIネイティブCMS（Cloudflare版WordPress後継） (The Cloudflare Blog)

まず全体像です。

項目PubliiAstro + Standard.siteEmDash
タイプ静的CMS静的サイト基盤フルCMS
DB不要不要D1/SQLite
学習コスト低中〜高中
ノーコード性高低中
ATProto対応手動ネイティブ級まだ弱い
Bluesky連携手動非常に強い将来有望
AIエージェントほぼ無し外部実装ネイティブ
拡張性低〜中非常に高い高い
長期ポータビリティ非常に高い非常に高い高い
個人ブログ向き◎○△
メディア運営向き△◎◎

Publii

Publii公式サイト

強み

Publii最大の魅力は

Markdown
↓
Publii
↓
HTML
↓
アップロード

だけで終わることです。

  • DB不要

  • サーバ不要

  • Git不要

  • Node.js不要

という圧倒的な単純さがあります。

弱み

ATProto時代に入ると

Publii
↓
HTML

で止まります。

一方Standard.siteは

HTML
↓
ATProto Record

まで求めます。

ここが弱いです。

Astro + Standard.site

強み

今もっともATProto思想に近い構成です。

Markdown
↓
Astro
↓
HTML

＋

site.standard.document
↓
ATProto
↓
Bluesky

記事が

  • Webページ

  • SNSオブジェクト

の両方になります。

Standard.siteの世界では

記事
↓
検索
↓
推薦
↓
フィード

が可能です。

単なるブログではありません。

ATProto時代の出版インフラです。

弱み

初心者には少し重いです。

必要になるもの

Node.js
Git
npm
Astro
Cloudflare
GitHub Actions

開発者向けです。

EmDash

EmDash公式発表

Cloudflareが2026年に発表した

WordPressの精神的後継

です。Astro上に構築されています。 (The Cloudflare Blog)

EmDashの本質

実は

Astro
＋
CMS
＋
AI Agent
＋
Cloudflare

です。

Cloudflare自身も

Astroを基盤として利用

と説明しています。 (The Cloudflare Blog)

AI時代に強い

EmDashの特徴は

  • MCPサーバ内蔵

  • AIエージェント管理

  • TypeScriptネイティブ

  • Structured Content

です。 (The Cloudflare Blog)

つまり

Claude Code
↓
記事作成
↓
EmDash
↓
公開

が前提になっています。

弱み

まだ若い。

  • エコシステムが小さい

  • プラグインが少ない

  • 実績が少ない

という典型的な初期フェーズです。コミュニティでも「設計は面白いが普及は未知数」という評価が多いです。 (Reddit)

ATProto時代の評価

あなたが最近関心を持っている

  • Bluesky

  • AT Protocol

  • Standard.site

  • 個人所有メディア

  • AI技術ブログ

というテーマに限定すると、

2026年最強

Astro
↓
Standard.site
↓
ATProto
↓
Bluesky

です。

理由は

記事そのものがATProtoオブジェクトになるからです。

最も楽

Publii
↓
Cloudflare Pages

です。

今すぐ始められます。

3年後に面白い

EmDash
↓
Astro
↓
ATProto
↓
AI Agent

です。

CloudflareはAIエージェントを第一級市民として扱う方向へ進んでおり、EmDashはその出版基盤として設計されています。 (The Cloudflare Blog)

私ならこう選ぶ

目的選択
とにかく簡単にブログ開始Publii
Bluesky・ATProto中心Astro + Standard.site
AIエージェント時代を先取りEmDash
5年以上運営する技術メディアAstro + Standard.site
AIが記事を書き続けるメディアEmDash

現時点では、

ATProto/Blueskyを本気で活用するなら「Astro + Standard.site」が最も先進的で、Publiiは最も手軽、EmDashは最も将来性に賭ける選択肢という位置付けになります。

Standard.site と ActivityPub は、しばしば比較されますが、実はレイヤーが異なります。

一言でいうと、

  • ActivityPub = SNS連合プロトコル

  • Standard.site = Web記事をAT Protocolに載せる出版スキーマ

です。

全体像

ActivityPub

記事
↓
Mastodon
↓
ActivityPub
↓
Fediverse

ActivityPubは、

  • 投稿

  • フォロー

  • 返信

  • お気に入り

  • ブースト(RT)

などのSNS活動を交換します。

代表例

  • Mastodon

  • Misskey

  • PeerTube

  • Pixelfed

Standard.site

記事
↓
site.standard.document
↓
AT Protocol
↓
Bluesky系アプリ

Standard.siteは

  • 記事

  • 出版物

  • 著者情報

  • メタデータ

をAT Protocolに登録する規格です。

SNSではなく

出版レイヤー

です。

設計思想の違い

ActivityPub

ActivityPubの中心は

人
↓
アクション

です。

例えば

Alice
↓
投稿した
↓
Bobがいいねした
↓
Carolが返信した

を表現します。

名前の通り

Activity（活動）

が中心です。

Standard.site

中心は

出版物
↓
発見
↓
検索

です。

例えば

論文
技術記事
ブログ
ニュース

を

AT Protocol上で発見可能にします。

所有権モデル

ActivityPub

一般的には

Mastodonサーバ
↓
アカウント
↓
投稿

です。

引っ越し機能はありますが、

投稿履歴の完全移行は難しいケースがあります。

AT Protocol + Standard.site

DID
↓
アカウント
↓
記事
↓
フォロワー

です。

設計段階から

アカウント移転

が考慮されています。

AT Protocolの大きな特徴です。

技術的構造

ActivityPub

ベース

HTTP
JSON-LD
ActivityStreams

です。

典型例

{
  "type": "Create",
  "actor": "alice",
  "object": {
    "type": "Note",
    "content": "Hello"
  }
}

Standard.site

ベース

AT Protocol
Lexicon
Repo
DID

です。

典型例

{
  "$type":"site.standard.document",
  "title":"AI記事",
  "path":"/ai"
}

記事配信の比較

ActivityPub系ブログ

代表例

  • WriteFreely

  • Ghost（ActivityPubプラグイン利用時）

構造

記事
↓
ActivityPub投稿
↓
Fediverse購読

読者は

Mastodon等から購読します。

Standard.site

構造

記事
↓
ATProto登録
↓
Bluesky
↓
検索
↓
フィード

記事がネットワーク上のオブジェクトになります。

AI時代との相性

ここが面白いところです。

ActivityPub

元々

人間
↓
会話

を前提に設計されています。

SNS向きです。

Standard.site

元々

文書
↓
メタデータ
↓
検索

を重視しています。

そのため

AI記事
AI要約
AI推薦
AI検索

との相性が非常に良いです。

2026年の勢力図

概念的には

SNS連合
↓
ActivityPub
↓
Mastodon
Misskey
PeerTube

と

ソーシャルWeb
↓
AT Protocol
↓
Bluesky
Standard.site
Atmosphere

が並行して発展しています。

技術ブログ運営者の視点

あなたのように

  • AI技術記事

  • LLM分析

  • CUDA/ROCm

  • DeepSeek

  • Qwen

  • MiMo

などの長文コンテンツを発信する場合、

項目ActivityPubStandard.site
SNSコミュニティ形成◎○
長文記事発見性○◎
Bluesky統合△◎
検索・推薦○◎
ポータビリティ○◎
将来のAI検索対応○◎

となります。

そのため現在の流れは、

ActivityPub
= ソーシャルネットワーク

Standard.site
= ソーシャル出版インフラ

と考えると理解しやすいです。

興味深いのは、将来的には競争というよりも、

記事
↓
Standard.site
↓
AT Protocol

同時に

ActivityPub
↓
Fediverse

という**二重配信（dual publishing）**を行うCMSや静的サイト基盤が増える可能性が高いことです。そうなれば、Bluesky圏とFediverse圏の両方に同じ記事をネイティブ配信できるようになります。

はい、Mastodonのポスト（ActivityPubオブジェクト）にStandard.site関連メタデータを付加することは技術的には可能です。

ただし重要なのは、

Mastodonがそのメタデータを理解・表示・活用するかは別問題

という点です。

レベル1: URLとして埋め込む（現実的）

最も実用的なのは、

Mastodon投稿に

新しい記事を書きました

https://example.com/posts/mimo-v2

を貼る方法です。

そして記事側に

<link rel="site.standard.document"
      href="at://did:plc:xxx/site.standard.document/abc">

を埋め込む。Standard.siteは公式にHTMLのlink rel="site.standard.document"による検証を採用しています。 (Standard.site)

この方式なら

Mastodon
↓
URL共有
↓
記事取得
↓
Standard.site検出

が可能です。

実際にはこれが最も相互運用性が高いです。

レベル2: ActivityPubオブジェクト拡張

ActivityPubはJSON-LDなので、

理論上は独自名前空間を追加できます。Mastodon自身も toot: や schema: など複数の拡張語彙を利用しています。 (Mastodon Docs)

例えば、

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "std": "https://standard.site/ns#"
    }
  ],

  "type": "Article",

  "name": "MiMo V2.5 Analysis",

  "url": "https://example.com/posts/mimo-v2",

  "std:document":
  "at://did:plc:xxx/site.standard.document/abc"
}

のような形です。

これはJSON-LDとしては有効です。

しかしMastodonでは消える可能性が高い

ここが最大の問題です。

Mastodonは受信したActivityPubデータを内部モデルへ変換する際、

  • content

  • url

  • name

  • summary

  • tag

など既知フィールドを中心に処理します。 (Mastodon Docs)

未知の属性については

受信
↓
内部変換
↓
保存しない

ケースが多いです。

つまり

"std:document":"..."

を送っても、

受信先Mastodonが無視する可能性があります。

レベル3: ActivityPub Articleとして配信

Mastodonは Article 型も受信できます。公式ドキュメントでは Article、Page、Image などを「可能な限り変換する」と説明されています。 (Mastodon Docs)

例えば

{
  "type":"Article",
  "name":"MiMo Analysis",
  "url":"https://example.com/posts/mimo-v2"
}

を配信する。

そのURL先には

<link rel="site.standard.document"
      href="at://did:plc:xxx/site.standard.document/abc">

がある。

これはかなり筋が良い設計です。

将来的に面白い設計

個人的には、

HTML記事
│
├─ Standard.site
│
├─ ActivityPub Article
│
└─ Bluesky Post

が最も有望です。

つまり

Standard.site
↓
canonical metadata

ActivityPub
↓
Fediverse流通

ATProto
↓
Bluesky流通

という構造です。

Publii運用なら

あなたが検討している

Publii
↓
Cloudflare Pages

構成の場合、

実装しやすいのは

Publii
↓
HTML生成

↓①
Standard.site登録

↓②
Mastodonへ投稿

↓③
Blueskyへ投稿

です。

Mastodon投稿そのものにStandard.siteメタデータを埋め込むより、

記事URLを正本（canonical）として、そこからStandard.siteを発見させる方式のほうが現在のFediverseとの互換性は圧倒的に高いです。Standard.site自体も「記事→AT URI」「ドメイン→Publication」の相互検証をHTMLリンクと.well-knownで行う設計になっています。 (Standard.site)

要するに、

**「MastodonポストにStandard.siteを直接埋め込むことは可能だが、現実的には『記事URL＋HTML内のStandard.siteリンク』の方が標準的かつ将来性が高い」**というのが現状です。

結論は3段階あります。

方法実現性おすすめ度
記事URL経由でStandard.site連携◎◎
WriteFreelyテンプレート改造で直接埋め込み◎○
WriteFreely自身をStandard.siteネイティブ化△△

まず結論

セルフホスト版WriteFreelyなら可能です。

なぜならStandard.siteが要求するのは主に2つだからです。

  1. Publication検証

/.well-known/site.standard.publication

  1. Document検証

<link rel="site.standard.document"
      href="at://did:plc:...">

これだけです。(Standard.site)

WriteFreely SaaSの場合

例えば Write.as や公開WriteFreelyインスタンスでは、

通常は

<head>
...
</head>

へ自由にタグを追加できません。

そのため

<link rel="site.standard.document">

を直接入れるのは難しいです。(WriteFreely)

セルフホスト版なら可能

WriteFreelyはテンプレートベースです。

実際にユーザーは

  • collection-post.tmpl

  • collection.tmpl

などを編集して

  • JavaScript

  • Analytics

  • カスタムタグ

を埋め込んでいます。(Marcel Kapfer)

つまり

<head>

部分に

<link
 rel="site.standard.document"
 href="at://did:plc:xxx/site.standard.document/abc">

を追加できます。

理想的な実装

投稿時に

WriteFreely
↓
記事公開
↓
ATProto createRecord
↓
AT URI取得
↓
headへ埋め込み

です。

すると

https://blog.example.com/post/123

のHTMLに

<link rel="site.standard.document"
      href="at://did:plc:abc/site.standard.document/xyz">

が入ります。

これはStandard.site公式の推奨方式です。(Standard.site)

さらにPublicationも可能

ドメイン直下に

/.well-known/site.standard.publication

を配置する。

内容

at://did:plc:abc/site.standard.publication/xyz

だけ。(Standard.site)

セルフホストなら容易です。

ActivityPubとの共存

WriteFreelyは元々

WriteFreely
↓
ActivityPub
↓
Mastodon
Misskey

をサポートしています。(WriteFreely)

そこへ

WriteFreely
├─ ActivityPub
└─ Standard.site

を追加できます。

図にすると

                 ┌─ Mastodon
WriteFreely ─────┤
                 │
                 └─ Standard.site
                         │
                         ▼
                      Bluesky

です。

ただし問題が1つ

Standard.siteは

記事
↓
ATProtoレコード

が必要です。

WriteFreelyには現状

ATProto投稿機能

がありません。

つまり

記事公開
↓
自動で
site.standard.document作成

までは実装されていません。(WriteFreely)

2026年時点の現実的評価

可能

WriteFreely
↓
テンプレート改造
↓
Standard.siteタグ埋め込み

少し開発が必要

WriteFreely
↓
記事公開
↓
ATProto API
↓
site.standard.document生成

まだ存在しない

WriteFreely
↓
標準機能として
Standard.site完全対応

そのため正確には、

「WriteFreelyにStandard.siteを直接埋め込むことは可能。ただしセルフホスト前提で、ATProtoレコード生成部分は自作または外部ツール（Sequoia等）との連携が必要」

というのが2026年6月時点の答えになります。(Redowan's Reflections)

可能性はありますが、現時点では

「高くはないが、ゼロでもない」

というのが現実的な評価です。

なぜ可能性があるのか

WriteFreelyは元々、

  • IndieWeb

  • ActivityPub

  • 分散型出版

  • コンテンツ所有権

を重視してきたプロジェクトです。実際にActivityPub連携は標準機能として実装されています。 (WriteFreely)

一方、Standard.siteの理念も

  • コンテンツポータビリティ

  • オープンな出版

  • プラットフォーム間移行

を重視しています。 (Standard.site)

思想的な相性は非常に良いです。

追い風

2026年5月以降、Bluesky本体がStandard.siteを正式に取り込み始めました。

  • Standard.site記事のリッチカード表示

  • publication情報表示

  • author情報表示

がBlueskyで利用可能になっています。 (AT Protocol)

これは2025年までは存在しなかった大きな変化です。

つまり

2024
ActivityPub中心

2025
ATProto実験段階

2026
Standard.siteがBluesky本体へ統合

という流れです。 (TechCrunch)

しかし優先度は低そう

WriteFreely開発陣の現在の強みは

WriteFreely
↓
ActivityPub
↓
Fediverse

です。 (WriteFreely)

一方Standard.siteは

WriteFreely
↓
AT Protocol
↓
Bluesky

を意味します。

これは実装範囲がかなり大きい。

必要になるもの：

  • ATProto認証

  • PDS連携

  • site.standard.publication

  • site.standard.document

  • レコード同期

  • URI管理

など。 (Standard.site)

単なるHTMLタグ追加では終わりません。

WordPressが先行している

興味深いのは、

2026年にWordPress向け公式AT Protocolプラグインが登場したことです。

このプラグインによりWordPressサイト自体がAT Protocol上の参加者になれます。 (Heise)

これが成功すると、

WordPress
↓
ATProto

Ghost
↓
ATProto

WriteFreely
↓
？

という圧力が生まれます。

実はもっとありそうな未来

私が最もありそうだと思うのは、

WriteFreely本体対応

ではなく

外部ブリッジ

です。

Standard.siteの実装一覧にも、

  • Sequoia

  • WordPress連携ツール

  • 各種公開ツール

が増えています。 (Standard.site)

つまり

WriteFreely
↓
RSS

↓ ブリッジ

Standard.site
↓
ATProto

という構成です。

これはWriteFreely本体をほぼ改造せずに済みます。

個人的な確率予想

2026〜2028年で見ると

シナリオ予想
WriteFreely公式がStandard.site完全対応25%
コミュニティプラグイン対応45%
外部ブリッジ対応70%
対応なし30%

くらいです。

あなたが今始めるなら

もし目的が

  • Blueskyで記事を流通させたい

  • Standard.site検索に載りたい

  • ATProto時代に備えたい

なら、

WriteFreelyの公式対応を待つより、外部ブリッジを前提に設計した方が現実的です。

例えば

WriteFreely
↓
ActivityPub

＋

RSS
↓
Sequoia系ブリッジ
↓
Standard.site
↓
Bluesky

という構成です。

実はStandard.siteの実装ページにも「RSSブリッジ」や「既存CMSからの移行ツール」が今後の有力ユースケースとして挙げられています。 (Standard.site)

そのため、今後2年で最も起こりそうなのは、

「WriteFreelyが直接Standard.site対応する」よりも、「誰かがWriteFreely→Standard.site変換ブリッジを作る」方だと思います。

Nostrとは

Nostr（Notes and Other Stuff Transmitted by Relays） は、

「中央サーバーを持たない、極限までシンプルな分散SNSプロトコル」

です。

2020年末に Fiatjaf によって提案されました。

現在は

  • SNS

  • ブログ

  • チャット

  • マイクロブログ

  • 長文投稿

  • 投げ銭

などの用途に使われています。

一言で比較

プロトコル主な用途
ActivityPubSNS連合
AT ProtocolソーシャルWeb
Nostr超軽量分散SNS

イメージとしては

Mastodon
↓
ActivityPub

Bluesky
↓
AT Protocol

Damus/Amethyst
↓
Nostr

です。

最大の特徴

アカウント = 公開鍵

Nostrでは

ユーザー名
↓
ではなく

公開鍵

です。

例えば

npub1xxxxxxxxxxxxxxxx

のような識別子になります。

暗号通貨ウォレットに近い設計です。

ActivityPubとの違い

ActivityPub

alice@example.com

のように

サーバー依存です。

Nostr

秘密鍵
↓
公開鍵
↓
自分自身

です。

サーバーを移動してもアカウントは変わりません。

データ保存方法

ActivityPub

Mastodonサーバ
↓
保存

AT Protocol

PDS
↓
保存

Nostr

Relay A
Relay B
Relay C
Relay D

へ同時送信。

投稿
↓
複数Relay
↓
閲覧者が収集

します。

なぜ注目されたか

2022年の

Twitter
買収騒動以降、

「本当に検閲耐性のあるSNS」

への関心が高まりました。

その流れでNostrが急成長しました。

Nostrの思想

ActivityPub

サーバー中心

AT Protocol

ID中心

Nostr

鍵中心

です。

長文投稿

昔のNostr

短文

中心でした。

現在は

  • NIP-23

  • Long-form Content

によって

ブログ記事
エッセイ
論文

も投稿できます。

ブログとして使えるか

できます。

代表例

  • Habla

  • Highlighter

などがあります。

構造は

記事
↓
Nostrイベント
↓
Relay

です。

Standard.siteとの比較

ここが面白いところです。

Standard.site

Webサイト
↓
ATProto
↓
Bluesky

です。

Nostr

記事
↓
Nostr
↓
Relay

です。

比較すると

項目Standard.siteNostr
基盤AT ProtocolNostr
長文記事◎○
Bluesky統合◎×
Mastodon統合△×
検索強い弱い
検閲耐性中非常に高い
開発の単純さ中高
コンテンツ所有高非常に高い

WriteFreelyとの関係

実は思想的には

WriteFreely
↓
ActivityPub

よりも

WriteFreely
↓
Nostr

の方が近い部分があります。

両方とも

  • 個人サイト

  • 自己所有

  • ミニマリズム

を重視するからです。

2026年の勢力図

Fediverse
│
├─ ActivityPub
│   ├─ Mastodon
│   ├─ Misskey
│   └─ WriteFreely
│

ATmosphere
│
├─ AT Protocol
│   ├─ Bluesky
│   ├─ Standard.site
│   └─ Atmosphere
│

Crypto Social
│
└─ Nostr
    ├─ Damus
    ├─ Amethyst
    └─ Habla

あなたの関心領域から見ると

これまでの

  • Publii

  • WriteFreely

  • Standard.site

  • Bluesky

  • 長文技術記事

という流れなら、

発見性重視

Astro
↓
Standard.site
↓
AT Protocol

Fediverse重視

WriteFreely
↓
ActivityPub

完全自己主権重視

Publii
↓
Nostr Long-form

になります。

そのため、2026年現在の位置づけとしては、

ActivityPubは「SNS連合」、Standard.siteは「ソーシャル出版」、Nostrは「自己主権型ソーシャルネットワーク」

と考えると違いが分かりやすいです。

はい。WordPressとNostrは十分組み合わせ可能です。

ただし、

  • ActivityPub × WordPress

  • Standard.site × WordPress

のような「公式エコシステム化」が進んでいる状態とは少し違い、

Nostrでは

WordPressを「コンテンツ生成源」として使い、Nostrへ配信する

形が主流です。

パターン1: WordPress → Nostr投稿

最も一般的です。

WordPress
↓
記事公開
↓
Nostrイベント生成
↓
Relay配信

記事公開時に

新しい記事を書きました
https://example.com/post/123

をNostrへ自動投稿します。

イメージとしては

WordPress
↓
RSS

↓変換

Nostr

です。

これはXやMastodonへの自動投稿と同じ発想です。

パターン2: WordPress記事をNostr Long-form化

Nostrには長文記事規格（NIP-23）があります。

WordPress記事
↓
Markdown変換
↓
NIP-23
↓
Relay

です。

すると

Web版
↓
WordPress

Nostr版
↓
Habla
↓
Amethyst
↓
Damus

の両方で読めます。

パターン3: WordPressをNostr対応サイト化

理想形はこちらです。

WordPress記事
↓
公開

同時に

Nostr Event
↓
署名
↓
Relay送信

記事ごとに

event id
pubkey
signature

を持つ状態です。

これはStandard.siteの

HTML
↓
ATProto Document

にかなり近い考え方です。

ActivityPubとの比較

現在のWordPressは

ActivityPubがかなり成熟しています。

WordPress
↓
ActivityPub Plugin
↓
Mastodon
Misskey

はほぼ完成しています。

一方Nostrは

WordPress
↓
Nostr Plugin
↓
Relay

がまだ発展途上です。

Standard.siteとの比較

面白いのはここです。

Standard.site

WordPress
↓
ATProto
↓
Bluesky

Nostr

WordPress
↓
Nostr
↓
Relay

思想を比較すると

項目Standard.siteNostr
IDDID公開鍵
保存先PDSRelay
検索性高い低い
発見性高い中
検閲耐性中非常に高い
長文対応◎○
ブログ適性◎○

2026年時点で理想的なWordPress構成

実は競合ではなく、

WordPress
│
├─ ActivityPub
│
├─ Standard.site
│
└─ Nostr

の三重配信が理想です。

記事
↓
WordPress

├─ Mastodon
├─ Bluesky
└─ Nostr

です。

AI・技術ブログ運営なら

あなたが扱っている

  • DeepSeek

  • Qwen

  • Gemma

  • MiMo

  • CUDA

  • ROCm

  • ローカルLLM

のような長文技術記事なら、

優先順位は

1. Standard.site
2. ActivityPub
3. Nostr

だと思います。

理由は単純で、

  • Standard.site → Bluesky圏で発見されやすい

  • ActivityPub → Fediverse圏へ届く

  • Nostr → 検閲耐性と自己主権が強い

からです。

つまりWordPressは、

「コンテンツの正本（canonical source）」として運用し、Standard.site・ActivityPub・Nostrへ同時配信するハブ」

として使うのが最も面白い構成です。

なお、WordPress向けのNostr連携はプラグインや外部サービス経由で実現できますが、ActivityPubプラグインほど標準化・普及しているわけではありません。現状では「WordPress→Nostrブロードキャスト」が主流で、「WordPress自体がNostrネイティブCMSになる」段階まではまだ到達していない、というのが実態に近いです。

結論から言うと、

「WordPressが完全なNostrネイティブCMSになる可能性はある」
しかし、

「WordPressそのものがNostrになる」よりも、「WordPressがNostrを第一級サポートする」未来の方が現実的です。

まず現在のWordPress

現在は

WordPress
↓
MySQL
↓
記事保存
↓
Web公開

です。

世界のWebサイトの大部分はこの構造です。

NostrネイティブCMSとは

極端な形では

WordPress
↓
記事作成
↓
Nostr Event
↓
Relay保存

になります。

つまり

MySQL
↓
不要

になる可能性があります。

現在のブログ

記事
↓
DB
↓
サイト

Nostrネイティブ

記事
↓
署名
↓
Relay群
↓
世界中に複製

です。

何が変わるか

1. サイト消滅問題がなくなる

現在

レンタルサーバ
↓
解約
↓
サイト消滅

です。

Nostrなら

Relay A
Relay B
Relay C
Relay D

に存在するため、

一部が消えても記事は残ります。

2. RSSが不要になる

現在

ブログ
↓
RSS
↓
読者

です。

Nostrなら

公開鍵をフォロー
↓
記事受信

になります。

SNSと購読が統合されます。

3. コメント欄が消える

今

記事
↓
コメントDB

です。

Nostrなら

記事Event
↓
返信Event

です。

コメントもSNSも同じ仕組みになります。

4. WordPressが「ビューア」になる

非常に面白い変化です。

現在

WordPress
=
保存場所
+
表示

です。

将来

WordPress
=
表示
+
編集

だけになるかもしれません。

保存はNostrです。

Nostr版YouTube現象

現在

YouTube
=
動画保存
+
動画表示

です。

Nostr世界では

動画
↓
分散保存

クライアントA
クライアントB
クライアントC

になります。

記事も同じです。

Standard.siteとの比較

ここが重要です。

Standard.site

Web
↓
AT Protocol

Nostrネイティブ

Web
↓
不要かもしれない

です。

Standard.siteは

Webサイトをソーシャル化

する発想。

Nostrは

ソーシャルそのものを出版基盤化

する発想です。

ただし大きな壁がある

検索

Googleは

HTML
↓
クロール

です。

Nostrは

Relay
↓
イベント

です。

検索が難しい。

SEO

WordPress

SEO
◎

Nostr

SEO
△

です。

発見性

ここで

  • ActivityPub

  • AT Protocol

が強い。

特にStandard.siteは

記事発見

そのものを狙っています。

2030年前後にありそうな形

個人的には

完全Nostr CMSよりも

WordPress
│
├─ HTML
├─ ActivityPub
├─ Standard.site
└─ Nostr

です。

つまり

記事
↓
WordPress

↓同時

Google
Bluesky
Fediverse
Nostr

です。

さらに先

もしNostrが大成功すると、

WordPressは

WordPress
↓
Nostr Editor

になります。

記事は

秘密鍵で署名
↓
Nostr公開

される。

ドメインすら必須ではなくなる。

その世界の本質

現在のWebは

サイト中心

です。

ActivityPubは

サーバ中心

です。

AT Protocolは

ID中心

です。

Nostrは

鍵中心

です。

もしWordPressが本格的にNostrネイティブ化したら、

「ブログを書く」という行為は

サイトに投稿する

から

自分の秘密鍵で出版する

へ変わります。

そのときWordPressはCMS（Content Management System）というより、

Nostr上の出版クライアントに近い存在になるでしょう。

ただし、私の予想

2030年までを見ても、

  • NostrがWordPressを置き換える確率 → 低い

  • Nostr連携がWordPress標準機能になる確率 → 中程度

  • ActivityPub連携が標準化する確率 → 高い

  • Standard.site/AT Protocol連携が標準化する確率 → 中〜高

です。

そのため最も現実的な未来は、

WordPress
↓
記事作成

↓同時配信

ActivityPub
AT Protocol
Nostr
検索エンジン

という「マルチプロトコル出版ハブ」です。

WordPressが消えるのではなく、WordPressが複数のソーシャル・出版プロトコルを束ねる中心になる可能性の方が高いと考えています。

Standard.site を理解するには、単に「Blueskyのブログ機能」と見るのではなく、

Web出版史
→ ブログ史
→ RSS史
→ ソーシャルメディア史
→ Fediverse史
→ AT Protocol史

の流れで見ると分かりやすいです。

Standard.siteに至る歴史

年代出来事意義
1989Tim Berners-Lee がWWWを提案Web誕生
1991World Wide Web公開ハイパーリンク時代
1993NCSA Mosaic 登場Web普及開始
1994RSSの源流となるサイト更新通知文化更新追跡の需要発生
1997weblogという言葉が普及ブログ文化の誕生
1999RSS 登場配信型Webの始まり
1999Blogger 公開個人出版の民主化
2001RSS 2.0ブログ黄金期開始
2003WordPress 公開CMS時代の始まり
2004Facebook 誕生ソーシャルグラフ時代
2006Twitter 誕生リアルタイムSNS時代
2007iPhone登場モバイルSNS時代
2009RSS利用率低下開始SNSへの移行
2010Facebookニュースフィード支配強化アルゴリズム時代
2012Google Reader終了発表RSS衰退の象徴
2013Google Reader終了オープンWeb弱体化
2014Mastodon 開発開始分散SNSの萌芽
2016Mastodon一般公開Fediverse拡大
2018ActivityPub がW3C勧告化Fediverse標準成立
2019IndieWeb運動拡大個人サイト回帰
2020Nostr 提案鍵中心SNS
2021Blueskyプロジェクト本格始動Twitter代替研究
2022Twitter買収騒動分散SNSブーム
2022AT Protocol公開新世代分散SNS
2023Bluesky 一般公開AT Protocol実戦投入
2024Bluesky急成長AT Protocol認知拡大
2024Atmosphere構想登場SNSを超えるATProto構想
2025長文コンテンツのATProto対応議論活発化ブログ統合の模索
2025Standard.siteプロジェクト開始出版スキーマ誕生
2026BlueskyがStandard.site記事をリッチカード表示実運用開始
2026WordPressやAstro系実装が登場CMS連携フェーズ

進化の流れ

第1世代（1990–2005）

Web
↓
HTML
↓
ブログ
↓
RSS

主役はサイト。

第2世代（2005–2020）

ブログ
↓
Facebook
Twitter
↓
SNS

主役はプラットフォーム。

第3世代（2020–2025）

ActivityPub
Nostr
AT Protocol

主役はプロトコル。

第4世代（2025–）

記事
↓
プロトコルネイティブ化
↓
Standard.site

主役はコンテンツそのもの。

RSSとの関係

Standard.siteはしばしば

RSS 3.0

と誤解されますが、実際には

RSSStandard.site
XML配信ATProtoレコード
更新通知ソーシャルオブジェクト
購読中心発見・推薦中心
Web専用ソーシャルWeb
作者情報が弱いDIDベース
ポータビリティ限定的高い

です。

ActivityPubとの関係

RSS
↓
ActivityPub
↓
AT Protocol
↓
Standard.site

という直線的な進化ではありません。

むしろ

                 RSS
                  │
                  ▼
            ブログ文化
                  │
        ┌─────────┴─────────┐
        ▼                   ▼
 ActivityPub         AT Protocol
        │                   │
        ▼                   ▼
 Fediverse         Standard.site

です。

なぜ今になって登場したのか

1999年のRSS時代には

記事
↓
配信

だけで十分でした。

2026年は

記事
↓
検索
↓
推薦
↓
AI要約
↓
ソーシャルグラフ

が必要です。

Standard.siteは

「RSSでは足りないが、SNSだけでも足りない」

という問題への回答として登場しました。

歴史的な位置付け

もし後世の教科書的に一行でまとめるなら、

技術歴史的役割
HTML文書公開
RSS文書配信
ActivityPub会話の分散化
AT Protocolソーシャルグラフの分散化
Standard.site出版物の分散化

と言えるでしょう。

その意味でStandard.siteは、1999年のRSS、2003年のWordPress、2018年のActivityPubに続く「分散出版インフラ」の新しい試みとして位置付けられます。

Standard.siteが本当に重要になる場合、その歴史的意義は単なる「Bluesky向けブログ規格」ではありません。

Web史の文脈では、

「Webページがソーシャルネットワーク上の第一級オブジェクトになった」

ことにあります。

HTMLの画期（1991）

Web初期

文書
↓
HTML
↓
URL

でした。

革命は

文書に永続的アドレスを与えたこと

です。

RSSの画期（1999）

記事
↓
RSS
↓
購読

になりました。

革命は

更新を取りに行かなくても届く

ことでした。

SNSの画期（2004–2006）

記事
↓
投稿
↓
アルゴリズム

になりました。

革命は

人が記事を見つけるのではなく、
フィードが記事を運ぶ

ことでした。

しかし代償として

Facebook
Twitter

が流通を支配しました。

ActivityPubの画期（2018）

SNS
↓
分散化

です。

革命は

ソーシャルグラフを企業から取り戻す

ことでした。

AT Protocolの画期（2022–）

AT Protocolは

アカウント
↓
ポータブル化

しました。

革命は

フォロワーを持ち運べる

ことです。

Standard.siteの画期

ここが本質です。

従来のブログは

記事
↓
URL

でした。

Standard.siteでは

記事
↓
URL

＋

記事ID
↓
ATProto

になります。

つまり

記事が

Webページ

であると同時に

ソーシャルオブジェクト

になります。

RSSとの決定的違い

RSSは

サイト
↓
フィード
↓
記事

です。

Standard.siteは

記事
↓
ネットワーク

です。

主語が

サイト

から

記事

へ移ります。

WordPress以来の転換点か？

比較すると

年技術変化
1991WWW文書を公開
1999RSS文書を配信
2003WordPress出版を民主化
2018ActivityPub会話を分散化
2022AT Protocolアイデンティティを分散化
2025–26Standard.site出版物を分散化

という位置づけになります。

もし普及すれば、

かなり大きな節目です。

AI時代との関係

ここが特に興味深い点です。

RSS時代は

人
↓
購読

でした。

Standard.site時代は

AI
↓
発見
↓
要約
↓
推薦

が前提です。

記事は単なるHTMLではなく

著者
タグ
出版物
更新履歴
所有権

を持つ構造化オブジェクトになります。

AIが扱いやすい。

Web史的に見た最大の意義

Webは長らく

サイト中心

でした。

例えば

WordPressサイト
Mediumサイト
Substackサイト

です。

Standard.siteは

記事中心

です。

極端に言うと

サイト
↓
重要ではない

記事
↓
重要

になります。

もし成功したら

将来は

記事を書く
↓
記事ID生成
↓
Standard.site登録
↓
どのアプリでも読める

になります。

今の

ブログを作る

という発想が

出版物をネットワークに公開する

へ変わる。

歴史家が後から振り返るなら

もしStandard.siteが定着した場合、その画期は

RSSが「サイトの更新」を配信したのに対し、Standard.siteは「記事そのもの」をネットワーク上の可搬なオブジェクトにしたこと

だと評価される可能性があります。

言い換えると、

  • HTML → 文書の標準化

  • RSS → 配信の標準化

  • ActivityPub → 会話の標準化

  • Standard.site → 出版物の標準化

という流れです。

だからStandard.siteの本当の勝負は「Bluesky対応」ではなく、

Webがサイト中心からコンテンツ中心へ移行する転換点になれるかどうかにあります。

コメント

コメントを投稿

このブログの人気の投稿

#INVIDIOUSを用いて広告なしにyoutubeをみる方法　#士17 #2018INVIDIOUSとOmarRoth_令和IT史ざっくり解説

https://www.youtube.com/watch?v=XXXXXXXXXX ↑のURL↓のように入れ替えると広告なしにyoutubeをみれる。 https://yewtu.be/watch?v=XXXXXXXXXX Invidious は、 YouTubeに代わる無料のオープンソースのフロントエンドです。 Dockerコンテナとして、またはGitHubマスター ブランチから利用できます。公式 YouTube Web サイトの軽量で「プライバシーを尊重した」代替サイトとして使用することを目的としています。多くのプライバシー保護リダイレクト ソフトウェアおよび YouTube クライアントは Invidious インスタンスを使用します。 Invidious は、YouTubeの動画を広告なしで視聴できる、プライバシーに配慮したオープンソースのサービスです。Googleのトラッキングを避けつつ、YouTubeコンテンツを楽しみたい方におすすめです。 Invidiousのメリット 広告なし: YouTubeの煩わしい広告をスキップできます。 プライバシー保護: Googleのデータ収集を抑え、プライバシーを重視した視聴が可能です。 オープンソース: 誰でも自由に利用・開発できるオープンソースソフトウェアです。 多様なインスタンス: 世界中に多くのInvidiousインスタンスが存在し、それぞれ異なる特徴や機能を提供しています。 Invidiousの使い方 Invidiousインスタンスを探す: 検索エンジン: "invidious instance"などで検索すると、多くのインスタンスが見つかります。 リスト: いくつかのInvidiousインスタンスをまとめたリストサイトも存在します。 YouTubeの動画URLをInvidiousの検索バーに入力: 視聴したいYouTube動画のURLをコピーし、選んだInvidiousインスタンスの検索バーに貼り付けます。 動画を再生: 検索結果から目的の動画を選択し、再生ボタンを押せば広告なしで視聴できます。 Invidiousの使い方 Invidiousは、YouTube動画を広告なしで視聴できる便利なサービスです。 基本的な使い方 Invidio...
MORE »

複数のRSSFeedを一つのURLにまとめる・統合する方法 #士30 #1999RSS_RDF・SiteSummary_平成IT史ざっくり解説

イメージ
  お気に入りのすべてのブログやニュースサイトからの複数のRSSフィードを追跡するのは簡単ではありません。 　この問題が発生した場合は、RSSアグリゲーターを使用して、複数のRSSフィードを1つのフィードに結合します。 　 RSSアグリゲーターは、複数のブログやサイトを持つコンテンツプロデューサーであり、読者やフォロワーへのサービスとしてRSSフィードを1つのフィードに結合したい場合にも役立ちます。 独自のパーソナライズされたニュースフィードを作成するために使用できる4つの無料のアグリゲーターツールを見てみましょう。 １http://www.rssmix.com http://www.rssmix.com 複数のフィードを1つのフィードに簡単に組み合わせることができます。特定の各フィードの完全なURLアドレスを 各行に1つずつ入力し 、[作成]を押します。最大100のフィードを、少なくとも2つ以上の固有のソースと組み合わせます。 RSS Mixは、集約されたフィードのアドレスを生成します。このアドレスを使用して、読者がすべてを1か所で最新の状態に保つことができます。 RSSMIXが死んでる？  2021/10.28あたりから不通 ２、 http://rssmixer.com/ http://rssmixer.com/ RSS Mixerはやや制限されたツールですが、フィードを混合するための超高速でシンプルなソリューションが必要な場合は、試してみる価値があります。 無料版では、1日1回更新される1つの混合RSSフィードに最大3つのフィードを組み合わせることができます。 より多くの機能が必要な場合は、1時間ごとに更新される10〜30の混合フィードを提供する有料プランにアップグレードしてください。 このツールは使いやすいです。メインフィードに名前を付け、説明を入力し、含めるURLを入力するだけです。 ３、 http://feed.informer.com/ http://feed.informer.com/ Feed Informerは、いくつかの異なるRSSフィード結合サービスを提供します。いくつかのフィードをすばやく統合したい場合は、 アカウントにサインアップ してから、FeedInformerのテンプレートを使用して結合するRSSフィードを入力しま...
MORE »

🚀Void登場！Cursorに代わるオープンソースAIコーディングIDEの全貌と未来とは？#AI開発 #OSS #プログラミング効率化　#五09 #2024VoidオープンソースAIコーディングIDE_令和IT史ざっくり解説

🚀Void登場！Cursorに代わるオープンソースAIコーディングIDEの全貌と未来とは？#AI開発 #OSS #プログラミング効率化 AIコーディングツールの新星「Void」を徹底解剖！Cursorとの違い、VSCodeフォークの是非、そして開発の未来をDopingConsommeが熱く語ります🔥 序文 どーも！売れっ子ブロガーのDopingConsommeです☕ dopingconsomme.blogspot.com とTwitterアカウント @Doping_Consomme を運営しています。バズるブログ記事ならお任せあれ！ さて、今回筆者が筆を執ったのは、巷で話題沸騰中のAIコーディングIDE「 Void 」について語り尽くしたいと思ったからです。Cursorの代替として彗星の如く現れたこのツール、オープンソースであるという点も相まって、開発者界隈では既に大きな注目を集めていますよね？ この記事では、Voidが一体どんなツールなのか、既存のツールと何が違うのか、そして私たちのコーディングライフをどう変えてくれる可能性があるのか、といった点を深掘りしていきます。読者の皆さんには、単なる機能紹介に留まらず、Voidを取り巻く議論や、AIと共存する未来の開発スタイルについて、多角的な視点から考えていただくきっかけになれば嬉しいです。それでは、熱いコーヒーでも片手に、じっくりお付き合いください！😉 はじめに この記事では、オープンソースのAIコーディングIDEである「 Void 」について、その特徴、機能、そして開発者コミュニティからの様々な意見を交えながら詳細に解説していきます。Voidは、人気のAIコーディングツール「Cursor」の代替を目指して開発されており、VSCodeをベースにしたフル機能のIDE（統合開発環境）です。AIエージェントの活用、ローカルでのモデル実行サポート、データのプライバシー重視といった点が主な特徴として挙げられます。 本記事を通じて、Voidがどのようなツールであり、現在のAIコーディングツール市場においてどのような位置づけにあるのか、そして将来的にどのような可能性を秘めているのかを明らかにしていきます。また、類似ツールとの比較や、開発におけるメリット・デメリット、さらにはコミュニティでの議論なども幅広...
MORE »