PHP問題/ECモール出品への影響

今回のPHP（ピーエイチピー）問題で、Amazon（アマゾン）・楽天市場・Yahoo!ショッピング（ヤフーショッピング）の出品機能が一律に停止したとは確認できません。楽天市場には一部ページの緊急メンテナンス表示がありますが、PHPとの関係や店舗管理画面の停止までは、その表示から判断できません。

各モールの確認状況

「楽天でPHP対応のメンテナンス」と聞いても、対象サービス名まで読んでください。楽天チケットはPHP脆弱性への予防対応を明記していますが、これは楽天市場の店舗管理画面RMS（アールエムエス）が止まったという告知ではありません。

Amazon Linux（アマゾンリナックス）にも、PHPに関する公式の脆弱性情報があります。これはサーバー用OS（オーエス）のパッケージ情報で、Amazon.co.jpの買い物やセラーセントラルが停止したことを示す告知ではありません。同じ社名を含んでいても、対象のシステムを分けます。

PHP採用の有無や修正済みかどうかを、ページの見た目、URL（ユーアールエル）の末尾、ほかのサービスの停止から推測することもできません。担当者は自店の管理画面内の告知、契約先からの案内、実際の連携結果を確認します。

出品者が直す範囲

PHP公式は、重大な脆弱性2件を修正する8.5.12、8.4.27、8.3.36、8.2.35を公開しています。自社のサーバーでPHPを運用する担当者は、提供元の修正済みパッケージや修正の取り込み状況を確認します。

一方、出店しているだけの店舗は、モール本体のPHPを更新できません。管理画面が使えない場合は、運営会社の対象機能と再開案内を確認します。外部の受注ソフトで止まっている場合は、その提供会社の案内を読みます。

自社サイト、WordPress（ワードプレス）、独自の在庫連携や受注取込を持つ店舗には、別の確認が残ります。連携処理がどのサーバーで動き、誰が保守しているかを棚卸しします。PHPを直接扱わないSaaS（サース・事業者が提供するクラウド型サービス）なら、利用者が内部の設定を変える前に提供元へ確認してください。

商品が見えても別確認

「商品ページが開くなら、自動処理も正常」とは限りません。買う側の画面、店舗の管理画面、注文取込、在庫更新、出荷通知は、成功を確かめる場所がそれぞれ違います。

Yahoo!ショッピングの公式開発者向け資料も、商品・在庫・注文など複数のAPI（エーピーアイ・システム同士の連携窓口）を案内しています。トップページの表示確認と、各連携処理の成功確認を分ける理由はここにあります。

確認のために実際の注文を重複作成したり、未確認の処理を一括で再実行したりしないでください。まず自店の画面とログで未処理の範囲を確定し、操作方法は連携ソフトの案内に従います。

復旧後の受注照合

1. 停止前の最終成功時刻から復旧までの対象期間を決める。
2. モールの注文一覧と、自社に取り込んだ注文番号を照合する。
3. 取込漏れ、重複、キャンセルや支払状態の変更を注文ごとに確認する。
4. 在庫の正本を確認し、実在庫と販売可能数を合わせる。
5. 出荷済み注文を除外して発送を進め、追跡番号と通知を確認する。

たとえば、停止前に取り込んだ注文が復旧時にもう一度届いた場合、その番号を照合せずに発送すると二重発送につながります。これは各モールで今回その障害が起きたという報告ではなく、連携を再開するときの確認例です。

私は、復旧確認は「画面が開いた」で終えず、「対象期間の注文をすべて説明できる」状態まで行う方が、発送と返金の手戻りを減らせると考えます。PHP対応の状況、モール側の案内、連携ソフト側の案内を1枚に記録しておくと、誰へ照会するかも決まります。

梱包用品や端末を買ってもサーバーの脆弱性は直りません。このページでは対策商品としての販売案内を置かず、通常の管理分担と費用の比較は、関連する出店比較記事へまとめています。