Marketoのロールは、担当者が行う業務を先に整理し、その業務に必要な権限が含まれるものを選びます。最初に確認したいのは、「何をするか」「どの範囲で行うか」「どこから先は別の担当者の仕事か」の3点です。
たとえば、レポートを読む人と作る人では要件が異なります。メールの下書きを作る人と承認する人、配信を開始する人も、同じ権限でよいとは限りません。ロール名から判断する前に、実際に必要な操作へ分解しましょう。
この記事では、基本となる標準ロールの違いと、閲覧・作成・承認・管理の4担当での選び方を解説します。Adobe Marketo Engage Business Practitioner Professional（AD0-E561）の「ユーザーとロールの管理」に対応する学習内容です。試験範囲はAdobeの公式資格ページで確認できます。
公式資料の確認日：2026年10月18日。担当者の例は架空で、権限の組合せを実機検証したものではありません。カスタムロールの作成操作ではなく、選定前の判断を扱います。
ロール・権限・ワークスペースの違い
ロールは権限をまとめたものです。ワークスペースを利用する環境では、操作の種類に加えて、対象となる作業領域も確認します。3つの言葉を分けると、権限の依頼を具体的に書けます。
| 要素 | 目的 | 確認に必要な情報 | 変更・確認の観点 |
|---|---|---|---|
| 権限 | 実行できる操作を決める | 作成、承認、書き出しなどの業務 | 該当項目と前提のAccess権限を照合する |
| ロール | 権限のまとまりを利用者に割り当てる | 必要な権限と現在のロール定義 | 割当の変更と、定義そのものの変更を区別する |
| ワークスペース | プログラムやメールなどを置く作業領域を分ける | 対象領域と利用者のアクセス範囲 | 対象領域で必要な作業ができるか確認する |
たとえば「メール編集が必要」と「日本向けの作業領域が必要」は別の要件です。また、ワークスペースと、人物データを分けるPerson Partitionも同じものではありません。根拠はロールの公式説明とワークスペースとPerson Partitionの公式説明を参照してください。
「特定のメール1件だけ編集できるロール」を作れると考えるのも避けましょう。Adobeは、個別のアセットやプログラムに限定したロール設定は提供しておらず、ワークスペースが有効な環境では領域ごとの制限を利用できると説明しています。詳しくは個別アセットへのアクセス制限に関する公式回答で確認できます。
基本となる標準ロール6種類を比較する
以下は、Adobeの基本ロール一覧が示す領域の概要です。「業務候補」は選定の出発点を示す例であり、そのまま割り当てる推奨設定ではありません。
| ロール名 | 公式資料の基本範囲 | 業務候補・用途の例 | 注意点と確認方法 |
|---|---|---|---|
| Admin | Adminを含む全領域 | 広い管理責任を持つ担当 | 全領域が必要な責任範囲かを確認 |
| Adobe Product Admin | Adminを含む全領域 | 製品管理を担う担当 | Console側の管理者任命とMarketo内の権限をそれぞれ確認 |
| Standard User | Adminを除く全領域 | 複数領域を使う運用担当 | 現在の権限項目と、不要な操作の有無を確認 |
| Marketing User | Adminを除く全領域 | 複数領域を使う施策担当 | Standard Userと同じ内容と決めず、利用機能を照合 |
| Web Designer | Design Studio | 同領域で制作する担当 | 制作に加えて承認・削除まで許可されていないか確認 |
| Analytics User | Analytics | レポートを扱う担当 | 閲覧だけでよいのか、作成・削除・書き出しも必要か確認 |
出典：Managing User Roles and Permissions。AdminとAdobe Product Adminは削除できないシステムロールです。他の4つは編集・削除できるため、同じロール名でも、自社環境での権限設定を確認する必要があります。
この6種類で、追加機能のロールや権限まで網羅できるわけではありません。たとえばCoworker for Marketo Engageには専用ロールがあり、機能別の表ではMarketing UserとStandard Userの扱いも異なります。基本範囲が同じでも全機能が同じとは判断せず、利用機能の個別資料も確認してください。
閲覧・作成・承認・管理の業務から選ぶ
ここでいう4担当は、業務を整理するための区分です。Marketoにこの名前の4つの標準ロールがある、という意味ではありません。
閲覧担当：読む・作る・書き出すを分ける
「週次レポートを見るだけ」という依頼でも、Analytics Userを閲覧専用と即断しないでください。権限一覧のCreate Reportには、作成に加えて読み取りや更新も含まれています。Create Reportを外せば、必要な閲覧だけが残るとはいえません。
必要なレポートを読めるかと、不要な変更・削除・書き出しができてしまわないかを分けて確認します。希望する境界を設定で満たせない場合は、ロール名だけで解決済みにせず、管理者と共有方法や担当範囲を再検討しましょう。
作成担当：下書きの完成と承認を分ける
メールを作る仕事は、どこまで担当するかを書きます。たとえば「下書きの作成と修正まで。承認は別担当」です。権限一覧ではEdit EmailとApprove Emailが別項目として示されています。
Web Designerを候補にする場合も、Design Studio以外で必要な作業がないかを確認します。実際に使うエディター、作業領域、保存までの流れを基準にすると、権限不足を見落としにくくなります。
承認担当：何を承認するのかを具体化する
メールアセットの承認、Email Programの承認、バッチキャンペーンの予約、トリガーキャンペーンの有効化は別の操作です。「承認担当だから配信開始もできるようにする」と一括りにせず、担当する操作を明記してください。
また、内容を見ることと、画面内でコメントすることも異なります。Email Designerの公式説明では、メールのread-only権限ではコメントの閲覧・追加ができません。コメントも必要なら、その要件と権限付与の影響を確認します。根拠はEmail collaborationのPermissionsを参照してください。
承認だけを許し、編集などを完全に分離できるかは、対象機能と現在の権限で確認が必要です。本記事の例は、その組合せが必ず実現できると保証するものではありません。
管理担当：利用者の管理とロール定義の管理を分ける
Access Usersはユーザーの管理、Access Rolesはロールの管理を対象とする別項目です。これらはMarketo内の権限名で、Adobe Admin Consoleの管理資格を付与するものではありません。「管理担当」という職名だけでAdminを選ばず、利用者の保守か、ロール定義の変更か、全体設定の変更かを分けます。
ここまでの権限名と範囲はDescriptions of Role Permissionsで確認できます。Accessは必ずしも閲覧だけを意味せず、下位の権限には対応するAccess権限が必要です。名前だけで最小の権限セットを決めず、業務の完了まで確かめましょう。
IMS環境での管理場所と確認担当
Adobe Identity Management System（IMS）を利用する環境では、ユーザー管理にAdobe Admin Consoleが関わります。一方、Marketoのロール定義の確認は、AdminのUsers & RolesにあるRolesで行う案内が公式資料にあります。
| 確認したいこと | 確認先・担当 | 選定時の注意 |
|---|---|---|
| 対象製品を利用するための割当 | Adobe Admin Console／製品プロファイルを扱う管理者 | 製品を利用できることと、目的の操作ができることを分ける |
| ロールに含まれる権限 | MarketoのRoles／ロールを確認・管理できる担当者 | 名前ではなく、現在の定義を業務要件と照合する |
| 本人が実際にできる作業 | 対象利用者と確認担当者 | 本人の環境・対象領域で結果を記録する |
管理者の種類と範囲はAdobe Identity Management Overview、ロール定義の確認先はAdmin Section ChecklistのRolesを参照してください。古い画面案内と表示が違う場合は、移行状況と管理方式を確認します。
ロールの割当操作には確認が必要です。2026年10月18日時点で、IMS移行後の割当について、上記Checklistとユーザー追加の個別手順・User Setup Checklistに記載差があります。本記事では割当の操作順を確定せず、必要な権限を整理するところまでを扱います。変更する際は、対象環境の管理者と現行の操作経路を確認してください。
架空の4担当でロール選定を練習する
次の表は、実在する組織や実測結果ではない学習用の例です。「必要な仕事」「担当しない仕事」「確認する内容」を同じ行に書くと、ロール候補の過不足を説明しやすくなります。
| 担当 | 必要な仕事／担当しない仕事 | 調べる候補 | 確認したい結果 |
|---|---|---|---|
| A：週次報告の閲覧 | 既存レポートを読む／作成・変更・削除・書き出しはしない | Analytics Userの現在の定義と、レポート関連の権限 | 閲覧と担当外操作の制限を両立できるか |
| B：メールの下書き制作 | 下書きの作成・修正／承認・配信開始はしない | Web Designerなどと、実際の作業領域・メール権限 | 保存まででき、承認・配信に進めないか |
| C：メールアセットの承認 | 内容確認とアセット承認／配信予約はしない | 対象機能の参照・承認権限と、コメントの必要性 | 承認できるかと、予約が制限されるか |
| D：利用者情報の保守 | 担当範囲のユーザー管理／共通ロールの定義は変えない | 管理方式、Access Users、Console側の管理資格 | 必要な利用者管理ができ、ロール定義を変更できないか |
たとえばBのロール候補に承認まで含まれていたら、「下書きを保存できたので合格」では確認が足りません。担当外の操作も許されているなら、要件との差として記録します。既存の標準ロールが広すぎる場合は、カスタムロールの設計候補に進みます。
なお、Cの承認操作にはどの前提権限が必要か、Dの管理がどの画面で行われるかは、表だけでは確定できません。ここで完成させるのは、管理者へ渡す要件と検証項目です。
権限の過不足を確認する5つのポイント
- 担当業務を動詞で書く。「マーケティング業務」ではなく、「レポートを読む」「メールを修正する」「予約する」のように具体化します。
- 現在の権限と対象範囲を確認する。付与済みロール、権限項目、ワークスペース、利用する機能を記録します。権限一覧と機能別資料を照合してください。
- 既存ロールへの変更の影響を調べる。共有するロール定義を変えると、そのロールを持つ利用者全員に影響します。1人の設定変更として扱わないことが大切です。
- 複数ロールを単純な足し算と考えない。現行の公式手順は、複数選択時に最も制限の強い権限を既定とする旨を記載しています。ロールを追加すれば不足が必ず解消する、と判断せず、組合せと実際の結果を確認します。
- 本人の権限で、必要な操作と担当外の操作を確認する。許可されたテスト環境・検証用データで行い、実配信や実ユーザーの変更につながる操作は検証計画を立ててから実施します。定義変更後は再ログインし、期待結果と実結果を分けて記録してください。
ロール定義変更の影響と複数割当はロールの変更に関する公式手順、再ログインについては権限変更の反映に関する公式説明が根拠です。複数ロールの具体的な組合せや、各担当例の操作結果は本記事では未検証です。
ボタンやアセットが見えるだけで操作権限があるとは限らない点も、公式の権限一覧に説明されています。管理者アカウントで代わりに成功した結果を、担当者の確認結果として記録しないようにしましょう。
理解を確認する独自問題
以下は学習用に作成した非公式の単一選択問題です。本試験の再現問題ではありません。
問題1：レポートを見るだけの担当者
担当Aは既存レポートの閲覧だけを求められています。最も適切な判断はどれでしょうか。
- Analytics Userなら必ず閲覧専用なので、そのまま完了とする。
- Create Reportを外せば、必ず閲覧だけが残る。
- 現在のレポート関連権限を調べ、閲覧と担当外操作の両方を確認する。
正答：C。Aはロール名を操作範囲の保証として扱っている点が不適切です。BはCreate Reportに読み取りや更新も含まれることを見落としています。Cなら、必要な仕事ができるかと、不要な操作が許されていないかを別々に検討できます。復習先：権限一覧のAccess Analytics。
問題2：1人のために共有ロールを変更する
同じロールを使う3人のうち、1人だけに新しい仕事が加わりました。最初に確認すべきことはどれでしょうか。
- そのロールの定義変更が、他の利用者にも与える影響。
- ロール名を変えれば、変更対象は自動的に1人になること。
- 最も広いロールを全員に追加すれば確認が不要になること。
正答：A。ロール定義の変更は、そのロールを持つ利用者全員に影響します。Bのように名称だけで対象者は限定されません。Cは不要な権限と複数割当の影響を確認しておらず、不適切です。復習先：Edit a Role／Change a User's Role。
問題3：メール承認と配信予約
担当Cの仕事はメールアセットの承認までで、配信予約は別担当です。最も適切な進め方はどれでしょうか。
- メールに関わる権限はすべて同じなので、一括で付与する。
- 承認と予約を別の要件にし、必要な前提権限と操作結果を確認する。
- 承認ボタンが見えれば、権限の確認を完了とする。
正答：B。Aはアセット承認とキャンペーン予約の区別をしていません。Bは担当範囲と検証対象を具体化できます。Cは画面表示だけで実行可否を判断しているため不十分です。復習先：Design StudioとMarketing Activitiesの権限。
次に進むための権限要件メモ
まず、担当者1人分について次の4行を書いてみてください。
- 行う操作：何を、どこまで担当するか。
- 担当しない操作：承認、配信、書き出し、全体設定などの境界。
- 対象範囲：利用機能、作業領域、利用者管理なら対象製品や担当範囲。
- 確認方法：必要な操作と担当外の操作それぞれの期待結果。
そのメモを現在のロール定義と照合し、標準ロールで足りるか、カスタムロールの設計が必要かを判断します。実際の作成・割当へ進むときは、公式のロール管理資料と対象環境を確認しましょう。
資格全体の位置付けを確認したい方は、Marketo資格の試験概要と学習方法も参照してください。
