共有のレンタルサーバーに業務の仕組みを載せるなら、作る前に、サーバーの公式の機能の一覧を開きます。使えるデータベースの種類、常に動き続けるプログラムを置けるか、定期の処理を何分ごとに動かせるか、公開するフォルダを選べるか、SSH で入れるか、自動のバックアップが何日分か。どれも、設計の前提を変えるものです。
当社は 2026 年 4 月 16 日に、PostgreSQL というデータベースを前提に進みかけた設計を止め、MySQL を前提に書き直しました。機能の一覧を最初に開いていれば、書き直さずに済んだことです。
2026 年 4 月 16 日、設計の途中でデータベースを MySQL に変えました
当社の製品を紹介するサイトを、AI と一緒に設計していたときのことです。設計の文書は、データベースに PostgreSQL を使う前提で書かれていました。置き先は、当社が普段から使っている共有の レンタルサーバー です。
ところが、そのサーバーの共有プランで使えるデータベースは、MySQL と MariaDB だけでした。PostgreSQL は、機能の一覧のどこにもありません。私はその日のうちに設計を止め、MySQL を第 1 の候補にして書き直すよう指示しました。
MySQL と MariaDB は、どちらもよく使われるデータベースです。PostgreSQL と同じように表を扱えますが、データの型や書き方に違いがあります。PostgreSQL にしかない型を前提にした設計は、そのまま MySQL には載りません。気づくのが、プログラムを書き終えた後だったら、手戻りはもっと大きくなっていました。
このとき決めたことは、1 つです。サーバーを使う設計では、データベースを選ぶ前に、サーバーの公式の機能の一覧を開いて確かめる。今もこの順番で進めています。
共有のレンタルサーバーで、できることとできないことを先に表にします
共有のレンタルサーバーは、1 台のサーバーを多くの契約者で分け合う仕組みです。そのぶん安く、管理もサーバー会社が受け持ちますが、入れられるソフトや動かし方には決まりがあります。当社が使ってきた共有プランを例に、作る前に確かめる項目を並べます。
| 確かめること | 当社が使ってきた共有プランの場合 | 設計への影響 |
|---|---|---|
| データベースの種類と版 | MySQL・MariaDB と SQLite。PostgreSQL は機能の一覧に無い | 使えないデータベースを前提にした設計は、書き直しになる |
| 常に動き続けるプログラム | 置けない | 届いたメールの処理や、送信の順番待ちは、定期の処理で起こして片付ける |
| 定期の処理（cron） | 使える | いちばん短い間隔で 1 分ごと。「すぐに送る」処理も、最大で 1 分ほど待つことがある |
| 公開するフォルダ | ドメインごとに決まった場所で、別の場所に変えられない | 仕組みの本体は公開しない場所に置き、入口のファイルだけを公開の場所に置く |
| SSH | 使える | コマンドで配置と確認ができる。使えないサーバーでは、FTP でのファイルのやり取りしかできない |
| 自動のバックアップ | Web とメールとデータベースの、それぞれ過去 14 日分 | 14 日より前には戻せない。作業の前には自分でも取る |
データベースの種類、cron、SSH、自動のバックアップは、サーバー会社の機能の一覧に書いてあることです。常に動き続けるプログラムを置けないことと、公開するフォルダを変えられないことは、当社が配置の作業をしてきた中で確かめたことです。
常に動き続けるプログラムを置けないので、定期の処理を 1 分ごとに起こします
業務の仕組みには、画面の操作とは別に、裏で動く処理があります。フォームが届いたら確認のメールを送る。夜のうちに集計する。決まった日にお知らせを送る。こうした処理は、専用のサーバーなら、常に動いて待ち構えているプログラムに任せます。
共有のレンタルサーバーでは、そうしたプログラムを置けません。代わりに、cron で 1 分ごとに処理を起こし、たまっている仕事を片付けて終わる形にします。動きとしては足りますが、「送信ボタンを押した瞬間にメールが届く」ことは約束できません。最大で 1 分ほどの待ちが出ます。この待ちが困る仕組みなら、別の種類のサーバーを選びます。
- 画面の操作フォームの送信などで、送るメールや集計の仕事を「順番待ち」に入れる
- cron が起こす1 分ごとに、決めた処理を起こす
- 片付ける順番待ちの仕事を取り出して、メールを送る・集計する
- 終わる仕事が無くなったら止まり、次の 1 分を待つ
常に動き続けるプログラムを置けないサーバーでの組み方
公開するフォルダを変えられないときは、仕組みの本体を公開の外に置きます
共有のレンタルサーバーでは、ドメインごとに、インターネットに公開するフォルダが決まっています。業務の仕組みの中には、データベースのパスワードを書いた設定のファイルがあります。仕組みをまるごと公開のフォルダに置くと、この設定のファイルまで、外から読まれるおそれが出ます。
当社は、仕組みの本体を公開しない場所に置き、公開のフォルダには入口のファイルだけを置いています。設定のファイルは、サーバーの持ち主のアカウントしか読めない権限にします。作る会社に任せる場合も、パスワードの入ったファイルがどこに置かれるかは、最初に聞いておく価値があります。
自動のバックアップは 14 日分で、作業の前には自分でも取ります
サーバー会社の自動のバックアップは、心強い仕組みです。ただ、当社が使ってきた共有プランでは、過去 14 日分です。壊れてから 15 日たって気づいたら、もう戻せません。
プログラムを入れ替えたり、データベースの形を変えたりする前には、データベースを自分で書き出し、サーバーとは別の場所に残します。戻す先が手元にあれば、作業でつまずいても、その時点まで戻れます。バックアップ は、置き場所を元のデータと分けて初めて役に立ちます。
サーバーを選ぶ前に、作る会社と一緒に確かめる 6 つのこと
- 使えるデータベースの種類と版が、作る仕組みの前提と合っているか
- 裏で動く処理があるか。あるなら何分ごとに動かせば足りるか
- 公開するフォルダを選べるか。選べないなら、パスワードの入ったファイルをどこに置くか
- SSH で入れるか
- PHP の版を選べるか
- 自動のバックアップが何日分か。作業の前に自分で取る手順があるか
この 6 つは、WordPress のサイトでも業務の仕組みでも同じです。WordPress なら、PHP とデータベースの版が、WordPress の公式の推奨の環境に合っているかも見ます。WordPress の本体と PHP の版が古いまま止まっているサイトは、更新に手間がかかります。
サーバーに入る方法も確かめておきます。SSH が使えれば、配置や確認をコマンドで進められ、作業の記録も残しやすくなります。サイトが不正なアクセスを受けたときの調査でも、サーバーの通信の記録を読めるかどうかで、調べられる範囲が変わります。当社の WordPress の被害復旧 でも、最初に読むのはサーバーの通信の記録です。
