はじめに
ヘルスエンドポイントは、アプリケーションが応答していることを知らせる小さな URL です。この実験では、JavaScript で Cloudflare Worker を作成し、LabEx 内で JSON レスポンスをテストします。その後、同じコードを公開 workers.dev URL に公開し、1 件のリクエストログを確認して、テスト用デプロイを削除します。
Prepare Your Cloudflare Learning Account で準備した、メールアドレスを確認済みの自分の学習アカウントと Workers Free を使用してください。また、Connect LabEx to Your Cloudflare Account で確認したデバイス認証の流れを理解し、JavaScript の基礎知識があることを前提とします。この新しい VM では、Workers のデプロイと削除を含む独自の認証が必要です。購入済みのドメイン、データベース、有料プランへのアップグレードは必要ありません。テストレスポンスは公開されますが、サンプルデータのみを含みます。
セットアップにより、Node.js 22.22.0 とプロジェクトローカルの Wrangler 4.131.1 が /home/labex/project/first-worker にインストールされています。Wrangler でアカウント情報を確認し、curl でレスポンスをテストします。これらのツールは LabEx の外でも使用できます。Worker と設定ファイルは自分で作成し、標準の Wrangler コマンドを実行します。削除とログアウトの確認が終わるまで、この VM を開いたままにしてください。
ヘルスチェック用 Worker を作成する
このステップでは、JavaScript のエントリーポイントを作成し、Wrangler にその実行方法を伝えます。Worker は fetch ハンドラーをエクスポートします。Cloudflare は受信した HTTP リクエストに対してこのハンドラーを呼び出し、返された Response が HTTP レスポンスになります。この最初の Worker は、すべてのパスに対して同じヘルスメッセージを返します。ルーティングは次の実験で扱います。
準備済みのプロジェクトに移動し、CLI のバージョンを確認します。
cd /home/labex/project/first-worker
npx wrangler --version
バージョンは 4.131.1 になるはずです。Wrangler はプロジェクトの依存関係としてインストールされているため、このディレクトリからコマンドを実行してください。自分のコンピューターでロックファイルが提供されているプロジェクトの固定依存関係をインストールする場合は、npm ci を使用します。
次のコマンドでは、ヒアドキュメントを使用します。cat は <<'WORKER' と WORKER の間にある行を src/index.js に書き込みます。> はそのファイルを置き換えます。区切り文字を引用符で囲むことで、シェルによる JavaScript テキストの変更を防ぎます。最後の区切り文字を含め、ブロック全体を貼り付けてください。
cat > src/index.js <<'WORKER'
export default {
async fetch(request) {
console.log("health-request", request.method, new URL(request.url).pathname);
return Response.json({ service: "labex-first-worker", status: "ok" });
},
};
WORKER
Response.json は、ステータス 200 と JSON の Content-Type を持つ JSON レスポンスを作成します。コンソールメッセージには、ヘッダーや認証情報を記録せずにメソッドとパスが記録されます。
既存の Worker を上書きしないように、一意の名前を生成します。Node.js の組み込み crypto モジュールは 6 個のランダムなバイトを生成し、それを 12 個の 16 進数文字として書式化します。$(...) はそのテキストをシェル変数に格納します。
WORKER_NAME="labex-first-$(node -p "require('node:crypto').randomBytes(6).toString('hex')")"
設定ファイルを作成します。ここでは区切り文字を引用符で囲まないため、$WORKER_NAME が一意の値に展開されます。
cat > wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-09-14",
"workers_dev": true,
"preview_urls": false
}
CONFIG
main は JavaScript ファイルを指定します。compatibility_date はランタイムの互換性動作を選択するもので、デプロイ日時ではありません。workers_dev は公開テスト URL を有効にし、preview_urls は追加のバージョンプレビュー URL を無効にします。コメントを含まない JSON は有効な JSONC です。この実験では、示されている形式を使用してください。
cat wrangler.jsonc
名前が labex-first- で始まり、一意のサフィックスを含んでいることを確認します。この名前は実験中ずっと保持してください。デプロイと削除の対象になります。アカウント認証後にアカウント ID を追加します。
ステップの検証ボタンを使用して、設定とハンドラーを確認します。次のステップでは、ローカルランタイムを通して自分でレスポンスを確認します。
Worker をローカルで実行してテストする
このステップでは、公開前に VM 内で Worker を実行します。Wrangler のローカルランタイムは、クラウドにデプロイを作成せずにハンドラーを実行します。
同じターミナルから HTTP リクエストを送信できるように、開発サーバーをバックグラウンドで起動します。--ip 0.0.0.0 により VM のサービスを LabEx の Web インターフェースから利用できるようになり、--port 8080 でポートを指定します。> local.log は標準出力を保存し、2>&1 はエラーを同じファイルに送り、& はサーバーの実行中にターミナルのプロンプトを返します。
npx wrangler dev --ip 0.0.0.0 --port 8080 > local.log 2>&1 &
cat local.log
ログにサーバーがポート 8080 で起動したことが表示されるまで待ちます。まだ起動中の場合は、続行する前に cat local.log をもう一度実行してください。このステップの最後までサーバーを実行したままにします。
curl を使ってリクエストを送信します。-i はレスポンスヘッダーを含めるため、ステータスと Content-Type の両方を確認できます。
curl -i http://127.0.0.1:8080/health
レスポンスには、次の安定した値が含まれます。ヘッダーの順序と大文字・小文字は異なる場合があります。
HTTP/1.1 200 OK
Content-Type: application/json
...
{"service":"labex-first-worker","status":"ok"}
アドレス 127.0.0.1 はこの VM を指します。自分のコンピューターでも、公開された Cloudflare デプロイでもありません。続行する前に、HTTP ステータス、JSON の Content-Type、2 つのレスポンスフィールドを確認してください。
開発サーバーがまだ実行されている間に、このステップの検証を完了します。
Cloudflare に認証してデプロイする
このステップでは、この VM を学習アカウントに接続し、テスト済みの Worker をデプロイします。まず、バックグラウンドジョブを確認します。jobs は、このターミナルで開始したジョブを一覧表示します。エントリには wrangler dev と表示されるはずです。
jobs
kill %1 でそのジョブを停止します。ここで %1 はこのターミナルのジョブ 1 を意味し、システムのプロセス ID ではありません。jobs に wrangler dev の別の番号が表示されている場合は、その番号を使用してください。このコマンドはジョブに終了シグナルを送信します。
kill %1
デバイス認証を開始します。読み取り用スコープはアカウントを識別するために使用し、workers_scripts:write はスクリプトのデプロイと削除を許可し、workers_tail:read はライブログの表示を許可します。--browser=false は、自分のブラウザーで開くリンクを表示します。
npx wrangler login --device --browser=false --scopes account:read user:read workers_scripts:write workers_tail:read
表示されたリンクを開き、求められた場合は Cloudflare にサインインし、現在のデバイスコードを入力して、Wrangler の権限要求を確認します。すべてのアカウントではなく、自分の学習アカウントを選択してください。同意ページには必須の Background Access も含まれます。アプリケーション、アカウント、権限を確認してから承認し、ターミナルに戻って認証が完了するまで待ちます。コードの期限が切れた場合は、ログインコマンドを再実行して新しいコードを取得してください。トークンをターミナルに貼り付けたり、認証情報ファイルを共有したりしないでください。
Account & Billing と Developer Platform を展開し、以下に示す権限名を確認します。今回の実験では Worker をデプロイし、ライブログを開くため、これらの権限は読み取り専用の接続レッスンより広い範囲を持ちます。
学習アカウントが選択されていることを確認します。別のアカウント、またはすべてのアカウントが選択されている場合は Edit を使用してください。Authorize をクリックする前に、選択内容を確認します。
このログインで利用できるアカウントを確認します。
npx wrangler whoami --json
"loggedIn": true と "authType": "OAuth Token" を確認します。accounts 配列から、学習アカウントの name を持つオブジェクトを見つけ、32 文字の id をコピーします。この実験では、その他のアカウント設定は必要ありません。アカウントが 1 つだけ表示される場合も、その名前を確認してください。複数表示される場合は、Dashboard で区別します。アカウントが見つからない場合は、目的のアカウントを選択して認証をやり直してください。
設定に account_id を追加します。実行前に、このブロックの YOUR_ACCOUNT_ID をコピーした ID に置き換えてください。この操作では、ステップ 1 の $WORKER_NAME 変数を保持したまま設定を書き直します。このターミナルを開いたままにしてください。変数を失った場合は、cat wrangler.jsonc で元の名前を確認し、その名前と完全に一致するように WORKER_NAME を先に復元します。デプロイ後に別の名前を生成したり、アカウントを変更したりしないでください。
cat > wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-09-14",
"workers_dev": true,
"preview_urls": false,
"account_id": "YOUR_ACCOUNT_ID"
}
CONFIG
cat wrangler.jsonc
一意の Worker 名を確認し、account_id を whoami --json の対象アカウントのオブジェクトと比較します。この ID はパスワードではなく設定値です。Wrangler はデプロイと削除の際にこの値を読み取ります。ここでローカルソースを公開します。
npx wrangler deploy
このアカウントにまだ workers.dev サブドメインがない場合、Wrangler は登録するかどうかを尋ねます。yes と入力し、英小文字、数字、ハイフンを使った利用可能な小文字の名前を選んで確認してください。このアカウントレベルの名前は、今後の Worker でも共有され、今回の実験で使う一意の Worker 名とは異なります。すでにサブドメインがある場合は、そのまま再利用してください。名前を変更しないでください。カスタムドメインの購入やプランのアップグレードは必要ありません。
デプロイが完了するまで待ちます。Wrangler は次の形式の URL を表示します。
https://<your-worker-name>.<your-subdomain>.workers.dev
デプロイ時に表示された実際の URL をシェル変数にコピーします。以下の例の URL 全体を置き換え、引用符は残し、末尾のスラッシュは省略してください。
WORKER_URL="https://YOUR_WORKER.YOUR_SUBDOMAIN.workers.dev"
curl -i "$WORKER_URL/health"
HTTP 200 と、ローカルテストと同じ JSON が返ることを確認します。新しいホスト名の反映に時間がかかっている場合は、少し待ってから再試行してください。エラーページはデプロイ成功を意味しません。実際の /health URL をブラウザーで開くこともできます。ブラウザーまたはネットワークが workers.dev をブロックする場合は、VM の curl 結果を使用してください。ブラウザーのセキュリティ設定を無効にしないでください。VM からのリクエストと、以下の独立した確認が必須のレスポンステストです。
次に、Cloudflare Dashboard で同じデプロイを目視確認します。ターミナルは開いたままにしてください。
アカウント切り替えメニューで学習アカウントを選択します。選択したアカウントと同じであることを確認してください。
Compute → Workers & Pages を開きます。必要に応じてアプリケーション一覧を更新し、設定に表示されている正確な labex-first-... 名を探します。アプリケーションが多数ある場合は、その完全な名前で検索してください。
その Worker を開きます。名前を確認し、workers.dev アドレスを見つけます。アドレスを wrangler deploy が表示した URL と比較してください。
これらのスクリーンショットはデプロイ例です。ランダムに生成された Worker のサフィックスとアカウントのサブドメインは異なります。例をコピーせず、自分の値を確認してください。Dashboard は、ターミナルから作成したリソースを別の画面で表示するものです。ここで 2 つ目の Worker を作成したり、コードを編集したりしないでください。Worker が見つからない場合は、まず選択したアカウント、正確な名前、デプロイコマンドが完了したかを確認します。
アプリケーション一覧はクラウドリソースが存在することを確認します。curl でテストした HTTP レスポンスは、そのコードが動作していることを確認します。自分でスクリーンショットを撮ったり、提出したりする必要はありません。
ステップの検証ボタンを使用します。独立したバックエンドチェックは、選択したアカウントの Worker 設定を読み取り、公開エンドポイントをテストします。そのため、別の Web サイトが似たテキストを返しても検証を満たすことはできません。
ライブリクエストログを確認する
このステップでは、ライブログストリームに接続し、ハンドラーが出力したメッセージを探します。ログストリームに接続している間に受信したリクエストだけが表示され、接続前のリクエストは再生されません。
Wrangler tail をバックグラウンドで開始します。--format json は構造化イベントを生成します。今回は標準出力とエラーを別々のファイルに送り、診断テキストがイベントデータに混ざらないようにします。
npx wrangler tail --format json > requests.json 2> tail-errors.log &
接続の初期化に数秒待ってから、新しいリクエストを送信します。
curl -i "$WORKER_URL/health"
イベントファイルには大量のリクエストメタデータも含まれます。head -n 32 は先頭 32 行を表示するため、最初のイベントとアプリケーションメッセージに注目できます。
head -n 32 requests.json
outcome が ok と等しく、/health で終わる GET リクエストと、health-request を含むコンソールメッセージを持つイベントを探します。その他のフィールド、タイムスタンプ、リクエストヘッダーは異なる場合があります。ファイルが空の場合は、tail-errors.log を確認し、接続を待ってから、もう一度リクエストを送信してファイルを読み直してください。
保存されたイベント全体を検証する前に tail を停止します。jobs を確認し、wrangler tail に表示された番号を使用してください。前のジョブが停止していれば、通常は 1 です。
jobs
kill %1
ステップの検証ボタンを使用して、取得したイベントをデプロイ済み Worker と照合します。
ファイルにはリクエストメタデータが含まれる場合があります。この VM 内に保持し、スクリーンショットとして公開したり、公開リポジトリに提出したりしないでください。
テスト用 Worker を削除する
このステップでは、管理用の認証が有効なうちに、テスト用 Worker だけを削除し、結果を確認します。VM を削除しても、デプロイ済みの Worker は削除されません。
プロジェクトの設定をもう一度確認し、name がこの実験で使用した一意の labex-first-... 名であることを確認します。
cat wrangler.jsonc
プロジェクトの設定を使用して、その Worker を削除します。
npx wrangler delete
確認プロンプトを読み、正確な名前を確認してから、y を押して確定します。強制削除を使用したり、別のプロジェクトを削除したりしないでください。通常、Wrangler は Worker が削除されたことを報告します。固定バージョンと今回のスコープ付き権限では、Worker を削除した後に /storage/kv/namespaces に対する認証エラーが表示される場合があります。これは、クリーンアップ中に Wrangler が従来の Workers Sites ストレージも確認するためです。今回の実験では KV namespace を作成していません。この診断を修正するために、提案されたすべての権限を付与したり、デプロイを繰り返したりしないでください。Worker が実際に削除されたかどうかは、このステップの検証ボタンで確認します。その他のエラーについては調査が必要です。
Cloudflare Dashboard で学習アカウントの Workers & Pages を開き、一覧を更新します。正確な Worker 名が表示されないことを確認します。その後、ステップの検証ボタンを使って独立した API チェックを実行します。
このチェックには、認証済みインベントリレスポンスが正常に返ることが必要です。ネットワークリクエストの失敗やログイン期限切れは、削除済みとはみなされません。学習アカウントとアカウントレベルの workers.dev サブドメインは、後の実験でも利用できます。ログアウトする前に、このステップの検証を完了してください。
VM の接続を解除する
このステップでは、クラウドのクリーンアップを確認した後、Wrangler に保存された認証を削除します。ローカルのソースファイルは VM に残りますが、アカウントへのアクセスを認証することはできなくなります。
npx wrangler logout
npx wrangler whoami --json
"loggedIn": false を探します。ログアウト後、このバージョンの Wrangler はゼロ以外の終了コードで終了します。これは想定された動作です。この明示的な状態が表示されず、ネットワークエラーだけが表示される場合は、ログアウトの証明にはなりません。ステップの検証ボタンを使用して独立に確認してください。
ブラウザーでは Cloudflare Dashboard にサインインしたままでもかまいません。ブラウザーのログインと、この VM の Wrangler 認証は別のものです。次の実験では新しい VM を使用し、独自の認証を要求します。
まとめ
Worker の fetch ハンドラーと設定を作成し、JSON レスポンスをローカルでテストしました。その後、自分の学習アカウントにデプロイして、ライブリクエストログを確認しました。公開レスポンスと所有権を独立に検証し、認証済みの状態でテスト用 Worker を削除して、VM からログアウトしました。
詳細については、Cloudflare の Wrangler commands、fetch handler、workers.dev configuration を参照してください。
