サーバーレスのメリットは？
HPの費用・保守・拡張性を解説

サーバーレスとは？会社の担当者は何が楽になる？

サーバーは、ホームページを表示したり、問い合わせを受け付けたりするためのコンピュータです。「サーバーレス」でもサーバーは存在します。利用者が自分で用意・管理する範囲を減らし、クラウド事業者の仕組みで動かします。

Cloud RunはGoogleが管理する基盤上でアプリを動かすサービスです。m-Labは、こうした基盤を使うことで、サーバーを一台ずつ運用するための作業を減らし、入稿のしやすさや業務に必要な機能へ開発の力を向ける選択肢と考えています。

ホームページ運用で考えられる4つのメリット

1. 基盤の管理作業を減らせる

サーバーの手配や台数の管理など、クラウド側へ任せられる範囲が広がります。社内の担当者がすべての技術作業を抱える構成から、制作・保守担当者と役割を分け、更新したい情報や改善したい業務に集中する構成を検討できます。

2. アクセスが増えたときに対応しやすい

Cloud Runの自動スケーリングは、アクセスやCPUの利用状況などに合わせてアプリを動かす数を調整します。広告やお知らせの公開後など、一時的なアクセス増に備える選択肢になります。ただし、データベースや外部サービスにも処理できる上限があるため、サイト全体で設計・確認します。

3. 利用状況に合わせて費用を検討できる

Cloud Runは利用したリソースに応じた課金で、課金方式や設定により費用が変わります。アクセスが少ない時間帯に処理を減らす構成も選べるため、常に大きな処理能力を用意する方法と比較できます。これは「必ず安い」という意味ではなく、実際の使い方に合わせて費用を考えられるメリットです。

4. 新機能を試してから公開する運用を組みやすい

Cloud Runには、新しいバージョンへ流すアクセスの割合を調整したり、前のバージョンへ戻したりする機能があります。たとえば入稿画面の改善を検証してから公開するなど、変更を確かめながら進める運用を検討できます。

公開後にフォームの不具合が見つかった場面を考えてみましょう。アプリを前の状態へ戻せても、公開後に受け付けた問い合わせや更新した記事は別のデータです。サイト全体を過去へ戻すと、残すべき新しい情報まで失うおそれがあります。

Googleの公式資料でも、Cloud Runで前のバージョンへアクセスを戻す際、接続先などの動作を自動で再確認するわけではないと説明しています。操作できることと、戻した後に業務が動くことは分けて確かめます。

• 公開前：戻せるアプリのバージョンと、現在のデータ・接続先で動く条件を確認する。
• データを変える場合：変更前のバックアップと、公開後に増えた記事・問い合わせを残す方法を決める。
• 不具合時：誰が公開継続・差し戻し・個別修正を判断するか、対応中の入稿や受付をどう扱うかを決める。
• 対応後：表示だけでなく、入稿・ログイン・フォームの送信と受信、外部連携も確認する。

データベースのバックアップ・復元は、Cloud Runのバージョン切り替えとは別の仕組みです。復旧時間やデータ保持を一律に保証するものではなく、保存先ごとの手順と確認担当を準備します。

データのバックアップ・復旧・引き継ぎを確認する →

React・Python・Google Cloudでの構成例

技術の名前は、それぞれの役割で考えるとわかりやすくなります。

• React：お客様が見るページや、担当者が使う入稿画面をつくる。
• Python：記事データの処理、予約・顧客管理などとの連携を担う。
• Google CloudのCloud Run：つくったアプリを動かす基盤として利用する。
• データベースや画像の保存先：記事や写真を継続して保存するため、別に設計する。

これは構成例です。事例を社内で更新したいなら入力項目と公開の流れを、予約と連携したいなら連携先の条件を確認し、必要な範囲を決めます。すべてのサイトに同じ構成を当てはめるものではありません。

ご希望に合わせたCMS（入稿機能）と連携の考え方 →

費用・表示速度・安全性で知っておきたいこと

クラウド全体の料金と、保守費用を分けて確認

アプリを動かす費用に加え、データベース、画像・資料の保存、通信なども確認します。Cloud Runの無料枠だけを見てサイト全体が無料と判断せず、利用量と設定に基づいて見積もります。制作費・クラウド利用料・公開後の保守や内容改善は、分けて確認しましょう。

予算通知を入れれば、料金の増えすぎを防げる？

Google Cloudには予算と通知の仕組みがあります。ただし、公式資料は「通知のみ」の予算では、金額に達しても利用や請求が自動的には止まらないと説明しています。通知を設定するだけでなく、誰が受け取り、いつ確認し、何を調整するかまで決めます。

支出上限を適用する仕組みも案内されていますが、使えるサービスや条件を確認する必要があります。「通知だけ」なのか「対象サービスを制限する設定」なのかを区別し、サイト全体の料金が一律に止まる前提にしません。

Cloud Runの最大インスタンス数は、アプリを動かす数を調整する設定です。月額の請求額を固定する設定ではなく、データベースや保存・通信などの料金も別に確認します。また数を小さくしすぎると、アクセス増の際に処理が追いつかなくなる場合があるため、費用と表示・問い合わせ受付への影響を一緒に検討します。

• 見積もりの対象：アプリだけか、データベース・画像保存・通信なども含むか。
• 確認する人：予算通知の宛先と、不在時に対応する人を決める。
• 通知後の対応：増えた費用の原因を確認し、設定変更や追加対応を誰が判断するか。
• 利用を制限する場合：公開ページやフォームが使えなくなる可能性と、復旧の担当・手順を確認する。

m-Labでは、利用量の想定と、費用を見直すタイミングを制作前に整理します。定額の保守契約と、変動するクラウド利用料を分けて確認すると、公開後の予算を考えやすくなります。

使っていない状態からの起動には時間がかかる場合も

アプリの稼働数をゼロまで減らした場合、次のアクセス時に起動するため、最初の応答に時間がかかる場合があります。必要な応答速度によっては、あらかじめ一定数を動かす設定などを検討します。速度と費用の両方で判断します。

アプリやデータを守る仕事は残る

認証・権限、ソフトウェアの更新、不具合対応、バックアップ、監視と復旧は引き続き必要です。「誰が何を管理するか」を明確にします。サーバーレスに変えることと、サイトを安全に運用することは、まとめて設計する必要があります。

バックアップ・復旧・引き継ぎで確認すること →

今のレンタルサーバーから移した方がよい？

現在のレンタルサーバーで必要な機能と運用を満たしているなら、継続する選択もあります。既存のWordPressを改善すれば解決するのか、入稿機能や外部連携をつくり直す方が合うのかを比較します。

CMSは「何をどう更新するか」、サーバーレスは「アプリをどう動かすか」に関わる選択です。サーバーレスは独自CMSだけの技術ではなく、WordPressを使っていることだけで移行の要否は決まりません。移行する場合は、記事・画像・独自機能・URLと保守体制も確認します。

WordPressからの移行前に確認したい内容 →

相談前に整理しておくとよいこと

• 更新したい情報：お知らせ・事例・採用情報など、誰がどの頻度で入稿するか。
• アクセスの特徴：普段と広告・イベント時で増減があるか。現在困っている遅さや停止があるか。
• 必要な機能：予約・会員・顧客管理など、何と連携したいか。
• 継続できる費用：利用料と保守費用をどこまで想定するか。誰が利用状況を確認するか。
• 変更・復旧の担当：公開前の確認、障害時の対応、データとソースコードの引き継ぎを誰が行うか。

わからない項目は未確認のままで構いません。現在の困りごとから、必要な仕組みを整理することが出発点です。

サーバーレスのよくある質問