このブログは、いま Astro + Vercel + GitHub で動いています。最初から「よし、この構成でいこう」と決めていたわけではなく、触ってみて、つまずいて、また戻って、という感じでここに落ち着きました。

最初に決めたかったのは、技術スタックそのものではなく 記事を書く時間をちゃんと残せること でした。AWS / GCP は個人ブログとしては少し大きく感じたので見送り、Cloudflare Pages は GitHub 連携で一回手が止まりました。最後に Vercel を試したら、ここなら書くところまで早く戻れそうだな、という感触になりました。

この記事では hosting 選定だけを扱います。フレームワークとして Astro を選んだ理由は 個人ブログのフレームワークは、Astroを軽く使うことにした に分けました。

きっかけは、書く場所も育てたくなったこと

ブログ自体も自分の環境として扱う

普段は SE をしています。最近は AI エージェントを使って、昔自分で書いたポートフォリオをリファクタリングしたり、細かい作業を手伝ってもらったりしています。これが思ったより楽しくて、気づいたら周辺の環境まで整えたくなっていました。

せっかくここまで触っているなら、ブログも 1 から自分で建ててみよう、という軽い気持ちで始めました。ところが実際にやってみると、記事を書く前の技術選定で思ったより迷いました。ここも含めて残しておくと、後から自分にも効きそうです。

Zenn / Qiita ではなく自前にした理由

記事とサイトの持ち方を自分で決める

最初から Zenn や Qiita に投稿する選択肢もありました。読まれやすさだけを考えるなら、そのほうが早い場面も多いと思います。ここは最初にけっこう迷いました。

それでも自前ブログにしたのは、記事とサイトの持ち方を自分で決めたかったからです。せっかくなら、書く場所そのものも少しずつ育てていきたい。そんな感じです。

  • テンプレートやディレクトリ構造を、サービス側の都合ではなく自分の運用に合わせたい
  • GitHub 上のソースを正本にして、CI/CD で build、link、脆弱性チェックを通したい
  • Vercel の preview URL で、公開前の記事やレイアウトを実際の表示に近い形で確認したい
  • RSS や将来のミラー配信を、自分の URL 設計に合わせて調整できるようにしたい
  • 記事本文は Git repo の Markdown を正本にして、Qiita / Zenn などの投稿サービスや特定クラウドの保存形式に寄せすぎない

外部サービスは導線として見る

Zenn は GitHub 連携でソース管理できますが、テンプレートやディレクトリ構造は Zenn の作法に寄せる必要があります。Qiita も読者に届きやすい一方で、サイト全体の設計や配信まわりを細かく組み立てる用途とは少し違います。

なので、このブログでは自前サイトを正本にして、外部サービスは必要になったら導線やミラーとして使う、くらいの距離感にしています。

迷ったのは、どこで動かすか

AWS / GCP は、ブログ 1 個には少し大きかった

ブログを建てるとなって、最初に思いつくのはやっぱり AWS と GCP でした。これまで触ってきた範囲でもなじみがあるし、できることも多いので。

ただ、ちゃんと検討してみると、ここで一回「あれ、ブログ 1 個にしては大きくないか？」となりました。結論としては 個人ブログ規模では、自分には少し大きすぎる という判断です。

  • S3 + CloudFront + Route53、または GCS + Cloud Run の構成は、組み立て自体はできる
  • でも、IAM、証明書、CDN キャッシュ、ログ、コスト監視を毎月見る運用は、個人ブログとしては気軽ではない
  • 月数百円〜数千円のコストも、何年も続く個人ブログには効いてくる
  • 何より、いちばん時間を使いたいのは記事を書くことだった

というわけで、AWS / GCP は 個人ブログ規模での話として 今回は見送りました。大きめの用途ではもちろん適材適所です。ただ、今回は「記事を書く時間を残す」ほうを優先しました。

Cloudflare Pages は、GitHub 連携で足が止まった

次に試したのが Cloudflare Pages です。「無料枠が大きい」「速い」とよく聞くので、これでいけるならかなり良さそうだなと思っていました。

実際に触ってみると、自分の環境では 思っていたほどスッと進みませんでした。具体的には GitHub 連携で詰まりました。

  • 自分の GitHub には個人で作った organization があって、対象 repo はその organization 配下に置いていた
  • Cloudflare Pages からデプロイするには GitHub 認証を通す必要があった
  • 個人アカウント側に Cloudflare 連携用の GitHub App をインストールしただけでは、対象 repo が出てこなかった
  • 公式 docs を読み直して、organization 配下の repo を扱うなら organization 側にも同じ GitHub App をインストールする必要があると分かった

参考にした公式 docs は Cloudflare Pages — GitHub integration です。ちゃんと書いてあるのですが、最初に読んだ時点ではうまく拾えず、少し遠回りしました。

設定自体は organization 側に App を入れ直せば動きます。ただ、この時点で自分の中では少し熱が下がっていました。ブログを書く前に、接続設定の細かいところで足が止まっている感覚があったからです。

Vercel は記事に戻るまでが早かった

GitHub 連携から preview までが軽い

最後に Vercel を試したら、想像していたより手早く動きました。ここで「あ、これなら記事を書くほうに戻れる」となりました。

  • GitHub repo をつなぐだけで終わり
  • main に push したら本番ビルド、PR を作ると preview deployment の URL が自動で出る
  • ダッシュボードもシンプルで、迷う場所が少ない

「とりあえず公開して、書きながら整える」をやりたい個人ブログには、この摩擦の少なさがかなり大きい な、というのが触ってみての感想です。最初の一歩が軽いと、その後の改善にも入りやすいですよね。

無料枠の範囲で個人ブログは十分動くので、コスト面の不安も今のところありません。

今回の判断

ざっとまとめると、hosting の判断はこうでした。

  • AWS / GCP は個人ブログ規模では自分には大きく感じたので見送った
  • Cloudflare Pages は GitHub 連携でつまずき、自分の運用には少し合わなかった
  • Vercel は GitHub をつなぐだけで動いて、preview deployment が便利だった
  • Zenn / Qiita は初期の正本にせず、自前サイトを軸にしてカスタマイズ性と移し替えやすさを優先した

このくらいの構成なら、記事を書きながら少しずつ直していけそうです。次は 個人ブログのフレームワークは、Astroを軽く使うことにした で、Astro と TypeScript を選んだ理由を整理します。