JetEngine Charts Builderで数値データをグラフ表示する具体例

Elementorで制作したサイトに「今月は問い合わせが増えているのか」「どの時期に相談が多いのか」を見せたい場面があります。画像で作ったグラフを毎月貼り替える方法でも最初は動きますが、数字の更新、古い月の修正、過去データとの比較がすぐに手作業になります。この記事では、JetEngineのCharts Builderを使い、月別問い合わせ数グラフをElementorページに表示する具体例で考えます。

作るのは大きな分析システムではありません。WordPressに保存した問い合わせデータを、月ごとの件数として見せる小さな運用グラフです。最初に考えるべきなのは見た目ではなく、グラフの元になるデータをどう分けて持つかです。

JetEngine公式ページを見てみる

• 問い合わせデータをどの入力項目に分けるか
• Query Builderで月別件数を返す考え方
• Charts Builderでラベルと数値を対応させる方法
• Elementorで読みやすく表示する構成
• 運用で便利になる所と複雑にしすぎる境界

まず何を作るのか

今回の例では、Web制作サービスのサイトに届いた問い合わせをWordPress内で管理し、その受付日をもとに月別件数をグラフ表示します。たとえば「1月は12件、2月は18件、3月は31件」のような推移を、管理者が見られる状態にします。公開ページで成果を見せる用途にも使えますが、最初は社内確認用のページとして作る方が安全です。

静的なElementorページだけで作る場合、毎月の数字を見て手作業でグラフ画像を作り、ページに貼り替えることになります。月が増えるたびに画像を直す必要があり、問い合わせ種別や流入元ごとの確認をしたくなった時点で運用が苦しくなります。JetEngineを使う場合は、問い合わせというデータの箱を作り、見た目は後から接続します。

どのデータをWordPressに持たせるのか

グラフを作る前に決めるべきなのは、どの数字を毎月集計するかです。今回なら問い合わせ1件を1レコードとして扱います。データの箱（CPT）は inquiry、表示名は「問い合わせ」とします。

「5月に検索から料金相談が来た」と長い文章で残すと、後から月別件数や流入元別件数として扱いにくくなります。グラフに使いたい情報は、入力項目として分けます。ここを分けるだけで、あとからQuery Builderで条件を作るときの迷いがかなり減ります。

JetEngineが中心になる理由

Charts Builderはグラフを表示する機能ですが、グラフだけを見て導入を考えると失敗しやすいです。実際には、グラフの前に「何を数えるのか」「どの条件で絞るのか」「どのページに表示するのか」を設計する必要があります。

JetEngineの役割は単なる見た目の部品ではありません。データの箱、入力項目、一覧テンプレート、条件つきの取得、Elementor表示までをつなげる土台です。Charts Builderは、その中の数字を読みやすい形で見せる部分と考えると分かりやすいです。公式情報でもJetEngineはカスタム投稿、カスタムフィールド、Listing、Query Builder、Charts Builder、REST API連携などを含む動的サイト制作の機能群として説明されています。

Query Builderで月別の件数を返す

Charts Builderに渡す前に、月別に問い合わせ数を取得する考え方を作ります。設定としては、対象を inquiry の投稿にし、received_date が空ではないものを集計対象にします。期間は今年の1月1日から12月31日まで、まとめ方は受付日の月ごと、返したい値は月のラベルと件数です。

• 対象のデータ: inquiry の投稿
• 条件: received_date が空ではない
• 期間: 今年分だけ
• まとめ方: 受付日の月ごと
• 返したい値: 月のラベルと件数

最初から流入元別、担当者別、サービス別まで全部入れないことが大事です。最初は月別の総件数だけで十分です。運用してから、必要な切り口を増やす方が安全です。

Charts Builder側でグラフを作る

Charts Builderでは、グラフに使うデータソースを選び、ラベルと数値を対応させます。今回なら横軸に「月」、縦軸に「問い合わせ件数」を置きます。推移を見たいなら折れ線、月ごとの比較を強く見せたいなら棒グラフが向いています。

色はブランドカラーに合わせて調整します。ただし、色を増やしすぎると数字の意味より装飾が目立ちます。月別問い合わせ数だけなら1色から2色で十分です。

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

Elementor側では、グラフを置くページを先に決めます。公開ページに見せるのか、管理者だけが見るページに置くのかで設計が変わります。問い合わせ数は社内向けの数字であることが多いので、最初は会員向けページや管理者確認用ページに置く方が無難です。

• 上部: 今月の問い合わせ件数カード
• 中央: 月別問い合わせ数グラフ
• 下部: 多かった月、少なかった月、未対応件数の補足

グラフだけを置くと読者が数字を判断しにくいので、Dynamic Fieldや通常テキストで補足カードを足すと運用で見やすくなります。Elementor側では余白、見出し、補足文を整え、数字の入力そのものはWordPressの問い合わせデータに寄せます。

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

一番大きいのは、月次確認のたびにページを作り直さなくてよくなることです。問い合わせを登録すれば、グラフ側は元データを読みます。実際にはキャッシュや更新タイミングの確認が必要ですが、少なくとも画像を作り直して差し替える作業からは離れられます。

静的なElementorページでは、数字を直す場所がページ内に散らばります。JetEngineでデータを持たせると、修正する場所は問い合わせデータ側に寄せられます。担当者がページ編集画面に入らず、問い合わせデータだけを更新できるのも利点です。

任意でできるグラフ表示の調整

Charts Builderの標準設定だけで形になる場合、無理にコードを足す必要はありません。もしグラフの目盛りや凡例の見え方を細かく調整したい場合は、Advanced Optionsのような詳細設定欄で、公式ドキュメントに沿ってチャート設定を追加できるか確認します。

以下は、縦軸を0から始め、件数を整数で見せたい場合の考え方の例です。現在のCharts Builder画面で受け付ける設定形式を必ず確認してください。

{
  "scales": { "y": { "beginAtZero": true, "ticks": { "precision": 0 } } },
  "plugins": { "legend": { "display": false } }
}

配置場所はCharts Builderのグラフ詳細設定内にある高度なオプション欄です。標準設定で十分読めるなら、この調整は入れなくて大丈夫です。追加する場合はテスト環境で表示崩れがないか確認し、うまくいかなければすぐ戻せる状態で試してください。

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

グラフは便利ですが、増やしすぎると運用が重くなります。問い合わせ数、流入元、担当者、商談化率、受注率、地域、サービス別、広告別、と増やしていくと、WordPressのページというより分析基盤の設計に近づきます。

JetEngineで小さな可視化を作ることはできます。ただし、すべての分析や業務判断をWordPress内で完結させる必要はありません。大量データ、複雑な集計、権限ごとの細かい閲覧制御が必要なら、別の分析ツールや専用システムも含めて検討します。JetEngineやCrocoblockが、セキュリティ設計やパフォーマンス調整を自動で全部解決するわけではありません。

この作り方が向いている人、向いていない人

向いているのは、Elementorで作ったサイトに、問い合わせ数、実績数、申込数のような小さな数値表示を足したい人です。毎月の数字を手作業で直していて、そろそろデータから表示したいと感じている場合は、JetEngineの考え方と相性がよいです。

向いていないのは、広告分析や売上予測、複数部門の権限管理まで含む本格的な管理画面をいきなり作りたいケースです。その場合は、データベース設計、権限、キャッシュ、外部分析ツールとの分担を別に考える必要があります。

管理画面での入力フローを決めておく

グラフを安定して動かすには、制作時の設定だけでなく、公開後に誰がどの順番で入力するかも決めておきます。問い合わせが届いたら、まず「問い合わせ」データを新規追加し、受付日、問い合わせ種別、流入元、対応状況を入れます。担当者が詳しいメモを書きたい場合でも、グラフに使う項目とは分けておくのが安全です。メモ欄にだけ「検索から来た」と書いても、Charts Builder側では扱いにくいからです。

小規模サイトなら、最初の運用ルールはかなり単純で構いません。たとえば、営業担当が問い合わせを受けた日に1件登録し、月末に管理者がグラフを確認します。未対応が多い月は、問い合わせ数だけではなく対応状況も見直します。このように、数字を見る目的を先に決めると、不要なフィールドを増やさずに済みます。

フィールド名も運用しやすさに影響します。内部名を date や type のように短くしすぎると、後で別のデータにも同じ名前を使いたくなります。今回なら received_date、inquiry_type、inquiry_source のように、何のデータか分かる名前にしておく方が見直しやすいです。

つまずきやすい設定と避け方

よくある失敗は、日付をテキストで保存してしまうことです。「2026年5月12日」のような文字列で入れると、人間には読めますが、月ごとの集計や期間指定では扱いにくくなります。受付日はDate型として持たせ、表示するときに日本語形式へ整える方が安全です。

もう1つの失敗は、1つのグラフに情報を詰め込みすぎることです。問い合わせ数、流入元、種別、担当者、受注率を1枚のグラフにまとめると、見た目は高度に見えても判断しにくくなります。最初のグラフは「月別問い合わせ数」だけにして、流入元別は別のカードや別のグラフに分けます。

また、グラフが表示されないときは、Charts Builderだけを見るのではなく、元データ、Query Builder、Elementor配置の順番で確認します。問い合わせデータがあるか、受付日が入っているか、クエリーが想定件数を返しているか、グラフウィジェットが正しいデータ元を見ているか。この順番にすると原因を切り分けやすくなります。

公開後に見るべき点

公開後は、グラフが表示されているかだけでなく、数字が運用感覚と大きくずれていないかを確認します。問い合わせが実際には10件あったのにグラフでは6件なら、登録漏れ、日付未入力、期間条件のミスが考えられます。逆に、同じ問い合わせを二重登録している場合もあります。

月末確認の手順としては、まず問い合わせ一覧で当月分を絞り込み、件数を確認します。次にグラフの当月件数と見比べます。最後に未対応の件数を確認します。この3つだけでも、静的なページで数字を貼り替えるより運用の見通しがよくなります。

ここまでを小さく回せるようになってから、流入元別、問い合わせ種別別、サービス別のグラフを検討します。最初から全部を作るより、実際に毎月見る数字だけを増やす方が、Elementor制作者にとってもクライアントにとっても管理しやすいです。

小さなサイトでの具体的な置き換え例

たとえば、これまで毎月の問い合わせ数を固定ページに「今月の相談件数」として手入力していたサイトなら、最初の置き換えはかなり小さくできます。問い合わせデータを1件ずつ登録し、月別グラフを1つ作り、ページ上部に今月の件数カードを置くだけです。ここまでなら、複雑な会員機能や外部連携を作らなくても始められます。

制作会社がクライアントに納品する場合は、入力担当者向けの簡単なルールも添えると運用が止まりにくくなります。「受付日を空にしない」「問い合わせ種別は選択肢から選ぶ」「テスト投稿は公開前に削除する」の3つだけでも、グラフの数字は安定します。見た目より先に入力ルールを整えることが、動的サイトではかなり重要です。

また、過去データを一気に入れるときは、最初から全期間を完璧に再現しようとしない方が安全です。まずは直近3か月だけ登録し、グラフが想定通りに出るか確認します。問題なく動いたら半年分、1年分と広げます。いきなり大量のデータを入れると、日付形式のミスや重複登録に気づきにくくなります。

最後に、クライアント確認用の説明文も用意しておくと安心です。「このグラフは問い合わせ登録の受付日をもとに自動で集計しています。数字が合わない場合は、ページではなく問い合わせデータの登録漏れを確認してください」と書いておけば、編集担当者がElementorのページ本文を直接直してしまう事故を減らせます。動的サイトでは、表示画面を直すのではなく、元データを直すという考え方に慣れてもらうことが大切です。

納品時には、グラフの見た目よりも入力手順、確認手順、戻し方を短くまとめます。誰が問い合わせを登録するのか、月末に誰が数字を見るのか、不要なテストデータをいつ消すのか。この3点が決まっていれば、小さなCharts Builder構成でも実務で使いやすくなります。

まとめ

JetEngine Charts Builderは、Elementorページに数字の変化を見せたいときに役立ちます。ただし、先に考えるべきなのはグラフの見た目ではなく、どのデータを、どの粒度で持たせるかです。

今回の月別問い合わせ数グラフなら、問い合わせというデータの箱を作り、受付日や種別を入力項目として分け、Query Builderで月別の件数を返し、Charts BuilderでElementorページに表示する流れになります。最初は小さく作り、運用で本当に必要な数字だけを増やしていくのが現実的です。

JetEngine公式ページを見てみる