VuePress でブログを公開するまでのロードマップ — 2021 年の手順と 2026 年に転用できる考え方

2026 追記: 旧 VuePress ブログから移植した記事。手順 UI のスクリーンショットは 2021 年当時のもので、Netlify / お名前.com の画面は現行 UI と差分がある。VuePress 1.x 自体は新規構築に向かないため、本文は「2021 年の構築記録 + 4 段ロードマップとして転用できる骨子」という二重構成で書き直してある。

2021 年当時、Aulvem の前身ブログは VuePress 1.x で組み、GitHub にソースを置いて Netlify でビルド・配信し、お名前.com で取った独自ドメインを当てていた。よくある「無料でブログを公開する」記事を読みながら手を動かしたが、どこで何をやっているのかの全体像が見えるまでに時間がかかった。

この記事は、当時の自分が最初に欲しかった「全体ロードマップ + ステップ別の責務」をまず提示する。VuePress 1.x はもう新規採用の選択肢ではないが、ロードマップ自体は Astro + Cloudflare Pages の組み合わせにそのまま転用できる。

VuePress のディレクトリ構成そのものについては別記事に分けてある（VuePress/blog のディレクトリ構成 — 2021 年の構築メモ）。ここでは「個別ファイルの中身」ではなく「サイト全体を公開状態に持っていくまでの段取り」に絞る。

短い答え — 4 段ロードマップに分けて 1 段ずつ片付ける

短い答え: VuePress ブログを独自ドメインで公開するまでは、(1) ローカル開発 → (2) GitHub にソースを置く → (3) Netlify が自動ビルドして配信 → (4) お名前.com のネームサーバーを Netlify に委任、の 4 段に分けて 1 段ずつ片付けるのが一番早い。

理由は責務の分離。1 つのサービスにまとめると「どこで失敗したか」が分かりづらくなる。書く・保管する・ビルドする・公開する、を別レイヤーに置くと、トラブル時の切り分けがしやすい。

全体図にするとこうなる。

[ローカル PC]
   │ git push
   ▼
[GitHub] ──── ソースの正本
   │ webhook
   ▼
[Netlify] ──── ビルド & 静的配信（xxx.netlify.app）
   │ DNS (ネームサーバー委任)
   ▼
[お名前.com のドメイン]
   │ 独自ドメインで公開
   ▼
[読者]

注意点: この 4 段は VuePress 固有ではない。Astro でも Hugo でも、Markdown を静的 HTML に変換して配信するタイプの SSG なら同じ並びになる。VuePress 部分は (1) と (3) のビルド命令にしか出てこない。

用語: SSG と Jamstack — このロードマップが成り立つ前提

SSG（Static Site Generator）: Markdown や JSON をビルド時に静的 HTML に変換するツールの総称。VuePress / Astro / Next.js (output:static) / Hugo / Jekyll などが該当する。リクエスト時にサーバーで動的に組み立てる WordPress 等の CMS と対になる概念。

Jamstack: JavaScript / API / Markup（プリビルドされた静的ファイル）の頭文字。SSG で作った HTML を CDN に置き、必要な動的処理だけ外部 API で補う構成のことを指す。Netlify はこの Jamstack を前提に設計されたホスティング。

このロードマップが成り立つのは、出力物が「単なる静的ファイル」だからこそ。GitHub にソースだけ置けば Netlify がビルドし直して CDN に撒く、というシンプルさが Jamstack 側の前提に支えられている。

ステップ 1 — ローカルで VuePress プロジェクトを開発・執筆する

短い答え: ローカルで VuePress プロジェクトを開発・執筆するフェーズでは、vuepress dev src でホットリロードしながら Markdown と Vue コンポーネントを書く。

理由は反復速度。デプロイ後に直すより、ローカルで完結する方が一桁速い。ビルド時間も短いので、書きながら整える運用が現実的だった。

具体的には次の構成で開発した。

src
├─ _posts                   各記事 Markdown
│  └─ category
│     └─ page.md
└─ .vuepress
   ├─ components            記事用コンポーネント vue
   ├─ public                画像・robots.txt
   ├─ theme                 layouts / components / styles
   ├─ config.js             VuePress 本体の設定
   └─ enhanceApp.js         Vue プラグインの差し込み口

_posts/ が記事、.vuepress/ がフレームワーク設定とテーマ、という二分割。詳細はVuePress/blog のディレクトリ構成に書いた。

注意点: 開発中は vuepress dev src --host 0.0.0.0 --port 8080 で LAN 内の別端末から開いてスマホ表示を確認できる。Markdown の見た目はデスクトップだけ見ていると詰めが甘くなりやすい。

ステップ 2 — GitHub にリポジトリを作りソースをプッシュする

短い答え: GitHub にリポジトリを作りソースをプッシュするフェーズでは、空のリポジトリを作り、ローカルから git remote add → git push -u origin main でソースだけを上げる。

理由はソースとビルド成果物の分離。dist/ や node_modules/ を Git に乗せると履歴が肥大化して、Netlify 側で再ビルドする意味も薄れる。

具体的には .gitignore で以下を除外していた。

node_modules/
src/.vuepress/dist/
src/.vuepress/.cache/
src/.vuepress/.temp/
.env
.env.local

ビルド成果物は Netlify が毎回作り直すので、リポジトリには src/ と package.json / package-lock.json だけ入っていれば足りる。

注意点: 公開リポジトリにする場合、API キーやアクセストークンを誤コミットしないこと。当時は GitHub Secrets と Netlify の環境変数のどちらに置くかで迷ったが、結論「ビルド時にしか使わない値は Netlify 側、ランタイムから漏れる前提なら持たない」のが安全。

ステップ 3 — Netlify にリポジトリを接続して自動ビルドさせる

短い答え: Netlify にリポジトリを接続して自動ビルドさせるフェーズでは、Netlify の Add new site → Import an existing project で GitHub リポジトリを選び、ビルドコマンドと公開ディレクトリを指定する。

理由は webhook 駆動の自動化。GitHub への git push を Netlify が検知して、毎回最新ソースから vuepress build を回し直してくれる。手で npm run build → サーバーへ FTP、という昔ながらの流れがまるごと消える。

具体的な設定は以下だった。

Netlify ログイン後の流れは、ざっくり以下のとおり（UI は 2021 年当時のもの）。

リポジトリ選択後、ビルド設定で vuepress build src と src/.vuepress/dist を入力するとデプロイが走る。

注意点: 初回ビルドは Node のバージョン違いで落ちることが多い。NODE_VERSION 環境変数を 14 のように固定するか、リポジトリ直下に .nvmrc を置いておくと事故が減る。詳しい手順はVuePress / 静的サイトを Netlify にデプロイするに分けている。

ステップ 4 — お名前.com で独自ドメインを取得する

短い答え: お名前.com で独自ドメインを取得するフェーズでは、希望のドメイン名を検索 → サーバー契約は「利用しない」を選択 → 決済する、までで完結する。サーバーを同時契約する必要はない。

理由は責務分離。お名前.com の役割は「ドメインの所有」だけで、ホスティングは Netlify が担う。サーバー契約までセットで案内されがちだが、Jamstack 構成では不要。

実画面はこうなっていた。

サーバー選択欄では「利用しない」を選んで進む。

注意点: Whois 情報公開代行は無料の範囲で必ず有効化する。個人情報がそのまま Whois に載るのを避けるため。更新料はドメインによって新規登録料より高くなる場合があるので、長期運用前提なら .com / .net など標準的な TLD の方が後で読みやすい。

ステップ 5 — Netlify と お名前.com をネームサーバー委任でつなぐ

短い答え: Netlify と お名前.com をネームサーバー委任でつなぐフェーズでは、Netlify 側で Add custom domain → Set up Netlify DNS を実行し、表示された 4 つのネームサーバーを お名前.com Navi の「ネームサーバー変更」に貼り付ける。

理由は DNS の管理を Netlify に寄せるため。ネームサーバーを委任すると A / CNAME レコードや SSL 証明書（Let’s Encrypt）の発行を Netlify が肩代わりしてくれる。お名前.com 側で自分でレコードを書く必要がなくなる。

Netlify の overview から Domain settings を開く。

Add custom domain を進めると、最終的に 4 つのネームサーバーが表示される。

お名前.com Navi にログインし、対象ドメインの「ネームサーバーの変更」で「その他のネームサーバーを使う」を選び、控えた 4 つを貼り付ける。

反映は数分〜最大 48 時間。半日経って独自ドメインで開けない場合、別ネットワーク（モバイル回線など）からアクセスして DNS キャッシュの影響かどうかを切り分ける。詳しい注意点はNetlify に お名前.com の独自ドメインをつなぐに分けて書いた。

注意点: ネームサーバー委任後は、お名前.com 側の DNS レコード設定画面はもう触らない。Netlify DNS が正本になるので、サブドメインの追加やメール用 MX レコードもすべて Netlify の DNS Records UI から行う。

比較表 — 2021 年の VuePress 構成と 2026 年の Astro 構成

ロードマップ自体は変わらないが、各レイヤーで選ぶ道具は 5 年で入れ替わった。Aulvem 自身も VuePress から Astro に移行している。

ここで言いたいのは新しい方が「優れている」ではなく、4 段のロードマップは変わらず、各段の実装だけ差し替えていけばよい、ということ。VuePress から Astro への移行も、レイヤーごとに区切って 1 つずつ置き換える形で進めた。

注意点: Netlify は 2026 年でも有効な選択肢で、Forms / Identity / Edge Functions など独自機能を使う前提なら今も第一候補になる。Cloudflare Pages との優劣はユースケース次第。

よくある質問

Q. VuePress 1.x で今からブログを始める意味はあるか？ A. 新規ブログの第一候補としては勧めない。VuePress 1.x はメンテが実質止まっており、依存パッケージの脆弱性対応も期待しづらい。Markdown 中心の静的ブログなら Astro + content collections や VitePress の方が学習コストに見合う。Vue を維持したい個人的な理由がある場合のみ、VitePress を候補に入れる。

Q. GitHub と Netlify を分ける必要は本当にあるか？ A. 原則ある。GitHub は「ソースの正本」、Netlify は「ビルド済み HTML の配信」と責務が違うため、片方が落ちてももう片方が残る。GitHub Pages や Cloudflare Pages のように両方を兼ねるサービスもあり、その場合は一元化してもよい。ただし Pages 系は CI のカスタマイズに制約があるので、ビルド工程を細かく組みたい場合は分けたほうが楽。

Q. ドメイン取得を後回しにしても公開はできるか？ A. できる。Netlify は無料で xxx.netlify.app のサブドメインを発行するので、独自ドメインを買う前にビルドと内容の確認まで進められる。実装上、ドメイン接続は最後に切り替えるのが安全。先にドメインを買って待ち時間が長くなるより、サイトが動くことを確認してから DNS をいじる方が事故が少ない。

Q. 2026 年に同じ構成を組むなら何に置き換える？ A. VuePress → Astro、Netlify → Cloudflare Pages、お名前.com → そのまま（または Cloudflare Registrar）が個人的な置き換え案。ロードマップの 4 段（ローカル開発 → Git ホスティング → ビルド & 配信 → DNS 接続）はそのまま流用できる。逆に言うと、この 4 段を意識せずにサービス名だけ覚えても、別のサービスに移るときに毎回最初からやり直すことになる。

まとめ

VuePress でブログを独自ドメインで公開するまでは、書く場所・置く場所・ビルドする場所・配信する場所を別々のレイヤーに分けて、1 つずつ片付けるのが結局いちばん早かった。

2026 年現在、VuePress 1.x のままで新規構築する人は多くないと思う。それでも、ローカル → GitHub → ビルド & 配信 → DNS という 4 段の責務分割は、Astro + Cloudflare Pages の今でも同じ形で生きている。具体的なコマンドや UI のスクリーンショットは古くなっても、骨子は転用できるという例として残しておく。

関連: VuePress/blog のディレクトリ構成 — 2021 年の構築メモ ／ Netlify に お名前.com の独自ドメインをつなぐ ／ VuePress / 静的サイトを Netlify にデプロイする