同じ製品情報を、Webと仕様書で二重管理しない。

製品ページと仕様書のずれを、CMS要件として捉える

対象は、産業用機器の製品カタログ、仕様書、お知らせ、採用情報をWebで発信する製造業です。移行元のケース資料では、製品情報の更新、仕様書作成、問い合わせ・採用受付、お知らせ・FAQの運用が、それぞれ設計課題として記録されています。

AMELAが担当した範囲として確認できるのは、WordPressを基盤にした製品情報管理、入力内容からの仕様書PDF生成、問い合わせ・採用フォーム、管理画面の構成です。企業名、プロジェクト名、製品名、型番、画面内の件数・日付・状態は、機密保持のため承認済みの仮名またはモックに置き換えています。

構造化した製品情報を、Web・PDF・受付へつなぐ

移行元資料では、WordPressとACFで製品項目を構造化し、PHPとdompdfで仕様書PDFを生成する構成が示されています。問い合わせ・採用フォームにはMW WP Form、業務データにはMySQL、運用時の持ち出しにはCSV出力が記載されています。

公開デモでは、製品カテゴリによる絞り込み、製品詳細、仕様書PDFへの導線、問い合わせ・採用フォーム、製品・お知らせ・FAQ・受付を確認する管理画面を操作できます。

この事例の根拠と読み方

• 根拠：AMELAの移行元ケース資料、CMS登録内容、2026年8月26日に確認した公開デモの動作と画面。
• 対象期間：公開資料に記載された開発範囲と、上記確認日時点のデモ。
• 確認できること：製品カテゴリ・詳細、仕様書PDFへの導線、問い合わせ・採用フォーム、製品・お知らせ・FAQ・受付を扱う管理画面、WordPress・ACF・dompdf・MW WP Form・MySQLを用いた構成。
• 確認できないこと：本番データ量、処理性能、更新頻度、利用率、工数・コスト削減、問い合わせ・応募への効果、権限設計の詳細、監査・認証・法令適合、障害・可用性の実績。
• 公開上の扱い：企業名、プロジェクト名、製品名、型番、画面、件数、日付、状態は機密保持のため仮名またはモックです。実在する顧客、製品、業績を示すものではありません。

導入前に、データの正本と公開責任を決める

製品情報をCMSへ集約しても、承認前の仕様や廃番情報まで自動公開してよいとは限りません。製品データの責任者、下書きと公開の権限、PDFを再生成する条件、旧版の保存、公開停止時の扱いを決める必要があります。

フォームには個人情報が含まれます。保存期間、通知先、閲覧権限、削除手順、同意文面、迷惑送信対策、障害時の代替受付は、導入企業の規程と法務確認に合わせて別途設計してください。

読者が使える実践ツール

要件定義の前に、次の「データ正本・PDF・受付・権限・受入確認シート」を埋めると、CMS側と業務側の責任を整理できます。以下は公開デモで確認できる機能を使った記入例であり、BrandCore本番環境の運用値ではありません。

• 製品データの正本：CMSの製品項目をWeb表示とPDF生成の入力にする。基幹データとの同期有無と責任者は別途決める。
• PDF生成：承認済みの項目だけを出力する。仕様変更時の再生成、旧版の保管、ファイル名の規則を決める。
• 受付：問い合わせと採用応募で入力項目と通知先を分ける。受付番号、対応状態、期限の管理方法を決める。
• 権限：製品編集、お知らせ・FAQ編集、公開承認、受付閲覧を分ける。退職・異動時の権限削除を決める。
• 受入確認：同じ製品データがWebとPDFへ反映される、未承認情報を公開しない、必須・同意・エラー表示が動く、受付を権限外の利用者に見せないことを確認する。

実データで評価する場合は、製品項目の種類、PDFのページ構成、同時編集者、フォーム件数、保存期間、連携先、除外条件をそろえて、導入前に受入基準を定義してください。