サーバー移管記

Netlify 無料枠が枯渇した時の ConoHa WING 緊急移管 3 時間体験記 — DNS / FTPS / SSL 全手順

公開: 2026-05-25 · 著者: GRAMSHIFT

Free tier 枯渇症状の特定から本番復旧まで、再現可能な手順を一次情報で

あなたが Netlify Free tier で個人運営メディアサイトを動かしていて「deploy が 5 分前まで動いていたのに突然 Forbidden で失敗する」「ローカルログは『完了』と表示するのに本番に反映されない」「無料枠リセット待ちか移管かで迷ってる」状況なら、私が 個人運営メディアサイト 1 つを Netlify から ConoHa WING に 3 時間で緊急移管した実体験 が判断材料になるはずです。Free tier 枯渇症状の特定から DNS 切替・FTPS デプロイ切替・SSL 発行・ロールバック手順まで、再現可能な全工程を一次情報で公開します。

本記事の結論を先出しすると、以下の3点です。

Netlify Free tier の月間ビルド分数 (個人プラン 300 分) は 記事更新頻度の高いメディアサイトでは予想以上に早く枯渇 する。深夜の自動デプロイで気づかぬうちに枯渇しているケースが多い
移管先の最有力は ConoHa WING (月¥1,400)。マルチドメイン無制限 + FTPS デプロイで継続的な自動更新も対応可能、移管手順は DNS 設定 + FTP 設定で 3 時間以内
緊急時のロールバック手順を事前に整備しておけば、移管リスクは最小化できる (DNS A レコードを Netlify IP に戻すだけで復旧可)

以下、3 時間移管の全工程を順を追って共有します。

Netlify Free tier 枯渇の症状 (気づきが遅れる罠)

2026 年 5 月の Netlify Free tier 仕様 (個人プラン) は以下の通り:

月間ビルド分数: 300 分
転送量: 100GB / 月
同時ビルド数: 1
Concurrent build: なし (有料プランから)

記事更新頻度の高いメディアサイトを自動 deploy で運用すると、月 300 分は予想以上に早く枯渇します。1 回のビルドが 30-60 秒だとしても、毎日 10 回 deploy すれば月 150-300 分 = ギリギリの計算。SEO 系サイトでビルド時間が長い (静的サイトジェネレータの index 構築含む) ケースでは、月 100 回の deploy で 300 分超過。

枯渇すると deploy リクエスト全部が HTTP 403 Forbidden で失敗 します。問題は、ローカルの自動 deploy スクリプトが「exit code 0 = 成功」と判定するケースで、Netlify CLI の version 次第では deploy 失敗を exit code 1 で返さず stdout のみエラー出力するため、ローカルログには「✅ 完了」と表示されて気づきが遅れます。

枯渇を確実に検知する方法 3 つ

「ローカルログは『完了』なのに本番が更新されない」状況を早期発見するために、以下 3 つの監視を入れることを推奨します。

Netlify ダッシュボードの Builds 画面で直近 deploy 確認 — 「Failed」「Cancelled」が連続してたら枯渇のサイン
Discord webhook 通知 — deploy 完了後に本番 URL を curl で叩いて、コンテンツが更新されたかをハッシュ比較。ハッシュが一致しないなら deploy 失敗の可能性
使用量メーター — Netlify ダッシュボード → Billing → Usage で当月の build 分数を確認。月初に「先月の枯渇日」を確認しておくと、当月の枯渇予想日が立つ

監視を入れずに運用していると、月 5-7 日分の deploy がサイレント停止 → 記事が本番未反映で SEO 機会損失、というのが本記事の元になった実体験です。

移管先選定の判断軸 3 つ

Netlify 枯渇後の選択肢:

有料プラン (Netlify Pro): 月 $19、build 分数 1,000 分。料金 / 機能比は良いが、長期的に毎月コストが乗る
別の Jamstack 系サービス: Vercel / Cloudflare Pages (それぞれ Free tier あり、ただし同じ枯渇問題が再発する可能性)
共用ホスティング (FTPS デプロイ): ConoHa WING / Xserver / さくらレンタル等。月¥1,000-1,500、ビルド分数の概念なし、無制限デプロイ可

私のケースでは 「複数メディアサイトを 1 アカウントで管理 + ビルド分数を気にしない安心感」 を重視して、ConoHa WING を選びました。マルチドメイン無制限なので、移管後にサブドメ追加も追加料金ゼロです。

ConoHa WING への移管全工程 (3 時間タイムライン)

緊急移管の全工程と所要時間を実測ベースで共有します。

Step 1: ConoHa WING 契約 + ドメイン追加 (30 分)

ConoHa アカウント (VPS と共通) でログイン
「WING」→ プラン選択 (スタンダード推奨、マルチドメイン無制限)
支払い情報入力 → 契約完了 (即時利用可)
「サイト管理」→「ドメイン」→ 既存ドメインを追加 (Netlify で使ってたドメインを入力)
FTP アカウント (`apick01@your-domain.com` 形式) のパスワードを控える
document root のパス (例: `/public_html/your-domain.com`) を確認

所要時間: 30 分 (契約時の本人認証含む)。

Step 2: コンテンツキャッシュを OFF にする (5 分、重要)

ConoHa WING のデフォルト設定では「コンテンツキャッシュ」(Nginx microcache レイヤー) が ON で、URL ベースで 1 時間 HTML をキャッシュします。開発・初期構築中は OFF にしないと「FTPS で新ファイル上げても本番に反映されない」事故が発生 します。

サイト管理 → 該当ドメイン → 「高速化」
「コンテンツキャッシュ」を OFF に変更 → 保存
1-2 分で反映、以降は HTML が毎回上流から取得される

本番運用後は ON に戻して問題ありませんが、移管初期は必ず OFF にしておくことを推奨します (この罠で 30 分溶かした個人開発者のブログを複数見ました)。

Step 3: コンテンツの FTPS アップロード (60-90 分)

Netlify でホストしていた静的ファイル一式を ConoHa WING の document root にアップロードします。

FTPS 対応クライアント (FileZilla / WinSCP / curl のいずれか) を準備
ホスト: `your-domain.com` (or ConoHa が指定するFTPサーバー)、ユーザー: `apick01@your-domain.com`、パスワード: Step 1 で控えたもの
ポート: 21 (FTPS、明示的 TLS)
ローカルの `public/` or `dist/` 配下の全ファイルを `/public_html/your-domain.com/` にアップロード
アップロード完了後、`index.html` が直接 root に配置されていることを確認

所要時間: コンテンツボリュームによる。100-200 HTML + 画像で 60 分前後、500+ ファイルあると 90 分以上かかるケースもあります。FTPS の並列接続数 (4-8) を上げると高速化可能 (ConoHa は最大 8 並列まで対応)。

Step 4: DNS 切替 (5-30 分、ConoHa 経由なら自動)

独自ドメインを Netlify から ConoHa WING に向ける DNS 設定:

ConoHa DNS を使ってる場合: ConoHa WING にドメインを追加した瞬間に A レコードが自動で WING IP に変更 されます (ConoHa の標準仕様)。手動切替不要、5 分前後で伝播完了
外部 DNS (お名前.com / Cloudflare / ムームー等) を使ってる場合: 該当 DNS 管理画面で A レコード値を Netlify の IP (75.2.60.5 等) から ConoHa WING の IP (160.251.x.x) に変更。伝播に 30 分〜数時間

DNS 伝播確認は `nslookup your-domain.com 8.8.8.8` で Google DNS から正しい新 IP が返ることをチェック。

Step 5: SSL 証明書発行 (15 分、DNS 伝播後)

Let's Encrypt 無料 SSL を ConoHa WING の管理画面から発行します。

DNS 伝播確認 (Step 4)
サイト管理 → 該当ドメイン → 「無料独自SSL」
「利用する」を選択 → 「設定」
2-5 分で発行完了、HTTPS で本番アクセス可能

DNS 未伝播の状態で SSL 発行を試行すると失敗します。慌てて「利用する」をクリックする前に、必ず `nslookup` で確認してから実行を推奨。

Step 6: 自動 deploy スクリプトの切替 (30-60 分)

記事追加・更新を継続的に行うなら、Netlify CLI ベースの deploy スクリプトを FTPS ベースに書き換えます。

変更前 (Netlify):

// deployer.mjs (旧)
import { execSync } from 'child_process';
export function deployToNetlify(dist) {
  execSync(`netlify deploy --dir=${dist} --prod`, { stdio: 'inherit' });
}

変更後 (ConoHa WING FTPS):

// deployer.mjs (新)
import { Client } from 'basic-ftp';
export async function deployToWing(dist) {
  const client = new Client();
  await client.access({
    host: 'your-domain.com',
    user: 'apick01@your-domain.com',
    password: process.env.WING_FTP_PASSWORD,
    secure: true,
  });
  await client.uploadFromDir(dist, '/public_html/your-domain.com');
  client.close();
}

注意: ステージング (例: `dist-wing/`) を使う場合、deploy スクリプトの冒頭で `rmSync` 等で全削除 → ソースから再コピーする実装になりやすいです。このステージングディレクトリを直接編集しても、次回 deploy で全削除されて上書きされます。ソースコード側 (例: `src/` or `public/`) を編集するルールを守らないと「変更したのに本番に出ない」事故が起きます。

Step 7: 動作確認 + ロールバック準備 (15 分)

本番 URL を別ブラウザ・別ネットワークから確認 (キャッシュなしで)
主要ページ (HOME / カテゴリ / 個別記事) の表示確認
HTTPS が正しく動作していることを確認
形式チェックツール (Schema.org Validator 等) で構造化データ正常出力
Search Console で「URL 検査」→ 新サーバーで正しくクロールされるか確認

ロールバック手順 (もし WING で問題発生時): DNS A レコードを Netlify の IP (75.2.60.5 等) に戻す → 5-10 分で復旧 → Netlify Free tier リセットを待つ。事前にロールバック手順を文書化しておけば、緊急時のパニック回避できます。

移管で踏みやすい落とし穴 3 つ

実体験で「これは要注意」と感じたポイント:

1. コンテンツキャッシュ OFF を忘れる — Step 2 で書いた通り、ConoHa WING のデフォルトでは microcache が ON。「FTPS で上げたのに本番反映されない」事故の最大原因。新規契約時の最初のチェックリストに必ず入れる。

2. ステージングディレクトリ直接編集事故 — deploy スクリプトでステージング (例: `dist-wing/`) を rmSync するロジックの場合、ステージングを直接編集すると次回 deploy で全部消える。ソースコード側のみ編集するルールを守る (これで本番未反映事故が 2 度発生した記録あり)。

3. SSL 発行を DNS 伝播前に試行 — ConoHa の SSL 発行は DNS 確認を内部で行うため、伝播未完了だと「証明書発行失敗」となる。`nslookup ... 8.8.8.8` で確認してから「利用する」をクリック。

移管後の運用ルール (継続的な自動更新を維持する)

移管後に自動 deploy パイプラインを継続的に動かすための運用ルール:

FTPS パスワードを `.env` で管理 — Git にコミットしない、`.gitignore` で除外
deploy 成功後に本番 URL の HTTP 200 確認 — curl ベースの簡易チェックを deploy スクリプトに組み込む
Discord webhook で成功・失敗両方通知 — 「沈黙 = 異常」が判定できる状態にする
定期バックアップ — WING の自動バックアップ (有料オプション) or 自分で Google Drive 等に転送
ステージングディレクトリの注意書きを README に明記 — 別の開発者・将来の自分が直接編集事故を起こさないように

Netlify を使い続けるべきケース vs WING に乗り換えるべきケース

本記事は移管推奨の体裁ですが、フェアに「Netlify 継続が筋」のケースも整理します。

Netlify (有料プラン or Free tier) が向くケース:

Git push → 自動 deploy のワークフローを変えたくない (CI/CD 統合のメリット)
Edge Functions / Forms / Identity 等の Jamstack 機能を使ってる
月間 build 分数が 300 分以内で収まる小規模サイト
月 $19 (Pro プラン) を許容できる予算

ConoHa WING に乗り換えるべきケース:

無料枠枯渇が複数回発生してる (構造的に Free tier では収まらない)
マルチドメインを 3-10 個並走運用したい (WING マルチドメイン無制限)
FTPS デプロイで十分 (Jamstack 機能を使ってない)
VPS と組み合わせて統合管理したい (同じ ConoHa アカウント)

3 時間の移管コストを払うべきか、Netlify Pro 月 $19 を払い続けるか、これは個人開発者の運用方針次第。私のケースは「複数メディア + VPS の統合管理」を重視して移管しましたが、「Netlify Pro でいい」と判断するのも合理的です。

結論 — 緊急移管が必要になる前に判断基準を整備しておく

個人開発でメディアサイトを Free tier ホスティングに置く場合、月間ビルド分数の枯渇は構造的にいつか発生する 前提で運用設計するのが現実的です。本記事の 3 時間移管手順を事前に把握しておけば、いざ枯渇した時に慌てずに対応できます。

ConoHa WING 公式の契約は ConoHa WING 公式から、スタンダード月¥1,400 でマルチドメイン無制限。ConoHa VPS との一元管理を目指す個人開発者には特に推奨です。

ConoHa WING 4 サイト並行運用の実コスト集計は月¥1,400 で 4 サイト記事、microcache 罠の対処はmicrocache 解決策記事、VPS との使い分けは使い分け判断軸記事を参照ください。

筆者: GRAMSHIFT — Instagram 自動運用 SaaS『GramShift』開発者、saas-diary.com / ai-pick.tech / lab.ai-pick.tech 等複数メディア運営。Netlify Free tier 枯渇で個人運営メディアサイトの deploy が詰まった経験から、ConoHa WING への緊急移管手順を実体験で整理。本記事は実際に 3 時間で完了した移管プロセスを再現可能な形で公開したものです。

📚 サーバー移行関連書籍 (楽天市場)

※ アフィリエイトプログラム参加中 (ステマ法対応 [PR] 表記)

よくある質問

Netlify Free tier の月間ビルド枠 300 分は、メディアサイトで実際どれくらい持ちますか?

1 回のビルドが 30-60 秒だとして、毎日 10 回 deploy すれば月 150-300 分でギリギリ。記事更新頻度の高いメディアサイト (静的サイトジェネレータ + index 構築あり) では、月 100 回の deploy で 300 分超過するケースもあります。深夜の自動 deploy で気づかないうちに枯渇しているパターンが多いので、月初に当月の予想枯渇日を試算しておくのが推奨です。

ConoHa WING への移管、どれくらいの時間がかかりますか?

実体験で 3 時間でした。内訳: 契約 + ドメイン追加 30 分、コンテンツキャッシュ OFF 5 分、FTPS アップロード 60-90 分 (コンテンツ量による)、DNS 切替 5-30 分 (ConoHa DNS なら自動)、SSL 発行 15 分、自動 deploy スクリプト書き換え 30-60 分、動作確認 15 分。FTPS アップロードがコンテンツ量で延びる部分以外は予測可能な時間で進みます。

DNS 切替時の本番ダウンタイムはどれくらいですか?

ConoHa DNS を使ってる場合、ドメイン追加と同時に A レコードが自動で WING IP に切り替わるため、ダウンタイムはほぼゼロ (5 分前後で伝播完了)。外部 DNS (お名前.com / Cloudflare 等) を使ってる場合は、A レコード変更後の伝播に 30 分〜数時間。緊急移管なら、事前に新サーバーへのコンテンツアップロードを完了してから DNS 切替するのがダウンタイム最小化のコツです。

ロールバック (Netlify に戻す) はできますか?

可能です。手順は (1) DNS A レコードを Netlify の IP (75.2.60.5 等) に戻す → 5-10 分で復旧、(2) deploy スクリプトの import 文を deployToWing → deployToNetlify に 1 行差し戻し、(3) Netlify Free tier リセットを待つ (毎月 1 日)。事前にロールバック手順を文書化しておけば、緊急時のパニック回避ができます。