cf のご紹介：Cloudflare API 全体に対応するエージェント型 CLI

この1年間で、エージェントによる Wrangler の使用が急増しました。

2026年3月には、エージェントによる利用が Wrangler 全体の4分の1を占めました。前年は1桁台でしたが、先週には48%に達しました。

エージェントはコマンドをより積極的に活用しており、1日に使用するコマンドの種類は人間のほぼ2倍、6種類以上のコマンドを使用する割合はほぼ4倍です。

エージェントは CLI を好んで使用します。しかし、Wrangler が提供するコマンドは約280の操作に限られる一方、Cloudflare API には数千もの操作があります。

今年初めに、この問題を解決する計画について一部を紹介しました。本日、新しい CLI「cf」を発表し、エージェントがあらゆる Cloudflare 製品を利用できるようにします。

cf は、次世代のソフトウェア開発に向けて構築された CLI です。

• エージェントは、専用の検索・誘導機能を使って、必要な操作を実行するコマンドを見つけられます。
• デフォルトのインターフェースは JSON です。人間向けには読みやすく整形され、エージェント向けにはコンテキスト消費を最大限抑えられるよう圧縮されます。
• cloudflare.config.ts は、Cloudflare 全体に対応する新しい設定形式です。まず Workers に対応し、TypeScript の安全性と正確性を、利用者やエージェントが使用する言語サーバープロトコル（LSP）にもたらします。
• Vite がデフォルトになり、最高水準のローカル開発サーバーと、開発者やフレームワーク開発者向けのプラグインスイートを利用できます。

オープンベータ版は世界中で利用できます。今すぐインストールして、どこからでも実行できます。

npm i -g cf

cf があればエージェントが Cloudflare API 全体にアクセスできる

エージェントが Cloudflare で可能なあらゆる操作を実行できるとしたらどうでしょうか。私たちが今年初めに関心を持ったきっかけは、この問いでした。エージェントはますます強力になる一方で、Cloudflare の CLI で実行できる操作は依然として限られていました。

Wrangler は手作業で構築され、各プロダクトチームが独自の方針でコマンドの開発者体験を設計していました。約280のコマンドパスに対してさえ、チーム間で共通のパターンを徹底することはほぼ不可能でした。各チームがそれぞれ異なる時期に独自の慣行を採用したため、d1 info、hyperdrive get、workflows describe などで用語が統一されていませんでした。数千行ものコードを費やして独自の操作体系を構築したものの、実際にはほとんど利用されなかったケースもあり、同じ問題に対してチームごとに異なる解決方法が採用されていました。

既存機能の標準化と大幅な拡張を同時に実現したいと考えていました。これを可能にしたのが、Cloudflare の新しい統合 API 生成パイプラインである Forge です。Forge は、API ドキュメントや SDK の生成に使用している API スキーマから、CLI コマンドを直接生成するという発想に基づいています。Cloudflare が提供するすべての機能には OpenAPI スキーマがあるため、そこにわずかな情報を注釈として追加すれば、Forge が CLI を生成するためのソースとして利用できます。

これにより、Wrangler が長年かけて実装してきた約280の機能から、3,000を超える操作を含む Cloudflare API 全体へと、cf の対応範囲を拡大できます。

これからは、エージェントが cf を利用できるようにするだけで、Worker の設定とデプロイ、監視と可観測性の確保、Cloudflare Access による保護、ドメインの購入、Cloudflare WAF の前段への配置まで、すべて単一のツールで簡単に依頼できます。

cf を使ったことのないエージェントを想定した設計

cf は、エージェント主導の開発によってソフトウェアの構築・デプロイ方法が大きく変わりつつあるという、ソフトウェアエンジニアリングの方向性を見据えて開発されています。今年はこの変化を支えるツールの提供に注力してきましたが、その集大成が cf です。cf は当初からエージェントの利用を想定して設計されており、エージェントがコマンドを見つけるための新しい機能も備えています。こうした機能は、近い将来、多くの CLI で標準になると考えています。

Wrangler には、長年にわたるドキュメント、ブログ、サードパーティ製ガイドの内容が LLM の学習に取り込まれているという利点があります。しかし、これは同時に欠点でもあります。今から Wrangler の動作を変えると、エージェントが学習済みの使い方と食い違うことになります。一方、目指す改善の規模を考えれば、大幅な変更は避けられません。

エージェントが一度も使ったことのない新しい CLI の導入は、大きな破壊的変更のように思えるかもしれません。しかし実際には、これが最も明快な方法です。今回採用した設計、エージェントに提供できるコンテキスト、追加できる AGENTS.md ファイルにより、使い慣れたツールの2つのバージョン間にある大きな違いをエージェントに理解させるよりも、この方法で切り替える方が混乱を抑えられます。提供開始時点ですでにエージェント向け機能をいくつか組み込んでおり、今後さらに追加する予定です。

エージェントにはテーブルではなく JSON のフィルタリングが必要

エージェントが Wrangler を使用する場合、実行するすべてのコマンドに --json を追加し、jq を使って出力を絞り込み、必要なフィールドだけを抽出することがよくあります。しかし、Wrangler で --json をサポートしているのは一部のコマンドだけであり、多くのコマンドは、ターミナル上で人間が確認するための Unicode 形式の表を返します。エージェントでも解析できますが、jq で絞り込む場合より多くの時間とトークンが必要です。

cf では反対の方針を採用しています。エージェントに必要なのは JSON であり、将来的にエージェントがこのツールの主な利用者になるのであれば、JSON をデフォルトにすべきです。大多数のコマンドは人間が直接使用する機会がほとんどないため、これは明らかに適切な判断です。

この CLI を利用する人間は、実際には CLI を直接操作する立場から一歩離れています。エージェントが結果を簡単に絞り込み、利用者が指定した形式で返せる方が、おそらく直接読むことのない表を提供するよりも望ましいのです。

しかし、購入するドメインを検索するなど、実際に人による入力が必要な操作の場合はどうでしょうか。

長く煩雑な名前付きパラメータを連ねなければならないコマンドでも、フォームに入力するだけで操作できます。cf は API の要件を検証可能な一連の入力項目に分解するため、複雑な条件のあるドメインでも、手順に沿って簡単に購入できます。

あるいは、必要であればエージェントに任せることもできます。

エージェントが正しいコマンドを自分で見つけられる

3,000もの操作がある CLI から、コンテキストを肥大化させずに必要な操作をすばやく見つけるにはどうすればよいでしょうか。そのために、cf cli search も追加しました。

このコマンドを使うと、エージェントは実行したい操作を自然言語で指定できます。小規模な検索インデックスが API の説明とパラメータに基づいて、適切なコマンドの一覧を返します。エージェントが初めて --help を実行したときには、このコマンドの存在が自動的に通知されます。

エージェントの設定編集を型チェックで支援

新しい設定フォーマットは TypeScript をベースにしており、人間とエージェントの両方が解析しやすく、プログラムで設定を記述することができます。

型付き設定はエージェントにとって非常に有用です。プログラムで記述する設定形式について事前知識がなくても、エージェントは必要に応じて設定を簡単に見つけて編集できます。Wrangler に同名の機能がありながら大幅に仕様が変わった env のような要素でも同様です。Claude Code や Codex など、LSP プラグインを利用するエージェントは、設定ファイルの形式をコンテキストからより深く理解できるため、より正確な提案を行えます。

一方、TOML には参照可能なスキーマがなく、JSONC にはスキーマが関連付けられていたものの、エージェントが利用することはほとんどありませんでした。

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`),
      },
    },
}));

Cloudflare Workerをこの新しいフォーマットに移行するには、cf migrateを使用してください。

Workerを構築する際に便利なヘルパー機能もいくつか提供しています。

bindingsを使用すれば、開発者プラットフォームで提供されるすべての機能をエージェントが簡単に確認できます。環境変数からストレージ、データベース、キューに至るまで、すべてにおいてエディタが自動補完や説明を行えます。

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 < { userId: string } > ({
        name: `example-${mode}-jobs`,
      }),
      AI: bindings.ai(),
      SEARCH_INDEX: bindings.vectorize({
        name: `example-${mode}-search`,
      }),
      API: bindings.worker({ worker: `example-${mode}-api` }),
    },
  },
}));

同様に、triggers用のヘルパーを追加しました。これは、Workerのルート、キュー、スケジュール、メールトリガーを定義する新しい方法です。これらが設定ファイルに散らばっているのではなく、Workerの実行をトリガーする可能性のあるアクションを、1つのブロックで簡単に見つけることができるようになりました。

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全体をこのように管理する方法として機能することです。必要なすべての製品（およびそのAPIがcfを通じてエージェントに提供される場合）は、型安全な設定を通じて表現できるようになります。まもなく、この設定ファイルを通じて、ポリシー全体の設定、ゾーンのセットアップ、DNSの構成など、あらゆる設定が可能になります。

最高水準の開発体験

Wrangler が JavaScript Workers の構築を始めた当時、Vite はまだ存在していませんでした。そのため、Wrangler では esbuild を使って Workers をバンドルしていました。Wrangler が :8787 で提供する開発サーバーも Wrangler チームが独自に構築したもので、変更するには Miniflare など、Cloudflare 固有のローカルツールの内部実装に手を加える必要がありました。

Vite はこの環境を大幅に改善します。豊富なプラグインエコシステムに加え、HMR（ホットモジュール置換）を備えた最高水準の開発サーバーや、Rust ベースのライブラリ Rolldown によるツリーシェイキング対応のビルド機能を利用できます。Vite でできることは、Cloudflare Vite Plugin でも実現できます。

Cloudflare Vite Plugin は、フロントエンド中心のプロジェクトでもバックエンド API でも、Workers を構築する際に推奨する方法です。Vitest プラグインと組み合わせることで、Workers ランタイムに適合した一貫性のある開発・テスト環境を構築でき、バインディングやプラットフォーム API に直接アクセスできます。

cf は Vite をデフォルトで使用します。ほとんどの Workers は、エージェントを使えば簡単に移行できますが、移行に時間がかかるものもあります。そのため、esbuild を引き続き使用する必要がある JavaScript Workers、および Rust や Python の Workers については、cf から Wrangler に開発とデプロイを引き続き委ねます。

Wrangler からの移行

Wrangler から Worker を移行するには、cf migrate を実行するだけです。

cf migrate

すでに Vite でビルドしている Workers は、自動的に cloudflare.config.ts へ変換されます。Worker が esbuild によるビルドを Wrangler に依存している場合は、cf から引き続き Wrangler にビルドを委ねます。

オープンベータの終了時には、利用者とエージェントを cf へ誘導する Wrangler の最終メジャーバージョンをリリースします。移行期間を確保するため、ベータ終了後も18か月間は Wrangler のメンテナンスサポートを継続します。

また、cf init/deploy を実行することで新しいプロジェクトを自動的に Cloudflare 向けに設定することもできます。Cloudflare Vite Plugin のインストールと設定ファイルの作成が自動で行われます。

静的サイトは引き続き設定ファイルなしで開始でき、プロジェクト内で cf deploy を実行するだけでデプロイできます。

cf で新しい Hello World プロジェクトを始めるには、cf init を使用してください。

cfはオープンソースであり、問題をGitHubリポジトリに報告することができます。