WordPressで製品データベース型サイトを構築した話。70以上のACFフィールド設計と検索機能の裏側
2026.05.26
山キノコロリ WEB事業部では、WordPressを使ったWebサイト制作や、既存サイトのリニューアル、カスタム投稿・カスタムフィールドを活用した情報設計を行っています。
今回は、制作会社様経由でご相談いただいた、大手企業関連サイトの全面リニューアル案件について、技術設計と実装の視点から振り返ります。
守秘義務の関係上、企業名・業種・URL・具体的な公開時期などは伏せていますが、WordPressで複雑な情報管理を行う案件の一例として、どのようなことを考えながら実装したのかをまとめます。
案件の概要：大手企業関連サイトの全面リニューアル
今回の案件は、既存サイトの全面リニューアルでした。
一般的なコーポレートサイトのように、会社概要やお知らせを掲載するだけのサイトではありません。
製品情報、導入事例、お役立ち情報、お客様サポート、各種資料ページなど、多数の情報を扱うサイトでした。
WordPress上では、主に以下のような構成で実装しています。
- 製品情報：カスタム投稿
- 導入事例：カスタム投稿
- お役立ち情報：カスタム投稿
- お知らせ：通常投稿
特に中心となったのは、製品情報の設計です。
製品ごとに掲載する情報量が多く、カテゴリによって必要な項目も異なるため、単純な固定ページや通常投稿だけでは運用しづらい構成でした。
そこで、製品情報をカスタム投稿として設計し、ACFのカスタムフィールドを使って、製品ごとの情報を管理できるようにしました。
最終的に、製品情報まわりでは70以上のカスタムフィールドを設計・実装しています。
WordPressを「製品情報データベース」として使う難しさ
WordPressは、とても柔軟なCMSです。
カスタム投稿、カスタムタクソノミー、カスタムフィールドを組み合わせることで、一般的なブログやお知らせだけでなく、製品情報サイトや導入事例サイトのような構成にも対応できます。
ただし、自由に作れるからこそ、設計を誤ると運用しづらいサイトになってしまいます。
今回のような製品情報サイトでは、以下のような点を同時に考える必要がありました。
- 管理画面で入力しやすいこと
- 製品カテゴリごとに必要な情報を出し分けられること
- 検索や絞り込みに対応できること
- 表示側で無駄な処理を増やしすぎないこと
- 将来的な更新や改修に耐えられること
見た目を再現するだけであれば、HTML/CSSの実装で済みます。
しかし、WordPressで長く運用されるサイトにする場合は、「どの情報を、どの単位で、どこに持たせるか」という設計が重要になります。
正直なところ、ここまで来ると通常のWordPressサイト制作というより、WordPressをベースにした製品情報管理システムに近い感覚でした。
70以上のACFカスタムフィールドをどう設計したか
今回もっとも大きなポイントは、製品情報のカスタムフィールド設計でした。
製品情報には、基本情報、製品の特徴、仕様、関連資料、関連リンク、カテゴリごとの表示制御、検索・絞り込みに使う情報など、多くの項目が必要でした。
単純にフィールドを増やしていくだけなら簡単です。
しかし、フィールド数が多くなるほど、管理画面は複雑になります。入力する人が迷いやすくなり、更新ミスも起きやすくなります。
また、ACFではフィールドをひとつのグループ内に多く作りすぎると、保存時に不安定になるケースもあります。
そのため今回は、フィールドを大きなひとつのグループにまとめるのではなく、用途やカテゴリごとに細かくグループ分けしました。
たとえば、以下のような考え方です。
- 基本情報として共通で使う項目
- 製品カテゴリごとに必要になる項目
- 表示制御に使う項目
- 検索・絞り込みに使う項目
- 関連資料やリンクに関する項目
入力する人にとって、どこに何を入れればよいか分かりやすいこと。
テンプレート側で扱いやすい構造になっていること。
この両方を意識して設計しました。
カスタムフィールドは、増やすだけなら簡単です。ですが、運用に耐える設計にするには、「入力する人の画面」と「表示する側のテンプレート」の両方を見ながら組み立てる必要があります。
ACFグループを細かく分けた理由
ACFのフィールドグループは便利ですが、大量の項目をひとつのグループに詰め込みすぎると、管理画面が重くなったり、保存がうまくいかなかったりすることがあります。
また、今回のように製品カテゴリによって表示する項目が異なる場合、すべての入力欄を常に表示してしまうと、管理画面が非常に分かりにくくなります。
そこで、フィールドグループを細かく分け、必要な場所に必要な項目だけが表示されるように整理しました。
これは、開発者側の都合だけではありません。
実際に入力・更新する担当者にとっても、不要な項目が並んでいる画面は迷いやすく、ミスの原因になります。
WordPressの管理画面は、納品後にお客様が使い続ける場所です。
だからこそ、表示側のデザインだけでなく、管理画面の使いやすさも品質の一部だと考えています。
製品カテゴリごとの表示出し分け
製品情報では、カテゴリごとに必要な情報や見せ方が異なりました。
すべての製品に同じテンプレートを当てはめるだけでは、不要な項目が出たり、逆に必要な情報が足りなかったりします。
そのため、製品カテゴリに応じて表示内容を出し分ける設計を行いました。
このときに重要なのは、テンプレート側で無理やり条件分岐を増やしすぎないことです。
もちろん、条件分岐は必要です。
しかし、場当たり的に分岐を増やしていくと、後から見たときに何がどこで制御されているのか分かりにくくなります。
今回は、カテゴリごとの違いを整理し、共通化できる部分と個別に出し分ける部分を分けながら実装しました。
WordPressのカスタム投稿とACFを組み合わせる場合、この「共通部分」と「個別部分」の切り分けがとても重要です。
検索・絞り込み機能で意識したこと
製品情報サイトでは、ユーザーが目的の製品にたどり着きやすいことも重要です。
今回の検索・絞り込みでは、主に以下の条件を扱いました。
- キーワード
- 製品カテゴリ
- カスタムフィールド値
WordPressで検索や絞り込みを実装する場合、条件を増やそうと思えばいくらでも増やせます。
しかし、条件を増やせば増やすほど、処理は複雑になります。
特にカスタムフィールドを使った検索は、実装方法によってはパフォーマンスに影響することがあります。
そのため今回は、検索対象を必要な範囲に絞り、tax_query と meta_query を中心に構成しました。
「何でも検索できるようにする」のではなく、実際にユーザーが探したい条件は何か、運用上必要な条件は何かを整理したうえで実装しています。
検索機能は、見た目にはシンプルに見えても、裏側では設計の影響が大きい部分です。
だからこそ、最初の段階で条件を整理しておくことが重要です。
パフォーマンスを落とさないための実装判断
今回のように、カスタム投稿、カスタムフィールド、カテゴリによる出し分け、検索・絞り込みが絡むサイトでは、パフォーマンスにも注意が必要です。
特に意識したのは、以下の点です。
- 検索対象を必要な範囲に絞る
tax_queryとmeta_queryを中心に構成する- 表示側で不要なループを避ける
- 画像を最適化する
複雑なサイトでは、要望をそのまま積み上げるだけだと、テンプレートも処理も重くなっていきます。
必要な情報を必要な場所で取得し、不要なループや条件分岐を増やしすぎないこと。
画像についても、表示品質を保ちながら、できるだけ無駄に重くならないように調整すること。
こうした小さな判断の積み重ねが、サイト全体の使いやすさや保守性につながります。
仕様が流動的な案件で、技術側から進行を支える
大型リニューアル案件では、最初からすべての情報や仕様が確定しているとは限りません。
今回も、原稿やデザインが段階的に届いたり、途中で要件が追加されたり、公開直前に新たな要望が出たりする場面がありました。
その中で意識したのは、技術側からも進行を支えることです。
たとえば、課題をスプレッドシートで管理し、確認事項や未確定事項を共有しました。
また、確認に時間が必要な部分は早めに実装し、関係者がチェックできる期間を確保するようにしました。
公開直前の追加要望については、すべてを無理に対応するのではなく、公開前に必要なものと、公開後に回せるものを切り分けました。
無理なスケジュールで対応すれば、どこかで品質に影響が出ます。
だからこそ、「今やるべきこと」と「後でもよいこと」を整理し、現実的な進め方を提案することも、技術者の役割だと考えています。
公開前後で気をつけたこと
公開作業では、サーバー環境やドメイン切り替えによるトラブルにも注意しました。
今回はクラウド環境上での公開作業も含まれていたため、事前確認と切り替え時の影響範囲を意識しながら進めました。
また、公開前には確認フェーズを設け、表示崩れやリンク、フォーム、管理画面の入力内容などをチェックしました。
大型サイトでは、公開直前にすべてを一人で確認するのは現実的ではありません。
必要に応じて確認担当を分け、チェックの抜け漏れを減らすことも品質管理の一部です。
WordPressの“魔改造”は、設計と判断が重要
WordPressは柔軟です。
カスタム投稿、カスタムタクソノミー、ACF、テンプレート、検索機能を組み合わせれば、かなり複雑な情報設計にも対応できます。
ただし、自由に作れるからこそ、設計と判断が重要になります。
今回の案件でも、単に要望をそのまま実装するのではなく、以下のような点を常に考えながら進めました。
- どこまでをWordPressで管理するか
- どこからをテンプレートで制御するか
- どの情報を検索対象にするか
- 管理画面で入力しやすいか
- 表示側で無駄な処理が増えないか
- 将来的な改修に耐えられるか
WordPressのカスタマイズは、コードを書くだけではありません。
情報設計、管理画面の使いやすさ、表示側の構造、検索条件、パフォーマンス、運用後の保守性まで含めて考える必要があります。
そこに、WordPress案件の難しさと面白さがあると感じています。
まとめ
今回の案件では、WordPressを使って、製品情報をデータベースのように扱う大型サイトを構築しました。
特に重要だったのは、以下の3点です。
- 70以上のACFカスタムフィールド設計
- 製品カテゴリごとの表示出し分け
- 検索・絞り込み機能の設計とパフォーマンス配慮
ACFは便利ですが、何も考えずにフィールドを増やしていくと、管理画面もテンプレートもすぐに複雑になります。
便利な道具ほど、設計なしで使うと後から効いてきます。
だからこそ、WordPressで複雑なサイトを構築する場合は、実装前の情報整理や設計がとても大切です。
ご相談ください
山キノコロリ WEB事業部では、WordPressを使ったサイト制作、既存サイトのリニューアル、カスタム投稿・カスタムフィールドを活用した情報設計、複雑な検索・絞り込み機能の実装などに対応しています。
特に、制作会社様の外部技術パートナーとして、以下のような場面でお手伝いできます。
- デザインはあるが、WordPress実装が複雑で不安
- カスタムフィールドが多く、設計から相談したい
- 製品情報や事例情報をデータベースのように管理したい
- 既存サイトのリニューアル方針を技術面から相談したい
- ディレクション段階で実装リスクを洗い出したい
「このWordPress案件、少し複雑かもしれない」と感じたときは、ぜひ一度ご相談ください。
札幌拠点リモートでも全国案件対応OK。
WordPressフルカスタマイズやカスタム投稿・カスタムフィールド設計、既存サイトリニューアルのご相談は
▶ 山キノコロリ WEB事業部 まで！