Webサイトのお助け隊

会員限定ページを作りたい、という相談で最初に確認するのは、技術の話ではありません。「その会員は、誰がどうやって増えるのか」です。自分で登録させるのか、こちらが手で登録するのか、申し込みを見て承認するのか。ここが決まっていないまま会員管理の仕組みを作ると、ログイン機能は動くのに運用が回らない、という結果になります。会員制の構築は、閲覧制限そのものより、その周りにぶら下がる登録・承認・通知・決済のほうが分量を食う仕事です。どこまでを作り、どこを既製の仕組みに任せるかで、費用は一桁変わります。

「会員制」は3つの水準に分かれる

会員限定と一口に言っても、実現の仕方には段階があります。どれを選ぶかは、会員数でも予算でもなく「会員ごとに見せるものを変える必要があるか」で決まります。

判定を作らないという選択肢

いちばん上の行を軽く見ないでください。会員価格とビジター価格を出し分けたい、という要件に対して、会員判定の仕組みをまったく作らずに解決した案件があります。やったのは、会員向けのページとビジター向けのページを分けて、それぞれに別の価格のボタンを置いただけです。判定を実装していないので、開発費もかからず、壊れる箇所もありません。

もちろん穴はあります。ビジターが会員ページのURLを直接踏めば、会員価格で購入できてしまう。これは技術で塞げない以上、リスクとして明示したうえで、その運用でよいかを決めてもらうものです。逆に、価格の違うボタンを同じページに並べる設計のほうが、誤って安い方を押されたときの返金対応という運用コストを生みます。技術的にできるかではなく、運用で事故るかどうかを基準にして構成を選ぶ場面です。

承認フローは既製プラグインで足りる

「申し込みを見てから会員として有効にしたい」という要件は、会員登録プラグインの標準機能で満たせることが多いです。登録されたユーザーを未承認の状態で保留し、管理者が承認して初めてログインできるようにする、という動作は wp-members のようなプラグインが持っています。会員制の相談を受けたとき、独自実装に入る前に真っ先に確認する選択肢です。

「ログインしていない人には会員登録画面しか見せたくない」という要望も、同じくリダイレクト制御で実装できます。functions.php で未ログインのアクセスを規約ページや登録ページへ飛ばす処理を入れるだけで、専用の仕組みは要りません。

ただし承認制には運用上の落とし穴があります。承認漏れが、そのまま「登録したのにログインできない」という問い合わせになります。新規登録時に管理者へ通知メールが飛ぶ設定になっているか、承認する画面がどこにあるかを、運用開始前に必ず担当者へ案内してください。もう1つ、規約への同意を挟む場合は、同意した日時をログとして残すかどうかを先に決めます。チェックボックスを通過させるだけの実装だと記録が残らず、後から「同意していない」と言われたときに示すものがありません。

独自テーブルで組むときの形

会員をグループに分け、グループごとに見せるコンテンツを変える。この要件が入った時点で、WordPressの標準ユーザーの枠には収まりません。企業向けの会員専用コンテンツシステムを構築した案件では、WordPress標準のユーザーとは独立した会員管理を、独自テーブルと独自のセッションで実装しました。テーブルは5つです。

<code>members              会員そのもの
groups               グループ
member_group         会員とグループの中間テーブル
group_content_access グループと閲覧可能コンテンツの中間テーブル
email_templates      通知メールの文面</code>

要はどちらの関係も多対多だ、という話です。1人の会員が複数のグループに所属することがあり、1つのコンテンツが複数のグループに開放されることもある。この2つを中間テーブルで持つ構造が、グループ単位の閲覧制限を作るときの標準形になります。会員テーブルにグループ名の列を1つ足すだけの設計は、必ず後から破綻します。逆に、この形にしておけば「あるグループにこのカテゴリーを追加」という運用が管理画面の操作だけで完結します。業務データをカスタム投稿タイプで持つか独自テーブルで持つかという判断は、カスタム投稿タイプと独自テーブル、業務データはどちらで持つかで整理しています。

この案件でもう1つ入れたのが、通知メールの文面をデータベースに持たせて管理画面から編集できるようにする仕組みです。%company_name% のようなプレースホルダを用意しておけば、会員名や会社名は差し込みで解決します。文面を1文字変えるたびに開発の依頼が発生する状態は、運用が始まった途端に負担になります。ここを最初に外へ出しておくと、その後の細かい発注が消えます。

決済をどこに置くか

会員制と決済は、同時に相談されることが多い割に、設計上は分けて考えたほうがうまくいきます。判断の分かれ目は、扱う商品と価格の数です。単一の商品を単一の価格で売るだけなら、決済処理を自作したほうが早く終わります。メールの文面も、決済後のリダイレクト先も自由に決められます。

問題は、商品や価格が増えたときです。金額をコードに直接書いた実装は、2つ目の価格が出てきた時点で破綻します。実際に、自作した決済処理が価格の追加で行き詰まり、最終的にダウンロード販売プラグインへ全面移行した案件があります。商品が増える、価格が複数になる、と分かった時点で既製の決済基盤へ寄せるのが総額としては安く付きます。

ただし既製の基盤にも守備範囲があります。ダウンロード販売を前提としたプラグインは、決済完了後すぐ動画のURLへ飛ばす、といった柔軟なフローに制約があり、メールでURLを渡す形に迂回することになりました。会員向けに何を提供するのか——ファイルなのか、閲覧権なのか、視聴なのか——によって向き不向きが変わるので、プラグインを決める前に提供物の形を確定させてください。

膨らむのは会員機能ではなく、その周り

フルスクラッチで会員機能を作った案件で最も苦労したのは、閲覧制限そのものではありませんでした。承認フロー、通知メールの文面、一覧画面でのクイック編集、ログイン状態の管理。要件定義書が5版まで増えています。会員機能は「登録して、ログインして、見せる」の3つに見えますが、実際には登録の前後と、ログインできなかったときと、管理側の操作が全部ぶら下がってきます。

ここを見誤らないための実務的な対処は、要件定義のフェーズと実装のフェーズで、期間と費用を分けて契約することです。数十万円規模の会員システムの要件を、テキストのやり取りだけで詰めるのは現実的ではありません。画面を並べて話す場を一度設け、その日に決まったことを必ず文章に落として双方の手元に残してください。後から「そう決めたはずだ」を確認できる形が残っていないと、仕様変更なのか認識違いなのかを判定できなくなります。

外部システムとの連携も、後から足すと高く付く項目です。会員が登録された時点で他のサービスへ通知したい、という要件は Webhook で繋ぐことになりますが、これは会員データの持ち方が決まって初めて設計できます。連携の予定があるなら、最初のテーブル設計の段階で伝えてください。

作ったあとに誰が触るのか

独自の管理画面を作った案件では、納品時に操作マニュアルを用意しました。標準のWordPressと違って、管理画面の使い方を調べても情報が出てこないためです。同じ理由で、依頼者自身が変更できる箇所とその手順を明記して渡すことも欠かせません。ボタンの文言や金額を自分で変えられる状態にしておくと、以後の細かい依頼が発生しなくなります。

逆に言えば、独自実装を増やすほど「触れる人が限られる資産」が増えます。既存の古い仕組みを抱えたまま会員機能を足すのか、この機会に整理するのかという判断についてはEC-CUBE・CakePHP・Movable Typeの古いシステム、延命か作り直しかも併せてご覧ください。会員向けに請求書や明細を出したい場合の作り方は請求書と見積書をWebで発行する仕組みを小規模向けに作るにまとめています。

よくある質問

会員数が数十人なら、手作業で登録してもよいですか

問題ありません。むしろ登録フォームと承認フローを作らないぶん、初期費用も障害点も減ります。判断の目安は、登録の頻度と、登録を担当する人の手が空いているかです。毎日数件入るなら自動化する価値がありますが、月に数件なら管理画面から手で追加するほうが安上がりです。

WordPressの標準ユーザーで会員を管理してはいけませんか

いけないということはありません。会員を分類する必要がなく、見せる・見せないの2値で足りるなら標準のユーザーと権限で十分です。切り替えを検討すべきなのは、グループごとに見せるコンテンツを変えたい、会員ごとに独自の項目を持ちたい、外部システムと会員情報を同期したい、のいずれかが出てきたときです。

会員ページのURLを知られたら見られてしまいますか

判定を実装していない構成であれば、その通りです。閲覧制限をかけている場合でも、ページ本体は保護されていても添付ファイルの直URLは保護されない、という抜けがよくあります。PDFや動画を会員限定にするなら、ファイルの直接アクセスを .htaccess で制限するところまでを含めて設計してください。

費用はどのくらい見ておけばよいですか

判定を作らない構成なら、既存サイトへのページ追加と同程度です。既製の会員登録プラグインで承認制を組む場合は、設定と検証が中心になります。独自テーブルと専用管理画面を作る規模になると、要件定義だけで別途の工程になり、数十万円の単位に変わります。この差は機能の数ではなく、会員をどう分類したいかで決まります。