JetEngine REST APIで外部データを表示する前に知るべきこと

記事内に広告を含みます

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

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

外部サービスのデータをWordPressサイトに表示したい、という相談はよくあります。たとえば店舗ごとの在庫、スクールの空き枠、外部システムにある商品情報などです。Elementorでページは作れるけれど、データを毎回コピーして貼り替えるのは避けたい。そこで候補に入るのが、JetEngineのREST API連携です。

この記事では、実APIの秘密情報を扱わずに、店舗在庫API風のデータを一覧表示する例で考えます。目的は、API連携を難しく見せることではなく、Elementorユーザーが外部データを表示する前に何を決めるべきかを整理することです。

今回のゴール

外部データから「店舗名」「在庫数」「更新日」「エリア」を受け取り、Elementorページに在庫カード一覧として表示する流れを作ります。実際の秘密キーや個人情報は扱わず、公開してよいデータだけを例にします。

JetEngine公式ページを見てみる

REST API連携で何を表示できるのか
JetEngine側でエンドポイントを作る前に決める項目
受け取ったデータを一覧テンプレートに整理する考え方
Elementor側で在庫カードとして見せる構成
秘密キー、個人情報、更新遅れで失敗しないための注意点

まず何を作るのか

今回作るのは、店舗在庫の簡易一覧です。複数店舗を持つスクールや小売店があり、外部システム側に「店舗ごとの空き枠」や「在庫数」があるとします。そのデータをWordPress側に取り込み、Elementorで作ったページにカード形式で表示します。

静的なElementorページだけで対応する場合、在庫数が変わるたびに担当者がページを開き、数字を直し、表示順を調整する必要があります。月に1回ならまだよいですが、週に何度も変わる情報では現実的ではありません。JetEngine REST API連携を使う場合は、外部データを受け取る入口を作り、その返ってきたデータを一覧表示に接続します。

REST API連携でJetEngineが担当すること

REST APIは、別のシステムからデータを受け取るための窓口のようなものです。JetEngineでは、REST API Listingsや関連機能を使って、外部から返ってくるデータをListing表示に接続する考え方が用意されています。

ただし、JetEngineがあれば外部システム連携の設計がすべて不要になるわけではありません。どのURLへアクセスするのか、認証が必要なのか、どの項目を表示するのか、エラー時に何を出すのかは、制作側で決める必要があります。ここで大事なのは、APIという言葉に引っぱられて難しいことを始める前に、公開ページに出してよい項目だけを選ぶことです。

[
  { "store_name": "渋谷校", "stock_count": 8, "updated_at": "2026-05-13", "area": "東京" },
  { "store_name": "横浜校", "stock_count": 0, "updated_at": "2026-05-13", "area": "神奈川" }
]

このJSONは説明用の例です。実際のAPI仕様は、接続先サービスのドキュメントに合わせて確認します。

JetEngine側で決める設定例

REST API連携では、先に「どのデータを受け取るか」を小さく決めます。店舗在庫一覧なら、最初は次の4項目で十分です。

表示名	データキー	表示用途	サンプル値
店舗名	`store_name`	カード見出し	渋谷校
在庫数	`stock_count`	在庫あり/なしの判断	8
更新日	`updated_at`	情報の新しさ	2026-05-13
エリア	`area`	地域ラベル	東京

エンドポイント名は store-stock のように分かりやすくし、取得方法は一般的な参照なら GET を使います。秘密キーが必要なAPIをそのまま公開ページのJavaScriptから呼ぶのは避けます。キーを扱うなら、サーバー側で安全に中継する設計が必要です。

受け取るデータを一覧テンプレートに整理する

APIからデータが返ってきても、そのままでは読者に見せる画面になりません。Elementor側で表示するために、一覧テンプレートを作ります。これは、1件分の店舗カードを作るイメージです。

カードには、店舗名、在庫状態、更新日、エリアを置きます。在庫数が0なら「在庫なし」、1以上なら「在庫あり」と表示できると読みやすくなります。Dynamic Fieldや表示条件を組み合わせると、数字の意味を読者に伝えやすくなります。

見出し: store_name を表示
ラベル: area を小さく表示
在庫表示: stock_count をもとに在庫あり/なしを表示
補足: updated_at を更新日として表示

最初から検索、並び替え、地図表示まで一気に作る必要はありません。まずは一覧カードが安定して表示されるかを確認します。表示が安定してから、必要に応じて絞り込み検索や地図表示を検討します。

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

Elementor側では、通常の固定テキストを並べるのではなく、JetEngineの一覧表示を置くイメージです。ページ上部に説明文を置き、その下に店舗カードを並べます。カードの中身は外部データから受け取った項目を表示します。

公開ページに出す場合は、更新日を必ず表示するのがおすすめです。外部データは取得できていても、元システム側の更新が止まっている可能性があります。読者にとっては、在庫数そのものだけでなく、その数字がいつの情報なのかも重要です。

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

REST API連携がうまくはまると、WordPress側で同じ情報を二重管理しなくてよくなります。外部システムが在庫数を持っているなら、その数字をWordPressに毎回手入力するより、表示だけをWordPress側で担当する方が自然です。

運用面では、情報の入口を1つに寄せられることが大きいです。店舗担当者は元システムを更新し、サイト側はその結果を表示します。Elementorページのデザインを調整したいときも、データそのものを作り直す必要はありません。API連携は一度つなげば終わりではないため、仕様変更、レスポンス遅延、空データ、メンテナンス停止も想定します。

任意の小さなJavaScript補助

標準のJetEngine設定で一覧が出るなら、コードを追加する必要はありません。もし公開ページで「外部データの取得状態」を軽く見せたい場合は、Elementor Custom Codeに小さなJavaScriptを置き、一覧エリアにカードが出ているかだけを見てメッセージを変える方法があります。

以下は、公開ページに data-stock-list という属性を付けた一覧ラッパーがある前提の例です。APIキーや個人情報は扱いません。表示補助だけのスクリプトです。

document.addEventListener('DOMContentLoaded', function () {
  const list = document.querySelector('[data-stock-list]');
  const status = document.querySelector('[data-stock-status]');
  if (!list || !status) return;
  const cards = list.querySelectorAll('.jet-listing-grid__item');
  status.textContent = cards.length > 0 ? '在庫情報を表示しています' : '現在表示できる在庫情報がありません';
});

配置場所はElementor Custom Code、または子テーマのJavaScript読み込みです。導入前にテスト環境で確認し、テーマやJetEngineの出力クラスが変わった場合はセレクタを見直してください。これがなくても一覧表示は成立します。あくまで読者向けの補助表示です。

公開してよいデータ、出してはいけないデータ

REST API連携で一番避けたいのは、秘密情報や個人情報を公開ページに出してしまうことです。店舗名、在庫数、更新日、エリアのように公開してよい情報だけなら扱いやすいですが、管理用URL、APIキー、担当者の個人連絡先、顧客情報は公開ページに出してはいけません。

また、表示条件だけで機密情報を守ろうとするのも危険です。画面に見えないだけで、データがHTMLやAPIレスポンスに含まれている場合があります。権限管理が必要なデータは、取得する段階から制御します。

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

最初の段階では、1つのAPIから在庫カードを表示するくらいに留めるのが安全です。複数APIを同時に呼ぶ、ログインユーザーごとに内容を変える、予約や決済と連動する、個人情報を含むデータを扱う、といった段階になると制作難度は一気に上がります。

JetEngine REST API連携は、Elementorサイトに外部データ表示を足すための強い選択肢です。ただし、セキュリティ設計、認証、キャッシュ、障害時の表示、個人情報保護を自動で解決するものではありません。ここから先は慎重にした方がいいです。

接続前に決める運用ルール

REST API連携では、技術的に接続できるかだけでなく、誰がデータ元を管理するのかを先に決めます。店舗在庫の例なら、在庫数を更新するのは店舗担当者なのか、本部なのか、外部システムなのかを確認します。WordPress側の制作者が毎回数字を直す運用なら、API連携の意味が薄くなります。

更新頻度も重要です。1日に何度も変わる在庫なのか、1日1回の更新で十分なのかによって、キャッシュや表示文言が変わります。頻繁に変わる情報なら「最終更新日」を目立たせます。あまり変わらない情報なら、更新タイミングを読者に伝えるだけでも十分です。

APIの返り値が空だった場合の表示も決めておきます。「現在表示できる在庫情報がありません」と出すのか、「店舗へお問い合わせください」と出すのかで、読者の行動が変わります。空データをエラーと扱うのか、在庫なしと扱うのかも、制作前に確認しておくべきです。

実装時につまずきやすいポイント

一番多いのは、APIから返ってくる項目名と、一覧テンプレートで参照する項目名がずれているケースです。API側が storeName を返しているのに、Elementor側で store_name を見ていれば表示されません。最初にサンプルレスポンスを保存し、表示に使う項目名を表にしてから作るとミスが減ります。

次に多いのは、数値を文字列として扱ってしまうことです。在庫数が "8" のような文字列で返る場合、条件表示や並び替えで期待通りに動かないことがあります。接続先の仕様で数値として返せるなら数値にし、難しい場合は表示だけに使うのか、条件にも使うのかを分けて考えます。

認証が必要なAPIも注意が必要です。公開ページのHTMLやJavaScriptに秘密キーを置くと、閲覧者から見える可能性があります。JetEngineの設定だけで安全に扱える範囲なのか、サーバー側の中継が必要なのかを必ず確認してください。ここを曖昧にしたまま本番公開するのは危険です。

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

たとえば、これまで店舗ごとの在庫状況を固定ページの表に手入力していたサイトなら、最初の置き換えは「在庫カード一覧」だけで十分です。外部データから店舗名、在庫数、更新日、エリアを受け取り、Elementor側ではカードを並べます。検索や地図表示は、一覧が安定してから考えます。

クライアントに説明するときは、API連携を難しい言葉で話すより「元システムの数字を、WordPressのページに読み込む仕組み」と伝える方が理解されやすいです。そのうえで、元システムが止まればサイト表示にも影響すること、項目名が変われば表示調整が必要なこと、秘密情報は公開ページに置かないことを共有します。

導入前のテストでは、通常データ、空データ、在庫ゼロ、更新日が古いデータの4パターンを用意します。通常データだけで確認すると、本番で「データがない日」に表示が崩れることがあります。REST API連携は、うまく取得できる時だけでなく、取得できない時の見せ方まで含めて設計するのが現実的です。

納品時には、API連携の責任範囲も短く書いておくと安心です。「WordPress側は受け取った公開データを表示する」「データの正しさは元システム側で管理する」「API仕様が変わった場合は表示調整が必要になる」という線引きです。ここを曖昧にすると、表示が崩れたときにWordPress、外部システム、運用担当のどこを確認すべきか分からなくなります。

また、公開ページには読者向けの一言を置くと親切です。「在庫情報は最終更新日時点の内容です」のように書くだけでも、数字が常にリアルタイムで保証されるという誤解を避けられます。REST API連携は便利ですが、読者に見せる情報としての説明責任も含めて設計する必要があります。

運用担当者には、表示が空になったときの一次確認も共有します。元システムにデータがあるか、APIのURLが変わっていないか、WordPress側の一覧テンプレートで参照している項目名が変わっていないか。この順番で見るだけでも、原因の切り分けが速くなります。制作側だけが仕組みを知っている状態にしないことが、API連携を長く使うための現実的な対策です。

小さく試してから広げるのが安全です。