cfの紹介：Cloudflare API全体に対応するエージェントCLI
Cloudflareが新CLIツールcfを発表、3000以上のAPI操作に対応し、agentが1つのツールでデプロイ、監視、ドメインとWAF設定を完了可能に。
日本語
コピー
過去1年で、agent による Wrangler の利用が急増した。2026年3月時点で Wrangler 利用の4分の1を agent が占めており、前年の1桁台から大きく伸びた。先週には agent の利用率が48%に達している。agent はより生産性の高いユーザーで、1日に使うコマンドの種類は人間のほぼ2倍、6種類以上を使う割合は4倍近い。agent は CLI を好む。だが Wrangler がコマンドを提供するのは約280の操作に限られ、Cloudflare には数千の操作がある。
今年の初めにこの問題にどう取り組むかを予告した。そして今日、agent が Cloudflare のあらゆる製品を使えるようにする新しい CLI、cf をリリースする。cf は次世代のソフトウェア開発のために作られた CLI だ。
- agent は専用の検索とガイダンスを通じて、あらゆるタスクに必要なコマンドを見つけられる。
- JSON がデフォルトのインターフェースで、人間向けには整形して出力し、agent 向けにはコンテキストを最大限節約するよう圧縮して出力する。
- cloudflare.config.ts は Cloudflare 全体の新しい設定フォーマットで、Workers を皮切りに、TypeScript の安全性と正確さをあなたとあなたの agent の言語サーバープロトコル（LSP）に届ける。
- Vite がデフォルトになり、最高のローカル開発サーバーと、開発者およびフレームワーク作者向けのプラグイン群が付いてくる。
公開ベータ版を今すぐグローバルにインストールして、どこでも実行できる：
npm i -g cf
cf で agent は Cloudflare API 全体にアクセスできる
あなたの agent が Cloudflare にできることすべてを実行できたらどうか。今年の初めに私たちが関心を持ったのは、まさにこの問いだった。agent はどんどん強力になっているのに、Cloudflare の CLI を使ってできることは依然として限られている。
Wrangler は手作業で作られ、各製品チームがそれぞれに貢献し、コマンドの開発者体験もそれぞれの道を歩んできた。チームをまたいで統一パターンを徹底するのはほぼ不可能で、それは約280あるコマンドパスの間でも同じだった。d1 info、hyperdrive get、workflows describe の間で用語が揃っていないのは、各チームがそれぞれのやり方を別々のタイミングで固めてきたからだ。数千行のコードで完全にカスタムな体験を構築したのにほとんど使われていない、というチームもあれば、同じ問題を別の方法で解決しているチームもある。
私たちは2つのことを一度に成し遂げたかった。既存のものを標準化し、同時に大規模に拡張する。Forge——Cloudflare の新しい統合 API 生成パイプライン——がそれを可能にした。API schema から直接 CLI コマンドを生成するという考え方で、この schema は API ドキュメントと SDK 生成の基盤でもある。私たちが提供するあらゆる機能には OpenAPI schema があり、そこに少し注釈を加えるだけで Forge の入力として CLI を生成できる。
これにより cf は、Wrangler が長年かけて積み上げた約280の関数から、Cloudflare の API 面全体を覆う3,000を超える操作へと拡張された。
あとは agent に cf をインストールし、worker の作成、デプロイ、監視と可観測性、Cloudflare Access による保護、ドメインの購入、Cloudflare WAF を前段に置くところまで、すべてを1つのツールでこなせる。
cf を使ったことのない agent のために作る
cf はソフトウェアエンジニアリングの進化の方向に沿って作られており、agentic な開発はソフトウェアの構築とデプロイの仕方を根本から変えつつある。今年私たちはこの変化のためのツールに注力してきたが、cf はその集大成だ。cf は設計の根底から agent を中心に据えており、agentic なコマンド発見のための新しい仕組みも組み込んでいる。こうした仕組みは間もなく、より多くの CLI の標準になるはずだ。
Wrangler には強みがある。長年のドキュメント、ブログ、サードパーティのガイドが LLM の学習過程に取り込まれていることだ。同じくらい明らかな弱みもある。Wrangler の動作を変えることは、モデルがすでに学習した振る舞いに逆らうことを意味する。そして私たちが望む改善幅を考えると、大きな変更は避けられない。
agent が見たことのない新しい CLI を出すことは、大きな破壊的変更のように聞こえる。だが実際にはそれが最もクリーンなやり方だ。私たちが下した設計上の判断、注入できるコンテキスト、追記できる AGENTS.md ファイルのおかげで、この切り替えは、agent が慣れ親しんだツールの2つのバージョン間の大きな違いを理解するよりも、かえって混乱を招きにくい。リリース時点で agent 向けの機能をいくつか組み込んでおり、今後さらに追加していく。
agent が必要とするのは、人間向けの表ではなくフィルタ可能な JSON
agent が Wrangler を使うときは、毎回のコマンドに --json を付け、さらに jq で出力を絞り込んで一部のフィールドだけを取り出すことが多い。だが Wrangler で --json に対応しているコマンドは一部だけで、多くのコマンドはターミナルで人間が見るための unicode テーブルを返す。agent にももちろん読めるが、jq で絞り込むのに比べれば、時間も token も余計にかかる。
cf では立場がまったく逆だ。agent が必要とするのは JSON だけであり、agent が将来このツールの主なユーザーになるのなら、JSON がデフォルト出力であるべきだ。人間がほとんど触らないコマンドが大半を占めるなら、これは明らかに正しい選択だ。
この CLI の人間ユーザーとして、あなたは実際にはもう一段隔てられた場所にいる。agent に結果を楽にフィルタリングさせ、あなたが指定した形式でフィルタ後のリストを返してもらうほうが、おそらく直接見ることのない表を渡されるより良い。
だが、やろうとしていることに本当に人手の入力が必要ならどうする？たとえば、買いたいドメインを検索する場合だ。
agent が名前付き引数をつないで長く扱いにくいコマンドを組み立てることでしかアクセスできない操作なら、あなたはフォームに記入するだけでいい。cf は API の要求を検証付きの入力項目の並びに分解しているので、ドメインの購入も、要件が複雑であっても順を追って記入できる。
あるいは、どうしてもというなら agent にやらせればいい。
agent は自分で正しいコマンドを見つけられる
CLI に 3,000 通りのパスがありうるとして、agent はコンテキストを溢れさせずに必要な操作をすばやく見つけられるのか？そのために我々は cf cli search も追加した。
このコマンドを使うと、agent は自分がやりたいことを自然言語で説明でき、小さな検索インデックスがコマンドの API 記述と引数をもとに適切なコマンドの一覧を返す。agent が最初に --help を実行したとき、我々は自動的にそのコマンドの存在を伝える。
agent に型チェックを効かせられる設定
新しい設定フォーマットは TypeScript をベースにしており、人間にも agent にも解析しやすく、プログラム的に設定を書ける。
型付き設定は agent にとって非常に有用だ。このプログラマティックな設定フォーマットについて事前の文脈がまったくなくても、agent は必要に応じて設定を容易に識別・修正できることがわかった。Wrangler の同名機能と比べて大きく変わった env のような要素であってもだ。Claude Code や Codex など LSP プラグインを使う agent はすべて、設定ファイルのフォーマットに関する情報をコンテキスト内でより多く読み取れるため、はるかに正確な提案ができる。
対照的に、TOML にはアクセス可能な schema がなく、JSONC にはリンクされた schema があるものの、agent はほとんど使わない。
Cloudflare 社内では、5,000 行を超えていた Wrangler の設定ファイルが 40% 圧縮された例もある。以前は開発者ごとに大量のカスタム環境があったが、それが各開発者の設定をより効率的に構築するファクトリファイルになった。
やり方は、共通のベースから出発し、各環境をプログラム的に定義する。Wrangler でよくあるように env ブロックをコピーするのではない。複数の環境を持つシンプルな Worker なら、Vite ネイティブの mode 引数をオンにするだけで、ある設定群と別の設定群を切り替えられる。
そうしたシンプルな設定は今ではこうなる：
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`),
},
},
}));
cf migrate を使えば、Cloudflare Worker をこの新フォーマットに移行できる。
Worker を構築する手間をかなり減らすヘルパー関数もいくつか用意している。
bindings は、開発者プラットフォームが提供するすべてを見つけられる手軽な場所を agent に与える。環境変数からストレージ、データベース、キューまで、すべてがエディタの自動補完と説明の対象になる。
import { bindings, defineConfig } from "cf/config";
export default defineConfig(({ mode }) => ({
worker: {
// ...
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` }),
JOBS: bindings.queue ({
name: `example-${mode}-jobs`,
}),
AI: bindings.ai(),
SEARCH_INDEX: bindings.vectorize({
name: `example-${mode}-search`,
}),
API: bindings.worker({ worker: `example-${mode}-api` }),
},
},
}));
同様に triggers, にもヘルパー関数を用意した。これは Worker のルート、キュー、cron ジョブ、メールトリガーを定義する新しい方法だ。これらはもう設定ファイルのあちこちに散らばらず、単一のブロックで Worker の実行をトリガーしうるすべてのアクションを簡単に見つけられる。
import { defineConfig, triggers } from "cf/config";
export default defineConfig({
worker: {
// ...
triggers: [
triggers.fetch({ pattern: "example.com/*" }),
triggers.scheduled({ schedule: "0 * * * *" }),
triggers.queue({ name: "jobs", maxBatchSize: 10 }),
triggers.email({ addresses: ["support@example.com"] }),
],
},
});
defineConfig.worker はまだ始まりにすぎない。cloudflare.config.ts について我々が描いているのは、Cloudflare 全体を管理する場所になるという姿だ。必要なすべてのプロダクトが、cf を通じて agent に公開される API も含めて、型安全な設定で表現できるようになる。まもなく、この設定ファイルを通じてポリシー一式の設定、zone の作成、DNS の設定などができるようになる。
一級の開発体験
Wrangler が JavaScript Workers を最初に作り始めたころ、Vite はまだ存在していなかった。当時我々は Wrangler 内で esbuild を使って Workers をバンドルしていた。Wrangler が :8787 で提供する dev server は Wrangler チームが自前で書いたもので、どこか一箇所を変えるには Miniflare のような Cloudflare 専用のローカルツールの内部まで踏み込む必要があった。
Vite はこの方式に対する大きな前進だ。利用できるプラグインエコシステムは巨大で、HMR（ホットモジュール置換）を備えた一級の dev server を提供し、ビルド時には Rust ベースの Rolldown で tree-shaking を行う。Vite でできることは、Cloudflare Vite Plugin でもすべてできる。
フロントエンドプロジェクトでもバックエンド API でも、何を構築するにせよ、Workers の構築には Cloudflare Vite Plugin を使うことを勧める。我々の Vitest プラグインと組み合わせれば、Workers ランタイムと一致した一貫性のある開発・テスト環境が手に入り、bindings やプラットフォーム API に直接アクセスできる。
cf はデフォルトで Vite 上に構築されている。ほとんどの Workers は agents で問題なく移行できるが、そうでないものにはもう少し時間がかかる。そのため、esbuild を使い続ける必要がある JavaScript Workers と、Rust および Python の Workers については、cf は引き続き dev とデプロイを Wrangler に委ねる。
Wrangler からの移行
Worker を Wrangler から移行するには、次を実行するだけでいい。
cf migrate
すでに Vite でビルドしている Workers は自動的に cloudflare.config.ts に変換される。Worker が esbuild ビルドのために Wrangler に依存している場合、cf は引き続きビルドを Wrangler に委ねる。
オープンベータが終了したら、Wrangler の最後のメジャーバージョンをリリースし、あなたとあなたの agent を cf へ誘導する。ベータ終了後 18 か月間は Wrangler のメンテナンスサポートを続けるので、移行の時間は確保できる。
cf init/deploy を実行すれば、新しいプロジェクトを作成して Cloudflare の設定を自動で完了できる。Cloudflare Vite Plugin がインストールされ、設定ファイルが生成される。
静的サイトはこれまで通り設定ファイルなしで始められ、デプロイもプロジェクト内で cf deploy を実行するだけだ。
cf で Hello World プロジェクトを新規作成したい場合は、cf init を実行する。
cf はオープンソースだ。問題があれば私たちの GitHub リポジトリで報告してほしい。