Wrangler と cf（Cloudflare CLI）徹底比較：2026年10月時点のコマンド対応表と使い分け

Cloudflare の CLI といえば長らく Wrangler でしたが、2026 年 9 月 28 日に新しい cf（Cloudflare CLI）がオープンベータになりました。Workers 開発のツールとしての Wrangler と、Cloudflare API 全体をカバーする cf は何が違い、今どちらを何に使うべきか。公式ドキュメント、ブログ、changelog、API リファレンス、両ツールのソースコード（cloudflare/cf リポジトリと npm パッケージの同梱コード）、手元にインストールした両 CLI の --help / cf schema / cf cli search の出力を見比べて整理したメモです（調査日: 2026-10-11、追加検証: 2026-10-12）。

前提: cf はベータです。公式ドキュメントも「stable リリースまでにコマンド・設定・Build Output は変わりうる」と明記しています。本稿のコマンド名とフラグは cf 1.0.0-beta.14 と Wrangler 4.147.0 で確認したものです。

TL;DR

• cf は npm の unscoped パッケージ cf（コマンド名 cf / cloudflare）で配布される「Cloudflare CLI」。2026-09-28 にオープンベータ、最新は 1.0.0-beta.14。Wrangler の最新は 4.149.0（2026-10-08 リリース）。
• cf は Cloudflare の公開 API 全体を生成ベースでカバーし、DNS・ゾーン・WAF・Zero Trust なども扱える。コマンド数は、ブログでは約 3,000 オペレーション、ドキュメントでは 2,900 以上。1.0.0-beta.14 に同梱されたコマンド一覧（dist/_meta/commands.json）には 2,947 件が登録されている。Wrangler はブログによれば約 280 のコマンドパス。
• ロードマップ上、cf は Wrangler の後継。ベータ終了時に「cf へ誘導する Wrangler の最終メジャー版」が出て、その後 18 か月間メンテナンスされる。
• ただし cf dev / cf build / cf deploy 自体はバンドラーを持たず、フレームワーク、Cloudflare Vite プラグイン、または Wrangler（4.136.0 以上）に処理を委譲する。つまり「置き換え」と「ラップ」の両面がある。
• 設定は wrangler.jsonc / wrangler.toml から TypeScript の cloudflare.config.ts へ。移行は cf migrate。
• wrangler tail（ライブログ）など、まだ Wrangler にしかない機能がある。既存の Wrangler プロジェクトは無理に移行せず、リソース操作だけ cf を併用する使い方が公式に案内されている。

1. cf とは何か

名前・パッケージ・インストール

• 正式名称は Cloudflare CLI。changelog の見出しは「Cloudflare CLI is now in beta」、README では「Cloudflare のための統一されたコマンドラインインターフェイス」と説明されています。
• npm パッケージ名は unscoped の cf。package.json の bin は cf と cloudflare の 2 つで、どちらも同じ実体です。PATH 上に別の cf コマンドがある場合は cloudflare を使うよう案内されています。
• リポジトリは github.com/cloudflare/cf（packages/cli）。ライセンスは MIT OR Apache-2.0 のデュアルライセンス。
• 動作要件は Node.js 22.18 以上（公式ドキュメント。package.json の engines は >=22）。Bun は非サポートで、Bun 上では cloudflare.config.ts を読むコマンドが失敗します。
• 匿名の利用テレメトリがあり、CF_SEND_TELEMETRY=false または DO_NOT_TRACK=1 で無効化できます（cf cli telemetry コマンドもあります）。

# グローバルインストール（npm / yarn / pnpm / bun いずれも公式に記載あり）
npm install --global cf
cf --version        # 1.0.0-beta.14（2026-10-12 時点の npm latest）
cf auth login

# プロジェクトでは devDependency に入れてバージョンを固定するのが推奨
npm i -D cf
npx cf --help

リリース状況とバージョン

• 2026-04-13: Cloudflare ブログ「Building a CLI for all of Cloudflare」で technical preview として初公開。この時点では一部プロダクトのみ対応で、「将来の Wrangler CLI の一部」と説明されていました。
• 2026-09-28: Birthday Week の発表「Introducing cf: the agentic CLI for the entire Cloudflare API」と changelog でオープンベータに。
• cf の現行版は 1.0.0-beta.14（npm の latest タグ）。GitHub の Releases ページにはリリースが掲載されておらず、バージョンは npm で確認しました。
• Wrangler の現行版は 4.149.0（npm の latest、workers-sdk の GitHub Releases で 10 月 8 日リリース）。本稿のコマンド確認はプロジェクトに入っていた 4.147.0 で行っています。

コマンドはどう作られているか

cf の API 系コマンドは Cloudflare の公開 API スキーマから生成されています。4 月の記事では、OpenAPI だけでは対話的な CLI コマンドや Workers バインディングを表現しきれないため、API・CLI コマンド・引数をまとめて定義する TypeScript ベースのスキーマを作ったと説明されています。9 月の記事では生成パイプラインを「Forge」と呼んでいます。コマンドは cf <product> [group…] <operation> という形にそろっており、cf schema <command> を実行すると、各コマンドが呼ぶ API の operationId・HTTP メソッド・パスを確認できます。

--help に出ないコマンドがある理由

cf cli search では見つかるのに、cf --help の一覧には出てこないコマンドがあります（例: cf mtls-certificates、cf tunnels、cf workers-builds）。理由はソースコードに書かれています。

• packages/cli/src/index.ts では、生成プロダクトのうち hideCommand: true のものを yargs に describe: false で登録しています。コメントには「invokable but suppressed from --help」とあり、コマンドとしては実行できます。
• シェル補完（packages/cli/src/commands/completions/index.ts）も hideCommand のコマンドを除外します。
• 一方、cf cli search（packages/cli/src/commands/cli/search.ts）は同梱の commands.json を MiniSearch で索引化しており、hideCommand による除外をしていません。そのため検索には出てきます。
• 1.0.0-beta.14 の同梱コードでは、生成プロダクト 180 グループのうち 88 グループが hideCommand: true です。

2. 位置づけとロードマップ

Wrangler

Wrangler は「Developer Platform のための CLI」で、Workers プロジェクトのビルド・ローカル開発・デプロイと、D1 / R2 / KV / Queues などの Workers 周辺リソースの管理が中心です。9 月の記事によれば、各プロダクトチームが手作業でコマンドを追加してきたため用語やパターンに揺れがあり、カバーしているのは約 280 のコマンドパスです。

cf

cf は「Cloudflare API 全体のためのエージェント向け CLI」という位置づけです。ゾーン、DNS、ストレージ、セキュリティ設定などのリソース管理と、Workers プロジェクトの作成・開発・デプロイを 1 つのツールで扱います。設計上の特徴は次のとおりです。

• 出力はデフォルトで JSON（stdout）。メッセージやエラーは stderr に分かれるので jq にそのままパイプできる。
• cf cli search "<やりたいこと>" で自然文からコマンドを探せる（ローカル実行・認証不要・最大 5 件）。
• cf schema <command> で、生成コマンドが送る API リクエスト（operationId、HTTP メソッド、パス、ボディのフィールド）を確認できる。
• 生成コマンドには --dry-run があり、リクエストを送らずに内容を確認できる。

実際に cf --help を実行すると、冒頭に「エージェントは入れ子の --help をたどらず、まず cf cli search を使うこと」という案内が表示されます。

置き換えか、ラップか

答えは「CLI としては後継であり、ビルドの実装としては Wrangler に委譲する部分がある」です。

• 置き換え: 9 月の発表によれば、オープンベータ終了時に cf へ利用者とエージェントを誘導する Wrangler の最終メジャーバージョンがリリースされ、その後 18 か月間メンテナンスが続きます。
• 委譲: cf dev・cf build・cf deploy は自前の dev サーバーやバンドラーを持たず、フレームワーク自身のコマンド、Cloudflare Vite プラグイン、またはインストール済みの Wrangler（4.136.0 以上）に処理を渡します。9 月の記事では、esbuild ベースの JavaScript Worker と Rust・Python の Worker の開発・デプロイは引き続き Wrangler が担うとされています。
• 併用: Wrangler プロジェクトのまま cf のリソース系コマンド（cf d1 list など）を使うことは公式に想定されています。一方、cf dev / cf build / cf deploy は cloudflare.config.ts を前提にしているため、先に cf migrate を実行する必要があります。

3. Wrangler → cf コマンド対応表

凡例: 「→」が対応関係、【cf のみ】【Wrangler のみ】は片方にしかないものです。対応関係は、公式ドキュメントの記載、または両ツールが同じ API エンドポイントを呼んでいること（cf schema の出力と Wrangler 4.147.0 の同梱コードで確認）を根拠にしています。「片方にしかない」は、cf 1.0.0-beta.14 の全コマンド一覧（commands.json、非表示コマンドを含む 2,947 件）と Wrangler 4.147.0 の --help で確認した結果です。

全体に共通する違いは、Wrangler はリソースを名前で指定することが多いのに対し、cf は API のパスパラメーターに合わせて ID を要求することが多い点です（D1 のデータベース、Queues のキューなど）。環境の切り替えは --env <NAME> が --mode <NAME> に変わります。

認証・アカウント

• wrangler login → cf auth login
• wrangler logout → cf auth logout
• wrangler whoami → cf auth whoami
• wrangler auth create / activate / deactivate / list / delete（Wrangler 側は experimental）→ cf auth create / activate / deactivate / list / delete
• wrangler auth token（現在の認証情報を出力）【Wrangler のみ】cf auth のサブコマンドは上記 8 つ（login / logout / whoami とプロファイル管理 5 つ）で、認証情報を出力するものはありません。
• wrangler auth keyring（OS キーチェーン保存の設定）【Wrangler のみ】cf 側はコマンドではなく環境変数で切り替えます（6 章参照）。

開発・ビルド・デプロイ・バージョン・ログ

• wrangler init → cf init（cf は cloudflare.config.ts と vite.config.ts を含む Hello World を生成）
• wrangler dev → cf dev（cloudflare.config.ts が必要。実体はフレームワーク / Vite プラグイン / Wrangler に委譲）
• （Wrangler に独立したビルドコマンドはない）→ cf build【cf のみ】.cloudflare/output/v0/ に Build Output を生成し、cf deploy --prebuilt で再利用できる
• wrangler deploy → cf deploy
• wrangler delete → cf workers delete <worker-id>
• wrangler versions upload → cf workers versions create
• wrangler versions list / view → cf workers versions list / get（cf workers versions list の Worker 指定は --worker-id）
• wrangler versions deploy → cf workers deployments create（どちらも POST /accounts/{account_id}/workers/scripts/{script_name}/deployments）
• wrangler deployments list → cf workers deployments list
• wrangler deployments status → cf workers deployments list の先頭要素。Wrangler 4.147.0 の deployments status は、デプロイ一覧を取得して先頭（deployments.at(0)）を表示する実装です。cf workers deployments list の help にも「一覧の最初のデプロイが、現在トラフィックを処理している最新のデプロイ」と書かれています。特定のデプロイの詳細は cf workers deployments get <deployment-id> で取得します。
• wrangler rollback → cf workers deployments create（下のコード例）。cf に Workers 用の rollback という名前のコマンドはありません。詳細は次項。
• wrangler tail 【Wrangler のみ】公式ドキュメントに「cf cannot stream live logs yet」とあり、npx wrangler tail <WORKER_NAME> を使うよう案内されています。
• wrangler triggers deploy → cf workers triggers deploy
• wrangler types → cf workers types（出力先は .cloudflare/types/index.d.ts）
• wrangler preview（open beta）→ cf previews deploy [preview-name]
• wrangler check startup → cf workers check
• （なし）→ cf migrate [path]【cf のみ】Wrangler の設定ファイルを cloudflare.config.ts に変換

ロールバックの実体

• Workers のドキュメント（Rollbacks）では、ロールバックは「指定したバージョンで新しいデプロイを即座に作成する」操作と説明されています。分割デプロイからロールバックした場合も、選んだバージョンが 100% のトラフィックを受けます。対象は直近 100 バージョンまでです。
• Wrangler 4.147.0 の wrangler rollback は、同梱コード上 POST /accounts/{account_id}/workers/scripts/{script_name}/deployments に strategy: "percentage" と「対象バージョン 100%」を送っています。シークレットが変わっていてエラーになった場合は、確認のうえ ?force=true を付けて再送します。
• cf workers deployments create は同じエンドポイントを呼びます（cf schema で確認）。フラグは --worker（別名 --script-name）、--strategy（percentage のみ）、--versions（version_id と percentage の JSON 配列。合計 100）、--bypass-deployment-checks です。--bypass-deployment-checks の help は、API の force クエリと同じく「シークレット変更後に古いバージョンへ戻すなど、通常はブロックされる場合でもデプロイを作成する」と説明しています。

# 戻したいバージョン ID を確認
cf workers versions list --worker-id <WORKER_NAME>

# そのバージョンに 100% のトラフィックを向けるデプロイを作成（= wrangler rollback と同じ API 呼び出し）
cf workers deployments create --worker <WORKER_NAME> --strategy percentage \
  --versions '[{"version_id":"<VERSION_ID>","percentage":100}]'

シークレット

ここは、公式ドキュメントの記述と CLI に実在するコマンドが一致していないので、両方を正確に書いておきます。

• ドキュメントの記述: 「cf for Wrangler users」と「Wrangler to cf reference」の両方に「cf cannot set a single secret yet.」とあります。代わりに npx wrangler secret put <SECRET_NAME> --name <WORKER_NAME> を使うか、cf deploy / cf workers versions create に --secrets-file <PATH> を渡して新しいバージョンと一緒にアップロードするよう案内されています。
• CLI の実体: cf 1.0.0-beta.14 には API から生成された cf workers secrets update <name> があります。呼ぶのは PUT /accounts/{account_id}/workers/scripts/{script_name}/secrets で、API リファレンスでの説明は「Add a secret to a Worker script by creating a new version with that secret.」です。
• cf workers secrets update の引数: 位置引数の <name> がバインディング名です。フラグは --worker（別名 --script-name）、--type（secret_text | secret_key）、--text（シークレットの値）、--format / --key-base64 / --usages（secret_key 用）、--body、--dry-run です。
• Wrangler 4.147.0 の wrangler secret put も、同梱コード上は同じ PUT .../secrets エンドポイントを呼んでいます。違いは値の渡し方で、Wrangler は対話プロンプトか標準入力から読み、cf は --text 引数で受け取ります。
• wrangler secret list → cf workers secrets list
• wrangler secret delete → cf workers secrets delete <secret-name>
• wrangler secret bulk → cf workers secrets bulk
• （なし）→ cf workers secrets get <secret-name>【cf のみ】
• wrangler secrets-store（open beta）→ cf secrets-store stores / secrets / quota

D1

• wrangler d1 create <name> → cf d1 create（名前はフラグで渡す。公式例: cf d1 create --name my-database --dry-run）
• wrangler d1 list → cf d1 list
• wrangler d1 info <name> → cf d1 get <database-id>
• wrangler d1 delete <name> → cf d1 delete <database-id>
• wrangler d1 execute <database> --remote --command "..." → cf d1 query <DATABASE_ID> --sql "..."（公式ドキュメントの対応例。Wrangler は名前、cf は ID）。--local で使えるのは cf d1 raw <database-id> で、cf d1 query にはローカル版がありません。
• wrangler d1 migrations create <database> <message> → cf d1 migrations create <message>
• wrangler d1 migrations list / apply <database> → cf d1 migrations list / apply <database>（cf はデフォルトでリモートが対象で、--local でローカル。設定の migrations_dir / migrations_pattern / migrations_table は --dir / --pattern / --table に対応）
• wrangler d1 time-travel → cf d1 time-travel（get-bookmark / restore）
• wrangler d1 export【Wrangler のみ】API には POST /accounts/{account_id}/d1/database/{database_id}/export がありますが（API リファレンス）、cf 1.0.0-beta.14 の全コマンド一覧にこのエンドポイントを呼ぶコマンドはありません。D1 のコマンドは create / delete / edit / get / list / migrations / query / raw / time-travel / undelete / update です。
• wrangler d1 insights（experimental）【Wrangler のみ】Wrangler は GraphQL Analytics API（d1QueriesAdaptiveGroups）を呼んで集計しています。cf 1.0.0-beta.14 には GraphQL Analytics API を呼ぶ汎用コマンドがありません（名前に graphql を含むのは cf cloudforce-one events graphql ... だけです）。
• （なし）→ cf d1 undelete、cf d1 edit / update【cf のみ】

# 公式ドキュメントに載っている対応例
wrangler d1 execute my-database --remote --command "SELECT 1"
cf d1 query <DATABASE_ID> --sql "SELECT 1"

R2

• wrangler r2 bucket create / list / delete / info → cf r2 buckets create / list / delete / get
• wrangler r2 bucket cors / lifecycle / lock / domain / notification / sippy / local-uploads → cf r2 buckets cors / lifecycle / locks / domains / event-notifications / sippy / local-uploads
• wrangler r2 bucket dev-url → cf r2 buckets domains managed list / update。Wrangler 4.147.0 の dev-url 系は GET / PUT /accounts/{account_id}/r2/buckets/{bucket_name}/domains/managed を呼んでおり、cf の 2 コマンドも同じエンドポイントです。有効化は cf r2 buckets domains managed update <bucket-name> --enabled。
• wrangler r2 object get / put / delete → cf r2 objects get / put / delete（cf r2 objects put は上限 300 MB。help では大きなファイルには S3 互換 API や R2 バインディングの利用を推奨）
• （なし）→ cf r2 objects list、cf r2 objects bulk-delete、cf r2 super-slurper、cf r2 temporary-credentials【cf のみ】

KV

• wrangler kv namespace create / list / delete / rename → cf kv namespaces create / list / delete / update（update の help は「Rename a namespace」）
• wrangler kv key put / get / list / delete → cf kv keys put / get / list / delete
• wrangler kv bulk → cf kv bulk
• cf にはこのほか cf kv metadata グループがあります。

Queues

• wrangler queues create / list / info / update / delete → cf queues create / list / get / edit / delete（cf は <queue-id> を取る）
• wrangler queues consumer add / remove / list → cf queues consumers create / delete / list
• wrangler queues purge → cf queues purge
• wrangler queues subscription → cf queues subscriptions
• wrangler queues pause-delivery / resume-delivery → cf queues edit <queue-id> の --settings-delivery-paused（boolean）。Wrangler 4.147.0 は PATCH /accounts/{account_id}/queues/{queue_id} に settings.delivery_paused を送っており、cf queues edit は同じ PATCH を呼ぶコマンドで、--settings-delivery-paused フラグを持っています。
• （なし）→ cf queues messages push / pull / ack / peek など、メッセージを直接操作する API コマンド、および cf queues metrics【cf のみ】

Durable Objects

• Wrangler 4.147.0 の --help には Durable Objects 専用のトップレベルコマンドはありません。クラスの宣言やマイグレーションは設定ファイルで行います。
• cf durable-objects namespaces list と cf durable-objects namespaces objects で、名前空間やオブジェクトを API 経由で参照できます【cf のみ】
• 設定面では、Wrangler の migrations は cloudflare.config.ts の worker.exports（例: exports.durableObject({ storage: "sqlite" })）に置き換わります。cf migrate はこれを自動変換しないため、手作業での移行が必要です。

Pages

• wrangler pages deploy [directory] → cf pages deploy [directory]
• wrangler pages project create / list / delete → cf pages create / list / delete（cf pages get / edit もある）
• wrangler pages deployment list / delete → cf pages deployments list / delete
• wrangler pages deployment tail 【Wrangler のみ】
• wrangler pages dev、wrangler pages functions 【Wrangler のみ】
• （なし）→ cf pages deployments rollback / retry、cf pages domains、cf pages build-cache【cf のみ】

Workers AI / Vectorize / Hyperdrive / Workflows ほか

• wrangler ai models list → cf ai models list（どちらも /accounts/{account_id}/ai/models/search）
• wrangler ai models schema <model> → cf ai get-model-schema（どちらも /accounts/{account_id}/ai/models/schema）
• wrangler ai finetune → cf ai finetunes
• （なし）→ cf ai run [model-name]（CLI から推論を実行）、cf ai to-markdown【cf のみ】
• Vectorize: create / delete / get / list / info / query / insert / upsert / list-vectors は同名で対応。wrangler vectorize get-vectors / delete-vectors → cf vectorize get-by-ids / delete-by-ids、create- / list- / delete-metadata-index → cf vectorize metadata-index create / list / delete（いずれも同じ .../get_by_ids、.../delete_by_ids、.../metadata_index/* エンドポイント）
• Hyperdrive: create / delete / get / list / update は同名で対応。cf hyperdrive replace / restart【cf のみ】
• Workflows: wrangler workflows list / delete → cf workflows list / delete、wrangler workflows describe → cf workflows get（どちらも GET /accounts/{account_id}/workflows/{workflow_name}）、wrangler workflows trigger → cf workflows instances create（どちらも POST .../workflows/{workflow_name}/instances）
• wrangler ai-search ↔ cf ai-search、wrangler containers ↔ cf containers、wrangler mtls-certificate ↔ cf mtls-certificates（--help 非表示）、wrangler turnstile（alpha）↔ cf turnstile は両方に存在
• AI Gateway（cf ai-gateway）は cf のみ

4. それぞれにしかできないこと

cf にしかできないこと

• Workers 以外のプロダクトの操作: cf zones（ゾーンの作成・設定）、cf dns records（list / create / import / export など）、cf cache（パージなど）、cf rulesets / cf firewall、cf zero-trust、cf load-balancers、cf images、cf stream、cf radar、cf billing、cf accounts、cf registrar など。--help に表示される生成プロダクトだけで 92 グループ、非表示を含めると 180 グループあります。
• API 由来の細かな操作: R2 のオブジェクト一覧、Queues のメッセージ push / pull、D1 の undelete など、Wrangler にコマンドがない操作も API があればそのまま使えます。
• エージェント向けの機能: cf cli search、cf schema、JSON がデフォルトの出力。公式ドキュメントによれば、対応するコーディングエージェント内で cf dev を実行すると Local Explorer API の URL も表示されます。
• グローバルな --zone / -z フラグと CLOUDFLARE_ZONE_ID による、ゾーン単位コマンドのデフォルト指定。
• ビルドとデプロイの分離: cf build で Build Output を作り、cf deploy --prebuilt で同じ成果物をデプロイできる。

Wrangler にしかできないこと（cf 1.0.0-beta.14 時点）

• ライブログ: wrangler tail、wrangler pages deployment tail。
• esbuild ベースの Worker、Rust / Python Worker のビルドとデプロイ（9 月の発表による）。これらは cf 経由でも Wrangler が処理します。
• Wrangler 自身のローカル開発サーバー。wrangler dev は Miniflare（本番と同じ workerd ランタイムで Worker を実行するシミュレーター）上で動き、バインディングはデフォルトでローカルにシミュレートされます。--remote によるリモート実行や、wrangler pages dev もあります。
• wrangler d1 export、wrangler d1 insights、wrangler auth token（それぞれの根拠は 3 章を参照）。

ローカル実行と Miniflare

cf 自体は dev サーバーを持ちませんが、miniflare に依存しています（1.0.0-beta.14 の package.json では 5.20261006.1-alpha）。README によれば、これはリソース操作の --local フラグのためです。cf kv keys ... --local、cf d1 raw --local、cf d1 migrations apply --local、cf r2 objects ... --local などを付けると、本番 API ではなく短命の Miniflare インスタンスに対して操作します。ドキュメントでは、状態は cf の設定ディレクトリ配下に保存されるとされ（--help の既定値表示は ~/.config/cloudflare/state）、--persist-to で変更できます。ローカル版がないコマンドは本番にフォールバックせず、エラーになります。

5. 設定ファイル

Wrangler: wrangler.jsonc / wrangler.toml

• wrangler.json、wrangler.jsonc、wrangler.toml のいずれかを使います。新規プロジェクトには wrangler.jsonc が推奨で、新しい機能の一部は JSON 設定でしか使えません。
• 設定ファイルを Worker の source of truth として扱うのがベストプラクティスです。ダッシュボードで変えた変数やルートは次のデプロイで上書きされます（keep_vars で変数は保持可能）。
• 環境は env.<name> ブロックで定義し、--env で選択します。name や compatibility_date は環境に継承されますが、vars や KV / D1 / R2 などのバインディングは環境ごとに明示が必要です。

cf: cloudflare.config.ts

• TypeScript モジュールで、cf/config から defineConfig を import します。cf を devDependency に入れ、package.json に "type": "module" が必要です。
• トップレベルは accountId、complianceRegion、worker、containers。Worker の設定は worker の下にまとまり、name → worker.name、main → worker.entrypoint、compatibility_date → worker.compatibilityDate のように camelCase になります。
• バインディングは worker.env に bindings.d1(...)、bindings.secret(...) などのビルダーで書きます。トリガーは worker.triggers（triggers.fetch / scheduled / queue / email など）、Durable Objects や Workflows のクラスは worker.exports で宣言します。
• 環境はマージされません。defineConfig に関数を渡し、mode（--mode で指定）や isPreview で分岐して、モードごとに完全な設定を返します。cf migrate は env.<NAME> を switch (ctx.mode) の case に変換します。
• ビルド設定は cloudflare.config.ts に書きません。Vite を使う場合は vite.config.ts、Wrangler バンドラーの場合は自動生成される wrangler.config.ts に置きます（ベータ中は experimental）。
• 生成物の置き場所は .cloudflare/ です（Build Output は .cloudflare/output/v0/、型は .cloudflare/types/index.d.ts）。

// cloudflare.config.ts の最小例（公式ドキュメントの例をもとにしたもの）
import { defineConfig } from "cf/config";
import * as entrypoint from "./src/index.ts" with { type: "cf-worker" };

export default defineConfig({
  worker: {
    name: "example-worker",
    entrypoint,
    compatibilityDate: "<COMPATIBILITY_DATE>",
  },
});

両者の関係

• cloudflare.config.ts があれば、cf は Wrangler の設定ファイルを無視します。逆に Wrangler は cloudflare.config.ts を読みません。
• wrangler tail など Wrangler のコマンドを使い続けるうちは、移行後も Wrangler の設定ファイルを残しておく必要があります。
• cf migrate は既存ファイルを上書きしません。変換できない項目は TODO(@cloudflare) コメントとして書き込まれ、ファイル先頭に throw が入るため、解消するまで cf dev / build / deploy は失敗します。変換されないのは、Durable Object の migrations、Workflows、Containers、Workers Sites（site）、preview_id 系、keep_vars、シークレット（.dev.vars / .env は読まない）などです。
• 移行前の Wrangler プロジェクトで cf dev / cf build / cf deploy を実行すると、自動設定がエントリーポイントやバインディングを含まない cloudflare.config.ts を作ったり、package.json などを書き換えたりします。公式ドキュメントは、先に cf migrate を実行するよう案内しています。

cf migrate --dry-run      # 変更内容の確認のみ
cf migrate                # cloudflare.config.ts を生成し、cf を devDependency に追加
cf migrate --bundler vite # バンドラーを明示（vite | wrangler）

6. 認証モデルの違い

どちらも「ブラウザでの OAuth ログイン」と「API トークン」の 2 本立てですが、ログイン情報は共有されません。公式ドキュメントにあるとおり、cf は Wrangler のログインを再利用しないため、cf auth login を別途実行する必要があります。

Wrangler（公式ドキュメントより）

• wrangler login のデフォルトは、ブラウザを開いて localhost:8976 へのコールバックで完了する方式です。--device を付けると OAuth 2.0 Device Authorization Grant（RFC 8628）を使います。--scopes でスコープを絞れます。
• 保存先はデフォルトで、グローバル設定ディレクトリ配下の平文 TOML（ドキュメント上「通常は ~/.config/.wrangler/config/default.toml」）です。
• --use-keyring、または wrangler auth keyring で OS キーチェーン方式にすると、AES-256-GCM で暗号化した default.enc に保存し、鍵は macOS Keychain / libsecret / Windows Credential Manager に置きます。保存先は wrangler whoami で確認できます。
• 優先順位は CLOUDFLARE_API_TOKEN → CLOUDFLARE_API_KEY + CLOUDFLARE_EMAIL（Global API Key）→ OAuth トークンです。

cf（ドキュメントと 1.0.0-beta.14 のソースコードより）

ログインフローと保存先は公式ドキュメントに詳しく書かれていないため、npm パッケージ cf@1.0.0-beta.14 の同梱コードで確認しました。

• ログインフロー: cf auth login の --device フラグはデフォルトで有効（help:「Use OAuth device authorization (use --no-device for the localhost callback flow)」）です。デフォルトでは OAuth 2.0 Device Authorization Grant（grant_type=urn:ietf:params:oauth:grant-type:device_code、エンドポイント dash.cloudflare.com/oauth2/device/auth）を使います。ドキュメントにある「リンクとワンタイムコードを表示し、ブラウザで承認する」流れがこれにあたります。
• --no-device を付けると、PKCE（code_challenge_method=S256）付きの Authorization Code フローになり、http://localhost:8877/oauth/callback で受け取ります。--no-browser はリンクを開かずに表示だけ行います。
• 設定ディレクトリ: アプリ名 cloudflare の XDG 形式パスです。macOS は ~/Library/Preferences/cloudflare、Linux は ~/.config/cloudflare、Windows は %APPDATA%\xdg.config\cloudflare で、XDG_CONFIG_HOME を設定するとそちらが優先されます。
• 認証情報ファイル: デフォルトでは平文 JSON の <設定ディレクトリ>/config/default.json（名前付きプロファイルは <名前>.json）に、パーミッション 0600 で書き込みます。ディレクトリとプロファイルの紐づけは <設定ディレクトリ>/profiles/directory-bindings.json に保存されます。
• OS キーリング: CLOUDFLARE_AUTH_USE_KEYRING=true のとき（またはユーザー設定の keyring_enabled が true のとき）は、AES-256-GCM で暗号化した <設定ディレクトリ>/config/<プロファイル>.enc に保存し、鍵を @napi-rs/keyring 経由で OS キーリング（サービス名 cloudflare）に置きます。1.0.0-beta.14 の cf auth サブコマンドの help には、これを有効にするフラグはありません。
• 認証情報の優先順位は CLOUDFLARE_API_TOKEN（カレントディレクトリの .env も含む）→ --profile <NAME> → cf auth activate でディレクトリに紐づけたプロファイル → cf auth login のデフォルトプロファイルです。Global API Key はサポートされません（ドキュメント）。
• アカウントは、CLOUDFLARE_ACCOUNT_ID → cloudflare.config.ts の accountId → プロジェクトに保存された前回の選択 → アクセスできる唯一のアカウント、の順で決まります。非対話環境で候補が複数ある場合はエラーになります。選択したアカウントのキャッシュは、最寄りの node_modules/.cache/cloudflare/ か .cloudflare/cache/ の cloudflare-account.json です。
• .env から読むのは認証・コンテキスト関連の限られた変数（CLOUDFLARE_API_TOKEN、CLOUDFLARE_ACCOUNT_ID、CLOUDFLARE_ZONE_ID など）だけで、.env.local や .env.<MODE> は読みません。トークンを含む .env はコミットしないこと。

Wrangler にも --profile と wrangler auth create / activate などのプロファイル機能（experimental）が入っており、ディレクトリ単位でアカウントを切り替える仕組みは両者で共通しています。

7. CI/CD での使い方

共通

• CI ではブラウザログインが使えないため、CLOUDFLARE_API_TOKEN と CLOUDFLARE_ACCOUNT_ID をシークレットとして渡します。トークンには必要最小限の権限だけを付けます（Wrangler のドキュメントでは「Edit Cloudflare Workers」テンプレートを起点にするよう案内）。
• cf のドキュメントは、CI で毎回同じリリースを使うために cf を devDependency としてインストールするよう案内しています。

Wrangler

• GitHub Actions の公式ドキュメントでは cloudflare/wrangler-action@v4 を使い、apiToken と accountId を渡して wrangler deploy を実行する構成が紹介されています。
• GitHub Actions を使わない選択肢として、Cloudflare 側でビルドする Workers Builds もあります。

cf

• cloudflare.config.ts は必ずコミットしてください。ない場合、CI で自動設定が走り、レビューなしでファイルが書き換えられます。
• cf build → cf deploy --prebuilt --mode production の 2 段構成で、同じ成果物をデプロイできます。ビルド時とデプロイ時の mode が一致しないと、アップロード前に停止します。
• cf deploy --dry-run は認証情報なしで動くため、フォークからの PR でも検証に使えます。cf previews deploy はブランチ名（GITHUB_HEAD_REF など）からプレビュー名を決めます。
• 非対話モードの落とし穴: 破壊的なコマンドを --force なしで実行すると Aborted. を stderr に出して何もせず、終了コード 0 で終わります。終了コードだけでは削除の成否を判断できません。
• テレメトリを止めたい場合は CF_SEND_TELEMETRY=false を設定します。

# cf を使う GitHub Actions のステップ（公式ドキュメントの構成を要約）
- run: npm ci
- run: npx cf build
- run: npx cf deploy --prebuilt --mode production --dry-run
- if: github.event_name == 'push'
  run: npx cf deploy --prebuilt --mode production
  env:
    CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
    CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

8. 使い分けの推奨（2026-10 時点）

1. 既存の Wrangler プロジェクト（wrangler.jsonc / wrangler.toml）の dev / deploy は、当面 Wrangler のままで問題ありません。ベータ終了後も 18 か月のメンテナンス期間があります。
2. DNS、ゾーン設定、キャッシュパージ、WAF、Zero Trust など Workers 以外の操作や、Wrangler にない API 操作は cf を使います。Wrangler プロジェクトのままでもリソース系コマンドは併用できます。
3. 新規の Vite ベース Worker で、ベータ版の変更を許容できるなら cf init から始めると、cloudflare.config.ts による型付き設定を使えます。
4. 移行するなら、まず cf migrate --dry-run で差分を確認します。Durable Object の migrations、Workflows、Containers、シークレットは手作業で移行し、wrangler tail を使い続けるあいだは Wrangler の設定ファイルを残します。
5. コーディングエージェントに作業させる場合は、公式が提案するように AGENTS.md に「Wrangler 設定ファイルがないプロジェクトでは cf を使う」と書いておくと、2 つのツールの使い分けをエージェントに伝えられます。
6. CI は本番デプロイの経路を一本にします。Wrangler プロジェクトなら wrangler-action、移行済みなら cf build と cf deploy --prebuilt。cf は devDependency で固定し、破壊的な操作では --force の扱いに注意します。

比較サマリー

公開情報がない項目

• オープンベータの終了時期: 公式ブログ・changelog・ドキュメントに記載なし（2026-10-12 確認）。
• cf へ誘導する Wrangler の「最終メジャー版」のバージョン番号と時期: 公式ブログ・changelog・ドキュメントに記載なし（2026-10-12 確認）。

参考資料

• Introducing cf: the agentic CLI for the entire Cloudflare API（Cloudflare Blog, 2026-09-28）
• Building a CLI for all of Cloudflare（Cloudflare Blog, 2026-04-13）
• Changelog: Cloudflare CLI is now in beta
• Cloudflare CLI ドキュメント（概要）
• cf: Get started（インストールとサインイン）
• cf for Wrangler users
• Migrate a Wrangler project
• Wrangler to cf reference
• cf: Develop, build, and deploy
• cf: Programmatic configuration（cloudflare.config.ts）
• Use cf with coding agents
• Use cf in CI
• cf: Environment variables
• GitHub: cloudflare/cf
• cloudflare/cf: packages/cli/src/index.ts（hideCommand の扱い）
• cloudflare/cf: packages/cli/src/commands/cli/search.ts
• npm: cf
• Wrangler ドキュメント
• Wrangler General commands（login / whoami / auth）
• Wrangler configuration
• Workers: Rollbacks
• Workers: Development & testing
• Workers CI/CD: GitHub Actions
• API: Create Worker Deployment
• API: Add script secret
• API: Export D1 Database
• GitHub: cloudflare/workers-sdk Releases
• npm: wrangler