【速報】Cloudflare、新CLI「cf」をオープンベータ公開──Wranglerから何が変わって、Web制作現場はどう動くか
公開日
2026年9月28日、CloudflareがWranglerの後継となる新CLI「cf」をオープンベータで公開しました。従来のWranglerが対応していたAPI操作は約280、cfは3,000以上のAPI操作をカバーし、TypeScriptネイティブの設定ファイルとVite + HMRの開発体験、JSON出力のデフォルト化、そして「AIコーディングエージェントで使いやすい」ことを明確に打ち出した設計が特徴です。
この記事では、WordPress + Cloudflare構成でサイト保守を担当するシエロデザインが、現場の実装・運用目線で「何が変わって」「いつ移行判断すべきか」を整理します。公式ドキュメントの翻訳ではなく、実務の意思決定材料に絞って書きます。
先に結論：移行判断の目安
| 状況 | 推奨アクション |
|---|---|
| 新規Workersプロジェクトをこれから作る | cfで始める（最初から正解の環境） |
| 既存Workersプロジェクトが稼働中 | オープンベータ中は様子見。cf migrateの実行テストだけ試す |
| AIコーディングエージェント（Claude Code等）で開発 | すぐにcfを試す価値あり（エージェント最適化が本命） |
| 社内に Wrangler 大量に使ってるチームがある | 18か月の猶予期間がある。慌てず正式版を待つのも可 |
| Pages / R2 / D1 / KVを横断で触りたい | cfに移行する価値大（API全体を一本化） |
Cloudflare が cf をリリースした背景
Cloudflareの公式発表で興味深いデータが共有されました。2026年3月時点でWranglerの利用の25%がコーディングエージェント経由、2026年9月第3週には48%まで上昇。しかもエージェントは人間の利用者より1日あたりの実行コマンド種類が約2倍、1日に6回以上実行する確率が約4倍高い、というものです。
つまりWranglerの利用者の半分弱がすでに「AIが打ち込んでいる」状態になっており、人のCLI操作体験の最適化だけでは追いつかないフェーズに入っていた、ということです。cfはこの前提から再設計されています。
Wrangler と cf の違い（実務目線）
公式比較を実装者目線で整理するとこうなります。
| 項目 | Wrangler | cf |
|---|---|---|
| 対応API操作数 | 約280 | 3,000以上 |
| 設定ファイル | wrangler.toml / wrangler.jsonc | cloudflare.config.ts（TypeScriptネイティブ） |
| ビルドツール | esbuild | Vite（HMR対応） |
| 出力フォーマット | 人間可読が中心 | JSON出力がデフォルト |
| エージェント対応 | 人間向けUI優先 | 最初からエージェント対応設計 |
| インストール | npm i -g wrangler |
npm i -g cf |
| 既存プロジェクト移行 | － | cf migrateで変換 |
とくに大きい変更点3つ
個別の仕様の中でも、現場で効いてくる変更を3つ挙げます。
| # | 変更点 | 何が嬉しいか |
|---|---|---|
| 1 | 設定ファイルがTypeScript | 補完・型チェック・リファクタ耐性が入る。設定の記述ミスが実行時ではなくビルド時に落ちる |
| 2 | Vite + HMRビルド | 開発中の反映が速い。esbuildより開発体験が明確に上がる |
| 3 | JSON出力デフォルト | CIパイプライン・エージェント・スクリプトから結果をパースしやすい |
Wranglerはいつまで使えるのか
既存のWranglerユーザーが気になるのは「サポートはいつ切れるのか」です。公式のロードマップは次の通りです。
| フェーズ | Wranglerの扱い |
|---|---|
| 現在（cfオープンベータ中） | Wranglerは引き続き主力。両方使える |
| cfベータ終了時 | Wranglerの最終メジャーリリースが出て、cfへの移行を案内 |
| 最終リリース以降 | 18か月間のメンテナンス期間（セキュリティ修正中心） |
| 18か月後 | サポート終了見込み |
つまり最短でも最終リリースから18か月は使い続けられるので、慌てて全プロジェクトを移行する必要はありません。ただし新規プロジェクトからcfに切り替えるのは早いほうが得です。
WordPress + Cloudflare 構成の現場視点
弊社シエロデザインではWordPressサイトの保守運用でCloudflare（キャッシュ・CDN・WAF・Workers）を多用します。この構成でcfを使うメリットを3点挙げます。
1. Workers でキャッシュパージを自動化
WordPress更新時に特定URLだけキャッシュをパージする運用は、Wrangler + Workersで実装してきました。cfはcloudflare.config.tsで型補完が効くので、「どのZoneのどのキャッシュタグをパージするか」の記述ミスが激減します。保守案件の属人化を減らす点で地味に効きます。
2. Pages / R2 / D1 を一本のCLIで触れる
これまでPages・R2（オブジェクトストレージ）・D1（SQLite互換DB）はそれぞれダッシュボードや個別コマンドで触っていました。cfは3,000以上のAPIをカバーするため、画像アップロード・DBマイグレーション・Pagesデプロイを1つのCLIから一気通貫で実行できます。CI/CDの記述が明確にシンプルになります。
3. Claude Code 等との相性が良い
cfはJSON出力デフォルト・TypeScript設定で、Claude CodeのようなAIコーディングエージェントとの連携が最初から想定されています。弊社ではWordPress保守タスク（キャッシュパージ・エラーログ取得・Rate Limit調整）をClaude Codeから叩く運用を試行中ですが、Wrangler時代は出力のパースが手間でした。cfに切り替えると、エージェントが結果を解釈して次の判断に進むまでが短縮される見込みです。
移行手順の目安
既存のWorkersプロジェクトをcfに移行するフローは次の通りです（詳細は公式ドキュメント参照）。
npm i -g cfでcfをインストール- プロジェクトルートで
cf migrateを実行し、wrangler.toml（またはwrangler.jsonc）をcloudflare.config.tsに変換 - 変換結果を目視でチェック（環境変数・secrets・bindingsが正しく移っているか）
cf devでローカル確認（Vite + HMRが立ち上がる）cf deployで本番デプロイ- CI/CDパイプラインの
wranglerコマンドをcfに差し替え
注意点として、オープンベータ段階では「まだcf側に移っていない機能」がいくつかあります。移行前に自分のプロジェクトで使っている全機能がcfでサポートされているか、確認を忘れないようにしてください。
cielo での当面の方針
弊社シエロデザインでは、当面以下の方針でcfを扱っていきます。
- 新規Workersプロジェクトはcfで開始（研修用含む）
- 既存の保守案件はWrangler継続。ただし
cf migrateの実行テストはステージングで試す - Claude Codeとの連携スクリプトはcfで書き直しを検討
- オープンベータ中は本番環境でのcf単独運用はしない（Wranglerをフォールバックに残す）
- 正式版リリースと主要機能のcf対応が揃った段階で、全案件を順次移行
よくある質問
Q. 今すぐ全プロジェクトをcfに移行すべきですか？
A. いいえ。オープンベータ段階では主要機能のcf対応が揃っていない可能性があります。新規プロジェクトから始めて、既存プロジェクトは正式版と機能完備を待つのが安全です。
Q. cfにしたら実行速度は上がりますか？
A. ビルド速度（Vite + HMR）は上がります。デプロイ後のWorkers自体の実行速度はWranglerと変わりません（同じCloudflareエッジで動くため）。
Q. 既存のwrangler.tomlは残しておくべきですか？
A. 移行後も当面は残しておくことをおすすめします。cf migrateで変換後に問題が出た場合、Wranglerに戻すのが容易です。移行が安定したら削除します。
Q. CI/CDのスクリプトはどう書き換えますか？
A. 基本はwranglerをcfに置き換えるだけですが、JSON出力がデフォルトになる点で既存のパース処理が壊れることがあります。CI上のjq等でのJSONパースに書き換える前提で見直しましょう。
Q. AIコーディングエージェントとの連携は何が変わりますか？
A. JSON出力デフォルトと3,000以上のAPIカバレッジで、エージェント側が「結果を見て次の判断をする」サイクルが回しやすくなります。弊社ではClaude Codeで保守タスクをスクリプト化しており、cf移行で記述量が減ることを期待しています。
Q. Pages（静的サイトホスティング）だけ使っていてもcfは入れるべきですか？
A. Pagesのみの運用ならWrangler／ダッシュボードで十分間に合います。cfのメリットが大きく出るのはPages・Workers・R2・D1など複数サービスを横断で使うケースです。
Q. 日本語ドキュメントはありますか？
A. 2026年10月時点では英語ドキュメントが先行しています。日本語版はCloudflare Japanが順次整備中です。実装にあたっては英語ドキュメントを並行で読む前提をおすすめします。
Q. シエロデザインにWordPressサイトのCloudflare運用を相談するとき、何を伝えれば良いですか？
A. 「現在のCloudflareプラン（Free / Pro / Business / Enterprise）」「Workersを使っているか」「月間PV・キャッシュヒット率の目安」の3点があれば、現状の最適化余地と、cf移行を含めた今後の運用方針を具体的に提案できます。
まとめ：次に取るアクション
- 新規Workersプロジェクトはcfで開始してみる
- 既存プロジェクトは
cf migrateの実行テストだけステージングで試す - CI/CDの
wranglerコマンドをcfに差し替えた場合の影響を洗い出しておく - AIコーディングエージェント連携スクリプトは、cf前提で書き直しを検討する
弊社シエロデザインではWordPress + Cloudflare構成の保守運用、Workers / Pages / R2 を使った運用改善、Claude Code等のAIエージェントを前提にした開発フロー設計をお手伝いしています。「cfに移行して何が変わるか、自社の構成で具体的に知りたい」といったご相談があればお気軽にお問い合わせください。
この記事を書いた人
シエロデザインのサービス
お問い合わせ
Webサイト制作・保守・広告運用・Web戦略チーム支援など、私たちシエロデザインが伴走できる領域はさまざまです。
「うちの場合どうすれば？」というご相談も、まずはお気軽にお声がけください。