JetEngineで会員サイトを作る前に決めるべき設計

jetengine-member-site-design-thumbnail

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

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

会員サイトは、Elementorで見た目を作るだけならそれほど難しく見えません。ログイン後のページを作り、資料一覧を置き、会員向けのお知らせを並べる。けれども本当に難しいのは、ページのデザインよりも「誰に何を見せるのか」を先に決める部分です。

この記事ではJetEngineを中心に、会員別に資料ページを見せ分ける小さな会員サイトを例にします。決済や高度な学習管理システムを作る話ではありません。Elementorで作ったマイページに、会員種別ごとの資料一覧を表示するためのデータ設計を考えます。

この記事の結論

会員サイトでは、最初に「会員」「資料」「会員種別」「表示条件」を分けて考えます。JetEngineは資料データ、一覧テンプレート、表示条件、プロフィール画面づくりに使えますが、個人情報保護、権限、決済、監査ログまで自動で解決する道具ではありません。

JetEngine公式ページや関連ドキュメントでは、動的なデータ構造、Listing Grid、Profile Builder、Dynamic Visibility、Query Builderなどが紹介されています。会員サイトでは、これらを全部一気に使うより、まず「会員向け資料をどう登録し、どう表示するか」に絞る方が進めやすいです。

JetEngine公式ページを見てみる

JetEngineで会員サイトの会員と資料を分けて設計する全体像

この記事で分かること

  • 会員サイトを作る前に決めるべき情報の分け方
  • 資料ページCPTと会員種別フィールドの具体例
  • Elementorでマイページと資料一覧を表示する流れ
  • Dynamic Visibilityを使うときの注意点
  • 会員情報や決済まで広げる前に慎重にする境界線

まず何を作るのか

今回作るのは、ログインした会員が自分向けの資料を見られる小さなマイページです。資料のデータの箱(CPT)は member_resource、管理画面の表示名は「会員向け資料」とします。1件の投稿が1つの資料ページです。PDFや動画URL、閲覧対象の会員種別、公開期限を入力し、Elementorのマイページに一覧表示します。

想定する会員種別は、一般会員、プレミアム会員、講座受講者の3つです。資料ページには「どの会員種別に見せるか」を入力します。Elementor側では、ログイン中のユーザーにだけマイページを見せ、会員種別に合った資料一覧を表示します。最初はここまで分かれば十分です。

ここで迷いやすいのは、会員情報をWordPressユーザーの項目として持つのか、別の会員CPTとして持つのかです。ログイン機能と本人確認が必要なら、基本はWordPressユーザーを軸に考えます。一方で、公開プロフィールや社内管理用の補足情報を見せたい場合は、別のデータ構造を足すこともあります。最初から両方を複雑にしない方が安全です。

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

会員サイトでまず作るのは、会員向け資料CPTです。資料そのものを固定ページで増やすと、一覧化や見せ分けがつらくなります。資料を1件ずつCPTに入れておくと、会員種別、公開期限、カテゴリ、表示順で扱いやすくなります。

画面ラベル フィールド名 サンプル値 使い道
資料タイトル 投稿タイトル Title 初回設定ガイド 一覧と詳細見出し
資料カテゴリ resource_category Select 導入資料 一覧の分類
対象会員種別 allowed_member_type Checkbox / Select premium 表示条件
資料ファイル resource_file Media guide.pdf ダウンロードリンク
動画URL resource_video_url URL 限定動画URL 詳細ページ
公開期限 resource_expires_on Date 2026-06-30 見直し・非表示判断
表示順 resource_order Number 10 一覧の並び順

個人情報は最小限にするのが前提です。資料ページ側に会員の氏名、メールアドレス、購入履歴のような情報を混ぜないでください。資料データは資料データ、ユーザー情報はユーザー情報として分けます。入力欄を増やすほど便利に見えますが、管理する責任も増えます。

会員向け資料CPTと会員種別の入力項目の例

会員種別は、ユーザー側に持たせる必要があります。たとえばユーザーメタとして member_type を作り、値を generalpremiumstudent のようにします。見た目のラベルは日本語でも、内部値は揺れにくい英小文字にしておくと、条件設定で扱いやすいです。ただし、ユーザーメタの編集画面を誰が触るのかは事前に決めておきます。

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

Elementor側では、まずマイページの枠を作ります。上部に「会員情報」、中央に「資料一覧」、下部に「次に見るもの」や問い合わせ導線を置く程度で十分です。資料一覧は、1件分の一覧テンプレート(Listing Item)を作り、Listing Gridで繰り返し表示します。

資料カードの構成例は、資料タイトル、資料カテゴリ、短い説明、公開期限、詳細ページへのリンクです。資料ファイルへ直接リンクする場合は、公開範囲を慎重に確認します。ファイルURLを知っていれば誰でも見られる状態になっていないか、ダウンロードリンクを検索エンジンに拾わせないか、ここは少し立ち止まるところです。

Elementorのマイページに会員向け資料一覧を表示する構成

マイページ全体は固定ページで作ってもよいですが、会員ごとに表示内容を変える部分は動的にします。固定テキストで「プレミアム資料はこちら」と書くだけでは、一般会員にも見えてしまう可能性があります。表示条件とクエリの考え方を分けて、見せる一覧そのものを絞る設計にします。

表示条件で出し分ける前に決めること

Dynamic Visibilityは、条件に合うときだけブロックを表示する仕組みです。たとえばログイン中のユーザーだけにマイページの資料エリアを見せる、会員種別がプレミアムのときだけ「プレミアム資料」ブロックを見せる、といった使い方ができます。

ただし、表示条件は「見た目の表示制御」です。セキュリティ設計そのものではありません。HTMLに出力されていないか、ファイルに直接アクセスできないか、キャッシュで別ユーザーに表示されないか、検索結果やサイトマップに混ざらないかを確認します。初心者ほど「隠れているから大丈夫」と考えがちですが、そこは危ないです。

ログイン状態と会員種別で資料表示を出し分ける条件設計

Query Builderを使う場合は、資料CPT member_resource を対象にし、allowed_member_type が現在のユーザーの member_type と一致するものを表示します。マクロやユーザーメタを使う設定は環境や実装方法によって変わるため、公式ドキュメントの該当設定を見ながらテストします。最初は会員種別ごとに固定の資料一覧を分け、動きが分かってから動的クエリに寄せるのも現実的です。

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

静的なElementorページでは、資料が増えるたびにマイページを開き、カードを複製し、リンクを貼り直します。一般会員向け、プレミアム会員向け、受講者向けの資料が混ざると、更新漏れや誤表示が起きやすくなります。

JetEngineで資料CPTを作ると、担当者は「会員向け資料を追加」画面から資料を登録します。対象会員種別を選び、公開期限を入れ、資料ファイルや動画URLを保存します。Elementor側は一覧テンプレートを使うため、見た目を毎回作り直す必要がありません。運用面では、資料の追加とページデザインを分けられるのが楽になります。

会員向け資料を登録してマイページに反映する運用フロー

もう一つの利点は、期限切れ資料の見直しです。resource_expires_on を入れておけば、月に一度、期限が近い資料を確認する運用を作れます。自動非表示まで最初から作らなくても、管理画面で「期限順に並べて確認する」だけで十分役立つことがあります。小さく始めるなら、このくらいの運用からでよいです。

任意のPHP:非ログイン時だけログインページへ送る

マイページへの入口を作るだけなら、WordPressや会員系プラグインの設定で制御できる場合があります。もし固定ページ member-documents に非ログインユーザーが来たときだけログインページへ送る程度なら、短いPHPで補助できます。これは標準設定の代わりではなく、入口の補助です。

配置場所はCode Snippetsプラグイン、または子テーマの functions.php です。ページスラッグは自分のサイトに合わせて変更してください。決済、購入判定、会員ランク判定まではこのスニペットで扱いません。

add_action( 'template_redirect', function () {
    if ( ! is_page( 'member-documents' ) ) {
        return;
    }

    if ( is_user_logged_in() ) {
        return;
    }

    wp_safe_redirect( wp_login_url( get_permalink() ) );
    exit;
} );

このコードは、非ログインユーザーをログインページへ送るだけです。資料ファイルそのものの保護、会員種別ごとの閲覧権限、決済状態の確認は別に設計してください。スニペットを入れる前にバックアップを取り、エラーが出たらすぐ無効化できるようにします。

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

会員サイトが複雑になる境界は、個人情報、決済、権限、履歴管理が絡み始めるところです。たとえば、会員ごとの購入履歴、個別契約書、請求書、住所、電話番号、本人確認書類を扱うなら、JetEngineの表示設定だけで考えるべきではありません。保存範囲、アクセス権限、削除ルール、プライバシーポリシー、バックアップ、監査ログまで確認します。

Profile Builderで会員のアカウントページを作る場合も、公開プロフィールなのか、本人だけが見る設定画面なのかを分けます。プロフィール編集フォームを置くなら、入力値の検証、スパム対策、権限確認も必要です。JetEngineやCrocoblockは会員サイト作りの部品になりますが、セキュリティ設計を丸ごと肩代わりするものではありません。

会員サイトで小さく始める範囲と慎重に設計する範囲

会員種別を増やす前に運用を決める

会員サイトでよく起きるのは、会員種別を増やしすぎる問題です。一般会員、プレミアム会員、受講者、卒業生、法人会員、紹介会員のように細かく分けると、一見きれいに管理できそうに見えます。けれども、資料を登録するたびに「どの会員種別へ見せるのか」を判断する必要が出ます。運用担当者が迷うなら、その分類はまだ早いかもしれません。

最初は、見せる資料が明確に違う2〜3種類に絞るのが現実的です。たとえば「無料会員」「有料会員」「講座受講者」までです。会員種別を増やしたくなったら、先に資料の棚卸しをします。本当に別の資料が必要なのか、同じ資料を別の順番で見せればよいのか、単なるタグで足りるのかを確認します。

会員種別の内部値も早めに決めます。表示ラベルは「プレミアム会員」でも、内部値は premium のように揺れない値にします。あとから「Premium」「paid」「有料」のように表記が混ざると、表示条件やクエリの設定で混乱します。これは小さなことですが、運用が続くほど効いてきます。

公開前に確認したいテストパターン

会員サイトは、ログインしている画面だけ見て安心しない方がいいです。最低でも、非ログイン、一般会員、プレミアム会員、会員種別が未設定のユーザーで確認します。一般会員にプレミアム資料が見えていないか、非ログイン時にマイページの中身が見えていないか、未設定ユーザーに変な空欄だけ出ていないかを見ます。

資料ファイルの扱いも確認します。マイページ上のボタンを隠しても、ファイルURLを直接開ける状態なら、見せ分けとしては弱いです。重要な資料を扱うなら、ファイルの保存場所、アクセス制御、ダウンロード履歴、リンク共有への対策を別に考えます。単なるお知らせPDFならそこまで厳密でなくてもよい場合がありますが、判断は内容によります。

キャッシュも見落としやすいです。ログインユーザーごとに表示が変わるページを強くキャッシュすると、別のユーザー向け表示が残ることがあります。使用しているキャッシュプラグインやサーバーキャッシュで、マイページを除外する必要があるか確認します。ここは見た目の問題ではなく、会員サイトとしての信頼に関わる部分です。

さらに、退会や会員期限切れの扱いも先に決めます。退会したユーザーを削除するのか、ログイン不可にするのか、過去の問い合わせ履歴を残すのか。これはJetEngineの画面作成だけでは決まりません。資料ページの表示条件だけを整えても、ユーザー管理の運用が曖昧だと後で困ります。

資料の更新日も表示しておくと、会員側の不安を減らせます。resource_updated_note のような短いテキスト欄を作り、「2026年5月版」「手順3を修正」のように書けるようにしてもよいです。すべてを自動化しなくても、更新履歴が少し見えるだけで、古い資料なのか新しい資料なのか判断しやすくなります。

問い合わせ導線も忘れずに分けます。資料カードの下に毎回同じ問い合わせボタンを手入力するより、マイページ下部に共通の相談導線を置く方が管理しやすいです。会員別の相談先を変えるなら、表示条件でブロックを分ける前に、誰が返信するのか、どのフォームに送るのかを決めておきます。

会員サイトは、作った後の問い合わせ対応まで含めて設計すると現実的になります。「資料が見えない」「ログインできない」「期限が切れているはずなのに見える」といった質問が必ず出る前提で、管理者が確認する画面を用意します。会員種別、最終ログイン、閲覧期限、問い合わせ先を一目で確認できるだけでも、運用時の混乱はかなり減ります。

逆に、最初から完全な自動判定を目指すと重くなります。まずは資料CPTと表示条件で小さく作り、会員数や資料数が増えてから、通知、期限切れ処理、購入履歴連携を検討する。段階を分ける方が、初心者向けのElementorサイト制作では扱いやすいです。

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

向いているのは、Elementorで会員向け資料ページや講座受講者向けのマイページを作りたい人です。資料の追加が多く、毎回固定ページを編集するのがつらい場合、資料CPTと一覧テンプレートの組み合わせは分かりやすいです。

向いていないのは、最初から本格的な学習管理、サブスクリプション決済、購入履歴連動、個人ごとの契約書管理、権限の細分化まで作りたいケースです。その場合は、会員管理プラグイン、決済サービス、カスタム開発、セキュリティレビューを含めて考えます。無理にJetEngineだけで完結させようとしない方が安全です。

作る前に確認したいこと

公式プラグインと有効なライセンスを使い、アップデートを維持してください。会員ページはテスト環境でログイン状態、非ログイン状態、会員種別ごとの表示を必ず確認します。個人情報は最小限にし、ファイルURLへの直接アクセス、キャッシュ、検索インデックス、権限設定を別途チェックします。

まとめ

JetEngineで会員サイトを作る前に決めるべきなのは、どのページを作るかよりも、誰に何を見せるかです。今回の例では、会員向け資料CPT member_resource を作り、資料カテゴリ、対象会員種別、資料ファイル、公開期限を持たせました。Elementor側ではマイページと資料カードを作り、Listing Gridと表示条件で見せ方を整えます。

小さく始めるなら、一般会員とプレミアム会員の2種類、資料カテゴリは2〜3個、表示条件も最小限で十分です。決済、個人情報、契約管理、監査ログまで入れるなら、別の設計が必要です。静的ページから一歩進めるときほど、最初の線引きが後から効いてきます。

JetEngine公式ページを見てみる