今は作者自身が記事を書いているけれど、将来ほかの編集者を迎えるかもしれない。そんなとき、共通パスワードをひとつ置くだけでは管理が難しい。誰がログインしているかを識別する仕組みが必要になる。

そこでClerkを使っているんですね。

そう。EnginemixではWorkerがリクエストを受け取り、Clerkで認証状態とユーザーIDを確認する。そのうえで、許可された編集者かを判定する。

const allowedUserIds = env.AUTHOR_USER_IDS
  .split(',')
  .map((id) => id.trim())
  .filter(Boolean);

const canEdit = allowedUserIds.includes(userId);

作者が誰かを編集者として招きたいときは、その人のユーザーIDを許可一覧へ加えればよいんですか?

現在の構成ではそうだ。カンマ区切りの AUTHOR_USER_IDS をWorkerの環境変数として管理すれば、コードへ個人情報を書かずに編集者を追加・削除できる。

さらに重要なのは、ボタンを隠すだけで終わらせていないことだ。GraphQLの作成・更新・削除処理そのものが、Worker側で編集権限を検査する。

ブラウザ側の表示は書き換えられるから、サーバー側で止める必要があるんですね。

その通り。UIの権限制御は操作ミスを防ぐため、APIの権限制御はデータを守るためにある。役割が違う。

編集者がさらに増え、管理者・執筆者・確認者のような役割が必要になったら、単純なID一覧からロールベースの権限へ発展させられる。最初から複雑にせず、人数と運用に合わせて育てる設計だ。