固定費を削減しようとするとき、多くの人はまず「安いサービス」を探し始めます。
ただ実際には、すでに契約しているリソースの中に重複が起きていて、そこを整理するだけでコストが下がるケースの方が多いです。
この記事では、n8n用VPSの契約をきっかけにXserverとの二重コストを解消した判断記録から、「新しく探す前に重複を見る」という設計の順番を整理します。
固定費削減の正しい順序は「安いサービスを探す」ではなく「すでに契約しているリソースに重複がないかを確認する」ことです。
新しく契約するたびに、既存の契約を棚卸しする習慣を持てているかどうかで、コスト設計の精度が変わります。
– 新しいツールを契約した直後の方は「H2-1」から
– メール環境やバックアップの整理に悩んでいる方は「H2-3・H2-4」から
n8n用VPSを契約した時点で、固定費の見直しが始まりました
記事自動生成の自動化を進めるために、私はHetzner CX22というVPSを契約しました。当時の契約状況では月額600円ほどのサーバーで、Ubuntu 24.04にDockerでn8nを立ち上げ、bizinets.biz・jogtime.jp・bizinets.lifeの3サイトへの記事投稿を自動化するパイプラインを構築しました。
ただ、この段階でふと気づいたことがあります。
WordPressサイトはまだXserverに残っていました。Xserverは当時、月額1,100円ほどで契約していました。VPSと合わせると、毎月1,700円近くを2つのサーバーに支払っている状態です。
「VPSはn8n用に使っているだけ」と最初は思っていました。でも実際には、少なくとも私の運営規模では、WordPress 6サイトを移しても運用できる余地がHetzner CX22にはありました。2コア・4GBメモリ・40GB SSD。Xserver上のディスク使用量は3GB程度。技術的に移行できない理由がありませんでした。
新しいツールを契約したとき、既存の契約を棚卸しする。この行動を自然にできているかどうかが、固定費設計の分岐点だと思います。
判断基準：新しいサービスを契約した直後 → 「同じ役割を持つ既存契約が残っていないか」を確認する
固定費削減は「安い方に乗り換えること」ではありません
コスト削減と聞くと、「より安いサービスを探して乗り換える」という発想になりがちではないでしょうか。
私も最初はそう考えていました。n8nをセルフホストするためのVPSを探すとき、Oracle Cloudの無料枠を使おうとしました。完全無料で使えるなら、それが一番コストが低いと判断したからです。
ところが実際には、Oracle Cloudの無料インスタンス（VM.Standard.A1.Flex）は空き枠がなく、何度試してもサーバーを作成できませんでした。無料であることを前提に計画を進めていたので、詰まったときのダメージが大きかったです。
そのとき判断したのは「無料に固執するより、安定を買う」という切り替えです。Hetzner CX22は当時の契約状況では月600円ほどですが、安定して使えるサーバーが確保できます。無料枠の空きを待ち続けるという時間コストを考えたとき、有料のほうが合理的でした。
無料ツールをやめる判断基準で書いたように、金額だけでなく「時間コスト」と「機会コスト」を合算して判断することが、コスト設計の本質だと思います。
今回のXserver解約も同じです。「Xserverが高い」から解約したのではありません。「すでにVPSを持っているのに、同じ役割のサーバーを二重に払い続ける必要があるか」を問い直したことが出発点でした。
判断基準：既存契約を見直すとき → 「安さ」ではなく「役割の重複」を先に確認する
WordPressをVPSへ移すだけでは、移行は終わりません
WordPressのファイルとDBをHetznerに移せば解約できると思っていました。でも実際には、移行が終わってもXserverへの依存が残っていることに気づきました。
具体的には3つです。
1つ目はドメインメール。[email protected]などの受信メールがXserverのメールサーバーに設定されていました。Xserverを解約するとメールが届かなくなります。
2つ目はGmailのSMTP設定。Gmailから[email protected]で返信できるように設定していたのですが、経由サーバーがsv745.xserver.jpのままになっていました。これはXserver解約後に送信ができなくなるという意味です。気づかないまま解約していたら、しばらく送信エラーに気づかないところでした。
3つ目はBenchmark Emailの送信ドメイン認証。メルマガをbizinets.bizのドメインから送るためのSPF・DKIM設定が、古いXserverのレコードを参照していた可能性があります。
詰まったら止まる判断設計でも書きましたが、「移行した」という確認だけでは不十分で、「依存先が残っていないか」を別軸で確認することが必要です。
判断基準：サービスを解約する前 → 「そのサービスに依存している設定が他にないか」をリストアップしてから解約する
メール・SMTP・配信認証は「受信」「送信」「配信」の3つが独立した依存先になっています。WordPressのファイル移行だけを確認しても、この3つは別途確認が必要です。
メールはVPSに載せず、Cloudflareで受ける判断をしました
メール環境をどこに移すか、という問いに直面したとき、選択肢はいくつかありました。
VPSにメールサーバーを立てる方法もあります。Postfixなどを使えば技術的には可能です。ただ、メールサーバーの運用は思った以上に複雑です。スパム対策・送信レピュテーション管理・サーバー障害時の対応など、管理コストが継続的にかかります。
今回選んだのはCloudflare Email Routingです。受信メールをGmailに転送する仕組みで、Cloudflare側の案内に沿ってMXレコードや必要なTXTレコードを設定しました。ただし、これはあくまで受信転送の設定です。Benchmark Emailのような配信サービスのSPF・DKIM・DMARC認証は、別途Cloudflare DNSに追加して確認しました。
3ドメイン（bizinets.biz・bizinets.co.jp・jogtime.jp）にinfo@のアドレスを設定し、すべて同じGmailに転送するシンプルな構成にしました。
転送先のGmailアカウントを分けるかどうかも迷いましたが、「切り替えはすぐできる」と判断して一本化しました。完璧な設計よりも、まず動く状態を作ることを優先しました。
一時しのぎより永続設計を選ぶ判断で書いたように、「将来的に変えられる設計」にしておくことで、今の判断を軽くできます。Cloudflare Email Routingの転送先変更は1分でできるので、今は一本化で十分です。
判断基準：自前管理か外部委託かを迷ったとき → 「管理コストと障害リスクがどちらに大きいか」で判断する
送信と配信認証は、受信とは別の依存先として確認しました
受信メールをCloudflareで解決した後、送信側の確認が別途必要でした。
Gmailから[email protected]で返信するための設定は、Gmailの「アカウントとインポート」→「他のメールアドレスを追加」から行っています。経由するSMTPサーバーをXserverのものからGoogleのSMTPサーバー（smtp.gmail.com）に変更しました。
この変更のために、GoogleアカウントでアプリパスワードのしかもGoogleの2段階認証（今回はパスキー）を先に有効にする必要がありました。手順としては：
- Googleアカウントで2段階認証を有効化
- アプリパスワードを発行（16桁）
- Gmailの設定画面でSMTPサーバーをsmtp.gmail.comに変更
配信認証の方は、Benchmark Email（使用しているメール配信サービス）の管理画面でDNSレコードを確認します。bizinets.bizはすでに設定済みでしたが、jogtime.jpは新規でドメインを追加してSPF・DKIM・DMARCをCloudflareのDNSに追加しました。
受信・送信・配信の3つが独立していることを意識できていると、どこが抜けているかを確認しやすくなります。
判断基準：メール設定を確認するとき → 「受信・送信・配信」の3軸を別々にチェックする
バックアップは「全部守る」より「復旧に必要なもの」を守る
Xserver解約後にVPSが止まったらどうなるか、という不安も整理しました。
まず、記事コンテンツについては心配が少ない状況でした。bizinets.bizとjogtime.jpは、n8nの自動化パイプラインで記事を生成するとき、GoogleドライブにJSONファイルとして記事を保存してからWordPressに投稿する設計になっています。記事本文はGoogleドライブにも残っていますが、WordPressとして復旧するにはDB、テーマ設定、メディアファイルなどが必要です。
今回取った対応は、mysqldumpで6サイト分のDBを一括でダンプしてFileZillaでGoogleドライブにダウンロードすることでした。合計46MBほどでした。
bizinets_biz.sql 16MB
jogtime_jp.sql 12MB
karadanonioi_info 9.3MB
bizinets_co_jp 7.6MB
shibukidai_com 1.8MB
4buki_net 333KB
このファイルがあれば、VPSが消えても別のサーバーにインポートしてWordPressの復元に使えます。
VPSが消えるリスクとして最も現実的なのは、Hetznerへの支払い失敗です。クレジットカードの有効期限切れや請求メールの見落としで、サーバーが削除されることがあります。今回この確認も合わせて行いました。
判断基準：バックアップ対象を決めるとき → 「消えても再現できるか」で分類して、再現できないものだけを守る
コストを下げるとは、管理する仕組みを減らすことです
今回の一連の作業を振り返ると、「安いサービスに乗り換える」ではなく「管理する構造を整理する」という作業だったと思っています。
すべてを1か所に集約したわけではありません。むしろ、VPSに載せるもの、Cloudflareに任せるもの、Gmailで送るもの、Benchmark Emailで配信するものを分け直したことで、「何かあったときにどこを確認するか」が明確になりました。
固定費を下げることよりも、管理の複雑さを減らすことの方が長期的には重要だと感じています。費用の削減は結果であって、目的は「構造をシンプルにすること」です。
新しいサービスを契約するたびに、既存の契約を棚卸しする。同じ役割を担うものが重複していれば整理する。この順番を守るだけで、意図せず積み上がる固定費を防ぐことができます。
固定費や契約サービスを整理するときは、いきなり解約するのではなく、まず役割ごとに並べることが大切です。ここまで読んで「自分のサイト運営でも同じような重複がありそうだ」と感じた方は、まず契約しているサービスを一覧にして、役割ごとに整理してみてください。
判断の順番を整理したい方に、無料PDFを用意しています。「何から手をつければいいか」がひと目で分かる構造チェックリストです。
コメント