第15章：エージェント時代のCloudflareと、次の学習ルート 🚀
ここまで学んできた内容を、最後にひとつの地図としてまとめます 😊 この章のテーマは、Cloudflareを「Webを速くする箱」ではなく、「AIエージェントが動いて・見て・守られて・外とつながる土台」として見ることです。2026年のCloudflareは、Workers だけを見るより、Agents SDK・Durable Objects・Workflows・MCP・Browser Rendering・Zero Trust・Tunnelまでつなげて見ると、かなり全体像がわかりやすくなります。 (Cloudflare Docs)
この章のゴール 🎯
この章では、次の3つをつかめれば大成功です 🌟
- Cloudflareが、なぜ「エージェント時代」に強いのか
- MCP・Browser Rendering・Zero Trust・Tunnel がどうつながるのか
- このあと何をどの順で学ぶと、いちばん迷いにくいのか
1. いまのCloudflareは「コードを置く場所」より、もう一段広い ☁️🧠
CloudflareのAgents SDKは、いわゆる「ただのチャット」ではなく、記憶する・道具を使う・予定で動く・リアルタイムにつながるような本格的なエージェントを作る方向に寄っています。公式ドキュメントでも、現代のAIアプリは stateless になりがちだけれど、本物のエージェントには会話の記憶、ツール呼び出し、スケジュール、リアルタイム接続が必要だと説明されています。そして Agents SDK では、各エージェントが Durable Object 上で動き、SQLデータベース、WebSocket、スケジューリングを持てます。しかもスターターは Workers AI をデフォルトに使います。 (Cloudflare Docs)
ここがすごく大事です 😊
Cloudflareでは、「AIの頭脳」だけでなく、「状態を持つ実行場所」まで同じ土台で考えやすいんです。Durable Objects 自体も、公式では AI agents・chat・リアルタイムアプリの土台として案内されています。なので、Cloudflareを学ぶときは「Workerで1回返して終わり」だけでなく、ずっと生きている小さな頭脳を世界中に置ける感じで見ると、発想が一気に広がります。 (Cloudflare Docs)
2. エージェント時代のCloudflare地図 🗺️✨
この章では、4つの役に分けると整理しやすいです。
2-1. つなぐ役：MCP 🔌🤝
Cloudflareは、managed remote MCP servers のカタログを自前で持っています。公式には、Cloudflareの remote MCP server は OAuth でクライアントにつなげられ、Cloudflare API MCP server では DNS・Workers・R2・Zero Trust などを含む 2,500 以上の API endpoint に、実質2つの道具 search() と execute() で触れられると案内されています。 (Cloudflare Docs)
さらに Zero Trust 側では、MCP server portals によって複数のMCPサーバーを 1つのHTTP endpoint にまとめられますし、Access for SaaS を使うと Cloudflare Access を OAuth SSO provider として使って MCP サーバーを守れます。つまり Cloudflare のMCPは、単に「ツールを増やす」だけでなく、会社やチームの中で安全に使う導線まで用意され始めています。 (Cloudflare Docs)
2-2. 見る役：Browser Rendering 🌐👀
Browser Rendering は、Cloudflareのグローバルネットワーク上で headless Chrome を動かす機能です。用途としては、ブラウザ自動操作、スクレイピング、テスト、コンテンツ生成などが公式に挙げられています。 (Cloudflare Docs)
そして 2026年4月10日の changelog では、Browser Rendering が CDP（Chrome DevTools Protocol） を公開し、Cloudflare Workers・ローカルPC・他クラウド環境など、どこからでも CDP client で接続できるようになったこと、さらに MCP client からも Browser Rendering を使えることが明記されています。Cloudflareの Browser Rendering docs でも、MCP client と組み合わせると、AI coding agent が ページ遷移・スクリーンショット・パフォーマンス監査・JavaScriptデバッグまでできると説明されています。 (Cloudflare Docs)
しかも Cloudflare には Playwright MCP まで用意されていて、こちらは screenshot 前提ではなく accessibility snapshot のような構造化データで LLM が扱いやすい設計になっています。なので Browser Rendering は、「ブラウザを自動で開く機能」より、エージェントに“Webを見る目”を持たせる部品として理解するとしっくりきます。 (Cloudflare Docs)
2-3. 守る役：Zero Trust と Access 🛡️🔐
Cloudflare Access は、公式に identity-aware proxy として説明されています。つまり、アプリの前に立って、IdP の情報や device posture などを使って、各リクエストごとに「通していいか」を判断する役です。社内ツールや管理画面を守るときに、VPN一発ではなく、人・端末・条件で絞る発想ですね。 (Cloudflare Docs)
MCP サーバーや社内アプリの時代になると、この考え方はさらに重要です。Cloudflare docs でも、internal apps を browser から VPN なしで安全に使える流れや、MCP サーバーに OAuth で安全に権限委譲する流れが案内されています。つまり「AIに道具を持たせる」時代ほど、その道具を誰にどこまで持たせるかを Access で考える必要が出てきます。 (Cloudflare Docs)
2-4. 通す役：Tunnel 🚇☁️
Cloudflare Tunnel は、公開側の docs では origin servers・APIs・services を、public IP なしで、post-quantum encrypted tunnels で Cloudflare に安全接続する仕組みとして説明されています。 (Cloudflare Docs)
一方で Cloudflare One 側の Tunnel docs は、private networking・VPN replacement・private network access 用の文脈で案内されています。つまり Tunnel は1つでも、見方は2つあります。 外に安全に公開するトンネルとして見るか、内側のネットワークへ安全につなぐトンネルとして見るかです。エージェント時代には後者もかなり重要で、たとえば AI が社内ダッシュボードや社内APIを触る場合、Tunnel で通路を作り、Access で鍵をかけると理解すると覚えやすいです。 (Cloudflare Docs)
3. 長く動く処理は Workflows で考えるとラク ⏳🔁
エージェントっぽい処理は、1回のHTTPリクエストで終わらないことが多いです。 たとえば「調査して」「途中で承認を待って」「終わったら通知して」みたいな流れですね。
Cloudflare Workflows は、公式に durable multi-step applications のための仕組みとして説明されていて、自動リトライ、状態の永続化、数分〜数週間の継続、外部イベントや承認での一時停止、観測性などが入っています。しかも Workers changelog では、Workflows は GA になっていて、waitForEvent による human-in-the-loop も強化されています。 (Cloudflare Docs)
さらに Cloudflare は、Agents SDK と Workflows を組み合わせて Durable AI Agent を作るガイドまで出しています。そこでは、LLM呼び出しやツール呼び出しを個別の step にし、失敗時は自動再試行、承認待ちは長時間停止、進捗はリアルタイム更新、という流れが紹介されています。なので初心者のうちは、 会話の中心 = Agents SDK 長時間の仕事 = Workflows と分けて覚えるとかなり楽です 😊 (Cloudflare Docs)
4. GitHub Copilot と Cloudflare は、どう組み合わせると気持ちいい？ 🧑💻✨
GitHub docs では、MCP は Copilot の能力を他システムやツールに広げるための仕組みとして説明されています。しかも MCP は、IDE、Copilot CLI、GitHub.com 上の agent など、複数の Copilot surface で使われます。 (GitHub Docs)
Windows + VS Code 前提で見ると、いちばん実務的にわかりやすいのは VS Code で MCP を使う流れです。GitHub docs では、VS Code で MCP サーバーを .vscode/mcp.json または settings.json に設定でき、Copilot Chat の Agent モードから使えると案内されています。さらに、すでに Claude Desktop 側で MCP 設定があるなら、chat.mcp.discovery.enabled を使って VS Code 側が既存設定を見つける方法も載っています。 (GitHub Docs)
Copilot を Cloudflare 開発に自然になじませたいなら、リポジトリ側のガイドも大事です。GitHub docs では、.github/copilot-instructions.md にリポジトリ共通の指示を書けて、.github/instructions 配下の path-specific instructions も作れます。さらに AI agent 向けには AGENTS.md も使えます。これらの instruction は保存直後から Copilot の request に自動追加され、References から使われたか確認できます。つまり Cloudflare プロジェクトでは、**「Wranglerで検証する」「Workers優先で考える」「R2はこう扱う」**みたいなチームルールを Copilot に食べさせやすいわけです。 (GitHub Docs)
ただし、ここは期待値調整が必要です ⚠️ GitHub docs では、Copilot cloud agent は、OAuth を使う remote MCP servers を現時点ではサポートしていないと明記されています。Cloudflare の managed remote MCP servers は OAuth 接続が前提なので、GitHub.com 側の cloud agent ですぐ何でも直結できる、とは考えない方が安全です。現実的には、まず VS Code の Copilot Chat / Agent モードで MCP を触り、Cloudflare 側の Browser Rendering や自分で用意した MCP を使いながら慣れるのが、いちばん滑らかです。これは Cloudflare docs と GitHub docs を並べると見えてくる、かなり大事な実務ポイントです。 (Cloudflare Docs)
5. 初学者向けの覚え方は「考える・覚える・見る・守る」だけでOK 🧩😊
難しく考えすぎなくて大丈夫です。 Cloudflareをエージェント時代の地図でざっくり覚えるなら、こんな4つで十分です。
考える → Workers AI / Agents SDK 覚える → Durable Objects / Vectorize / 必要ならD1 見る → Browser Rendering / MCP 守る → Access / Tunnel / Zero Trust policy
この見方は、Cloudflareの各公式 docs が示している役割分担にかなり沿っています。Workers AI は serverless GPU でモデルを動かし、AI Gateway は可視化や rate limiting や fallback を担い、Vectorize は vector database として埋め込みを扱い、AI Search は自然言語で更新され続ける検索インデックスを作り、Agents SDK はその上に stateful な agent を載せられます。 (Cloudflare Docs)
6. このあと進むなら、学習ルートはこの3本がおすすめです 🛤️🌈
ルートA：まず「作る」を極める 🛠️
最短で手応えが出やすいのは、Workers → Durable Objects → Agents SDK → Workflows → Browser Rendering の順です。Workers はフルスタックや各種フレームワークの土台になり、Agents Quick Start では React フロントとリアルタイム同期する agent まで入っています。そこへ Workflows を足すと「長い仕事」ができ、最後に Browser Rendering を足すと「Webを見て動く」まで届きます。 (Cloudflare Docs)
ルートB：まず「守る」を極める 🔐
社内ツール、管理画面、会員制サイト、検証環境を触ることが多いなら、Tunnel → Access → Policies → MCP portal / MCP security の順が強いです。Tunnel で通路を作り、Access で人と端末を見て、Policy で条件を決め、必要なら MCP portal で AI 向けの道具をまとめる流れです。これは「AIアプリを作る前に、まず入口をちゃんと守る」ルートです。 (Cloudflare Docs)
ルートC：まず「AIアプリ」を極める 🤖
AIが一番気になるなら、Workers AI → AI Gateway → Vectorize → AI Search → Agents SDK が自然です。Workers AI がモデル実行、AI Gateway が観測と制御、Vectorize が埋め込み検索、AI Search が自然言語検索の入口、最後に Agents SDK で状態を持つエージェントへ進む感じです。第14章で作ったAI地図を、そのままエージェント実装へ伸ばすルートですね。 (Cloudflare Docs)
7. この章のミニ実践テーマ ✍️💡
この章を読んだあと、次のどれか1つを妄想設計できたらかなり強いです 😊
案1：社内ドキュメント調査エージェント 社内サイトや限定ページは Access で守る。必要なら Tunnel で内側につなぐ。Agent が Browser Rendering でページを見に行き、必要な処理は Workflow に回す。
案2：会員限定の自動チェック係 会員向け管理画面を Access で保護し、Agent が定期的に状態確認。エラー時は Workflows で再試行し、必要なら人の承認待ち。
案3：Cloudflare運用補助エージェント Cloudflare API MCP を将来的な選択肢として見つつ、まずは VS Code + Copilot + instructions ファイルで開発体験を整え、Browser Rendering や Workers AI を足していく。
まとめ 🎓☁️🚀
第15章で本当に覚えてほしいのは、たったこれだけです。
Cloudflareは、もう「CDNの会社」だけではありません。 AIエージェントが、考えて 🧠・覚えて 🗂️・見て 👀・安全に動く 🔐 ための土台が、かなり1か所に集まってきているプラットフォームです。 (Cloudflare Docs)
そして学び方としては、全部を一気にやらなくて大丈夫です 🙌 まずは 自分が「作りたい人」なのか、「守りたい人」なのか、「AIを組みたい人」なのか を決めて、そのルートから掘ればOKです。Cloudflareは機能が多いですが、地図さえあれば怖くありません。最後にその地図が頭に入れば、この15章のゴールは達成です 🌈✨
必要なら次に、この第15章をベースにして 「章末課題つきの完成版教材」 の形に整えます。