FIELD GUIDE / CLOUDFLARE

DISCOVER → VERIFY → RUN

Cloudflare cf
CLI ハンズオンガイド

コマンドを探し、要求を読み、確かめて実行する。API操作からWorkers開発まで、一本の手順で身につける。

公開ベータ cf 1.0.0-beta.5

2026.09.29 検証 / 12章 / 7図解 / 目安70分

準備から始める →

全体像:cfで何が変わるか

cfは、Cloudflareの公開API操作とWorkersの開発・配備を一つの入口にまとめたCLIです。コマンドを暗記するより、目的を検索し、ヘルプとスキーマで確かめ、対象を選んで実行する流れを身につけます。

CLIはターミナルから文字で操作する道具、APIはサービスをプログラムから操作する窓口です。cfの生成コマンドはAPI仕様を元に作られます。WorkersはCloudflare上でコードを実行するサービス、KVはキーと値を保存するストレージです。

目的を言葉にする人間 / AIエージェントcfで発見・確認search → help → schemaCloudflareを操作API / Workersの配備
図1 API操作とWorkers開発を、cfから使い分ける
入口役割このガイドでの扱い
cf <product> …DNS・KV・D1などのAPI操作。製品→グループ→操作の順。KVを使って作成・読み書き・削除を練習
cf init / dev / build / deployプロジェクト作成、ローカル開発、ビルド、配備。新規Workerを型検査してビルド
cf cli search / cf schema操作を探し、API要求の構造を調べる。認証なしで始める基礎演習
Wrangler既存のWorkers開発CLI。cfから委譲される経路もある。既存アプリは移行前にビルド経路を確認

一次資料:公式発表(2026-09-28) ↗CLI公式README ↗配布パッケージの定義 ↗

演習の準備とインストール

必須はNode.js 22以上とnpmです。JSONの絞り込み演習にはjqを使います。macOS / Linux / WindowsのWSLで、bashまたはzshから実行する例です。Windows PowerShellでは環境変数や引用符の書式を読み替えてください。

所要時間の目安は基礎20分、KV20分、Workers30分です。CLIの取得と依存のインストールにはインターネットが必要です。検索・スキーマ・dry-runはログインなしで試せます。実クラウド演習にはCloudflareアカウントと対象操作の権限が必要です。

端末 · bash / zsh
node --version
npm --version
jq --version

# このガイドと同じ版を入れる
npm install -g cf@1.0.0-beta.5
cf --version

# 検証用の作業場所
mkdir cf-hands-on
cd cf-hands-on

# このシェルではcf自身のテレメトリを無効にする
export CF_SEND_TELEMETRY=false
演習ログイン実リソースへの影響
検索・schema・API dry-run不要なし。要求の構造を調べる
KVのローカル操作不要端末内の専用状態だけ
KVのリモート操作必要専用namespaceを作成・削除
Workers init / dev / build原則不要ファイルとローカル実行環境を作成
Workers deploy必要公開URLと実Workerを作成・更新
到達チェック
cf --version に 1.0.0-beta.5 が含まれること。node --version は22以上。

一次資料:配布パッケージの定義 ↗CLI公式README ↗cfテレメトリ方針 ↗

探す → ヘルプ → スキーマ → dry-run

cf cli search は、コマンド・説明・引数を検索して最大5件の候補を返します。AIに処理を丸投げする命令ではありません。検索しただけではDNSやKVは変更されません。英語の操作語とリソース名で探すと、元のAPI説明に合いやすくなります。

端末 · bash / zsh
cf cli search "list DNS records"
cf dns records list --help
cf schema dns records list

cf cli search "create KV namespace"
cf kv namespaces create --help
cf schema kv namespaces create
cf kv namespaces create --title cf-guide-lab --dry-run
search:候補何を使うかhelp / schema:仕様引数 / メソッド / 必須項目dry-run:要求送信内容を組み立てる
図2 検索結果を、実行前の確認へつなぐ
実測例 · 未認証のdry-run(JSON)
{
  "command": "cf kv namespaces create",
  "method": "POST",
  "url": "https://api.cloudflare.com/client/v4/accounts/<account-id>/storage/kv/namespaces",
  "pathParams": {},
  "bodyKind": "json",
  "body": { "title": "cf-guide-lab" }
}

操作の入口を切り替える

これはコマンドの説明表示です。ブラウザからCLIやAPIを実行しません。

到達チェック
検索結果に cf dns records list があり、KVのschemaで title が必須、dry-runで POST が表示されること。

一次資料:検索の実装 ↗KVコマンドの公式ソース ↗DNS一覧の公式ソース ↗

認証と操作対象を取り違えない

認証は「誰の権限で実行するか」、アカウントとゾーンは「どこを操作するか」です。アカウントはリソースを管理する単位、ゾーンはCloudflareに登録したドメインの単位です。ログインできたことと、目的の対象を操作できることは別です。

環境変数のトークンCLOUDFLARE_API_TOKEN選択したOAuthフラグ → フォルダ指定defaultプロファイル明示指定がないとき
図3 認証情報の優先順位。上位があれば下位を使わない
端末 · bash / zsh
cf auth login
cf auth list

# 環境変数は各自の対象IDへ置き換える
export CLOUDFLARE_ACCOUNT_ID="自分のアカウントID"
export CLOUDFLARE_ZONE_ID="自分のゾーンID"

cf auth login はdefaultプロファイルを認証します。beta.5ではデバイス認証が既定です。ブラウザの画面で対象アカウント・要求権限を確認して認証を完了します。ブラウザを自動起動しない場合はcf auth login --no-browserを使い、表示された案内に従います。

端末 · bash / zsh
# 複数のログインを使い分けたい場合
cf auth create lab
cf auth activate lab
cf auth list

# このコマンドだけlabを選ぶ
cf kv namespaces list --profile lab

# フォルダへの関連付けを外す
cf auth deactivate
対象優先順位 / 指定方法間違えやすい点
認証APIトークン環境変数 → --profile → 最も近いディレクトリへの紐付け → defaultトークンが設定されていると --profile より優先。プロファイル管理自体も制限される
Account IDCLOUDFLARE_ACCOUNT_ID → 設定ファイル → 保存済みaccount → 対話選択等--account-id は全コマンド共通のフラグではない
Zone--zone / -z → CLOUDFLARE_ZONE_IDゾーンIDまたはドメイン名。名前解決には追加の権限が必要になる場合がある
到達チェック
選択中のプロファイルと、対象Account ID / Zone IDを自分で説明できること。

一次資料:CLI公式README ↗認証・プロファイル ↗アカウント・ゾーンの解決順 ↗APIトークンの権限 ↗

読み取りとJSON:最初の実API

ここから実Cloudflareへの読み取りを行います。DNSを登録済みの場合はDNS一覧、ドメインがない場合はKV namespace一覧を使います。--dry-runを外すと実APIへ送信されます。

端末 · bash / zsh
# DNS:指定ゾーンにあるAレコードを1ページ取得
cf dns records list --zone "$CLOUDFLARE_ZONE_ID"   --type A --page 1 --per-page 5 > dns-records.json

# JSONの配列から必要な列だけを抜き出す
jq '.[] | {id, name, type, content}' dns-records.json

# ドメインがない場合はこちら
cf kv namespaces list --page 1 --per-page 20 > namespaces.json
jq '.[] | {id, title}' namespaces.json

beta.5の構造化結果は標準出力へJSONで出ます。多くの一覧は配列に正規化されるため、例では.result[]ではなく.[]を使っています。最初はファイルの形を確認してからフィルターを書いてください。

cf の結果構造化APIはJSONJSONファイル / jq配列なら .[] を選ぶ必要な情報表 / 監査メモ / スクリプト
図4 標準出力をデータとして次の処理へ渡す

ページングで見落とさない

この例は1ページだけです。--page / --per-pageがある操作と、--cursorを使う操作を区別します。beta.5の出力処理では一覧のresult_infoが除かれる場合があるため、「一覧を保存した=全件を保存した」と扱わないでください。全件収集が目的なら、対象コマンドの出力とAPIのページング情報を検証し、必要に応じて公式SDK/APIを使います。

到達チェック
JSONをファイルへ保存でき、配列から必要な列を抽出できること。空配列は必ずしもエラーではありません。対象と権限も確認します。

一次資料:DNS一覧の公式ソース ↗KVコマンドの公式ソース ↗JSON出力の実装 ↗CLI公式README ↗

認証不要:ローカルKVを操作する

まずMiniflareというローカル実行環境で、キーgreetingの保存・読み取りを試します。--localと同じ--persist-toを毎回付けます。クラウドにnamespaceを作成する操作は不要です。以下のcf-guide-labはローカル状態を識別する演習用の名前です。

端末 · bash / zsh
cf kv keys put greeting --namespace-id cf-guide-lab   --body "Hello cf" --local --persist-to ./cf-state

cf kv keys get greeting --namespace-id cf-guide-lab   --text --local --persist-to ./cf-state

cf kv keys list --namespace-id cf-guide-lab   --local --persist-to ./cf-state

cf kv keys delete greeting --namespace-id cf-guide-lab   --local --persist-to ./cf-state --force
cf … --local認証を使わないMiniflareローカルAPI相当の処理./cf-state今回の演習データ
図5 --localは端末内の状態へ向かう

--localが表示されても全操作がローカル対応とは限りません。READMEはKVのキー操作、D1のraw・migration、R2オブジェクト操作などの範囲を示しています。未対応はエラーになり、本番へ自動的に切り替える動作ではありません。--persist-toは--localと組み合わせるオプションです。

到達チェック
getが Hello cf を返し、listに greeting があること。削除後はlistから消えること。

一次資料:CLI公式README ↗ローカル実行の実装 ↗KVコマンドの公式ソース ↗

実践:専用KVの作成から片付けまで

この演習は実クラウドに書き込みます。既存アプリが使うnamespaceを指定せず、専用のcf-guide-labを作ります。契約・利用量に応じた料金や上限があるため、アカウントのプランを確認して実施してください。本ガイド制作時は以下の実リソース作成・削除を行っていません。

1. 送信内容を確認して作成する

端末 · bash / zsh
cf kv namespaces create --title cf-guide-lab --dry-run

# Account IDとtitleを確認した後に実行
cf kv namespaces create --title cf-guide-lab > kv-created.json
cat kv-created.json

# 作成結果のIDを使う(.idがあることを先に確認)
export CF_LAB_KV_ID="$(jq -er '.id' kv-created.json)"
: "${CF_LAB_KV_ID:?KVの作成結果を確認してください}"

作成済みの同名namespaceがある場合、createはエラーになることがあります。失敗を回避するために既存namespaceを削除せず、一覧で確認して演習名を変更してください。通信が途切れた場合も、再作成の前に一覧で結果を照合します。

2. 保存 → 読み取り → 更新

端末 · bash / zsh
cf kv keys put greeting --namespace-id "$CF_LAB_KV_ID"   --body "Hello cf" --dry-run
cf kv keys put greeting --namespace-id "$CF_LAB_KV_ID"   --body "Hello cf"
cf kv keys get greeting --namespace-id "$CF_LAB_KV_ID" --text

# 同じキーへのputは値を置き換える
cf kv keys put greeting --namespace-id "$CF_LAB_KV_ID"   --body "Hello again"
cf kv keys list --namespace-id "$CF_LAB_KV_ID" --prefix greeting

3. 演習で作ったnamespaceだけを削除する

端末 · bash / zsh
# kv-created.jsonのtitleとidが今回の演習のものか照合
jq '{id, title}' kv-created.json
cf kv namespaces delete "$CF_LAB_KV_ID" --dry-run

# namespace内の全キーも消える。ID確認後、対話確認して実行
cf kv namespaces delete "$CF_LAB_KV_ID"

# 削除後の一覧も確認(複数ページの場合は続きも見る)
cf kv namespaces list --page 1 --per-page 100
unset CF_LAB_KV_ID
到達チェック
専用namespaceで保存・更新を確認し、最後にそのIDが削除されたことを確認できること。削除コマンドの --force は確認を省略するため、通常の手動演習では付けません。

一次資料:KVコマンドの公式ソース ↗Workers KVの仕様 ↗APIトークンの権限 ↗

Workers:新規作成・起動・型検査

次はAPIの直接操作から、Workerの開発へ進みます。新しい空のディレクトリを指定してください。cf initは既存ファイルがある場所では自動構成を行うため、空ディレクトリのひな形生成と動作が異なります。

端末 · bash / zsh
# cf-hands-onディレクトリで実行
cf init cf-worker-lab --package-manager npm
cd cf-worker-lab

# 以後はプロジェクト内のcfを使う
npm run dev

端末に表示されたLocal URLをブラウザで開きます。通常のポート番号を固定で決めつけず、起動ログを使ってください。ひな形ならHello World!が表示されます。コードを編集して保存し、ブラウザの応答が変わることを確認します。開発サーバーはCtrl + Cで止めます。

生成ファイル意味
src/index.tsHTTPリクエストに応答するWorker
cloudflare.config.tsWorker名・互換日・bindingsなど
vite.config.tsViteにCloudflare pluginを登録
.cloudflare/types/index.d.ts設定に対応したWorkerの型
package.json / lockfile実行スクリプトと依存。再現性のためlockfileを保存
端末 · bash / zsh
npm run typecheck
npm run build
npx cf deploy --dry-run
src + configアプリとbindingsを定義Vite / 型生成dev / typecheck / buildBuild Output.cloudflare/output/…
図6 コードと設定から配備用Build Outputを作る
到達チェック
Hello Worldを表示し、編集が反映され、型検査とビルドが終了コード0になること。dry-runではアップロードしません。

一次資料:initの公式実装 ↗CLI公式README ↗Cloudflare Vite plugin ↗deployの公式実装 ↗

TypeScript設定:bindings・mode・triggers

cloudflare.config.tsはTypeScriptで書く設定です。worker.envはWorkerへ渡すbindingsの対応表です。bindingは、文字列・秘密情報・KV・D1などをWorker内の名前へ結びつけます。Wranglerのenv環境ブロックをそのまま移すものではありません。

cloudflare.config.ts · ひな形を置き換える
import { bindings, defineConfig } from "cf/config";
import * as entrypoint from "./src/index.ts" with { type: "cf-worker" };

export default defineConfig(({ mode }) => ({
  worker: {
    name: mode === "production" ? "cf-worker-lab" : "cf-worker-lab-dev",
    compatibilityDate: "2026-09-25",
    entrypoint,
    env: {
      WORLD: bindings.text(mode === "production" ? "Production" : "Local"),
    },
  },
}));
src/index.ts
import { env } from "cloudflare:workers";

export default {
  fetch() {
    return new Response(`Hello ${env.WORLD}!`);
  },
} satisfies ExportedHandler;
端末 · bash / zsh
npm run typecheck
npx cf dev --mode development
# 開発サーバーを止めてから
npx cf build --mode production
npx cf deploy --mode production --dry-run
--mode production設定評価の入力defineConfig({ mode })名前・bindingを選択worker.env.WORLDWorkerから env.WORLD
図7 modeによって設定を評価し、envにbindingを渡す

modeで値を変えただけでリソースが隔離されるわけではありません。Worker名、KVのID、D1・R2などの参照先も環境別に分けます。compatibilityDateは互換性を選ぶ日付です。日付を更新する場合は挙動を確認します。

bindingsとtriggersを拡張する

以下は構造を学ぶための部分例です。実リソースの設定・権限・対応ハンドラーを用意してから組み込みます。bindings.secret()は秘密値を設定ファイルに書くためのものではありません。

設定の部分例 · このまま実行しない
// worker.envに追加する例
API_TOKEN: bindings.secret(),
CACHE: bindings.kv({ id: "環境別のKV namespace ID" }),
DATABASE: bindings.d1({ name: "cf-lab-db" }),
UPLOADS: bindings.r2({ name: "cf-lab-uploads" }),
トリガーの部分例 · ルート / Cron / Queue
// import { defineConfig, triggers } from "cf/config";
// worker.triggersに置く部分例
triggers: [
  triggers.fetch({ pattern: "example.com/*" }),
  triggers.scheduled({ schedule: "0 * * * *" }),
  triggers.queue({ name: "jobs", maxBatchSize: 10 }),
],
到達チェック
developmentとproductionで応答用の文字列とWorker名が切り替わる理由を説明できること。

一次資料:公式発表(2026-09-28) ↗CLI公式README ↗Cloudflare Vite plugin ↗

配備・バージョン・既存Wranglerからの移行

cf deployは既定でビルドしてからアップロードします。このステップは実際にWorkerを作成・更新し、公開URLを持つ場合があります。演習用のWorker名、対象アカウント、配備するmodeを確認して進めてください。

端末 · bash / zsh
# 同じmodeで内容を確認
npx cf deploy --mode production --dry-run

# 実際の配備(ユーザーが実施する演習)
npx cf deploy --mode production

# 出力されたURLをブラウザ、またはcurlで確認
curl -i "https://配備ログに表示されたURL/"

成功メッセージだけで終えず、応答コードとHello Production!の本文を確認します。片付けるときはCloudflare Dashboardで今回作ったWorker名を確認して削除します。CLIで削除する場合はcf cli search "delete Worker"から現在のコマンドと対象を確認し、共有Workerを選ばないでください。

コマンド意味注意点
cf build標準化されたBuild Outputを作るこれだけでは公開されない
cf deployビルドして配備する実クラウドへの変更
cf workers versions createバージョンをアップロードするアップロードだけで即配備とは限らない
cf workers triggers deploy構成されたルート・Cronを適用トリガー側の変更も確認する
--prebuilt既存Build Outputを再利用出力を作ったmodeと内容を照合。新しいmode指定だけで成果物が作り直されるわけではない

既存プロジェクトの移行

端末 · bash / zsh
# 既存プロジェクトの作業ツリーがきれいな状態で開始
 git status --short
 git switch -c migrate-cf
 cf migrate
 git diff --stat
 git diff

# 実際に用意されているプロジェクトのスクリプトで確認
 npm run build

移行後は生成・変更された設定、依存、スクリプト、environment、bindings、routesを比較します。既存の型検査とテスト、ローカル応答も確認してから配備します。ViteベースのWorkerでは新しい設定への変換が行われ、esbuildが必要なJavaScript WorkerやRust / Python WorkerではWranglerへの委譲が残る経路があります。

一次資料:CLI公式README ↗deployの公式実装 ↗移行コマンド ↗公式発表(2026-09-28) ↗

自動化とトラブルシューティング

スクリプトでは対象と失敗条件を明示する

CIの秘密変数へトークン、通常変数へアカウントIDを設定し、リポジトリ内のcfとlockfileを固定します。以下はKV一覧を読み取って保存する例です。set -euo pipefailはbashのエラー検出を厳格にします。

CI用bash · 読み取りのみ / 1ページ分
#!/usr/bin/env bash
set -euo pipefail
: "${CLOUDFLARE_API_TOKEN:?CIの秘密変数を設定してください}"
: "${CLOUDFLARE_ACCOUNT_ID:?対象アカウントIDを設定してください}"
export CF_SEND_TELEMETRY=false
export CF_QUIET=1
npm ci
npx --no-install cf kv namespaces list --page 1 --per-page 100 > namespaces.json
jq -e 'type == "array"' namespaces.json >/dev/null
jq '[.[] | {id, title}]' namespaces.json > namespace-summary.json

CF_QUIET=1は進捗表示を抑えるために使います。JSONが必要な処理では出力の有無を確かめずに--quietを付けないでください。ログにenv全体やset -xでトークンを出さないようにします。

AIエージェントへ渡す指示の例

依頼文の例
cfを使い、指定した検証アカウントのKV namespace一覧だけを取得する。
最初に cf cli search で操作を探し、help / schemaで引数を確認する。
検索には個人名、ドメイン、ID、トークンを含めない。
新規作成・更新・削除・配備は実行しない。
出力形式とページング範囲を確認してから結果を要約する。
症状確認すること次の操作
コマンドが見つからないcfの実体とバージョン、コマンド名の変更command -v cf、cf --version、cf cli search
認証に失敗 / 401・403トークン優先、期限、権限、対象リソースプロファイルと対象IDを照合。秘密値は表示しない
wrong account / 対象がないAccount IDとZone IDの混同、modeの設定環境変数と設定の優先順位を見直す
jqで失敗JSON配列か、生テキストか、空出力か元ファイルと終了コードを確認。.[]等を修正
localでエラー対応操作か、状態ディレクトリが同じか--localを外して再試行しない。外すと本番操作になる
localが結果出力後に終了しない検証環境のput・listの一部で発生出力と状態を確認しCtrl+C。1コマンドずつ試す
createで同名エラー前回の成功・通信中断・同名リソース一覧で照合して演習名を変える。既存を消さない
ビルド時にDocker警告Containerを使っているか、最終終了コード本検証の通常Workerは警告後もbuild成功。Container利用時は別途Dockerを確認
429 / 5xxAPI制限や一時障害間隔を空け、変更操作は結果照合後に再試行

テレメトリの確認

端末 · bash / zsh
cf cli telemetry status
cf cli telemetry disable
# コマンド単位で止めたい場合
CF_SEND_TELEMETRY=false cf cli search "list KV namespaces"

一次資料:cfテレメトリ方針 ↗JSON出力の実装 ↗CLI公式README ↗アカウント・ゾーンの解決順 ↗

到達チェックと公式資料

知識を読んだだけで終わらせず、手順を見ずに次の項目を説明・実行できるか確認します。チェック状態はこのブラウザ内に保存されます。

検証の範囲

調査日:2026年9月29日。検証対象:cf 1.0.0-beta.5 / Node.js 25.9.0 / macOS。公式の検索、ヘルプ、schema、API dry-run、ローカルKVの応答、init、Workerの型検査・ビルド・ローカルHTTP応答を確認しました。ローカルKVの終了待ちは既知の検証結果として本文に記載しています。

認証操作、実アカウントのDNS・KVの読み書き、サンプルWorkerの本番配備・削除、既存プロジェクトの移行は利用者が行う演習です。本書の公開作業とは別であり、それらの成功を実測済みとは扱いません。

一次資料への入口

資料用途
公式発表(2026-09-28) ↗発表の背景・設定構想・移行方針
CLI公式README ↗導入・認証・プロジェクト・local・出力
配布パッケージの定義 ↗対応Node.jsと配布版
検索の実装 ↗コマンド検索の仕様
アカウント・ゾーンの解決順 ↗Account / Zoneの優先順位
JSON出力の実装 ↗配列正規化とJSON例外
KVコマンドの公式ソース ↗実際のKV引数・操作
cfテレメトリ方針 ↗検索語を含むテレメトリ

公式リポジトリの参照コミット:bf0a0e7008d2b7037df8c03194cf8d335626dcf9。本書は公式README・公式実装を中心に整理しています。専用の developers.cloudflare.com/cf/ ページは調査時に取得できなかったため、そこを確認済みの根拠には使っていません。

デザイン:StellarArc Design System。本文・コード・inline SVGはローカル配信のCSSとフォントを利用します。