Ruuma
作ったこと

Cloudflareの「Account」をユーザーアカウントだと思ってハマった

  • サイト運営
  • インフラ

Astroで作った個人サイトをCloudflare Workersへデプロイし、共同管理しているドメインのサブドメインで公開しました。

最終的には問題なく公開できましたが、途中でデプロイに失敗し、原因を理解するまでかなり時間がかかりました。

結果だけを見ると、次の2点を直したことで解決しています。

  • デプロイ時に共同管理しているAccountも選択する
  • wrangler.jsoncに、そのAccountのIDを指定する

ただ、単純な設定漏れというより、そもそも私がCloudflareにおける「Account」の意味を勘違いしていたことが原因でした。

この記事では、CloudflareがUser、Account、Zoneなどをどの単位で管理しているのかと、複数人で管理しているドメインへサイトを公開するまでに混乱した点を整理します。

やりたかったこと

今回作ったのは、Astroで生成した静的サイトです。

これをCloudflare Workers Static Assetsへデプロイし、次のようなサブドメインで公開しようとしていました。

https://site.example.com

親ドメインであるexample.comは共同管理者がCloudflareへ追加したもので、自分も管理者として招待されていました。

構成は次のようなものです。

GitHub
   │
   │ push
   ▼
Cloudflare Workers
   │
   ▼
site.example.com

CloudflareのDashboardでは、Accountを切り替えることでexample.comを確認できていました。

そのため、自分も管理者として招待されているなら、そのままデプロイできるだろうと思っていました。

最初の設定

最初のwrangler.jsoncは、次のような内容でした。

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "example-site",
  "compatibility_date": "2026-07-12",
  "route": "site.example.com/*",

  "assets": {
    "directory": "./dist",
    "not_found_handling": "404-page"
  }
}

この時点では、account_idを指定していませんでした。

account_idは必須項目ではなかったため、特に設定しなくてもデプロイ先は自動で判断されると思っていました。

また、初めてデプロイ設定を進めたとき、自分のメールアドレス名が付いたAccountと、共同管理者のメールアドレス名が付いたAccountの両方が候補に表示されました。

自分のメールアドレス's Account
共同管理者のメールアドレス's Account

私は当時、CloudflareのUserとAccountを同じものだと思っていました。

そのため、共同管理者のメールアドレス名が表示されたのを見て、共同管理者本人のアカウントまで自分に紐づけようとしているように感じました。

自分のログインなのに、他人のアカウントを選んで大丈夫なのか 共同管理者の管理画面や権限まで触れるようになったらまずいのではないか

と不安になり、自分のメールアドレス名が付いたAccountだけを選択しました。

この時点では、それが安全な選択だと思っていました。

デプロイに失敗した

この状態でデプロイすると、対象のZoneを見つけられない旨のエラーが発生しました。

自分が選択したAccountには、公開に使いたいexample.comが存在しません。

自分のメールアドレス's Account
└─ example.comは存在しない

共同管理者のメールアドレス's Account
└─ example.com

最初は、共同管理Account側で自分に必要な権限が付いていないのだと思いました。

しかし確認すると、自分には管理者権限が付与されていました。

そのため、権限が弱くて操作できないわけではありませんでした。

AIへエラー内容を渡したり、共同管理者にCloudflare側の設定を確認してもらったりしながら原因を探しましたが、なかなか理解できませんでした。

調べていく中で、ようやくCloudflareにおけるAccountの考え方が、自分の認識とは異なることに気づきました。

UserとAccountを同じものだと思っていた

そもそも私は、UserとAccountをほぼ同じものだと思っていました。

自分の認識

自分のメールアドレスでログインする
=
自分のCloudflare Account

一般的なWebサービスで「アカウント」と言われたときと同じように、メールアドレスでログインする一人のユーザーそのものが、その人のアカウントであるという認識です。

そのため、Dashboardに次の2つが表示されること自体が、うまく理解できていませんでした。

自分のメールアドレス's Account
共同管理者のメールアドレス's Account

自分のメールアドレスでログインしているのに、なぜ共同管理者のアカウントまで選択できるのか。

共同管理者本人のアカウントへ自分が入っているのか。

User Groupに追加されたことで、相手のアカウントを共有されたのか。

この時点では、UserとAccountが別の概念であり、一人のUserが複数のAccountに所属できるという構造を理解していませんでした。

CloudflareではUserとAccountが分かれている

Cloudflareでは、ログインする個人と、リソースを管理する単位が分かれています。

User
└─ Cloudflareへログインする個人

Account
└─ Zone、Workers、メンバーなどを保持する管理単位

一人のUserは、複数のAccountに所属できます。

今回の状態は、次のようなものでした。

User：自分
│
├─ 自分用Account
│  └─ 今回使うリソースはない
│
└─ 共同管理Account
   ├─ Zone: example.com
   ├─ Worker
   ├─ Member: 共同管理者
   └─ Member: 自分

自分のAccountにexample.comが共有されているわけではありません。

自分というUserが、自分用Accountと共同管理Accountの両方に所属しています。

DashboardにあるAccount切り替えは、ログインするユーザーを切り替えるものではなく、どのAccountに所属するリソースを見るかを切り替えるものです。

ログイン中のUser：自分
          │
          ├─ 自分用Accountを表示
          └─ 共同管理Accountを表示

この構造を理解して、ようやくDashboardの表示と実際のリソースの所属がつながりました。

Account名がさらに分かりにくかった

今回の共同管理Accountには、次のような名前が付いていました。

共同管理者のメールアドレス's Account

Cloudflareを使い始めた際に自動で付いた名前を、そのまま使っていたためです。

この名前だと、どうしても共同管理者本人の個人アカウントに見えます。

実際には、そのAccountを最初に作成した共同管理者のメールアドレスが、初期のAccount名として残っているだけでした。

そのAccountには、共同管理者と自分の二人がメンバーとして所属しています。

共同管理者のメールアドレス's Account
├─ Member: 共同管理者
├─ Member: 自分
├─ Zone: example.com
└─ Worker

共同管理者のログイン情報を借りているわけでも、共同管理者本人の権限をそのまま使っているわけでもありません。

自分自身のUserとして、そのAccountに付与された自分の権限を使っています。

共同利用するAccountであれば、初期名のままにせず、用途が分かる名前へ変更した方が分かりやすそうです。

変更前

├─ 自分のメールアドレス's Account
└─ 共同管理者のメールアドレス's Account
変更後

├─ 自分のメールアドレス's Account
└─ example-project

これなら、個人用Accountと共同管理Accountの違いがかなり分かりやすくなります。

User GroupもAccountそのものではない

自分は共同管理AccountのUser Groupにも追加されていました。

この「グループ」という言葉も、最初は共同利用するためのAccountのようなものなのかと思っていました。

しかし、User Groupはリソースを所有する単位ではありません。

誤って想像していた構造

User Group
└─ example.com

実際には、Accountの中にUser GroupとZoneがそれぞれ存在します。

共同管理Account
├─ User Group
│  ├─ 共同管理者
│  └─ 自分
│
├─ Zone: example.com
└─ Worker

User Groupは、複数のメンバーへ同じ権限をまとめて付与するためのものです。

今回の場合、User Groupの権限には問題がなく、自分には管理者権限が付いていました。

原因が分かった

調べていく中で、最初の設定時に共同管理Accountを自分で選択肢から外していたことが原因だと分かりました。

流れを整理すると、次のようになります。

1. wrangler.jsoncにaccount_idを指定していなかった
2. 初回設定時に、自分用Accountと共同管理Accountが候補に出た
3. UserとAccountを同じものだと思っていた
4. 共同管理Accountを他人本人のアカウントだと受け取った
5. 不安になり、自分用Accountだけを選択した
6. 自分用Accountにはexample.comが存在しなかった
7. site.example.comへのデプロイに失敗した

必要な共同管理Accountは最初から候補に表示されていました。

しかし、Accountの意味を誤解していたため、自分で対象から外していました。

設定を見直した

まず、現在どのAccountが利用対象になっているかを確認しました。

npx wrangler whoami

修正前は、自分用Accountだけが表示されていました。

Account Name                         Account ID
自分のメールアドレス's Account       <自分用Account ID>

一度ログアウトし、再度ログインしました。

npx wrangler logout
npx wrangler login

今回は、自分用Accountだけでなく、共同管理Accountも選択しました。

再度確認すると、両方が表示されました。

Account Name                         Account ID
自分のメールアドレス's Account       <自分用Account ID>
example-project                      <共同管理Account ID>

そのうえで、wrangler.jsoncへ共同管理AccountのIDを追加しました。

修正後の設定

最終的なwrangler.jsoncは、概ね次のようになりました。

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "example-site",
  "account_id": "<共同管理Account ID>",
  "compatibility_date": "2026-07-12",

  "routes": [
    {
      "pattern": "site.example.com",
      "custom_domain": true
    }
  ],

  "assets": {
    "directory": "./dist",
    "not_found_handling": "404-page"
  }
}

指定するのは、自分用AccountのIDではありません。

example.comとWorkerを管理する共同管理AccountのIDです。

共同管理Account
├─ Zone: example.com
├─ Worker: example-site
└─ Account ID
   └─ wrangler.jsoncへ指定

この状態で再度デプロイしたところ、正常に公開できました。

最終的に理解した構造

今回の構造をまとめると、次のようになります。

User：自分
│
├─ 自分用Account
│  │
│  ├─ Member
│  │  └─ 自分
│  │
│  └─ 今回使うZoneやWorkerはない
│
└─ 共同管理Account
   │
   ├─ Members
   │  ├─ 共同管理者
   │  └─ 自分
   │
   ├─ User Group
   │  └─ メンバーへの権限設定
   │
   ├─ Zone
   │  └─ example.com
   │
   └─ Worker
      └─ example-site

Dashboardでは、Account切り替えで表示するリソースを選びます。

Dashboard
└─ 表示するAccountを画面で切り替える

デプロイ設定では、利用対象に含めるAccountと、設定ファイルで指定するAccountを合わせる必要があります。

デプロイ設定
├─ 共同管理Accountを利用対象に含める
└─ account_idに共同管理Accountを指定する

まとめ

CloudflareのAccountは、私が想像していた「一人のユーザーそのものを表すアカウント」とは違いました。

今回理解した内容は次の通りです。

User
└─ Cloudflareへログインする個人

Account
└─ Zone、Workers、メンバーなどを保持する管理単位

Zone
└─ Accountに所属するドメイン

Member
└─ そのAccountを操作できるUser

User Group
└─ 複数のMemberへ権限をまとめて設定するもの

一人のUserは、複数のAccountに所属できます。

共同管理Accountを利用対象へ含めても、共同管理者のログイン情報や権限を借りるわけではありません。自分のUserに付与された権限で、そのAccountを操作します。

今回は、Accountの意味を誤解していたため、必要な共同管理Accountを自分で選択肢から外していました。

さらに、wrangler.jsoncにaccount_idを指定していなかったため、自分用Accountが使われましたが、そこには対象ドメインが存在せず、エラーになりました。

複数人でCloudflareを管理する場合は、最初に次の点を確認するとよさそうです。

・対象のZoneがどのAccountに所属しているか
・自分のUserがそのAccountに所属しているか
・デプロイ時にそのAccountを選択しているか
・wrangler.jsoncがどのAccountを指定しているか

また、共同管理するAccountには、メールアドレス由来の初期名ではなく、プロジェクト名や組織名を付けておくと混乱を減らせるなと思います。