Web制作の現場において、避けては通れないのが「老朽化したサーバーからの脱却」です。 先日、計10サイト（うち9サイトがWordPress）のサーバー移転と、それに伴う一斉アップデートを担当しました。

元々の環境は「PHP 5.x」「WordPress 4.x」というレガシーな構成。旧サーバーのアップデートが止まっていることへの不安や、バラバラだった管理の一元化が今回のミッションでした。

単なる「引っ越し」では済まない、技術的負債と向き合う現場でどのような選択をしたのか。その事例をご紹介します。

1. 「作り直し」ではないからこその、コードの取捨選択

今回の案件は、サイトを新しく作り直すリプレイスではありません。限られた予算とスケジュールの中で、「新しい環境でいかに安定して動かすか」がゴールです。

ここで重要になるのが、完璧を追い求めすぎないことでした。

• 古い関数の置換とプラグインの精査：最新のPHP環境では動かない古い関数を書き換え、開発が止まったプラグインは「代替プラグイン」へリプレイスするか、あるいは「最小限の改変」で動かすか。

• 表示と動作の維持：リプレイスなら新しく作るだけですが、既存の挙動を維持しながら環境だけを変える作業は、実はより細やかな調整を要します。

どこまでを修正範囲とするか。ディレクター様と予算を相談しながら、事象毎に対応策・改修案を検討・決定していきました。

「動かないから作り直しましょう」と突き放すのではなく、現状の資産を活かしながら着地させる。それが「調整力」の使い所だと考えています。

「どこまで直すか」の線引きと追加費用の考え方

移転作業を進めると、コードを開けてみて初めてわかる根深い不具合が見つかることもあります。その際、独断で進めたり、後から一方的に追加費用を請求したりはしません。

• 基本範囲：新サーバーで「現状の表示・動作」が再現できるまでの修復。

• 追加検討：大規模な仕様変更が必要な場合。例えば、「代替となるプラグインが存在せず、既存プラグインを大幅に改修する必要がある」「廃止するにしてもテーマ側の大規模な修正が不可欠」といったケースです。

想定以上の事象が発生するたびに、「この修正にはこれだけの工数がかかる」「今回はプラグインの改変で最小限に抑えるか、あるいは今後のために新調するか」をディレクター様と相談し、予算内で納得感のある着地点を検討・決定していきました。

2. 業務を止めない、一歩先を行く「メール移転」の工夫

Webサイトの表示以上に、クライアントの業務に直結するのがメールの問題です。10サイト分ともなると、その影響範囲は小さくありません。

今回は、切り替え時の混乱を最小限に抑えるため、以下のフローを徹底しました。

• 事前設定によるスムーズな移行：あらかじめ新サーバー側にアカウントを作成。さらに、メーラーには先回りしておいていただきました。これにより、切り替え後の「設定がわからない」というトラブルを回避しています。

• 予期せぬ外部ブロックへの迅速な対応：サーバー移転後、Hotmail（Outlook系）等の外部サービス側でメールがブロックされていました。これは事前に察知しきれない「地雷」の一つですが、発覚後すぐに対象サービスへのホワイトリスト追加依頼を働きかけるなど、トラブルを長引かせないための連携を重視しました。

3. 「丸投げ」から始まる、技術的なパートナーシップ

こうした複雑な移転案件において、制作会社のディレクター様が最も負担に感じるのは「どこに地雷が埋まっているか分からない」という不安ではないでしょうか。

私は、単に作業を請け負うだけでなく、以下のような「安心感」を提供することを大切にしています。

• リスクの事前洗い出し：移転前に環境を調査し、不具合が出そうな箇所をあらかじめ共有します。

• 予算に応じた柔軟な提案：全てを最新に書き換えるのがベストかもしれませんが、予算が合わないこともあります。その際「この方法なら安価に直せる」「ここはしっかり直すべき」といった、現実的な相談をさせていただきます。

検討材料の一つとして、いつでもご相談ください

「古い仕様のまま放置されているサイトがあるけれど、触るのが怖い」「サーバーをまとめたいが、メール周りの調整が不安」。

そんな課題があれば、ぜひ一度お声がけください。 押し付けの提案ではなく、プロジェクトの状況に寄り添った答えを一緒に見つけていければ幸いです。

納品後の制約を「改善」に変えた、イベントカレンダーの実装事例

Webサイトは公開して終わりではありません。運用が始まってから新たな制約が判明したり、さらなる使い勝手の向上が求められたりすることも多いものです。

今回は、当初「トップページへのカレンダー表示」と「個別記事の作成」という要件で納品した「FullCalendar」導入事例が、その後の環境変化を経て、いかにパフォーマンスを30％以上向上させるに至ったかをご紹介します。

背景：上位組織の仕組みと、デザインカンプの意図

本案件のスタートは、サイトのトップページにイベントカレンダーを配置し、各イベントの詳細を個別記事で管理するという要件でした。

そこには上位組織が運用しているイベントカレンダーの仕組みを参考にしたいという明確な意図がありました。しかし、実際に扱うデータ構造や記事のボリューム、さらにはサイトのルールが異なるため、そのままコピーすることは現実的ではありません。

そこで、ディレクターと打ち合わせを重ね、「どこまで共通化し、どこから独自設計にするか」の整合性を丁寧に調整しました。

特にこだわったのが、デザインカンプに描かれていた「カレンダー・モーダル・個別記事」による3層の導線設計です。カレンダー上のイベントをクリックした際、即座にページ遷移するのではなく、まずはモーダルで概要を表示。そこから「詳細記事へ」「関連情報へ」といった複数の導線を設けることで、ユーザーがページを移動することなく情報を取捨選択でき、必要に応じて深い階層へ進める自然な回遊を実現しました。

初期実装：スピードと柔軟性を優先したプラグイン活用と、見えてきた課題

当初の構築段階では、イベント情報の管理にカスタムフィールドプラグインを採用しました。

なぜ独自のプログラムを組まずにプラグインを選んだのか。それは、「限られた予算内で、将来的な要件変更に最も簡素かつ迅速に対応できるから」です。

開発初期において、最初からフルスクラッチの独自システムを構築することは、コストを押し上げるだけでなく、仕様変更のたびに追加費用が発生するリスクを孕みます。あえて柔軟性の高い構成をベースに据えることで、進行中の細かな調整や追加要望に対しても、予算の範囲内でロジックを崩さず、最小限のコストで打ち返せる状態を優先しました。

しかし、運用を進める中で、標準的なAJAX方式ゆえの課題も見えてきました。今回の要件ではカレンダーの表示タイプによって複数のJSONを出力する必要があり、データが重なるほどリクエストのオーバーヘッドが無視できなくなっていたのです。

「表示までに一瞬の『間』が空く」という状態は、UX（ユーザー体験）の観点からも改善の余地があると感じていました。

経緯：納品後の制約を「REST API化」による改善へ

無事に納品を完了し、運用が進んでいたある時、大きな状況の変化がありました。

クライアント側のセキュリティ方針が更新され、それまで使用していたカスタムフィールドプラグインは利用不可となったのです。

納品後のこの制約に対応するため、データ構造をプラグインに依存せず、テーマ内で完結する独自実装へと急遽シフトすることになりました。

この際、大きな強みとなったのが、すでに数ヶ月の運用を経て「フィールドの設計自体には問題がないこと」が証明されていた点です。運用実績に裏打ちされた完成度の高い設計をそのままコードへ落とし込むことができたため、移行は非常にスムーズでした。

幸いにもこの改修時には、予算的な余裕がありました。そこで、単なるプラグインの代替に留めるのではなく、前述の「JSON出力の重さ」を抜本的に解消すべく、システムを「WP REST API + FullCalendar」の構成へと刷新する提案を行いました。

成果：数値で現れた「30％以上」の速度改善

REST APIベースへの切り替えにより、カレンダーの挙動は劇的に進化しました。

• パフォーマンスの向上：インサイトデータ上で30％以上の高速化を確認。

• ストレスのない操作感：月を切り替える際の読み込み待ちがほぼ解消され、体感でも明らかに「軽くなった」と分かるレベルに。

制約をきっかけとした改修ではありましたが、予算というリソースを最大限に活かし、結果として「運用の継続性」を確保しつつ、サイト全体のユーザー体験（UX）を底上げすることができました。

制作のポイント

今回のプロジェクトにおいて、制作パートナーとして意識したポイントです。

• ディレクターとの整合性調整：上位組織の仕組みをリサーチした上で、ディレクターと「自サイトにとっての正解」を議論し、仕様を固めた。

• 「複数導線」を持つモーダルの実装：デザインカンプの意図を汲み取り、モーダル内に詳細記事や関連リンクを配置。ユーザーを迷わせない情報の厚みを構築。

• 納品後の変化への柔軟な対応：プラグイン利用不可などの予期せぬ制限に対し、単なる「修正」に留めず、パフォーマンス向上という付加価値を乗せて打ち返した。

• リソースに応じた技術提案：予算の余裕を「将来への投資」と捉え、REST API化によるデータ取得の最適化を提案・実行。

変化に寄り添い、現実的で「モアベター」な落としどころを探る

今回の事例は、最初から完璧な計画があったわけではなく、上位組織との調整や、納品後の制約、運用の変化に合わせて、その都度「モアベター」を選択し続けた結果です。

「既存の仕組みを参考にしたいが、そのままでは難しい」「特殊なUIを指定されているが、実装できるか」といった懸念は多いかと思います。

最初からフルスペックのシステムを組まなくても、まずは要件を満たし、状況に応じて中身をアップデートしていく。そんな柔軟な進め方も、一つの正解だと考えています。アイデア段階の「これ、どう実装するのがいいかな？」というご相談から、ぜひお気軽にお声がけください。

後記：なぜ「ベスト」ではなく「モアベター」なのか

今回の事例を通じて、改めて感じたことがあります。それは、予算や納期、予期せぬ制約が複雑に絡み合うWeb制作の現場において最初から「絶対的なベスト（最善）」を定義するのは、ある種の思考停止になりかねないということです。

開発のスタート時点では、クライアントの運用体制がどこまで固まっているか、将来的にどのような要件の変化があるか、すべてを見通すことはできません。

もし、初期段階で「これが最高の実装だ」と決め打ちして独自のガチガチなシステムを組んでいたら、納品後の「プラグイン利用不可」という急な制約変更に対応できず、多大な改修コストや工期が発生していたかもしれません。

• まずは要件を柔軟に満たせる構成でスタートする

• 運用を経て検証された設計をベースにする

• 変化に合わせて、その時点での最適解へアップデートする

この「その時々の状況におけるモアベター（より良い選択）」を積み重ねていくアプローチこそが、結果として「破綻しないシステム」と「納得感のある着地点」に繋がると考えています。

「完成図が見えきっていないけれど、まずは形にしたい」「運用しながら育てていきたい」といった、現実的な課題に向き合っている制作会社様。ぜひ、その時点での「モアベター」を一緒に探るパートナーとして、お力になれれば幸いです。

1. プロジェクトの背景と要件

今回の診断サイト制作では、以下の条件が求められました。

• 柔軟性： 診断ロジックや質問内容が未確定で、作りながらブラッシュアップしたい。

• 拡張性： 今回の仕組みをベースに、別なドメイン・別のサイトへ水平展開したい。

• 運用性： プログラムがわからなくても、HTMLや管理画面の操作だけで更新を完結させたい。

• 体験： ユーザーの離脱を防ぐため、画面遷移（URL遷移）なしでサクサク動かしたい。

2. 採用した解決策：ヘッドレスWordPress

これらを実現するために、WordPressを「サイトの器」としてではなく、「データの箱（API）」として使用する手法を採用しました。

構成のポイント

• バックエンド（管理画面）： WordPressのカスタム投稿とカスタムフィールドを活用。

• フロントエンド（表示側）： バニラJS（生のJavaScript）によるシングルページ構成。

3. 制作会社様にとっての「3つのメリット」

① 「プログラム不要」で中身をブラッシュアップ

質問文、選択肢、診断結果の数値、イラスト画像……。これらすべてをWordPressの管理画面から編集可能にしました。エンジニアにコード修正を依頼することなく、ディレクターやクライアント様の手で、公開直前まで内容を追い込むことができます。

② 「バニラJS」による高いメンテナンス性

クライアント様がAIを活用した「パイプコーディング」を運用していたことがわかったため、本プロジェクトではあえてバニラJSでの実装を選択しました。

ReactやVue.jsといったモダンなフレームワークは、構文ルールや複雑な依存関係が「パイプコーディング」の障壁となることが想像できます。バニラJSであれば、コンパイルも不要でAIの出したコードを直接反映できるため、クライアントのプロンプトに対応しやすいからです。

③ 「テーマを作らない」ことによるコスト最適化

今回は「ヘッドレス」という名の通り、WordPress側のテーマ制作は行っていません。 既存のテーマをホワイトアウトさせて「データの送受信」に特化させることで、見えない部分の作り込みをカット。その分、デザインの自由度やUIの向上にリソースを割くことが可能になりました。

4. エンジニアの目線：あえて「作り込みすぎない」

今回の設計で大切にしたのは、「エンジニアがいないと何もできない状態」を作らないことです。

• HTMLベースの組み込み： フロントエンド側は、特定のIDを振ったHTMLにJSを読み込ませるだけ。コーダーの方が、通常のサイト制作と同じ感覚でデザインを調整できます。

• 水平展開の容易さ： コア部分はREST APIで共通化されているため、別の診断を作る際も、WordPress側の設定をコピーするだけでスピーディに立ち上げが可能です。

制作ポイント

• フロントエンド： バニラJS（コンパイル不要、URL遷移なし）

• バックエンド： WordPress（REST API活用、カスタムフィールドで柔軟な編集）

• 拡張性： 質問の増減や、別ドメインへの水平展開も容易

• メリット： デザインの完全自由化 ＋ クライアント自身でのコンテンツ更新可能能力

こんな時にご相談ください

「ガチガチのシステム開発」にするほどではないけれど、「既存のプラグインでは自由度が足りない」。そんな案件に、今回のヘッドレスWP構成は非常に相性が良いです。

• 「中身が固まっていないけれど、とりあえず箱だけ作っておきたい」

• 「一つのシステムを使い回して、複数の診断ツールを量産したい」

• 「デザインにはこだわりたいが、運用の手間は最小限にしたい」

技術の押し付けではなく、プロジェクトの規模や予算に合わせた「最適な引き算」をご提案します。もし似たような課題をお持ちでしたら、まずは壁打ち相手としてお気軽にお声がけください。

Webhook を活用した商品情報の自動同期

サイトの新規制作において、「製品一覧ページを作りたい」「記事に関連商品情報を載せたい」というご要望をいただくことは少なくありません。

一見するとシンプルな要件ですが、エンジニアの視点で見ると、その先にある「日々の運用コスト」が大きな課題として浮かんできます。今回は、EC-CUBEとWordPressを連携させ、運用の手間とミスを劇的に減らした事例をご紹介します。

1. 「手動更新」に潜む、運用開始後のリスク

当初の要件は「製品一覧」と「関連商品の表示」のみで、機能面での細かな指定はありませんでした。しかし、そのまま最小構成（手動更新）で進めた場合、以下のようなリスクが予想されました。

• 情報のズレ： EC側で価格改定や在庫切れがあっても、ブランドサイト側の更新を忘れてしまう。

• 作業の二度手間： 同じ情報を2つの管理画面に入力しなければならない。

• ヒューマンエラー： 商品名やURLの打ち間違いが起きやすく、ブランド価値を損なう。

これらは、運用が始まってからクライアントの負担としてじわじわと効いてくる部分です。

2. なぜ「Webhook同期」が最適なのか？（他方式との比較）

連携方法にはいくつか種類がありますが、本プロジェクトでは「軽さ」と「情報の鮮度」を重視し、Webhookを活用した自動同期を採用しました。他の方式と比較すると、そのメリットが明確になります。

Webhookは、EC-CUBE側で商品が「登録・更新・削除」された瞬間だけWordPressに通知を飛ばす仕組みです。無駄な負荷をかけず、常に最新の状態を保つことができます。

3. 実装における「現場目線」のこだわり

単にデータを同期するだけでなく、制作会社やライターの方が「迷わず、安全に」使える工夫を施しました。

• 入力ミスを物理的に防ぐ： WordPress側に同期された商品データは「読み取り専用」に設定。運用者が誤って編集してしまい、EC側の情報と矛盾が生じる事態を防ぎます。

• 記事制作をスムーズに： 投稿画面では、同期済みの商品リストから選択するだけで関連商品を紐付けられるUIを構築。URLをコピペする手間をゼロにしました。

• 他チームとのスムーズな連携： EC側を別会社が担当している場合でも、エラー時の責任分界点（どちらのシステムの問題か）を明確にするログ設計を行い、ディレクター様の進行管理をサポートします。

4. 「やりすぎない」カスタマイズが、将来の柔軟性を生む

最初からフルシステムを組む必要はありません。

「まずは価格と在庫状況だけ同期させておき、将来的にレビューやキャンペーン情報も連携させる」といった、フェーズに合わせた拡張が可能です。ブランドサイトがECに依存しすぎない構造にしているため、将来的な仕様変更にも柔軟に対応できます。

制作パートナーとして、一歩先の「安心」を。

「こうした連携ができるなら、あの案件の提案に盛り込めるかも」

「技術的な話はわからないけれど、運用の手間を減らすアイデアが欲しい」

そんな段階でのご相談も大歓迎です。

ただ作るだけでなく、クライアントが長く、楽に使い続けられるサイトを、一緒に作り上げませんか。

Web制作の現場において、LP（ランディングページ）のフォーム実装は判断が分かれるポイントです。

今回のプロジェクトは「複数の採用LP」の制作。クライアントは外部ASPフォームと契約しておらず、メインのWordPress（以下WP）サイトで既にContact Form 7（以下CF7）が稼働している状況でした。

当初、ディレクターからは「管理が楽なように、既存のフォームをiframeで埋め込めないか」という相談を受けました。しかし、マークアップエンジニアの視点から検証した結果、検討の遡上に載せたのは「LPをPHP化し、WPシステムを直接ロードして埋め込む」手法です。

その技術的背景と、判断基準となる「サーバー環境」の考え方を整理します。

1. 「物理的に同じサーバー」であることの定義

この手法（wp-load.phpを読み込む方法）が採用できるかどうかは、ドメインの見え方ではなく、「ドメインルート（公開ディレクトリ）が同じサーバー内にあるか」という物理的な条件が鍵となります。

◯ 直接埋め込みが検討可能なケース

• 条件： WPがインストールされているディレクトリと、LPのディレクトリが同じサーバーの公開領域（public_html や www など）に含まれている。

• 物理階層のイメージ：

  • public_html/（ドメインルート）

    • index.php（WPのコア）

    • wp-load.php（←これを読み込んでWPの機能を呼び出す）

    • lp/index.php（今回のLPをPHP化して配置）

• 理由： プログラムの実行パスが通っているため、LP側からWPのシステムを内部的に参照できるからです。

× 直接埋め込みが困難なケース

• 条件： URL上は同じドメイン配下に見えても、中身が「別サーバー」や「別契約のインスタンス」にある場合。

• 物理階層のイメージ：

  • サーバーA：WPが稼働

  • サーバーB：LP（静的ファイル）をアップロード

• 理由： 物理的に「家（サーバー）」が違うため、外部からPHPファイルを直接ロードして実行することはセキュリティ上制限されます。

2. もう一つの選択肢「WP REST API」との比較

サーバーが異なる（物理的にファイルを参照できない）場合の手段が WP REST API です。これは「ファイルの中身をロードする」のではなく、「通信（API）」でデータをやり取りします。

ただし、この手法は現場のスキルセットによって工数やリスクが変動する点に注意が必要です。

現場視点での検討ポイント

API連携は、HTML/CSSを主体とするコーディング環境においては「専門外」の領域になりやすく、万が一「メールが届かない」などのトラブルが起きた際、原因がフロントか、バックエンドか、WPの設定かを特定できないリスクがあります。

「直接ロード」であれば、CF7の標準機能をそのまま活用するため、トラブルシューティングの透明性が高く、保守的な観点からも一つの選択肢となり得ます。

3. 実装時にマークアップエンジニアが配慮すべき点

直接ロードを採用する場合、マークアップエンジニアはあらかじめ以下の「WP特有の挙動」をコントロールし、LPとしての品質を整えます。

1. 自動改行（wpautop）の抑制: LP側に、意図しないタグ挿入によるデザイン崩れを防ぎます。

2. 依存アセットの確実な発火: wp_head() 等を通じて、CF7の動作に必要なスクリプトを確実に読み込みます。

3. 送信後の挙動制御: wpcf7mailsent イベントをフックし、送信完了後にサンクスページへ確実にリダイレクトさせることで、広告計測等の計測漏れを防ぎます。

制作ポイント

• フロントエンド：デザインの完全自由化と計測の最適化

• バックエンド：既存資産の「直接ロード」による有効活用

• 保守・運用：リスクを抑えた技術選定

• メリット：低コスト・高パフォーマンスの実装

状況に合わせた「実装の目利き」を

「ASPを契約していない」「でもデザイン品質は落としたくない」といった制約がある中で、どのような実装がプロジェクトにとって最適か。

単に「できる・できない」の二択ではなく、ドメインルートやサーバー環境、そして運用フェーズでの保守性を考慮し、最適な実装形式をディレクターと共に探っていく。そうしたエンジニアの視点を共有することが、プロジェクトをより円滑に進めるための一助になるのではないでしょうか。