1. あのサービスが消えたら、何が残るか
長年使っていたブログサービスが終了した、という経験を持つ人は少なくない。書いた記事は消え、積み上げたコンテンツは跡形もなくなる。バックアップを取っていた人だけが、何かを持ち出せた。
SNSのアカウントが突然凍結されることもある。何年もかけて育てたフォロワーと、投稿のすべてが、一夜にして失われる。
これらは事故ではなく、構造的な問題だ。「プラットフォームの中にコンテンツを置く」という設計を選んだ時点で、その依存は始まっている。
2. 所有と利用の違い
「自分のコンテンツ」と言うとき、何を指しているか。
多くの場合、それは「あのサービスの中にある自分のページ」だ。アクセスできる。編集できる。公開できる。しかし、サービスが終了すればアクセスできなくなる。プラットフォームのルールが変われば、表示方法が変わる。アカウントが停止されれば、すべてを失う。
これは所有ではなく、利用だ。より正確には、賃借だ。家賃を払い続ける限り住めるが、大家の都合で出ていかなければならないことがある。
本当の意味でコンテンツを所有するとは、そのデータが自分の管理下にあることだ。サービスが消えても、データは残る。プラットフォームが変わっても、内容は変わらない。
2.5 自動化で突破しようとした時代
かつて、MediumもnoteもNotionも使っていた。そしてそれぞれに、自動化で運用コストを下げようと試みた。キーボードやマウスの操作を自動化するツールを使い、投稿・更新・管理をスクリプト化した。
しばらくは動いた。しかしやがて、同じことが繰り返された。サービスのインターフェースが変わる。操作の順序が変わる。制約が追加される。そのたびに、自動化スクリプトのメンテナンスが必要になった。
外部のUIに依存した自動化は、外部のUIが変わるたびに壊れる。それは自動化ではなく、「壊れ続けるものを直し続けること」だった。
トキストレージを設計した後、ふと気づいた。問題は自動化の方法ではなく、依存の構造そのものにあった。インターフェースに依存している限り、インターフェースが変わるたびにコストが発生する。境界の外に制御権があるものは、どれだけ自動化してもメンテナンスコストが消えない。
MediumもnoteもNotionも、継続をやめた。ツールの問題ではなく、設計の問題だったからだ。境界を持つこと——自分の管理下にあるものとそうでないものを明確に分けること——がその答えだった。
3. GitHubという地盤
コンテンツの置き場所として、Gitリポジトリは優れた選択肢だ。
Markdownファイルは、どんな環境でも開ける。テキストエディタ、ターミナル、ブラウザ——ソフトウェアを選ばない。20年後も、おそらく読める。フォーマットとして枯れている。
GitHubはそのリポジトリをホストするサービスだが、重要なのはGitHub自体ではなく、その下にあるGitだ。GitHubが消えても、リポジトリはローカルに残る。別のホスティングサービスに移せる。分散して複数箇所に置ける。
コンテンツ（Markdown）→ 自分のGitリポジトリ
↓
レンダリング → プラットフォーム（Zenn、GitHub Pages、その他）
この構造が成立するとき、プラットフォームは「表示する場所」になる。消えても、別の場所で表示すればいい。コンテンツそのものは失われない。
4. Zennという選択の理由
技術系の発信に、Zennを使っている。その理由はシンプルだ。
Zennは「GitHubリポジトリのMarkdownを記事として公開する」設計になっている。コンテンツはGitHubにある。Zennはそれを読んで、整形して、表示しているだけだ。
つまり、Zennが消えても記事は消えない。GitHubリポジトリは手元に残り、別のサービスで公開し直せる。Zennのルールが変わっても、Markdownファイルは変わらない。フォーマットに縛られない。
これは他の多くのプラットフォームとは根本的に異なる設計だ。コンテンツをサービスの中に閉じ込めず、外部のリポジトリを参照する。その一点が、依存関係を大きく変える。
5. MediumやnoteとZennの違い
「エクスポート機能があるから大丈夫」という反論がある。確かに、多くのサービスはデータの書き出し機能を持っている。しかしエクスポートできることと、最初から自分のものであることは、根本的に違う。
似ているようで、設計思想が真逆だ。
Medium・note：サービスの中にコンテンツがある → 出ていくとき荷物を持たせてくれる
Zenn：最初から自分のGitHubにコンテンツがある → そもそも外に出す必要がない
エクスポート機能は「出口」だ。出口があることは重要だが、それは依存の解消ではない。サービスが突然終了したとき、エクスポートする時間が与えられるとは限らない。エクスポートしたデータが完全に再現可能とも限らない。
Zennの場合、「移行」という概念がそもそも発生しない。コンテンツはずっと自分のGitHubにある。Zennが消えても、別のサービスが同じリポジトリを読めばいい。それだけだ。
Mediumやnoteはコンテンツのホスティングサービスだ。Zennはコンテンツのレンダリングサービスだ。この違いが、外部依存性の差になる。
6. 外部依存性という概念
ソフトウェア設計に「外部依存性」という概念がある。システムが外部のコンポーネントにどれだけ依存しているかを表す。依存が多いほど、外部の変化がシステムに影響を与えやすい。
コンテンツ発信にも同じ概念が当てはまる。
特定のサービスにしか存在しないコンテンツは、外部依存性が高い。サービスの仕様変更、価格改定、サービス終了——すべてが直接的なリスクになる。
自分のリポジトリに存在し、プラットフォームは表示する場所に過ぎないコンテンツは、外部依存性が低い。プラットフォームが変わっても、コンテンツは影響を受けない。
7. 声メモ・エッセイ・技術記事の統一設計
この発想を徹底すると、コンテンツ発信全体の設計が変わる。
声でメモしたものは、プライベートなGitリポジトリに蓄積される。エッセイはGitHubでホストされたサイトに置く。技術記事はZennがGitHubから読み込む。すべてのコンテンツが、自分の管理下にあるGitリポジトリに存在している。
プラットフォームはその上に乗るレイヤーだ。使いやすければ使う。使いにくくなったら乗り換える。コンテンツはどこにも縛られていない。
これは「道具は消耗する、インフラは育つ」という考え方の、コンテンツ版だ。プラットフォームは道具であり、消耗する。データは自分のインフラであり、育つ。
8. ベンダーロックインとの戦い
「ベンダーロックイン」という言葉がある。特定のベンダーの製品やサービスに依存し、他に移行しにくくなった状態だ。クラウドサービスでよく議論される概念だが、コンテンツ発信にも同じ問題がある。
独自フォーマットで書かれたコンテンツは、そのサービス以外では読めない。エクスポート機能があっても、完全な再現は難しいことが多い。長年積み上げたコンテンツが、特定のサービスに縛られていく。
標準的なフォーマット（Markdown）で書き、バージョン管理システム（Git）で管理し、オープンなホスティング（GitHub）に置く。これはベンダーロックインに対する、設計レベルの抵抗だ。
9. 1000年残すための土台
トキストレージは「1000年残す」という使命を掲げている。1000年先を考えたとき、今存在するどのプラットフォームも存在しないだろう。会社が消え、サービスが終わり、フォーマットが廃れる。
だからこそ、コンテンツをプラットフォームから独立させることが重要になる。データを自分で持つ。フォーマットを標準的なものにする。複数の場所に分散して保存する。
これは1000年という極端なタイムスパンを前提にした話だが、10年先を考えても同じことが言える。今使っているサービスが10年後も存在するかどうかは、誰にも分からない。
「書いたものが消えない場所」を、自分で設計する。それがコンテンツを所有するということだ。
プラットフォームはレンダリングする場所であって、所有する場所ではない。データが自分の管理下にある限り、どのサービスが消えても、コンテンツは残る。
関連コンテンツ
この設計思想を実践した具体例として、伊賀の忍者の末裔に学んだ「網膜瞬間記憶術」をAIで再現するZenn本を書いた。全20章・約40,000字。コンテンツはGitHubに置き、Zennがレンダリングしている——まさにこのエッセイで述べた設計そのものだ。