JetEngineのCCTはいつ使う?問い合わせ履歴を軽く管理する例で解説

jetengine-custom-content-type-thumbnail-simple

この記事には広告を含む場合があります。

記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。

問い合わせ履歴や簡単な業務メモをWordPress内に残したいとき、すぐにデータの箱(CPT)を作る人は多いです。CPTは分かりやすくElementorでも表示しやすい反面、公開ページを持たない履歴データまで投稿として増やすと、管理画面も検索対象も少しずつ散らかります。

この記事では、JetEngineのCustom Content Type、つまり専用テーブルに保存する軽いデータの箱を使って、問い合わせ履歴を管理する例を作ります。フォームから届いた内容のうち、公開ページに出さない対応履歴だけをCCTに保存し、管理者が状態を確認できる社内用一覧にする構成です。

この記事の結論

CCTは公開記事ではなく内部で増える履歴を持たせたいときに向いています。今回の例では、受付日時、件名、対応状態、担当者メモを分け、必要な人だけが見られる管理用データとして扱います。

JetEngine CCTで問い合わせ履歴を軽く管理する全体像

公式情報では、CCTは通常の投稿とは違い、独自のデータベーステーブルへ保存される仕組みとして説明されています。初期状態では個別ページを持たず、一覧テンプレートで表示する考え方です。ブログ記事や制作事例のように公開ページを持つ情報ではなく、注文、申込、履歴、内部管理データのように、たくさん増えても投稿一覧を汚したくない情報に向いています。

JetEngine公式ページを見てみる

この記事で分かること

  • CCTとCPTをどう使い分けるか
  • 問い合わせ履歴CCTに持たせる入力項目の例
  • 管理画面で見やすくする項目設計
  • Elementor側で社内用一覧として表示する流れ
  • 個人情報を扱いすぎないための境界線
  • 任意のコードで対応件数を見える化する方法

まず何を作るのか

CCTと投稿タイプの使い分け

今回作るのは、問い合わせフォームから届いた内容を追跡する問い合わせ履歴です。サイト訪問者へ公開する投稿ではありません。管理者が、いつ届いたか、どんな件名か、対応状態はどうか、誰が確認したかを見られるようにする内部用のデータです。

静的なElementorサイトでは、問い合わせが来たらメールやスプレッドシートで管理することが多いです。件数が増えると誰が対応中か、未確認が残っていないか、同じ相談が何件あるかが追いにくくなります。そこでWordPress側に履歴を持たせると、管理画面の中で状態をそろえられます。

会員情報、住所、決済情報、医療情報のような重い個人情報まで入れる設計にはしません。今回のCCTは問い合わせの進行状況を軽く残すためのものです。本文の全文保存が必要な場合でも、アクセス権限、保存期間、削除ルール、プライバシーポリシーを別途決める必要があります。

CCTとCPTの使い分け

データの箱(CPT)はWordPressの投稿として保存されます。講座、制作事例、スタッフ、店舗、イベントのように、公開ページや一覧ページを作りたい情報には向いています。タイトル、本文、アイキャッチ、URL、カテゴリ、タグを持てるので、Elementorで詳細ページを作りやすいからです。

一方、CCTは専用テーブルに保存するデータです。公式ドキュメントでは、CCTを作ると wp_jet_cct_ にスラッグを足したテーブル名が使われると説明されています。たとえばスラッグを inquiry_logs にすると、標準的な接頭辞なら wp_jet_cct_inquiry_logs のようなテーブルになります。

判断基準は公開したいか、URLを持たせたいか、カテゴリやタグで読者に探してもらいたいかです。答えがはいならCPTが合います。答えがいいえで、社内の処理状態や履歴だけを残したいならCCTを検討します。

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

問い合わせ履歴CCTの入力項目設計

JetEngineでCCTモジュールを有効化したら、Custom Content Typesから新しいCCTを作ります。今回のCCT名は問い合わせ履歴、スラッグは inquiry_logs とします。初期設計ではHas Single Pageはオフにします。公開用の個別ページを作らない履歴だからです。

長文欄を1つだけ作らないことが重要です。対応状態で絞り込みたいなら status、日付順で並べたいなら received_at、担当者別に見たいなら owner_name を分けます。分けておくことで、一覧、検索、集計、通知の設計が後から楽になります。

画面ラベル フィールド名 サンプル値 理由
受付日時 received_at Date/Datetime 2026-05-08 10:15 対応順を見やすくする
件名 subject Text 講座ページの相談 一覧で内容を判別する
対応状態 status Select new / working / done 未対応を残さない
担当者 owner_name Text 佐藤 誰が見るか分ける
公開しないメモ internal_note Textarea 折り返し済み 社内用の短い履歴を残す
関連ページ related_url URL https://example.com/course/ 問い合わせ元を追える

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

CCTの一覧表示と対応状態の絞り込み

CCTのデータは必要に応じて一覧テンプレートから表示できます。JetEngineのListingsで、Listing SourceをCustom Content Typeにし、対象を inquiry_logs にします。テンプレート内にはDynamic Fieldで件名、受付日時、対応状態、担当者を出します。公開サイトに出す用途ではなく、管理者だけが見る社内ページに置く想定です。

ページ側ではElementorにListing Gridを置き、問い合わせ履歴用の一覧テンプレートを選びます。表示件数は20件ほどにして、並び順は受付日時の新しい順にします。対応状態で絞り込みたい場合は、JetEngine側のQuery Builderや一覧条件で未確認だけ、対応中だけを分けると、管理者向けの確認ページが作りやすくなります。

このページを一般公開するのは避けます。問い合わせ履歴は社内向けです。固定ページとして作る場合でも、ログイン必須設定、ロール制御、サーバー側のアクセス制限などを組み合わせ、検索エンジンや未ログインユーザーが見られない状態にしてください。表示条件だけで個人情報を守る設計にはしない方が安全です。

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

運用面ではメールを探す作業が減ります。問い合わせが届いたら、管理者がCCTの履歴を開き、対応状態を未確認から対応中に変えます。対応が終わったら完了にします。担当者メモには、次に見る人が分かる短いメモだけを書きます。

Elementorで作った静的ページの場合、問い合わせ管理そのものはページ外に散らばりやすいです。メール、チャット、スプレッドシート、個人のメモが混ざります。CCTに最低限の履歴を集めると、未確認が何件あるか、対応中が誰の担当か、完了したものはどれかをWordPress内で確認できます。

問い合わせ対応状態を更新する運用フロー

どこから複雑になりすぎるのか

CCTを使う範囲と専用システムを検討する境界

CCTは便利ですが、内部データを全部WordPressに入れるための万能箱ではありません。問い合わせ履歴、簡単な申込履歴、担当者メモ、表示しない集計元のような軽いデータなら始めやすいです。一方で、機密性の高い個人情報、大量ログ、決済、契約情報、細かな権限分岐を扱うなら、CCTだけで済ませようとしない方が安全です。

REST APIエンドポイントを有効化できる設定もありますが、初心者が不用意にオンにするのは避けてください。外部から取得、作成、更新、削除ができる導線は便利な反面、権限設定を間違えるとデータが見えたり変更されたりする危険があります。必要になった時点で、Access Capability、認証、ログ、テスト環境を確認します。

小さな拡張例

CCT導入後に必要な数字だけ集計する拡張例

対応中の件数だけでなく、担当者別の件数や未確認の件数をカード化すると、管理者が朝に見る画面として使いやすくなります。ただし、集計を増やす前に、入力が続くかを確認してください。データが更新されないなら、どれだけきれいな一覧を作っても運用は楽になりません。

実務で迷いやすいのは、問い合わせ本文をどこまで保存するかです。全文を保存すれば検索はしやすくなりますが、個人情報や相談内容が長期間残ります。最初は件名、対応状態、担当者、関連ページ、短い社内メモだけにし、詳細本文はメール側で管理する方が安全な場合もあります。

CCTを作る前に削除ルールも決めてください。完了から三か月で削除する、年度ごとにエクスポートして整理する、未確認だけを毎朝確認する、担当者が退職したら引き継ぎ名に変える、といった運用です。データの箱を作るだけでは運用は楽になりません。

静的Elementorページとの違いも意識してください。静的ページではカードや表を直接編集しますが、CCTでは入力項目を更新すると一覧側が変わります。Elementor担当者は見た目を整え、運用担当者はデータを更新する役割分担になります。

失敗しやすい例は、最初から状態、担当者、優先度、カテゴリ、顧客ランク、対応期限、添付、内部コメント、履歴ログを全部作ることです。項目が増えると入力が面倒になり、結局誰も更新しなくなります。最初は受付日時、件名、状態、担当者メモの四つから始めます。

実務で迷いやすいのは、問い合わせ本文をどこまで保存するかです。全文を保存すれば検索はしやすくなりますが、個人情報や相談内容が長期間残ります。最初は件名、対応状態、担当者、関連ページ、短い社内メモだけにし、詳細本文はメール側で管理する方が安全な場合もあります。

CCTを作る前に削除ルールも決めてください。完了から三か月で削除する、年度ごとにエクスポートして整理する、未確認だけを毎朝確認する、担当者が退職したら引き継ぎ名に変える、といった運用です。データの箱を作るだけでは運用は楽になりません。

静的Elementorページとの違いも意識してください。静的ページではカードや表を直接編集しますが、CCTでは入力項目を更新すると一覧側が変わります。Elementor担当者は見た目を整え、運用担当者はデータを更新する役割分担になります。

失敗しやすい例は、最初から状態、担当者、優先度、カテゴリ、顧客ランク、対応期限、添付、内部コメント、履歴ログを全部作ることです。項目が増えると入力が面倒になり、結局誰も更新しなくなります。最初は受付日時、件名、状態、担当者メモの四つから始めます。

実務で迷いやすいのは、問い合わせ本文をどこまで保存するかです。全文を保存すれば検索はしやすくなりますが、個人情報や相談内容が長期間残ります。最初は件名、対応状態、担当者、関連ページ、短い社内メモだけにし、詳細本文はメール側で管理する方が安全な場合もあります。

CCTを作る前に削除ルールも決めてください。完了から三か月で削除する、年度ごとにエクスポートして整理する、未確認だけを毎朝確認する、担当者が退職したら引き継ぎ名に変える、といった運用です。データの箱を作るだけでは運用は楽になりません。

静的Elementorページとの違いも意識してください。静的ページではカードや表を直接編集しますが、CCTでは入力項目を更新すると一覧側が変わります。Elementor担当者は見た目を整え、運用担当者はデータを更新する役割分担になります。

失敗しやすい例は、最初から状態、担当者、優先度、カテゴリ、顧客ランク、対応期限、添付、内部コメント、履歴ログを全部作ることです。項目が増えると入力が面倒になり、結局誰も更新しなくなります。最初は受付日時、件名、状態、担当者メモの四つから始めます。

実務で迷いやすいのは、問い合わせ本文をどこまで保存するかです。全文を保存すれば検索はしやすくなりますが、個人情報や相談内容が長期間残ります。最初は件名、対応状態、担当者、関連ページ、短い社内メモだけにし、詳細本文はメール側で管理する方が安全な場合もあります。

CCTを作る前に削除ルールも決めてください。完了から三か月で削除する、年度ごとにエクスポートして整理する、未確認だけを毎朝確認する、担当者が退職したら引き継ぎ名に変える、といった運用です。データの箱を作るだけでは運用は楽になりません。

静的Elementorページとの違いも意識してください。静的ページではカードや表を直接編集しますが、CCTでは入力項目を更新すると一覧側が変わります。Elementor担当者は見た目を整え、運用担当者はデータを更新する役割分担になります。

失敗しやすい例は、最初から状態、担当者、優先度、カテゴリ、顧客ランク、対応期限、添付、内部コメント、履歴ログを全部作ることです。項目が増えると入力が面倒になり、結局誰も更新しなくなります。最初は受付日時、件名、状態、担当者メモの四つから始めます。

実務で迷いやすいのは、問い合わせ本文をどこまで保存するかです。全文を保存すれば検索はしやすくなりますが、個人情報や相談内容が長期間残ります。最初は件名、対応状態、担当者、関連ページ、短い社内メモだけにし、詳細本文はメール側で管理する方が安全な場合もあります。

CCTを作る前に削除ルールも決めてください。完了から三か月で削除する、年度ごとにエクスポートして整理する、未確認だけを毎朝確認する、担当者が退職したら引き継ぎ名に変える、といった運用です。データの箱を作るだけでは運用は楽になりません。

この構成が向いている人、向いていない人

向いているのは、Elementorで作ったサイトに少しだけ業務管理の仕組みを足したい人です。問い合わせ、講座申込、資料請求、簡単な社内メモのように、公開記事ではないけれどWordPress内で見たいデータがある場合です。

向いていないのは、最初から複雑な顧客管理、決済管理、詳細な承認フロー、外部システム連携を全部作りたいケースです。JetEngineで土台を作ることはできますが、セキュリティ設計、パフォーマンス確認、バックアップ、運用ルールまで含めると、標準設定だけでは足りない場面があります。

作る前に確認したいこと

問い合わせ履歴に何を保存するか、誰が見られるか、いつ削除するかを先に決めてください。個人情報を必要以上に保存しないこと、テスト環境で試すこと、公式ライセンスとアップデートを維持することが大切です。

まとめ

JetEngineのCCTは、投稿として公開しないデータを軽く持たせたいときに役立ちます。問い合わせ履歴の例では、受付日時、件名、対応状態、担当者メモを分けて保存し、管理者用の一覧で確認できるようにしました。Elementor側ではListing Gridで社内用一覧を作れますが、アクセス制限は別途しっかり設計します。

静的なElementorページから一歩進めるなら、まずは公開ページを作るCPTと、内部履歴を持つCCTを分けて考えるのがおすすめです。小さく始めて、運用が本当に楽になる範囲だけをJetEngineに任せると、複雑になりすぎずに実務へ取り入れられます。

JetEngine公式ページを見てみる