「Cloudflareって名前はよく聞くけど、結局なにができるの?」「AWSやAzureは触ったことがあるけど、Cloudflareは何から始めればいいのか分からない」——そんなモヤモヤを抱えていませんか。CDNやDNSのイメージが強い一方で、最近はアプリの実行基盤としても存在感を増しています。とはいえ公式ドキュメントは英語が中心で、最初の一歩を踏み出しにくいのも事実です。
この記事では、Cloudflareの全体像と他のクラウドとの違いを押さえたうえで、アカウント開設から「Hello World」ページをインターネットに公開するまでを、Windowsとブラウザの操作だけで体験します。Node.jsのインストールは不要で、コマンド操作も必須ではありません。
できるようになること
この記事の手順を最後まで実施すると、次のことができるようになります。
- Cloudflareアカウントを作成し、2要素認証で保護できる
- サーバーレス実行環境「Cloudflare Workers」を、ブラウザだけで作成・デプロイできる
- 自分で書いたHTMLページを
https://<Worker名>.<サブドメイン>.workers.devというURLでインターネットに公開できる - 表示されたページから、どの拠点(データセンター)でリクエストが処理されたかを確認できる
サーバーの構築やOSの管理、SSL証明書の設定は不要です。また、Workersの無料プランには1日あたり100,000リクエストの枠があり、本記事の範囲はすべて無料で完結します(Workers Pricing)。
完成イメージ(全体構成)
完成イメージ(ブラウザに表示されるページ)
URL: https://hello-cloudflare.<サブドメイン>.workers.dev
------------------------------------------------------------
Hello World!
Cloudflare Workers からこのページを配信しています。
このリクエストを処理した拠点: NRT
------------------------------------------------------------
最後の行の「NRT」は、リクエストを処理したCloudflareのデータセンターを表す3文字の空港コードです(Request - IncomingRequestCfProperties)。どの拠点で処理されるかは、アクセス元の場所や回線の経路によって変わります。
Cloudflareとは?他のクラウドとの違い
Cloudflareは、世界中に分散した自社ネットワークの上で、Webサイトの高速化(CDN)、DNS、セキュリティ、そしてアプリケーションの実行基盤までを提供するサービスです(What is Cloudflare?)。公式サイトでは、348都市にデータセンターを持ち、13,000以上のネットワークと相互接続していると案内されています(Cloudflare Global Network)。
AWSやAzure、Google Cloudが「リージョン(特定の地域のデータセンター群)を選んで、その中にシステムを組み立てる」クラウドだとすれば、Cloudflareは「世界中に張り巡らされたネットワークそのものが実行環境になる」クラウドだとイメージすると分かりやすいでしょう。
ネットワーク・パフォーマンス(CDN/DNS)
- CDN:閲覧者に近い拠点からコンテンツを配信し、表示までの遅延を減らします
- DNS:ドメインの権威DNSに加え、誰でも使える無料のDNSリゾルバー「1.1.1.1」も提供しています(What is Cloudflare?)
セキュリティ
- DDoS防御:L3/L4/L7のDDoS攻撃に対する防御を、すべてのプラン・すべてのサービスで、通信量の上限なく提供しています(About Cloudflare DDoS protection)
- ボット・不正アクセス対策:悪意のあるボットや不正な侵入からWebサイトを保護します
- ゼロトラスト(Cloudflare One):Cloudflare Accessなどを使い、社内アプリや開発中のサイトに認証をかけられます(Cloudflare One)
開発者プラットフォーム(Workersなど)
本記事で使うのがこの領域です。
- Workers:サーバーレスの実行環境です。コンテナや仮想マシンではなく、V8エンジンの「isolate」という軽量なサンドボックスでコードを動かすため、仮想マシン型のコールドスタートがなくなるとされています。公式ドキュメントでは、isolateはコンテナや仮想マシン上のNodeプロセスよりおよそ100倍速く起動できると説明されています(How Workers works)
- 静的アセット配信:WorkersでHTMLや画像などの静的ファイルも配信でき、静的アセットへのリクエストは無料・無制限です(Workers Pricing)
- データストア:S3互換APIを持つオブジェクトストレージのR2、サーバーレスSQLデータベースのD1、キーバリューストアのWorkers KVなどがあります
静的サイト向けには「Cloudflare Pages」もありますが、公式のベストプラクティスでは、新規プロジェクトではPagesではなくWorkersを使うよう推奨されています(Workers Best Practices)。また、手元のHTMLフォルダをドラッグ&ドロップするだけで公開できる「Cloudflare Drop」も2026年7月に提供が始まっています(Changelog)。
他のクラウドサービスとの比較
代表的なリージョン型クラウドとして、AWSのサーバーレス(Lambda)と比べると次のような違いがあります。
| 観点 | Cloudflare(Workers) | AWS(Lambdaなど) |
|---|---|---|
| コードが動く場所 | リクエストを受けたデータセンター(世界中の拠点)で実行(How Workers works) | 利用者が選んだリージョンで実行 |
| 実行方式 | 既存のランタイム内に軽量なisolateを作成 | 隔離された実行環境(Execution environment)を作成(AWS Lambda ドキュメント) |
| コールドスタート | 仮想マシン型のコールドスタートを排除する設計 | 利用できる実行環境がないときに新しい環境を作るため発生する(同上) |
| インターネットへのデータ転送料 | 静的アセットへのリクエストは無料・無制限。R2はエグレス(外向き転送)料金なし(R2 Pricing) | 全サービス合計で月100GBまで無料、それを超えると従量課金(AWS Global Network FAQ) |
| 得意な領域 | Webの入口(配信・セキュリティ・軽量なAPI)をまとめて担う | 仮想マシン、各種データベース、分析、機械学習など幅広いサービスで大規模システムを構築する |
なお、AWSにもCloudFront FunctionsやLambda@Edgeといったエッジで処理を動かす仕組みはあります。違いは、Cloudflareでは「エッジで動かす」ことが標準の前提になっており、配信・セキュリティ・実行環境が1つのネットワークにまとまっている点です。
Cloudflareを使うメリットと注意点
メリット
- 始めやすい:アカウント作成に必要なのはメールアドレスとパスワードだけで(Create account)、ブラウザ操作だけで数分でWebページを公開できます
- 速い:世界中の拠点でコードが動くため、閲覧者がどこにいても近い場所で処理されます
- コストが読みやすい:転送量に応じた課金を気にしなくてよい場面が多く、個人開発や検証で予期せぬ請求が起きにくい構成をとれます
- セキュリティが標準装備:DDoS防御が無料プランを含む全プランで使えます
注意点
- 無料プランのWorkersは、1回の呼び出しあたりのCPU時間が10ミリ秒までです(Workers Pricing)。重い計算処理や長時間のバッチ処理には向きません
- 無料プランで1日のリクエスト上限を超えると「Error 1027」が返ります。カウンターはUTCの0時(日本時間の9時)にリセットされます(Workers Limits)
-
workers.devは個人・趣味用途向けの位置づけで、本番運用では独自ドメインの利用が推奨されています(workers.dev) - 仮想マシンや大規模なリレーショナルデータベースのような汎用インフラは、AWSなどのほうが選択肢が豊富です。どちらか一方ではなく、「Webの入口はCloudflare、バックエンドは既存クラウド」と併用する構成もよく採られます
用意するもの
ハンズオンを始める前に、次の前提条件がそろっているかチェックしてください。
2要素認証用の認証アプリ(推奨)
インターネットに公開するサービスを持つアカウントは、乗っ取られると被害が大きくなります。Cloudflareではパスワードに加えて2要素認証(2FA)を設定できます(Two-factor authentication)。
本記事では、スマートフォンの認証アプリ(TOTP方式)を使います。次の手順で準備してください。
- スマートフォンのApp StoreまたはGoogle Playを開く
- 「Google Authenticator」や「Microsoft Authenticator」など、TOTPに対応した認証アプリをインストールする
Cloudflareは、少なくとも2種類の異なる2要素認証を有効にすることを推奨しています。認証アプリのほかに、セキュリティキー(YubiKeyなど)やメール認証も利用できます。
実際にやってみる
ここからが実行手順の全体です。上から順番に進めてください。
本記事は2026年10月時点の公式ドキュメントと画面構成に基づいています。Cloudflareのダッシュボードは頻繁に更新されるため、ボタン名や配置が変わっている場合は、各手順に記載した公式ドキュメントのリンク先を正としてください。
1. Cloudflareアカウントを作成する
Cloudflareのすべての機能は、アカウントにひもづいて管理されます。まずは無料のアカウントを作成し、メールアドレスの認証まで済ませます。
1-1. サインアップページを開く
Cloudflareのアカウント作成画面を開きます(Create account)。
- ブラウザで https://dash.cloudflare.com/sign-up を開く
1-2. メールアドレスとパスワードを登録する
ログインに使うメールアドレスとパスワードを登録し、アカウントを作成します。
- Email にメールアドレス、Password にパスワードを入力する
- Create Account を選択する
Google、Apple、GitHubのアカウントでサインインする方法もあります。Cloudflareに未登録のメールアドレスでこれらのサインインを選ぶと、その場で新しいアカウントが作成されます(Log in to Cloudflare)。
1-3. メールアドレスを認証する
登録したメールアドレスが本人のものであることを確認します。アカウントを作成すると、Cloudflareから認証メールが自動で送信されます(Verify email address)。
- メールソフトでCloudflareからのメールを開く
- メール内のリンクを選択する
- Cloudflareにログインして認証を完了する
メールが届かない、リンクがうまく動かないといった場合は、ハマりどころ1を参照してください。
1-4. アカウント名を変更する(任意)
アカウント名は、初期状態では「(メールアドレス)'s Account」になっています。用途が分かる名前にしておくと、複数のアカウントを扱うときに区別しやすくなります(Create account)。
- ダッシュボードで Manage account > Configurations ページを開く
- Account Name の横にある Change Name を選択する
- 新しいアカウント名を入力し、Save を選択する
2. アカウントのセキュリティを強化する
これから作るページはインターネットに公開されます。アカウントを乗っ取られて内容を書き換えられないよう、公開作業の前に2要素認証を設定しておきます。公式の学習コンテンツでも、アカウント作成直後に2要素認証を有効にする流れになっています(Create a Cloudflare account)。
2-1. 認証アプリで2要素認証を設定する
ログイン時に、パスワードに加えて認証アプリに表示される6桁のコードを求めるようにします(Two-factor authentication)。
- ダッシュボード右上のアカウントアイコンから Profile を選択する
- Access Mnagement > Authentication を選択する
- Mobile App Authentication の Add を選択する
- 表示されたQRコードをスマートフォンの認証アプリで読み取り、アプリに表示されたコードを入力する(読み取れない場合は Can't scan QR code, Follow alternative steps を選択)
- 画面の指示に従ってCloudflareのパスワードを入力し、Next を選択する
- バックアップコードが表示されたら、次の手順で保管してから Next を選択して完了する
なお、Googleアカウントなどで登録した場合はCloudflareのパスワードがありません。その場合はログイン画面でパスワードを忘れた場合の手続きで登録します。

2-2. バックアップコードを安全に保管する
スマートフォンを紛失した場合でもログインできるように、バックアップコードを保管します(Two-factor authentication)。
- バックアップコードの画面で Download、Print、Copy のいずれかを選択する
- パスワードマネージャーなど、安全な場所に保存する
バックアップコードは1つにつき1回しか使えません。また、再発行(Regenerate)すると以前のコードは無効になります。
3. Hello World Workerをデプロイする
まずはCloudflareが用意しているテンプレートをそのまま公開し、「Workerを作る → デプロイする → URLが発行される」というWorkersの基本の流れをつかみます。
3-1. Workers & Pages を開く
Workersを管理する画面を開きます。
- ダッシュボードの左メニューから Workers & Pages を選択する(メニューが見つからない場合は Workers & Pages への直接リンク を開く)
この画面の Your subdomain に表示されているのが、あなたのアカウントに割り当てられた workers.dev のサブドメインです(workers.dev)。
3-2. Hello Worldテンプレートを選ぶ
「Hello World!」という文字列を返すだけの、最小構成のWorkerを作成します(D1 Getting started)。
- Create application を選択する
- Start with Hello World! の Get started を選択する
3-3. Worker名を決めてデプロイする
Workerに名前を付けてデプロイします。Worker名はそのまま公開URLの一部になります。
- Workerの名前入力欄に
hello-cloudflareと入力する(ランダムな名前が入力済みの場合は書き換える) - Deploy を選択する
workers.dev で公開するWorker名には、「63文字以内」「英数字とハイフンのみ」「先頭と末尾はハイフン不可」という制約があります(workers.dev)。名前でエラーになる場合は、ハマりどころ2を参照してください。
このときデプロイされるテンプレートのコードは、おおむね次のような内容です。
worker.js(Hello Worldテンプレートの例)
export default {
async fetch(request, env, ctx) {
return new Response("Hello World!");
},
};
Workerは fetch という関数(ハンドラー)を持つオブジェクトを export default で公開します。HTTPリクエストが届くたびにこの関数が呼ばれ、戻り値の Response がそのまま閲覧者に返されます(Get started - CLI)。
3-4. 公開URLを確認する
デプロイしたWorkerがどのURLで公開されたかを確認し、実際に開いてみます。URLは https://<Worker名>.<サブドメイン>.workers.dev の形式です(workers.dev)。
- Workers & Pages の一覧から
hello-cloudflareを選択する -
Settings > Domains & Routes を開き、
workers.devの行に表示されたURLを確認する - URLを選択して開き、「Hello World!」と表示されることを確認する
URLにアクセスできない場合は、ハマりどころ3を参照してください。
サブドメインは自動で割り当てられ、公開URLにそのまま含まれます。公開して問題のない名前か確認し、変更したい場合は Workers & Pages 画面の Your subdomain の横にある Change から変更します(workers.dev)。サブドメインを変更すると、このアカウントで workers.dev を使っているすべてのWorkerのURLが変わる点に注意してください。
4. HTMLページに書き換えて公開する
テンプレートのままでは、ただの文字列(テキスト)が返されるだけです。ここではコードを書き換えてHTMLページを返すようにし、あわせて「どの拠点で処理されたか」を表示して、世界中の拠点でコードが動いていることを体感します。
4-1. コードエディタを開く
ブラウザ上のコードエディタで、Workerのコードを直接編集できるようにします(D1 Getting started)。
- Workers & Pages の一覧から
hello-cloudflareを選択する -
Edit code(
</>アイコン)を選択する
4-2. worker.js をHTMLを返すコードに置き換える
エディタに表示されているファイル(worker.js)の中身をすべて削除し、次のコードを貼り付けます。公式サンプル「Return HTML」をベースに、処理した拠点を表示する処理を加えたものです(Return HTML)。
worker.js(置き換え後のコード)
export default {
async fetch(request, env, ctx) {
// リクエストを処理したデータセンターの空港コード(例: NRT)
// ダッシュボードのプレビューでは request.cf が使えないため「不明」と表示する
const colo = request.cf?.colo ?? "不明";
const html = `<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Hello World from Cloudflare</title>
</head>
<body>
<h1>Hello World!</h1>
<p>Cloudflare Workers からこのページを配信しています。</p>
<p>このリクエストを処理した拠点: <strong>${colo}</strong></p>
</body>
</html>`;
return new Response(html, {
headers: {
"content-type": "text/html;charset=UTF-8",
},
});
},
};
ポイントは次の2つです。
-
content-typeヘッダーにtext/html;charset=UTF-8を指定し、ブラウザにHTMLとして解釈させています。指定しないと、タグがそのまま文字として表示されることがあります -
request.cf.coloには、リクエストを処理したデータセンターの3文字の空港コードが入ります(Request)。?.と??を使い、値がない環境でもエラーにならないようにしています
4-3. プレビューで表示を確認する
デプロイする前に、エディタのプレビュー画面で表示を確認します。
- エディタのプレビュー領域に「Hello World!」の見出しと本文が表示されることを確認する
このとき「処理した拠点」は「不明」と表示されますが、これは想定どおりの動きです。理由はハマりどころ5を参照してください。
4-4. デプロイして本番に反映する
編集したコードを本番環境に反映し、公開URLから見えるようにします。
- エディタ右上の Deploy を選択する
Deploy の横にある▼から Save を選ぶと、本番には反映せずに保存だけできます。保存したバージョンは、Workerの Deployments の Version History から Deploy version を選び、続く画面で Deploy を選択すると本番に反映されます(Workers KV Getting started)。
5. インターネットに公開されたことを確認する
自分のPCだけでなく、誰でも・どこからでもアクセスできる状態になっているかを確かめます。
5-1. ブラウザで公開URLにアクセスする
手順3-4で確認したURLを開き、書き換えたページが表示されることを確認します。
- ブラウザで
https://hello-cloudflare.<サブドメイン>.workers.devを開く - 「Hello World!」の見出しと、「このリクエストを処理した拠点」に3文字のコード(例:NRT)が表示されることを確認する
URLは https:// で始まり、証明書を自分で用意しなくても暗号化された通信になっています。古い「Hello World!」の文字だけが表示される場合は、ハマりどころ6を参照してください。
5-2. 別のネットワークから確認する
社内ネットワークや自宅の回線に限らず、インターネット全体に公開されていることを確認します。
- スマートフォンのWi-Fiをオフにし、モバイル回線に切り替える
- スマートフォンのブラウザで同じURLを開き、ページが表示されることを確認する
アクセス元の回線によっては、PCとは異なる拠点のコードが表示されることもあります。
5-3. レスポンスヘッダーを確認する(任意)
ブラウザの開発者ツールで、Cloudflareを経由して配信されていることを確認します。
- 公開URLを開いた状態で F12 キーを押し、開発者ツールを開く
- ネットワーク(Network)タブを選択し、F5 キーでページを再読み込みする
- 一覧の先頭にあるリクエストを選択し、応答ヘッダー(Response Headers)を確認する
content-type が text/html;charset=UTF-8 になっていること、cf-ray ヘッダーが付いていることを確認します。cf-ray は「Ray ID」とも呼ばれ、レスポンスヘッダーとして表示される場合は、リクエストを処理したデータセンターを識別する値になります(Cloudflare HTTP headers)。
コマンドで確認したい場合は、PowerShellで次のように実行します。Windows PowerShell 5.1では curl が Invoke-WebRequest の別名になっているため、curl.exe と拡張子まで指定するのがポイントです。
PowerShell(レスポンスヘッダーの確認)
curl.exe -sI https://hello-cloudflare.<サブドメイン>.workers.dev
おつかれさまでした。これで、あなたが書いたHTMLページがCloudflareのネットワークからインターネットに公開されました。
ハマりどころと対処法
1. 認証メールが届かない/リンクが機能しない
【発生するトラブル/エラー】
アカウント作成後、Cloudflareからの認証メールが見当たらない。またはメール内のリンクを開いても認証が完了しない。
【原因】
迷惑メールフォルダへの振り分け、メールの紛失やリンクの期限切れ、すでに認証済みであることなどが考えられます(Verify email address)。
【対応手順】
- メールソフトの迷惑メールフォルダを確認する
- 見つからない場合は、ダッシュボードの Account home から My Profile を開き、Email Address の Send verification email を選択して再送する(この項目が表示されない場合は、すでに認証済みです)
- リンクが機能しない場合は、My Profile のメールアドレスの後ろに「(verified)」と表示されているか確認する。表示されていなければ、別のブラウザやプライベートウィンドウでリンクを開くか、認証メールを再送する
2. Worker名でエラーになる/Deployできない
【発生するトラブル/エラー】
Worker名の入力欄でエラーが表示される。または Deploy ボタンが押せない。
【原因】
workers.dev で公開するWorker名は、URLの一部(DNSラベル)として使われます。そのため「63文字以内」「英数字とハイフンのみ」「先頭と末尾はハイフン不可」という制約があり、これに違反するとデプロイできません(workers.dev)。
【対応手順】
- 日本語、アンダースコア(
_)、ドット(.)、スペースなどを含んでいないか確認する -
hello-cloudflareのように、小文字の英数字とハイフンだけの名前に付け直す - 名前に問題がないのに押せない場合は、時間をおいてページを再読み込みし、Cloudflare Status で障害が発生していないか確認する
3. 公開URLにアクセスしても表示されない
【発生するトラブル/エラー】
公開URLを開くと「このサイトにアクセスできません」「DNS_PROBE_FINISHED_NXDOMAIN」などのエラーが表示される。
【原因】
主に次の3つが考えられます。
- Worker名やサブドメインの入力ミス
- そのWorkerで
workers.devのルートが無効になっている(workers.dev) - デプロイ前やサブドメイン変更前に同じURLへアクセスしたため、DNSリゾルバーに「存在しないホスト名」という結果がキャッシュされている(ネガティブキャッシュ)。この場合、キャッシュの保持期間が過ぎるまで新しいレコードが安定して引けません(Troubleshooting DNS issues)
【対応手順】
- Workerの Settings > Domains & Routes に表示されている
workers.devのURLをコピーし、そのまま開く - 同じ画面で
workers.devの状態を確認し、無効になっている場合は有効に戻す - それでも開けない場合は、しばらく時間をおいてから再読み込みするか、スマートフォンのモバイル回線など別のネットワークから開いてみる
なお、PC側のDNSキャッシュは次のコマンドで消去できます。ただし消去されるのは手元のPCのキャッシュだけで、プロバイダーなど上流のDNSリゾルバーのキャッシュには影響しません(Troubleshooting DNS issues)。
PowerShell(PCのDNSキャッシュを消去する)
ipconfig /flushdns
4. 日本語が文字化けする/HTMLのタグがそのまま表示される
【発生するトラブル/エラー】
ページを開くと <h1> などのタグが文字としてそのまま表示される。または日本語が文字化けする。
【原因】
レスポンスの content-type ヘッダーを指定していないか、文字コード(charset)の指定が漏れています。ヘッダーを指定せずに文字列を返すと、テキストとして扱われます。
【対応手順】
- 手順4-1の要領でコードエディタを開く
-
new Response()の第2引数に"content-type": "text/html;charset=UTF-8"が指定されているか確認する(Return HTML) - HTMLの
<head>内に<meta charset="UTF-8">があるか確認する - 修正したら Deploy を選択して本番に反映する
5. プレビューで拠点が不明と表示される
【発生するトラブル/エラー】
コードエディタのプレビューでは、「このリクエストを処理した拠点」が「不明」と表示される。
【原因】
request.cf オブジェクトは、ダッシュボードのコードエディタやPlaygroundのプレビューでは利用できない仕様です(Request)。
【対応手順】
- 不具合ではないため、そのまま Deploy する
- 公開URL(
https://hello-cloudflare.<サブドメイン>.workers.dev)で開き、拠点コードが表示されることを確認する
request.cf.colo を ?. を使わずに参照すると、プレビューでエラーになる場合があります。本記事のコードのように request.cf?.colo ?? "不明" と書いておくと安全です。
6. 書き換えたのに古いHello Worldのまま表示される
【発生するトラブル/エラー】
コードを書き換えたのに、公開URLでは「Hello World!」という文字だけのページが表示される。
【原因】
Save(保存のみ)で作業を終えていて、本番にデプロイされていない可能性があります。保存したバージョンは、デプロイするまで本番には反映されません(Workers KV Getting started)。
【対応手順】
- Workers & Pages の一覧から
hello-cloudflareを選択する - Deployments を開き、Version History の表で最新のバージョンの Deploy version を選択する
- 続く画面で Deploy を選択する
- ブラウザで Ctrl + F5 キーを押し、公開URLを再読み込みする
7. URLを開くとログイン画面が表示される
【発生するトラブル/エラー】
公開URLを開くと、ページの代わりにCloudflareのログイン画面(認証画面)が表示され、ほかの人が閲覧できない。
【原因】
workers.dev のURLやプレビューURLに、Cloudflare Accessによるアクセス制御(認証の要求)が設定されています。Accessを使うと、閲覧できる人を自分やチームなどに限定できます(workers.dev - Manage access)。
【対応手順】
- Workerの Settings > Domains & Routes を開き、
workers.devのアクセス制御の設定を確認する - 誰でも閲覧できる状態にしたい場合は、アクセス制御を無効にする
- ログイン画面を表示したまま限定公開にしたい場合は、設定を残したままアクセスポリシーで閲覧者を指定する(Access policies)
8. Error 1027 が表示される
【発生するトラブル/エラー】
公開URLを開くと「Error 1027」が表示される。
【原因】
無料プランの1日あたりのリクエスト上限(100,000リクエスト)を超えています(Workers Limits)。
【対応手順】
- カウンターはUTCの0時(日本時間の9時)にリセットされるため、それまで待つ
- 継続的に上限を超える見込みがある場合は、有料プランへの移行を検討する(Workers Pricing)
おわりに
この記事では、Cloudflareの全体像と他のクラウドとの違いを整理したうえで、アカウント開設から2要素認証の設定、Workersを使ったHello Worldページの公開までを、ブラウザ操作だけで体験しました。表示された拠点コードを見ると、自分のコードが世界中のネットワーク上で動いていることを実感できたのではないでしょうか。
次のステップとして、独自ドメインの設定やR2・D1との連携、CLI(Wrangler)を使った開発にもぜひ挑戦してみてください。最後まで読んでいただき、ありがとうございました。
X(旧Twitter)でもクラウドや開発に関する情報を発信しています。よろしければフォローをお願いします!
https://x.com/tamaoki_tk