この記事の結論
小さな会社の管理画面は、自前のサーバーを持たずに作れます。画面は前もって作った静的なファイルとして配り、ログインやデータの読み書きといった処理は、クラウドの関数に必要なときだけ動いてもらいます。データは、クラウドの管理されたデータベースに置きます。サーバーの保守やOSの更新から解放され、使った分だけの費用で済みやすいのが利点です。そのかわり、ログインの回数制限や、見られる範囲の分け方など、守りは最初から作り込んでおく必要があります。
自前のサーバーは、持つだけで手間がかかる
予約や問い合わせ、在庫を確かめる管理画面を作るとき、以前は自前のサーバーを1台用意して、そこで画面もデータも動かすのが一般的でした。
この形は、作った後の手間が大きくなります。
- OSやソフトの更新を、定期的に続ける必要がある
- 急にアクセスが増えたときに、サーバーが耐えられるかを気にする必要がある
- サーバーが止まったら、管理画面もすべて止まる
- 使っていない夜間も、サーバーの費用がかかり続ける
社内にサーバーを見られる人がいない小さな会社ほど、この手間は重くのしかかります。
サーバーを持たない構成
今は、自前のサーバーを持たずに管理画面を作れます。役割を3つに分けて、それぞれをクラウドの仕組みに任せる形です。
| 役割 | 任せる先 | 中身 |
|---|---|---|
| 画面 | 静的なファイルの配信 | 前もって作った画面のファイルを、世界中の配信の仕組みから届ける |
| 処理 | クラウドの関数（サーバーレス関数） | ログイン、データの読み書きなど。呼ばれたときだけ動く |
| データ | 管理されたデータベース | 予約、問い合わせ、設定など。バックアップや更新はクラウド側が担う |
私たちの自社プロダクト（予約管理システム）の管理画面も、この形で作っています。画面は静的なファイルとして配り、ログインやデータの読み書きはクラウドの関数で処理し、データは管理されたデータベースに置いています。
自社サイトの問い合わせフォームも、同じ考え方で動かしている
このサイトの問い合わせフォームも、サーバーを持たない形です。
| 役割 | 私たちの使っているもの | ねらい |
|---|---|---|
| 画面 | Firebase Hosting（静的なファイルの配信） | サーバーの更新や監視をしない |
| 送信の処理 | Cloud Functions（クラウドの関数） | 送信されたときだけ動く |
| 公開の作業 | GitHubのmainに反映すると、自動で公開 | 人の手順を減らし、毎回同じ流れで出す |
| 公開のための認証 | Workload Identity（鍵のファイルを置かない認証） | 漏れると困る鍵を、そもそも持たない |
| 公開の前 | 手元で、表示とフォームの動き・改行を自動で点検 | 壊れたまま公開しない |
GitHubから自動で公開する仕組みはFirebaseの公式の手順にあり（Firebase：GitHubからのデプロイ）、鍵のファイルを使わない認証は、Google Cloudが鍵の管理の負担を減らす方法として説明しています（Google Cloud：Workload Identity連携、どちらも2026-10-02 確認）。管理画面でも、公開の流れと鍵の扱いは、画面や機能と同じくらい先に決めておくところです。
この構成の利点
- サーバーの保守がいらない。 OSの更新や、サーバーの監視から解放されます
- 使った分だけの費用になりやすい。 処理は呼ばれたときだけ動くので、利用の少ない時間の費用が抑えられます
- アクセスの増減に強い。 画面の配信も関数も、クラウド側が自動で広げてくれます
- 画面が速い。 静的なファイルは、利用者に近い場所から届けられます
守りは、最初から作り込む
サーバーを持たない構成でも、守りは自動では手に入りません。管理画面は、お客様の情報を扱う場所です。次の点は、最初から作り込みます。
1. ログインの回数制限
同じアカウントに何度もログインを試される攻撃に備えて、一定の回数を失敗したら、しばらくログインできないようにします。試行の回数は、データベースに記録して数えます。
2. 見られる範囲を分ける
管理者と、各拠点や部署の担当者で、見られるデータの範囲を分けます。「どの画面が見えるか」だけでなく、「どのデータを読み書きできるか」を、データを扱う処理の側で必ず確かめます。画面を隠すだけでは、守りになりません。
3. 秘密の値を、ファイルに書かない
データベースに接続するための鍵や、外部のサービスの合言葉は、プログラムのファイルに書かず、クラウドの環境変数に置きます。プログラムを管理する仕組み（Gitなど）に、秘密の値が入らないようにします。私たちは社内でも、パスワードや鍵はソースコードやチャットに書かず、決まった保管場所にだけ置く決まりにしています。公開の作業のように、鍵のファイルを置かずに済む方法があるところは、そちらを選びます。
4. 扱うデータを、処理の側で固定する
関数が読み書きしてよい表（データの置き場所）を、処理の側で決めておきます。画面から送られてきた指定を、そのまま信じて使わないようにします。
「サーバーがない＝セキュリティは任せられる」わけではありません。配信やデータベースの土台はクラウドが守ってくれますが、誰に何を見せるかは、作る側が決めて作り込むものです。
向いている場合、向いていない場合
| 向いている | 向いていない |
|---|---|
| 予約、問い合わせ、在庫、顧客の一覧など、社内で使う管理画面 | 長時間かかる重い計算を、常に動かし続ける処理 |
| 利用する人数や時間に波がある | 特殊な機器や、社内のネットワークにつながる必要がある |
| 社内にサーバーを見られる人がいない | 決まったサーバーの上でしか動かないソフトを使う |
どちらになるかは、業務の中身で決まります（業務システムの考え方はSaaSか、オーダーメイドかや、Excelでの業務管理が限界になったときの、7つのサインにまとめています）。
よくある質問
自前のサーバーより、安くなりますか？
クラウドのサービスが止まったら、使えなくなりませんか？
今の自前のサーバーの管理画面を、この構成に移せますか？
持たないことで、守ることに集中できる
サーバーを持たない構成は、保守の手間を減らし、その分の時間と注意を、データの守りと、使いやすさに向けられる形です。小さな会社の管理画面こそ、この形が合う場面は多くあります。
まずは、今使っている管理の仕組みで、サーバーの保守に誰がどれだけ時間を使っているかを書き出してみてください。
ご相談
サーバーやクラウドの運用について、いまの状況をお聞かせください。
「何から手をつければいいか分からない」という段階からで構いません。返信は担当者が直接お送りします。
