Cloudflare 2026年5月時点・採用判断ガイド

結論(一行で)

Cloudflare は依然第一候補。ただし新規構築は Pages 単体ではなく Workers + Static Assets を本命に据え、スタッフ限定は Cloudflare Access（50ユーザー無料）、購入者限定は Cloudflare 単体で考えない（決済・会員管理サービス併用）。当初の「Pages か Access か」という二者択一は、2025-04-08 の Cloudflare 公式方針転換（新規・将来投資は Workers 中心）以降、組み合わせ問題へと拡張した。

要点(5つ)

Pages の評価は依然高い — Gartner Peer Insights 4.7/5（16件・2026年1月更新）、Product Hunt 5.0/5（20件）、devtoolreviews.com で Vercel 8.8 に対し Cloudflare Pages 8.7。実ユーザーは「無制限帯域がヤバい」「コスパ最強」「Netlifyから移行して驚くほど良い」と評価。
ただし Cloudflare 公式は「新規・将来投資は Workers 中心」と明言 — 2025-04-08 の公式ブログ "Full-stack development on Cloudflare Workers" 以降、Pages → Workers + Static Assets への公式移行ガイドが提供されている。既存 Pages は継続サポート（"Cloudflare Pages will continue to be supported"）だが、Durable Objects / Workflows / 詳細オブザーバビリティ等の新機能は Workers 中心。
検討軸は「Pages か Access か」から「Workers + Static Assets + Access + Wrangler/MCP の組合せ」へ — Pages は置き場所、Access は認証で、そもそも役割が違う（ホスティング vs セキュリティ）。
用途別に最適サービスが異なる — ①公式サイト・SEO ②スタッフ限定 ③購入者限定で別解。Cloudflare 単体で③に挑むのは危険。
無料枠は静的中心・50ユーザー以内なら現実的に運用可能 — Workers Free は 1日 100,000 リクエスト、静的アセットへのリクエストは無料・無制限。Cloudflare Access は 50 ユーザーまで時間制限なしで無料。2026年5月時点で Workers 関連の $5/月プランも登場。

図解 — 用途別の採用可否マップ

この文書全体の核心は 「3つの用途で最適なサービス組が異なる」 ことにある。下図は、①公式サイト・SEO ②スタッフ限定 ③購入者限定の3用途について、推奨サービス組と Cloudflare 単体での採用可否を1枚に集約したもの。

図の読み方: 左から右へ「公開度」が下がっていく順に並んでいる。①は誰でも見える、②は許可された人だけ、③は購入者だけ。各列の中段に「必要なサービス組」、下段に「Cloudflare 単体での採用可否」を示した。注目点: ③だけ Cloudflare の枠から外れた追加サービス（Stripe / Auth 等）が必要になる。

Cloudflare 公開基盤 Cloudflare 補助サービス Cloudflare 外の追加サービス

図1: 3用途別の採用可否マップ。①②は Cloudflare で完結、③だけ外部サービスとの組み合わせが必要になる。

この図のビジュアルを強化したい場合 → ChatGPT/GPT Image 用プロンプト

強化推奨ケース: 決裁者プレゼン、保護者向け説明会、note 記事のサムネなど、外部の人に「Cloudflare で何ができて何ができないか」を一目で伝えたい場面。現状の SVG は判断材料としては十分だが、もう少し印象に残るビジュアルにしたい時に使う。

Style: minimalist editorial infographic, warm beige background #FAF8F4.
Accent colors only: deep red #8B2635, teal #5BA89E, gold #B8985A, soft gray.
No text anywhere in the image. 16:9 aspect ratio.

Subject: A horizontal three-column composition representing three different
levels of website accessibility, arranged left to right from "most open" to
"most restricted":

1. Left column: An open plaza with a tall, elegant glass storefront. A few
   stylized search-engine spider icons walk freely toward the building. The
   building glows softly with teal light. Conveys "public, SEO-friendly,
   anyone can enter."

2. Middle column: A modest building behind a low decorative gold gate. A
   small group of figures with key-shaped silhouettes approach the gate;
   one inserts a key while a search-engine spider bounces off the gate.
   The building's interior glows warm teal through the windows.
   Conveys "members-only, limited but welcoming."

3. Right column: The same kind of building, but it is connected by thin
   glowing wires to three small external satellite boxes floating above it
   (payment, identity, database). Without those satellites, the building
   has no light. A dashed red boundary encircles the satellites to indicate
   they live outside the main system.
   Conveys "paid-access requires components from outside the core platform."

Below all three columns: a long thin warm-beige ribbon that visually ties
them together, suggesting they are all variants of one platform with
different configurations.

Soft shadows, slightly grainy texture, hand-drawn line quality but precise
geometry. Editorial illustration style, not cartoonish, not photorealistic.

使い方: このプロンプトを ChatGPT に貼り、生成画像を assets/images/figure_usecase.png として保存。図解スロット内の SVG を <img src="../../assets/images/figure_usecase.png"> に置き換えるか、SVG の上に重ねて使う。注意: 文字や記号は画像に含めないこと。説明文や凡例は HTML 側で別途追加する。

当初の論点と拡張後の論点 — 何が変わったか

トミタコーチは当初「Pages か Access か」で迷っていた。だが Cloudflare 自身の方針転換と AI エージェント連携の進展により、検討対象が広がった。下表は7観点で時系列を対比したもの。

局面	当初の見方	拡張後の見方(2026-05時点)
Webページを置く場所	Cloudflare Pages でよいか	新規なら Workers + Static Assets も候補。Pages は試用・既存運用の入り口
社内限定にする方法	Access を使うか	Access は AIエージェント時代の認証基盤にもなる(Managed OAuth, 2026-03-20)
Claude Code 連携	Pages にアップできるか	Wrangler / MCP / Cloudflare Skills で Cloudflare 全体を AI から操作する話に拡張
長期安定性	Pages の評判を見る	Cloudflare の投資先が Workers へ移っているかを見る
最初の導入	Pages か Access か	Workers/Pages + Access の組み合わせを考える
役割の理解	Pages = 静的、Workers = 動的	Workers が静的サイト公開まで担う中心基盤に進化(2024 Builder Day)
認証の範囲	ログイン制限	AIエージェント・CLI・SDK の OAuth 2.0 認証まで(2026-03-20 Managed OAuth)

主要サービスの位置づけ

「Pages か Workers か Access か」を判断する前に、それぞれの今の立ち位置を押さえる。

Cloudflare Pages — 既存運用は継続OK / 新規本命視はしない

静的サイト公開に特化して始まったサービス。今は「既存の静的サイト公開・簡単な導入口としてはまだ使える」立ち位置。

評価(2026年1月〜5月)

Gartner Peer Insights: 4.7/5(16件、2026-01更新)「高速・信頼性が高く、開発者フレンドリー」
Product Hunt: 5.0/5(20件)— Git連携自動ビルド・デプロイ、Workers/DNS/セキュリティ統合が評価
devtoolreviews.com 2026年比較: 8.7前後(Vercel 8.8前後)パフォーマンスとコストで優位
実ユーザー声(Reddit / Medium / X): 「Netlifyから移行して驚くほど良い」「無制限帯域がヤバい」「コスパ最強」(2025〜2026年)

強み

無料ティアの寛大さ — 無制限帯域、ビルド回数・プレビューURL実用的
グローバルパフォーマンス — エッジ 300以上、TTFB 50ms未満クラス。R2(egress無料)組み合わせで配信が極めて安価・高速
デプロイ体験 — Git連携、ブランチ/PRごとプレビューURL、HTTPS自動、カスタムドメイン容易
エコシステム統合 — Pages Functions + Workers、D1/KV/R2/AI とシームレス連携

弱み・懸念点

将来性(最重要): 2026年現在、Cloudflare は Pages を Workers(Static Assets)へ統合中。新機能(Durable Objects、Workflows、詳細オブザーバビリティ)は Workers 中心。公式移行ガイドあり(2026年4月時点)。"deprecated" は exaggeration だが、長期的に Workers を意識した方が無難。
Next.js 対応: OpenNext アダプターで大部分動作するが、Vercel の「ゼロコンフィグ」ほどシームレスではない
実運用での小さなつまずき: DNS設定(www サブドメイン等)、_redirects や .html の自動308リダイレクトが SEO や旧URLに影響、高度な設定時のドキュメントが散漫

Cloudflare Workers + Static Assets — 新規構築の本命

Workers は 2017年 正式リリースの老舗。「+ Static Assets」の「+」は併用の意味で、Workers という実行基盤の中で Static Assets 機能を使い HTML/CSS/画像等を配信する構成。

技術特性

エッジで動く — 世界数百都市のデータセンターに瞬時にデプロイ。超低遅延
コールドスタート 0ms — ブラウザ内部の V8 Isolate を採用。AWS Lambda 等の数百ms〜数秒と対照的
インフラ管理不要 — スケールアップ自動。100万リクエスト急増でも対応
シームレス統合 — Pages、D1(SQL)、R2(egress無料)、KV と連携

対応言語・フレームワーク

JavaScript / TypeScript / Python / Rust。React / Vue / Svelte / Next / Astro 等のフレームワーク対応。

料金

静的アセットへのリクエストは 無料・無制限。アセット保存にも追加費用なし(公式明記)
Workers 本体は Free plan で 1日 100,000 リクエストまで
2026年5月時点で Workers 関連の $5/月プランも登場

懸念(トレードオフ)

実行時間制限: 数十秒かかる重い処理(動画エンコード、大規模データ分析)には不向き
Node.js 完全互換ではない — nodejs_compat フラグで API 互換を有効化できる(互換性は劇的向上中)

Cloudflare Access — スタッフ限定の標準解

ゼロトラスト・アクセス制御。「公開するため」ではなく「Cloudflare 上に置いたものを見せる相手を絞るため」のサービス。

AIエージェント時代への進化

2026-03-20: Managed OAuth サポート — CLI、AIエージェント、SDK、スクリプト等の非ブラウザクライアントが Access 保護アプリに OAuth 2.0 で認証可能に
2026-04: 公式ブログで「Access を内部アプリ前段に置くことで、既存アプリをコード変更なしに agent-ready にできる」と明示

無料枠と認証方法

50ユーザーまで無料(時間制限なし)。Cloudflare Zero Trust / SASE の複数機能を含む
ポリシー: 特定メールアドレス、Googleログイン、組織ドメインなどで制限可能

代表ユースケース

社内ツール保護、外部パートナーへの限定権限付与、開発者リモートアクセス、公開前 LP の確認、講師向け教材管理。

不向き

「商品 A を購入済みか」「閲覧期限内か」「返金後の停止」「商品ごとの権限」など、購入履歴に基づく権限管理は単体では弱い。

数値・スコア・無料枠(一覧)

判断のときに見返すべき数値を集約。すべて出典が複数情報源で確認済み。

項目	値	出典
Pages 評価(Gartner)	4.7/5(16件、2026-01更新)	Gartner Peer Insights
Pages 評価(Product Hunt)	5.0/5(20件)	Product Hunt
Pages vs Vercel スコア	8.7 vs 8.8	devtoolreviews.com 2026年比較
エッジロケーション	300以上	Cloudflare 公式
TTFB	50ms 未満クラス	レビュー記事複数
Workers Free リクエスト	1日 100,000 リクエスト	Cloudflare Docs Pricing
Workers 静的アセット	無料・無制限(保存も追加費用なし)	Static Assets billing
Access Free	50ユーザーまで・時間制限なし	Reference Architecture: SASE
Workers 関連プラン	$5/月(2026年5月登場)	Grok レビュー
Workers リリース	2017年	Cloudflare ブログ
Pages → Workers 公式方針	2025-04-08	Cloudflare ブログ "Full-stack on Workers"
Managed OAuth for Access	2026-03-20	Cloudflare Changelog
Builder Day(Pages → Workers 統合)	2024年	Cloudflare ブログ

用途別の採用可否 — 5ケース

本ノートの中核。3つの主用途と2つの参考ケースについて、第一候補・代替・Access の要否・無料可否・Claude Code/Codex 相性・採用可否・避けたい誤解を整理した。

① 公式サイト・SEO 目的 — 採用

第一候補: Cloudflare Workers + Static Assets
代替候補: Cloudflare Pages(簡単な入口)、Vercel(Next.js ヘビーユース時)
Access: 不要(かけると検索エンジンが読めなくなる)
SEO 必須設定: 独自ドメイン、サイトマップ送信、Search Console、適切なメタ情報
無料で済むか: 済む — 静的アセットは無料・無制限
Claude Code / Codex 相性: ◎ — HTML生成 → Wrangler でデプロイの一気通貫が現実的
避けたい誤解: Access を SEO ページにかけない。Pages 単体を長期本命視しすぎない

向いている例: 公式LP、教材販売ページ、講座案内、SEO記事の静的HTML化、note / メルカリ等への導線。

② スタッフ向け限定共有(多少の秘匿情報を含む) — 採用

第一候補: Cloudflare Workers + Static Assets + Cloudflare Access
代替候補: Cloudflare Pages + Access
検索除外: Access + robots.txt + noindex の三段構え
認証方法: メールOTP、Googleログイン、組織ドメインなど
無料で済むか: 済む(50ユーザー以内)
Claude Code / Codex 相性: ◎ — Wrangler 経由でデプロイ、Access ポリシー設定支援も可能
避けたい誤解: 公開サイトと同じ扱いにしない。Access のメリットは「絞り込み」であって「会員管理」ではない

向いている例: スタッフ向け手順書、教材制作フロー、AI活用マニュアル、社内ナレッジハブ、公開前LP確認、講師向け共有資料。

注意点: 生徒の成績、個人情報、決済情報、契約情報は置かない(Cloudflare 云々以前に情報管理設計を別に考えるべき)。

③ サービス購入者だけが閲覧できる — 段階的採用

第一候補: Cloudflare 単体ではなく、販売・会員管理サービス併用
Cloudflare の役割: 表示基盤、高速配信、一部API、ファイル配信
別途必要なもの: 決済、購入履歴管理、ログイン、権限管理
候補サービス(既存利用): note 有料記事 / 有料マガジン、メルカリShops、Shopify、Gumroad、Teachable、Thinkific
自社化する場合: Cloudflare Workers + Static Assets + Stripe(決済) + Clerk / Auth0 / Supabase Auth(認証) + D1 / Supabase / 外部DB(購入者DB) + R2(教材ファイル)
無料で済むか: 済まない — 決済手数料、認証サービス、DB、保守、セキュリティ設計コスト
Claude Code / Codex 相性: ○(実装可だが設計が必要)
避けたい誤解: Access だけで購入者限定を作るのは危険。Access は「メールアドレス通す」までは得意だが、「商品Aを買った人だけ・返金したら停止・閲覧期限あり」は単体では弱い

Access 単体の限界

商品ごと権限分離が手動寄り
返金後の自動停止は決済連携が必要
閲覧期限管理は会員管理 DB が必要
パスワード共有対策、複数商品の権限管理

推奨アプローチ: まず note 等の販売プラットフォームで済ませ、自社化は次フェーズ。

④ 既存 WordPress サイト(参考) — 無理に移行しない

採用可否: 無理に移行しない
理由: Cloudflare 静的構成は PHP / MySQL 前提の仕組み(プラグイン、フォーム、管理画面)と相性が悪い
推奨: Xサーバー等での継続運用、または別管理

⑤ Next.js ヘビーユース(参考) — Vercel と比較したうえで判断

第一候補: Vercel(ゼロコンフィグ、Next.js ネイティブ)
代替: Cloudflare Workers + OpenNext アダプター(一部ギャップあり)
採用可否: Vercel と比較したうえで判断

競合との比較(2026年5月)

同じ用途を別プラットフォームで実現する場合の比較。コスト・グローバル性能・エコシステム重視なら Cloudflare、Next.js ヘビーユースや「とにかく楽に作りたい」なら Vercel というのが複数レビュー共通の結論。

プラットフォーム	ホスティング主力	アクセス制御 / 認証	特徴 / コメント
Cloudflare	Workers + Static Assets / Pages	Cloudflare Access(50ユーザー無料)	無料枠が大きく、無制限帯域。AIエージェント連携公式対応。コスト・グローバル性能重視ならこれ
Vercel	Vercel(Next.js等)	Auth0 / NextAuth.js(Deployment Protection: Password Protection、Trusted IPs、Vercel Authentication)	DX とNext.js ネイティブで勝る。プレビュー / ダッシュボードの洗練度が高い。Claude Code 用 deploy plugin あり
Netlify	Netlify	パスワード保護(Pro プラン)、SSO(Enterprise 寄り)	特定ツール(フォーム)で優位だが、全体的にCloudflareにコスト・パフォーマンスで劣る
GitHub Pages	GitHub Pages	Private Pages(Enterprise Cloud のみ、リポジトリ読み取り権限者に限定可能)	小規模で「特定ユーザー安全共有」の主役にするには重い
Google Cloud	Cloud Run / Firebase	IAP(Identity-Aware Proxy)	コンテナベースで動かせるため移行容易。IAP で Access に近いゼロトラスト実現可能
AWS	AWS Amplify / ECS	AWS Cognito / AWS WAF	世界最大シェア。バックエンド連携は強固だが学習コスト・複雑化が懸念

段階的導入プラン(5段階)

最初から本命構成 + MCP まで全部やる必要はない。5段階で徐々に拡張するのが現実的。各段階で何ができて何にお金がかかるかを明示した。

第1段階 — Cloudflare Pages または Workers にテスト公開

目的: 公開体験を確認。Cloudflare アカウント、HTTPS自動発行、URL発行を体感する。
費用: 無料。ハードル: 低い。典型作業: 1ページの HTML を Cloudflare に置くだけ。

第2段階 — Workers + Static Assets を Wrangler で公開

目的: 今後の本命構成を確認。Wrangler CLI 経由でデプロイの再現性を担保する。
費用: 無料。ハードル: 中。典型作業: npx wrangler login → wrangler deploy。
詰まりやすいポイント: Wrangler ログイン、wrangler.jsonc 設定、出力フォルダ指定。

第3段階 — Access で限定共有

目的: スタッフ共有を確認。メールOTP / Googleログイン / 組織ドメインのいずれかで認証をかける。
費用: 50人以内なら無料枠。ハードル: 中〜やや高。典型作業: Access アプリ作成 → 認証方法選択 → 許可ポリシー設定 → 自分とスタッフでアクセステスト。

第4段階 — Claude Code から Wrangler 運用

目的: 一気通貫に近づける。Claude Code でファイル編集 → Wrangler でデプロイをひとつのセッションで完結させる。
費用: 無料(Cloudflare 側の課金は AI ツール選択ではなく「Cloudflare 上で何を動かすか」で決まる)。ハードル: 中。

第5段階 — MCP / Cloudflare plugin で AI 連携を深化

目的: DNS、Access、ログ、分析まで AI に寄せる。Claude Code / Codex の /plugins で Cloudflare plugin を入れると Cloudflare Skills と MCP server が登録される。
費用: 無料〜要確認。ハードル: 高め。判断: 運用が固まってから導入。最初から飛び込む必要はない。

弱み・つまずきポイント(重要度順)

採用を決めるとき・運用を始めるときに見落としやすい論点。Gemini が示した評価軸3点(ベンダーロックインの許容度 / 対象ユーザーと用途 / データレジデンシー)も合わせて事前に明確化しておきたい。

カテゴリ	内容	対応方針
Pages の方向性	メンテナンスモード寄り。新機能は Workers 中心	新規構築は Workers + Static Assets を本命に
Access と Pages の混同	Pages は置き場所、Access は認証	役割を分けて考える
購入者限定の複雑さ	購入履歴・決済・権限管理が必要	Cloudflare 単体で考えない
Node.js / npm / Wrangler の理解負荷	公開作業の裏側で必要	最初は Claude Code / Codex に任せ、最低限だけ理解
MCP の導入負荷	便利だが初期は重い	最初は Wrangler まで
WordPress やフォーム	静的構成では PHP/MySQL 前提の仕組みが動かない	既存 WordPress は無理に移行しない
SEO 設定ミス	限定ページが検索に出る、公開ページが検索されない	noindex / robots / sitemap を用途別に分ける
個人情報・成績・決済情報	秘匿性が高い	Cloudflare 上の静的ページに置かない
ベンダーロックイン	D1 / R2 / KV まで使うと依存強化	データ層は外部サービス併用も検討。Cloudflare Tunnel(cloudflared)でインフラとセキュリティを分離する手も
英語ドキュメント・サポート	トラブル時の学習コスト	まず小さい範囲で試す
`_redirects` / `.html` 308 リダイレクト	SEO や旧URLに影響(回避策あり)	リダイレクト挙動を必ず検証
大規模 Node.js アプリ・長時間処理	Workers の実行時間制限に触れる	コンテナ機能や他プラットフォームを検討

自分の解釈

トミタコーチの視点

用途別に整理してみると、ある事実が浮かび上がる:

Cloudflare は「用途を分けて使えば」依然第一候補。ただし「全部を Cloudflare で済ませる」と無理が出る。

2026年も "shockingly good(驚くほど良い)" という声が続いており、「無制限帯域 + 高速グローバル配信 + 低コスト」で個人開発者・小規模チーム・コンテンツサイトに非常に強い選択肢である。さらに Managed OAuth(2026-03-20)で Access が AIエージェント時代の認証基盤として公式に位置づけられたため、Claude Code / Codex を投資の中心に据えるトミタコーチの方針とも整合する。

一方、購入者限定だけは「認証」ではなく「購入履歴に基づく権限管理」が本質であり、Access 単体では届かない領域。ここを誤ると、返金後にコンテンツが見え続ける、商品ごとの権限分離が手動になる、といった運用事故につながる。最初は note / Shopify 等で済ませ、自社化は別フェーズとして切り分けるべき。

用途	結論
公式サイト・SEO	Cloudflare Workers + Static Assets で採用(無料、Access は不要)
スタッフ限定共有	Cloudflare Workers + Static Assets + Access で採用(50ユーザーまで無料)
購入者限定	段階的採用。最初は note 等、自社化は次フェーズで決済+認証+DB を組み合わせる
Pages の扱い	試用・既存運用なら有力。新規の長期本命としては Workers 寄りに考える
Claude Code / Codex	どちらでも Cloudflare 連携は公式対応。AI ツール側の将来移行に強い

採用度: ★★★★☆

最初の実験は「1ページの HTML を Cloudflare に公開し、その次に Access で限定共有」が一番安全。最初から MCP まで全部やる必要はない。