全体像:cfで何が変わるか
cfは、Cloudflareの公開API操作とWorkersの開発・配備を一つの入口にまとめたCLIです。コマンドを暗記するより、目的を検索し、ヘルプとスキーマで確かめ、対象を選んで実行する流れを身につけます。
CLIはターミナルから文字で操作する道具、APIはサービスをプログラムから操作する窓口です。cfの生成コマンドはAPI仕様を元に作られます。WorkersはCloudflare上でコードを実行するサービス、KVはキーと値を保存するストレージです。
| 入口 | 役割 | このガイドでの扱い |
|---|---|---|
cf <product> … | DNS・KV・D1などのAPI操作。製品→グループ→操作の順。 | KVを使って作成・読み書き・削除を練習 |
cf init / dev / build / deploy | プロジェクト作成、ローカル開発、ビルド、配備。 | 新規Workerを型検査してビルド |
cf cli search / cf schema | 操作を探し、API要求の構造を調べる。 | 認証なしで始める基礎演習 |
| Wrangler | 既存のWorkers開発CLI。cfから委譲される経路もある。 | 既存アプリは移行前にビルド経路を確認 |
演習の準備とインストール
必須はNode.js 22以上とnpmです。JSONの絞り込み演習にはjqを使います。macOS / Linux / WindowsのWSLで、bashまたはzshから実行する例です。Windows PowerShellでは環境変数や引用符の書式を読み替えてください。
所要時間の目安は基礎20分、KV20分、Workers30分です。CLIの取得と依存のインストールにはインターネットが必要です。検索・スキーマ・dry-runはログインなしで試せます。実クラウド演習にはCloudflareアカウントと対象操作の権限が必要です。
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以上。探す → ヘルプ → スキーマ → dry-run
cf cli search は、コマンド・説明・引数を検索して最大5件の候補を返します。AIに処理を丸投げする命令ではありません。検索しただけではDNSやKVは変更されません。英語の操作語とリソース名で探すと、元のAPI説明に合いやすくなります。
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{
"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 が表示されること。認証と操作対象を取り違えない
認証は「誰の権限で実行するか」、アカウントとゾーンは「どこを操作するか」です。アカウントはリソースを管理する単位、ゾーンはCloudflareに登録したドメインの単位です。ログインできたことと、目的の対象を操作できることは別です。
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を使い、表示された案内に従います。
# 複数のログインを使い分けたい場合
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 ID | CLOUDFLARE_ACCOUNT_ID → 設定ファイル → 保存済みaccount → 対話選択等 | --account-id は全コマンド共通のフラグではない |
| Zone | --zone / -z → CLOUDFLARE_ZONE_ID | ゾーンIDまたはドメイン名。名前解決には追加の権限が必要になる場合がある |
選択中のプロファイルと、対象Account ID / Zone IDを自分で説明できること。
読み取りとJSON:最初の実API
ここから実Cloudflareへの読み取りを行います。DNSを登録済みの場合はDNS一覧、ドメインがない場合はKV namespace一覧を使います。--dry-runを外すと実APIへ送信されます。
# 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.jsonbeta.5の構造化結果は標準出力へJSONで出ます。多くの一覧は配列に正規化されるため、例では.result[]ではなく.[]を使っています。最初はファイルの形を確認してからフィルターを書いてください。
ページングで見落とさない
この例は1ページだけです。--page / --per-pageがある操作と、--cursorを使う操作を区別します。beta.5の出力処理では一覧のresult_infoが除かれる場合があるため、「一覧を保存した=全件を保存した」と扱わないでください。全件収集が目的なら、対象コマンドの出力とAPIのページング情報を検証し、必要に応じて公式SDK/APIを使います。
JSONをファイルへ保存でき、配列から必要な列を抽出できること。空配列は必ずしもエラーではありません。対象と権限も確認します。
認証不要:ローカルKVを操作する
まずMiniflareというローカル実行環境で、キーgreetingの保存・読み取りを試します。--localと同じ--persist-toを毎回付けます。クラウドにnamespaceを作成する操作は不要です。以下のcf-guide-labはローカル状態を識別する演習用の名前です。
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--localが表示されても全操作がローカル対応とは限りません。READMEはKVのキー操作、D1のraw・migration、R2オブジェクト操作などの範囲を示しています。未対応はエラーになり、本番へ自動的に切り替える動作ではありません。--persist-toは--localと組み合わせるオプションです。
getが
Hello cf を返し、listに greeting があること。削除後はlistから消えること。実践:専用KVの作成から片付けまで
この演習は実クラウドに書き込みます。既存アプリが使うnamespaceを指定せず、専用のcf-guide-labを作ります。契約・利用量に応じた料金や上限があるため、アカウントのプランを確認して実施してください。本ガイド制作時は以下の実リソース作成・削除を行っていません。
1. 送信内容を確認して作成する
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. 保存 → 読み取り → 更新
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 greeting3. 演習で作ったnamespaceだけを削除する
# 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 は確認を省略するため、通常の手動演習では付けません。Workers:新規作成・起動・型検査
次はAPIの直接操作から、Workerの開発へ進みます。新しい空のディレクトリを指定してください。cf initは既存ファイルがある場所では自動構成を行うため、空ディレクトリのひな形生成と動作が異なります。
# 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.ts | HTTPリクエストに応答するWorker |
cloudflare.config.ts | Worker名・互換日・bindingsなど |
vite.config.ts | ViteにCloudflare pluginを登録 |
.cloudflare/types/index.d.ts | 設定に対応したWorkerの型 |
package.json / lockfile | 実行スクリプトと依存。再現性のためlockfileを保存 |
npm run typecheck
npm run build
npx cf deploy --dry-runHello 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環境ブロックをそのまま移すものではありません。
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"),
},
},
}));import { env } from "cloudflare:workers";
export default {
fetch() {
return new Response(`Hello ${env.WORLD}!`);
},
} satisfies ExportedHandler;npm run typecheck
npx cf dev --mode development
# 開発サーバーを止めてから
npx cf build --mode production
npx cf deploy --mode production --dry-runmodeで値を変えただけでリソースが隔離されるわけではありません。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" }),// 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を確認して進めてください。
# 同じ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指定だけで成果物が作り直されるわけではない |
既存プロジェクトの移行
# 既存プロジェクトの作業ツリーがきれいな状態で開始
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への委譲が残る経路があります。
自動化とトラブルシューティング
スクリプトでは対象と失敗条件を明示する
CIの秘密変数へトークン、通常変数へアカウントIDを設定し、リポジトリ内のcfとlockfileを固定します。以下はKV一覧を読み取って保存する例です。set -euo pipefailはbashのエラー検出を厳格にします。
#!/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.jsonCF_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 / 5xx | API制限や一時障害 | 間隔を空け、変更操作は結果照合後に再試行 |
テレメトリの確認
cf cli telemetry status
cf cli telemetry disable
# コマンド単位で止めたい場合
CF_SEND_TELEMETRY=false cf cli search "list KV namespaces"到達チェックと公式資料
知識を読んだだけで終わらせず、手順を見ずに次の項目を説明・実行できるか確認します。チェック状態はこのブラウザ内に保存されます。
検証の範囲
調査日: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とフォントを利用します。