Cloudflareのサイトやアプリを、Claude CodeやCodexに任せて設定している会社は増えています。そこで起きるのが、エージェントがwranglerで出来ることの壁に当たって止まる、という場面です。Workerのデプロイは通るのに、キャッシュの設定やWAFの例外はダッシュボードを人が開く。エージェントに任せた意味が半分になります。

2026年9月28日、Cloudflareはこの壁を取り払う新しいCLI、cfを公開しました。この記事は、cfで何が変わるのか、wranglerはいつまで使えるのか、いま移行すべきかを、公式の発表と手元で実際に入れて動かした結果から書きます。あわせて、9月15日から28日にかけて出た関連する更新10件を、当社の35プロジェクトにどう当てはめたかも載せます。確認日は2026年9月29日です。オープンベータの段階なので、導入時には最新の公式情報も確認してください。

結論を先に書きます。

  1. cfは、wranglerの約280コマンドをCloudflare API全体の3,000超の操作へ広げたCLIです。 エージェントが自然文でコマンドを探せる cf cli search、JSONが既定の出力、TypeScriptで書く設定ファイル、Vite既定の開発環境の4つが柱です
  2. wranglerはすぐには消えません。 cfはesbuildで組んだJavaScript WorkerやRust・Python Workerの開発とデプロイを引き続きwranglerに委ねます。ベータ終了後にwranglerの最終メジャー版が出て、その後18か月は保守されます
  3. いま移行すべきかは、プロジェクトの型で決まります。 新規のWorkerはcfで始めてよく、既存の本番はwranglerのまま最新版に上げて、cfはAPI操作の道具として先に使う。当社はこの分け方で35プロジェクトを整理しました

なぜ新しいCLIが必要だったのか

Cloudflareの発表で、いちばん意外だった数字から書きます。wranglerの利用のうち、エージェントによるものが2026年3月に4分の1、直近の週には48%に達したそうです。しかもエージェントは人より使うコマンドの種類が1日あたり約2倍多く、6種類以上のコマンドを使う確率は約4倍とのことです。

つまり、CLIの利用の半分近くがエージェントになり、Cloudflareはエージェントを今後の主な利用者として設計を組み直しました。ところがwranglerは、各プロダクトのチームが手作りで足してきたコマンドの集まりで、扱えるのは約280の操作です。Cloudflareの製品はAPIで3,000を超える操作を持っているので、wranglerでは10分の1も触れません。エージェントに「このWorkerをAccessで保護して、WAFを前に置いて、ドメインを買って」と頼んでも、途中でwranglerに無い操作に当たります。

もう1つの理由は、一貫性です。d1 info、hyperdrive get、workflows describe のように、同じ「詳細を見る」操作なのにチームごとに動詞が違う。人なら読み替えられますが、エージェントは学習したパターンから外れるたびに試行錯誤し、その分だけトークンと時間を使います。

この2つを一度に解くために、CloudflareはAPIに対応するコマンドを手で書くのをやめました。API定義（OpenAPIのスキーマ）に少しだけ注釈を足し、そこからコマンドを自動生成する仕組み、Forgeを作り、同じ日にオープンソースとして公開しています。cfはForgeの最初の成果物です。cf dev や cf build のように、APIの呼び出しではない手元の操作だけは、引き続き手で書かれています。

cfで変わる4つのこと

wranglerとcfの違いを、対象範囲・出力・設定ファイル・ビルド・コマンドの探し方の5点で並べた表

1. エージェントが自然文でコマンドを探せる

3,000を超える操作を --help を辿って探すのは、人にもエージェントにも無理があります。cfには cf cli search があり、やりたいことを文で渡すと、該当しそうなコマンドが短い説明つきのJSONで返ります（手元では5件でした）。試した例です。

cf cli search "cache rules vary"

[
  { "command": "cf cache settings variants edit", "summary": "Change variants setting" },
  { "command": "cf cache settings variants get",  "summary": "Get variants setting" },
  ...
]

手元で --help を打つと、冒頭にエージェント向けの案内が出ました。要約すると、--help を入れ子で辿らず、まず cf cli search を使え。検索文には名前・メールアドレス・ドメイン・アカウントID・トークンなどの識別情報を入れるな、という指示です。個人情報や顧客情報を検索文に混ぜない前提の設計で、エージェントに使わせるときは、この案内がそのまま社内ルールの土台になります。

APIのリクエスト内容を知りたいときは、見つかったコマンドの先頭の cf を cf schema に置き換えると定義が出る、と同じ案内に書かれています。

2. 出力はJSONが既定

wranglerでは --json を付けても、対応していないコマンドは人向けの罫線つき表を返しました。エージェントはそれを読み解けますが、jq で絞るより時間もトークンもかかります。cfは逆で、JSONが既定です。人が見るときは整形され、エージェントが読むときは詰めた形で出ます。

ドメインの購入のように人の判断が要る操作には、必要な入力を順に聞くフォーム形式が用意されています。長い名前付き引数を並べる代わりに、項目ごとに検証しながら埋められます。

3. 設定ファイルがTypeScriptになる

wranglerの設定は wrangler.toml か wrangler.jsonc でした。cfでは cloudflare.config.ts になります。Cloudflareが挙げている利点は、エディタとエージェントの言語サーバー（LSP）が型を読めることです。TOMLにはスキーマが無く、JSONCのスキーマはエージェントがほとんど参照しなかった、と発表にあります。

書き方は関数で、環境（mode）に応じて値を切り替えられます。発表の例を短くしたものです。

import { bindings, defineConfig, triggers } from "cf/config";

export default defineConfig(({ mode }) => ({
  worker: {
    name: "example-worker",
    compatibilityDate: "2026-09-27",
    env: {
      API_URL: bindings.text(
        mode === "production" ? "https://example.com" : "https://staging.example.com",
      ),
      API_TOKEN: bindings.secret(),
      DATABASE: bindings.d1({ name: `example-${mode}-database` }),
      AI: bindings.ai(),
    },
    triggers: [
      triggers.fetch({ pattern: "example.com/*" }),
      triggers.scheduled({ schedule: "0 * * * *" }),
    ],
  },
}));

bindings はKV・D1・R2・Queues・AI・Vectorize・別Workerなどを補完つきで書ける補助関数、triggers はルート・スケジュール・キュー・メールの起動条件を1か所にまとめる補助関数です。wranglerで env ブロックを環境ごとに複製していた設定は、同じ土台から関数で組み立てる形になります。Cloudflare社内では5,000行超の設定ファイルが40%縮んだそうです。

発表では、この設定ファイルをWorkersだけでなくCloudflare全体の設定の置き場にすると書かれています。ゾーン・DNS・ポリシーの設定も、いずれ同じファイルで扱う構想です。

4. 開発環境はVite既定

wranglerが生まれたときViteは無く、バンドルはesbuild、開発サーバーはCloudflare独自でした。cfはViteを既定にし、Cloudflare Vite Pluginで開発と本番の差を無くす方針です。HMR（差分の即時反映）やRolldownによるビルドが使え、Vitestプラグインでバインディングを含むテストも同じ環境で回せます。

wranglerはどうなるか

ここは移行判断に直結するので、発表の記述をそのまま整理します。

  • 既にViteで組んでいるWorkerは cf migrate で cloudflare.config.ts に変換される
  • esbuildに依存しているWorker、RustとPython Workerは、cfが開発とデプロイをwranglerに委ねる（cfを入れても内部でwranglerが動く）
  • オープンベータが終わると、cfへの誘導を含むwranglerの最終メジャー版が出る
  • その後、wranglerは18か月間、保守される
  • 静的サイトは設定ファイル無しで cf deploy できる

つまり、当面はcfとwranglerが同居します。cfは新しい入口で、裏では既存のwranglerが動く。急いで全部を書き換える必要はありませんが、wranglerの側にも動きがあります。9月22日に出たWorker Previews（後述）は、Cloudflareが公開しているエージェント向けスキルの記述によると、プロジェクト内のwrangler 4.135.0以上を前提にしています。Previewsを使うなら、cfへ移行しなくてもwranglerを上げる作業は要るということです。

実際に入れて分かった、つまずく所

当社の環境（WSL2・Node 22・npm）で、発表当日の翌朝に入れました。3つつまずいたので先に書きます。

1つ目は、インストールが黙って不完全に終わることです。 npm i -g cf を打つと、依存するworkerdのインストール後スクリプトがnpmの allow-scripts の既定で止められ、警告だけ出て終わります。本体は入るのにバイナリが使えない状態になりました。直し方は次の1行です。

npm install -g --allow-scripts=workerd cf

2つ目は、PATHです。 npmのグローバル配置先を ~/.local/share/npm-global のように変えている環境では、そこがPATHに無いと cf: command not found になります。当社はwranglerを別の場所に入れていたので気づきませんでした。npm prefix -g で場所を確かめて、bin/cf をPATH上の場所へリンクしました。

3つ目は、エージェントの振る舞いが変わることです。 cf --help の冒頭の案内は、エージェントに向けて書かれています。Claude Codeにcfを使わせると、この案内に従って cf cli search から入ります。wranglerで覚えたコマンドをそのまま打とうとして失敗する、という往復は減りますが、社内のスクリプトやドキュメントが wrangler 前提のままだと、エージェントが2つの道具をどう使い分けるか迷います。当社は使い分けを1枚に書いて、エージェントが最初に読む場所に置きました（後述）。

入った後の動作は素直でした。cf --version で v1.0.0-beta.5、cf cli search は1秒前後で返ります。

当社の35プロジェクトをどう整理したか

当社はCloudflare上に、会社サイト・研修の申込・顧客向けの入稿の仕組み・個人の実験サイトなど、wranglerの設定ファイルを持つプロジェクトが35あります。全部にcfを入れて回るのではなく、次の3つに分けました。

Cloudflareの既存プロジェクトをcfへ移す段取りを、棚卸し・wrangler更新・cfの試行・新規はcfの4段階で示した図

まず、本番で動いていてwranglerに依存するもの。 ここはcfに移さず、wranglerを最新版に上げるだけにしました。理由は2つあります。デプロイがcronの中でwranglerを呼ぶ形で組まれていること、そしてcfがオープンベータであることです。上げた後は型検査とビルドと wrangler deploy --dry-run を通し、緑になったものだけコミットしました。

結果はこうです。35のうち、直近120日に手が入っていてwranglerを依存に持つものが21。そのうち19を4.143.0系に上げて通しました（wrangler 3系から4系へ一気に上がったものも2つあり、設定はそのままで通りました）。失敗は1つで、wranglerに同梱されるMiniflareでローカルのD1に全マイグレーションを流すテストがメモリ不足で落ちるようになったため、そのプロジェクトだけ元に戻しています。どの版から落ちるかを二分探索してから上げ直す予定です。

副産物として分かったことが2つあります。1つは、@cloudflare/workers-types を5系に上げると、Honoを使う2つのプロジェクトで実行コンテキストの型がHono側と合わずに型検査が落ちること。ここはwranglerだけ上げて、型定義は据え置きました。もう1つは、pnpmの「公開から日が浅いパッケージを入れない」設定に4.143.0が引っかかり、除外の指定が要ったことです。どちらも、上げてみて初めて出る種類の問題で、複製ではなく本番のリポジトリで型検査とビルドを回したから見つかりました。

なお、Workflowsを使っているプロジェクトは35の中に無く、Workers AIのバインディングを使うのは1つだけでした。9月24日と27日に出たWorkflowsの exports 宣言や、17日のWorkers AIの混雑時に待たない指定（rejectIfBusy）は、当社では当てはまる先がほぼ無い、と分かった時点で見送りにしています。棚卸しは、やらないことを決めるためにも要ります。

次に、cfの動きを見るための試行。 本番の2プロジェクト（Hono製のWorkerと、Vite＋Pages構成の会社サイト）を別の場所に複製して cf migrate を走らせ、何が生成され、何がwranglerに委ねられるかを確かめました。分かったことは4つです。

  • cf migrate はプロジェクト内のwranglerが4.100.0以上でないと、何も書かずに止まります。当社の2つはどちらも古く、複製の側でwranglerを上げてから通しました
  • Workerのほうは cloudflare.config.ts と wrangler.config.ts が生成され、cf が開発用の依存に足されます。元の wrangler.jsonc と npm scripts はそのまま残ります。D1の migrations_dir に相当する項目が新しい設定に無く、対応が要る箇所として書き出されました（cf d1 migrations apply --dir で代替します）。その後の cf build は「Delegating to Wrangler」と表示してwranglerに委ね、cf dev もwranglerの開発サーバーが上がりました
  • Pages構成は移行されません。 「The Pages configuration is not supported by the new config and was not migrated」と出て、cf build は入口が無いと止まります。cfにはPagesプロジェクトをAPIで扱うコマンドはありますが、ビルドとデプロイの対象はWorkersです。Pagesで動いているサイトは、当面wranglerのままにするか、Workers（静的アセット）へ作り直してからcfへ移す、の二択になります
  • 認証はwranglerと別です。 wranglerでログイン済みでも、cfは未ログインの状態から始まります。cf auth login でブラウザ認証するか、CLOUDFLARE_API_TOKEN を渡します。当社は自動実行の経路では1Passwordに置いたトークンを環境変数で渡す形にしました

最後に、cfを今日から使う場面。 それはデプロイではなく、API操作です。wranglerが扱えないゾーン設定（キャッシュルール、WAFの例外、Turnstileのウィジェット一覧、Workersの権限）は、これまでAPIを直接叩くスクリプトを自作していました。ここをcfに置き換えると、エージェントが cf cli search で自分でコマンドを見つけて実行できます。自作スクリプトが減る分、保守も減ります。

あわせて、Cloudflareが公開しているエージェント向けのスキル集（cloudflare/skills）の14本を、9月26日の版に更新しました。wranglerのスキルにはWorker Previewsと権限の項が足され、当社の3つのエージェント環境（Claude Code・Codex・共通の置き場）で同じ版になるように揃えています。

9月に出た関連アップデート10件と、自社での判断

cfの発表は単体ではなく、9月15日から28日にかけての2週間の一連の更新の締めくくりでした。会社サイトやアプリをCloudflareで運用している立場で関係するものを10件に絞り、当社でどう判断したかを添えます。

Cloudflareの2026年9月の関連アップデート10件を、今すぐ効くか様子見かと、開発チーム向けかサイト運営向けかの2軸で配置した図

更新 発表日 要点 当社の判断
Worker Previews 9/22 Gitのブランチごとに専用URL・設定・状態を持つ検証環境。npx wrangler preview で作る。Durable ObjectsとContainersはブランチごとに分離。公式スキルの記述ではプロジェクト内のwrangler 4.135.0以上が前提 本番プロジェクトのwranglerを上げた。Preview URLは既定で誰でも開けるので、顧客データを持つものはAccessで認証を掛けてから使う
Workersの細かい権限 9/15 Worker単位でアクセスを絞り、Metadata Read-Only／Content Read-Only／Editor／Adminの4役割を割り当てられる。CIやエージェント用のAPIトークンも1つのWorkerに限定できる エージェントに渡すトークンをWorker単位のEditorに作り直す。全Workerに効くトークンは人の手元だけに残す
Turnstile Spin 9/25 Turnstileの設置をコーディングエージェントに任せる仕組み。フロントの部品とバックエンドの検証（Siteverify）を両方組む。検証を省いたウィジェットにはダッシュボードに「Fix with Spin」が出る 会社サイトのフォームは検証まで実装済みで対象外。顧客のサイトにTurnstileを入れるときの標準手順にする
Cache RulesのVary対応 9/22 全プランで、Varyヘッダの扱いをnormalize／passthrough／bypassから選べる。Vary: * は常にキャッシュしない 当社のサイトは応答を出し分けていないので設定不要。画像形式や言語で出し分けるサイトを持つ顧客向けに、normalizeを既定として案内
Python Workersの一般提供 9/21 FastAPI・Django・Flaskが、接続用の数行（workers.asgi / workers.wsgi）を足すだけでWorkersで動く。バインディングをPythonの型のまま扱える。Hyperdrive経由でPostgreSQLとMySQLに接続 当社はTypeScript中心のため見送り。Pythonで書かれた社内ツールをWorkersへ移す相談は受けられる
Vinext 1.0 9/28 Next.jsのアプリをViteで動かす枠組み。App RouterとPages Routerの両対応。顧客が求める主要機能のテストで99%超の互換（Cache Componentsを除く）。npx vinext check で移行可否を確認 当社にNext.jsのプロジェクトは無く適用なし。Next.jsのサイトをCloudflareへ移したい顧客向けに、確認コマンドの結果から判断する
Forge 9/28 OpenAPI定義からSDK・CLI・ドキュメントを生成するパイプライン。Apache 2.0。CIで動き、変更ごとにプレビュー版を作る 自社のAPIを持つ顧客に、エージェント向けのCLIとMCPを生成する道具として提案の選択肢に入れる
EmDash 1.0 9/28 Astro製のCMSが安定版に。MITライセンス。プラグインは隔離された実行環境（Dynamic Workers）で動き、宣言した権限しか持たない。プラグインの登録所はAT Protocol上 WordPressからの移設先の候補に加える。WordPressのプラグインが同じプロセスで全権を持つ構造との違いが、移設の理由になる
RustのEmscriptenターゲット 9/28 実験段階。wasm-bindgenがEmscriptenに対応し、Tokioを使うRustのライブラリがWorkersで動く見込み。Minecraftサーバーを1つのDurable Objectで動かした例 当社は対象外。実験段階なので本番には入れない
AIクローラーの「検索は許可・学習は拒否」 9/15 検索とAI学習の両方に使う混合クローラー（Apple・Google・Microsoft）に対し、検索の巡回を保ったまま学習だけを断る設定。robots.txtに反映される。Bingへの反映は2027年初頭の予定 当社は検索とAI検索の両方に引用されたい立場なので、学習の拒否は入れない。広告収入のあるメディアを持つ顧客には選択肢として案内

10件のうち、開発チームがまず動くべきなのはWorker Previewsと権限の2つです。どちらもエージェントが本番に触る範囲を狭める道具で、cfでエージェントに出来ることを広げるのと対になっています。広げる道具と絞る道具を同時に出した、と読むと、この2週間の更新の意図が分かります。

注意点

オープンベータです。 設定ファイルの形式や補助関数の名前は変わり得ます。本番のデプロイ経路をcfに置き換えるのは、ベータ終了後のwrangler最終版の案内を見てからで間に合います。18か月の保守期間があるので、慌てる理由はありません。

検索文に識別情報を入れない。 cf cli search の案内どおり、顧客名・ドメイン・アカウントIDを検索文に混ぜないよう、エージェントの指示書に1行入れてください。エージェントは便利さのために具体的な名前を入れがちです。

権限は先に絞る。 cfでエージェントの手が届く範囲は、wranglerの10倍以上になります。9月15日の権限の細分化を先に適用し、エージェントに渡すトークンを目的ごとに絞ってからcfを渡すのが順序です。Workerのデプロイ用ならWorker単位のEditor、ゾーン設定用ならそのゾーンの該当する権限だけ、という分け方です。逆にすると、エージェントが「出来てしまう」操作が一気に増えます。

Preview URLは既定で公開。 Worker Previewsのブランチ環境は誰でも開けます。顧客データやログインを持つアプリは、Cloudflare Accessで認証を掛けてから使います。認証やCookieを本番と同じ条件で試したいときは、カスタムドメインも合わせて設定します。

wranglerのバージョンはプロジェクト内が効く。 グローバルに最新を入れても、npx wrangler はプロジェクトの package.json に固定された版を使います。Previewsが動かないときは、まずここを疑ってください。

KOIYALの見解

この更新で、CloudflareはCLIの主な客をエージェントだと決めました。JSONが既定、自然文検索、型のある設定ファイル。どれも人のためというより、エージェントが迷わず動くための設計です。人はエージェントの一段後ろで、判断だけをする位置に置かれています。

当社が会社の情報システムを支援する現場で見る限り、この方向は正しいと思います。ダッシュボードで人が設定を触る運用は、設定の根拠が人の記憶にしか残りません。設定ファイルがTypeScriptで、変更がGitに残り、エージェントが設定を読んで説明できる。この形のほうが、担当者が変わっても設定の意図が残ります。

ただし、道具の側が「エージェントに全部任せられる」方向へ進むほど、会社の側で決めるべきことは増えます。誰のエージェントが、どのWorkerに、どの権限で触ってよいか。これはcfでもwranglerでも決まりません。9月15日の権限の細分化は、その決めごとを実装する道具が揃ったという意味で、cfより先に触るべき更新だと考えています。

もう1つ。Cloudflareは自社のCLIのうちAPIに対応する部分を、API定義から生成する方式に切り替えました。手で書き足す運用をやめて、生成する仕組み（Forge）に投資した。これは、自社のAPIを持つ会社にも同じ判断が迫っていることを示しています。人向けのドキュメントとSDKを手で書く時代から、エージェント向けのCLIとMCPを定義から生成する時代へ。当社が顧客の社内ツールを作るときも、この前提で設計を始めています。

次の行動

自社で進める場合、順番は次のとおりです。

  1. 手元のCloudflareプロジェクトを棚卸しし、本番で動いているものと実験を分ける
  2. 本番のwranglerを4.135.0以上に上げ、型検査とビルドと wrangler deploy --dry-run で確かめる
  3. エージェントに渡すAPIトークンを目的ごとに作り直す。デプロイ用はWorker単位のEditor、ゾーン設定用はそのゾーンの該当権限だけ
  4. cfを入れ、cf cli search でゾーン設定の操作から試す。デプロイ経路は当面wranglerのまま
  5. 新しいWorkerを1つ作るときに、cfとcloudflare.config.tsで始めてみる

Cloudflareでの運用をエージェントに任せたいが、権限と段取りをどう決めればよいか分からない。そういう相談は、当社が社外の推進チームとして中に入り、棚卸しから権限の設計、エージェントの指示書までを一緒に作ります。お問い合わせからご連絡ください。プロジェクトの数と、いま使っているCLI（wranglerかcfか）と、困っている操作を1つ書いていただければ、初回の打ち合わせで段取りの当たりをお出しします。

参考