Substackだけで書くのは危険？独自サイト＋POSSE戦略で自分のコンテンツを守る方法

2026年6月、テクノロジー系の議論が集まるHacker Newsで394点を獲得した記事がありました。マレーシアのライターElizabeth Tai氏による「Substack writers, you need a website!」です。その冒頭に書かれた一文が、多くの技術者の胸に刺さりました。

「あなたはSubstackの借家人に過ぎない」

耳の痛い指摘です。Substackやnote、Mediumで発信している方にとって、この言葉は単なる比喩ではありません。プラットフォームに依存したコンテンツ運用の構造的なリスクを鋭くついています。

この記事では、次の3点を具体的に解説します。

• なぜプラットフォーム依存がリスクなのか（実際に起きた事例つき）
• POSSE戦略の概念と実装手順（4ステップで今日から始められる）
• 独自サイト構築に必要な技術選定（2026年版SSGガイド）

最初に結論をお伝えします。Substackをやめる必要はありません。「コンテンツの家」と「配信チャネル」を分けるだけです。

あなたのブログは「借家」かもしれない — プラットフォーム依存という盲点

Elizabeth Tai氏が鳴らした警鐘「デジタル小作農」

yourname.substack.com でコンテンツを公開しているとき、あなたのドメインはSubstackが管理しています。記事を何百本書こうと、読者が何千人集まろうと、その資産が積み上がっているのはあなたのドメインではなく、Substackのドメインです。

Elizabeth Tai氏はこの状態を「他人の土地に家を建てること」と表現しました。地主（プラットフォーム）が土地を売ったり、ルールを変えたり、最悪の場合に土地を取り上げたとしても、借家人（ユーザー）には抗う術がありません。

Hacker Newsでこの主張が大きく支持された背景には、技術者コミュニティの経験的な共感があります。プラットフォームのポリシー変更やサービス終了を何度も目撃してきたエンジニアたちにとって、これは仮定の話ではないのです。

「使いやすさ」と引き換えに手放しているもの

Substackが提供してくれるのは確かに価値があります。メール配信インフラ、新規読者の発見機能、課金システム。これらをゼロから構築するコストを考えれば、無料で使えることは大きなメリットです。

しかし、その利便性と引き換えに手放しているものがあります。

• URL（ドメイン権威） — 検索エンジンが積み上げた評価は、Substackのドメインに紐づく
• 読者との直接的な接点 — メールリストの完全な所有権は、エクスポートできるとはいえ曖昧な部分がある
• 表示と収益化のルール — これはプラットフォームが一方的に決定できる

この記事のスタンス — アンチSubstackではない

誤解のないよう明確にしておきます。Substackの配信力と発見性は本物の価値です。今すぐ削除すべきという話ではありません。問題は「そこにしか置いていない」という一点に尽きます。

プラットフォームリスクは仮定の話ではない — 実際に起きた事例

起きてしまった5つの事例

技術者であれば、「それは大げさでは」と感じるかもしれません。しかし、過去10年の記録を振り返ると、プラットフォームリスクは繰り返し現実になっています。

2026年8月現在、Tumblrでは再度の大規模障害が報告されており、プラットフォーム依存リスクへの関心が改めて高まっています。

リスクは「サービス終了」だけではない

多くの人が想定するリスクは「プラットフォームが突然閉鎖される」というシナリオです。しかし実際には、サービス終了よりも頻繁に発生するリスクが4つあります。

1. ポリシー変更 — コンテンツの可否基準が変わる
2. アルゴリズム変更 — 突然、記事が表示されなくなる
3. 収益条件の変更 — 収益化の閾値や配分率が変わる
4. アカウント凍結 — 異議申し立ての手段が限られる

最も現実的なリスクは「サービス終了」ではなく「ルール変更」です。そしてルール変更は予告なく行われます。

技術者が特に注意すべき点

技術記事には独特の資産性があります。チュートリアルやトラブルシューティング記事は、公開から3年後、5年後も継続して検索流入を生み続けます。この長期的な価値が積み上がるドメインが、自分のものでなくなっている状態を認識しておく必要があります。

過去に書いた記事が今でも読まれているとしたら、その恩恵を受けているのはあなたのドメインですか？Substackのドメインですか？

POSSE戦略とは何か — 自サイトを本拠地にする公開モデル

POSSE = Publish on your Own Site, Syndicate Elsewhere

POSSEはIndieWebコミュニティが提唱するコンテンツ公開戦略です。日本語に直訳すれば「自サイトで公開し、他所へ配信する」となります。

[自分のサイト（オリジナル）]
         ↓
[Substack / Medium / SNS（配信チャネル）]

フローは単純です。最初に自サイトで公開し、そのあとで各プラットフォームへ配信する。この順番と意識がPOSSEの核心です。

「クロスポスト」との決定的な違い

「それは単なるクロスポストでは？」と思われるかもしれません。しかし、クロスポストとPOSSEには決定的な違いがあります。

クロスポスト → どこが原本か曖昧。場合によっては同時公開。 POSSE → 原本は「常に自サイト」と明確に定義されている。

この違いを技術的に担保するのが canonical URL（正規URL）の仕組みです。Canonical URLを正しく設定することで、検索エンジンはどこが原本記事かを正確に把握できます。

POSSEで何が変わるのか

POSSEを実践することで、次の4つの変化が起きます。

1. SEO評価が自ドメインに集約される — 被リンクや検索評価は自分の資産になる
2. プラットフォームが消えても記事は残る — Substack側が消えても原本は自サイトにある
3. 読者を自メーリングリストへ誘導できる — 各記事末尾からの導線設計が可能
4. 配信先を後から自由に増減できる — 新しいプラットフォームが登場しても柔軟に対応できる

POSSEのデメリットと限界

技術的に正確な情報を提供するためには、デメリットも正直に述べる必要があります。

• 初期構築コスト — ドメイン取得からサイト立ち上げまで、最初の投資が必要
• エンゲージメントの分散 — Substackのコメント文化のような深いインタラクションは各所に分散する
• 管理の複雑さ — 複数プラットフォームの状態把握が必要になる

コメントの分散については、Webmentionという標準プロトコルが解法として存在します。他サイトへの言及を自サイトに集約する仕組みですが、実装難度はやや高めです。まずは運用を回すことを優先し、Webmentionは後から検討する順番が現実的です。

POSSE戦略の実装方法 — 4ステップの具体的手順

Step 1｜自ドメインのサイトに記事を公開する

すべての出発点はドメインの取得です。yourname.com の形式で、自分の名前やブランドに紐づくドメインを取得してください。年間費用は1,500円前後が目安です。

公開順序は厳守してください。必ず自サイトを先に公開し、検索エンジンにインデックスされてから各プラットフォームへ配信する。この順番を逆にすると、プラットフォーム側の記事が原本と認識されてしまうリスクがあります。

Step 2｜canonicalタグで正規URLを宣言する

自サイトの記事HTMLに以下のタグを追加します。

<link rel="canonical" href="https://yourname.com/posts/your-article/" />

このタグは「この記事の正規URLはここです」と検索エンジンへ伝える宣言です。Substackへ転載した際にSubstack側でもcanonical設定を行えると理想的ですが、2026年時点ではSubstackにネイティブなcanonical設定機能はありません。記事末尾に原本リンクを明示することで補完してください。

Mediumは投稿時にcanonical URLを設定できます。各プラットフォームの対応状況を確認した上で、可能な範囲で設定しておきましょう。

Step 3｜各プラットフォームへシンジケートする

配信形式には「全文転載」と「冒頭＋続きリンク」の2種類があります。

全文転載が適しているケース

• Substackなど、メール配信が主体のプラットフォーム
• プラットフォームのエンゲージメントを最大化したい場合

冒頭＋続きリンクが適しているケース

• SNSなど、クリック誘導を目的とする場合
• 自サイトへのトラフィックを優先したい場合

どちらの形式を選んでも、記事末尾に「オリジナルはこちら」リンクを必ず設置してください。これが読者を自サイトへ引き込む最重要導線です。

Step 4｜自動化して運用負荷を下げる

毎回手動でコピー&ペーストするのは継続が難しくなります。以下のツールを活用して自動化を検討してください。

GitHub Actionsを使ったCI/CDパイプラインに配信ステップを組み込む方法も有効です。記事のマージをトリガーに、自動的に各プラットフォームへ配信する構成が実現できます。

最小構成から始めるなら

すべてを一度に整備しようとすると挫折します。「ドメイン取得＋SSGで公開＋canonical設定」の3点だけでも、POSSEの価値の8割は取れます。自動化は運用が安定してから段階的に追加してください。

独自サイトとSubstackの使い分け — 役割分担の設計図

「家」と「チャネル」で考える

考え方のフレームを変えると整理しやすくなります。

• 独自サイト = コンテンツの「家」（アーカイブ・SEO資産・ポートフォリオ）
• Substack = 「配信チャネル」（新規読者獲得・メール到達・課金導線）

家は自分のものでなければなりません。チャネルは目的に応じて使い分けて構いません。

用途別マトリクス

メーリングリストは「必ず自分で持つ」

読者リストは、コンテンツそのものと同等かそれ以上に重要な資産です。そして、最も移植が困難な資産でもあります。

Substackは読者リストをCSV形式でエクスポートできます。しかし「エクスポートできる」と「移行済み」は全く別物です。エクスポートしたリストのインポート先として、Ghost（自己ホスト型）・ConvertKit・Buttondown・MailerLiteなどを選択肢として検討してください。

今すぐ移行する必要はありません。ただし今月中にエクスポートを一度実行して、手元にバックアップを確保しておくことは強くお勧めします。

FAQ｜Substackをやめるべき？

答え：やめなくていいです。使い方を変えるだけです。

削除ではなく「原本の場所を移す」というリフレーミングが正確です。Substackの課金機能・配信機能はそのまま使いながら、コンテンツの原本だけを自サイトに置く運用は十分に成立します。

静的サイトジェネレータ選定ガイド — 2026年版

なぜ技術者にはSSGが最適なのか

静的サイトジェネレータ（SSG）が技術者のブログ運営に向いている理由は明確です。

• Markdownで書ける — 慣れ親しんだ記法でそのまま記事作成
• Gitでバージョン管理 — 記事の変更履歴が完全に追跡できる
• ホスティングがほぼ無料 — GitHub Pages / Netlify / Cloudflare Pages
• 表示速度が速い — サーバーサイドの処理がないため、Core Web Vitalsで有利
• メンテナンスコストが低い — WordPressのようなプラグイン管理・セキュリティ更新が不要

主要SSG比較表

3つの質問で決める選定フロー

Q1「記事数は将来1,000本を超えそうか？」 → YESなら Hugo。ビルド速度がダントツで、大規模コンテンツでも実用的な速度を維持します。

Q2「デザインや動的要素にこだわりたいか？」 → YESなら Astro。ReactやVueコンポーネントを混在させながら、デフォルトでJavaScriptを最小化できます。

Q3「とにかく最速で無料公開したいか？」 → YESなら Jekyll + GitHub Pages。設定がシンプルで、GitHubのリポジトリをそのままサイトとして公開できます。

2026年の推奨

• トラフィック・表示速度重視 → Astro
• 記事量・シンプル運用重視 → Hugo

ホスティングの無料枠比較では、Cloudflare Pagesがビルド回数・帯域ともに最も寛大な条件を提供しています。Netlifyはビルド時間制限があるため、記事数が増えてきたら移行を検討してください。

FAQ｜技術的に難しくないか？

AstroもHugoも、公式チュートリアルに沿って進めれば1〜2時間で初回デプロイが完了します。既存のテーマを使えば、デザイン作業をゼロから始める必要はありません。Markdownが書けて、GitHubが使えれば、技術的なハードルは実際には高くありません。

技術者向けブログ運営のベストプラクティス5選

1. ドメイン所有は交渉不可の必須条件

CMSは何度でも乗り換えられます。しかしドメインを変えるとSEO資産はリセットされます。WordPressからAstroへの移行も、SubstackからGhostへの移行も、ドメインが同じであれば資産は引き継がれます。サブドメイン（blog.yourname.com）ではなく、ルートドメイン（yourname.com）で運用してください。

2. RSSフィードを必ず公開する

RSSフィードは、あらゆる自動シンジケーションの起点になります。前述のBridgyやSiloRiderも、RSSフィードをベースに動作します。また、RSSは読者がプラットフォームを介さずに購読できる唯一の標準手段です。主要なSSGはすべてRSSフィードを自動生成できます。

3. canonical URLの運用ルールを固定する

canonical設定の最大の敵は「たまに忘れる」という運用ミスです。公開手順をチェックリスト化し、毎回同じ手順で実行するルールを作ってください。記事公開の際の確認項目は3点あれば十分です。①自サイトへのpushが完了したか、②canonicalタグが正しく設定されているか、③インデックス登録のリクエストを送ったか。

4. コンテンツはMarkdown＋Gitで管理する

特定のCMSに依存しないフォーマットで記事を保存することが、将来の移行コストをほぼゼロにします。Markdownファイルをそのままリポジトリで管理していれば、SSGを変更しても記事本文は一切手を加えずに移行できます。

5. 「明日サービスが止まったら」で定期点検する

年に1回、次の4点のバックアップ所在を確認してください。

• 記事本文 — Gitリポジトリに含まれているか
• 画像・メディア — ローカルにコピーがあるか
• 読者リスト — 最新のCSVエクスポートが手元にあるか
• コメント — プラットフォーム依存のものは諦めるか、Webmentionで対応するか

よくある質問

Q. POSSEは手間が増えませんか？

初期構築のコストは確かにあります。しかし一度環境を整えてしまえば、Bridgy等の自動化ツールによって追加の作業工数はほぼゼロになります。記事を自サイトにpushすれば、あとは自動的に各プラットフォームへ配信される状態が目標です。

Q. Substackから移行する具体的な手順は？

段階的に進めることをお勧めします。

1. Substackからメール読者リストをCSV形式でエクスポート
2. ConvertKit / Buttondown等へインポートし、移行先を確保
3. 既存のSubstack記事をMarkdown形式で変換（html-to-markdownツールが利用可能）
4. 自サイトへ記事を移設し、canonical URLを設定
5. Substack側の記事には「オリジナルはこちら」リンクを残す

一度にすべてを移行しようとせず、新しい記事からPOSSEを適用していく方法が現実的です。

Q. 既存のSubstack記事のSEO評価はどうなる？

既存のSubstack記事を削除することは推奨しません。削除すると、その記事へのバックリンクが404になり、積み上げてきたSEO評価が失われます。canonical設定と「オリジナルはこちら」リンクを設置した状態で共存させながら、新しい記事から順次POSSE方式に切り替えていく戦略が最も損失が少なくなります。

Q. Substackの課金機能はどうなる？

コンテンツの原本を自サイトに置きながら、Substackの課金機能はそのまま継続利用できます。Substackを「決済と配信のインフラ」として活用しつつ、コンテンツの正規URLは自サイトに維持する運用は完全に成立します。将来的に読者規模が育ったタイミングで、Ghost等への移行を検討する流れが一般的です。

まとめ — 今日からできる3つのアクション

この記事を読んでいただいた方へ、具体的なネクストアクションをお伝えします。

今日：ドメインを取得する 年間1,500円前後の投資です。yourname.com または yourname.dev を取得してください。このドメインがあなたのデジタル住所になります。

今週：最小構成のサイトを立ち上げ、記事を1本移す AstroまたはHugoの公式テーマを使い、1〜2時間で最初のデプロイを行ってください。完璧なデザインは後回しにして、まず「動く状態」を作ることが重要です。

今月：canonical設定を習慣化し、メールリストをバックアップする Substackからメール読者リストをCSVエクスポートし、手元に保管してください。これだけで、最悪の事態が起きたときのダメージを大幅に軽減できます。

プラットフォームは道具であって、住所ではありません。住所は自分で持つ。これが、長期的にコンテンツを資産として育てるための、唯一の確実な方法です。

参考リンク

• Substack writers, you need a website! – Elizabeth Tai
• POSSE – IndieWeb
• How to Achieve POSSE – Genx Notes
• POSSE Strategy – dasroot.net
• The Truth About Substack for Creators in 2026 – Stack Influence