Zenn、note、GitHub Pages、独自サイトの選び方を調べる
個人技術ブログの公開先を選ぶとき、読者を集めやすいかだけを見ると、後から移行の問題にぶつかります。
私が比較で最初に確認したのは、記事の正本をどこへ置くかです。
その次に、URLを維持できるか、レビューと公開を自動化できるか、運用の負担を許容できるかを見ました。
この順番にすると、Zennやnoteのようなホスト型サービスと、Astroを使う独自サイトは競合する選択肢ではなくなります。
原稿の保存場所と配信先を分離できるからです。
比較の前提を5つに分ける
1. 原稿の正本
記事をMarkdownとしてGitへ保存すれば、公開先を変更しても本文を再利用できます。
専用エディターの記法へ依存すると、画像、埋め込み、目次、リンクの変換作業が移行時に発生します。
したがって、長く残したい技術ノートでは、公開サービス以外にも原稿と画像の元データを保持します。
2. URLの継続性
サービスのURLは公開までが短い一方、サービスの仕様やアカウント状態に影響されます。
独自ドメインは初期設定が必要だが、ホスティング先を変えても同じURLを維持しやすいです。
ただし、独自ドメインだけで検索流入が増えるわけではありません。
URL構造、内部リンク、記事の内容、更新の継続性を同じ条件で考える必要があります。
3. 発見性と所有権
ホスト型サービスには、サービス内の読者や検索から見つかる経路があります。
独自サイトは、構造、デザイン、URL、計測方法を自分で決められる代わりに、最初から同じ発見経路を持つとは限りません。
この2つは同時に満たせます。
Gitを正本にして、代表的な記事だけをZennなどへ転載する構成も選べます。
重要なのは、読者と自分の双方が正本の記事を判別できる状態にすることです。
4. 自動化
技術ブログでは、次の作業を後から自動化したくなります。
- Pull Requestで本文をレビューする
- Markdownのlintやリンクチェックを実行する
- pushごとにプレビューを作る
- 下書きと公開済み記事を分ける
- RSSとサイトマップをビルドする
Gitリポジトリを中心にすると、これらをCIへ組み込みやすいです。
ホスト型サービスは書き始めの手間が小さい一方、リポジトリ単位の検証や公開手順はサービスの仕様に左右されます。
5. 運用負担
独自サイトでは、依存パッケージ、ビルドエラー、ドメイン、バックアップを自分で確認する必要があります。
静的ホスティングはサーバーの常時運用を軽くするが、更新や設定確認までなくすわけではありません。
ホスト型サービスはインフラ管理を減らせる代わりに、料金、機能、利用規約の変更を受けます。
公式資料から分かることを確認する
Zennの公式マニュアルには、Markdown記法とGitHubリポジトリ連携が案内されています。
これは、Gitで原稿を管理しながらホスト型サービスへ配信する構成が可能であることを示します。
一方、GitHub連携があることと、URL、表示、計測、エクスポートまで所有できることは別です。
GitHub Pagesの公式資料は、リポジトリのHTML、CSS、JavaScriptを公開する仕組みとして説明しています。
Astroの公式ガイドにもGitHub Pages向けのデプロイ手順があるため、Markdownから静的HTMLを作るサイトと組み合わせやすいです。
Cloudflare Pagesの公式ガイドは、GitリポジトリからAstroサイトをビルドする手順を示しています。
静的出力から始め、必要になった場合だけCloudflare固有の機能を追加する判断がしやすいです。
選択肢を同じ軸で比較する
| 選択肢 | 向いている目的 | 確認できる強み | 移行・運用上の注意 |
|---|---|---|---|
| Zennやnote | 早く公開して反応を見る | 執筆から公開までの経路が短い | URL、表示、エクスポートはサービス仕様を確認する |
| GitHub Pages | Git中心で静的公開する | ソースとビルドの対応を追跡しやすい | プロジェクトサイトではbaseとURLを確認する |
| Astro + Cloudflare Pages | 独自サイトを育てる | Git連携、プレビュー、独自ドメインを構成しやすい | プロバイダー設定と依存関係を保守する |
| VPSや自前サーバー | 実行環境まで自由に管理する | サーバー構成とデータ処理を決められる | セキュリティ、更新、監視、バックアップが必要になる |
表の強みは永続的な保証ではありません。
料金、無料枠、公開範囲、エクスポート機能は導入時に公式情報を確認します。
Zennやnoteを先に使う場合
最初の目標が「記事を完成させて公開すること」なら、ホスト型サービスは合理的です。
ビルド環境やデザインを整える前に、執筆ペースと読者の反応を確かめられるからです。
ただし、次の資産をサービス内だけへ置きません。
- Markdownの原稿
- 画像の元ファイル
- 記事のslugと公開日
- 外部リンクや埋め込みの一覧
転載先を増やす場合は、正本と転載先を決めます。
記事の冒頭や末尾から正本へ戻るリンクを付けると、更新版の場所を説明しやすいです。
GitHub Pagesを選ぶ場合
GitHub Pagesは、GitHubリポジトリにある静的なWeb資産を公開する仕組みです。
Astroの静的ビルドをGitHub Actionsからデプロイする構成なら、変更履歴とレビューを残せます。
プロジェクトサイトでは、公開URLへリポジトリ名が含まれます。
その場合はAstroのsiteとbaseを合わせ、内部リンク、RSS、サイトマップのURLも同じ前提で確認します。
独自ドメインを使うと、公開URLからリポジトリ名を外せます。
ログイン、コメント、サーバー側検索のような機能は、静的サイトだけでは完結しません。
必要になった時点で外部サービスや別の実行環境を追加する方が、最初から運用範囲を広げずに済みます。
AstroとCloudflare Pagesを選ぶ場合
Cloudflare Pagesは、Gitリポジトリからのビルドと、push単位のデプロイやプレビューを構成できます。
Astroの公式資料には静的サイトのデプロイとCloudflareアダプターを使う構成があります。
そのため、最初はMarkdownと静的ビルドだけで公開し、必要が出てからフォームや検索などを検討できます。
R2、KV、D1などCloudflare固有のAPIを本文サイトへ組み込むと、別ホスティングへの移行コストは上がります。
拡張する順番は、静的ビルド、CIとプレビュー、独自ドメイン、動的機能の順にするのが説明しやすいです。
私の選択と残した不確実性
技術備忘録を長く残す目的なら、Markdown、画像、メタデータをGitで管理し、Astroでサイトを生成します。
公開先にはGitHub PagesまたはCloudflare Pagesを選べます。
重要なのは、公開先の管理画面へ記事の正本を閉じ込めないことです。
読者との接点を増やしたい記事だけをZennなどへ転載する運用も残します。
一方で、サービスの料金、機能、利用規約、エクスポート仕様は将来変わり得ます。
このノートの比較は、特定サービスの永続的な評価ではなく、導入時に確認する順番を示すものとします。