Cloudflare の新しい CLI「cf」：Agent のために作り直されたツール

Cloudflare のコマンドラインツール Wrangler の利用者は、いま Agent に変わりつつあります。Cloudflare 自身の数字によると、今年の早い時期に Agent が Wrangler 利用の4分の1を占め、1年前は1桁台のパーセントにすぎませんでした。先週にはその割合が 48% に達しました。

しかも Agent は人よりずっとよく使います。1日に使う異なるコマンドの数は人の約2倍で、6つ以上のコマンドを使う確率は人の4倍近くです。

ネットワーク全体のトラフィックも同じ方向に動いています。下は Cloudflare Radar（Cloudflare が公開しているネットワークトラフィックの統計ページ）のスクリーンショットです。Web ページ（HTML）へのリクエストのうち、機械によるものが 57.5%、人によるものは 42.5% にとどまります。また、すべてのレスポンスをコンテンツタイプ別に見ると、JSON が 33.1% で、HTML の 12% を大きく上回っています。ここでの「機械」はあらゆる自動化プログラムを指し、AI Agent はその一部にすぎません。したがって Agent の割合としてそのまま読むことはできませんが、機械が読むデータ形式がすでに Web ページより一般的になっていることは示しています。

Cloudflare 自身のツールに話を戻すと、Wrangler がカバーする操作は約280個ですが、Cloudflare 全体では数千の操作があります。そのため、Agent が Cloudflare で実行できることは Wrangler のコマンド一覧に制約されていました。そこで Cloudflare は新しいコマンドラインツール cf を作りました。Cloudflare API 全体をコマンドラインに持ち込むことを目指し、設計のすべてが Agent を第一の利用者として組まれています。現在はオープンベータで、npm i -g cf でインストールできます。

以下では、Agent がどこでつまずくかという観点から、cf の4つの変更を説明します。

1つのツールで Cloudflare のすべてができる

まず、Wrangler がなぜ280個で止まっていたのかを見ます。各製品チームがそれぞれ手作りしていたため、同じ「リソースの情報を見る」操作でも、あるチームは d1 info、別のチームは hyperdrive get、また別のチームは workflows describe と名付けました。数千行を費やした独自の体験を作ったチームもありますが、ほとんど使われていません。チームが増えれば、コマンドの流儀をそろえるのは難しくなります。

cf はやり方を変えました。コマンドを手で書くのをやめ、API の OpenAPI 仕様（各エンドポイントにどんなパラメータがあるかを記述する標準ドキュメント）から直接生成します。Cloudflare のすべての API にはもともとこの仕様があり、API ドキュメントや各言語の SDK の生成に使われています。仕様にもう少しだけ注釈を加えれば、Forge という統一的な生成パイプラインがコマンドライン用のコマンドも一緒に出力できます。その結果、コマンドは約280個から、3,000 を超える API 操作をカバーするまでに広がりました。

利用者にとって最も直接的な変化はこうです。1つのツールを使って、Agent に「Worker（Cloudflare 上で動くサーバー側の小さなコード）を作り、デプロイし、監視し、Cloudflare Access で保護し、ドメインを買い、その前に WAF（Web アプリケーションファイアウォール）を置く」という一連の作業を続けて任せられます。ツールを切り替える必要も、ダッシュボードをクリックして回る必要もありません。

出力は人向けの表ではなく、既定で JSON

Agent が Wrangler を使うとき、ほぼすべてのコマンドに自分で --json を付け、さらに jq（JSON のフィールドを絞り込むコマンドラインの小さなツール）で必要な数項目だけを取り出します。ところが Wrangler で --json に対応しているのは一部のコマンドだけで、残りは人向けに整形した表を出力します。Agent は表も読めますが、jq 1本で済ませるより時間もトークンもかかります。

cf はこれを逆にしました。JSON が既定の出力です。人が見るときは整形され、Agent が見るときは余分な空白を詰めてコンテキストを節約します。Cloudflare の考えでは、このツールのコマンドの大半は人がほとんど直接触りません。実際には Agent に結果を絞り込ませ、あなたが望む形式で報告させるのですから、あなたがまず細かく読まない表を渡す意味はありません。

とはいえ、ドメインを検索して購入するように、人が決めなければならないこともあります。そうしたコマンドを名前付きパラメータの長い連なりで書くのは難しいので、cf は API の要件を検証付きの入力に分解し、人がフォームのように1つずつ入力できるようにしています。

Agent に任せることもできます。デモでは --force を付けると、コマンドは確認を省略して JSON の結果をそのまま返します。

3,000 のコマンドから、Agent は使うべき1つをどう見つけるか

コマンドが多いと、コマンド一覧をそのまま Agent に渡すだけでコンテキストがあふれてしまいます。そこで cf には cf cli search が加わりました。Agent がやりたいことを自然言語で伝えると、小さな検索インデックスが各コマンドの API 説明とパラメータをもとに、該当するコマンドの一覧を返します。Agent が初めて --help を実行したとき、cf はこのコマンドの存在を自動的に教えるので、プロンプトで伝える必要はありません。

設定ファイルを TypeScript にして、エディターが Agent の誤りを正す

Wrangler の設定は TOML か JSONC で書きます。Cloudflare の観察では、TOML にはアクセスできるスキーマがなく、JSONC はスキーマへのリンクを付けられるものの Agent はほとんど見に行きません。cf の新しい設定ファイルは cloudflare.config.ts といい、TypeScript で書きます。利点は、LSP（Language Server Protocol。エディターが補完やエラー表示を行うための仕組み）のプラグインを使う Agent、たとえば Claude Code や Codex が、各フィールドが何で何を入れられるかを直接読み取れ、より正確な修正ができることです。Cloudflare によると、この形式を事前に知らない Agent でも、Wrangler と同名でも意味が大きく変わった env のような部分を含め、設定を問題なく見つけて編集できます。

もう1つ副次的な効果があります。設定をコードで生成できることです。Cloudflare 社内では、開発者ごとにカスタム環境を何通りもコピーしていて元は 5,000 行を超えていた Wrangler の設定ファイルがあり、共通のベースから環境ごとに生成する形に変えたところ、40% 短くなりました。複数環境の Worker は、Vite 標準の mode 引数に応じて2組の設定を切り替えるだけで済みます。

import { bindings, defineConfig } from "cf/config";
import * as entrypoint from "./index.js" with { type: "cf-worker" };

export default defineConfig(({ mode }) => ({
  worker: {
    name: "example-worker",
    entrypoint,
    compatibilityDate: "2026-09-27",
    env: {
      Environment: bindings.text(`This is ${mode} environment`),
    },
  },
}));

bindings は、Worker が接続できるもの（環境変数、シークレット、KV キャッシュ、D1 データベース、R2 ストレージ、キュー、AI、ベクトルインデックス、別の Worker）への統一的な入口です。エディターが各項目を補完して説明してくれるので、Agent にとってそのまま参照できる一覧になります。

env: {
  API_URL: bindings.text(
    mode === "production" ? "https://example.com" : "https://staging.example.com",
  ),
  API_TOKEN: bindings.secret(),
  CACHE: bindings.kv({ id: mode === "production" ? "production-namespace-id" : "staging-namespace-id" }),
  DATABASE: bindings.d1({ name: `example-${mode}-database` }),
  UPLOADS: bindings.r2({ name: `example-${mode}-uploads` }),
  AI: bindings.ai(),
  // ほかに queue、vectorize、worker など
}

triggers は「何がこの Worker を動かすのか」を1か所にまとめます。Web リクエスト、定期実行、キューのメッセージ、メールの受信。以前は設定ファイルのあちこちに散らばっていましたが、いまは1つのブロックに書けます。

triggers: [
  triggers.fetch({ pattern: "example.com/*" }),
  triggers.scheduled({ schedule: "0 * * * *" }),
  triggers.queue({ name: "jobs", maxBatchSize: 10 }),
  triggers.email({ addresses: ["your-inbox-address"] }),
],

現時点でこの設定が対応しているのは Worker だけです。公式の計画では、これで Cloudflare 全体を管理できるようにします。今後はポリシー、ゾーン（zone）、DNS などが追加され、すべて同じ型付きの設定で書けるようになります。

ローカル開発の既定を Vite に変更

Wrangler が作られた当時、Vite はまだ存在せず、バンドルには esbuild を使い、ローカルの開発サーバー（既定では 8787 番ポート）も自前で作っていました。何かを変えたければ Miniflare（Cloudflare のローカル実行環境）の内部に手を入れる必要がありました。いまは Vite のエコシステムが成熟し、豊富なプラグインと、HMR（ホットモジュールリプレース。コードを変えると画面が自動で更新される仕組み）付きの開発サーバーがあり、バンドルには Rust 製の Rolldown を使ってツリーシェイキング（使われていないコードの除去）を行います。cf は既定で Vite と Cloudflare Vite プラグインの上に構築されており、テスト用の Vitest プラグインと合わせて、本番の Workers ランタイムと一致する開発・テスト環境が得られます。

Cloudflare によると、ほとんどの Worker は Agent の助けを借りればスムーズに移行できます。ただし、すべてのプロジェクトがすぐに移れるわけではありません。esbuild に依存している JavaScript Worker と、Rust や Python で書かれた Worker については、cf は引き続き開発とデプロイを Wrangler に任せます。

Wrangler からの移行

既存の Worker は cf migrate を実行するだけです。すでに Vite でビルドしているものは cloudflare.config.ts に変換され、まだ Wrangler の esbuild に頼っているものは、ビルドを引き続き Wrangler に任せます。新しいプロジェクトは cf init で始めます。cf init と cf deploy が Cloudflare Vite プラグインを入れて設定ファイルを作ってくれます。静的サイトは今までどおり設定ファイルが不要で、プロジェクトで cf deploy を実行すればデプロイできます。

スケジュールについて：オープンベータが終わったら、Cloudflare は Wrangler の最後のメジャーバージョンを公開します。これはあなたと Agent を cf に誘導するもので、その後も Wrangler は18か月間メンテナンスされ、移行の猶予が用意されます。cf 自体はオープンソースで、問題は GitHub の cloudflare/cf リポジトリに報告できます。

なぜ Wrangler にパッチを当てず、新しいツールにしたのか

ここには意外な点があります。Wrangler については長年のドキュメント、ブログ、サードパーティのチュートリアルが大規模モデルに学習されており、Agent はすでによく知っています。Agent が見たことのない新しいツールに替えるほうが、誤りが増えそうに聞こえます。Cloudflare の見方は正反対です。古いツールでこれほど大きな変更をすれば、Agent に学習済みの古い使い方を忘れさせなければならず、たとえば env の意味が変わったことがそうです。まったく新しいツールのほうがむしろクリーンで、設計上の選択、注入できるコンテキスト、追記できる AGENTS.md ファイル（プロジェクト内に置く、Agent 向けの説明書）を通じて、新しい使い方を Agent に直接教えられるというのです。こうした Agent 向けの誘導は、いまのところいくつか実装されているだけで、今後さらに増えるとのことです。なかでも Agent が自分でコマンドを見つける仕組みは、今後より多くのコマンドラインツールで標準になると公式は見ています。

どう捉えるか

この記事が語るのは、Cloudflare にコマンドラインツールが1つ増えたことだけではなく、もっと大きな転換です。ツールの主な利用者が人から Agent に変わると、製品設計の既定値はすべて逆になります。 出力形式は既定で機械向け、コマンドは暗記ではなく検索で探し、設定はエディターで検査できるようにし、古い習慣は互換性を断ってでも捨てます。Agent 向けのツールや API を作っているなら、この4点は自分のものと見比べる価値があります。

注意点が2つあります。冒頭の 48% は、Cloudflare が集計した Wrangler 利用における Agent の割合であり、すべての開発者を代表するものではありません。また cf は現在オープンベータで、新しい設定形式が対応しているのは Worker だけです。DNS やポリシーなど、ほかの製品の設定は計画中です。