Ownership
契約、決済、重要情報の管理主体はクライアント側に残す。
CASE STUDY 14 / ACCESS GOVERNANCE / COMMERCE
外部担当者へ、どこまで
管理権限を付与するべきか。
権限が狭すぎれば作業が止まり、広すぎれば所有権・機密情報・誤操作のリスクが増えます。最初から最大権限を渡すのではなく、必要な仕事から開始権限を決め、実作業で不足を確認し、段階的に調整する方法を検討します。
- THEME
- Access Governance
- CASE EXAMINED
- 京都御所西 小川金正堂
- SYSTEMS
- Shopify / Rakuten RMS
- EVIDENCE STATUS
- Audited / Publication Ready
CENTRAL QUESTION
安全性と作業可能性を、どう両立するか。
外部担当者へ最初から最大権限を渡すのでも、作業できないほど制限するのでもなく、必要な権限をどの時点で、何を根拠に決めるべきか。
CASE CONTEXT
二つの販売基盤へ、外部から入る必要があった。
楽天市場の商品構造を確認し、Shopifyを構築するため、外部担当者は楽天RMSとShopifyの双方へアクセスする必要がありました。
2026年2月16日、マスター権限でも作業可能だが、セキュリティの観点から個別アカウントを推奨しました。楽天RMSについては、当初使った「サブアカウント」という表現を、R-Loginでのスタッフアカウント追加という意味に訂正しています。
Shopifyでは2月19日に「オンラインストア編集者」で招待されました。当初はそのまま開始しましたが、実作業で権限不足と認証リクエストの発生を確認し、2月22日に対応案を提示しました。翌日、クライアントが一旦管理者を追加し、作業可能になりました。
ANALYSIS
権限名ではなく、実行する仕事から決める。
権限設計は、最も強い役割を選ぶことでも、最小権限という言葉だけを守ることでもありません。担当業務、情報感度、作業頻度、承認負荷を対応させる必要があります。
Work
外部担当者が実施する構築・商品・テーマ作業を先に特定する。
Friction
認証要求や作業停止を、権限不足を示す運用上の証拠として扱う。
Adjustment
不足が確認された時だけ、選択肢を示し、クライアント判断で変更する。
分析上の結論：安全な権限設計は「常に狭い権限」ではありません。独立アカウントで開始し、実際の仕事に必要な範囲を確認し、所有者の判断で段階的に変更できる状態です。
DECISION FRAMEWORK
開始・観察・変更・確認の四段階。
Separate
共有ログインではなく、主体を識別できる個別アクセスから始める。
Limit
予定している仕事に対応する開始権限を選ぶ。
Observe
実作業で、停止箇所、認証要求、不足機能を確認する。
Authorize
対応案とリスクを示し、所有者の判断で変更後の作業可否を確認する。
IMPLEMENTATION
CASEで行われた権限調整。
個別アクセスを依頼
Shopifyと楽天RMSについて、マスター権限の共有より個別アカウントを推奨しました。楽天側の呼称はR-Loginのスタッフアカウントへ訂正しました。
楽天RMSはスタッフ権限から開始
クライアントがスタッフ権限を了承し、R-Loginから登録申請。申請確認時点では、楽天RMSへのログイン完了とはしていません。
Shopifyはオンラインストア編集者で招待
クライアントが選んだ開始権限を確認し、当初は現状のままで開始する判断を伝えました。
実作業で不足を確認し、二案を提示
権限不足と認証リクエストの発生を報告し、マスター共有または必要権限を都度付与する段階方式を選択肢として示しました。
管理者追加後の作業可能状態を確認
クライアントが「一旦管理者を追加」と連絡。変更後、外部担当者側で作業を進められることを確認しました。
VERIFIED RESULTS
一次情報で確認できた権限運用。
CONFIRMED / SEPARATE ACCESS
楽天RMSはR-Loginのスタッフ登録から開始した
スタッフ権限の了承、登録情報の共有、登録申請、申請確認が時系列で残っています。
Evidence: S-R1 / 2026-02-16 20:57〜02-17 14:57
CONFIRMED / INITIAL ROLE
Shopifyはオンラインストア編集者で開始した
2026年2月19日、クライアントが当該権限で招待したことを報告しています。
Evidence: S-R1 / 2026-02-19 14:38
CONFIRMED / ACCESS FAILURE
実作業で権限不足が確認された
2026年2月22日、複数箇所で権限不足となり、その都度認証リクエストが発生したことが報告されました。
Evidence: S-R1 / 2026-02-22 14:07
CONFIRMED / ADJUSTED ACCESS
管理者追加後、作業可能になった
2026年2月23日、クライアントが一旦管理者を追加し、同日、外部担当者が作業を進められる状態を確認しました。
Evidence: S-R1 / 2026-02-23 11:17・15:32
FINDINGS
外部支援の権限を決める実務上の示唆。
個別アカウントを先に確保する
誰が操作したかを区別できる状態が、権限調整の前提になります。
開始権限を最終権限と考えない
予定作業から仮決定し、実作業で不足や過剰を確認します。
不足を具体的な作業事実で示す
「権限が欲しい」ではなく、停止箇所と必要操作を説明します。
変更判断を所有者へ戻す
外部担当者は選択肢を示し、クライアントが付与範囲を決めます。
LIMITS
このCASEが証明しないこと。
- 2026年2月22日のマスターアカウント共有は提案された選択肢であり、共有実施を示すものではありません。
- 「一旦管理者を追加」という原文は確認できますが、付与された個別権限の完全な一覧は確認していません。
- 管理者追加が恒久運用になったこと、作業終了後に権限を縮小・削除したことは確認していません。
- 楽天RMSについて、スタッフ登録後に付与された全機能・全操作範囲は本文で断定しません。
- 認証情報、管理画面、銀行・決済情報、顧客・注文情報は公開しません。
- 本記事は2026年2月の個別CASEです。Shopifyまたは楽天の現在・将来のプラン仕様や権限名称へ一般化しません。
EVIDENCE AUDIT
推奨・付与・不足・変更・利用を分ける。
| 主張 | 品質区分 | 根拠・処理 |
|---|---|---|
| 個別アカウントを推奨した | 提案事実 | S-R1、2026-02-16 19:18 |
| 楽天側をR-Loginスタッフ追加へ訂正した | 訂正・要件事実 | S-R1、2026-02-16 20:57 |
| R-Login登録申請を確認した | 申請確認事実 | S-R1、2026-02-17 10:56・14:57。ログイン完了とは分離。 |
| オンラインストア編集者で招待された | 付与事実 | S-R1、2026-02-19 14:38 |
| 権限不足と認証リクエストが発生した | 作業確認事実 | S-R1、2026-02-22 14:07 |
| 管理者追加後に作業可能になった | 変更・利用確認事実 | S-R1、2026-02-23 11:17・15:32 |
| 段階調整が安全性と作業可能性を両立する | 分析 | 開始権限、不足発生、変更、作業確認から導いた解釈 |
| マスターアカウントが共有された | 未確認 | 提案のみ。実施事実として書かない。 |
| 作業後に権限を撤回した | 未確認 | 撤回・削除記録がないため主張しない。 |
重要な識別：CASE STUDY 06は、必要な利用者構成と費用からプランを選ぶ研究です。本記事は、外部担当者へ実際に付与するアクセス範囲を、作業事実から調整する研究です。
公開範囲：権限の考え方、役割名、変更の時系列、作業可否のみを公開し、ID、パスワード、個人メール、管理画面、機密情報は掲載しません。
公開許可：2026年2月16日の実績公開許可と、2026年6月10日のPROJECT全体公開許可を確認しています。
判定：本文の事実主張はEvidence Audited。開始権限、不足、対応案、クライアントによる変更、作業可能確認まで原本追跡でき、未確認の共有・撤回を除外したPublication Readyです。