JetEngine Glossaryで選択肢を使い回す方法。業種タグ管理の例

Elementorで制作事例や店舗紹介ページを作っていると、「業種」「地域」「対応サービス」のような選択肢を何度も入力する場面が出てきます。最初は数件なので手入力でも進められますが、投稿項目、フォーム、絞り込み検索で同じ選択肢を別々に持つと、あとから名称変更や追加が起きたときに崩れやすくなります。

今回作るのは、業種タグを一度だけ管理し、複数の入力場所で使い回す小さな仕組みです。例として、制作会社の「クライアント事例」サイトを想定します。各事例には「飲食」「美容」「士業」「教育」のような業種を付け、一覧ページでは業種で絞り込めるようにします。

ここで使う中心機能がJetEngineのGlossaryです。日本語で言えば、サイト内で再利用する「選択肢の台帳」です。データの箱（CPT）や入力項目（Custom Field）を作るだけでなく、選択肢そのものを別管理にできるので、静的なElementorページから一歩進めたい人にはかなり実務的です。

JetEngine公式ページを見てみる

この記事で作るもの

• クライアント事例のデータの箱（CPT）を作る
• 業種タグをGlossaryとして一括管理する
• 投稿編集画面の入力項目にGlossaryの選択肢を接続する
• Elementorの一覧テンプレートで業種を表示する
• 絞り込み検索やフォームでも同じ選択肢を使う考え方を整理する

まず何を作るのか

想定するサイトは、制作会社やマーケターが使う「クライアント事例一覧」です。静的なElementorページであれば、1件ずつカードを複製して、タイトル、画像、業種、紹介文を手で差し替えます。件数が少ないうちは十分ですが、20件、50件と増えたときに、カードの並び替え、業種別の一覧、業種名の変更が負担になります。

JetEngine側では、次のような構成にします。

ポイントは、業種名を投稿ごとに自由入力させないことです。自由入力にすると「美容」「美容系」「ビューティー」のような表記揺れが起き、一覧表示や検索の条件に使いにくくなります。後から絞り込みたい情報は、なるべく選択式に分けるのが安全です。

JetEngineでどのデータを持たせるのか

今回のGlossaryは、業種タグの台帳として作ります。設定例は次のようにします。

値は英数字にして、表示名は日本語にします。英数字の値は内部処理や条件指定で扱いやすく、日本語の表示名は読者や編集者に分かりやすいからです。最初から「業種名を変更する可能性がある」ことを考えるなら、値は安定させ、表示名だけ変更できる形にしておくと運用が楽になります。

入力項目側では、クライアント事例CPTに industry_tag という項目を追加します。Field typeは、1件の事例に1つの業種だけ付けるならSelect、複数の業種にまたがるならCheckboxにします。Crocoblock公式ドキュメントでも、Glossaryの値をSelect、Checkbox、Radioなどの選択項目に使える流れが案内されています。

このとき、何でもGlossaryにすればよいわけではありません。記事ごとに違う短い説明文、事例ごとの成果数値、担当者コメントのような情報は、通常の入力項目として持たせます。Glossaryに向いているのは、複数の場所で同じ候補を使い、後から増減する可能性がある情報です。

Elementor側ではどう表示するのか

Elementor側では、JetEngineの一覧テンプレート（Listing Item）を作り、1件のクライアント事例カードを設計します。カードにはアイキャッチ画像、事例名、業種タグ、短い説明、詳細ページへのリンクを置きます。業種タグの出力には、Dynamic Fieldを使い、industry_tag の値を表示します。

カード例としては、次のような構造が扱いやすいです。

• 上部: Dynamic Imageで事例画像を表示
• 中央: Dynamic Fieldで事例タイトルを表示
• タグ: Dynamic Fieldで業種タグを表示
• 本文: 抜粋または短い説明文を表示
• 下部: Dynamic Linkで詳細ページへ移動

一覧ページでは、Listing Gridにこのカードを読み込ませます。静的なElementorカードを複製していた頃と違い、投稿を追加すれば一覧にも反映されます。レイアウトを直したいときも、1件の一覧テンプレートを直せば全カードに反映されるので、運用時の修正範囲が小さくなります。

絞り込み検索にも使うなら設計を先に決める

業種タグは、一覧カードに表示するだけでなく、絞り込み検索の条件としても使えます。たとえば、一覧ページ上部に「飲食」「美容」「士業」「教育」のチェックボックスを置き、選んだ業種の事例だけを表示する形です。ここで別々の選択肢を手入力していると、投稿編集画面では「士業」なのに検索側では「専門職」になってしまうようなずれが出ます。

JetEngineのGlossaryで選択肢を持っておけば、投稿項目、フォーム、絞り込み検索で同じ候補を使う方針を取りやすくなります。絞り込み検索自体には、必要に応じて「一覧を絞るためのプラグイン（JetSmartFilters）」を組み合わせます。ただし、この記事の中心はJetSmartFiltersではありません。まずはJetEngine側で、検索条件に使える整ったデータを持つことが先です。

Query Builderを使って「特定の業種だけをおすすめ枠に出す」ような条件を作る場合も、値が安定していると扱いやすくなります。たとえば industry_tag = food のように内部値で条件を決め、表示名だけを「飲食店」へ変える運用ができます。表示名を変更しても内部値を変えなければ、条件指定が壊れにくくなります。

運用すると何が楽になるのか

運用面で一番大きいのは、選択肢の追加や名称変更を一か所で考えられることです。新しく「医療」という業種を扱うことになったら、Glossaryに medical / 「医療」を追加します。その後、投稿編集画面、フォーム、検索UIで同じ選択肢を使う設計にしておけば、管理者は「どこを直せばよいか」で迷いにくくなります。

静的なElementor運用では、業種ラベルが各カードのテキストとして散らばります。すると、表記を変えるだけでも複数ページを開いて確認しなければなりません。JetEngineでデータを持たせると、ページの見た目と情報の管理場所を分けられます。見た目はElementor、繰り返し使う情報はJetEngineという役割分担ができるわけです。

もう一つの利点は、入力ミスを減らせることです。選択式にしておけば、編集者が毎回文字を打つ必要がありません。複数人で更新するサイトほど、この差は大きくなります。とくにクライアントに更新を任せる場合、自由入力欄を増やすより、選択肢をあらかじめ用意しておく方が安定します。

逆に、ここから先は慎重にした方がいいです

Glossaryは便利ですが、分類設計を詰め込みすぎると管理が複雑になります。たとえば、業種、地域、サービス種別、予算帯、制作期間、担当チーム、公開状態をすべて選択式で管理し、さらに絞り込み条件に使うと、編集者は何を選べばよいか分からなくなります。

最初は、一覧表示や検索で本当に使うものだけを選択式にします。今回の例なら、業種タグは使う価値があります。一方で、社内だけが見る細かいメモは自由入力で十分です。絞り込みたい情報、並べ替えたい情報、再利用したい情報だけを分ける、と考えると迷いにくいです。

また、会員情報、問い合わせ内容、予約情報のような個人データに近いものを扱う場合は、表示条件、権限、プライバシーポリシー、バックアップを別途設計してください。JetEngineはデータ構造と表示を作る強力な道具ですが、セキュリティ設計や運用ルールまで自動で完成させるものではありません。

管理画面での作業順序

実際に作るときは、Elementorの見た目から先に作り始めるより、管理画面側のデータを先に決めた方が失敗しにくいです。まず「クライアント事例」というデータの箱を作り、次に業種タグのGlossaryを作り、最後に入力項目へつなげます。見た目はその後で十分です。データが決まっていない状態で一覧カードを作ると、あとから項目名や出力方法を直す回数が増えます。

作業順序としては、1つ目にCPTを作成します。スラッグは client_case、単数名は「クライアント事例」、複数名も同じ日本語で問題ありません。2つ目にGlossaryを作成し、スラッグを industry にします。3つ目にCPTの入力項目として industry_tag を追加し、入力タイプをSelectまたはCheckboxにします。4つ目に、その選択肢の取得元としてGlossaryを指定します。

この順序で作ると、どこで何を管理しているかが分かりやすくなります。Glossaryを後回しにして、先に入力項目へ手入力の選択肢を入れてしまうと、あとでGlossaryに移し替える手間が出ます。小さなサイトなら大きな問題にはなりませんが、クライアントに納品するサイトでは、最初から再利用する選択肢をGlossaryに寄せておく方が親切です。

よくある設定ミス

一つ目のミスは、表示名だけを見て内部値を雑に決めることです。たとえば「美容」という表示名に対して内部値も日本語で「美容」にしてしまうと、条件指定や外部連携を考えたときに扱いにくくなる場合があります。必ず英数字でなければいけないわけではありませんが、長く使う分類ほど beauty のような安定した値にしておく方が無難です。

二つ目のミスは、選択肢を細かく分けすぎることです。「美容」「美容室」「ヘアサロン」「ネイル」「エステ」を全部同じ階層に入れると、投稿者が迷います。サイトの読者が業種で探すなら「美容」で十分かもしれません。もし詳細分類が必要なら、業種タグとは別に「サービス種別」という入力項目を作る方が整理しやすいです。

三つ目のミスは、一覧に表示するラベルと検索条件を別々に考えることです。業種タグをカードに出すだけなら見た目の問題で済みますが、絞り込み検索に使うなら内部値の一貫性が重要になります。あとからJetSmartFiltersを組み合わせる可能性があるなら、最初の段階で「この項目は検索条件に使う」と決めておきます。

小さく試すためのサンプル入力

いきなり本番の全事例を移す必要はありません。まずは3件だけテスト投稿を作ります。1件目は「カフェサイトリニューアル」で業種を「飲食」、2件目は「美容室予約ページ制作」で業種を「美容」、3件目は「税理士事務所コーポレートサイト」で業種を「士業」にします。この3件で、投稿編集画面、一覧カード、業種ラベル、絞り込みの動きまで確認できます。

テスト時には、業種名を1つ変更してみるのも有効です。たとえば「士業」を「専門職」に変えた場合、既存投稿の表示がどう変わるか、検索条件が壊れないかを確認します。もし表示名の変更だけで済むなら設計は扱いやすい状態です。逆に、投稿ごとに手直しが必要なら、選択肢の持たせ方を見直す合図です。

納品前には、編集者向けに「業種を増やすときはGlossaryを開く」「投稿画面で自由入力しない」「削除前に既存投稿で使っていないか確認する」という短い運用メモを残すと安心です。JetEngineの設定そのものよりも、更新担当者が迷わない導線を作ることが、実務では大切です。

この構成が向いているケース

• 制作事例、店舗紹介、講師一覧など、似た情報を何件も管理するサイト
• 業種、地域、対応サービスのような選択肢を複数画面で使いたいサイト
• Elementorで見た目を作りながら、WordPress側で情報を整理したい制作者
• あとから絞り込み検索やフォーム入力にも広げたいサイト

逆に、1ページだけのLPや、更新頻度がほとんどない会社概要ページでは、Glossaryまで作る必要はないかもしれません。静的ページで十分な情報まで動的化すると、設定の管理コストの方が大きくなります。

納品時に残しておきたい短いメモ

クライアントに渡すサイトなら、Glossaryの場所を説明する短いメモを残しておくと後の問い合わせが減ります。たとえば「業種の追加は、投稿編集画面ではなくGlossaryの業種リストで行います」「既に使っている業種を削除すると、一覧や検索結果に影響することがあります」「表示名は変更してもよいですが、内部値はむやみに変えないでください」といった内容です。高度なマニュアルでなくても、更新担当者が最初に開く場所を迷わないだけで十分価値があります。

また、選択肢を追加した後は、投稿編集画面、一覧ページ、絞り込み検索の3か所を確認します。管理画面で追加できたから完了ではなく、Elementor側で表示されるか、検索条件として使えるかまで見るのが実務の確認です。ここを省くと「管理画面にはあるのに、公開画面に出ない」という相談につながります。

将来、地域タグやサービス種別もGlossary化したくなった場合は、業種タグと同じ考え方で増やせます。ただし、分類が増えるほど編集画面は複雑になります。最初は業種だけ、次に地域、必要になってからサービス種別、というように段階的に増やす方が安全です。JetEngineは仕組みを作る道具なので、運用担当者が迷わない範囲に抑えることも設計の一部です。

なお、この記事の例では業種タグだけを扱いましたが、同じ考え方は「対応エリア」「対象業種」「サービスカテゴリ」にも使えます。判断基準は、複数の投稿やフォームで同じ候補を使い、あとから増減する可能性があるかどうかです。候補を一か所で管理できると、Elementorで作った見た目を保ちながら、WordPress側の情報だけを落ち着いて更新できます。

まとめ

JetEngine Glossaryは、選択肢をきれいに再利用するための機能です。今回の業種タグの例では、Glossaryで「飲食」「美容」「士業」「教育」を管理し、クライアント事例CPTの入力項目、Elementorの一覧表示、絞り込み検索へつなげる流れを作りました。

重要なのは、最初から大きなシステムを作ろうとしないことです。まずは1つのデータの箱、1つの選択肢、1つの一覧ページで試し、運用で本当に使う分類だけを増やしていくのが現実的です。JetEngineを使うと、Elementorで作った見た目に、更新しやすいデータ構造を接続できます。

JetEngine公式ページを見てみる