会員サイトはログイン画面より「権限表」が重要です

CodexやClaude Codeを使えば、WordPressに会員登録やログイン画面を用意できます。

ただし、実務で重要なのはログインできることではありません。利用者ごとに、閲覧・登録・変更できる範囲を分けることです。

【最初に分ける利用者】

・一般会員

・法人やグループの担当者

・運営担当者

・サイト管理者

同じログイン利用者でも必要な操作は異なります。「担当者は管理できる」のような曖昧な表現ではなく、機能ごとに閲覧・作成・更新・削除を整理します。

【本人のデータと他人のデータを分ける】

一般会員がプロフィールを更新できても、他会員の情報まで変更できてはいけません。法人担当者も、自社メンバーだけを扱える設計が必要です。

役割だけでなく、本人のみ、同じ法人やグループのみ、運営対象全体、管理者のみ、というデータ範囲を定義します。

【REST APIにも同じ制限を適用する】

画面から編集ボタンを消しただけでは十分ではありません。REST APIへ直接要求された場合も、本人確認と権限判定を行います。未ログイン、別会員、別法人、停止済み会員など、拒否すべき条件もテストします。

【AIへ渡す実装手順】

1. 利用者の種類を整理する

2. 機能とデータを一覧化する

3. 閲覧・作成・更新・削除の権限表を作る

4. 本人・自社・全体の範囲を定義する

5. 画面とREST APIの判定を実装する

6. 権限不足のテストを行う

7. 権限変更と退会の履歴を残す

「会員サイトを作って」だけでなく、「一般会員は自分の申請だけ更新できる」と具体的に伝えると、CodexやClaude Codeが実装条件を判断しやすくなります。

WordPressにはユーザー、ロール、権限の仕組みがあります。無料プラグインで会員登録やプロフィール機能を補いながら、標準REST APIと組み合わせて独自の会員サイトへ拡張できます。

重要なのはプラグインを増やすことではなく、誰が何をできるかを先に決めることです。権限表を共通仕様として残せば、予約、EC、求人、学習サイトなどへ展開するときも同じ判断基準を再利用できます。