Cloudflare が新 CLI「cf」をオープンベータ公開。wrangler の約280コマンドに対し3,000超のAPI操作を覆う

要約

Cloudflare が2026年9月28日、cf という新しい CLI をオープンベータで公開しました。npm i -g cf で今日から入れられます。

最大の違いは網羅範囲です。 wrangler が約280コマンドだったのに対し、cf は Cloudflare API の3,000を超えるオペレーション全体を覆います。10倍以上です。 これが可能になったのは手作業でコマンドを書いていないからで、OpenAPI スキーマから、同日発表された生成パイプライン Forge（Apache 2.0）で生成しています。

そして、設計の主眼が「エージェント／LLM に使わせること」に置かれています。 公式の見出しがそのまま “the agentic CLI” です。具体的には4点。

1つ目は cf cli search です。 3,000超のオペレーションから、自然言語でコマンドを探せます。 コマンド数が10倍になれば、人間もエージェントも「そもそも何を打てばいいか」が分からなくなります。網羅性を上げた結果として必要になった機能で、--help を延々と辿る代わりに検索する、という発想です。

2つ目は出力です。 JSON が既定のインターフェースで、「人間向けには pretty print、エージェント向けには圧縮」と説明されています。人間向けの整形された表示がまずあって、機械可読な出力はオプション、という従来の順序が逆転しています。

3つ目は cloudflare.config.ts です。 TypeScript の型付き設定で、LSP による補完と型検査が効きます。 設定ファイルの正しさをエディタと型チェッカーが保証する形です。

4つ目は入力フォームです。 複雑な操作について、引数を延々と並べる代わりに、検証付きのフォームで組み立てられます。

wrangler との関係が明確に語られています。 cf は置き換えではなく別ツールとして出されました。理由は「wrangler のレガシーな設計を引き継がずに、きれいに作り直すため」。そしてwrangler には「cf へ誘導する最終メジャーバージョン」が出され、ベータ終了後18か月の保守が約束されています。

つまり wrangler は明日止まるわけではありませんが、終わりが見えました。 移行は cf migrate で既存の wrangler プロジェクトを変換できます。静的サイトは設定不要、新規は cf init / cf deploy。オープンソースで、GitHub で issue を受け付けています。

何が変わったか

• 新 CLI cf がオープンベータで公開。npm i -g cf で導入
• Cloudflare API の3,000超オペレーションを網羅（wrangler は約280コマンド）
• OpenAPI スキーマから、同日発表の生成パイプライン Forge（Apache 2.0）で生成
• cf cli search で自然言語によるコマンド探索
• JSON が既定の出力インターフェース。人間向けは pretty print、エージェント向けは圧縮
• cloudflare.config.ts による型付き設定（LSP 補完・型検査つき）
• 引数の羅列に代わる検証付き入力フォーム
• wrangler は置き換えではなく別ツール。cf へ誘導する最終メジャー版を出し、ベータ終了後18か月の保守
• cf migrate で既存 wrangler プロジェクトを変換。新規は cf init / cf deploy
• 静的サイトは設定不要。オープンソースで GitHub にて issue 受付

業務インパクト（一般企業向け）

まず、期限が示されたことを記録してください。 「ベータ終了後18か月」なので具体的な日付はまだ決まっていませんが、期限の存在が公式に宣言されたという点が重要です。wrangler を前提にした CI パイプライン、デプロイ手順書、新人向けオンボーディング資料——これらは今すぐ壊れませんが、18か月の時計が動き始めています。

現実的な進め方は、新規プロジェクトから cf にすることです。 既存の稼働中パイプラインをオープンベータのツールへ今すぐ移すのは、リスクに対して得るものが釣り合いません。新しく作るものは cf で、既存は cf migrate の検証をしておいて、GA を待って切り替える。 これがいちばん安いはずです。

より大きい変化は、CLI がエージェント前提で設計されたことのほうです。 JSON 既定出力と自然言語検索は、「AI にインフラ操作を任せる」ことを現実的な選択肢にします。 従来は、人間向けに整形された出力をパースし、--help を読ませてコマンドを組み立てさせる必要がありました。その手間が公式側で解消されています。

ただしここは統制の論点でもあります。 3,000超のオペレーションを覆う CLI に、エージェントが自然言語でコマンドを探して実行できる——これは便利であると同時に、「意図しない操作に到達できる範囲」が一気に広がったということです。wrangler の280コマンドなら、できることの範囲は人間が把握できました。3,000は把握できません。

運用に入れるなら、認証情報のスコープを先に絞ってください。 API トークンの権限を最小にする、本番環境の操作は別の認証情報に分ける、エージェントに渡すトークンと人間が使うトークンを分ける。CLI 側が広くなった分、権限側で絞るしかありません。 「どのコマンドを許可するか」でホワイトリストを作る運用は、3,000オペレーションに対しては現実的に維持できません。

情シス・セキュリティ部門への説明としては、「便利な CLI が出た」ではなく「インフラ API の全面が1つのコマンドから叩けるようになった」と伝えるほうが正確です。 監査ログの取得方針も、あわせて確認しておく価値があります。

副業・個人活用視点

Cloudflare を触っているなら、まず cf cli search を試す価値があります。 これまで「この設定、ダッシュボードのどこだったか」「API のこの操作、wrangler にコマンドあったか」で止まっていたものが、自然言語で引けるようになります。個人開発でいちばん時間を溶かすのは、機能の有無を調べる時間です。そこが直接短くなります。

AI コーディングエージェントと組み合わせる用途では、これはかなり効きます。 JSON 既定出力なので、エージェントが結果を読んで次の判断をするのが素直に繋がります。「Workers にデプロイして、DNS を設定して、R2 のバケットを作って」を一気通貫でエージェントに投げる、という作り方が現実的になりました。副業で複数案件のインフラを面倒見ている人にとって、定型作業の自動化の敷居が下がります。

ただし、個人こそ権限の絞り込みを先にやってください。 個人開発では API トークンを「全権限」で1つ作って使い回しがちです。3,000オペレーションを覆う CLI に全権トークンを渡し、そこにエージェントを繋ぐというのは、事故ったときの範囲が読めません。読み取り専用のトークンで試す、本番アカウントと検証アカウントを分けるといった基本を、cf を入れるタイミングで整えておくのが安全です。

受託の観点では、「wrangler で書いた納品物に18か月の期限がついた」という話になります。 今後納品する構成は cf 前提にするか、少なくとも移行が必要になる旨を引き継ぎ資料に書いておくのが誠実です。保守契約を持っているなら、移行作業そのものが次の案件になります。 期限が公式に示されているものは、提案の根拠として使いやすい材料です。

オープンベータである点は正直に伝えてください。 今日から入れられますが、GA ではありません。クライアントの本番環境に入れるかどうかは、案件の性質で分けるべきところです。