複数の運用担当者がいるWooCommerceストアでは、「管理画面へのアクセスを許可する」だけでは、誰が何をできるかを定義できません。サポート担当者には注文の閲覧が必要でも、返金は不要かもしれません。商品カタログの担当者は商品を編集できても、変更の公開はできない場合があります。また、「各チームが閲覧できる注文を制限する」といった業務ルールは、標準の権限に当てはまらないことがあります。
WooCommerceのロールと権限を設計するには、これらのレベルを区別し、操作とリソースを具体化したうえで、許可される操作と拒否される操作の両方を確認する必要があります。目的は、正当な業務を妨げたり、その場しのぎのルールに頼ったりせずに、業務に必要な最小限のアクセス権を付与することです。
ロール・権限・業務ルールを分ける
ロールは、特定のユーザー種別に対する権限をまとめたものです。権限（capability）は、商品編集やWooCommerceの特定設定の管理など、システムが許可できる操作を表します。ユーザーがどの権限を持つかはロールによって決まりますが、個々のルールをロールで代用すべきではありません。
利用できる権限は、WordPress、WooCommerce、インストール済みの拡張機能によって異なります。manage_woocommerce、view_woocommerce_reports、商品や注文に関連する権限などが見つかることがあります。名前だけから効果を推測せず、利用中の環境でどのように使われ、どの操作を可能にするのかを確認してください。
業務ルールは、一般的な権限だけでは表せない文脈を加えるものです。たとえば、担当者が自分のチームに割り当てられた注文は閲覧できても、他チームの注文は閲覧できないようにします。注文を編集する権限だけでは、リソースごとのこの制限は定まりません。また、アクセス制限と、ステータス変更の前に承認を必須にするといったワークフロー制御も混同しないでください。
権限を割り当てる前に操作とリソースを洗い出す
まず、各担当者が実際に行う業務を記述します。操作ごとに、対象リソースと関連する文脈を特定してください。「ストアを管理する」のような曖昧な分類は、見直しを難しくし、不要なアクセスを見えにくくしがちです。
- サポート：注文の閲覧、許可された情報の更新、メモの追加、または合意した手順に沿った返品処理の開始。
- 商品カタログ：商品の作成・編集、画像やカテゴリーの管理、必要に応じた変更の公開。
- 管理：担当範囲内での設定、ユーザー、財務処理の管理。
これらは出発点の例であり、普遍的な権限設定ではありません。役立つ権限マトリクスには、担当者、操作、リソースの種類、データの範囲、条件、期待される結果を記録します。また、操作が閲覧・作成・編集・公開・削除・エクスポートのどれに当たるか、取り消せない処理を実行するかも明確にしてください。
たとえば、「注文を閲覧する」には、すべての注文が対象なのか、割り当てられた注文だけなのか、個人情報の全項目を表示するのか、限定された表示なのかを明記します。「商品を編集する」には、価格、在庫、表示設定、公開ステータスの変更を含むかどうかを示します。具体化すれば、同じ権限をチームごとに異なる意味で解釈することを防げます。
リスクと文脈を考慮したマトリクスを作成する
担当者と操作の組み合わせごとに、許可、拒否、条件付きのいずれかを記入します。業務上の理由と、アクセス承認の責任者も追加してください。返金、価格変更、個人データのエクスポート、レコードの削除、決済や税の設定変更など、機密性の高い操作も含めます。
最低限、次の問いに答えられるマトリクスを作成します。
- プロセスを完了するために、どの操作が必要か。
- どの種類のリソースに適用され、どのレコードが対象範囲に含まれるか。
- チームへの所属や承認の取得など、条件があるか。
- 権限の誤用や不正利用があった場合、どのような影響が生じるか。
- 担当業務が変わったとき、アクセスをどのように見直し、取り消すか。
リスクのある操作を、同じ人が開始して承認すべきでない場合は、職務分掌を検討してください。WooCommerceやインストール済み拡張機能で分掌を実現できない場合は、その制約を記録し、明示的な対策を検討します。別のロールを作成しただけで解決したとみなしてはいけません。
各ルールの実装場所を選ぶ
まず、既存の権限が必要な操作を正確に表しているか確認します。該当する場合は、保守可能なツールや方法で適切なロールに割り当て、管理画面と関連する操作経路で結果をテストしてください。他の拡張機能が付与する権限も確認します。実効権限には、複数の提供元の権限が累積することがあります。
新しい権限が必要な場合や、注文に割り当てられたチームなど具体的なデータに依存する場合は、場当たり的にテーマを変更せず、独自の拡張機能または保守可能なコンポーネントに実装します。テーマは表示を制御するものです。認可処理をテーマに結び付けると、テーマの変更時にルールが失われたり、場所の特定やテストが難しくなったりするおそれがあります。
実装では、ボタンを隠すだけでなく、操作が実行される箇所でアクセスを検証してください。選択肢を隠すとインターフェースは使いやすくなりますが、それだけでは直接リクエストによる保護対象の操作を防げません。リソースに関するルールでは、ユーザーがその特定のレコードに対して操作できることも確認します。一般的な権限の確認と、リソースの対象範囲の確認は分けてください。
連携が想定どおりに動かないからといって、広範な権限を付与して埋め合わせるのは避けます。権限を広げる前に、どのチェックが失敗しているのか、どのコンポーネントがチェックしているのか、その操作を許可すべきなのかを特定してください。広範な例外を設けると、意図した範囲を超える画面や操作が有効になる可能性があります。
許可される操作と拒否される操作をテストする
テストでは、設定にロールが表示されることだけでなく、実際の動作を確認します。対象となる担当者ごとにテストケースを作成し、許可される操作、禁止される操作、文脈による制限を検証してください。注文の状態、チーム、その他の条件に依存する操作では、条件を満たすケースと満たさないケースの両方を確認します。
- サポート担当者は許可された注文を閲覧でき、対象範囲外の注文は閲覧できない。
- 商品カタログ担当者は指定された項目を編集できるが、許可がなければ注文やストアの設定にはアクセスできない。
- 権限のないユーザーは、ボタンが表示されていなくても、URLや直接リクエストから操作を完了できない。
- 機密性の高い操作が期待どおりの結果になり、定義済みの承認や制限を迂回しない。
各担当者のアカウントと、関連する制限を反映したデータを用意し、本番環境を適切に再現するテスト環境で確認してください。注文、商品、ロールに関わるWooCommerce、WordPress、拡張機能を更新した後も、テストケースを再実行します。期待される結果と実際の結果を記録し、将来の変更で意図せずアクセスが再び許可されることを防いでください。
運用への影響を確認し、変更を監査する
権限を厳しくしすぎると、サポート担当者が注文を見つけられない、商品カタログ担当者が緊急の修正を公開できないなど、業務が滞ることもあります。変更をデプロイする前に、一時的なアクセスの申請方法、承認者、取り消し方法を決めてください。画面単位の確認だけでなく、実際に業務を行う人と一緒に一連のワークフローを確認します。
各権限を付与するロール、アクセスをさらに制限するルール、それらを実装するコンポーネントを記録します。ロールと権限の変更について、担当者、理由、日付を含む記録を残し、不要になったアカウントのアクセスを定期的に見直してください。予期しない拒否が起きた場合は、権限を広げる前に、実効権限、リソースに関するルール、関連する拡張機能、リクエストの文脈を調査します。
WooCommerceで堅牢なロールと権限を設定するには、検証可能な操作から始め、保守できる場所に業務ルールを保持し、誰が何をできるかをテストで実証します。これにより、運用上の問題が起きるたびにアクセス権を恒久的に拡大することなく、ストアを保護できます。
