コンサートサロンのウェブサイトを長年運営してきた中で、ある日突然「予約システムが正常に動かない」という事態に直面しました。原因を辿っていくと、それはWordPressのバージョンアップという、本来は喜ばしいはずの出来事が引き金でした。この記事では、その問題を解決するために独立した予約システムをゼロから開発するに至った経緯と、実装の内容をご紹介します。
きっかけは「PHPのバージョンアップ」だった
横浜ノアスコンサートサロンのウェブサイトはWordPressで構築・運営されています。長年にわたり大きなトラブルもなく安定稼働していましたが、あるときWordPressの最新バージョンへのアップデートが必要になりました。
最新版のWordPressを動かすには、サーバー側のPHPも対応バージョンに引き上げる必要がありました。さくらインターネットの共用サーバーではサーバー全体のPHPバージョンを変えること自体は簡単にできます。しかし、いきなり全体を切り替えてしまうとサーバー上の他のサイトやファイルに影響が出る可能性があります。そこで、まずWordPressのディレクトリだけPHPバージョンを上げて動作確認をする、という慎重な進め方を選びました。
ディレクトリ単位でPHPのバージョンを切り替えるには「CGIモード」を使います。この方法でWordPressのディレクトリをPHP 8.3に切り替え、動作確認を行いました。
技術的な背景
さくらインターネットの共用サーバーでは、ディレクトリ単位のPHPバージョン切り替えにCGIモードを使います。具体的には php.cgi ファイル（パーミッション705）と .htaccess での Action/AddHandler 設定が必要です。この方法で、サイト全体に影響を与えることなくWordPressディレクトリだけPHP 8.3へ移行しました。
PHPのバージョンアップとWordPressの最新版へのアップデートは無事に完了。同時に、セキュリティ強化の一環として各種プラグインのアップデートも実施しました。ここまでは順調でした。
問題発覚——予約システムが動かない
ところが、WordPressとプラグインのアップデートを終えた後、それまで正常に機能していた予約システムプラグインに異変が生じました。画面表示が崩れたり、予約フォームから送信できなかったり、管理画面での予約管理が正しく行えなかったりと、複数の不具合が一度に現れたのです。
アップデート前
予約システムプラグインは正常動作。お客様からの予約受付・管理がスムーズに行えていた。
PHPバージョンアップ → WordPress最新化
サーバー環境の更新が必要だったため段階的に対応。プロセス自体は完了。
プラグインアップデート後
予約システムプラグインが正常動作しなくなる。フォーム表示崩れ・送信エラー・管理画面の不具合が多数発生。
原因の把握
プラグイン間の競合、またはWordPress本体・PHPバージョンとの非互換性が原因と判明。プラグインの修正版リリースを待つか、代替手段を講じる必要が生じた。
プラグインの修正版がリリースされるのを待つ、という選択肢もありましたが、「いつ修正されるかわからない」状態でコンサートサロンの予約受付が止まるのは現実的ではありません。
プラグインに依存している限り、同じ問題がまたいつか起きる。ならばWordPressの外に、自分たちでコントロールできる予約システムを作ろう。
「独立したシステム」という選択
問題を根本から解決するには、WordPressのプラグインエコシステムに依存しない予約システムが必要でした。既存のSaaS型予約サービスを導入する案も検討しましたが、サロン固有の予約フロー・料金体系・メール通知の要件に対して柔軟に対応できるか不透明な部分が多く、最終的に「自社開発」という決断に至りました。
開発の概要と技術スタック
新しい予約システムは、WordPressとは完全に別のディレクトリに構築しました。WordPressのテーマや管理画面とは独立した、純粋なウェブアプリケーションです。技術構成は以下の通りです。
- フロントエンド：HTML / CSS / jQuery
- バックエンド：PHP 8.3
- データベース：MySQL（phpMyAdminで管理）
- 決済：未定
- サーバー：さくらインターネット（共用サーバー）
イベント別予約フォーム
コンサートごとに設定された定員・料金・日程に対応した予約フォームを動的に生成します。同じフォームの仕組みを使いながら、イベントによって内容を柔軟に変えられるように設計しました。
オンライン決済
決済プラットフォームは選定中。
「メールで決済リンクを送ってお客様に支払っていただく」という運用フローに対応している決済サービスを実装する必要があります。決済プラットフォームは機能一覧だけでなく、実際の運用フローとの適合性で選ぶことが大切だと考えています。。
自動メール通知
予約完了時にお客様と管理者へ確認メールを自動送信します。メールの内容はイベント情報に応じて動的に変化するように実装しており、手作業によるメール送信の手間をなくしました。
予約管理画面
イベント別・日付別の予約一覧・定員状況・キャンセル処理を管理者が一元管理できるダッシュボードを用意しました。スタッフが直感的に操作できるUIを意識して設計しています。
スマートフォン対応
ハンバーガーメニューを含むレスポンシブレイアウトを実装。スマートフォンからの予約がストレスなく行えるよう、SP表示のUIも丁寧に仕上げました。
開発を通じて得られた知見
数字のみのスラッグはWordPressが誤解する
イベント投稿のスラッグに数字だけを使用していたところ（例：1415）、WordPressがその数字を「年」として解釈し、日付アーカイブと混同するという問題が発生しました。utagoe-baton-2026 のように英数字とハイフンを組み合わせたスラッグを使うことが重要だとわかりました。
「たった1文字」の欠落が引き起こす連鎖
パンくずリストのHTMLタグで > が一か所抜けていたことで、ブラウザがその後のHTMLを属性値として読み込んでしまい、4つの表示崩れが同時に発生するという事態がありました。「1文字の欠落が複数の別々に見える問題を引き起こす」という現象は、HTMLの仕組みを改めて理解する良い機会になりました。
CSSの診断はライブの値を見る
CSSの問題を診断する際、ソースファイルを眺めるだけでなく、ブラウザの開発者ツールで実際に適用されているスタイルを確認する方法が有効でした。ソースと実際の適用値は異なる場合があります。
ライブデバッグの重要性
CSSの問題を診断する際、ブラウザの開発者ツールで window.getComputedStyle() を使って実際に適用されているスタイルを確認する方法が有効でした。ソースと実際の適用値は異なる場合があり、特にキャッシュが絡む場面では「ライブの値を見る」ことが確実な診断につながります。
WordPressのセキュリティ強化も同時に実施
予約システムの開発と並行して、WordPressサイト本体のセキュリティも見直しました。よくある脆弱性への対策を講じることで、サイト全体の堅牢性を高めています。
REST API経由の管理者ユーザー名漏洩を防止
WordPressのREST APIを通じて管理者のユーザー名が外部から取得できてしまう問題を、関数の追記で無効化しました。
XML-RPC を無効化
不要なXML-RPCエンドポイントを無効化し、ブルートフォース攻撃の入り口を塞ぎました。
WordPressバージョン情報の非表示
HTMLのメタタグから「このサイトがWordPressの何バージョンを使っているか」がわからないよう、generator情報を削除しました。
ログイン保護プラグインの導入
「Limit Login Attempts Reloaded」を導入し、一定回数ログインに失敗したIPアドレスを一時的にブロックする仕組みを追加しました。
成果と今後の展望
100%
WordPress更新の
影響をゼロに
独自
サロン固有の
予約フローを実現
安定
プラグイン依存からの
完全な脱却
独立した予約システムを構築したことで、WordPressのアップデートやプラグインの更新が予約機能に影響を与えることがなくなりました。管理者側の操作性も向上し、日々の予約管理がよりスムーズになっています。
今後はオンライン決済との連携をより深め、予約から決済・入場管理までの一連のフローをシステム上で完結できるよう、機能を拡張していく予定です。また、スタッフが直感的に操作できる管理画面のUI改善も継続的に行っていきます。
今回の経験を通じて実感したのは、「便利なプラグインも、長期運用の観点では依存リスクになりうる」ということです。特に、予約・決済・顧客管理のような業務の中核を担う機能は、自分たちでコードをコントロールできる形で持つことに大きな安心感があります。同じような状況でお困りの方の参考になれば幸いです。