Webサイトのお助け隊

サーバー会社から「ご利用中のPHPバージョンは提供終了予定です」というお知らせが届いた。その一通から始まる相談が、いちばん多いです。動いているサイトは動いているのに、期限だけが先に決まっている。しかも中身はEC-CUBEだったりCakePHPで組まれた独自システムだったり、CGIで動くMovable Typeだったりして、社内に触れる人がもういない。この状態で判断すべきなのは「どう直すか」ではなく、そもそも直すのか、延命するのか、作り直すのかです。順番を間違えると、動かないバージョンアップに数十万円を払うことになります。

取りうる手は4つしかない

整理すると、選択肢は4つです。1つ目は本体のバージョンを上げる。2つ目は本体には手を付けず、古い環境が動くサーバーへ移して延命する。3つ目は別のCMSやフレームワークへ載せ替える。4つ目はフルスクラッチで作り直す。多くの相談は1つ目を前提に来ますが、実際に1つ目で着地する割合はそれほど高くありません。

理由は単純で、業務システムとして使い込まれたものほど、本体に直接手が入っているからです。EC-CUBEの案件では、独自プラグインと本体への直接改変が積み重なった状態でバージョンアップを試み、テスト環境のほうが復元不能な状態になりました。本番ではなかったので被害は出ませんでしたが、その時点で1つ目の選択肢は消えています。バージョンアップの成否は、本体の新しさではなく、改変の量で決まります。

判断を分けているのは、技術ではなく事業の残り年数

相談を受けたとき、最初に聞くのは「このサイトを何年使う予定ですか」です。技術的な正解と、事業にとっての正解は一致しないことがあります。3年以上使い続けるなら、いま費用をかけて土台を新しくするのが結局は安い。1年以内に閉じる、譲渡する、リニューアルの計画が別にある。この場合は、期限まで安全に動かすことだけを考えたほうが合理的です。

次に見るのが、外部との接続です。決済、配送、会計、予約。外につながっている口が多いほど、載せ替えの費用は跳ね上がります。逆に、コンテンツを出しているだけのサイトなら載せ替えは現実的な選択肢になります。3つ目が、止められる時間です。受注が毎日入るサイトで数日止められるかどうかは、技術ではなく業務の問題です。

EC-CUBEで、延命を選んだ話

PHP 7.3で動いていたEC-CUBE 4.0.2を、7.4へ引き上げたいという急ぎの相談でした。EC-CUBEにはバージョンごとの対応表があり、PHP 7.4に対応するには4.1.0以上、PHP 8.1に対応するには4.2系が必要です。しかも4.1系と4.2系には互換性がありません。つまり「PHPを上げたい」という依頼は、実質的に「EC-CUBE本体を2段階上げたい」という依頼になります。

独自プラグインと直接改変が多かったため、まずテスト環境で試したところ、そのテスト環境自体が戻せない状態になりました。ここで方針を変えています。話を聞くと、1年以内にサイトを手放す計画が既に決まっていました。であれば、恒久対応にお金をかける理由がありません。古いPHPが動くサーバーを用意してそちらへ移し、期限まで安全に動かす形に切り替えています。

移行後に一度、決済が全滅しました。代引きだけが通り、カード決済とキャリア決済が通らない。原因は決済プラグインの設定ファイルで、サーバー固有の絶対パスが直接書かれていたためです。具体的には 3GPSMDK.properties の CA_CERT_FILE と、log4php.properties のログ出力先の2か所。EC-CUBEに決済プラグインが入ったサイトを移すときは、この2ファイルを必ず開くようにしています。もう一つ、キャリア決済は携帯会社ごとに決済代行会社が分かれていることがあり、管理画面も別々です。「キャリア決済だけ通らない」という報告を受けたら、どの携帯会社かを先に確認すると切り分けが早く終わります。

この案件では、旧環境を消さずに別のサブドメインとして並行稼働させたままにしました。切り戻せる状態を保ったまま検証を続けられるので、リスクの高い移行では毎回この形にしています。移行そのものの進め方はサーバー移行の対応内容のほうに整理してあります。

放置していると、選択肢そのものが減る

CGIで動くMovable Typeを2サイト分、サーバー移行と合わせて引き受けた案件があります。バージョンはMT5.2でした。移行の初期調査でファイルを見たところ、見覚えのない index.php が置かれ、/mt/xfile/ というディレクトリの下に next.php があり、別の場所には wso.php がありました。いずれもWebシェルで、フィッシングサイトの踏み台にされていた状態です。

ここで重要なのは、ファイルを消しても終わらなかったことです。index.php を削除したあとに xfile ディレクトリが見つかり、それを消したあとにディレクトリ名を変えた形で再び置かれました。バックドアは複数仕掛けられている前提で動く必要があります。最終的にはサーバー移行、パスワードの全変更、SSHの無効化、そしてMT8への本体バージョンアップまでを一括で実施しています。

ここで誤解されやすい点を書いておきます。新しいサーバーへ移すことは速度の改善であって、セキュリティ対策ではありません。サーバー会社に確認しても同じ回答でした。侵入の入口が古い本体の脆弱性である以上、そこを塞がなければ場所を変えても同じことが起きます。逆に言えば、この段階まで来ると「延命」という選択肢は消えます。放置していた期間そのものが、選べる手を減らしていきます。

なお、バージョンアップ後に「記事の画像が表示されない」という不具合が出ましたが、原因はコードではなくテンプレート側の設定でした。抜粋を140文字で切る設定になっており、その途中に画像のURLがあったため、URLが切れていたのです。同じ構成の2サイトのうち片方だけ症状が出ていたのは、検証用にもう片方だけ300文字にしていたからでした。バージョンアップ直後の不具合は、まず設定値の差分を疑うと早いです。

「昨年は動いていたのに」と言われたら、ソースは見ない

CakePHPで組まれた物件検索サイトで、画像のアップロードだけがエラーになるという相談がありました。前年までは動いていて、コードは誰も触っていない。この時点で、原因はサーバー側にあると考えたほうが早いです。共用のレンタルサーバーでは、事業者側がPHPのバージョンを一斉に引き上げることがあり、共用サーバー案件で最も多い故障の型です。

実際、PHP 8.0の環境で画像処理に使うImagickライブラリが古く、処理が通らない状態でした。厄介なのは、共用サーバーでは拡張ライブラリの更新をサーバー管理者しか行えない点です。ここは「事業者が更新しない限り、利用者側では解決できません」と正直に伝えるしかありません。そのうえで、事業者に打診する、VPSへ移る、PHPを7.4へ下げる、の3案を、実現性と費用とリスクをそろえて提示しました。7.4はすでに非推奨で、告知なく提供終了になる可能性があるため、あくまで暫定です。この一時しのぎを選ぶ場合は、「暫定措置である」と書面に残しておいてください。

細かい点をひとつ。CakePHPを共用サーバーで動かすなら、PHPの実行モードは「モジュール」を選んでください。CGIモードでは必要なライブラリが利用できないことがあります。コントロールパネルの言語バージョン設定から切り替えられます。

作り直すと決めたら、載せ替え先の性格を先に見る

CakePHPで動いていたECサイトの担当者から、WordPressへ移せるかと聞かれたことがあります。答えは「移せます。ただし性格が変わります」でした。WordPressでECを組む場合、実体はWooCommerceに依存します。WooCommerceに特化したテーマを使い、足りない機能はアドオンを探して足していく、というのが定石です。自由に作り込みたい要件があるなら、スクラッチのほうが融通が利くという事実も、隠さず伝えるようにしています。囲い込まずに制約を先に出したほうが、結果として話が早く進みます。

作り直しで最も費用が振れるのは、業務データをどこに持たせるかの設計です。WordPressに載せる場合、カスタム投稿タイプで持つか独自テーブルを切るかで、その後の拡張性も検索性能もまったく変わります。判断の基準はカスタム投稿タイプと独自テーブル、業務データはどちらで持つかに書いています。繰り返し項目をカスタムフィールドで持たせる構成には限界があるので、件数が増える見込みがあるならACFの繰り返しフィールドで業務データを持たせる設計と限界のほうも先に読んでおくと安全です。見積書や請求書の発行だけを切り出したいという要望なら、CMS全体を作り直さずに請求書と見積書をWebで発行する仕組みだけを別に作るほうが安く済みます。

もう一点。既存システムに手を入れる前には、対象ファイルのバックアップを日付付きで残してください。本番を複数人が触る現場では、これが復旧手段であると同時に、どの変更が誰の作業によるものかを示す証拠になります。

よくある質問

古いPHPのまま動かし続けると、何が起きますか

すぐには何も起きません。問題は、セキュリティ更新が提供されないことです。公表された脆弱性が修正されないまま残るため、攻撃者から見れば侵入しやすい状態が続きます。実際に侵入されると、復旧に加えてサーバー移行・全パスワード変更・本体更新までが一度に必要になり、先送りした費用がまとめて戻ってきます。

バージョンアップの見積りは、なぜ幅が大きいのですか

着手してみないと改変の量が分からないからです。誠実に見積もるなら、改変箇所の棚卸しを最初の工程として費用に含めるか、調査だけを別の作業として切り出すことになります。棚卸しなしで一式の金額を出している見積りは、途中で方針転換の相談が来る前提で読んでください。

延命が正解になるのは、どういうときですか

期限が決まっているときです。事業の譲渡や閉鎖、別途進んでいるリニューアルの完了時期など、終わりが見えている場合は、その日まで安全に動かすことだけが要件になります。判断の材料はサイトの中身ではなく、事業計画のほうにあります。

作り直すとして、既存のデータはそのまま移せますか

そのままは、まず無理です。旧システムのテーブル構造が業務の変遷に合わせて継ぎ足されていることが多く、移行前に整理が必要になります。データ移行は作り直しの中で最も見積りにくい部分なので、要件定義の段階で実データを見せてもらったうえで、別枠の金額として出すようにしています。