wrangler login ができない・whoami が失敗する。トークンは有効なのにアカウントが取れないときの切り分け

この記事で切り分けられること

Cloudflare の wrangler が、ログインまわりで止まる。よくある形は次の2つです。

wrangler whoami
# Failed to automatically retrieve account IDs for the logged in user.

wrangler pages project list
# Authentication error [code: 10000]

この2つは症状が似ていますが、止まっている場所が違います。順番に切り分けます。2026年10月21日に実際に詰まって、両方とも踏んだときの記録です。

前提: ブラウザのログインと APIトークンは別物

wrangler login はブラウザを開いて OAuth で繋ぐ方式です。手元の机では使えますが、画面の無い場所(CI、サーバー、クラウドの実行環境)では使えません。そこでは CLOUDFLARE_API_TOKEN を環境変数に置く方式を使います。

そして、環境変数にトークンがあると、wrangler はそちらを優先します。手元で wrangler login 済みなのに挙動がおかしいときは、まず環境変数が残っていないか見てください。

echo $CLOUDFLARE_API_TOKEN | head -c 6     # 値そのものは出さない
echo $CLOUDFLARE_ACCOUNT_ID

第1段: トークンが「有効か」を確かめる

作り直す前に、いまのトークンが生きているかだけを先に見ます。

curl -s -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  https://api.cloudflare.com/client/v4/user/tokens/verify

"This API Token is valid and active" が返れば、トークンは生きています。ここで通ったら、トークンを作り直しても意味がありません。実際に詰まったときも、ここは 200 で返っていました。にもかかわらず whoami は失敗していました。

第2段: アカウントが見えないから失敗している

whoami が「Failed to automatically retrieve account IDs」で落ちるとき、wrangler は裏でアカウントの一覧を取りに行っています。

curl -s -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  https://api.cloudflare.com/client/v4/accounts

ここが空の配列で返ってきたら、原因はこれです。トークンは有効だけれど、アカウント一覧を読む権限が無いので、wrangler は自分がどのアカウントで動けばいいか決められません。

権限を足して回る前に、アカウントIDを直接渡して探索ごと飛ばすのが早いです。

export CLOUDFLARE_ACCOUNT_ID=<あなたのアカウントID>

アカウントIDは秘密情報ではありません。Cloudflare のダッシュボードの右側か、既に wrangler.toml に書いてあることが多いです。CI の環境変数に置く場合も、トークンと違って秘匿の扱いは要りません。

これを入れると、アカウント一覧の権限が無くても先に進めるようになります。

第3段: 資源ごとの権限が無い(Authentication error 10000)

アカウントIDを渡すと、今度はここまで進みます。

curl -s -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/pages/projects
# {"success":false,"errors":[{"code":10000,"message":"Authentication error"}]}

code 10000 は「鍵が間違っている」ではなく「その資源を触る権限がこのトークンに無い」です。ここまで来たら、トークンの中身の問題です。Cloudflare の画面(My Profile → API Tokens)から、そのトークンに必要な権限を足します。

Pages にデプロイする → Account / Cloudflare Pages / Edit
Workers を触る → Account / Workers Scripts / Edit
KV・R2・D1 → それぞれ別の権限。Pages の権限では触れません

権限を足したら、トークンを作り直す必要はありません。同じトークンのまま反映されます。

切り分けの順番(まとめ)

user/tokens/verify が 200 か → だめならトークンを作り直す
/accounts が空か → 空なら CLOUDFLARE_ACCOUNT_ID を環境に置く
/accounts/<id>/pages/projects が 10000 か → その資源の権限を足す

学んだこと

APIトークンは「有効か」ではなく「何ができるか」で確かめる。verify が 200 を返すのは、そのトークンが失効していないという意味だけで、目的の操作ができる保証ではありません。ここを同じものとして扱っていたせいで、効かない作り直しを何度か繰り返しました。

あわせて、wrangler を画面の無い場所で使うなら CLOUDFLARE_ACCOUNT_ID を必ず置く。アカウント探索は余計な権限を要求するので、最初から要求しない形にしておくと、権限の設計がそのぶん単純になります。

業務自動化 Cloudflare 個人開発