Cloudflare新CLI「cf」登場とVite標準化：開発フローを劇的に変える全貌

• Cloudflareが新CLI「cf」を公開。従来のWranglerを凌駕する3,000以上のAPI操作をカバーし、AI Agentとの親和性を高めた。
• 設定ファイルがTypeScriptベースの「cloudflare.config.ts」へ移行し、Viteが標準ビルドツールとして採用された。
• 既存のWranglerは18か月間サポートされるが、今後はcfへの移行が必須。開発者は設定ファイルの書き換えとワークフローの刷新が求められる。

深夜のデプロイ作業中、Wranglerの複雑な設定ファイルや、APIの微妙な挙動に頭を抱えた経験はないだろうか。今回発表された新しいCLI「cf」は、単なるツールのアップデートではない。Cloudflareが提供する約3,000以上のAPIを網羅する、まさに「Cloudflareのすべてを操作する司令塔」として設計されている。従来のWranglerが約280のAPI操作に留まっていたことを考えれば、その進化は劇的だ。特に注目すべきは、AI Agentによる利用を前提とした設計思想である。出力がJSONベースであることはもちろん、cf cli searchコマンドで自然言語から必要な操作を検索できる点は、今後の開発体験を大きく変えるだろう。

設定ファイルがcloudflare.config.tsに統一される点も、我々エンジニアにとっては朗報だ。これまでwrangler.jsoncやwrangler.tomlで環境ごとに苦労して書き分けていた設定が、TypeScriptの型補完を効かせながら記述できるようになる。これは、大規模なプロジェクトにおいて「設定のデッドロック」や「環境変数の不整合」といったヒューマンエラーを劇的に減らすはずだ。ただし、現時点ではWorkers以外のDNSやZone設定がこのconfigファイルに完全対応していない可能性がある点は、実務導入時に注意が必要な「落とし穴」と言える。Wranglerの保守は今後18か月間継続されるため、急激な移行を迫られるわけではないが、cf migrateコマンドによる移行準備は早めに着手すべきだろう。

さらに、このCLIの背後にある「Forge」というコード生成基盤のOSS化も見逃せない。OpenAPI定義からSDKやCLIを自動生成するこの仕組みは、CloudflareのAPIエコシステムをより強固なものにする。各チームのCIでSDKのPreviewを生成し、マージ前に検証できるフローは、我々が自社開発で取り入れるべきベストプラクティスそのものだ。Cloudflareが自らの開発基盤を公開し、コミュニティと共に進化させようとする姿勢には、単なるプラットフォーマーを超えた「開発者体験の民主化」への強い意志を感じざるを得ない。

Next.jsをVite上で動かす「Vinext 1.0」の登場は、正直なところ驚きを隠せない。当初はPoC的なプロジェクトと見ていたが、App RouterとPages Routerの混在対応、さらにはReact Server ComponentsやServer Actionsの互換性まで改善されている。特筆すべきは、Cloudflare Workersにおける「Prerendering」と「Cache Warming」の統合だ。本番トラフィックを流す前にキャッシュを温めるこの仕組みは、大量のページをビルド時に生成して待つという、あの「つらい待ち時間」を解消する強力な武器になる。既存のNext.jsアプリをCloudflareへ移行する際のハードルが、この1.0リリースで一気に下がったと言える。

また、WordPressの精神的後継を謳う「EmDash 1.0」も、CMSのあり方を再定義しようとしている。Blueskyでも採用されているAT ProtocolをベースにしたPlugin Registryは、分散型Webの思想をCMSに持ち込んだ非常に面白い試みだ。特に「Sandboxed Plugin」による権限分離は、セキュリティを重視する企業導入において決定的な要素となる。Dynamic Workersやworkerdによる分離環境は、画像処理プラグインがユーザー情報にアクセスするといった「権限の過剰付与」を物理的に防ぐ。Cloudflare Workers PaidプランとD1が必要という制約はあるものの、セキュアなCMSを構築したいエンジニアにとって、これは無視できない選択肢となるだろう。

さらに、Rust WorkersのEmscripten対応により、既存のRust資産をWorkersに持ち込む道も開かれた。MinecraftサーバーのPumpkinをDurable Object上で動かすというデモは、サーバーレス環境の限界を押し広げる象徴的な事例だ。Durable ObjectのSQLiteをワールド保存先に使うというアーキテクチャは、ステートフルなアプリケーションをサーバーレスで構築する際の新たなパターンとして定着する可能性がある。我々エンジニアは、これらのツールを単に「新しいもの」として消費するのではなく、自らのプロダクトのボトルネックを解消するための「実践的な処方箋」としてどう活用できるかを、今一度問い直す必要があるのではないだろうか。