納品の1週間ほど前、制作会社のディレクターから決まって同じ相談が来ます。「先方のログイン、どうしましょう」。

そのまま全員を管理者アカウントで渡してしまうと、半年後に「実績ページの項目が消えた」「見覚えのないフィールドが増えている」という連絡になりがち。クライアントが乱暴なことをしたわけではなく、触れる場所まで渡した側の設計の問題です。ヘッドレスCMSは役割（ロール）で触れる範囲を分けられるので、渡す前に一度決めておけば防げます。EmDashを例に、実際の線引きを書きます。

役割は5段階。分かれ目は「公開できるか」と「構造を触れるか」

EmDashのロールは下から Subscriber（10）／Contributor（20）／Author（30）／Editor（40）／Admin（50）の5段階で、上位は下位の権限をすべて引き継ぎます。

  • Subscriber … 公開済みのコンテンツを読むだけ。下書き・予約・ゴミ箱・リビジョン・プレビューURLは見えない
  • Contributor … コンテンツを作れるが、公開はできない
  • Author … 自分のコンテンツを作って公開できる
  • Editor … 全員のコンテンツとメディア、タクソノミー、メニューを管理できる。スキーマは閲覧のみ、設定は読むだけ
  • Admin … 設定変更とスキーマ変更を含めて全部

境界は2本しかありません。ひとつはContributorとAuthorのあいだ、公開ボタンを押せるかどうか。もうひとつはEditorとAdminのあいだ、サイトの構造（コレクションとフィールドの定義）と設定を触れるかどうか。管理画面でもスキーマビルダー（/content-types）と設定画面はAdminにしか表示されません。

EmDashのロール5段階。Subscriber、Contributor、Author、Editor、Admin

ひとつ注意点。最初に作られたユーザーは必ずAdminです。開発中に自分で作ったアカウントがそれに当たるので、引き渡し前に誰がAdminなのかを棚卸ししておく。

「壊されるのが怖い」は、渡す役割で解ける

管理画面をクライアントに渡すのが怖い理由は、突き詰めると構造を壊されるのが怖いから。でも構造を触れるのはAdminだけなので、日常の更新担当をEditor以下にしておけば、そもそも壊せません。「信頼して渡す」ではなく「壊せない範囲を渡す」に置き換えられる、という話です。

  • 記事や実績を書く担当が1人 … Author
  • 複数人の原稿をまとめて出す編集担当 … Editor
  • 外部ライターや協力会社 … Contributor（公開は社内の誰かが最後に押す）
  • 会員向けページを読むだけの人 … Subscriber
全員Adminで渡す場合と役割を分けた場合の比較。公開・構造・設定・事故の後

ひとつだけ削ってはいけないのが、クライアント側のAdminです。制作側だけがAdminだと、こちらと連絡が取れなくなった瞬間に先方は設定を一切変えられなくなる。先方に1人、こちらに1人が現実解だと考えています。数年後に別の会社が改修や保守を引き継ぐときも、Adminが社内にいるかどうかで初動が変わります。

人以外のアクセス——APIトークンとAIコネクタも同じ設計で絞る

いまの運用では、人だけでなくトークンが管理画面と同じAPIを叩きます。EmDashはトークンにスコープを持たせられて、content:read content:write media:read media:write schema:read schema:write taxonomies:manage menus:manage settings:read settings:manage、そして全許可の admin に分かれています。

肝心なのは、トークンのスコープはそのユーザーのロールを超えないこと。Editorのアカウントで発行したトークンに schema:write を付けても、スキーマは変更できません。AIアシスタントをつなぐときの同意画面は要求された権限がすべてチェック済みの状態で出てくるので、要らないものを外してから承認する。

自分のサイトでの運用も書いておきます。このブログは下書きと図版のアップロードをAIに任せていますが、公開だけは人間が管理画面で押すようにしています。これが成り立つのは、EmDashで編集と公開が別の操作になっているから。RESTでドラフトを更新するPUTは status を受け付けず、公開は別のエンドポイントに分かれています。書き込みを許しても、ライブに出る瞬間だけは人の手に残せる。仕組みの詳細はEmDash × MCPの記事にまとめました。

渡す前に決めておく4つ

  1. Adminを両側に1人ずつ置く。 日常の更新はEditor以下でまわす
  2. ログイン手段を先に整える。 EmDashはパスキーが基本で、招待リンクは7日で失効します。1人あたり10個まで登録できるので、PCとスマホの2台に入れてもらう。端末が1台壊れて詰む事故が減ります。セッションは30日のスライド式で、使っていれば延びる
  3. 消したときの戻し方を、渡す日に一緒に触っておく。 下書き・リビジョン・ゴミ箱のどれで戻るのかは、事故ってから調べると遅い
  4. 触れる範囲を1枚の紙にして渡す。 「この人はEditor、スキーマは触れません」まで書いておくと、あとから来る問い合わせが目に見えて減ります
引き渡し前に決めておく4つ。Adminの数、ログイン手段、戻し方、範囲の共有

権限設計はフィールド設計とセットで効きます。触っていい欄が絞られていて、触れない場所には最初から入れない。この2つが揃うと、納品後の管理画面はかなり静かになります。フィールド側の考え方はヘッドレスCMSのフィールド設計に書きました。

EmDashやヘッドレスCMSの構築、既存サイトのCMS入れ替えで、権限まわりの設計から相談したい制作会社の方はお問い合わせからどうぞ。すでに動いているサイトの見直しだけでも承ります。

本記事は2026年8月時点の情報です。