Cloudflareの新CLI「cf」は3,000超の操作を1つに束ねた

Cloudflareで動かしているWorkerにDNSレコードを1つ足したいだけなのに、wranglerのコマンドでは完結しない。ブラウザでダッシュボードを開き直す。そんな経験がある人は多いはずだ。Workerのデプロイはターミナルで済むのに、DNSやWAFの設定だけは別の窓口に頼ってきたのは、wranglerが担当してきた範囲がもともと狭かったからだ。Cloudflareは2026年9月28日、この境目を引き直す新しいCLI「cf」を公式ブログで発表した。Workerのデプロイに加え、DNSやWAF、独自ドメインの購入まで、1つのツールから動かせるようになったという。

wranglerの外にあった操作

wranglerでは、なぜDNSやWAFの設定に手が届かなかったのか。公式ブログはその理由を数字で説明している。wranglerが対応するのは約280操作にとどまり、Cloudflareが提供する機能全体は数千に上るという(Cloudflare公式ブログ)。つまりwranglerは、Cloudflareの機能のうち1割にも満たない範囲しかコマンド化していなかった。

新しいcfは、この範囲を3,000以上の操作まで一気に広げた。280から3,000、10倍を超える桁の差だ。

このグラフが表すのは、単なる機能数の増加ではない。公式ブログが挙げる例はこうだ。エージェントにcfを渡し、「Workerを立ち上げて、デプロイし、監視して、Cloudflare Accessで保護し、ドメインを買って、WAFを前段に置いて」と頼む。この一連の作業が単一のツールで完結するという(Cloudflare公式ブログ)。これまでなら、デプロイはwrangler、それ以外はダッシュボードやAPIの個別呼び出しに分かれていた作業だ。では、Cloudflareはなぜここまで対応範囲を広げる設計にしたのか。

なぜエージェントを主役にしたか

cfという名前の由来自体が、この疑問への手がかりになる。公式ブログのタイトルには、cfを「エージェント向けのCLI」と位置づける言葉が入っている。原題は「Introducing cf: the agentic CLI for the entire Cloudflare API」だ。

Cloudflareは、wranglerの使われ方の変化も数字で示した。2026年3月時点で、利用の約25%はAIエージェント経由だった。発表時点ではその比率が48%まで伸びたという(Cloudflare公式ブログ)。半数近くの利用が、人間が直接打つコマンドではなく、エージェントが実行するコマンドに置き換わっていたことになる。

自分がこの数字より驚いたのは、公式ブログの言い切り方だ。「人間はこのCLIから一歩離れた存在になる」とまで書かれている(原文: “one step removed from using it”)。開発者向けツールの説明として、かなり踏み込んだ言い方だと感じた。

この設計判断は出力形式にも表れている。従来のwranglerは、人間が読むための整形されたテーブル表示を主な出力にしていた、とgihyo.jpの解説は指摘する(gihyo.jp)。cfはこれを転換し、JSON形式の出力を既定にした。公式ブログは、エージェントにはJSON形式の出力が必要だと説明する(原文: “agents need JSON”)。人間向けの整形表示とは別に、トークン消費を抑えた圧縮形式で返す仕組みを用意したという。

コマンドを探す段階にも同じ発想が働く。自然言語で「〜したい」と伝えると、cf cli searchが候補コマンドを返す。この検索は、小さな検索インデックスが各操作のAPI説明とパラメータを手がかりに一致するコマンドを探す仕組みだという(Cloudflare公式ブログ)。公式ブログはさらに、型付きの設定ファイルもエージェントにとって特に助けになると述べている。エージェントが3,000以上の操作を安全に呼べるようにするために、設定ファイルの側はどう変わったのか。

型で防ぐ設定ミス

wrangler.tomlやwrangler.jsonで設定を書いてきた人なら、次の場面に覚えがあるはずだ。KVのnamespace idを1文字打ち間違えても、保存した瞬間には何も起きない。エラーが表面化するのは、Workerを実際に動かしてアクセスしたときだ。

cfは、この設定ファイルをTypeScriptのcloudflare.config.tsに置き換えた。公式ブログのコード例では、defineConfigという関数の中に設定をまとめる。KVならばbindings.kv({ id: "..." })のように、連携先ごとに専用の関数を呼ぶ形になっている(Cloudflare公式ブログ)。

bindings.kv()は文字列ではなく関数呼び出しだ。渡す値の型が合わない、必須の項目が抜けているといったミスを、エディタが保存前に示してくれる。wrangler.tomlの文字列指定では、実行するまで気づけなかった間違いが、書いている最中に分かるようになった。

用意されている連携先はKV・D1・R2にとどまらない。公式ブログのコード例に出てくる専用の関数を挙げる(Cloudflare公式ブログ)。

• bindings.text() bindings.secret(): 文字列や秘密情報を渡す
• bindings.kv() bindings.d1() bindings.r2(): KV・D1・R2のストレージにつなぐ
• bindings.queue() bindings.ai() bindings.vectorize(): キュー・AI・ベクトル検索につなぐ
• triggers.scheduled() triggers.queue(): wranglerのcron設定やキューからの呼び出しに対応する起動条件を書く

この仕組みを、今すぐ本番のwranglerから乗り換えて試していいのだろうか。

乗り換え前に確認すること

2026年9月29日時点で、cfはオープンベータの1.0.0-beta.5だ。GitHubのリポジトリでも、オープンベータであることと、Apache-2.0・MITのデュアルライセンスで公開されていることを確認できた(GitHub)。npmに公開されているパッケージ情報でも裏付けが取れた。説明欄は「The Cloudflare CLI」となっている。メンテナには、CloudflareのWorkers開発チームのアドレスが含まれている(npm registry)。npm i -g cfでインストールでき、既存のwrangler設定はcf migrateコマンドで移行できるという。

ただし、cfがwranglerを完全に置き換えるわけではない。JavaScript Workerのビルドや開発サーバーの中身は、引き続きwrangler相当の仕組みが担う。公式ブログは、オープンベータが終わったあともwranglerの保守を18か月続けると明言しており、手元のwranglerを今すぐ手放す必要はない。

まとめ

cfが変えたのは、Workerのデプロイだけを扱っていたCLIの範囲だ。DNSやWAF、ドメイン購入まで含む3,000以上の操作に対応する窓口に広がった。設定ファイルがTypeScriptになったことで、KVやD1の設定ミスを実行前に見つけられるようになった点も、開発者にとっての実利になる。今はオープンベータの段階だが、cf migrateで手元の設定を試すことはでき、wranglerは当面のあいだ併存する。