Cloudflare Workersをcf CLIで操作する方法

実務上の利点は、コマンドが短くなることではありません。連携部分を自前で作る手間が減ることです。創業者はダッシュボードを探し回らずにアカウントを確認でき、プラットフォームチームはエージェントへ機械可読な結果を渡せます。制作会社も、製品ごとにAPIラッパーを保守せず、顧客アカウントをまたいだCloudflare運用を標準化できます。

cf専用のライセンスを別途購入する必要はありません。リポジトリはオープンソースで、小規模なWorkerならCloudflareのFreeプランから始められます。Workers Paidの月額最低料金は$5です。一方、汎用的なインフラガバナンス基盤であるSpaceliftには、$20,000のStarter+プランがあります。cfは、この価格帯の両端にあるAPI連携の手間を大きく減らします。ただし、承認、監査証跡、慎重な権限設計まで不要になるわけではありません。

新しいcf CLIとは何か

cfは、Cloudflare API全体に対応する自動生成のコマンド群と、Workersの作成、ビルド、移行、デプロイなどに向けて個別に設計されたプロジェクトワークフローを組み合わせたものです。WranglerがWorkers向けの専門工具をそろえた作業台だとすれば、cfはCloudflareという建物全体の案内所とサービス窓口に当たります。そのうえで、Wranglerのほうが確実なWorker作業は、引き続きWranglerへ渡します。

この違いは、今回のリリースとCloudflareが4月13日に公開したテクニカルプレビューとの境界でもあります。4月版が対応していたのは、ごく一部の製品だけでした。9月のオープンベータでは、APIの全面的なカバー、デフォルトのJSON出力、コマンド検索、TypeScriptによるWorker設定、そしてWorkerの標準経路としてのViteが加わっています。

ワークフローを変える要素は、次の4つです。

• API全体をカバー： 3,000を超える操作に対し、自動生成されたコマンドをcf <product> [group…] <operation>の形で実行できます。
• コマンド検索： cf cli searchに自然文で作業内容を入力すると、関連度順に5件のJSON候補が返ります。コマンドツリーを暗記する必要はありません。
• 標準出力はJSON： APIの構造化結果は、整形済みJSONとして標準出力へ送られます。人、スクリプト、コーディングエージェントのいずれも、同じ応答をフィルタリングできます。
• 型付きWorker設定： cloudflare.config.tsにより、エディタやコーディングエージェントがTypeScriptのフィードバックを受けられます。現時点ではWorkersからの対応です。DNS、ゾーン、ポリシーを含むアカウント全体の設定は将来の方向性であり、現在の機能ではありません。

インストール、認証、読み取りテストまで

最初は読み取り専用の操作から始めます。スクリプトによる変更を許可する前に、パッケージ、認証情報、アカウント選択、コマンド検索、JSONの処理経路をまとめて確認できます。

公式パッケージにはNode.js 22以降が必要です。人がターミナルから操作する場合、cf auth loginがデフォルトのOAuthプロファイルを管理します。CIでは、対象を絞ったCLOUDFLARE_API_TOKENを設定します。cfは、保存済みのOAuthプロファイルより先にこの環境変数を確認します。顧客や社内の複数アカウントを扱う場合は、名前付きプロファイルを作り、ディレクトリごとに割り当てられます。

cf cli searchへ渡す文言は一般化してください。入力するのは操作とリソースの種類までとし、ドメイン、メールアドレス、アカウントID、トークンは含めません。

node --version
npm i -g cf
cf --version

cf auth login
cf auth whoami

cf cli search "list zones in an account"
cf zones list | jq -e 'type == "array" and all(.[]; has("name") and has("status"))'

現在、この検索ではcf zones listが最上位に表示されます。最後の行が検証です。読み取り専用のAPI呼び出しを行い、結果がJSON配列で、各要素にnameとstatusが含まれる場合にだけ正常終了します。複数のアカウントがある場合は、--profileで名前付きプロファイルを選ぶか、--account-idでコマンドの対象を絞ります。

トークンをシェル履歴へ貼り付けてはいけません。CIプロセスの環境変数にスコープを限定したトークンを設定し、そのジョブに必要な読み取り権限または書き込み権限だけを与えます。個人がターミナルで使う場合は、cfが選択済みプロファイルを更新できるため、OAuthのほうが扱いやすい標準設定です。

使い捨て環境で確認できたこと

9月29日に新しい隔離環境へインストールしたところ、cf v1.0.0-beta.5が返りました。コマンド検索は有効な5要素のJSON配列を返し、cf initは型付きのWorkerプロジェクトを生成しました。新規プロジェクトと、移行したViteフィクスチャは、どちらもローカルでビルドできました。この環境にはCloudflareのテストアカウント用認証情報がなかったため、認証済みのゾーン読み取りとデプロイは、完了済みテストとして扱っていません。

この境界は重要です。ローカルビルドの成功で確認できるのは、プロジェクトの経路です。トークンに本番環境で必要な権限があることや、デプロイがCloudflareへ到達したことまでは証明できません。

Cloudflare Workersを作成し、cfの生成内容を確認する

新しいプロジェクトの流れを確かめるなら、cf initが最短です。空のディレクトリで実行すると、TypeScriptソース、cloudflare.config.ts、vite.config.ts、パッケージスクリプト、生成済みのWorker型が作成されます。続いてcf buildを実行すると、Cloudflare Vite Pluginへ処理が渡され、標準化されたBuild Outputが生成されます。

cf init hello-cf --package-manager npm
cd hello-cf
npm run build

# In a copied existing Vite Worker:
cf migrate --dry-run
cf migrate
npm run build

どちらの経路でも、処理後にcloudflare.config.tsを開きます。基本的なWorkerであれば、名前、互換性日付、エントリーポイント、型付きバインディングを含むworkerブロックがあるはずです。テキストバインディングは、複数の環境ブロックへコピーするのではなく、設定APIを通じて宣言します。ここでTypeScriptが役立ちます。フィールド名の誤記を、デプロイ失敗より前にエディタの指摘として受け取れるからです。

生成されるVite設定は飾りではありません。cfでは、ローカル開発とビルドの標準経路がViteになりました。Cloudflareも、フロントエンドとバックエンドAPIの両方にViteプラグインを推奨しています。使い捨てプロジェクトでは、npm run buildからViteへ処理が渡され、正常に完了しました。デプロイは意図的に実施していません。レビューとアカウントでのテストが終われば、ドキュメントに記載されたcf deployによって、標準でビルドとアップロードが行われます。

Wranglerを残すべきケース

cfのインストールに成功しても、すぐにWranglerを削除してはいけません。適切な移行方法は、プロジェクトのビルド経路によって変わります。

既存のVite Workerでは、cf migrateを使ってWranglerのJSON、JSONC、TOMLをcloudflare.config.tsへ変換できます。このコマンドは、Wrangler設定のそばにあるCloudflare Viteプラグインを検出し、Vite経路を選択します。プラグインが宣言されていない場合、現在のベータ版では代わりにWranglerバンドラーが選ばれます。作業中のプロジェクトに触れる前に、ドライランのプレビューを実行し、追加対応項目をすべて確認したうえで、コピーまたはクリーンなブランチを移行してください。

Wranglerのesbuild動作に依存するJavaScript Workersでは、cfが開発とデプロイをWranglerへ委譲します。RustとPythonのWorkersも同様です。これは移行の失敗ではなく、互換性を保つための仕組みです。チームはcfを共通の入口にしながら、実績あるビルダーを処理経路に残せます。

Cloudflareのサポート期間も、読み違えやすい点です。Wranglerの保守は、9月28日の公開から18カ月ではなく、オープンベータ終了後の18カ月が予定されています。Rust、Python、esbuildのプロジェクトを、今週中に無理やりViteへ変換する理由はありません。

最初に効果が出る7つのワークフロー

最初の用途として適しているものには、共通点があります。初日から広範な書き込み権限を与えずに、繰り返し発生する調査と整形の作業を減らせることです。

1. 制作会社がアカウント確認を標準化する

制作会社の担当者は、顧客ディレクトリごとに名前付きOAuthプロファイルを割り当て、必要な読み取りコマンドを検索し、同じ形式のJSONをレビュースクリプトへ渡せます。あるエンジニアはダッシュボードを操作し、別のエンジニアは独自のcurlコマンドを保守する、といったばらつきを減らせます。特にDNS、ゾーン、アカウント設定、セキュリティレビューなど、顧客をまたぐ作業の再現性が高まります。

2. プラットフォームチームがコーディングエージェントへ安全なCloudflare操作面を渡す

プラットフォーム責任者は、cf cli searchに関するルールをAGENTS.mdへ記載し、読み取りコマンドを標準で許可しながら、変更操作には人の承認を必須にできます。検索機能によってエージェントが古いWrangler構文を推測する事態を避けられ、JSON出力なら結果をコンパクトに絞り込めます。すでにエージェントへビルド状況、ログ、キュー、アカウントリソースなどの確認を任せており、操作の入口を統一したいチームに特に有効です。

3. オンコール担当者がインシデントの周辺情報を集める

インシデント対応中でも、複数の製品画面を行き来せず、該当するログ、ゾーン、ルールセット、分析データの読み取り方法を検索できます。正確なコマンドと適切な権限は引き続き必要ですが、検索はローカルで完結し、応答はそのままjqへ渡せます。Cloudflare Browser Runのようなジョブを運用するチームなら、失敗したジョブから周辺のアカウント状態まで、より早くたどり着けます。

4. 創業者がツールチェーンを設計せずにWorkerを始める

Webhook、リダイレクトサービス、小規模な社内APIを作る創業者は、cf initを実行し、生成されたWorkerとバインディングを確認したうえで、個々のパッケージを選定せずにViteビルドを利用できます。プロジェクトはWorkers Freeで開始できます。有料プランが必要になった場合、現在の最低料金はアカウント当たり月額$5です。得られるのは、レビュー可能なローカル成果物までの短い経路であり、本番運用が無料になるという約束ではありません。

5. Viteチームがアプリを書き直さずに設定を変換する

ViteベースのWorkerを持つ開発チームは、コピー上でcf migrate --dry-runを実行し、生成されたTypeScriptを確認してから、デプロイ方法を変える前にビルドできます。環境ブロックの重複が増えている場合に特に役立ちます。新しい形式なら共通のベースから設定を計算できますが、移行すべきなのは単なるファイル構文ではなく、動作そのものです。

6. データチームや運用チームがCloudflareの読み取り結果をレポートへ流す

構造化された結果が標準でJSONになるため、担当者はUnicode表をスクレイピングせず、読み取り結果をjq、データウェアハウスのローダー、定期レポートへ渡せます。ビジネス上の利点は、良い意味で地味です。出力アダプターと壊れやすい解析ルールを減らせます。スコープを絞った読み取りトークンを使い、コマンド出力を公開CIログへ残さないでください。

7. Workerチームが本番環境へ触れる前にローカルリソースを確認する

対応コマンドに--localを付けると、ローカル状態を使う短命なMiniflareインスタンスと通信します。KV、D1、R2で定義されている操作も対象です。ローカル版がない場合、cfは黙って本番環境へ切り替えず、エラーを返します。Cloudflare AI Search Workerを開発するチームなら、この境界を使って補助的なローカルデータをテストでき、開発用コマンドがリモート書き込みへ変わるのを防げます。

cfを軸に作る価値がある2つの製品

CLI自体が製品機会なのではありません。非常に広いAPI操作面を扱うために、チームが今後も必要とする制御レイヤーに機会があります。

最有力：制作会社向けCloudflare変更管理

複数のCloudflareアカウントを扱う制作会社や小規模なプラットフォームチーム向けに、対象を絞った承認・証跡レイヤーを作ります。ユーザーがDNS、ゾーン、WAF、Workerの変更を提案すると、製品がcfで現在のJSON状態を取得し、人が読める差分を表示して承認を求め、スコープを限定したプロファイルで実行し、その結果を保存する仕組みです。

需要は大きくないものの、商用性はあります。cloudflare dns managementの米国における検索数は月間約170で、CPCは$6、ページ上部の入札単価は$3.85から$36.64です。汎用的なインフラガバナンスにも、実際の予算が付いています。SpaceliftのStarter+は$20,000です。Cloudflare特化型なら、すべてのクラウドを管理する必要がないため、より低価格で導入しやすい製品にできます。

販売可能な最小構成は、DNSとWorkerの変更を対象にしたGitHub appまたはホスト型レビューキューです。プロファイルの分離、コマンドの許可リスト、変更前後のJSON、基盤APIが対応する場合のワンクリックロールバックを含めます。課題は参入障壁です。cfがすでにコマンド範囲を提供しているため、防御力を持つのはポリシー、証跡、権限、制作会社向けワークフローです。単なるGUIラッパーは、すぐに模倣されます。

有用な機能：Worker移行準備の診断

リポジトリをネイティブVite、Wrangler経由のesbuild、Python、Rustに分類し、安全な移行プレビューを実行して、追加対応項目をプルリクエストのチェックリストへ変換するスキャナーを作ります。顧客は、多数のWorkersを抱えるチームです。小さなプロジェクトを1つ移行する個人開発者ではありません。

これだけで会社を成り立たせるには、需要が小さすぎます。cloudflare worker deploymentの米国における検索数は月間約10ですが、検索意図は取引型です。現実的なMVPは、Cloudflare運用製品の有料機能または移行サービスです。リポジトリのスキャン、cf migrate --dry-run、ビルド検証、明確なWranglerフォールバックレポートをまとめます。課題は、ベータ期間中のリリース変更です。スキャナーがcfとCloudflare Vite Pluginのバージョンへ追随できなければ、その助言は対象プロジェクトより早く古くなります。

制約を踏まえた現実的な判断

コマンド検索、JSON優先のアカウント読み取り、新しいVite Workers、慎重な移行テストには、今からcfを使えます。cfが処理を委譲するプロジェクトではWranglerを残し、本番環境への書き込みには明示的なスコープとレビューを必須にしてください。

オープンベータのcloudflare.config.tsは、まだアカウント全体の信頼できる唯一の設定情報ではありません。対応はWorkersから始まっています。また、Cloudflare APIのすべての操作が、安全な業務フローへ自動的に変わるわけでもありません。API全体をカバーするとトークンが届く範囲も広がるため、最小権限とコマンドレビューは、以前より重要になります。

ローカルオプションにも、意図的な境界があります。対応するKV、D1、R2、Durable Object、Workflowの操作ではローカル状態を利用できますが、ローカルエクスプローラーに相当する機能がない操作はエラーになります。安全性の面では優れた性質ですが、--localがCloudflare全体の汎用オフラインミラーになるわけではありません。

最後に、ベータ版は短期間で変化します。チームで使う場合はcfをプロジェクト依存関係に固定し、生成された設定をレビューしたうえで、CIでもプロジェクト内のバージョンを使ってください。グローバルインストールは探索に便利ですが、共同作業者の動作をそろえるには、バージョンの固定が必要です。

チームに合った安全なCloudflare自動化の設計と構築が必要なら、AI本番システムをご覧ください。