wranglerのログイン切れとAPIトークンへの切り替え

こんにちは！アントロンのNaokoです。

毎日自動で動かしていたものが、ある日いきなり止まっていた。直しても、また止まる。そんな経験はありませんか？

制作を担当している宿の予約システムでは、Claude Code（AI に作業を頼めるアプリ）が毎朝、本番の状態を自動で確認しています。2026年10月14日は、予約メールの送信状況の確認が NG になっていました。

この日に行った対処は、開発と自動実行で使っていた認証方法を分けることでした。別の作業で長く動かしていた wrangler dev はログインのまま、アプリ開発の wrangler をすべて API トークン（操作の権限を指定した認証情報）に切り替えました。デプロイと毎朝の確認も含みます。

以下は、私の環境で起きたことと、切り替え後に確認できた結果です。

10月14日朝：メールの送信状況を確認できなかった

予約システムは Cloudflare Workers（Cloudflare のサーバーでプログラムを動かすサービス）で動いています。その管理に使っているのが、wrangler（コマンドで Cloudflare を操作する公式ツール）です。

当時は、次の2つで同じログインを使っていました。

• 別の作業で長く動かしていた wrangler dev
• アプリ開発の wrangler。デプロイと毎朝の確認に使うコマンドを含みます。

wrangler のログには、ログインの認証情報の更新が 400 エラーで断られ、次のエラーが出たと残っています。

Token refresh failed: [object Object]

本番の D1（Cloudflare のデータベース）を読めず、予約メールの送信状況を確認できない状態でした。

この NG は、送信状況を調べる処理が認証エラーで止まったことを示しています。メールの送信失敗を確認した結果ではありません。

10月14日午後：ログインし直しても、また切れた

同じ日の午後、スマホでコードを入力して許可し、ログインし直しました。その後の経過も記録に残っています。

• 15:50：ログインし直しました。1回目はコードの期限が切れ、2回目で通りました。
• 17:31：アプリ開発のコマンドがログインの認証情報を更新しました。
• 17:32：別の作業で長く動いていた wrangler dev が、更新前のログインの認証情報で更新を試み、400 エラーになりました。
• 17:47：アプリ開発でも認証エラーになりました。

作業記録では、長く動く wrangler dev とアプリ開発のコマンドが同じログインを共有し、片方の更新でもう片方が切れたと整理しています。

ただし、Cloudflare 側でログインごと無効になる仕組みかどうかは未確認です。朝の最初の更新が断られた原因も、確認できていません。

10月14日夕方：認証方法を分けた

Cloudflare のダッシュボード（管理画面）で、API トークンを作りました。

設定した権限は、次の3つです。

• Workers Scripts の編集
• D1 の編集
• Workers Routes の編集。対象のドメインは画面で1つに絞りました。

API トークンは、Git（コードの変更を記録する仕組み）の管理対象に含めないファイルに保存しました。

Claude Code に作ってもらった専用スクリプトは、クリップボードから値を読み、形式と有効性を確認して保存し、クリップボードを空にします。私の環境では、次のコマンドで保存する形です。

node C:/base/.claude/scripts/devdept-wrangler.mjs put-token

保存した API トークンの有効性だけを確認するコマンドもあります。

node C:/base/.claude/scripts/devdept-wrangler.mjs check

check は Cloudflare の確認用 API を呼び、有効な状態を示す active かどうかを判定します。これは API トークン自体の有効性の確認です。本番のデータベースを読めるかどうかは、毎朝の確認結果で確かめます。

上のコマンドは、私の PC に置いた専用スクリプトを呼び出すものです。スクリプトには保存先、アカウント ID、予約システムのフォルダを指定しています。

wrangler を動かす際には、次の環境変数を渡しています。

• CLOUDFLARE_API_TOKEN：API トークンを渡す設定
• CLOUDFLARE_ACCOUNT_ID：アカウント ID を渡す設定

毎朝の確認を行う devdept-watch.mjs と、デプロイ用の devdept-deploy.mjs も、専用スクリプトの tokenEnv() を使っています。この関数が保存済みの API トークンを読み、wrangler に渡す環境変数を用意します。

つまり、手動で使うコマンドだけでなく、自動実行側とデプロイ側も同じ API トークンを使う形に変えました。

切り替え後の使い分けは、次のとおりです。

• 別の作業で長く動かしていた wrangler dev：これまでどおりログインを使用
• アプリ開発の wrangler：デプロイと毎朝の確認を含め、すべて API トークンを使用

日次記録には、18:16 に復旧したと残っています。

10月15日朝：本番のデータベースを読んで確認できた

翌朝は、予約メールの送信状況の確認が OK になりました。本番の D1 を読み、直近2日の予約で送信に失敗したものが0件だったという結果です。

今回、認証方法の切り替え後に確認したかったのは、この読み取りができることです。新たにメールを送るテストの結果ではありません。

同じ朝の記録には、ほかにも次の確認結果が残っています。

• 予約システムの空き表示：2026年10月の31日分を確認
• チャットボットの widget.js：取得したファイルは23,068文字
• チャットボットのページと指示文のずれ：5ページを確認し、ずれは0件

この4項目のうち、API トークンで本番の D1 を読んでいるのは、メールの送信状況の確認だけです。

10月17日に書いた振り返りの時点では、10月14日の切り替え後、デプロイと毎朝の確認は一度も止まっていませんでした。

同じエラーが出たら、認証の使い方を確認する

今回の記録で確認できたのは、同じログインを使う2つの処理で、ログインの認証情報の更新とエラーが続いたことです。朝の更新失敗の原因や、Cloudflare 側の無効化の仕組みまでは分かっていません。

同じエラーが出たときは、まず、自動実行と開発で同じログインを使っているかを確認してみてください。今回と同じ原因だと決めつけず、認証方法を見直すための確認事項として、この事例を使っていただければと思います。

Cloudflare Workers の本番運用や、自動実行の仕組みづくりでお困りでしたら、お問い合わせフォームからどうぞ。

最後まで読んでくださりありがとうございました！