EC管理画面の設定変更を属人化させない｜権限マップ・変更台帳・公開確認をチームで回す方法（Shopify・ecforce対応）

設定変更を「画面を知る人の仕事」にしない

送料、決済、商品公開、クーポン、配送条件、通知メール、外部サービス連携など、ECの管理画面には売上や購入体験に直結する設定があります。一方で、すべての作業者に広い権限を渡すと、意図しない変更が購入導線や受注処理に及ぶ範囲も広がります。反対に、権限を必要以上に絞ると、確認待ち・作業待ちが発生します。

この両方を避けるには、「誰が操作できるか」だけを決めるのでは不十分です。次の3点を同じ単位で管理します。

1. 権限マップ：役割ごとに、閲覧・作成・編集・公開・削認のどこまでを許可するか
2. 変更台帳：何を、なぜ、いつ、誰が、どの値からどの値へ変えるか
3. 公開確認：変更後に、管理画面・実際の購入画面・受注データのどこを誰が確認するか

対象は、管理画面の設定だけに限りません。テーマ、アプリ、プラグイン、独自改修の設定値を変更する場合も、同じ枠組みで扱えます。ただし、コードのデプロイやアプリ導入は、検証環境・リリース手順・契約上の権限など別の管理が必要です。本記事の台帳は、それらを置き換えるものではなく、設定変更の判断と証跡をそろえるための土台です。

変更対象を4段階で分類し、必要な承認と確認を決める

台帳の前に、変更の影響度を分類します。同じ「設定変更」でも、商品説明の誤字修正と決済手段の停止では、必要な確認が異なります。

この表は、変更を禁止するためのものではありません。承認者が不在の場合、C・D区分をいつまで保留するか、緊急時に誰が代行承認するかも決めておくことが重要です。障害対応などの緊急変更では、事前承認が難しいことがあります。その場合は、実施時刻、実施者、変更理由、暫定措置、事後確認者を台帳へ追記し、通常の変更より短い周期でレビューします。

影響範囲は「画面」ではなく「業務結果」で書く

「配送設定を変更」のような記載では、確認するべき結果が分かりません。次のように、購入者・受注担当者・外部連携先に起きる結果へ分解します。

• 購入者：カートで選択できる配送方法、表示される送料、決済可能な手段は変わるか
• 受注担当者：注文一覧の情報、出荷指示、同梱物、取消・返金の手順は変わるか
• 顧客対応担当者：問い合わせ時に案内する条件、テンプレート、例外対応は変わるか
• 外部連携先：OMS、倉庫、広告計測、会計、CRMへ渡す項目やタイミングは変わるか

この書き方なら、設定画面の場所を知らない承認者でも、判断に必要な情報を確認できます。

権限マップは「人」ではなく「役割」から作る

個人名を並べて権限を設計すると、異動・退職・委託先変更のたびに設計が崩れます。先に業務上の役割を定義し、その役割へ必要最小限の権限を割り当てます。

権限マップには、各役割について次の列を追加します。

• 利用するEC基盤のロール名、または付与する権限名
• 閲覧、編集、公開、承認の可否
• 申請が必要になる変更区分（A〜D）
• 代替担当者
• 権限を見直すタイミング

見直しの契機は、定期棚卸しだけではありません。担当変更、業務委託の開始・終了、利用アプリの追加、受注フローの変更があった時点で、対象者と不要権限を確認します。共有アカウントを使うと、操作した本人を特定しにくくなり、退職・契約終了時の無効化も不完全になり得ます。原則として個別アカウントを使い、役割に対応したロールを割り当てます。

変更台帳は「復元できる情報」と「確認した証跡」を残す

台帳はスプレッドシート、チケット管理ツール、社内データベースのいずれでも構いません。重要なのは、完了報告だけでなく、変更前に起票し、復元と確認に使える項目を持たせることです。

最低限の変更台帳テンプレート

変更ID：EC-2025-001
起票日・実施予定日時：
対象基盤・ストア：Shopify／本番ストア名
変更区分：A・B・C・D
対象機能・設定画面：
変更目的：
影響する業務結果：購入画面／注文処理／顧客通知／外部連携
変更前の値・状態：
変更後の値・状態：
実施手順または参照手順：
復元方法・復元に必要な値：
実施者／承認者：
必要権限：
テスト内容・期待結果：
公開後確認の担当者・期限：
確認結果・証跡URLまたは添付先：
実施日時・完了日時：
差し戻し・障害時の記録：

変更前の値は、「旧送料設定を参照」のように曖昧にせず、条件・金額・対象地域・対象商品などを復元できる粒度で記録します。画面キャプチャだけに依存すると、対象条件や設定の全体像を読み取りにくい場合があります。画面キャプチャは補助証跡とし、設定値をテキストでも残すと検索・差分確認がしやすくなります。

また、認証情報、APIキー、顧客情報、注文情報を台帳やキャプチャへ直接記載しない運用も必要です。秘密情報は既存の安全な保管先を参照する形にとどめ、閲覧権限も分けます。

テスト注文は「注文できた」で終えない

C・D区分では、テスト注文の前後で確認対象を決めます。実際に決済を行うか、テストモードやテスト用決済手段を使えるかは、利用中の決済サービスと環境の仕様に従ってください。利用できない場合は、カートまでの表示確認と、変更前後の設定値レビューを組み合わせ、未確認の範囲を台帳に明記します。

確認項目の例は次の通りです。

• 商品詳細からカートまで、対象商品・数量・在庫条件が想定どおりか
• 送料、割引、税、配送方法、決済手段が対象条件で正しく表示されるか
• 注文後、受注データ・通知メール・連携先データに必要な値が渡るか
• 取消、返金、注文修正が必要になった場合に、担当者が処理できるか
• 変更対象外の商品、地域、会員条件に意図しない影響がないか

Shopifyではロールとアクティビティログを役割分担に組み込む

Shopifyでは、ストアロールにストア権限を割り当て、商品、在庫、配送、決済、ストア設定などへの操作範囲を設定できます。ひとつの業務を完了するために複数の権限が必要になる場合があるため、権限付与後は「必要な画面が開けるか」だけでなく、対象業務を最後まで実行できるかを検証します。仕様確認時点は2025年2月です。権限の種類や管理画面表示は変更される可能性があるため、付与時には公式ヘルプも確認してください。

Shopifyの運用手順

1. 権限マップの役割ごとに、Shopifyのロールと必要なストア権限を対応付ける
2. 個人へロールを割り当てる前に、対象者の担当業務と代替担当を台帳へ記録する
3. 変更台帳に、変更対象・実施者・承認者・公開後確認者を設定する
4. 変更後、ストアアクティビティログで操作の記録を確認し、台帳の変更IDと結び付ける
5. 担当変更や契約終了時には、ロール見直しとアカウント無効化を同じチェックリストで実施する

Shopifyのストアアクティビティログでは、設定変更やアプリへのアクセス付与などの操作を確認できます。ただし、公式ヘルプ上、このログは閲覧専用でエクスポートできず、表示は最大250件です（2025年2月確認）。そのため、ログだけを長期保管用の唯一の証跡にしないことが重要です。

変更前に台帳を起票し、完了時にログの日時・操作内容を照合する設計なら、ログの表示上限に達した後も、「なぜ変更したか」「誰が承認したか」「どの値へ戻すか」を追えます。ログは台帳の代わりではなく、台帳の記載を確認するための証跡として位置付けます。

ecforceでは個別アカウントとメンバーロールを前提にする

ecforceでは、メンバーロールごとに管理画面メニューの操作権限を設定できます。公式FAQでは、共有の管理者アカウントを利用すると、変更履歴機能で変更者を正確に判断できなくなるため、推奨しないと案内されています。仕様確認時点は2025年2月です。

この仕様を踏まえると、台帳の「実施者」とecforce上の変更者を照合できる状態を維持するために、次の運用が有効です。

• 作業者ごとに個別アカウントを発行し、共通IDでの操作を避ける
• メンバーロールは、担当業務単位で作成し、権限の目的を名称に含める
• 一時的に広い権限が必要な場合は、台帳に期限と理由を記載し、作業完了後に戻す
• 変更後は、変更履歴と台帳の実施日時・実施者・対象設定を照合する
• 操作できないことが判明した場合は、個人へ都度追加する前に、ロール設計と業務分担を見直す

「管理者」ロールを複数人に常設することが唯一の解決策ではありません。緊急対応者を決める必要がある場合も、通常運用の権限と緊急時の昇格条件を分け、昇格・復帰を台帳に残す方が、後から判断を確認しやすくなります。

makeshop・futureshop・EC-CUBEでも共通台帳を使う

makeshop、futureshop、EC-CUBEなどでも、権限名や変更履歴の見え方は異なります。しかし、権限マップと変更台帳の列は共通で利用できます。基盤ごとの操作マニュアルを増やす前に、まず「どの変更に誰の承認・どの確認が必要か」を統一すると、引き継ぎ時の確認箇所を減らせます。

EC-CUBEでは、プラグインの導入・有効化をD区分として扱います。EC-CUBE 4.4に関する公開Issueには、複数プラグインを一括インストールした後、キャッシュ再生成前に別プラグインを有効化すると、MappingException が発生し得る条件と回避策が記録されています。この事例だけで、すべてのプラグイン変更に同じ不具合が起きるとは判断できません。

ただし、プラグイン変更では少なくとも次を台帳に残す根拠になります。

• 対象プラグイン、バージョン、導入・有効化の順序
• 実施前のキャッシュ状態と、公式手順・開発担当が定めた再生成手順
• エラー発生時に有効化を戻す方法、復元対象
• 本番反映前に確認する購入導線・管理画面機能・ログ

基盤の標準機能で履歴を十分に取得できない場合も、台帳を共通の変更記録にします。反対に、基盤側の履歴がある場合も、履歴だけでは承認理由や期待結果まで残らないことがあるため、両方を照合します。

月次レビューと引き継ぎで、台帳を使える状態に保つ

台帳を作成しても、更新されなければ引き継ぎ資料にはなりません。月次または担当変更時に、次の確認を実施します。

• 未完了の変更、公開後確認待ちの変更が残っていないか
• C・D区分の変更に、承認者・復元方法・確認結果がそろっているか
• 個別アカウントと権限マップの担当者が一致しているか
• 退職者、異動者、委託終了者の権限が残っていないか
• 一時権限の期限が過ぎていないか
• 変更台帳から、頻繁に変更する設定と、手順が不明瞭な設定を抽出できるか

引き継ぎでは、管理画面の全メニューを説明するより、直近の変更台帳を使って「何を変えたか」「どこを確認したか」「戻すときは何をするか」を確認する方が実務に直結します。新任者には、最初から本番の広い権限を渡さず、閲覧、下書き、限定的な編集、承認済み変更の実施という順に担当範囲を広げる方法も検討できます。

権限管理は、作業を遅くするための統制ではありません。変更の目的、影響、復元、確認者を事前にそろえることで、必要な人が必要な範囲で作業し、問題があったときにも判断と復旧を速くするための運用です。まずは直近1か月の設定変更を台帳へ転記し、権限マップと矛盾している操作から見直すと着手しやすくなります。

参考情報

• Shopify Help Center：Store permissions
• Shopify Help Center：Activity logs in the Shopify admin
• ecforce faq：ecforceの管理画面にアクセスするユーザーの追加・権限設定
• EC-CUBE / GitHub：複数プラグインをまとめてインストールした後の有効化が MappingException で失敗する · Issue #6984