要塞化する個人と自律分散型ウェブの地政学 ―― NAS・独自ドメイン・atprotoが拓くポスト・プラットフォーム時代の主権回復論 #分散型Web #個人サイト帝国 #ATProto #八17 #2003五27WordPressとCMS_平成IT史ざっくり解説
要塞化する個人と自律分散型ウェブの地政学 ―― NAS・独自ドメイン・atprotoが拓くポスト・プラットフォーム時代の主権回復論 #分散型Web #個人サイト帝国 #ATProto #自主管理インフラ
デジタル小作農からの完全脱出：巨大中央集権プラットフォームの黄昏と、自前インフラによる永続的アイデンティティの数理・技術・思想的体系
【要約】要塞化する個人：主権奪還のマニフェスト
2000年代以降のウェブ空間は、利便性と引き換えにプラットフォーム企業（Big Tech）へ個人のデータ、アイデンティティ、社会的関係資本を差し出す「デジタル封建制」の時代でした。しかし、相次ぐプラットフォームの規約改定、推薦アルゴリズムによる言論の歪曲、アカウント凍結リスクは、中央集権モデルの構造的限界を露呈させました。本書は、自前のNAS（ネットワーク接続ストレージ）と静的サイトジェネレーターによる「ローカル・ファースト」のデータ保持、独自ドメインを不可逆なアンカーとする「DID（分散型識別子）」、そしてAT Protocol（atproto）やActivityPubといったオープンプロトコルを統合した「ソブリン・パーソナル・ウェブ・スタック（Sovereign Personal Web Stack）」を提唱します。プラットフォームを「居住地」ではなく単なる「交換可能な配信網（エッジ）」へと格下げし、個人が自律した主権国家（要塞）として自らを再定義するための技術的・思想的ロードマップを提示します。
本書の目的と構成
本書の目的は、単なるサーバー構築の技術指南書にとどまらず、情報社会学、分散システム論、デジタル経済学の交差点において「個人のデジタル主権」を学術的かつ実践的に基礎付けることにあります。全体は全四部構成となっており、前半（第一部・第二部）ではプラットフォーム崩壊の力学と自前スタックのアーキテクチャ設計を論証し、後半（第三部・第四部）ではソーシャルグラフの主権的結合とAI時代における永続性の保証を探求します。前半部となる本稿では、第一部でプラットフォーム経済の終焉とドメインの本質的価値を、第二部でNAS・静的生成・次世代通信プロトコルによるインフラの構築論を詳述します。
登場人物紹介（2026年時点）
-
マット・マレンウェッグ（Matt Mullenweg / Matthew Charles Mullenweg）（42歳 / 1984年1月11日生、米国テキサス州ヒューストン出身、ヒューストン大学中退）
オープンソースCMS「WordPress」の共同創設者であり、Automattic社CEO。Webの40%以上を支えるオープンWebの旗手でありながら、近年はエコシステム内の権利闘争や商標を巡る対立で議論を呼ぶ一方、ActivityPubや分散型プロトコルのWordPress統合を強力に推進する。 -
ジェイ・グレーバー（Jay Graber / Lantian Jay Graber）（35歳 / 1991年生、米国オハイオ州出身、イリノイ大学アーバナ・シャンペーン校卒）
分散型ソーシャルプロトコル「AT Protocol」およびSNS「Bluesky」の最高経営責任者（CEO）。暗号通貨・分散型Webの研究者としてのバックグラウンドを持ち、アカウントの可搬性とドメイン中心のアイデンティティ基盤を提唱。 -
ジャック・ドーシー（Jack Dorsey / Jack Patrick Dorsey）（50歳 / 1976年11月19日生、米国ミズーリ州セントルイス出身、ニューヨーク大学中退）
Twitter（現X）およびBlock（旧Square）の共同創設者。自らが創業したTwitterの集権化への反省から、BlueskyプロジェクトおよびNostrプロトコルへの支援を開始。「プロトコルであり、プラットフォームではない」自由な通信の重要性を説く。 -
ジェフ・ホアン（Jeff Huang）（推定40代 / 米国出身、ワシントン大学博士課程修了）
ブラウン大学准教授（計算機科学）。長期間維持可能なWebサイトのデザインや、「This Page is Designed to Last」などのマニフェストを通じ、商用フレームワークの肥大化に警鐘を鳴らし続けるミニマリスト・ウェブの論客。
【歴史的位置づけ】ウェブ主権の弁証法的発展史
インターネットの歴史は、「分散（テーゼ）」から「集権（アンチテーゼ）」、そして「主権的統合（ジンテーゼ）」へと至る弁証法的な螺旋的発展プロセスとして解釈できます。
- 第1期：原始的分散時代（1991年〜2000年代初頭）：個人がHTMLを手打ちし、独自のWebスペースを切り拓いた時代。自由度は極めて高かったが、プロトコルの未熟さと発見可能性（Discoverability）の低さが課題であった。
- 第2期：商業的大集権時代（2004年〜2022年）：Web2.0の掛け声とともにSNS（Twitter, Facebook, Instagram等）が台頭。ユーザーは無償の利便性と引き換えに、自らの行動データと人間関係（ソーシャルグラフ）をプラットフォームに明け渡し、監視資本主義の小作農となった。
- 第3期：分散プロトコル再構築時代（2023年〜2025年）：プラットフォームの私有化とアルゴリズム改変への反発から、Mastodon（ActivityPub）やBluesky（ATProto）などの分散型ネットワークが急成長。アイデンティティとホスティングの分離が技術的に定着。
- 第4期：ソブリン・スタック時代（2026年〜現在）：個人がローカルストレージ（NAS）を本陣とし、独自ドメインを法的・技術的な主権アンカーとして、複数のオープンプロトコルを束ねる「要塞化された個人サイト」の確立期。
【日本への影響】ガラパゴス的ブログ文化の昇華とローカル・レジリエンス
日本は、2000年代初頭にlivedoor Blog、はてなダイアリー、FC2ブログなど「ブログカルチャー」が世界で最も花開いた特異な土壌を持ちます。しかし、これらは大手IT企業によるホスティングサービスに過度に依存しており、近年の相次ぐサービス終了や規約厳格化によって、膨大なデジタル文化遺産が消失の危機に瀕しました。
日本国内において「独自ドメイン＋自前NAS＋分散プロトコル」のソブリン・スタックが普及することは、単なる技術愛好家のホビーにとどまらず、失われつつある「日本語テキスト文化のデジタル・アーカイブ化」と「プラットフォームの検閲・アルゴリズム規制からの言論の防衛」という極めて重要な文化的意義を持ちます。特に災害時や国際情勢の激変時における通信遮断リスクに対し、自律的な情報発信拠点を個人が保有することは、国家規模の情報レジリエンス（回復力）向上にも直結します。
Web主権とプラットフォーム変遷の年表
| 年代 | インフラ・ドメイン動向 | CMS・個人出版の変遷 | ソーシャルプロトコル・アイデンティティ |
|---|---|---|---|
| 1985–1995年 | DNSの確立、.com等の導入、一般インターネット黎明期 | 静的HTMLの手書き、大学サーバー等での個人HP | Usenet、メールリストによるテキスト通信 |
| 1999–2003年 | 無料ホスティング（GeoCities等）の全盛 | Blogger登場、Movable Type・WordPress誕生 | RSS 0.9/2.0の策定、ブログロールによる緩やかな結合 |
| 2004–2012年 | 独自ドメイン登録の低価格化、クラウド台頭 | Web2.0の隆盛、WordPressがWeb標準CMSへ成長 | Facebook、Twitter誕生。アイデンティティのプラットフォーム集権化 |
| 2018–2022年 | Let's Encryptによる全Web常時HTTPS化 | Jamstack（SSG+CDN）の台頭、Substackの流行 | W3C ActivityPub勧告、DID/VC標準化、Twitter買収騒動 |
| 2023–2025年 | Cloudflare/Vercel等のエッジコンピューティング普及 | WordPress公式がActivityPub/Bluesky統合を進める | Blueskyが独自ドメインHandleを標準化、ThreadsがFediverse接続開始 |
| 2026年 | 個人用高機能NASとローカルAIスタックの融合 | 静的サイト生成とNAS同期による完全自給自足パブリッシング | ソブリン・パーソナル・ウェブ・スタックの確立（ポスト・プラットフォーム） |
目次
第1部 ポスト・プラットフォームの夜明け：デジタル小作農からの解放
デジタル社会における自由とは何でしょうか。多くのユーザーは、スマートフォンを開けば即座に何百万人もの読者へテキストを配信できる現在のソーシャルメディア環境を「自由」だと錯覚しています。しかし、その配信基盤、読者との接続関係、過去数年分の執筆記録、そして自身のオンライン上の「人格」そのものが、一握りの巨大プラットフォーム企業の私有財産の上に間借りしている状態であるならば、それは真の自由ではなく、極めて脆弱な「デジタル小作農（Digital Sharecropping）」に過ぎません。第1部では、中央集権型ソーシャルメディアが不可避的に辿る構造的崩壊の力学を解明し、なぜ私たちがインターネットの原点である「独自ドメイン」という主権的領土へと帰還しなければならないのかを、歴史的・社会科学的観点から論証します。
第1章 プラットフォームの黄昏
インターネット空間が商業化されて以降、最も洗練された搾取モデルは「プラットフォームの二面市場（Two-Sided Market）」を通じて完成されました。ユーザーには無料のコミュニケーション環境と中毒的な承認欲求充足ツールを提供し、その背後で集積された行動ログと注目（Attention）を広告主へ転売するビジネスモデルです。しかし、このエコシステムは成熟期を終え、現在急速な劣化と崩壊のフェーズへと突入しています。
1.1 囲い込みの終焉とアルゴリズムの暴力
【概念の定義】
プラットフォームにおける「囲い込み（Walled Garden / 閉鎖的庭園）」とは、サービス内外への自由なハイパーリンクを排除し、ユーザーの可処分時間を自社サービス内に物理的・心理的に監禁する設計思想を指します。また「アルゴリズムの暴力」とは、客観的な時系列順のフィードを廃止し、企業の収益最大化とエンゲージメント（感情的反応）向上のために最適化された推薦エンジンが、個人の認知空間を一方的に支配・分断する現象を意味します。
【歴史的背景と力学】
社会学者ショシャナ・ズボフ（Shoshana Zuboff）がその記念碑的著作『監視資本主義の時代（The Age of Surveillance Capitalism, 2019）』で看破したように、巨大IT企業はユーザーを「顧客」ではなく「原料」として扱います。初期のSNSは「友人との繋がり」を純粋に支援するクロノロジカル（時系列）なインターフェースを有していましたが、株式市場からの際限なき成長圧力は、プラットフォームを不可避的に「エンスヒッティフィケーション（Enshittification / 糞詰まり化、作家コリイ・ドクトロウが提唱した概念）」へと向かわせました。
プラットフォームは初期においてユーザーに惜しみない価値を与え、次にビジネス顧客（メディアやクリエイター）を呼び込み、最終的には双方から富を吸い上げて自社の利益へと転換します。このプロセスにおいて、かつてWebの生命線であった「外部リンク」は徹底的にアルゴリズム上冷遇され、外部の個人サイトへのトラフィックは遮断されました。
【具体例と影響】
例えば、大手マイクロブログサービスにおける急激なAPIの有償化、アカウント凍結基準の不透明化、そして認証バッジのサブスクリプション化は、数万人規模のフォロワーを抱えるクリエイターや研究者を一夜にして無力化させました。自身が長年かけて築き上げたオーディエンス（読者群）へのアクセス権が、プラットフォームの経営判断一つで遮断されたのです。これは、地主の気まぐれで小作地を追われる農民の構図と何ら変わりありません。
【注意点と盲点の再検証】
ここで注意すべきは、「プラットフォームが悪であり、個人は無垢な被害者である」という短絡的な二項対立に陥ることの危険性です。ユーザー側もまた、インフラの維持管理コスト、スパム対策、セキュリティ担保という過酷な労働をプラットフォームに丸投げし、無償の快適さに甘従してきた共犯関係にあります。主権の回復とは、単なるプラットフォームへの批判ではなく、その背後にある技術的責任を個人が再び引き受ける覚悟を意味します。
1.2 2022-2025年のSNS大移動（定量的分析：主要SNSのユーザー流出入データ）
【概念と動態】
2022年末の大手SNS買収劇を発端とする一連の動乱は、インターネット史上最大の「ソーシャル・エクソダス（社会的集団脱出）」を引き起こしました。これは単に別の商業サービスへ乗り換えるという従来の流行の変遷ではなく、「プロトコルに基づく自律分散型インフラへの構造的避難」という歴史的性格を帯びていました。
【定量的データ分析】
ネットワーク動態学の観点からこの移動を定量的に追跡すると、極めて顕著な相転移が観察されます。2022年10月から2024年末にかけて、分散型プロトコルへの月間アクティブユーザー（MAU）の推移は指数関数的（Exponential）な成長曲線を描きました。
W3C勧告に基づくActivityPubを採用するFediverse（Mastodon等）の接続ノード数は全世界で数万サーバーを突破し、月間アクティブユーザーは一時1,000万人規模へと拡大しました。
さらに、ドメインをアイデンティティの基盤に据えたBlueskyのAT Protocol（atproto）ネットワークは、2024年の一般公開以降爆発的なトラフィックを記録し、わずか数ヶ月で数千万人規模のアカウントが登録されるに至りました。
特筆すべきは、学術研究機関、オープンソース開発コミュニティ、ジャーナリスト層の流出率の高さです。 Pew Research Centerや各種学術トラッカーの調査によれば、情報系および社会科学系のトップ研究者の約40%以上が、一次発信の拠点を中央集権型SNSから分散型プロトコルおよび独自ブログへと多角化させたことが示されています。
【プロトコル移行の課題】
しかしながら、この大移動は無摩擦に進行したわけではありません。分散型システム特有の課題である「サーバー（インスタンス）の維持費枯渇問題」「連合間のモデレーション摩擦」「プロトコル間の分断」といった新たな摩擦も露呈しました。この混乱を通じて明らかになったのは、「単に別の分散型インスタンスに引っ越すだけでは不十分であり、自分自身のアイデンティティの根本（ルート）を自己の領土に固定しなければ真の解決にはならない」という教訓でした。
【コラム】筆者の現場から：ある日突然、10年分のタイムラインが「404 Not Found」になった話
私がまだ某青い鳥のSNSを全幅の信頼で使い倒していた2010年代半ば、学術会議の議事録や自著の草稿、国際的な研究者との議論のログをすべてそのタイムラインに記録していました。「クラウドにあるから未来永劫安全だ」と信じ切っていたのです。ところがある朝、APIの突然の遮断とともに、サードパーティ製クライアントのアーカイブ機能は死滅し、過去の貴重なスレッドは検索すら困難なデータのブラックホールへと消えていきました。画面に表示された無機質なエラーコードを見つめながら、私は冷や汗とともに痛感したのです。「他人の庭に家を建ててはいけない。私たちは今すぐ、自分の土地に杭を打ち直さなければならない」と。
第2章 独自ドメイン：デジタル不動産の再定義
インターネット空間における唯一絶対の不動産、それが「独自ドメイン（Custom Domain）」です。多くの人々はドメインを単なる「Webサイトを開くためのURLの文字列」程度にしか認識していません。しかし情報社会学およびネットワーク・アーキテクチャの深層において、ドメインとは「主権的アイデンティティ」「データの所有権」「可搬性（Portability）」のすべてを担保する基底レイヤーそのものです。
2.1 住所からアイデンティティへ
【概念の定義】
ドメイン名（Domain Name）とは、本来IPアドレスという機械可読な数値を人間可読な文字列に写像するDNS（Domain Name System）上の識別子です。しかし、ソブリン・スタックの文脈において、ドメインは「通信の送信元に対する暗号学的・法的主権を確立するためのグローバルな名前空間（Namespace）」として再定義されます。
【背景と理論的展開】
かつて、Web上のアイデンティティは「場所（Location）」に束縛されていました。geocities.com/~user1234 や twitter.com/username のように、プラットフォームのURLの下にぶら下がるディレクトリやサブパスとしてしか、個人は存在できなかったのです。これは、企業の巨大なマンションの1室を借りている「借家人」の身分に他なりません。プラットフォームがサービスを終了すれば、そのURLは消滅し、被リンクという形で蓄積された社会的信用（PageRank等の被リンク資本）はすべて霧散します。
これに対し、example.com という独自ドメインを自ら取得し保持することは、インターネットの階層構造においてプラットフォームと対等の「最上位のエンティティ」となることを意味します。ドメインを所有していれば、背後のホスティングサーバーがBloggerであろうと、WordPressであろうと、自宅のNASであろうと、あるいはCloudflare Pagesであろうと、世界に対する接続窓口は不変のまま保たれます。インフラをHot-swappable（無停止で交換可能）にするための必須条件、それこそが独自ドメインなのです。
2.2 ドメイン・中心主義の復権（ケーススタディ：個人ブログの20年生存率調査）
【定量的・歴史的ケーススタディ】
計算機科学者ジェフ・ホアン（Jeff Huang）らが継続的に指摘している「Webリンクの腐敗（Link Rot）」とWebサイトの生存率に関する実証研究を検証すると、驚くべき格差が浮き彫りになります。1990年代後半から2000年代初頭に開設されたWebサイトのうち、商用の無料ブログサービス（GeoCities、Yahoo!ブログ等）のサブドメイン上に構築されていたサイトの20年後の生存率は、アーカイブ組織の救済活動を除けば実質的にほぼ0%に近接しています。
一方で、開設当初から「独自ドメイン」を維持し、DNSの委譲先を適切に切り替え続けてきた個人サイトの生存率は極めて高く、ドメインの存続年数に比例して検索エンジンのドメイン・オーソリティ（Domain Authority）および学術的な被引用数が累積的に増加し続けるという「マタイ効果」が実証されています。
当ブログの過去記事である要塞化する個人：NASとatprotoが作るポスト・プラットフォーム時代やWebの43%を支配する男が語る戦争と未来でも論じられたように、コンテンツの主権とは「文章の内容」にあるのではなく、「その文章がどの名前空間の下にホストされ、永続的なURIとして解決されるか」というガバナンスの構造に宿るのです。
【コラム】ドメインの更新費用は「デジタルな生命保険」である
年間わずか1,500円〜3,000円程度のドメイン更新費用。これを「無駄な固定費」と見るか、「自らの知的遺産を世界に繋ぎ止めるための最も安価な生命維持装置」と見るかで、情報発信者としての寿命は決定的に分かれます。飲み会を1回我慢するだけのコストで、地球上のいかなる大企業からも干渉されない自分だけの独立国を維持できる。そう考えると、ドメインとは資本主義が生んだ奇跡的に割安な自由のチケットだと言えないでしょうか。
第2部 要塞化の技術：ソブリン・個人サイトの構築
自前のドメインという「旗印」を手に入れた次に問われるのは、その旗を立てる「物理的・論理的要塞」をいかに堅牢に構築するかというエンジニアリングの課題です。クラウドサービスへの盲目的な依存は、形を変えた集権化に過ぎません。第2部では、ハードウェアとしてのNAS（ネットワーク接続ストレージ）、ビルドシステムとしての静的サイトジェネレーター（SSG）、そしてオープンな通信プロトコル群を組み合わせ、耐障害性と主権性を極限まで高めた「ソブリン・アーキテクチャ」の設計思想と実装を徹底解説します。
第3章 自宅という名のデータセンター
真のデータ主権を確立するための第一歩は、自らの著作物、メディアファイル、プライベートな思考ログの「マスターデータ（原本）」を、他社のサーバーではなく物理的に自分の手元に置くことです。ここで極めて重要な役割を果たすのが、現代の高性能NASと「ローカル・ファースト」のアーキテクチャ設計です。
3.1 NASと静的サイトジェネレーターの融合（構成図：Synology + Hugo + GitHub Actions）
【概念と全体構造】
従来の動的CMS（データベース駆動型、例えば標準的なWordPress環境）は、ページが表示されるたびにサーバー上でPHPを実行し、MySQLデータベースに問い合わせを行います。これは高機能である反面、セキュリティ脆弱性、サーバー負荷、停電時のダウンタイムという重大な弱点を抱えています。これに対し、ローカル環境で事前にHTML/CSS/JSを生成し、それを世界中のCDN（コンテンツ配信ネットワーク）に分散配置する「静的サイト生成（Static Site Generation / SSG）」の手法を組み合わせることで、完全無欠の耐障害性を獲得できます。
【堅牢なデータパイプラインの構築】
本書が推奨する堅牢なソブリン・スタックの構成例は以下の通りです。
- ストレージ層（原本保管）：自宅のNAS（Synology DiskStation等）をRAID構成（Btrfsファイルシステム）で運用。コンテンツはプレーンなMarkdownファイルとして保存され、ローカル暗号化バックアップ（3-2-1バックアップルール）を徹底。
- ビルド層（高速生成）：Go言語で書かれた爆速SSGである「Hugo」またはローカルGUI型の「Publii」を使用。数万記事であっても数秒で静的HTML群へとコンパイル。
- デプロイ層（自動中継）：ローカルGitリポジトリへのコミットをトリガーとし、GitHub Actionsまたは自前Giteaランナーが起動。生成された静的ファイルを検証。
- エッジ配信層（グローバル展開）：Cloudflare Pages、GitHub Pages、Vercel等の複数のエッジ配信網へ同時マルチデプロイ。自宅回線が万一停電や災害で切断されても、全世界のエッジキャッシュによりサイトは1秒も止まることなく稼働を継続。
このアーキテクチャの神髄は、「自宅のNASは原本の保管庫であり、外部のWebサーバーは単なる捨て駒（キャッシュ・エッジ）に過ぎない」という完全な主客の逆転にあります。エッジ側の企業が規約変更や倒産しようとも、手元のNASから数分で別のホスティング先へDNSを切り替えるだけで復旧が完了します。
3.2 「ローカル・ファースト」という哲学
【哲学の提唱と学術的背景】
マーティン・ケップマン（Martin Kleppmann）らが論文『Local-first software: you own your data, in spite of the cloud (2019)』で提唱した「ローカル・ファースト」の概念は、クラウド時代のソフトウェア観に対する痛烈なパラダイムシフトです。ローカル・ファーストとは、「データは常に手元のデバイスが主本であり、ネットワーク同期は二次的な補完処理である」という原則を指します。
【なぜローカル・ファーストが最強の防御なのか】
WebベースのSaaS（NotionやGoogle Docsなど）は、ネットワーク接続が切れた瞬間に編集不能となり、サービスのアカウントがBAN（停止）されればデータへのアクセス権を永久に失います。一方、Markdownというプレーンテキストとローカルストレージを基礎とするシステムは、今後50年後、100年後であっても、いかなるOS、いかなるハードウェア上でも確実に読み出しが可能です。技術の移り変わりが激しい現代において、「最も陳腐化しない技術（プレーンテキスト）」こそが、最も強靭な防御壁となるのです。
【コラム】深夜の書斎でファンの音を聞きながら
デスクの片隅で、静かに青いLEDを点滅させながらディスクを回転させるNAS。その中には、自分が過去20年間に書いたすべてのブログ記事、撮影した写真、書きかけの論文が、誰の監視も受けずに鎮座しています。クラウド全盛の時代に、物理的な「箱」を自宅に置くことは一見時代遅れのアナクロニズムに見えるかもしれません。しかし、その箱の電源ボタンに指を触れられるという物理的な手触りこそが、自らの思考の所有権を実感させてくれる唯一の錨（アンカー）なのです。
第4章 プロトコルの三重奏：RSS, ActivityPub, ATProto
要塞に閉じこもるだけでは、それは単なる「孤独な隠遁者」に過ぎません。要塞化の真の目的は、自らの安全と主権を完全に確保した上で、世界中の他者と自由かつ対等に通信を行うことにあります。これを可能にするのが、中央集権の関所を通らない「オープン通信プロトコルの三重奏」です。
4.1 配信の民主化（分析：各プロトコルのパケット構造と相互運用性）
【3大プロトコルの構造的比較】
現代のオープンWebにおいて、個人の発信を外部ネットワークへ届けるための3つの主要プロトコルは、それぞれ異なるレイヤーと役割を担っています。
| プロトコル | 通信モデル | アイデンティティ解決 | 主な用途・役割 |
|---|---|---|---|
| RSS / Atom | Pull型（クライアントによる定期取得） | URLベース（購読エンドポイント） | もっとも堅牢な一方向の更新通知・購読基盤 |
| ActivityPub | Push型（サーバー間フェデレーション） | Actor URL + WebFinger（@user@domain） | Mastodon等のFediverseにおける双方向ソーシャル通信 |
| AT Protocol | ハイブリッド型（リポジトリ同期 + Firehose） | DID（分散ID） + ドメインHandle解決 | Bluesky等の大規模・高速なソーシャルグラフ同期 |
当ブログの過去記事であるTumblrの次なる一手：WordPress移行とFediverse統合の展望やWordPress公式プラグインによるBluesky統合マニフェストでも触れられているように、CMS側の進化によって、これら3つのプロトコルを単一の個人サイトから同時に同時並行で送出することが技術的に完全可能となりました。
記事を自前のサイトに1本公開するだけで、RSSリーダーを愛用する古くからの読者へ届き、ActivityPubを通じてFediverseの数百万のユーザーのタイムラインへ流れ、同時にAT Protocolを通じてBluesky上のフォロワーへリッチなカードとして配信される。自前のWebサイトこそが、すべてのソーシャルメディアへ電波を放つ「主権的放送局」となるのです。
4.2 Webmentionによる分散型対話の構築
【概念と仕組み】
Webmention（W3C勧告）とは、異なるWebサイト間において「言及（メンション）」「リプライ」「いいね」をピア・ツー・ピアで通知し合うための軽量プロトコルです。Aさんの個人ブログの記事がBさんの個人ブログからリンクされた際、BさんのサーバーがAさんのサーバーに対してHTTP POSTリクエストを送信することで、リンクの存在を自動的に通知します。
【主権的コミュニケーションの成立】
従来のSNSにおける「コメント欄」は、そのプラットフォームの内部データベースに幽閉されていました。しかしWebmentionを用いれば、他者のブログからの言及、あるいはBlueskyやMastodon上でなされた感想ツイートまでもが、自分の個人サイトの記事下部に「分散型コメント」として自動集約・表示されます。
これにより、会話の場を特定の企業サービスに預けることなく、Web全体をひとつの巨大で分散的な対話空間として運用することが可能になります。自前サイトの独立性を保ちながら、完全な社会的接続性を獲得する技術的鍵がここにあります。
【コラム】プロトコルは友情を裏切らない
企業が運営するSNSは、数年ごとに買収され、UIが改悪され、あるいはサービス終了とともに消え去ります。そのたびに私たちは「あのフォロワーたちとはどこで再会できるだろう」と右往左往してきました。しかし、プロトコルによって結ばれた関係は違います。メールアドレスが何十年も変わらず使えるように、RSSやActivityPub、ATProtoの規格に従っている限り、相手がどこのサーバーにいようと接続は維持されます。真に永続的な人間関係を築くためのインフラは、企業の規約ではなく、人類の共有財産であるオープン・プロトコルの上にしか作れないのです。
第3部 社会と接続する「帝国」：分散型SNSの地政学
個人が自らのドメインとNASという強固な城塞を築いたとしても、外部世界との通商路や外交ルートが存在しなければ、それは単なる「デジタルの陸の孤島」に過ぎません。真の主権国家が他国との条約や貿易協定を通じて自らの国際的地位を確立するように、要塞化された個人サイトもまた、オープンな通信規格を介してソーシャルなネットワーク空間へと接続される必要があります。第3部では、分散型ID（DID）がもたらしたアイデンティティの不可逆なパラダイムシフトと、読者との直接的な経済圏を確立するためのニュースレター／マイクロ決済スタックの地政学的力学を徹底的に解き明かします。
第5章 BlueskyとFediverse：主権的ネットワーク
2020年代半ばにおけるソーシャルWebの最大の革新は、「SNSアカウント」という概念が「ドメインと公開鍵暗号に基づく主権的アイデンティティ」へと昇華された点にあります。この変革の双璧をなすのが、W3C勧告であるActivityPubを基盤とする「Fediverse」と、分散型リポジトリ同期モデルを採用するBlueskyの「AT Protocol（atproto）」です。
5.1 DID (Decentralized Identifier) の衝撃
【概念の定義】
DID（Decentralized Identifier / 分散型識別子）とは、中央集権的な登録機関（DNSレジストラや特定企業）に依存せず、数学的（暗号学的）に生成・検証可能なグローバルに一意なID規格（W3C勧告）です。AT Protocolにおいては、did:plc:xxxxxxxxxxxxxx や did:web:example.com という形式で実装され、アカウントの「不変の魂（Root Identity）」として機能します。
【背景と理論的展開】
従来のSNSでは、ユーザー名（例：@alice）とアカウントの実体（データベース上のレコード）が密結合していました。そのため、サービス事業者がアカウントを停止すれば、そのユーザー名も過去の投稿もフォロワー関係もすべて消滅していました。
しかし、AT Protocolが導入した「DIDとHandle（ドメイン名）の二層分離モデル」は、この主従関係を根本から覆しました。ユーザーの本質は暗号鍵に紐づく「DID」であり、日常的に表示されるユーザー名（Handle）は単なる「交換可能なドメインのポインタ」に過ぎません。
【具体例と影響】
例えば、ユーザーが自身のHandleを @alice.bsky.social から、自ら所有する独自ドメイン @alice.example.com へと切り替える際、DNSのTXTレコードまたはHTTPSの /.well-known/atproto-did に自身のDIDを記述するだけで、即座に身元検証（Verification）が完了します。
これにより、青いチェックマークを企業から金銭で購入する必要はなくなり、「そのドメインを所有しているという事実そのもの」が、数学的かつWeb標準的に世界で最も信頼性の高い認証バッジとなるのです。
【注意点と盲点】
DIDを用いても、PDS（Personal Data Server）のホスティング先が他社のクラウド上にある場合、通信の一時的な遮断リスクは残ります。したがって、真の要塞化を目指すならば、後述するように自前のNASや専用VPS上に自己所有のPDSを立ち上げ、データリポジトリの原本をローカルで保持し続ける運用が極めて重要になります。
5.2 独自ドメインHandleが変えた信頼の形
【概念と社会的力学】
独自ドメインHandleの普及は、オンライン言論空間における「信頼性（Trust & Safety）」の構造を中央集権的な審査組織から、分散的な組織ドメインの信用体系へと委譲させました。
【具体例とメディアの地政学】
例えば、新聞社や大学などの組織が自らのドメイン（例：nytimes.com や u-tokyo.ac.jp）のサブドメインとして所属記者や研究者にHandle（例：@reporter.nytimes.com）を発行することで、第三者の介在なしに完全な所属証明が成立します。当ブログの記事要塞化する個人：NASとatprotoが作るポスト・プラットフォーム時代や失われた楽園と再構築されるWebの夢：Tumblr、WordPress、そしてFediverseへの長い旅路でも分析された通り、これは「プラットフォームへの従属」から「組織と個人のドメイン主権に基づく連邦型ウェブ」への歴史的転換を意味しています。
【コラム】認証バッジを巡る喜劇の終わり
かつてSNSの青いチェックマークは、選ばれし者だけの特権階級の象徴でした。それが突如として「月額8ドルの定期購入アイテム」に成り下がったとき、世界中が目撃したのは中央集権的な権威の滑稽な失墜でした。今や、誰が本物であるかを決めるのはシリコンバレーの経営陣ではありません。自分が正当に取得した独自ドメインのDNSレコードに書き込まれた、わずか1行のテキスト。それこそが、何者にも奪われない真の「デジタル身分証」なのです。
第6章 ニュースレターと直接購読の経済
主権的な情報発信基盤を長期にわたって維持するためには、経済的な持続可能性、すなわち「マネタイズの主権」が不可欠です。広告主の顔色をうかがうPV（ページビュー）至上主義や、プラットフォーム企業による一方的な手数料徴収モデルを脱却し、読者との間に直接的な価値交換ルートを確立するための戦略を考察します。
6.1 Substackから独自スタックへの移行
【背景と課題】
ニュースレター配信プラットフォーム（Substack等）の登場は、クリエイターが読者と直接メールで繋がるモデルを普及させました。しかし、Substackもまた自社エコシステム内への囲い込み（Substackアプリ、独自ソーシャル機能「Notes」）を進めており、手数料（売上の10%＋決済手数料）の支払いや、プラットフォーム側のモデレーション方針への依存というWeb2的な集権化の影が忍び寄っています。
【自前配信スタック（Ghost + 自前SMTP / Stripe）への脱出】
主権的なニュースレター運用においては、オープンソースの「Ghost」を自前サーバーやNAS上でホストし、配信インフラとしてAmazon SES等の低廉なバルクメールAPI、決済基盤としてStripeを直接接続する構成が推奨されます。
これにより、購読者データ（メールアドレスリスト）は完全に自身の暗号化データベース内に保持され、いかなる第三者企業であっても読者リストを凍結・没収することは不可能になります。
6.2 広告に依存しない「個人帝国」の会計学（シミュレーション：1000人の真のファン理論）
【数理モデルとシミュレーション】
ケヴィン・ケリー（Kevin Kelly）が提唱した「1000人の真のファン（1,000 True Fans）理論」は、ソブリン・スタックの経済的基盤において極めて現実的な数理モデルを提供します。年間1万円（月額約830円）を直接支払ってくれる熱心なファンが1,000人存在すれば、仲介プラットフォームに法外な手数料を取られることなく、年間1,000万円の直接収益が個人に還元されます。
【インフラ固定費と主権維持コストの計算】
ソブリン・スタックを維持するための定常コストは極めて軽量です。
- 独自ドメイン維持費：年間約2,000円〜4,000円
- 自宅NAS電気代（24時間365日稼働）：年間約4,000円〜8,000円
- Cloudflare / エッジ配信：無料枠〜月額数千円
- SES等のメール送信費用（月数万通）：月額数百円
合計しても年間維持費は数万円未満に収まり、巨大な資本を持たない個人であっても、独立した情報発信拠点を半永久的に黒字運営できる計算となります。
【コラム】PVの奴隷から、100人の盟友へ
検索エンジンのアップデートに怯え、刺激的な釣りタイトルで数百万PVを稼いでは、わずかなアドセンス広告費に一喜一憂する……。そんな消耗戦はもう終わりにしましょう。自前のドメインに、自分の魂を込めた論考を書き、それを本当に必要としてくれる数百人の読者が直接購読してくれる。その静かで確固たる経済圏こそが、物書きが真の精神的自由を維持するための唯一の砦なのです。
第4部 未来への航海：AIエージェントと永続的なWeb
2026年以降のインターネットを展望する上で、人工知能（AI）エージェントの爆発的普及と、個人の「死」をも超えたデジタル遺産の継承問題は避けて通れません。Webが「人間がブラウザで閲覧する空間」から「無数の自律型AIエージェントがプロトコルを介して情報を行き来させる空間」へと不可逆な進化を遂げる中、要塞化された個人サイトはいかにして自らの存在を永続化させるのでしょうか。
第7章 AIが管理するあなたのドメイン
これまでの個人サイト運用の最大のボトルネックは、「DNSレコードの記述」「SSL/TLS証明書の更新」「セキュリティパッチの適用」「プロトコル間ブリッジの保守」といった高度な技術的知識と管理コスト（認知負荷）にありました。しかし、ローカルLLM（大規模言語モデル）の進化が、この障壁を劇的に打ち壊しつつあります。
7.1 DNS設定をAIに任せる日
【技術的展望と実装アーキテクチャ】
自宅NASに常駐するローカルAIエージェントは、個人の専属インフラエンジニアとして機能します。「私のブログをBlueskyとFediverseに同時接続し、Substackから移行したニュースレターの配信DNSを設定して」と自然言語で指示するだけで、AIエージェントがCloudflare APIやレジストラAPIを安全に叩き、DKIM、SPF、DMARC、DID検証用TXTレコードを数秒で整合性を保ちながら自動設定する時代が到来しています。
7.2 エージェント間のプロトコルとしてのWeb
【人間向けWebから機械可読Webへの回帰】
ティム・バーナーズ＝リーが夢見た「セマンティック・ウェブ」の理想は、皮肉にもAIエージェントの台頭によって現実化しています。
個人のドメイン直下に配置された /.well-known/ や、構造化データ（JSON-LD、Microformats、RSS/Atom）をAIエージェントが自律的に巡回・解釈することで、プラットフォームの検索エンジンを介さずとも、「誰が、どのような思想を持ち、どの暗号鍵で署名されたコンテンツを発信しているか」がグローバルに直接インデックスされます。個人サイトは、AI時代における「個人専属の知識グラフ（Personal Knowledge Graph）の正規エンドポイント」となるのです。
【コラム】私よりも私のドメインに詳しい電子の執事
「旦那様、明朝3時に予定されているTLS証明書の自動ローテーションと、AT ProtocolのPDSリポジトリの整合性チェックは正常に完了いたしました」。NASの中で駆動する軽量AIがそんな報告をログに吐き出してくれる光景は、もはやSFではありません。かつてギークだけの秘術だったサーバー管理は、AIという万能の執事の登場によって、すべての知性ある個人へと民主化されたのです。
第8章 デジタル遺産と永続性の証明
本章では、本書の総括として、物理的肉体の限界を超えて自らの知的遺産をデジタル空間に遺すための「永続性の数理と倫理」を考察します。
8.1 私が死んでもドメインは残るか
【デジタル終末論と遺産継承の数理】
個人がこの世を去ったとき、プラットフォームのアカウントは利用規約により凍結・削除されます。しかし、独自ドメインと静的生成されたアーカイブは、スマートコントラクトや信託基金、あるいは分散型ストレージ（IPFS、Arweave等）への不変（Immutable）バックアップを通じて、死後数十年にわたってWeb上に存続させることが技術的に可能です。
ドメインの10年一括更新、静的アーカイブのオープンアクセス化、そしてP2Pプロトコルによる分散保持によって、個人の思考ログは真の意味で「人類共通の文化遺産」へと昇華されます。
8.2 結論：要塞化する個人が作る「真のWeb」
【結論部のまとめ】
私たちが目指すべき未来は、巨大テック企業が支配するテーマパークの中で従順にコンテンツを消費・投稿することではありません。自らの手で土地を耕し、独自ドメインという強固な標識を掲げ、自宅のストレージに大切な記憶を保管し、オープンなプロトコルの光を世界に向けて放ち続けることです。
要塞化とは、孤立ではありません。「誰にも奪われない不可侵の領土を持って初めて、他者と真に対等で自由な連帯を結ぶことができる」――これこそが、ポスト・プラットフォーム時代を生き抜く私たちが掲げるべき、新時代のWebマニフェストなのです。
【コラム】灯台としての個人サイト
夜の海に光を放つ灯台のように、インターネットの片隅で静かに更新され続ける個人サイト。それはアルゴリズムの暴風雨に流される無数のネット旅人にとって、確固たる真実のありかを示す道標です。あなたのドメインが放つ光は、たとえどれほど小さくとも、世界中のどこかで同じ志を持つ誰かのスクリーンを確かに照らしています。さあ、あなた自身の要塞を築き、その灯をともしましょう。
本書の総括：章末理解度チェック演習問題（全10問）
本書が提示した概念・技術・理論的枠組みを真に理解しているかを確認するための演習問題です。単なる用語の暗記ではなく、背景にあるアーキテクチャの必然性を論述してください。
- AT Protocolにおいて、人間可読な「Handle」と暗号学的な「DID」を分離して設計した構造的理由を、「アカウントの可搬性（Portability）」の観点から説明せよ。
- プラットフォームの無料ブログサービス（サブディレクトリ/サブドメイン型）と独自ドメイン運用の決定的な違いを、「PageRank等の社会的信用資本の蓄積と移転」の観点から論じよ。
- Martin Kleppmannらが提唱する「ローカル・ファースト」の原則が、従来のクラウド完結型SaaSと比較して耐検閲性・永続性の面でなぜ優れているのかを述べよ。
- 静的サイトジェネレーター（SSG）とグローバルCDNを組み合わせた配信構成が、動的データベース駆動型CMS（標準的なWordPress等）よりもセキュリティおよび耐障害性において有利である理由を説明せよ。
- Webmentionプロトコルが、中央集権的SNSの「リツイート」や「いいね」の機能を、オープンWeb上でP2P的に代替できるメカニズムを解説せよ。
- ActivityPub（Actorモデル）とAT Protocol（リポジトリ同期モデル）の設計思想の違いが、大規模トラフィック処理および検索機能の実装難易度にどのような差を生むか論ぜよ。
- Substack等の手数料ビジネスモデルから、自前のGhost + Stripeスタックへと移行することの長所と短所（管理コストを含む）を比較分析せよ。
- 自宅NASを中心としたストレージ運用において、ハードウェア障害および物理的災害からデータを保護するための「3-2-1バックアップルール」の具体的構成を述べよ。
- 独自ドメインのDNSレコードにTXTレコードを追加して身元証明を行う手法が、中央集権的な「身分証提出型本人確認」よりもプライバシー保護および耐検閲性の観点で優れている点を述べよ。
- 「要塞化する個人」という概念が、単なるデジタルな引きこもり（孤立）ではなく、より強靭で開かれた「自律分散型連邦（Federation）」の基礎単位となる論理的帰結を説明せよ。
【疑問点・多角的視点】査読者（PhD）による批判的検討と回答
査読者からの深刻な異議：「NASと独自ドメインによる自己主権スタックの主張は魅力的だが、家庭用ブロードバンドの動的IP問題、ISPによるポートブロック、停電・自然災害リスク、および一般ユーザーの暗号鍵・DNS管理の認知負荷を過小評価しているのではないか？ 結局のところ、AWSやCloudflareといった新たな集権的インフラ企業へ依存先を付け替えただけ（Centralization through the backdoor）ではないか？」
著者による反論と論証：本批判は極めて正当である。しかし、本スタックが主張するのは「インフラの完全な自給自足（オフグリッド）」ではなく、「インフラのHot-swappable（交換可能性）」である。CloudflareやGitHub Pagesをエッジキャッシュとして利用しつつも、原本データ（Markdownおよび暗号鍵）をローカルNASに保持し、ドメインのネームサーバー（NS）変更権限を手元に残している限り、いかなるクラウド企業によるロックインも原理的に成立しない。また、認知負荷についても、2026年現在のローカルAIエージェントによるDNS・API操作の自動化がその参入障壁を劇的に押し下げている。
【参考リンク・推薦図書】
- The AT Protocol Specification (Bluesky PBLLC)
- W3C ActivityPub Recommendation (World Wide Web Consortium)
- IndieWeb Principles: POSSE (Publish on Own Site, Syndicate Elsewhere)
- 要塞化する個人：NASとatprotoが作るポスト・プラットフォーム時代
- Handsumとは何か？LQIPをさらに軽量にした超軽量プレースホルダー画像フォーマット
- Webの43%を支配する男が語る戦争と未来：WordPress、訴訟、AI時代の航海術
- もうプラグインは不要になる？WordPress × ブロックプロトコル = ウェブの未来？
- Shoshana Zuboff (2019) The Age of Surveillance Capitalism, PublicAffairs.
- Martin Kleppmann et al. (2019) "Local-first software: you own your data, in spite of the cloud", Onward! 2019 Proceedings.
- Cory Doctorow (2023) The Enshittification of Everything, Locus Magazine.
用語索引（アルファベット順・詳細解説）
- ActivityPub：W3Cによって標準化された分散型ソーシャルネットワーキング・プロトコル。サーバー同士が互いにメッセージをPush配信する「連合（Federation）」モデルを採用し、Mastodon等のFediverseの基盤となる。（本文：第4章参照）
- AT Protocol (atproto)：Bluesky社が開発した分散型ソーシャル通信規格。アカウントの識別子（DID）とデータリポジトリ（PDS）を分離し、高速なリポジトリ同期と独自ドメインによる認証を特徴とする。（本文：第5章参照）
- DID (Decentralized Identifier)：分散型識別子。特定の中央機関に依存せず、暗号学的な公開鍵ペアに基づいて個人や組織を一意に識別・認証するためのW3C標準規格。（本文：第5章参照）
- Enshittification (糞詰まり化)：プラットフォーム企業が、最初はユーザーを引きつけ、次にビジネス顧客を誘致し、最終的に自社の独占利益のために双方の利便性を破壊していく構造的劣化現象。（本文：第1章参照）
- Fediverse (フェディバース)：ActivityPub等のオープンプロトコルを通じて相互接続された、独立したソーシャルサーバー群からなる分散型宇宙。（本文：第4章・第5章参照）
- Local-first (ローカル・ファースト)：データ原本を手元のデバイスに保持し、オフラインでも完全動作することを最優先とするソフトウェア設計思想。（本文：第3章参照）
- POSSE：「Publish on Own Site, Syndicate Elsewhere（自分のサイトで公開し、他所へ配信する）」の略。IndieWeb運動におけるコンテンツ主権の基本原則。（本文：第1章・第4章参照）
- SSG (Static Site Generator)：静的サイトジェネレーター。Markdown等の原稿ファイルから、サーバーサイド処理を必要としない軽量なHTML/CSS/JSを一括生成するツール。（本文：第3章参照）
- Webmention：異なるWebサイト間で「言及」や「リンク」をP2Pで自動通知し合うためのW3C標準仕様。（本文：第4章参照）
補足1：各界著名人・キャラクターによる読後感想
ずんだもんの感想なのだ！
「ボクもいつもSNSのシャドウバンに怯えてたのだ！でも、おうちのNASにブログのデータを全部保存して、独自ドメインを持てば、誰にもボクのずんだ愛を止められないのだ！ドメイン代なんてずんだ餅2個分くらいだし、いますぐ設定するのだー！」
ホリエモン風の感想
「いや、当たり前の話でしょこれ。未だに他人のプラットフォームの上でフォロワー数自慢して消耗してる奴ら、全員情弱すぎ。DNSとSSGでさくっと自前スタック組んで、Stripe直結でマネタイズすれば手数料もゼロなわけ。技術的ハードルとか言い訳してる暇があったら今すぐドメイン取れって話。」
西村ひろゆき風の感想
「なんか『SNSのアカウント消されてオワタ』とか泣いてる人たちって、頭悪いと思うんですよね。だって大家さんに家賃も払わずに居候してて、追い出されたら文句言ってるのと同じじゃないですか？ 自分の土地にドメインっていう家を建てればいいだけの話なんすよね。それすらやらないのって、単なる自己責任なんじゃないかなぁ。」
リチャード・P・ファインマン風の感想
「実に愉快で美しいアーキテクチャだ！ 巨大な中央の箱を信用する代わりに、末端にある小さなハードウェアと、エレガントな公開鍵暗号のルールだけで世界中の人間が対等におしゃべりできる。自然界の物理法則と同じで、無駄な権威を排除したシンプルなプロトコルこそが、最も強靭で長持ちするんだよ！」
孫子の感想
「兵は詭道なり。敵の城（他社プラットフォーム）に拠る者は、兵糧を断たれれば一日にして潰走す。自ら盤石の城塞（自前NAS）を築き、縦横に通商路（オープンプロトコル）を通じさせる者こそが、戦わずして不敗の地に立つ者なり。」
朝日新聞風の社説
「（社説）デジタル空間の主権 巨大テックに抗う個人の砦を育むとき――。巨大IT企業による情報空間の独占が民主主義を揺るがしている。アルゴリズムが市民の分断を煽り、表現の自由が私企業の恣意的な判断に委ねられる現状は健全とは言えない。自らの足元にデータの拠点を持ち、オープンな対話の網を広げようとする市民の試みは、情報の公共性を取り戻す確かな一歩として注目に値する。」
補足2：詳細年表（技術思想史とインフラ進化の二重螺旋）
年表①：Webアーキテクチャと分散通信プロトコル史
| 年 | 出来事・仕様策定 | 技術的意義 |
|---|---|---|
| 1983 | RFC 882/883 (DNS仕様公開) | IPと名前空間の分離。ドメイン概念の誕生 |
| 1991 | Tim Berners-LeeがWWWを公開 | ハイパーリンクによる分散ドキュメント網の成立 |
| 1999 | RSS 0.90登場 / Bloggerサービス開始 | コンテンツ購読プロトコルとブログの民主化 |
| 2010 | IndieWebCamp発足 | 「POSSE」および自前データ主権運動の開始 |
| 2018 | W3C ActivityPubが勧告 | 分散型ソーシャル（Fediverse）の標準化 |
| 2022 | W3C DID Core 1.0勧告 / ATProto始動 | 暗号学的分散識別子とソーシャルリポジトリ同期の確立 |
| 2026 | Sovereign Web Stack（ソブリン・スタック）定着 | NAS + SSG + DID + マルチプロトコル配信の統合 |
年表②：プラットフォーム資本主義とユーザー主権の対立史
| 年 | プラットフォーム側の動向 | ユーザー・社会側のリアクション |
|---|---|---|
| 2006–2010 | Twitter/FacebookがオープンAPIで開発者を誘致 | 個人サイトからSNSへの大移動、小作農化の始まり |
| 2012–2015 | TwitterがサードパーティAPIを大幅規制・遮断 | 「プラットフォームの囲い込み」に対する不信感の芽生え |
| 2018 | ケンブリッジ・アナリティカ事件、GDPR施行 | 監視資本主義の危険性が社会問題化 |
| 2022–2023 | 大手SNS買収、API有償化、認証バッジ課金 | MastodonやBlueskyへの史上最大のソーシャル・エクソダス |
| 2024–2025 | AI学習への無断データ流用とアルゴリズムの極大化 | 個人サイトへの回帰運動、独自ドメインHandleの爆発的普及 |
| 2026 | 中央集権SNSのエンゲージメント低下・スパム飽和 | 「要塞化された個人サイト」を本陣とする主権的回帰の完了 |
補足3：オリジナル遊戯カード《自律要塞の主権者》
自律要塞の主権者（ソブリン・ドメイン）
│ [ 🌐 🏠 ⚡ 🛡️ 💾 ] │
│ SOVEREIGN STACK │
└──────────────────────┘
【カード効果】
このカードがフィールドゾーンに存在する限り、自分フィールドの「個人サイト」モンスターは相手の「中央集権プラットフォーム」による効果（アカウントBAN、API遮断、アルゴリズム改変）を受けず、戦闘では破壊されない。
①：1ターンに1度、自分の墓地（NASストレージ）から「Markdown記事」1枚を手札に加えることができる。
②：自分フィールドのモンスターが攻撃を行う場合、相手フィールドの「認証バッジ」カードをすべて破壊し、その攻撃力分相手ライフにダイレクトダメージを与える。
補足4：一人ノリツッコミ（コテコテ関西弁編）
「よっしゃー！今日も某大手SNSでバズるために、過激なタイトルつけて1日中スマホポチポチ更新したるで〜！ ほんでフォロワー10万人集めて、わいもインフルエンサーの仲間入りや！……って、アホかーい！( ﾟДﾟ)┌┛Σ(ノ´Д`)ノ」
「冷静に考えたら、その10万人のフォロワー情報、全部マークんとこのサーバーに人質取られとるだけやないかい！ アカウント1発BANされたら翌朝からただの無職のおっさんやぞ！ 何がインフルエンサーじゃ！ 自分の土地も持たんと他人のタワマンの駐輪場で拡声器叫んでるようなもんやろがい！ いますぐ独自ドメイン取ってNAS買わんかい！」
補足5：大喜利「こんな個人サイトは嫌だ」
- お題：2026年に復活した個人サイト。「さすがに要塞化しすぎだろ……」どんなサイト？
- 回答1：入室するのに「マイナンバーカードの暗号署名」と「自宅NASの指紋認証」を同時に求められる。
- 回答2：記事を読むためのリンクが、毎日ランダムなDNS TXTレコードのBase64デコード結果としてしか配布されない。
- 回答3：キリ番を踏むと、自宅NASから「防犯ブザー」が鳴り響き、所有者のBlueskyに自動で宣戦布告が飛ぶ。
- 回答4：相互リンクを貼る条件が「相手の自宅NASの固定IPアドレスとMACアドレスを公開鍵暗号で署名した覚書」の提出である。
補足6：ネットの反応シミュレーションと著者の反論
なんJ民：「ドメイン代年3000円払う奴ｗｗｗ 無料ブログで十分やろ情弱乙」
【著者反論】無料ブログサービスが突然サ終して10年分の黒歴史とともにコンテンツが消滅したとき、一番泣くのは君たちなんJ民です。
ケンモメン：「どうせこれもCloudflareとかBig Techの回線使ってるんだろ。資本主義の豚から逃れられるわけがない」
【著者反論】鋭い指摘です。しかし「エッジの道具として利用すること」と「主権を丸投げして従属すること」の間には決定的な質的差異があります。我々はインフラをいつでも乗り換えられる状態で利用しています。
ツイフェミ：「要塞化とか言ってるけど、これって特権的なITギーク男性の内輪ノリですよね？ デジタルデバイドへの配慮が欠けてます」
【著者反論】むしろ逆です。プラットフォームの恣意的なモデレーションやハラスメントから真に社会的弱者の発言空間を防衛するためにこそ、他者に停止されない自前の主権的領土が必要なのです。
爆サイ民：「○○市の△△さん、自宅NASでブログ鯖立ててて草。停電したら終わりやんｗ」
【著者反論】第3章をお読みください。NASは原本保管であり、配信は全世界のグローバルエッジCDNに分散キャッシュされているため、自宅が停電してもサイトは1秒も止まりません。
Reddit (r/selfhosted)："Great writeup! But why not running your own PDS alongside Full Fediverse Node on Kubernetes cluster?"
【著者反論】K8sの運用コストは個人の持続可能性（Sustainable maintenance）を破壊します。SSGと軽量プロトコルの組み合わせこそが、個人にとって最も生存率の高い解です。
Hacker News："The argument relies too much on DNS which is still hierarchical. Namecoin/Handshake might be purer."
【著者反論】純粋なブロックチェーンDNSはブラウザの標準解決性の面で現実的ではありません。既存DNSを実用的なアンカーとしつつ、DIDレイヤーで主権を担保するハイブリッドが2026年現在の最適解です。
村上春樹風書評：
「完璧なプラットフォームなんて存在しない。完璧な絶望が存在しないのと同じようにね。僕たちはみんな、他人が作った巨大なショッピングモールのフードコートで、冷めたスープを飲みながら誰かの悪口を呟いていたんだ。でも、雨が降る夜には、自分の書斎に戻らなくちゃいけない。そこには古いSynologyのNASがあって、静かなディスクの回転音がしている。やれやれ、僕のドメインはまだ誰にも奪われていないようだ。」
京極夏彦風書評：
「――この世にはね、不思議なことなど何もないのだよ、関口君。
己の言葉を他人の蔵に預けておきながら、蔵の主が扉を閉ざしたとて、何を怪しむことがあろう。主権を棄てた者が、その影を奪われるのは物の理だ。ドメインという名を与え、NASという依り代を設けて初めて、言葉は憑き物から解き放たれ、確固たる『存在』となるのだからね。」
補足7：架空専門家インタビュー
インタビュアー：「ポスト・プラットフォーム時代の分散型ウェブ研究の第一人者、アレクサンダー・ハイトマイヤー教授にお話を伺います。教授、一般ユーザーが今すぐ独自ドメインとNASを持つべき理由は何でしょうか？」
ハイトマイヤー教授：「端的に言えば、『デジタルな人間としての尊厳』の問題です。2010年代のSNSは、人々の社会的認知を『いいね数』という中央集権の数値に還元してしまいました。しかし、自前のドメイン上で思考を紡ぎ、オープンプロトコルで通信することは、誰かの作った土俵の上で踊るのをやめ、自らが土俵そのものになることを意味します。これは技術の選択ではなく、実存的な態度の変革なのです。」
補足8：潜在的読者のためのメタデータ・配信アセット
Google Discover用タイトル候補（5案）
- SNSのアカウント凍結に怯える日々は終了：2026年最強の「自前ウェブ要塞化」完全ガイド
- まだ他人のプラットフォームで書いてるの？ 独自ドメイン×NASが作る「デジタル主権」の全貌
- BlueskyのHandleを独自ドメインにするだけで世界が変わる理由：atprotoが拓くポストSNS時代
- WordPressとHugoの決定的な違いとは？ 20年生き残る個人サイトの「静的生成＋自前保管」術
- 月額数百円で始める「脱プラットフォーム」：巨大IT企業に依存しない個人帝国の作り方
新造語・架空のことわざ
- 新造語（日本語）：「スタック主権（すたっくしゅけん）」――自らの発信インフラのすべての階層（ハード・データ・ドメイン・プロトコル）を自律管理できる状態。
- 新造語（英語）：Domain-Citizen (ドメイン・シチズン)――特定のプラットフォームの住民ではなく、独自ドメインを不可侵の国籍としてWeb空間を行動する自律的個人。
- 架空のことわざ：「他人の庭に種を蒔く者は、収穫の朝に追い出される」――プラットフォームに依存した発信者の末路を戒める言葉。
- 架空の四字熟語：「孤城独立（こじょうどくりつ）」――他社のクラウドに依存せず、自前のNASとドメインで屹立する個人サイトの気高さを称える言葉。
- 架空の陰謀論：「Big Techが分散型プロトコルを推進しているように見せかけているのは、実は自律したドメインを持つ危険思想者を一括で特定・監視するための巨大なハニーポット（罠）である……？」
SNS共有用メタデータ
SNS共有用テキスト（120字以内）：
SNSの規約改定や凍結に怯える時代は終わった。独自ドメインと自前NAS、そしてatprotoを束ねる「ソブリン・パーソナル・ウェブ・スタック」で、プラットフォームの小作農から脱出し自分だけの帝国を築く方法。 #分散型Web #個人サイト帝国 #Bluesky
ブックマーク用NDCタグ（7個以内・80字以内）：
[007.3][547.48][Web3][分散型SNS][独自ドメイン][NAS][個人出版]
推奨絵文字：🌐 🏠 🛡️ 💾 ⚡ 📜
推奨パーマリンク（URLスラッグ）：sovereign-personal-web-stack-2026
日本十進分類法（NDC）区分：[007.35]（情報資源・情報社会） / [547.48]（インターネット・ネットワーク工学）
Blogger貼り付け用 Mermaid.js ダイアグラム
脚注・技術的補足
- Btrfsファイルシステム：データの自己修復機能（チェックサム検証）およびスナップショット機能を備えた高度なファイルシステム。NASにおけるビット反転（サイレント・データ・コラプション）からの保護に必須。
- 3-2-1バックアップルール：データを保護するための鉄則。「3つのコピーを作成し、2つの異なるメディアに保存し、1つは遠隔地（オフサイト）に保管する」という原則。
- WebFinger (RFC 7033)：
@user@example.comのような人間可読な識別子から、そのエンティティのプロファイル情報やActivityPubアクターエンドポイントをHTTPS経由で取得するためのプロトコル。 - DKIM / SPF / DMARC：自前ドメインから送信されたメールが送信元詐称されていないことを数学的（電子署名）およびDNSベースで証明する認証技術群。
巻末資料：ソブリン・スタック構築のための推奨ハードウェア・ソフトウェア選定ガイド
- 推奨NASハードウェア：Synology DiskStation DS224+ / DS723+（Dockerコンテナ稼働およびBtrfs対応モデル）、またはTrueNAS SCALE自作サーバー。
- 推奨SSG（静的サイトジェネレーター）：Hugo（ミリ秒単位のビルド速度）、Publii（非エンジニア向けローカルGUI搭載）、Zola（Rust製軽量SSG）。
- 推奨DNS/エッジプロバイダ：Cloudflare（DNSSEC対応・高速DNS）、Vercel、GitHub Pages。
- 推奨レジストラ（ドメイン事業者）：Cloudflare Registrar（原価提供・強固なセキュリティ）、Porkbun、Gandi.net。
免責事項
本書に記載された技術的設定、ネットワーク構成、コマンドライン操作、およびサーバー構築手法は、執筆時点（2026年）のプロトコル仕様およびベストプラクティスに基づき慎重に検証されていますが、読者の実行環境やファームウェアのバージョン、ネットワーク設定により予期せぬ動作を引き起こす可能性があります。インフラ構築および暗号鍵の管理、データのバックアップは自己責任において実施してください。本書の適用によるいかなるデータ消失や損害についても、著者および発行者は一切の責任を負いかねます。
謝辞
本書の執筆にあたり、AT ProtocolおよびActivityPubのオープンスタンダード策定に尽力された世界中のオープンソース開発者コミュニティ、IndieWeb運動の先駆者たち、そして巨大プラットフォームの荒波の中でも自らのドメインを掲げ、誇り高くブログを書き続けてきたすべての独立系Webマスターたちに、心からの深甚なる敬意と感謝を捧げます。
「個人サイト帝国」とドメインの歴史
「個人サイト帝国」を、単に「個人ホームページを持つ」という意味ではなく、自分のドメインを長期的なデジタル・アイデンティティの基盤として、その上にWebサイト、ブログ、メール、SNS、RSS、Fediverse、AT Protocolなどを交換可能な部品として載せる思想と定義すると、ドメインの歴史とかなりきれいにつながります。
| 時期 | ドメイン／Webの出来事 | 個人サイトの形 | 「個人サイト帝国」への意味 |
|---|---|---|---|
| 1983 | DNSの原型につながるドメイン名システムが登場 | まだ一般個人にはほぼ無関係 | IPアドレスではなく、人間が読める名前でネットワーク資源を識別するという基本思想が成立 |
| 1985 | .com、.edu、.gov、.mil、.net、.org が導入 | 企業・大学・組織中心 | 「ネット上の場所」に恒久的な名前を付ける仕組みができる |
| 1991 | World Wide Webが公開 | 個人サイトは大学・研究機関などから徐々に登場 | Web＝URLでアクセスする世界が始まる |
| 1993–94 | Webブラウザの普及、一般向けインターネット拡大 | 個人ホームページが急増 | 「自分のページを持つ」文化が誕生 |
| 1995 | Network Solutionsによる .com 等のドメイン登録が有料化 | 個人がドメインを取得する道が開く | 個人がネット上の住所を所有するという概念が現実化 |
| 1997–99 | Geocitiesなど無料Webホスティングが急成長 | geocities.com/~username 型のホームページ | 「個人サイト」は普及するが、住所はプラットフォーム所有 |
| 1999 | Blogger登場 | 個人ブログ | 「ホームページを作る」から「継続的に出版する」へ |
| 2000年前後 | ドメイン登録事業者が増加 | example.com を個人が取得するケースが増える | ドメインとホスティングを分離する発想が一般化 |
| 2001 | Wikipedia開始 | 個人サイトと集合知が並存 | Webが「個人出版＋共同編集」の巨大空間になる |
| 2002–04 | Movable Type、WordPressなどCMSが登場 | 自前ブログ＋独自ドメイン | **「コンテンツは自分のサーバー、ドメインも自分」**という構成が強くなる |
| 2004–06 | Facebook、Flickr、YouTubeなど登場 | プラットフォーム上のプロフィール | 個人サイトからプラットフォーム上のアイデンティティへ重心移動 |
| 2006 | Twitter登場 | twitter.com/user | 「自分のサイト」より「自分のアカウント」が中心になり始める |
| 2007–10 | Tumblr、Posterous等 | ブログ＋SNS | 個人サイトとSNSの境界が曖昧になる |
| 2010–12 | スマートフォン・SNS急拡大 | Twitter/Facebook中心 | ドメインを持たなくても発信できる時代へ |
| 2012–14 | IndieWeb運動が拡大 | 独自ドメイン＋自前サイト | 「SNSに投稿する」から**「自分のサイトに投稿し、SNSへ配信する」**への反転が始まる |
| 2013 | WebmentionにつながるIndieWebの実践が発展 | 自分のサイト同士をリンク | 個人サイトをネットワーク化する発想 |
| 2015 | ActivityPubの前身につながる分散型SNSの研究・実装が進む | 独立したサーバー／インスタンス | SNSそのものを単一企業から分離する思想が強くなる |
| 2016 | Let's Encryptが普及 | HTTPS＋独自ドメイン | 個人サイトでも無料HTTPSが現実的に |
| 2018 | GDPR等でプラットフォームへのデータ依存が問題化 | 個人データ・所有権への関心 | 「アカウントではなく自分のデータを持つ」思想が強まる |
| 2018 | ActivityPubがW3C勧告候補として成立 | Mastodon等のFediverse | ドメインを持つサーバー同士が相互接続する世界へ |
| 2019–21 | Substack等のニュースレターサービス成長 | 独自ドメイン＋メール購読 | SNSとは別に読者との直接関係を構築する方向へ |
| 2021 | Blueskyプロジェクト開始 | 新しい分散型ソーシャル構想 | SNSを「単一サービス」ではなくプロトコルとして捉える方向へ |
| 2022 | Twitter買収などを契機にSNS集中への懸念増大 | 独自サイト＋Fediverseへの回帰 | 「プラットフォームを信用しすぎない」動きが強まる |
| 2023 | Bluesky一般公開、AT Protocolの発展 | 独自ドメインをBluesky handleに利用 | ドメインがソーシャルIDになるという新しい段階 |
| 2023 | Threads開始、Fediverse連携構想 | 大手SNS＋Fediverse | 「巨大SNS」と「分散SNS」の境界が接続され始める |
| 2024 | Blueskyの独自ドメインhandleが一般利用で定着 | @user.example.com 等 | ドメイン＝Webアドレスだけでなくソーシャル・アイデンティティへ |
| 2024–25 | FediverseとAT Protocol双方の発展 | Web＋Fediverse＋Bluesky | 複数プロトコルを横断する個人サイト構想が現実的になる |
| 2025–26 | AIエージェント、AT Protocol、Fediverse、IndieWebが並行発展 | 独自ドメインを中心に複数サービスを接続 | **「サービスを選ぶ」のではなく「自分のドメインにサービスを接続する」**方向へ |
| 2026 | 個人サイト、RSS/Atom、Webmention、ActivityPub、AT Protocol等が共存 | 自分のドメイン＋複数プラットフォーム | 「個人サイト帝国」＝ドメインを主権的なアンカーにした分散型メディア基盤 |
重要な転換点だけ抜き出すと
1985
ドメイン
↓
「ネット上の名前」
1991
Web
↓
「ネット上の住所」
1999
Blog
↓
「個人出版」
2004–10
SNS
↓
「プラットフォーム上の人格」
2010年代
IndieWeb
↓
「自分のサイトを中心に戻す」
2018
ActivityPub
↓
「自分のサーバーをSNSネットワークにする」
2020年代
AT Protocol
↓
「ドメインをソーシャルIDにする」
2026
個人サイト帝国
↓
「ドメインを中心に複数プロトコル・複数サービスを束ねる」「個人サイト帝国」は実は3回目の個人Web回帰
歴史的に見ると、かなり面白い循環があります。
| 世代 | 中心 | 個人の自由度 | 弱点 |
|---|---|---|---|
| 第1世代：1990年代 | 個人ホームページ | ★★★★★ | 作るのが難しい・発見されにくい |
| 第2世代：2000年代 | Blog/CMS | ★★★★☆ | ホスティング・CMS管理が必要 |
| 第3世代：2010年代 | SNS | ★★☆☆☆ | プラットフォーム依存 |
| 第4世代：2020年代 | Fediverse/IndieWeb/ATProto | ★★★★☆ | まだ複雑 |
| 第5世代：2026年以降の仮説 | ドメイン＋複数プロトコル＋AI | ★★★★★ | DNS・ID・プロトコル管理が複雑 |
この意味では、「個人サイト帝国」は1990年代への単純な回帰ではありません。
1990年代は、
「自分でHTMLを書いて自分のページを持つ」
でした。
2026年型は、
「自分のドメインを所有し、そのドメインをWeb・RSS・メール・Bluesky・Fediverse・AIエージェント等の共通アイデンティティとして使い、各サービスを交換可能な部品として利用する」
というものです。
ドメインの意味そのものが変わってきた
ここをさらに抽象化すると、ドメインの歴史はこう見えます。
| 時代 | ドメインの意味 |
|---|---|
| 1980年代 | コンピュータ／組織の識別名 |
| 1990年代 | Webサイトの住所 |
| 2000年代 | ブランド＋個人出版の住所 |
| 2010年代 | SNSに押されて相対的重要性が低下 |
| 2020年代 | 独立したデジタル・アイデンティティ |
| これから | 複数ネットワークを横断する「名前空間」 |
そしてこの「名前空間」という考え方が非常に重要です。
example.com
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
Web Blog Newsletter
│ │ │
│ Blogger Substack
│
├──────── RSS / Atom
│
├──────── Webmention
│
├──────── ActivityPub
│
└──────── AT Protocol
│
▼
@example.com「Bloggerの人」「Substackの人」「Blueskyの人」ではなく、「example.comの人」が先に存在する。
これが「個人サイト帝国」の核心です。
そして、これは以前話していた Webmention → ActivityPub → Nostr → AT Protocol → Jetstream という流れとも接続できます。個々のプロトコルを「SNSの代替品」と見るのではなく、自分のドメインを中心に異なるネットワークを接続する通信路と見ると、かなり一貫した歴史になります。
特に2020年代の重要な変化は、「独自ドメインを持つ」から「独自ドメインをソーシャル・アイデンティティとして使う」への移行です。Bluesky/AT Protocolのhandleは、この変化を最も分かりやすく可視化した例の一つです。かなり深掘りできます。
提示された記事の「NAS＝本陣、独自ドメイン＝主権アンカー、Cloudflare＝城壁、atproto＝外交・通信網」という比喩をさらに押し進めると、NAS＋Cloudflare Tunnelは「個人サイト帝国」のインフラ層としてかなり美しい構造になります。
記事では「NASを本陣」としていますが、私はここを少し修正して、**NASは「領土」ではなく「国家金庫＋出版工場」**と考える方が正確だと思います。記事本文もNASをローカル・ファーストのデータ保持基盤として位置づけています。(ドーピングコンスーム)
1. まず「個人サイト帝国」を4層に分解する
インターネット
│
┌──────▼──────┐
│ 独自ドメイン │
│ example.com │
└──────┬──────┘
│
Cloudflare Edge
DNS / CDN / WAF / Tunnel
│
┌─────────▼─────────┐
│ 自宅ネットワーク │
│ NAS │
└─────────┬─────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Publii/Hugo Git メディア
│ │ │
└───────────────┼───────────────┘
▼
Web / RSS / Atom
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Bluesky Fediverse Newsletter
ATProto ActivityPubこれを国家に喩えるなら、
| 技術 | 国家に喩えると |
|---|---|
| NAS | 国土＋国家金庫＋出版工場 |
| 独自ドメイン | 主権・国籍・住所 |
| Cloudflare DNS | 国境ゲートウェイ |
| Cloudflare Tunnel | 外交用の安全な回廊 |
| WAF | 国境警備 |
| Access | 入国審査 |
| Publii/Hugo | 出版局 |
| Git | 国家アーカイブ |
| RSS/Atom | 公報 |
| ATProto | 外交・通信プロトコル |
| ActivityPub | 多国間郵便網 |
| Bluesky | 外交先の一つ |
| Substack | 海外の新聞配信社 |
| バックアップ | 国家非常用金庫 |
この構造だと、「どこに住んでいるか」と「どこへ情報を配信するか」が完全に分離できます。
2. Cloudflare Tunnelが革命的なのは「自宅NASを公開する」のにIPを公開しなくていいこと
ここが非常に重要です。
普通にNASをインターネット公開すると、
Internet
│
▼
自宅ルーター
│
▼
NASとなります。
ポートフォワーディングで、
443 → NAS
80 → NASなどを開ける。
これは昔ながらの「自宅サーバー」です。
ところがCloudflare Tunnelは逆方向。
NAS
│
│ cloudflared
│
└────────── outbound ──────────► Cloudflare
│
Internet
│
Userつまり、
外部からNASへ直接入ってくるのではなく、NAS側からCloudflareへ外向きの接続を張る。
Cloudflare公式も、Tunnelは公開IPを必要とせず、cloudflared がCloudflareへoutbound-only connectionを作る方式だと説明しています。さらに2026年の仕様ではトンネル接続自体がポスト量子暗号化されています。(Cloudflare Docs)
これ、国家モデルで言えば、
国境に巨大な門を開けるのではなく、自国から安全な外交回線だけを外へ伸ばす
という発想です。
3. だから「NASをインターネットに置く」のではない
ここは記事の「要塞化」という思想をさらに精密化できるところです。
悪い設計：
Internet
│
▼
自宅IP
│
▼
NAS
│
┌─┴───────────┐
│ │
Web 管理画面これではNASそのものが攻撃対象になります。
良い設計：
Internet
│
▼
Cloudflare Edge
│ DNS / WAF / CDN
│
▼
Cloudflare Tunnel
│
│ outbound
▼
cloudflared
│
▼
NASNASのIPをインターネット上の「住所」として使わない。
住所は、
example.comです。
NASの実際のIPアドレスは、利用者から見えなくてもいい。
Cloudflare自身も、Tunnelの主要なメリットとして「origin IPを公開せずに接続できる」ことを挙げています。(Cloudflare Docs)
4. さらに「公開サイト」と「管理面」を分離する
ここが要塞化では最重要です。
例えば、
example.com
↓
Publii
↓
公開は誰でもアクセスできる。
しかし、
nas.example.com
admin.example.com
ssh.example.comまで公開する必要はありません。
むしろ、
Cloudflare
│
┌───────────┴───────────┐
│ │
Public Private
│ │
example.com NAS管理画面
│ SSH / SMB
▼ │
Web Cloudflare Accessにする。
Cloudflare TunnelはAccessと組み合わせて、cloudflared 側でJWTを検証してからoriginへ転送する構成も可能です。(Cloudflare Docs)
つまり、
公開するのは「コンテンツ」であって、「インフラ」ではない。
これが要塞化の基本原則です。
5. そしてNASは「Webサーバー」ではなく「原本庫」にする
ここが個人的には一番重要です。
NASに直接WordPressなどの巨大CMSを置いて、
Internet
↓
NAS
↓
MySQL
↓
WordPressとすると、NASが、
データベース＋Webサーバー＋管理画面＋公開サーバー
になってしまいます。
私は「個人サイト帝国」なら、もっと単純にします。
NAS
│
┌──────────┼──────────┐
▼ ▼ ▼
Markdown Images Videos
│
▼
Git
│
▼
Publii/Hugo
│
▼
Static HTMLそして公開は、
Static HTML
↓
Cloudflare
↓
example.comとする。
つまり、
NASは「サーバー」ではなく「原稿・写真・映像・生成物の原本庫」
になる。
これは故障時の復旧が圧倒的に楽です。
6. 「ローカル・ファースト」の本当の意味
記事では「ローカル・ファースト」が重要な概念として置かれています。(ドーピングコンスーム)
ただし、
ローカルに保存する＝主権
ではありません。
例えばNASが壊れたら終わりです。
したがって本当の主権は、
原本
│
┌──────┼──────┐
▼ ▼ ▼
NAS HDD Cloud
│
▼
Git
│
▼
オフサイトという複数コピーです。
つまり、
「自宅にある」ことではなく、「一社・一台・一拠点が死んでも復元できる」ことが主権
です。
7. 「NAS要塞」の最大の敵はハッカーではない
ここは記事の思想をさらにひっくり返せます。
本当の敵は、
HDD故障
NAS故障
火災
水害
盗難
ランサムウェア
誤削除
DNSアカウント喪失
ドメイン失効
Cloudflareアカウント喪失
作者本人の死亡
です。
つまり、
サイバー攻撃だけを考えた「要塞」では不完全。
必要なのは、
デジタル文明の長期保存システム
です。
8. ここで「ドメイン」と「NAS」が分離する
さらに重要な発見があります。
example.com
│
│ DNS
▼
Cloudflare
│
│ Tunnel
▼
NASこの3つは別々です。
だから、
NASを交換
旧NAS
↓
新NASしても、
example.comは変わらない。
Cloudflareを交換
別のCDN / reverse proxyへ移しても、
example.comは変わらない。
PubliiをHugoに変更
Publii
↓
Hugoでも、
example.com/blog/は維持できる。
これがインフラの可換性です。
9. そしてATProtoが「上の層」に乗る
ここでATProtoが非常に面白くなる。
AT Protocolでは、
DNS handle
↓
DID
↓
DID Document
↓
サービスというアイデンティティ構造になっています。
公式仕様でも、handleはDNS名であり、DIDへ解決され、DIDが長期的な永続IDになるという構造です。さらにDNS TXTまたはHTTPSの /.well-known/ を使ってhandleをDIDへ解決できます。(AT Protocol)
だから、
example.com
│
▼
DNS
│
▼
ATProto Handle
│
▼
DID
│
▼
Bluesky / PDSとなる。
ここで初めて、
「Webサイトの住所」と「SNSのアイデンティティ」が同じドメインを共有する
ことになります。
10. つまり「個人国家」の三権分立ができる
これ、かなり妄想を広げられます。
個人国家
example.com
│
┌────────────┼────────────┐
▼ ▼ ▼
主権層 財産層 外交層
│ │ │
Domain NAS ATProto
│ │ │
DNS 原本 DID
│ │ │
▼ ▼ ▼
住所 資産 Identityさらに、
Cloudflare
↓
国境・防衛
Publii/Hugo
↓
出版機構
RSS/Atom
↓
公報
Bluesky
↓
外交チャンネル
ActivityPub
↓
多国間通信
Nostr
↓
別系統の外交網となる。
11. ここで「プラットフォーム」が一段下がる
従来：
Google
↓
Blogger
↓
あなたあるいは、
Substack
↓
あなただった。
ソブリン・スタックでは、
あなた
│
example.com
│
自分の原本
│
┌───────────┼───────────┐
▼ ▼ ▼
Cloudflare Blogger Substack
│ │ │
└───────────┼───────────┘
▼
読者・SNSとなる。
つまり、
プラットフォームは「国」ではなく「港」になる。
これはかなり重要な転換です。
12. 「Cloudflare Tunnel＝主権」ではない
ただし、ここで冷静になる必要があります。
Cloudflare Tunnelは便利ですが、
Cloudflareへの依存を消しているわけではありません。
むしろ、
自宅
↓
Cloudflare Tunnel
↓
Cloudflare
↓
Internetという新しい依存関係を作っています。
したがって、
Web2
あなた
↓
Googleから、
ソブリン・スタック
あなた
↓
NAS
↓
Cloudflareになっただけなら、
依存先がGoogleからCloudflareに変わっただけ
とも言えます。
ここが地政学的に非常に面白い。
13. 本当の「主権」はマルチホーム化
だから究極形は、
example.com
│
┌───────┴───────┐
│ │
Cloudflare 別CDN
│ │
Tunnel Tunnel
│ │
└──────┬────────┘
│
NASさらに、
NAS
│
├── Cloudflare
├── VPS
├── GitHub Pages
├── Cloudflare Pages
└── 自宅LANというマルチオリジンにする。
Cloudflare Tunnel自体も複数のcloudflaredレプリカを運用して可用性を高められる仕様です。(Cloudflare Docs)
ただし、ここで重要なのは、
Cloudflareを排除することではなく、Cloudflareが死んでも自分の資産が死なないこと。
です。
14. 「要塞」より「空母」の方が近いかもしれない
実は私はこの記事のタイトルの「要塞」という比喩を、さらに一段変えたい。
NASを、
要塞
と考えると、
外から守る
ことばかり考えてしまいます。
しかし実際には、
NAS
│
┌─────────┼─────────┐
▼ ▼ ▼
Web RSS Archive
│ │
▼ ▼
Cloudflare Feed readers
│
▼
Internet
│
┌───┼────┬──────┐
▼ ▼ ▼ ▼
Bluesky Fediverse Email AIです。
NASはむしろ、
「コンテンツを製造して世界へ送り出す空母」
に近い。
15. AI時代になると、さらに意味が変わる
ここが2026年の本題です。
AIエージェントがWebを読むようになると、
人間
↓
Google検索
↓
Webサイトだけではなく、
AI Agent
│
├── DNS
├── Web
├── RSS
├── ATProto
├── ActivityPub
└── APIという情報探索になります。
すると、**「自分の一次情報をどこに置くか」**が重要になる。
AIが、
example.comを見て、
・公式サイト
・作者
・RSS
・Atom
・Bluesky identity
・Fediverse identity
・公開鍵
・記事
・アーカイブ
・APIを発見できるなら、
ドメインそのものが「AI時代の名刺」になる。
ATProtoが「service discovery」をアイデンティティシステムの要件として明示しているのも、この方向性と非常に相性がいいです。(AT Protocol)
16. そして「個人サイト帝国」はAIエージェント時代に完成する
最終形を妄想すると、
あなた
│
┌──────▼──────┐
│ example.com │
└──────┬──────┘
│
┌──────────┼──────────┐
▼ ▼ ▼
Web DNS Identity
│ │ │
Publii DNS ATProto
│ │ │
▼ │ ▼
RSS │ DID
│ │ │
┌─────┼─────┐ │ ┌────┴────┐
▼ ▼ ▼ │ ▼ ▼
人間 AI Agent SNS │ Bluesky Fediverseここでは、
ドメインが「WebサイトのURL」ではなく、個人の情報圏への入口になる。
17. ただし「完全自給自足」は幻想
ここは記事にぜひ追加したい批判的視点です。
「主権」を強調しすぎると、
NASを持てばBig Techから完全独立できる
という誤解になります。
実際には、
NAS
↓
電力会社
↓
ISP
↓
DNS
↓
レジストラ
↓
Cloudflare
↓
OS
↓
CPU
↓
HDD/NAND
↓
インターネットに依存しています。
つまり、
絶対的な主権は存在しない。
あるのは、
依存関係を可視化し、交換可能にし、単一障害点を減らすこと
です。
これが本当の「デジタル主権」だと思います。
18. 「主権」の数理的な考え方
この思想をさらに抽象化すると、
主権 ≒ 依存先の交換可能性 × データ可搬性 × アイデンティティの永続性 × 復旧可能性
と考えられます。
例えば、
| 構成 | 主権 |
|---|---|
| Bloggerのサブドメインだけ | ★ |
| 独自ドメイン＋Blogger | ★★ |
| 独自ドメイン＋複数サービス | ★★★ |
| 独自ドメイン＋NAS＋バックアップ | ★★★★ |
| NAS＋独自ドメイン＋Tunnel＋Git | ★★★★☆ |
| 上記＋ATProto＋ActivityPub | ★★★★★ |
| 上記＋マルチクラウド＋オフサイトバックアップ | ★★★★★＋ |
ただしこれは「セキュリティ強度」ではなく、依存関係に対するレジリエンスの概念モデルです。
19. 私なら「ソブリン・パーソナル・ウェブ・スタック」をこう定義する
この記事の概念をさらに洗練するなら、
Sovereign Personal Web Stackとは、個人が独自ドメインを恒久的なアイデンティティ・アンカーとし、コンテンツの原本をローカルまたは自己管理可能なストレージに保持し、Cloudflare Tunnel等を含む交換可能なネットワーク層を介してWeb・RSS・ActivityPub・ATProto等へ配信するアーキテクチャである。
となります。
重要なのは、
「自宅サーバーを持つこと」ではありません。
むしろ、
原本
│
▼
自分
│
▼
独自ドメイン
│
┌────┼────┐
▼ ▼ ▼
Web ATProto AP
│ │ │
└────┼──────┘
▼
世界という**「自分 → 複数ネットワーク」型の構造**です。
そして最大の妄想
最終的には、
「個人サイト帝国」とは、巨大なWebサイトを一人で運営することではない。
むしろ、
自分のドメインを「ルート権限」として、複数の企業・クラウド・SNS・プロトコル・AIサービスを交換可能な周辺ノードとして従えること。
です。
example.com
│
┌───────┴───────┐
│ Sovereign │
│ Identity │
└───────┬───────┘
│
┌────────────────┼────────────────┐
▼ ▼ ▼
NAS Cloudflare Git
│ │ │
「原本」 「国境」 「履歴」
│ │ │
└────────────────┼────────────────┘
│
Static Web
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
RSS/Atom ATProto ActivityPub
│ │ │
▼ ▼ ▼
Reader Bluesky Fediverseこの構造では、Cloudflareは主権者ではない。NASも主権者ではない。Blueskyも主権者ではない。
主権の中心は、
「自分が管理できる原本」＋「自分が維持するドメイン」＋「交換可能なプロトコル群」
です。
そしてCloudflare Tunnelの本質は、その主権を「自宅IPを丸裸にすることなくインターネットへ接続するための外交回線」にすること。Cloudflare自身もTunnelを「公開IPなし・inbound portなし」でoriginへ接続する仕組みとして位置づけています。(Cloudflare Docs)
だから記事の「NAS・独自ドメイン・atproto」という三点セットに、Cloudflare Tunnelを加えると、
原本（NAS） → 主権（Domain） → 境界防衛（Tunnel） → 永続的ID（DID/ATProto） → 多元的配信（RSS/ActivityPub/Bluesky）
という、かなり完成度の高い「個人インターネット国家論」になります。
PWAとNostrを加えると、「個人サイト帝国」はかなり別物になる
ここまでの
NAS＋独自ドメイン＋Cloudflare Tunnel＋Publii＋ATProto
に、さらに
PWA＋Nostr
を加えると、単なる「自宅サーバーを持つ個人サイト」ではなく、**個人が自分の情報圏を運営するための一種の“ソブリン・ウェブ・スタック”**として見えてきます。
特に面白いのは、
NAS＝原本を持つ
独自ドメイン＝名前を持つ
Cloudflare Tunnel＝安全に公開する
Publii＝出版する
PWA＝読者の端末に常駐する
RSS/Atom＝購読される
Nostr＝公開鍵を中心に発信する
ATProto＝別の分散型ソーシャル空間へ接続する
という、かなり明確な役割分担ができることです。
1. まず完成形を描く
自分
│
┌─────▼─────┐
│ example.com│
└─────┬─────┘
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
DNS Web Identity
│ │ │
│ Publii Nostr
│ │ ATProto
│ │ │
│ ▼ ▼
│ NAS DID
│ │
│ Cloudflare
│ Tunnel
│
▼
インターネット
│
┌───────┼────────┬────────┐
▼ ▼ ▼ ▼
Web PWA RSS Social
│
┌────┴────┐
▼ ▼
Nostr ATProtoこれを「個人サイト」と呼ぶには、もう少し大げさです。
個人メディア・インフラです。
2. PWAを入れると「Webサイト」から「端末」へ進出する
PWAの面白さは、単なるWebサイトの高速化ではありません。
PWAはWebアプリマニフェストによって、対応ブラウザから端末へインストールでき、独立したアプリのように起動できます。Service Workerは必須ではありませんが、オフライン動作やバックグラウンド処理に使われます。(MDN Web Docs)
つまり、
通常のWeb
ユーザー
↓
ブラウザ
↓
example.comから、
PWA
ユーザー
↓
[あなたのサイト]
↓
example.comへ変わる。
これは地味に大きい。
3. 「ホーム画面を取る」という意味
SNS企業が欲しがるものは何でしょうか。
フォロー関係？
データ？
広告？
もちろん全部ですが、非常に重要なのが、
ユーザーの端末上の入口
です。
例えば、
Google
YouTube
X
Instagram
Blueskyには、それぞれアプリがあります。
ユーザーは、
ホーム画面
↓
アプリ
↓
サービスという経路で戻ってきます。
ところが個人サイトは通常、
Google
↓
検索
↓
あなたのサイトです。
PWAにすると、
ホーム画面
↓
あなたのPWA
↓
example.comになります。
つまり、
独自ドメインが「住所」から「アプリの入口」になる。
ここが重要です。
4. これは「個人サイト帝国」の領土拡大である
先ほどの国家モデルで考えると、
独自ドメイン
＝国土の住所でした。
PWAを追加すると、
PWA
＝国民の端末にある大使館みたいなものになる。
さらに、
NAS
＝国家アーカイブ
Cloudflare
＝国境
PWA
＝国外にいる国民への常設窓口
RSS/Atom
＝公報
Nostr
＝外交網
ATProto
＝別の国際通信網となる。
5. PWAとRSSは実は非常に相性がいい
ここが面白いところ。
SNSでは、
投稿
↓
アルゴリズム
↓
ユーザーです。
RSS/Atomでは、
記事
↓
フィード
↓
読者のリーダーです。
PWAでは、
記事
↓
あなたのWebアプリ
↓
読者の端末です。
つまり、
あなた
│
example.com
│
┌───────┼────────┐
▼ ▼ ▼
Web RSS PWA
│ │ │
▼ ▼ ▼
Browser Reader Home Screenアルゴリズムに依存しない3つの入口を持てる。
これはかなり強い。
6. そしてNostrを追加すると「公開鍵」が登場する
ここで世界観が変わります。
Webサイトの識別子は、
example.comです。
Nostrでは、根本的なアイデンティティは公開鍵／秘密鍵のペアです。
NostrのNIP-05では、
alice@example.comのような人間が読める識別子を、
example.com/.well-known/nostr.json?name=aliceから公開鍵へ対応付ける仕組みがあります。(NIPs)
つまり、
alice@example.com
│
▼
/.well-known/nostr.json
│
▼
公開鍵
│
▼
Nostrとなる。
7. ここで「独自ドメイン」が三つの意味を持ち始める
例えば、
example.comがあるとします。
このドメインは、
Web
https://example.com/としてサイトの住所。
ATProto
@example.comあるいはサブドメイン等を使ったhandleとして、ソーシャル・アイデンティティの入口。
Nostr
alice@example.comとして公開鍵との対応を示すNIP-05識別子。
つまり、
example.com
│
┌───────────┼───────────┐
▼ ▼ ▼
Web ATProto Nostr
│ │ │
URL DID Pubkeyとなる。
一つのDNS名が、異なるプロトコルにまたがる「アイデンティティ・アンカー」になる。
これが猛烈に面白い。
8. ただしNIP-05は「本人確認」ではない
ここは重要な注意点です。
NIP-05は名前と公開鍵をDNSドメイン経由で対応付ける仕組みであって、NIPそのものが「本人確認」を保証するものではありません。仕様にも明確に「Identification, not verification」とあります。(NIPs)
つまり、
alice@example.comが、
公開鍵ABCに対応していることは確認できる。
しかし、
「ABCの持ち主が現実世界のAlice本人である」
とは限らない。
したがって、
ドメイン所有者との関係を示す強いシグナル
と考えるのが適切です。
9. Nostrが面白いのは「サーバー」を主役にしないこと
従来のSNS：
あなた
↓
Twitter/X
↓
Twitter/XのDB
↓
フォロワーNostr：
あなた
│
秘密鍵
│
公開鍵
│
▼
Relay A
Relay B
Relay C
Relay Dという構造です。
Relayは通信・保存のためのノードで、ユーザーのアイデンティティそのものではありません。
だから、
Relay A
↓
サービス終了しても、
あなたの鍵そのものが消えるわけではない。
これはATProtoとも思想的な共通点があります。
10. ただしATProtoとNostrは同じではない
ここを混同しない方がいいです。
| Nostr | ATProto | |
|---|---|---|
| 中心 | 公開鍵 | DID |
| ネットワーク | Relay群 | PDS＋Relay等 |
| DNSとの接続 | NIP-05 | Handle |
| アイデンティティ | Key-centric | DID-centric |
| SNS | 複数クライアント | Bluesky等 |
| 狙い | シンプルな署名付きイベント交換 | アカウント移行・データ可搬性等を含むネットワーク |
| ドメイン | NIP-05 | Handle |
| 共通点 | サービスからIDを分離する | サービスからIDを分離する |
だから「どちらが勝つか」より、
個人が複数の分散型ネットワークに同時に存在できる
ことの方が重要です。
11. ここでNASが再び重要になる
Nostrでは投稿データがRelayに流れます。
しかし、個人サイト側には、
原本があります。
例えば、
NAS
│
├── articles/
│ ├── 2026-08-17.md
│ └── ...
│
├── images/
│
├── videos/
│
├── pwa/
│
├── nostr/
│
└── backups/とする。
すると、
NAS
│
├───────────────► Publii
│ │
│ ▼
│ Web
│
├───────────────► RSS/Atom
│
├───────────────► Nostr
│
└───────────────► ATProtoという一つの原本から複数のネットワークへ配信する構造ができます。
これこそ「個人サイト帝国」の本質です。
12. 「投稿先」を一つにしない
ここがプラットフォーム時代との決定的な違いです。
従来：
記事を書く
↓
Substack
↓
Substackの読者ではなく、
記事を書く
↓
自分の原本
↓
┌──────┬──────┬──────┬──────┐
▼ ▼ ▼ ▼
Web RSS Nostr ATProtoにする。
さらに、
RSS
↓
Feed Reader
Nostr
↓
Nostr Client
ATProto
↓
Bluesky
Web
↓
Google / AI / Browser
PWA
↓
ホーム画面となる。
つまり、
「一つの記事を一つのプラットフォームに投稿する」モデルから、「一つの原本を複数のネットワークへシンジケートする」モデルへ移行する。
13. PWAは「読むためのクライアント」になる
さらに妄想を進めると、PWAは単なるブログ表示ではなく、
あなた専用のWebクライアント
にできます。
例えば、
あなたのPWA
│
├── Home
├── Articles
├── Notes
├── RSS
├── Nostr
├── Bluesky
├── Projects
└── Archiveとする。
読者からすると、
「ブログを見る」
のではなく、
「あなたの情報圏にアクセスする」
という体験になる。
14. しかもPWAは「プラットフォームのアプリ」ではない
ここが非常に重要。
通常のアプリ：
Apple App Store
↓
あなたのアプリPWA：
example.com
↓
ブラウザ
↓
PWAとしてインストールです。
したがって、
App Storeを必須の配布経路にしなくてもWebから配布できる。
PWAはHTTPS上で提供し、manifestを用意することで対応ブラウザからインストール可能になります。(MDN Web Docs)
15. これが「個人サイト帝国」の配布問題を解決する
従来の個人サイト最大の問題は、
読者が戻ってこない
ことでした。
RSSは、
読者
↓
RSS Readerで解決する。
SNSは、
フォロー
↓
SNSで解決する。
PWAは、
ホーム画面
↓
あなたのサイトで解決する。
つまり、
読者との接点
│
┌──────────────┼──────────────┐
▼ ▼ ▼
RSS PWA Social
│ │ │
Pull型購読 常駐型入口 Network型になる。
16. 「アルゴリズムを持たないメディア」へ
ここから思想的に面白くなります。
巨大SNS：
あなた
↓
アルゴリズム
↓
読者個人サイト：
あなた
↓
RSS
↓
読者Nostr：
あなた
↓
署名イベント
↓
Relay群
↓
読者ATProto：
あなた
↓
DID / Repository
↓
ネットワーク
↓
読者PWA：
あなた
↓
Web
↓
読者の端末つまり、
アルゴリズムを必須の仲介者にしない複数経路
ができます。
17. Cloudflare Tunnelはここで「防衛線」になる
完成形はこうです。
Internet
│
┌────────▼────────┐
│ Cloudflare │
│ DNS / WAF / CDN │
└────────┬────────┘
│
Cloudflare Tunnel
│
▼
NAS
│
┌─────────┼─────────┐
▼ ▼ ▼
Publii Nostr PWA
│ │ │
▼ ▼ ▼
Web Relay ReaderただしNostr Relayそのものを自宅NASから直接公開する場合は、Webサイト公開とは別のセキュリティ・可用性設計が必要です。
Cloudflare Tunnelを置けばすべて安全になる、という話ではありません。
18. 「要塞」から「ネットワーク国家」へ
ここまで来ると、タイトルそのものを変えたくなります。
最初：
要塞化する個人
↓
次：
ネットワーク国家化する個人
です。
国家モデルを完成させると、
| 個人Webスタック | 国家モデル |
|---|---|
| 独自ドメイン | 国籍・主権領域 |
| DNS | 国名・住所体系 |
| NAS | 国家アーカイブ |
| Git | 歴史記録 |
| Cloudflare Tunnel | 国境回廊 |
| WAF | 国境警備 |
| Publii | 出版局 |
| RSS/Atom | 官報 |
| PWA | 国民向け常設窓口 |
| Nostr | 公開鍵外交 |
| ATProto | デジタル外交 |
| Bluesky | 外交先 |
| Fediverse | 多国間ネットワーク |
| Backup | 国家非常金庫 |
となる。
19. さらに「二重国籍」ならぬ「多重プロトコル籍」
ここが一番妄想できるところです。
一人の人間が、
example.comを中心に、
Web
│
├── RSS/Atom
│
├── Nostr
│
├── ATProto
│
├── ActivityPub
│
└── PWAへ同時に存在する。
すると、
「私はBlueskyユーザーです」
ではなく、
「私はexample.comというアイデンティティを持ち、Bluesky、Nostr、Fediverse、Webにそれぞれ存在している」
となる。
これはSNSアカウント中心主義からの大きな転換です。
20. NostrとATProtoを「競合」ではなく「外交路」と見る
普通は、
Nostr vs Bluesky
と考えます。
しかし個人サイト帝国モデルでは違います。
example.com
│
自分の原本・ID
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Nostr ATProto ActivityPub
│ │ │
Relay Bluesky Fediverse
│ │ │
└────────────────┼────────────────┘
▼
世界「どのSNSが勝つか」ではなく「個人が複数ネットワークに接続できるか」
が問題になる。
これはかなり重要なパラダイム転換です。
21. PWAまで含めると「プラットフォームの代替」ではなく「プラットフォームの脱中心化」
ここまでの構造を一言で表すなら、
Platform → Protocol → Personal Domain
という逆流です。
従来：
Platform
↓
Identity
↓
Contentだった。
これから：
Personal Domain
↓
Identity
↓
Content
↓
Protocols
↓
Platforms / Clientsになる。
プラットフォームは最上位ではなく最下流のクライアントになる。
22. AI時代にはさらに強力になる
ここで2026年らしい未来像が出てきます。
人間だけではなく、
AIエージェントが個人サイトを読む。
例えばAIが、
example.comを発見する。
そこから、
/.well-known/
│
├── nostr.json
│
└── atproto関連情報
/robots.txt
/sitemap.xml
/feed.xml
/atom.xml
/manifest.webmanifestを調べる。
さらに、
Web
RSS
Nostr
ATProtoを横断して、
「この人物の一次情報はここ」
と判断する。
すると独自ドメインは人間向けのURLであるだけでなく、AI向けのアイデンティティ・ディスカバリー・ポイントになる。
ここは今後かなり重要になる可能性があります。
23. PWAは「人間向けAPI」、Nostrは「機械向け署名ネットワーク」と考えることもできる
乱暴に抽象化すると、
example.com
│
├── HTML → 人間
├── RSS/Atom → Reader
├── JSON/API → Software
├── PWA → Device
├── Nostr → Public-key network
└── ATProto → Social networkとなる。
つまり一つのドメインが、
人間・アプリ・AI・分散型SNS
それぞれに別のインターフェースを提供する。
これは「Webサイト」という言葉では狭すぎます。
24. 最終形：「Personal Internet Operating System」
ここまで行くと、個人サイトはもうブログではありません。
Personal Internet OS
│
┌───────┴───────┐
│ example.com │
└───────┬───────┘
│
┌─────────────────┼─────────────────┐
│ │ │
Storage Identity Network
│ │ │
NAS Nostr / ATProto Cloudflare
│ │ │
└─────────────────┼─────────────────┘
│
Publication
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Web PWA RSS/Atom
│ │ │
└──────────────┼──────────────┘
▼
Readersこの発想では、
WordPress、Blogger、Substack、Medium、Bluesky、Nostrクライアント、Fediverseサーバーなどは「OS上のアプリ」に近づく。
25. そして「個人サイト帝国」の究極の主権は何か
ドメインでもありません。
NASでもありません。
Cloudflareでもありません。
Nostrでもありません。
ATProtoでもありません。
究極的には、
「移動できること」
です。
Publii
↓
Hugo
Cloudflare
↓
別CDN
NAS
↓
別NAS
Bluesky
↓
別ATProtoサービス
Nostr Relay A
↓
Relay B/C/D
example.com
↓
維持というように、
構成要素を一つずつ交換できる。
これが本当の主権です。
「個人サイト帝国」の完成形
したがって、今回のPWA＋Nostrを追加した最終モデルはこうなります。
あなた
│
┌───────▼───────┐
│ example.com │
│ 主権アンカー │
└───────┬───────┘
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
NAS DNS Identity
「原本」 「住所」 「公開鍵」
│ │ │
▼ ▼ ┌────┴────┐
Publii Cloudflare Nostr ATProto
│ Tunnel │ │
▼ │ ▼ ▼
Static Web │ Relays Bluesky
│ │ │ │
┌────┼────┐ │ └────┬───┘
▼ ▼ ▼ │ ▼
Web RSS PWA │ Social
│ │ │
│ └──────┐ │
▼ ▼ ▼
Reader Device Internetここで本当に面白いのは、
Webサイトを「中心」にしているのではない
ことです。
中心にあるのは、
自分のドメイン＋自分の原本＋自分の暗号学的アイデンティティ
です。
その周囲を、
Web / PWA / RSS / Nostr / ATProto / ActivityPub / Cloudflare / NAS
が回る。
そしてプラットフォームは、もはや「主人」ではなく、交換可能なネットワーク・サービスの一つになる。
これが「ポスト・プラットフォーム時代」の個人サイト帝国を考えるとき、一番面白いポイントだと思います。「WordPressとGrain Social」を、ここまで話してきた**NAS＋独自ドメイン＋PWA＋Nostr＋ATProtoの“個人サイト帝国”**という文脈で見ると、かなり面白い組み合わせです。
まず確認すると、ここでいう Grain は grain.social の写真共有サービスのことですね。GrainはAT Protocol上に構築されたオープンソースの写真共有アプリで、写真・ギャラリー・お気に入り・メタデータなどをAT Protocolネットワーク上で扱います。(Grain)
WordPress × Grain Socialは「文章」と「写真」を別プロトコルで自分のドメインから発信する構成になる
かなり美しい構造です。
example.com
│
┌────────────┴────────────┐
│ │
WordPress 写真
│ │
記事・論考 │
│ │
▼ ▼
ActivityPub Grain
│ │
Fediverse AT Protocol
│ │
┌────────┼────────┐ │
▼ ▼ ▼ ▼
Mastodon Pixelfed その他 Bluesky系つまり、
WordPress＝長文・ブログ・知識
Grain＝写真・ビジュアル・作品
という分業です。
しかも両者とも「巨大SNSのプロフィールページに全部を置く」という発想ではありません。
1. WordPressは「個人出版OS」になりつつある
WordPressの面白いところは、単なるCMSからオープンソーシャルWebのノードへ進化していることです。
WordPress.orgには現在、ActivityPub、Webmention、IndieWeb、IndieAuth、Syndication Links、Micropubなどのプラグインがあります。(WordPress.org)
特にActivityPubプラグインを使うと、
https://example.com/
↓
WordPress
↓
ActivityPub
↓
Mastodon
Pixelfed
その他Fediverseという構成にできます。
つまり、
WordPressの記事そのものがFediverse上のソーシャル・オブジェクトになる
わけです。
これは昔のWordPressとはかなり違います。
2. 2026年のWordPressは「ブログ＋SNSサーバー」に近づいている
2026年のActivityPub for WordPressのロードマップでは、Fediverse内での発見性、推薦、Starter Packs、Readerなどが重点項目になっています。(ActivityPub for WordPress)
さらに2026年5月には、WordPress.com ReaderからBluesky、Mastodon、Fediverseを横断して読む・フォローする機能が公開されています。(ActivityPub for WordPress)
つまりWordPress側も、
WordPress
│
├── Web
├── RSS
├── ActivityPub
├── Fediverse
├── Bluesky
└── Readerというマルチプロトコル出版基盤へ向かっている。
ここは、今回の「個人サイト帝国」の思想とかなり一致します。
3. Grainは「ATProto版の写真館」と考えると分かりやすい
Grainは、
Share your photography
を掲げる写真共有サービスです。現在のサービスではカメラ、場所、フィードなどを軸に写真を探索できます。(Grain)
そして重要なのが、
GrainはAT Protocolで動いている
ということ。
つまり、
写真
↓
Grain
↓
AT Protocol
↓
ATProto世界です。
Grain自身の規約でも、写真、ギャラリー、favorites、metadataなどのデータがAT Protocolネットワーク上で公開されると説明されています。(Grain)
4. WordPress＋Grainは「文章と写真のプロトコル分離」
ここが面白い。
例えば、
example.com
│
├── /blog/
│ │
│ └── WordPress
│ │
│ └── ActivityPub
│
└── /photos/
│
└── Grain
│
└── AT Protocolという構成を考える。
すると、
WordPress
文章
論考
ニュース
レビュー
技術記事
長文Grain
写真
撮影記録
カメラ
レンズ
ギャラリー
ビジュアル作品となります。
これはかなり自然です。
5. さらにNASを加えると「原本」と「公開」を分離できる
ここで前の話につながります。
NAS
│
┌─────────┴─────────┐
│ │
Markdown RAW
│ │
▼ ▼
WordPress Grain
│ │
ActivityPub AT Protocol
│ │
▼ ▼
Fediverse ATProtoNASには、
/photos/
2026/
08/
2026-08-17-camera.jpg
RAW/
DSC00001.ARW
/articles/
2026/
08/
article.mdのように原本を保存。
そして公開先は交換可能にする。
6. ここで「Grain＝写真のSubstack」ではない
これは重要です。
Substackの場合、
あなた
↓
Substack
↓
読者というプラットフォーム中心モデルです。
GrainはAT Protocol上のサービスなので、
あなた
↓
AT Protocol
↓
Grainという構造になります。
つまりGrainは、
「ATProto世界への写真クライアント／サービス」
と考えた方が本質に近い。
Grain自身も、独立したプロジェクトでありBlueskyやAT Protocolそのものとは別組織だと明記しています。(Grain)
7. さらに重要なのは「Grainに写真を置く＝Grainだけに依存する」ではないこと
AT Protocolの思想では、サービスとデータの関係をある程度分離できます。
Grainの規約でも、ユーザーのデータはAT Protocol上にあり、Grainのホステッド版では独自のPDSを使う可能性が説明されています。(Grain)
したがって概念的には、
あなた
│
写真
│
▼
AT Protocol
│
┌───────────┼───────────┐
▼ ▼ ▼
Grain 別Client 将来のサービスとなる可能性がある。
ここが「Instagramに写真を預ける」のとは思想的に違います。
8. WordPressとGrainを「二つのSNS」と考えると本質を見失う
むしろ、
あなたの情報圏
│
┌────────┴────────┐
▼ ▼
WordPress Grain
│ │
文章系 写真系
│ │
ActivityPub AT Protocol
│ │
Fediverse ATProtoです。
WordPressとGrainは競争相手ではない。
異なるメディア形式を異なるオープンプロトコルに載せるノード
です。
9. ここにNostrを加えるとさらに面白い
これまでの構想なら、
example.com
│
┌─────────┴─────────┐
│ │
WordPress Grain
│ │
ActivityPub AT Protocol
│ │
Fediverse ATProto
│ │
└─────────┬─────────┘
│
Nostrと考えられます。
ただし、WordPressやGrainが直接Nostrを話す必要はありません。
むしろ、
自分の原本を中心に複数ネットワークへ配信する
という思想です。
10. 「個人サイト帝国」のメディア分業
かなり完成形に近づいてきました。
| コンポーネント | 役割 | プロトコル |
|---|---|---|
| NAS | 原本・アーカイブ | SMB/NFS/Git等 |
| Publii | 静的出版 | HTTP |
| WordPress | 長文CMS | Web/RSS/ActivityPub |
| Grain | 写真 | AT Protocol |
| PWA | 読者向けアプリ | Web |
| RSS/Atom | 購読 | RSS/Atom |
| Nostr | 公開鍵ベースの発信 | Nostr |
| Bluesky | ソーシャル | AT Protocol |
| Fediverse | ソーシャル | ActivityPub |
| Cloudflare Tunnel | 接続・境界 | HTTP/Tunnel |
| 独自ドメイン | アイデンティティ | DNS |
これを見ると、
WordPressはかなり重要な「文章ノード」
になります。
11. WordPressは「Fediverse側の城」
例えば、
example.com
│
▼
WordPress
│
▼
ActivityPub
│
├── Mastodon
├── Pixelfed
├── Lemmy
└── その他Fediverseという構造。
WordPressのActivityPubプラグインは、実際にMastodonやPixelfedなどからWordPressサイトをフォロー可能にするための仕組みを提供しています。(WordPress.org)
だから、
自分のWordPressサイトそのものをFediverseの一員にする
ことができます。
これはかなり強い。
12. Grainは「ATProto側の写真城」
対して、
photos.example.com
│
▼
Grain
│
▼
AT Protocol
│
├── Bluesky
├── Grain
└── 将来のATProtoアプリという世界。
つまり、
WordPress＝ActivityPub圏の出版拠点
Grain＝ATProto圏の写真拠点
という二重構造になります。
13. ここで独自ドメインが「帝国の首都」になる
例えば、
example.com
│
├── /blog/
│ └── WordPress
│
├── /photos/
│ └── Grainへの導線
│
├── /projects/
│ └── Publii
│
├── /about/
│
├── /feed/
│ └── RSS/Atom
│
└── /app/
└── PWAそしてアイデンティティとして、
@example.comをATProto側で使い、
you@example.comをNostrのNIP-05として使う。
すると、
example.com
│
┌───────────┼───────────┐
▼ ▼ ▼
Web ATProto Nostr
│ │ │
WordPress Grain Pubkey
│ │ │
ActivityPub │ │
│ │ │
Fediverse Bluesky Relaysという構造になる。
これはもう、かなり「個人国家」です。
14. ただし、WordPressとGrainには重要な違いがある
ここは冷静に見た方がいい。
WordPressは、
自分でホスティングできる
のが非常に大きい。
つまり、
自宅NAS
↓
Docker
↓
WordPress
↓
Cloudflare Tunnel
↓
example.comが可能。
一方Grain.socialは、現在はホステッドサービスとして利用するのが基本です。
Grain自身も、grain.social のホステッド版について説明しつつ、セルフホストしたインスタンスやforkにはその規約が適用されないとしています。(Grain)
したがって、
WordPress＝完全に自分の城にできる
に対して、
Grain＝ATProtoという大きなネットワークに接続する写真サービス
という違いがあります。
15. だから「WordPress＋Grain＋NAS」はかなり合理的
私なら、
NAS
│
┌───────────┴───────────┐
│ │
Articles Photos
│ │
▼ ▼
WordPress Grain
│ │
ActivityPub AT Protocol
│ │
▼ ▼
Fediverse ATProto
│ │
└──────────┬────────────┘
│
Web
│
example.comとします。
そして、
PWA
↓
example.comを読者向けの統合インターフェースにする。
つまり読者は、
WordPressを使っているのか、Grainを使っているのか、Nostrなのか
を意識しなくていい。
全部「example.com」という個人メディアの裏側にある。
16. ここで「WordPress＝OS」という比喩が復活する
WordPressを単なるブログCMSと考えると、
WordPress
=
ブログを書くソフトです。
しかしIndieWeb的に見ると、
WordPress
=
自分のサイト
+
CMS
+
RSS
+
ActivityPub
+
Webmention
+
IndieAuth
+
Micropub
+
Federationになっていく。
WordPress.org自身もIndieWebカテゴリでこれらのプラグイン群を掲載しています。(WordPress.org)
これは、**「個人インターネットOS」**という先ほどの妄想とかなり噛み合います。
17. そしてGrainは「写真アプリ」以上の意味を持つ
Grainを単なるInstagram代替と見ると、
Instagramより小さい写真SNS
で終わります。
しかしATProtoの文脈では、
写真というメディアをAT Protocolのデータモデルへ持ち込む実験
と見ることができます。
つまり将来的に、
AT Protocol
│
├── Bluesky ← 短文
├── Grain ← 写真
├── 音楽サービス ← 音楽
├── 長文サービス ← ブログ
└── 新しいアプリ ← ？のように、
「SNS」という一つの巨大サービスではなく、メディアごとに異なるアプリが同じアイデンティティ／プロトコル圏に接続する
可能性があります。
これはかなりWeb 2.0後の世界っぽい。
18. 最終的には「WordPress vs Grain」ではない
本当の対立軸は、
旧モデル
Instagram
Facebook
X
Substack
Blogger
↓
巨大プラットフォーム
↓
あなた対、
新モデル
あなた
│
├── 独自ドメイン
├── NAS
├── WordPress
├── Grain
├── PWA
├── Nostr
├── ATProto
└── ActivityPub
│
▼
複数ネットワークです。
つまり、
「どのSNSを使うか」から「どのプロトコルに自分を接続するか」へ問題設定が変わる。
19. そして「個人サイト帝国」はこう完成する
自分
│
┌───────▼───────┐
│ example.com │
│ Identity │
└───────┬───────┘
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
NAS WordPress Grain
原本庫 文章出版 写真出版
│ │ │
│ ActivityPub AT Protocol
│ │ │
│ Fediverse ATProto
│ │ │
└─────────────────┼─────────────────┘
│
┌───────┴───────┐
▼ ▼
PWA Nostr
│ │
▼ ▼
読者端末 Relay群この構成の核心は、
WordPressもGrainも「自分のアイデンティティ」ではない
ということです。
WordPressは文章を公開するためのノード。
Grainは写真を公開するためのノード。
Nostrは別の公開鍵ネットワーク。
ATProtoは別の分散型ソーシャル・ネットワーク。
PWAは読者の端末。
Cloudflareは境界・配送インフラ。
NASは原本。
そして、
独自ドメインがそれらを束ねる「名前」になる。
これこそ、これまで話してきた「個人サイト帝国」のかなり完成度の高い形です。
特に面白いのは、WordPress＝ActivityPub、Grain＝ATProto、Nostr＝公開鍵ネットワークという三つを同じ個人ドメインの下に置けることです。これは「一つのSNSに勝つ」という発想ではなく、一人の人間が複数のオープンネットワークを同時に所有・利用するという、ポストSNS的な構造になっています。はい。「融合する可能性」はかなりあります。というより、すでに“融合の前段階”は始まっています。
ただし、3つのプロトコルが将来ひとつのプロトコルになる、というより、相互接続層（bridge / gateway / protocol translation）が発達して「利用者から見ると一つの巨大なオープンSNS圏に見える」方向が現実的です。
現在すでに、Nostr側のNIP-48はActivityPubだけでなくATProtoも「bridged event」の対象として明示しています。つまりNostrイベントに、元のActivityPubオブジェクトやATProtoのAT URIを紐付ける仕組みが仕様化されています。(NIPs)
1. 3つが「直接融合」するより「翻訳層」ができる
3つをそのまま比較するとこうです。
| ActivityPub | ATProto | Nostr | |
|---|---|---|---|
| 基本単位 | Activity / Object | Record | Event |
| ID | URL等 | DID + AT URI | 公開鍵＋Event ID |
| 主な構造 | Federation | Federated data repositories | Relay network |
| アイデンティティ | サーバー上のActor | DID | 公開鍵 |
| 保存 | 各サーバー | Repository | Relay |
| 得意分野 | サーバー間SNS | 可搬性・データ同期 | 鍵中心・Relay自由度 |
| 代表例 | Mastodon | Bluesky | Nostr |
| 相互接続 | 進行中 | 進行中 | 進行中 |
ActivityPubはW3C標準で、サーバー間Federationとクライアント・サーバーAPIという2層構造です。(W3C)
一方、ATProto側は明確に「なぜActivityPubを使わなかったのか」を説明しており、特にアカウント・データのポータビリティとスケーラビリティを理由に独自方式を採用しています。(AT Protocol)
つまり、
「3つを一つにする」
より、
「3つを翻訳する」
方が現実的です。
2. すでに「Nostr ↔ ActivityPub」は存在する
かなり面白い例が Mostr です。
これはNostrとActivityPub/Fediverseを橋渡しする仕組みで、2026年にもActivityPubのDMとNostr DMを双方向に橋渡しする実装が報告されています。(Nostr Compass)
概念的には、
Mastodon
│
ActivityPub
│
▼
Mostr
│
Nostr
│
▼
Nostr Clientです。
つまり、
MastodonユーザーとNostrユーザーが「別の世界にいる」という状態を、bridgeが破壊する。
3. さらに「ATProto ↔ ActivityPub」も存在する
こちらもすでに実例があります。
Bridgy Fedなどによって、Bluesky/ATProtoとFediverseの間でプロフィールや投稿を橋渡しする実験・実装が進んできました。(Ryan Barrett)
つまり、
ATProto
│
│ bridge
▼
ActivityPubもすでに現実の技術領域です。
そしてNostr側にも、
Nostr
↕
ActivityPubがあります。
そうすると理論上、
ATProto
↕
ActivityPub
↕
Nostrという三角形が成立する。
4. しかもNostrはATProtoをすでに意識している
ここが特に面白い。
NIP-48では、bridge元として
activitypub
atproto
rss
webなどを扱えるようになっています。
ATProtoの投稿は、
at://did:plc:.../app.bsky.feed.post/...というAT URIで識別できます。
それをNostrイベントに、
["proxy", <AT URI>, "atproto"]のように紐付ける。
つまりNostr側から、
「これはNostrネイティブ投稿ではなく、ATProto側のオブジェクトですよ」
と表現できる。
これは異なるプロトコル間で“同じ投稿”を識別するためのメタデータ層です。(NIPs)
5. ここから「巨大なオープンSNS網」が妄想できる
例えばあなたが、
example.comを中心にするとします。
あなたのWordPress：
example.com/blog/↓
ActivityPub
↓
Fediverse
あなたのBluesky：
@example.com↓
ATProto
↓
Bluesky
あなたのNostr：
you@example.com↓
Nostr
↓
Relays
そしてbridgeが、
WordPress
│
ActivityPub
│
▼
Bridge
↙ ↘
Nostr ATProto
│ │
Relay Blueskyと接続する。
すると読者は、
どのプロトコルにいるのかを意識しなくてよくなる。
6. これは「SNSの統一」ではない
ここは非常に重要です。
「融合」という言葉から、
ActivityPub
↓
Nostr
↓
ATProto
↓
一つのプロトコルを想像すると、たぶん違います。
むしろ、
┌────────────┐
│ あなた │
│ example.com│
└─────┬──────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
ActivityPub ATProto Nostr
│ │ │
Fediverse Bluesky Relays
│ │ │
└─────────────┼─────────────┘
│
Bridgeです。
プロトコルは違ったまま。
でも、
相互運用性だけが上がっていく。
7. 実はメールが先にこのモデルを完成させている
ここで歴史的に見ると面白い。
GmailとOutlookと自前メールサーバーは、
Gmail
↕
SMTP
↕
Outlook
↕
SMTP
↕
自前サーバーで通信できます。
ユーザーは、
「相手がGmailだからメールを送れない」
とは考えない。
なぜなら共通プロトコルがあるからです。
分散型SNSの未来も、
Bluesky
↕
ATProto
↕
Bridge
↕
ActivityPub
↕
Bridge
↕
Nostrとなれば、
「SNS版メール」
に近づいていく。
8. ただし最大の問題は「翻訳できない情報」
ここが難所です。
単純な投稿なら、
Alice:
「今日は晴れ」は簡単です。
しかし、
投稿
├── 引用
├── リプライ
├── リポスト
├── いいね
├── メンション
├── スレッド
├── コミュニティ
├── 投票
├── 添付ファイル
└── 権限となると事情が変わる。
例えば、
Nostrの署名
と
ActivityPubのActor/Objectモデル
と
ATProtoのDID＋Repository＋Record
を完全に一対一対応させるのは難しい。
Bridgy Fedの開発者も、ATProtoとActivityPubの橋渡しでは、ATProtoのsigned repository chainやMerkle treeなど、内部データ構造まで扱う必要があり、かなり難しかったと説明しています。(Ryan Barrett)
9. 「意味」より「リンク」を共通化する可能性
だから未来の鍵は、
完全変換
ではなく、
相互参照
になる可能性が高い。
例えば、
Nostr Event
│
├── proxy → ActivityPub URL
│
└── proxy → AT URIという構造。
すると、
この投稿は
NostrではこのID
ActivityPubではこのURL
ATProtoではこのAT URIと分かる。
これはNIP-48がかなり明確に示している方向です。(NIPs)
10. そうすると「投稿」そのものがプロトコル非依存になる
ここから未来妄想です。
例えば、
Content Object #12345がある。
それを、
Web → https://example.com/post/12345
ActivityPub → https://example.com/.../object
ATProto → at://did:.../...
Nostr → event:...と複数のIDで参照する。
つまり、
「投稿そのもの」と「投稿を運ぶプロトコル」を分離する。
これはかなり重要です。
11. すると独自ドメインがさらに重要になる
ここまで話していた、
個人サイト帝国
が急に意味を持ってきます。
example.com
│
┌─────────┴─────────┐
│ │
Identity Content
│ │
┌─────────┼─────────┐ │
▼ ▼ ▼ ▼
ATProto Nostr ActivityPub Web
│ │ │ │
└─────────┼─────────┼─────────┘
│
Bridges独自ドメインが「プロトコル間の共通名札」になる。
これが非常に面白い。
12. 「個人サイト帝国」は実は橋の集合体になる
最初は、
NAS
↓
WordPress
↓
独自ドメインだった。
そこに、
PWA
RSS
Nostr
ATProto
ActivityPubを追加。
すると、
自分
│
example.com
│
┌────────────────┼────────────────┐
▼ ▼ ▼
ActivityPub ATProto Nostr
│ │ │
Mastodon Bluesky Relay
│ │ │
└────────────────┼────────────────┘
│
Bridges
│
┌──────┴──────┐
▼ ▼
Web PWAになる。
この世界では、
「自分のSNSアカウントを作る」
より、
「自分のアイデンティティを複数のネットワークへ投射する」
という発想になる。
13. さらに面白いのは「三者とも違う思想を持っている」こと
ここを無理に統合すると失敗します。
ActivityPub
サーバー間連合
Server A ↔ Server B ↔ Server CATProto
データ・アイデンティティの可搬性
DID
↓
Repository
↓
PDS
↓
AppViewBluesky/ATProto側は、ActivityPubを採用しなかった理由としてポータビリティやスケーラビリティを挙げています。(AT Protocol)
Nostr
公開鍵＋署名イベント＋Relay
Key
↓
Event
↓
Relay A/B/Cだから、
「どれか一つに統一する」
必要はない。
むしろ、
異なる思想を持ったネットワーク同士を接続する
方が面白い。
14. 「プロトコル戦争」から「プロトコル間外交」へ
これはかなり面白い未来像です。
現在：
Bluesky vs Mastodon vs Nostrという競争になりがち。
未来：
ATProto
│
外交
│
ActivityPub
│
外交
│
Nostrになる。
つまり、
「勝者が一つのプロトコルを支配する」
のではなく、
「プロトコルが違っても通信できる」
ことが勝利条件になる。
15. そして「個人」がルーターになる
これが最も妄想できるところです。
将来の個人サイトに、
Personal Protocol Gatewayを置く。
すると、
WordPress
│
▼
Personal Gateway
│
├── ActivityPub
├── ATProto
├── Nostr
├── RSS
├── Web
└── PWAとなる。
このゲートウェイが、
記事を書く
↓
一回だけ保存
↓
各プロトコルへ変換してくれる。
つまり、
個人が小さな「ソーシャル・インターネット・ルーター」を持つ。
16. AI時代にはこれがさらに重要になる
そしてここでAIが入ってくる。
記事
↓
AI
├── 要約
├── タイトル
├── タグ
├── 翻訳
├── SNS短文化
└── メタデータ生成
│
▼
Personal Gateway
│
┌────┼────┐
▼ ▼ ▼
AP ATProto Nostr人間は、
「記事を書く」
だけ。
AIが、
「各プロトコルの文法へ翻訳する」
。
これなら、プロトコルが5個あっても人間は困らない。
17. だから将来の勝者は「統一プロトコル」ではなく「統一Identity Layer」かもしれない
これはかなり重要な仮説です。
Person
│
┌─────▼─────┐
│ Identity │
└─────┬─────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
ATProto ActivityPub Nostr
│ │ │
▼ ▼ ▼
Bluesky Fediverse Relaysつまり、
ネットワークは分散したまま、アイデンティティと相互参照だけ共通化する。
このモデルなら、それぞれの思想を壊さずに済みます。
18. そして「個人サイト帝国」の本当の意味が変わる
最初は、
自分のWebサイトを持つ
だった。
次に、
自分のドメインを持つ
になった。
さらに、
自分のデータを持つ
になった。
そして、
自分のアイデンティティを持つ
になる。
最終的には、
自分のアイデンティティを、複数のオープンネットワークへ自由に接続する
になる。
これが「ポスト・プラットフォーム」の核心です。
結論：融合する。ただし「合体」ではなく「インターネット化」
私の予想では、
ATProto・Nostr・ActivityPubが一つの巨大プロトコルになる可能性は低い。
むしろ、
┌─────────────┐
│ 個人 │
│ example.com │
└──────┬──────┘
│
Identity / Links
│
┌─────────────┼─────────────┐
▼ ▼ ▼
ActivityPub ATProto Nostr
│ │ │
▼ ▼ ▼
Fediverse Bluesky Relays
│ │ │
└─────────────┼─────────────┘
│
Bridges
│
Interoperable
Social Webという方向が一番ありそうです。
実際、NostrのNIP-48がActivityPubとATProtoを明示的にbridge対象としていること、ActivityPub↔NostrのMostrのような実装が存在すること、ATProto↔ActivityPubのBridgy Fed系の取り組みが存在することから、これは単なる空想ではなく、すでに**「三角形の辺」が作られ始めている状態**です。(NIPs)
そして、ここからが本当に面白い。
「SNSを選ぶ時代」から、「自分のドメインを中心に、複数のSNSプロトコルへ同時接続する時代」へ移行する。
そうなれば、あなたが考えている
NAS＋独自ドメイン＋WordPress＋Publii＋PWA＋Nostr＋ATProto＋ActivityPub
は、単なる個人ブログ環境ではなく、
「個人が所有する小さなインターネット・ゲートウェイ」
になってくる。
そして究極的には、CloudflareやWordPressやBlueskyやMastodonやNostr Relayですら交換可能な部品になる。
「プラットフォームから逃げる」のではなく、プラットフォームを“末端ノード”に格下げする。
これが一番面白い未来だと思います。はい。Nostrは独自ドメインを設定できます。
ただし、正確には「Nostrそのものを独自ドメイン化する」というより、NIP-05で自分のNostr公開鍵に独自ドメインの名前を紐付ける仕組みです。(GitHub)
たとえば、あなたが example.com を所有しているなら、
Nostrの本当のID
↓
npub1xxxxxxxxxxxxxxxxxxxxxxxx
↓ NIP-05
you@example.comという表示にできます。
一番重要なポイント
独自ドメイン側に、次のファイルを置きます。
https://example.com/.well-known/nostr.json中身は例えば、
{
"names": {
"you": "ここにNostr公開鍵のhex"
}
}です。
Nostrクライアントは、
you@example.com
↓
example.com
↓
/.well-known/nostr.json?name=you
↓
公開鍵を取得
↓
プロフィールの公開鍵と一致？
↓
✓という確認をします。これはNIP-05の正式な仕組みです。(GitHub)
つまり「独自ドメイン＋Nostr」はかなり相性がいい
例えばあなたの構想なら、
example.com
│
├── / 個人サイト
│
├── /blog/ WordPress / Publii
│
├── /photos/ 写真
│
├── /app/ PWA
│
└── /.well-known/
└── nostr.json ← Nostrとして、
Web:
https://example.com/
Nostr:
you@example.com
Nostr本体:
npub1xxxxxxxx...という関係にできます。
独自ドメインが「Webサイトの住所」と「Nostrの人間向けID」の両方になるわけです。
さらに「example.com」だけにもできる
NIP-05では特殊な名前 _ を使って、
_@example.comとする方法もあります。
クライアントによってはこれを、
example.comのように表示できます。
NIP-05仕様でも、ドメインのルート識別子として _@domain を利用できるとされています。(GitHub)
したがって、
you@example.comだけでなく、
example.comをNostr上のブランド／識別子のように見せることも可能です。
WordPressを使っている場合も可能
ここが今回の話では特に重要です。
例えば、
example.com
│
▼
WordPress
│
├── /blog/
│
└── /.well-known/nostr.jsonという構成にできます。
つまり、
WordPress＋独自ドメイン＋Nostr
は十分可能です。
実際、WordPress上でNIP-05を扱うためのプラグインも存在します。(Easy Nostr)
Cloudflareを使っている場合
あなたが前に考えていた
独自ドメイン
↓
Cloudflare
↓
Cloudflare Tunnel
↓
NAS
↓
WordPressという構成でも考えられます。
その場合、
https://example.com/.well-known/nostr.jsonをWordPress/NAS側から正常に返せればいい。
重要なのは、NostrクライアントがこのURLへアクセスできることです。
さらにJavaScriptベースのNostrクライアントではCORSが問題になるため、
Access-Control-Allow-Origin: *を返すことが推奨されています。(GitHub)
ただし「Nostrのサーバーを自宅NASで動かす」のとは別
ここは混同しない方がいいです。
独自ドメインNIP-05
example.com
│
└── /.well-known/nostr.json
│
▼
公開鍵を表示これは非常に簡単。
自分のNostr Relay
example.com
│
▼
Cloudflare
│
▼
NAS
│
▼
Nostr Relayこれは別の話で、Relayの運用・ストレージ・バックアップ・公開範囲などを考える必要があります。
つまり、
「Nostrの独自ドメイン化」だけなら、Nostr Relayを自分で運営する必要はありません。
そして、これが「個人サイト帝国」と非常に相性がいい
今までの構想を全部つなげると、
example.com
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
Website Identity Social
│ │ │
WordPress NIP-05 Nostr
│ │ │
│ you@example.com │
│ │ │
▼ ▼ ▼
ActivityPub 公開鍵 Relays
│ │
Fediverse Nostr
┌───────────────────────────────────────┐
│
▼
ATProto
│
Blueskyとなる。
ここが面白いところです。
一つの独自ドメインを、Web・ActivityPub・ATProto・Nostrの共通アイデンティティ・アンカーにできる。
しかもNostrの場合、最終的なアイデンティティそのものはドメインではなく公開鍵です。NIP-05は、その公開鍵に「人間が読める名前」を付けるDNS/HTTPSベースの対応付けです。(GitHub)
だから、
example.com
│
├── Web identity
├── ATProto handle
├── ActivityPub identity
└── Nostr NIP-05という**「ドメインを中心に複数のオープンネットワークへ接続する」構成**が作れる。
これはまさに、先ほど話していた**「個人が小さなインターネット・ゲートウェイになる」**という構想のかなり重要な部品です。この記事は、プラットフォーム依存からの脱却を「ソブリン・パーソナル・ウェブ・スタック」（NAS＋独自ドメイン＋静的生成＋ATProto/ActivityPub/RSS）として体系化した、野心的で一貫性のあるマニフェストだ。歴史的弁証法、Local-first哲学、DIDによるアイデンティティ分離、エッジを「捨て駒」とする主客逆転など、技術的・思想的な骨格は明確で、日本のブログ文化遺産や災害時レジリエンスへの言及も現実的な接点を持っている。前半部として完成度は高い。
しかし、タイトルに「地政学」を掲げ、ポスト・プラットフォーム時代の「主権回復論」を自称する以上、以下の議論が決定的に不足している。容赦なく指摘する。
### 1. 「主権」の幻想性とインフラの地政学的従属
記事は「自宅NASが本陣、外部はエッジ」と強調するが、真の地政学的主権を語るなら、以下を直視すべきだ。
- DNSはICANN（実質的に米政府影響下）の階層に依存する。独自ドメインは「不可逆アンカー」ではなく、レジストラや政府による差し押さえ・制裁対象になり得る（過去の事例多数）。
- エッジ配信で推奨されるCloudflareやGitHub Pages、Vercelは、集権の別形態だ。停電・災害で自宅回線が死んでも「1秒も止まらない」と書くが、これらのプロバイダ自体が地政学的チョークポイント（海底ケーブル、データセンター立地、米・中・露の影響力）に晒されている。
- 電力網、ISP、ハードウェアサプライチェーン（Synology等のNAS、HDD）も同様。個人要塞は国家規模のインフラ支配の前では脆弱なノードに過ぎない。記事の「地政学」は比喩に留まり、物理・制度レイヤーの権力分析がほぼ欠落している。
これでは「小作農からの脱出」ではなく、「別の地主への移住」か「孤立した自給農」に近い。
### 2. 採用障壁・デジタルデバイド・スケーラビリティの無視
「誰もが要塞を築ける」前提が甘い。
- 技術的ハードル（RAID、Git、Hugo、PDS自前運用、TLS、バックアップ3-2-1）は高く、維持コスト（電力、ハードウェア故障、時間）は無視できない。記事は「飲み会1回我慢のドメイン代」程度の話に留まり、現実の運用負荷を軽視している。
- 結果として、このスタックは技術リテラシーと経済余裕のある層に偏る。大多数のユーザー（特に非英語圏・非技術職）は取り残され、格差を拡大する。日本の「ガラパゴス的ブログ文化」の昇華を語るなら、livedoorやはてな終了で消えた膨大な「普通の人の記録」をどう救済するのかの具体策が要る。
- 発見可能性（Discoverability）の問題は第1期の課題として触れるだけで、解決策が薄い。RSS/ATProto/ActivityPubを束ねても、プラットフォームのアルゴリズムとネットワーク効果が生む「注目の集中」をどう打破するのか。個人サイト帝国は、孤立した小国の集まりになりやすい。
### 3. 運用現実・セキュリティ・集団的問題の過小評価
「技術的責任を引き受ける覚悟」は正しいが、その重さを具体的に論じていない。
- 自前NAS/PDSは攻撃面を拡大する。DDoS、ランサム、物理盗難、誤設定による漏洩。個人がプラットフォーム並みのスパム対策・モデレーションを担えるのか。
- 分散型ネットワーク固有の摩擦（インスタンス枯渇、連合モデレーション対立、プロトコル分断）を「教訓」として挙げるだけで、個人要塞がそれをどう克服するのかの設計がない。オープンプロトコルは「友情を裏切らない」が、スパム・ハラスメント・情報操作は裏切る。
- 災害・停電時の「レジリエンス」を強調するが、個人単位のバックアップと国家・地域単位の情報インフラの違いを混同している。
### 4. 経済・社会・AI時代の持続可能性
第6章でニュースレター（Ghost＋Stripe等）に触れるが、不十分。
- 広告・手数料モデルを否定するなら、直接購読以外の持続可能なモデル（マイクロペイメントの摩擦、読者数の壁、長期アーカイブの費用）を掘り下げるべきだ。
- AI時代の「永続性」を第4部に予告するが、前半部でも触れられるべき点が多い。AIスクレイピングによるコンテンツ搾取、合成コンテンツによる信頼崩壊、エージェントが「主権的サイト」をどう扱うか、など。Local-firstは強いが、AIが生成する「永遠に生きる偽情報」との戦いは別次元だ。
- 社会的孤立リスク。要塞化は防衛に優れるが、セレンディピティや集合知の生成を阻害し得る。「帝国」と呼ぶなら、外交・通商の設計がもっと必要だ。
### 5. 歴史的・実証的甘さ
弁証法的4期分けは美しいが、過度に進歩史観的。過去の「分散回帰」の失敗（個人サーバーブーム、早期Fediverseの停滞など）からの教訓が薄い。定量データ（ユーザー流出、生存率）は引用されるが、ソースの厳密性や反論データへの言及が弱い。Jeff Huangの議論を援用するなら、静的・ミニマル志向と現代のリッチ・ソーシャル期待の緊張関係も扱うべきだ。
### 総評
記事の強みは、技術スタックを思想的に統合し、「原本を手元に、配信を交換可能に」という原則を明確にした点にある。これは正しい方向性だ。しかし、「地政学」と「主権回復」を標榜するなら、個人の技術的要塞化が抱える権力・格差・運用・集団的脆弱性の議論を避けてはならない。理想のロードマップとしては魅力的だが、現実の政治経済・物理制約を直視した批判的工学が欠けている。後半部（第3・4部）でこれらを補完しなければ、単なる技術愛好家の高揚したマニフェストに終わるリスクが高い。
足りないのは「容赦ない現実直視」だ。理想を語るなら、その理想が崩れる条件を先に徹底的に洗い出せ。
コメント
コメントを投稿