--- title: "自分のものは自分で管理する：データ主権を取り戻す、新しいブログができるまで" description: "引っ越しは、ここ数年のブロガーにとっていちばん重たい心の旅路です。" author: "kidneyweakx" published: 2025-12-31T00:00:00.000Z updated: 2026-10-29T11:27:12.629Z lang: ja tags: ["blog", "cloudflare", "隨筆"] canonical: https://kidneyweakx.com/blog/take-back-your-data-sovereignty?lang=ja alternate_zh_tw: https://kidneyweakx.com/blog/take-back-your-data-sovereignty.md alternate_en: https://kidneyweakx.com/blog/take-back-your-data-sovereignty.md?lang=en --- # 自分のものは自分で管理する：データ主権を取り戻す、新しいブログができるまで > 引っ越しは、ここ数年のブロガーにとっていちばん重たい心の旅路です。 私はブログを気が向いたときにしか更新しないタイプですが、ブログへの思い入れは実はけっこう深いほうです。大学時代には成長の週記やハマりどころの記録をたくさん書きましたが、卒業後はいろいろなことに追われて、逆に何も書かなくなってしまいました。文章がうまいとは思っていませんが、2019 年に Rails を書いたり、デュアルブートを入れたり、Oracle を直したりした記事を読み返すと、やっぱり **これは自分のものだ、このまま消えていいものじゃない** と思うんです。 この記事では、このブログが何度引っ越してきたのか、そして最終的になぜ「全部自分で管理する」と決めたのかを記録しておきます。
## 1 回目の引っ越し：Hexo 時代 最初のブログは Hexo でした。Markdown を書いて、`hexo deploy` で GitHub Pages に push するだけ。無料でシンプル。当時は「Hexo で無料ブログを作る」という記事も書いていて、その後 utterances でコメント欄を付けたり、V5 へのアップグレードで大量にハマったりしました。 Hexo のいちばんの長所は、**記事がただの Markdown ファイルの集まりで、自分の repo に置いてある** こと。どこへでも持っていけます。 短所は、本当にただのファイルの集まりでしかないこと。管理画面がほしい、予約投稿がほしい、多言語対応がほしいとなったら、全部自力で無理やり作るしかありません。 ## 2 回目の引っ越し：CMS の誘惑 2025 年にサイトを再開したとき、私は「ちゃんとした CMS」の誘惑に負けました。フロントは SvelteKit で Cloudflare 上に、バックエンドは PayloadCMS、データは Turso。
Payload は使いやすくて、管理画面はきれいだし、フィールドも柔軟です。でもしばらく使っていると、だんだん違和感が出てきました： * 月に 1〜2 本しか更新しないブログのために、CMS サービスとデータベースを 1 つずつ養っている * 記事がデータベースの 1 行になってしまい、**もう自分で読めるファイルではない** * バックアップや引っ越しをしたければ、まずその schema を理解してから、エクスポート用のスクリプトを書かなければならない これが、私の言うデータ主権の問題です。データはもちろん今でも「自分のもの」ですが、何層もの抽象化に包まれている。いつか Payload がバージョンアップしたり、Turso がプランを変えたりしたら、こちらもそれに付き合って走り回るしかありません。 ## 3 回目の引っ越し：CMS を取り壊す 2026 年 6 月、Payload をまるごと削除しました。今の構成は、ちょっと笑えるくらいシンプルです： * R2 bucket ひとつが「データベース」のすべて：`index.json` が記事一覧、`content/.md` が本文、`media/` に画像 * 管理画面は Elysia + Svelte で自作した小さなツールで、`cms.kidneyweakx.com` で動いていて、前段に Cloudflare Access を置いているので私しかログインできない * フロントの Worker は **R2 の読み取り専用権限しか持っていない**。型の上では `get` / `head` / `list` しか公開せず、runtime でもこの 3 つのメソッドしか転送しないので、いつかフロントが突破されたとしても、記事は 1 本も書き換えられない 引っ越しのときには使い捨てのインポートスクリプトを書いて、Turso にある記事を全部 Markdown に変換して R2 に放り込みました。変換が終わって、すべての記事がまたひとつひとつの `.md` ファイルに戻ったのを見た瞬間、**質屋から大事なものを請け出したような気分になりました。データを自分で握っておくことって、やっぱりすごく大事です**。
## なぜそこまでこだわるのか？ 最近は [Solid(ar)ity](https://github.com/p2p-solidarity/solidarity) という、鍵を自分で持つタイプのプロフィールページ兼名刺アプリを作っていて、チームにはひとつ原則があります。**「会社が潰れても、仕組みは残る」**。データはユーザー自身のデバイスとクラウドに置き、検証はすべてクライアント側で動かす。たとえプロジェクトが明日消えても、すべてのカード、すべての証明が検証でき、さらには全部がそのまま動き続けなければならない。 そうやって作っているうちに、ふと自分のブログを振り返ってみたら、自分の記事ですらそれができていない。さすがに筋が通らないし、cypherpunk を名乗る身として、こんなにポンコツなままでいいのか、と。 というわけで、このブログの今の原則は： 1. **記事はファイルであって、データ行ではない**。R2 を開けば読めるし、引っ越したくなったら丸ごと持っていける 2. **書き込みの入口はひとつだけ**。書けるのは管理画面だけで、フロントは永遠に読み取り専用 3. **依存しなくて済むサービスには依存しない**。DB なし、サードパーティ CMS なし。いつか Cloudflare が使えなくなっても、Markdown ならどんな静的サイトジェネレーターに放り込んでも生き残れる ## AI 向けのバージョン 記事が全部 Markdown なので、ついでに AI が読む用のバージョンも作りました。各記事の URL の末尾に `.md` を付ければ元の Markdown が取れて、ほかに `llms.txt` と RSS もあります。AI 経由で答えを探す人がどんどん増えているので、クローラーに大量の HTML をかじらせるより、きれいな原文を直接渡したほうがいい。ただ、この仕組みができたのはだいぶ後になってからです。
## 自分のものは自分で管理する 結局のところ、「データ主権」というと大げさに聞こえますが、実はとても小さな話です。**自分が書いたものが、どこに置いてあって、どんな形をしていて、どうやって持ち出せるのかを知っておくこと**。 3 回引っ越して最後にわかったのは、いちばんいい構成は 2019 年の Hexo とほとんど同じ、Markdown ファイルの山だということ。違うのは、使いやすい管理画面と、Access という玄関の鍵が増えたことだけです。 ぐるっと一周して、**やっぱり KISS が正解だった**。（またそれかい XDD）