webflow-cli:cloud

Name: webflow-cli:cloud
Author: webflow

github.com/webflowクラウド・DevOps1331.0k 回インストール今日更新

リポジトリ

webflow-cli:cloud について

webflow-cli:cloud は、Webflow CLI によるプロジェクトの初期化、アプリのデプロイ、Webflow Cloud の管理を案内するスキルです。プロジェクトの状態に応じた手順と、非対話実行に必要なフラグを示します。

主な機能

01テンプレートや GitHub から初期化
02サイト連携型または単独アプリのデプロイ
03アプリ、環境、ログ、デプロイの管理
04環境変数の設定
05非対話型 CLI の手順案内

活用シーン

01ローカルの Next.js または Astro プロジェクトのデプロイ
02GitHub リポジトリを接続してデプロイ
03アプリのログやデプロイ状況の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/webflow/webflow-skills --skill webflow-cli:cloud

インストール後、Claude Code で/webflow-cli:cloudを入力して読み込まれたか確認します。

詳細

Webflow Cloud

テンプレートまたは既存の GitHub リポジトリから新しいプロジェクトを初期化し、Webflow Cloud にデプロイして、既存のアプリ（一覧表示、詳細確認、ログ、デプロイ、環境、環境変数）を管理します。デプロイには 2 つのモードがあります。サイトに接続（既存の Webflow サイトにデプロイ）と、プロジェクトアプリ（既存のサイトを必要とせず、独立したアプリとしてデプロイ）です。

名前空間：`apps`（正式）と `cloud`（非推奨のエイリアス）

webflow apps <command> は Webflow Cloud の正式な名前空間です。webflow cloud <command> も引き続き動作します。init／deploy 形式は同じハンドラーのエイリアスですが、apps が推奨されるため非推奨となっています。

正式	非推奨の `cloud` エイリアス	備考
`webflow apps init`	`webflow cloud init`	オプションとハンドラーは同じです。ただし、`--import` とそのリポジトリ取り込み用フラグは `apps init` でのみ使用できます。
`webflow apps deploy`	`webflow cloud deploy`	ハンドラーは同じです。ただし、`--json` と `--dry-run` は `apps deploy` でのみ使用できます。
—	`webflow cloud create <name>`	削除に先立って非推奨となっています。`apps init`（または従来の名前空間を使い続ける場合は `cloud init`）を使用してください。
—	`webflow cloud list`	スキャフォールドテンプレートを一覧表示します。アプリではありません。`cloud` の下に引き続き残り、`apps` に相当するコマンドはありません。ワークスペースのアプリを一覧表示する `apps list` と混同しないでください。
`webflow apps list` / `get` / `domains` / `link` / `update` / `delete` / `environments …` / `deployments …` / `logs …` / `env-vars …`	—	`cloud` に相当するコマンドはありません。正式な名前空間でのみ使用できます。

cloud init／cloud deploy 経由でコマンドを実行すると、apps 形式を案内する非推奨の通知が stderr に一度だけ表示されます（--json を指定すると抑制されます）。

新しい作業では apps 形式を優先してください。このスキルでは全体を通じて apps コマンドを使用しています。apps init／apps deploy の各呼び出しは、--import（init）と --json／--dry-run（deploy）を除き、同じフラグで cloud init／cloud deploy として実行できます。

手順

ステップ 0：CLI がインストールされていることを確認する

webflow --version

コマンドが見つからない場合は、インストールしてください。

npm install -g @webflow/webflow-cli@latest
# or yarn global add @webflow/webflow-cli@latest
# or pnpm add -g @webflow/webflow-cli@latest

その後、状態の検出に進みます。

ステップ 1：プロジェクトの状態を検出する

進む経路を決める前に、両方の確認を実行してください。

# Is this project already set up on Webflow Cloud?
cat webflow.json

# Is there a git remote?
git remote get-url origin 2>/dev/null

クイックリファレンス（CLI は現在 cloud.app_id を書き込みます。古いマニフェストには、フォールバックとして引き続き読み込まれるレガシーの cloud.project_id が含まれている場合があります）：

`webflow.json` の `cloud.app_id`（または従来の `cloud.project_id`）	git remote	→ パス
いいえ	—	A — 新規プロジェクト
はい	いいえ	B — 既存プロジェクト、git なし
はい	はい	C — 理想的な状態

TTY なしで実行されています。 CLI の対話型プロンプトは、process.stdin.isTTY が true の場合にのみ表示されます。サブプロセス経由で CLI を呼び出すエージェントには TTY がないため、すべてのプロンプトが何も表示されずにスキップされ、フラグで渡されていない必須値があると、--app-name cannot be empty のような致命的なエラーが発生します。

このスキルのすべてのコマンドに適用されるルール： 必須のフラグはすべて明示的に渡してください。プロンプトに頼らないでください。CLI が --no-input を受け付ける場合は、契約を明示するために渡してください。コマンドごとに必要なフラグは次のとおりです。

コマンド常に渡すフラグ
apps init（サイトに接続） --no-input --app-name <3–39 chars> --framework <astro|nextjs|vite> --mount <path> --site-id <id>
apps init --new（アプリ） --no-input --app-name <3–39 chars> --framework <astro|nextjs|vite|static> --workspace-id <id>
apps init --import（サイトに接続） --no-input --import <repo-url> --site-id <id> --mount <non-root path> --idempotency-key <key>
apps init --import --new（プロジェクトアプリ） --no-input --import <repo-url> --new --idempotency-key <key> — --mount は不要
apps deploy（サイトに接続） --no-input --mount <path> --environment <env> --site-id <id> に加え、初回デプロイでは --app-name
apps deploy（プロジェクトアプリ、初回デプロイ） --no-input --mount <path> --environment <env> --workspace-id <id> --app-name <name>

apps deploy の --site-id、--app-id、--framework、--workspace-id を使うと、デプロイ時に webflow.json の設定をエージェント側で上書きできます。

複数のワークスペースがあるトークンでは、以前はエージェントが致命的なハング状態になっていました。 ワークスペースの選択に TTY 以外での方法がなかったためです。現在は --workspace-id を渡すと、選択画面をスキップできます。ワークスペース ID は Webflow ダッシュボードの UI のどこにも表示されないため、ユーザーが手動で確認することはできません。エージェントが ID を持っていない場合は、ユーザーにプロジェクト内で webflow apps deploy を一度対話的に実行してもらってください。事前チェックでワークスペースの選択を求められ、webflow.json に cloud.workspace_id が書き込まれます。それ以降、エージェントはマニフェストから ID を読み取り、後続の実行で --workspace-id を渡せます。ID の確認に apps init --new を提案しないでください。既存のプロジェクトで実行すると、破棄される一時ディレクトリが作成されます。例外： Path A2（空のディレクトリ）では、単一ワークスペースのトークンを自動的に解決するために、--workspace-id なしで apps init --new を試しても_安全です_。Path A2を参照してください。

サイト ID はダッシュボードで確認できます。 --site-id が必要なのに不明な場合、ユーザーに site_XXXX 形式の値を直接尋ねないでください。代わりに webflow sites list を使ってサイトを取得し、表示名で選べる一覧を提示してください。ユーザーはダッシュボードで確認することもできます。

読み取り／管理コマンドでは --workspace-id は不要です。 apps list／get／domains／environments／deployments／logs／env-vars コマンドは、OAuth トークンからサーバー側でワークスペースを判定します。--workspace-id フラグはなく、ワークスペースを尋ねるプロンプトも表示されません。アプリの管理を参照してください。

Path A：`app_id` がない場合 — 新規プロジェクト

プロジェクトはまだデプロイされていません。ほかのことをする前に、ユーザーに次の2つの質問をしてください。

「このプロジェクトのソースコード（既存の Next.js または Astro のコードベース）はすでにありますか。それとも、空のディレクトリから始めて Webflow のスターターのスキャフォールドを作成しますか？」

コードがある場合：「そのコードはすでに GitHub リポジトリにプッシュされていますか。また、ローカルファイルではなく、そのリポジトリから Webflow にビルドさせたいですか？」

回答によって分岐先が決まります。次の3つは、それぞれ明確に異なります。

ユーザーの状況	分岐	初期化手順
既存のコードがあり、ローカルファイルからデプロイする	Path A1	`apps init`をスキップします。これを実行すると、リポジトリ内に hello-world のスキャフォールドを含む `./<app-name>/` サブフォルダーが作成されますが、これはユーザーが望んでいません。
空のディレクトリ、または Webflow のスターターを希望する	Path A2	`apps init`を実行して、`Webflow-Examples/hello-world-*`からスキャフォールドを作成します。
既存のコードがすでに GitHub 上にあり、Webflow にリポジトリからビルドさせたい	Path A3	`apps init --import <repo-url>`を実行します。リポジトリに紐付いたGitHub 接続済みアプリが作成されます。`apps`専用であり、`cloud init --import`はありません。

A1 と A3 の選択は見た目だけの違いではありません。後でアプリでできることが変わります。 GitHub 接続済みアプリ（A3）ではapps deployments trigger／redeployを利用でき、ダッシュボードのプッシュによるデプロイの対象となるのもこの種類だけです。ローカルのapps deployで最初に作成したアプリ（A1）はGitHub に接続されていないため、trigger／redeployは実行できません。ユーザーのコードがすでに GitHub 上にあり、CI、自動デプロイ、ロールバック、または「プッシュしたらデプロイ」といった話が出た場合は、A1 ではなくA3に案内してください。

いずれの方法を選んでも、後から変更できます。A1 のアプリはapps update --github-source <repo-url>で後からリポジトリを指定できます（apps updateを参照）。ただし、最初に A3 を選べば追加の手順を省けます。

分岐を決めた後、既存サイトに紐付けるか、アプリにするかも確認してください（最初のデプロイ前のみ関係します）。

ユーザーの発言	モード	結果
「Webflow サイト`<name>`にデプロイして」、「サイトに紐付けて」、既存サイトに言及する	サイトに紐付け	アプリが既存の Webflow サイトに紐付けられ、サイトの URL で選択したマウントパスにアプリが表示されます。`--site-id`が必要です。
「プロジェクトアプリ」、「アプリだけでいい」、「サイトは不要」、または既存サイトへの言及がない	プロジェクトアプリ	初回デプロイ時に、新しい Webflow サイト（`<app-name>-<hash>.webflow.io`）が作成されます。

どちらかの質問への回答が曖昧な場合は、質問してください。独断で決めないでください。

パス A1：既存のコードベース、ローカルファイルからデプロイする

コードが GitHub にある場合は、先に A3 を確認してください。 このパスではローカルファイルをアップロードしてビルドするため、GitHub に接続されていないアプリが作成されます。そのため、apps deployments trigger / redeploy とダッシュボードのプッシュによるデプロイはすべて拒否されます。リポジトリが GitHub にあり、そこから Webflow にビルドさせたい場合は、代わりにパス A3を使用してください。

ユーザーは動作するソースコードを用意しています。apps deploy がすべて処理します。フレームワークの検出は package.json を対象に実行され、事前チェックの段階でフラグまたはプロンプトから ID が解決されます。apps init は不要で、事前に webflow.json を手書きする必要もありません。

ステップ 1：初回の認証（人間のみ）。 ブラウザでの手順はエージェントが実行できないため、ユーザーにローカルで次を実行するよう伝えてください。

webflow auth login

ステップ 2：デプロイ。 正確な形式は、エージェントが把握している情報によって異なります。

A1-a — サイトに紐付ける場合、--site-id が分かっている場合：

webflow apps deploy --no-input \
  --site-id site_abc123 \
  --app-name my-app \
  --framework nextjs \
  --mount /app \
  --environment main \
  --skip-mount-path-check \
  --skip-update-check

package.json に検出可能なシグナルがある場合、--framework は省略可能です。該当するシグナルは、nextjs / astro の Cloudflare アダプター（@opennextjs/cloudflare、@astrojs/cloudflare）、または vite の場合の vite パッケージ自体です。モノレポの場合や、自動検出の信頼性が低い場合は、明示的に指定してください。

ユーザーの --site-id が分からない場合は、site_XXXX の値をそのまま尋ねないでください。ユーザーのサイトを取得するには webflow sites list を使用し、選択できるよう分かりやすい表示名を提示してください。

A1-b — プロジェクトアプリの場合、--workspace-id が分かっている場合：

webflow apps deploy --no-input \
  --workspace-id ws_abc123 \
  --app-name my-app \
  --framework nextjs \
  --mount / \
  --environment main \
  --skip-mount-path-check \
  --skip-update-check

A1-c — プロジェクトアプリの場合、workspace ID が不明な場合（よくある不足情報）：

workspace ID は Webflow ダッシュボードの UI 上のどこにも表示されません。 ユーザーが手動で調べることはできません。確認するには CLI を実行するしかありません。そのため、次の手順になります。

ユーザーに、ローカルで対話形式のデプロイを 1 回実行してもらいます。 プロジェクトディレクトリ内で次を実行します。

webflow apps deploy

--no-input も ID フラグも指定しない場合、事前チェックで次のプロンプトが表示されます。"このプロジェクトは Webflow Cloud 用に初期化されていません。どのようにデプロイしますか？" → ユーザーが「新しいアプリを作成」を選択 → ワークスペースの選択 → 完了。この人間主導のデプロイを 1 回実行すると、cloud.workspace_id と siteId が webflow.json に、WEBFLOW_SITE_ID が .env に書き込まれます。その後、エージェントは新たにプロビジョニングされたサイトを指定する --site-id を使って、以降のデプロイをすべて実行できます。

ユーザーに、workspace ID を「調べる」ために apps init --new を実行するよう依頼しないでください。既存のプロジェクトでこれを実行すると、ユーザーのリポジトリ内に破棄される ./<app-name>/ のスクラッチディレクトリが作成され、その中に hello-world のひな型が配置されます。上記の対話形式の apps deploy の手順を使用してください。workspace ID を確認し、同じ手順で初回のデプロイも完了できます。

ステップ 3：Git をセットアップする（まだの場合）— 以下のパス A2 のステップ 3 と同じです。

パス A2：空のディレクトリからの新規スキャフォールディング

プロジェクトをスキャフォールドする — ユーザーの意図に合った形式を選びます。
```
# Project app (no site attachment). --workspace-id avoids the multi-workspace hang.
webflow apps init --new --no-input \
  --app-name my-app \
  --framework astro \
  --workspace-id ws_abc123
```
```
# Site-attached (connect to an existing Webflow site). Requires --site-id.
webflow apps init --no-input \
  --app-name my-app \
  --framework astro \
  --mount /app \
  --site-id site_abc123
```
すべてのフラグについては、apps init を参照してください。

パス A2 のプロジェクトアプリにおけるワークスペース ID の検出のみ： パス A2 は空のディレクトリから始まるため、どちらの場合も apps init --new は新しいスキャフォールドを作成します。汚染されるものはありません。そのため、エージェントが --workspace-id を持っていない場合は、まず apps init --new を付けずに試しても問題ありません。
```
# Try this first if --workspace-id is unknown (Path A2 only — empty dir)
webflow apps init --new --no-input \
  --app-name my-app \
  --framework astro
```
- 単一ワークスペースのトークン： CLI は唯一のワークスペースを自動選択し、cloud.workspace_id を webflow.json に書き込み、終了コード 0 で終了します。マニフェストから値を読み取り、手順 2 の apps deploy に --workspace-id として渡します。
- 複数ワークスペースのトークン： ワークスペース選択画面が起動し、TTY がないためコマンドが停止します。Bash 呼び出しに 30 秒のタイムアウトを設定する（またはコマンドを timeout 30s ... でラップする）必要があります。単一ワークスペースの init が正常に完了するまでの時間は 10〜20 秒です（OAuth チェック + GET /v2/workspaces + GitHub からのスキャフォールドのダウンロード）。そのため、出力がないまま 30 秒を過ぎた場合は、選択画面で停止しています。タイムアウトが発生したら、ユーザーにワークスペース ID を直接尋ね、--workspace-id を指定して再実行します。
パス A2 のサイトにアタッチする場合、同等の自動検出方法はありません。事前に必ず --site-id が必要です。ユーザーが選べるよう、以下のサイト選択の方法を使用してください。

パス A1（既存のコードベース）では、この方法は使えません。 既存のプロジェクトで apps init --new を実行すると、破棄される一時的なサブディレクトリが作成されます。パス A1 のワークスペース ID 検出方法は、パス A1-c に記載されているとおりです。

パス A3：既存の GitHub リポジトリ、GitHub 接続済みアプリ

ユーザーのコードはすでに GitHub にあり、ローカルファイルではなくリポジトリから Webflow にビルドさせたい場合です。apps init --import <repo-url> を実行すると、そのリポジトリに紐づいたアプリが作成され、ローカルにクローンされます。

apps 専用です。 --import は apps init でのみ使用でき、意図的に cloud init --import は用意されていません。別の理由でユーザーが cloud 名前空間を使っている場合は、パス A1 に切り替えて、後から apps update --github-source でリポジトリを接続してください。

ステップ 0：前提条件 — Webflow GitHub App。 リポジトリのオーナーにインストールされ、ワークスペースに接続されている必要があります。CLI では設定できません。ダッシュボードと GitHub 側での設定が必要です。インポート時に権限エラーが発生した場合は、まずこれを確認してください。

ステップ 1：初回認証（人間のみ）。 A1 と同様に、エージェントはブラウザーでの認証フローを実行できません。

webflow auth login

ステップ 2：インポート。 --site-id または --new のいずれか一方が必須です。CLI がリポジトリ内の情報から対象を推測することはありません。

A3-a — サイトに紐づける場合（--mount は必須で、ルート以外を指定する必要があります）：

webflow apps init --import https://github.com/acme/site \
  --site-id 6234abc --mount /app --dry-run

webflow apps init --import https://github.com/acme/site \
  --site-id 6234abc --mount /app

A3-b — プロジェクトアプリの場合（プロジェクトアプリは独自ドメインのルートを所有するため、--mount は指定できません）：

webflow apps init --import https://github.com/acme/site --new

A3-c — 非対話型／CI の場合。 ここでは --idempotency-key が必須です。リポジトリと対象の組み合わせごとに一意で、再試行しても変わらないキー（例：$GITHUB_RUN_ID-$REPOSITORY-$SITE_ID）を使用してください。これにより、再試行時にアプリが二重に作成されず、元のアプリが再利用されます。

webflow apps init --import https://github.com/acme/site --new --no-input \
  --idempotency-key "$GITHUB_RUN_ID-acme-site" \
  --branch main --json

--skip-clone を追加すると、ファイルシステムに何も書き込まずにアプリを登録できます。アプリ ID と環境 ID が出力されます。リポジトリがすでにチェックアウト済みの場合や、クローンを作成したくない環境で実行する場合に便利です。

--branch でビルド対象のブランチを指定します。デフォルトではリポジトリのデフォルトブランチが使用されます。

ステップ 3：プッシュによるデプロイを有効化（ダッシュボードで手動設定）。 インポートするとアプリはリポジトリに接続されますが、ダッシュボードの設定が完了するまで、プッシュしてもデプロイされません。ワークフローの全例のステップ 3 以降を参照してください。それまでは、必要に応じてビルドを実行します。

webflow apps deployments trigger --json

A3 アプリで「更新をプッシュする」ために apps deploy を実行しないでください。このコマンドはローカルファイルをアップロードするもので、A1 の方式です。GitHub 接続済みアプリでは、deployments trigger（現在の HEAD をビルド）および deployments redeploy <depId>（過去のコミットを再実行、つまりロールバック）が同等の操作です。

一覧から `--site-id` を選択する

--site-id が必要な場合（Path A1 のサイト紐付け、Path A2 のサイト紐付け、またはその他の場合）で、ユーザーから指定がない場合は、webflow sites list --json を使ってトークンから参照できるサイトを列挙し、読みやすい名前の短い一覧を提示してユーザーに選んでもらいます。サイト ID は Webflow ダッシュボードの URL 設定で確認できますが、数値 ID を尋ねるのは使い勝手がよくないため、ID を求められない限り表示名を提示してください。

# Returns a JSON array of sites with id, displayName, lastPublished, etc.
webflow sites list --json

ワークフロー：

webflow sites list --json を実行します。CLI は JSON 配列を返して終了コード 0 で終了します。

出力を解析します。displayName をキーに（サイトが多数ある場合は lastPublished も含めて）、ユーザーに短い一覧を表示します。例：

Which site should this project deploy to?

1. Acme Marketing  (last published 2 days ago)
2. Acme Docs       (last published 3 weeks ago)
3. Acme Internal   (never published)

ユーザーが選んだ項目を対応する id フィールドにマッピングします。それを --site-id として渡します。

webflow sites list でエラーが発生した場合（認証情報がない／期限切れ）、エラーを提示し、ユーザーにローカルで webflow auth login を実行するよう依頼してください。エージェントから実行しようとしないでください。

デプロイ： 上記の初期化形式に合う形式を選びます。マニフェストの書き込みが不完全な場合でも読み違えが起きないよう、--site-id（project-app の初回デプロイの場合は --workspace-id）を渡してください。

# Project-app first deploy — provisions the Cloud site/app/env
webflow apps deploy \
  --no-input \
  --app-name my-app \
  --workspace-id ws_abc123 \
  --mount / \
  --environment main \
  --skip-mount-path-check \
  --skip-update-check

# Site-attached first deploy — uses the existing Webflow site
webflow apps deploy \
  --no-input \
  --app-name my-app \
  --site-id site_abc123 \
  --mount /app \
  --environment main \
  --skip-mount-path-check \
  --skip-update-check

これにより、Webflow Cloud にアプリが作成され、webflow.json の cloud.app_id が設定されます。更新した webflow.json をコミットしてください。

git をセットアップする（まだの場合）：

git init && git add . && git commit -m "init"
git remote add origin https://github.com/your-org/my-app.git
git push -u origin main

（任意）Webflow ダッシュボードでプッシュによるデプロイを有効にします。 GitHub にプッシュするだけではデプロイは実行されません。この連携は CLI やリポジトリではなく、Webflow ダッシュボードで設定します。ユーザーに次の手順を伝えてください：
1. Webflow ダッシュボード → Cloud アプリ → Settings → Git を開きます
2. GitHub アカウントを接続し、リポジトリとブランチを選択します
3. 確認します。接続を検証するため、ダッシュボードで最初のデプロイが自動的に実行されます
4. 以降、接続したブランチへのプッシュごとにデプロイが実行されます
CLI ではこれらの手順を実行できません。ユーザーがこの設定を省略した場合、デプロイは毎回、手動の webflow apps deploy 実行（Path B 形式）または CI/CD パイプラインで行う必要があります。

手順 2 でデプロイの認証エラーが発生した場合：webflow auth login を実行し、ブラウザーでのフローを完了してから、再試行してください。

Path B：`app_id` は存在するが、git リモートがない — 既存プロジェクト、git なし

プロジェクトはすでに Webflow Cloud 上にありますが、git リポジトリがありません。直接デプロイし、git のセットアップを促します。

デプロイ： まず webflow.json を読み込みます。siteId が設定されている場合は、それに一致する --site-id を渡します。cloud.workspace_id のみが設定されている場合は、それに一致する --workspace-id を渡します。
```
webflow apps deploy \
  --no-input \
  --site-id site_abc123 \
  --mount / \
  --environment main \
  --skip-mount-path-check \
  --skip-update-check
```
プッシュによるデプロイを促す： git リポジトリを初期化して GitHub にプッシュし、その後、Webflow ダッシュボードでリポジトリを接続する（アプリ → Settings → Git）ようユーザーに提案します。プッシュによるデプロイを有効にするには、ダッシュボードでの手順が必要です。CLI では実行できません。Path A の手順 3～4 を参照してください。

デプロイの認証エラーが発生した場合：webflow auth login を実行し、ブラウザーでのフローを完了してから、手順 1 を再試行してください。

Path C：`app_id` が存在し、git remote もある場合 — 理想的な可能性があります

プロジェクトはデプロイされており、git remote もあります。ただし、remote が存在するだけでは、プッシュによるデプロイが設定されている証拠にはなりません。 この設定はダッシュボード側で行われるため、CLI からは確認できません。提案する前に確認してください。

必ずユーザーに尋ねてください： 「このリポジトリは、ダッシュボードの Webflow Cloud アプリ（アプリ → Settings → Git でブランチを選択）に接続されていますか？」 回答によって推奨する対応が変わります。

はい、接続されています — プッシュによるデプロイは有効です。必要な操作は git push のみです。再リンクや再デプロイを提案しないでください。

いいえ、接続されていません — Webflow 側では git push を実行しても何も起きません。今すぐ手動でデプロイするか、今後のコミットでプッシュによるデプロイを有効にするため、先にダッシュボードでリポジトリを接続してもらいます。

わかりません — 接続されていないものとして扱い、ダッシュボードでの接続を推奨してください（一度設定すれば、その後はプッシュによるデプロイが継続して有効になります）。

接続されている場合 — コミットしてプッシュするだけです。
```
git add .
git commit -m "your message"
git push
```
Webflow Cloud はプッシュを検知して、自動的にデプロイします。接続後の初回デプロイはダッシュボード自体が実行し、それ以降のプッシュは自動的に検知されます。
接続されていない場合 — 2 つの方法があります。
- 今後のコミットでプッシュによるデプロイを有効にする（推奨）。Webflow ダッシュボード → 使用する Cloud アプリ → Settings → Git を開き、リポジトリを接続してブランチを選択するようユーザーに伝えてください。接続の確認のため、ダッシュボードが初回デプロイを自動的に実行します。それ以降は、そのブランチへの git push のたびにデプロイされます。
- 今すぐ一度だけ手動でデプロイする。プッシュによるデプロイは有効になりません。webflow.json の siteId と一致する --site-id を指定します。
```
webflow apps deploy \
  --no-input \
  --site-id site_abc123 \
  --mount / \
  --environment main \
  --skip-mount-path-check \
  --skip-update-check
```
  これにより現在の状態がデプロイされますが、プッシュによるデプロイは設定されません。次回の git push も Webflow 側では何も起きません。

デプロイ時に認証エラーが発生した場合は、webflow auth login を実行し、ブラウザーでの認証を完了してから再試行してください。

ツールの使用方法

すべての webflow apps ／ webflow cloud コマンドには Bash tool を使用します
webflow.json、package.json の確認には Read tool を使用します。これらを直接変更しないでください
プロジェクトファイルの検索には Glob tool を使用します
CLI ワークフローでは Webflow MCP ツールを使用しないでください

認証

# Interactive — local-only, opens a browser. NOT for agents or CI.
webflow auth login

webflow auth login はユーザーのブラウザーで OAuth フローを実行し、その後トークンを .env に書き込みます。--no-input では実行できず（No-input mode enabled. Aborting OAuth authentication で終了します）、エージェントはこのコマンドを操作できません。 webflow auth login が必要な場合（トークンがない、または期限切れの場合）は、ユーザーにローカルで一度実行してもらい、完了したら知らせてもらってください。

CLI はどちらのモードでも同じトークン環境変数を書き込みます。モードごとの使い分けはありません。

webflow auth login が .env に書き込む内容：

変数	常に書き込まれるか	説明
`WEBFLOW_API_TOKEN`	はい（両方のモード）	OAuth アクセストークン。標準のトークン環境変数です。`webflow auth login` によって設定されます。
`WEBFLOW_SITE_ID`	サイトに紐付けられたプロジェクトのみ（またはプロジェクトアプリの初回デプロイ後）	サイト ID。サイトに紐付けられたプロジェクトでは `apps init` が、プロジェクトアプリでは最初のデプロイでサイトがプロビジョニングされた後に `apps deploy` が書き込みます。

プロジェクトアプリの初回デプロイ後、CLI はバックエンドでサイトをプロビジョニングし、WEBFLOW_SITE_ID を .env に書き込みます。その後はプロジェクトアプリもサイトに紐付けられたプロジェクトと同様に動作します。ただし、トークン環境変数は引き続き WEBFLOW_API_TOKEN です。

非推奨のレガシー設定： WEBFLOW_SITE_API_TOKEN（および WEBFLOW_WORKSPACE_API_TOKEN）は読み取り専用のレガシーフォールバックです。CLI がこれらを書き込むことはありませんが、WEBFLOW_API_TOKEN が設定されていない状態で環境内にいずれかが設定されている場合は、レガシー値を使用し、実行のたびに非推奨の警告を表示します。 新しいプロジェクトでは WEBFLOW_SITE_API_TOKEN を .env や CI シークレットに設定せず、WEBFLOW_API_TOKEN を使用してください。

その他の環境変数（すべてのモードで使用）：

変数	説明
`DO_NOT_TRACK`	テレメトリーをオプトアウトするには、`1` に設定します。
`WEBFLOW_SKIP_UPDATE_CHECKS`	@webflow パッケージの更新チェックをスキップするには、`true` に設定します。

WEBFLOW_SITE_ID 環境変数は読み取り専用です。 フラグまたはマニフェストに値が設定されていない場合、実行時に使用されますが、webflow.json に書き戻されることはありません。.env で WEBFLOW_SITE_ID=X を設定してもマニフェストは更新されません。設定を反映するのは apps init、apps deploy、およびマニフェスト自体のみです。

GitHub Secrets： すべてのモードでトークンには WEBFLOW_API_TOKEN を使用してください。サイトに紐付けられたプロジェクトと、初回デプロイが完了したプロジェクトアプリでは、WEBFLOW_SITE_ID も設定してください。.env ファイルをコミットしないでください。既存の CI で WEBFLOW_SITE_API_TOKEN を使用している場合は、名前を変更してください。デプロイ自体は成功しますが、切り替えるまでは実行のたびに非推奨の警告が表示されます。

設定 — webflow.json

{
  "siteId": "site_abc123",
  "cloud": {
    "app_id": "app_xyz",
    "environment_id": "env_xyz",
    "workspace_id": "ws_xyz",
    "framework": "nextjs",
    "skipMountPathCheck": false
  }
}

すべての cloud.* キーは スネークケース です（appId ではなく app_id）。

キー	設定されるタイミング	備考
`siteId`	サイトに紐づくアプリ：`apps init` 時。プロジェクトアプリ：最初のデプロイ後（CLI がサイトをプロビジョニングします）。	まだデプロイされていないプロジェクトアプリには存在しません。
`cloud.framework`	`apps init` 時。	デプロイ先の解決に必須です — 以下を参照してください。
`cloud.app_id`	最初のデプロイ後。	正規のキーです。自動的に書き込まれます。旧式の `cloud.project_id` に代わるキーです。
`cloud.project_id`	レガシーのみ。	非推奨です。 `cloud.app_id` が存在しない場合（Project → App への名称変更前に作成されたマニフェスト）のフォールバックとして読み込まれます。新しいデプロイでは書き込まれず、将来のメジャーリリースで削除されます。
`cloud.environment_id`	最初のプロジェクトアプリのデプロイ後。	`createCloudApp` によって自動的に書き込まれます。
`cloud.workspace_id`	プロジェクトアプリの `apps init` 時（`--new`）。	最初のデプロイでサイトをプロビジョニングするために使用されます。
`cloud.skipMountPathCheck`	ユーザーが管理します。	`--skip-mount-path-check` と同等です。

CLI はビルド時に、cloud.deployment_type（"ssr" | "ssg" | "spa"）、cloud.entrypoint_path、cloud.framework_version も バンドル版 webflow.json に書き込みます（これらは cosmic deployer の wrangler 設定とテレメトリーに使われます）。これらはビルド時の出力です。ソースの webflow.json に見つかった場合は削除しないでください。値が欠落すると、Next.js のサーバーサイドデプロイが予期せず機能しなくなります。

ID の解決と環境変数

共通リゾルバーは、siteId、appId、environmentId、workspaceId を厳密な優先順位で解決します。

explicit flag / positional arg  >  env var  >  webflow.json manifest  >  interactive prompt  >  error

リソース	フラグ／引数	環境変数（読み取り専用）	`webflow.json`
App ID	`--app-id` / `[appId]` arg	`WEBFLOW_APP_ID`	`cloud.app_id`（従来の `cloud.project_id` にフォールバック）
Environment ID	`--environment-id` / `[envId]` arg	`WEBFLOW_APP_ENVIRONMENT_ID`	`cloud.environment_id`
Site ID	`--site-id`	`WEBFLOW_SITE_ID`	`siteId`
Workspace ID	`--workspace-id`	`WEBFLOW_WORKSPACE_ID`	`cloud.workspace_id`

環境変数は読み取り専用であり、マニフェストに書き戻されることはありません。値がマニフェストに由来する場合、CLI は Using <resource> from webflow.json という行をログに出力します（--json では抑制されます）。何も解決できず、コマンドがプロンプトを表示できない場合（--no-input、CI=true、または TTY がない場合）、エラーに機械可読な missingFlag を含めて終了します。詳しくは、アプリの管理の --no-input の仕様をご覧ください。

デプロイ時の cloud.framework の解決：

webflow.json が存在し、cloud.framework がある場合 — そのまま使用します。値が無効な場合は、コード 1 で終了します。
webflow.json は存在するが、cloud.framework がない場合 — package.json からの検出にフォールバックします。
webflow.json がない場合 — package.json から自動検出します。成功すると、CLI は新しい webflow.json を書き込みます。

apps init で作成されたプロジェクトは、常にケース 1 に該当します。

コマンド

webflow cloud list

webflow cloud list

利用可能なスキャフォールドテンプレート（init で使用）を一覧表示します。有効なスキャフォールド ID を確認するには、apps init --framework の前に実行してください。これは apps list（デプロイ済みアプリの一覧）とは別の機能で、cloud 名前空間の下にのみ存在します。削除に先立って非推奨となっています。引き続き使用できますが、警告が表示されます。有効なスキャフォールド ID を確認するには、代わりに apps init --framework <bad-value> または --help を使用してください。

webflow apps init

新しいアプリをローカルで初期化します。モードはサイト接続型とアプリ型の 2 種類です。（webflow cloud init は同じフラグを持つ非推奨のエイリアスです。）

サイト接続型（既存の Webflow サイトに接続）：

# Agent / non-TTY — always pass every flag
webflow apps init \
  --no-input \
  --app-name my-app \
  --framework nextjs \
  --mount /app \
  --site-id site_abc123

# Human at a real terminal — interactive prompts will fill in any missing flag
webflow apps init

フラグ：

フラグ	短縮形	説明
`--app-name <name>`	`-n`	アプリ名です。3～39 文字である必要があります。CLI は初期化時と、プロジェクトアプリの最初のデプロイ時に、この範囲外の値を拒否します。
`--project-name <name>`	—	`--app-name` の非推奨の別名です。引き続き使用できます。
`--framework <framework>`	`-f`	`cloud list` にあるスキャフォールド ID と一致する必要があります。現在は `nextjs`、`astro`、`vite`、`static` です（`static` は単独利用時のみです。フレームワークを参照してください）。
`--mount <path>`	`-m`	マウントパスです（新しいドメインではデフォルト `/`、既存サイトでは `/app`）。スキャフォールド時に設定ファイル内で置き換えられます。`webflow.json` には保存されません。
`--site-id <id>`	`-s`	非対話型のサイト接続モードでは必須です。`--workspace-id` とは同時に指定できません。
`--workspace-id <id>`	`-w`	`--new`（アプリモード）のワークスペース選択を省略します。`--site-id` とは同時に指定できません。
`--new`	—	プロジェクトアプリモード（サイトなし）です。
`--no-input`	—	CI モードです。`--app-name` と `--framework` が必要です。`--new` を指定しない場合は、デフォルトでアプリの動作になります。

--no-input のサイト接続時における認証情報の解決順序：--site-id フラグ → webflow.json の siteId → WEBFLOW_SITE_ID 環境変数 → エラー。

サイト接続プロジェクトのスキャフォールディング後、CLI は自動的に DevLink 同期を実行します。

プロジェクトアプリ（サイトへの接続なし）：

# Agent / non-TTY — always pass --workspace-id to skip the workspace picker
webflow apps init --new --no-input \
  --app-name my-app \
  --framework nextjs \
  --workspace-id ws_abc123

# Human at a real terminal — prompts for workspace if not passed
webflow apps init --new

トークンで複数のワークスペースが見つかり、エージェントにワークスペース ID がない場合は、プロジェクト内から対話形式で webflow apps deploy を実行するようユーザーに依頼してください。事前確認プロンプトでワークスペースが選択され、以降のエージェントによる実行に備えて webflow.json に cloud.workspace_id が書き込まれます。ワークスペース ID は Webflow ダッシュボード UI に表示されないため、対話形式での CLI 実行が、実際にこれを確認する唯一の方法です。

	サイト接続	プロジェクトアプリ（`--new`）
OAuth／サイト選択	初期化時に必須	省略（代わりにワークスペースを選択）
`.env` の `WEBFLOW_SITE_ID`	初期化時に書き込み	最初のデプロイ後にのみ書き込み
`.env` の `WEBFLOW_API_TOKEN`	書き込み	書き込み
`webflow.json` の `cloud.workspace_id`	未設定	初期化時に設定（最初のデプロイで使用）
スキャフォールド	`astro`、`nextjs`、`vite`	`astro`、`nextjs`、`vite`、`static`
マウントパス	設定可能（デフォルト `/app`）	常に `/`
DevLink 同期	初期化後に実行	省略
ワークスペースの選択（project-app モードのみ）： `--workspace-id` が渡されない場合、CLI は `GET /v2/workspaces` を呼び出し、トークンがアクセスできるワークスペースを列挙します。ワークスペースが 1 つの場合は自動選択され、複数ある場合は対話形式の選択画面が表示されます。`--workspace-id` を指定すると、API への往復はスキップされます。CLI はこのフラグを信頼し、無効な場合は後から `createCloudApp` によって 404 が通知されます。選択した ID は `webflow.json` の `cloud.workspace_id` として保存されます。

エージェントに関する注意事項： ユーザーのトークンが複数のワークスペースにアクセスでき、エージェントが --workspace-id を渡せない場合、選択画面が表示され、非 TTY 環境では処理が停止します。ワークスペース ID は Webflow ダッシュボードの UI では確認できないため、対処方法は次のとおりです。ユーザーに、プロジェクト内で webflow apps deploy を対話形式で一度実行するよう依頼してください。 事前確認のプロンプトでワークスペースを選択し、初回デプロイが完了すると、cloud.workspace_id（および siteId、app_id、environment_id）が webflow.json に書き込まれます。その後、エージェントはマニフェストからワークスペース ID を読み取り、以降の実行で --workspace-id（またはサイトの作成後は --site-id）を渡せます。後で別のワークスペースを対象にするには、cloud.workspace_id を削除し、ユーザーに対話形式でデプロイを再度実行してもらいます。

webflow apps init --import <repo-url>（`apps` のみ）

スターターテンプレートではなく、既存の GitHub リポジトリから Cloud アプリを作成し、ローカルにクローンします。これは、すでに GitHub に存在するコードベースを取り込むための方法です。スキャフォールドは生成されず、フレームワークも選択されません。

このフラグを指定できるのは apps init のみです。 リポジトリの取り込みでは実際のアプリが作成されるため、非推奨のエイリアスではなく正規の名前空間を維持するよう、cloud init --import は用意されていません。

前提条件： Webflow GitHub App がリポジトリにインストールされ、ワークスペースに接続されている必要があります。 インストールされていない場合、作成は失敗します。CLI からインストールすることはできません。ダッシュボード側で設定してください。

フラグ	備考
`--import <repo-url>`	`https://github.com/<owner>/<repo>` を指定します。空欄にはできません。
`--site-id <siteId>`	既存のサイトに紐付けます。`--new` とは併用できません。どちらか一方を必ず指定してください。
`--new`	サイトに紐付ける代わりに、プロジェクトアプリを作成します。
`--mount <path>`	`--site-id` と併用する場合は必須（ルート以外）です。`--new` とは併用できません。プロジェクトアプリは独自ドメインのルートを所有するため、常に `/` にマウントされます。
`--branch <branch>`	ビルドするブランチを指定します。デフォルトではリポジトリのデフォルトブランチが使われます。
`--idempotency-key <key>`	非対話型の実行（CI、`--no-input`）では必須です。このリポジトリとターゲットに固有で、再試行時にも同じキーを使える値を指定してください。たとえば `$GITHUB_RUN_ID-$REPOSITORY-$SITE_ID` を使うと、再試行時に新しいアプリを作成せず、元のアプリを再現できます。
`--skip-clone`	ローカルにクローンせずにアプリを作成します。ファイルシステムには何も書き込まれず、代わりにアプリ ID と環境 ID が出力されます。
`--json`	インポートパス専用です。スキャフォールドパスにはシリアライズする単一のレスポンスオブジェクトがありません。
`--dry-run`	スキャフォールドパスと共通です。副作用なしで検証とプレビューを行います。

リポジトリ内で見つかった siteId がターゲットの選択に使われることはありません。--site-id または --new を明示的に指定する必要があります。

インポート専用フラグ（--branch、--idempotency-key、--skip-clone、--json）は、--import が指定されていない場合、無視されるのではなく拒否されます。同様に、--import と併用した場合は --framework／--workspace-id／--project-name が拒否されます（リポジトリには独自のコードがあり、ワークスペースはトークンから決定されます）。拒否理由には、問題のあるフラグが missingFlag に機械可読形式で記載されるため、エージェントは説明文を解析せずに呼び出しを修正できます。

# Attach an existing repo to an existing site at /app
webflow apps init --import https://github.com/acme/site \
  --site-id 6234abc --mount /app --dry-run

webflow apps init --import https://github.com/acme/site \
  --site-id 6234abc --mount /app

# Project app from a repo, CI-safe (note: --idempotency-key required, no --mount)
webflow apps init --import https://github.com/acme/site --new --no-input \
  --idempotency-key "$GITHUB_RUN_ID-acme-site" \
  --branch main --json

# Register the app without touching the local filesystem
webflow apps init --import https://github.com/acme/site --new --skip-clone --json

webflow cloud create（非推奨）

webflow cloud create <name> は引き続き動作しますが、非推奨の警告が表示され、将来のメジャーリリースで削除される予定です。サイトに紐付けるモードではマウント先が /app に固定され、apps init の機能の一部しか利用できません。常に apps init（アプリモードでは apps init --new）を使用してください。

webflow apps deploy

webflow cloud deploy は apps deploy の非推奨のエイリアスであり、フラグとハンドラーは同一です。 プリフライトフェーズ：ID の解決。 バックエンドを呼び出す前に、apps deploy はプリフライト手順を実行し、サイトに紐付けたデプロイか、プロジェクトアプリの初回デプロイかを解決します。解決の優先順位は次のとおりです（一致した最初の項目が適用されます）。

#	ソース	結果
1	`--site-id <id>` フラグ	サイトに紐付けたデプロイ。環境変数とマニフェストを上書きします
2	`--workspace-id <id>` フラグ	プロジェクトアプリの初回デプロイ。環境変数とマニフェストを上書きします。`--site-id` とは相互排他的です
3	`WEBFLOW_SITE_ID` 環境変数	サイトに紐付けたデプロイ（読み取り専用。`webflow.json` には書き戻されません）
4	`manifest.siteId`（`webflow.json` から取得）	サイトに紐付けたデプロイ
5	`WEBFLOW_WORKSPACE_ID` 環境変数	プロジェクトアプリの初回デプロイ（読み取り専用。永続化されません）
6	`manifest.cloud.workspace_id`	プロジェクトアプリの初回デプロイ
7	一致なし + `--no-input`	必要なフラグを示す致命的なエラー
8	一致なし、対話モード	選択肢：新しいアプリを作成／既存のサイトに紐付け／キャンセル

環境変数はマニフェストより優先され、サイトはワークスペースより優先されます。 どちらも重要です。エクスポートされた WEBFLOW_SITE_ID は manifest.siteId を上書きし、サイトが解決されるとワークスペースの解決は試行されずに終了します。そのため、環境内の古い WEBFLOW_SITE_ID が、プロジェクトアプリのデプロイ用に設定されたマニフェストよりも暗黙に優先されます。意図した動作でない場合は、この環境変数を解除するか、--workspace-id を明示的に渡してください。

このプリフライトフェーズは、ID が確定する前にプロジェクトアプリのデプロイ経路が実行され、Cloud アプリがプロビジョニングされるのを防ぐためのものです。以前のバージョンでは、その後の手順が失敗すると、新しい Webflow サイトが孤立する可能性がありました。

可能な限り、--site-id または --workspace-id を明示的に指定してください。 これにより、書き込み途中のマニフェストに対処でき、apps init が残した状態に依存せずに済みます。サイトに紐付ける場合は --site-id を指定してください。プロジェクトアプリの初回デプロイでは、--workspace-id を指定してください。

未初期化のプロジェクト（siteId、workspace_id、フラグのいずれもなし）の場合、CLI は新しいプロジェクトアプリの作成、既存サイトへの紐付け、またはキャンセルをユーザーに確認します。--no-input を指定すると、必要なフラグを示す致命的なエラーになります。--no-input で実行するエージェントは、未初期化プロジェクトの初回デプロイ時に、必ず --site-id または --workspace-id を指定する必要があります。

デプロイ方法は 2 つあります。GitHub 連携デプロイを推奨します。CI の設定は不要です。一度ダッシュボードを設定すれば（CLI では設定できません）、接続したブランチへのプッシュごとにデプロイが実行されます。

オプション 1（推奨）：GitHub 連携デプロイ 一度ダッシュボードで設定すれば、接続したブランチへのプッシュのたびにデプロイが実行されます。CLI コマンドもワークフローファイルも不要です。設定はダッシュボードでのみ行えます。CLI だけではこの状態にできません。 リポジトリを GitHub にプッシュしただけでは、プッシュ時のデプロイは有効になりません。

プロジェクトを GitHub にプッシュします（ユーザーは少なくとも 1 つのコミットをプッシュしている必要があります）
ユーザーに Webflow ダッシュボードを開くよう伝えます → ユーザーの Cloud アプリ → Settings → Git の順に移動し、まだ接続していない場合は GitHub アカウントを接続します
リポジトリを選択し、デプロイ元のブランチ（例：main）を選択します
確認します。接続を検証するため、ダッシュボードが初回デプロイを自動的に実行します
以降は、接続したブランチへの git push でデプロイされます

ステップ 2〜4 はスクリプトでは実行できません。ユーザーがプッシュ時のデプロイを希望する場合、ダッシュボードで一度クリックして設定する必要があります。それ以降、このプロジェクトに関するエージェントの作業は基本的に完了です。今後はプッシュ時にデプロイされます。

ユーザーにデプロイの設定を提案するときは、必ず最初にこの方法を案内してください。ネイティブの GitHub 連携では対応できないカスタムの前後処理、シークレットの注入、複数環境のロジックが必要な場合に限り、GitHub Actions を提案してください。

オプション 2：GitHub Actions（手動 CI/CD）

カスタムのビルド手順、環境固有のシークレット、またはネイティブの GitHub 連携ではサポートされていないデプロイゲートが必要な場合に使用します。Examples セクションの GitHub Actions の例を参照してください。

オプション 3：ローカル／手動デプロイ

開発や単発のデプロイに使用します。

webflow apps deploy \
  --no-input \
  --mount / \
  --environment main \
  --skip-mount-path-check \
  --skip-update-check

apps deploy のすべてのフラグ：

フラグ	短縮形	説明
`--no-input`	—	CI モードです。以下のコールアウトで説明するプロジェクト選択プロンプトを除き、ほとんどのプロンプトを無効にします。
`--mount <path>`	`-m`	マウントパスです。`--no-input` と必ず併用してください。強制されません。省略してもエラーにはならず、ルート（`/`）に暗黙的にデプロイされます。`webflow.json` から自動で読み込まれることはありません。以下の警告を参照してください。
`--environment <env>`	`-e`	環境名です。存在しない場合は作成します。`--mount` と併用する必要があります。
`--app-name <name>`	`-n`	`webflow.json` に `cloud.app_id` がない場合、`--no-input` を指定した初回デプロイで必須です。プロジェクトアプリの初回デプロイでは、3～39 文字で指定する必要があります。
`--project-name <name>`	—	`--app-name` の非推奨の別名です。引き続き使用できます。
`--site-id <id>`	`-s`	サイトに紐づけたデプロイに使用する Webflow サイト ID です。`webflow.json` の `siteId` を上書きします。`--workspace-id` とは同時に指定できません。JSON を編集せずに、部分的にしか書き込まれていないマニフェストから復旧する場合に使用します。
`--workspace-id <id>`	`-w`	プロジェクトアプリの初回デプロイに使用するワークスペース ID です。`webflow.json` の `cloud.workspace_id` を上書きします。`--site-id` とは同時に指定できません。
`--app-id <id>`	`-a`	クラウドアプリ ID です。アプリ選択を省略します。`webflow.json` の `cloud.app_id` を上書きします。
`--project-id <id>`	—	`--app-id` の非推奨の別名です。引き続き使用できます。
`--framework <fw>`	`-f`	フレームワークの検出結果を上書きします。`nextjs`、`astro`、`vite`、`static` のいずれかを指定する必要があります。値は `webflow.json` に書き戻されます。`package.json` からの自動検出が不確実な場合（モノレポ、依存関係の不足など）に使用します。
`--directory <path>`	`-d`	アプリのディレクトリです（デフォルト：cwd）。モノレポで使用します。
`--description <text>`	—	初回デプロイ時のアプリの説明です。
`--skip-mount-path-check`	—	ドメインマニフェストの検証をスキップします。CI では必須です。`webflow.json` で `cloud.skipMountPathCheck: true` として設定することもできます。
`--auto-publish`	—	マウントパスのルーティングを同期するため、Webflow のサイトを公開します。アプリのデプロイには影響しません。
`--skip-update-check`	—	@webflow パッケージの更新確認をスキップします。
`--dry-run`	—	`apps deploy` のみで使用できます。`cloud deploy` エイリアスでは使用できません。フラグ／環境変数／`webflow.json` からすべてを解決し、ネットワーク呼び出しを行わず、実行した場合に `create`／`select`／`deploy` のどれが行われるかを報告します。
`--json`	—	`apps deploy` のみで使用できます。`cloud deploy` エイリアスでは使用できません。ビルド／アップロードの進行状況テキストの代わりに、成功時は `{appId, environmentId, deploymentId, deployUrl}`（古いバックエンドでは `deployUrl` は `null`）、失敗時はエラードキュメント、`--dry-run` と併用した場合はドライランの計画を、1 つのドキュメントとして出力します。

# Preview what a deploy would do, no side effects
webflow apps deploy --no-input --mount /app --environment main --site-id site_abc123 --dry-run --json

# Deploy and parse the result instead of scraping progress output
webflow apps deploy --no-input --mount /app --environment main --site-id site_abc123 --json

エージェント：毎回、--mount と --environment を必ず一緒に渡してください。 デプロイ時のプロンプト（既存のアプリを選択、新しいアプリに名前を付ける、環境を選択）は、--no-input の有無ではなく、--mount と --environment の_両方_が設定されているかどうかで制御されます。両方を指定せずに --no-input を渡すと、アプリ選択プロンプトが表示されたままになり、非 TTY 環境では処理が停止します。エージェントが安全にデプロイするために必要な最小限のフラグの組み合わせは、--no-input --mount <path> --environment <env> --site-id <id>（プロジェクトアプリの初回デプロイでは --workspace-id <id>）、および webflow.json に cloud.app_id がない場合は --app-name です。

⚠️ --no-input でのデプロイ時に --mount を省略すると、警告なしでルートにデプロイされます。 これはデプロイ先を誤るリスクであり、致命的なエラーではありません。エラーも警告も発生しません。マウントのプロンプトには /app のデフォルト値がありますが、バリデーターはありません。入力なしのパスではバリデーションを通過するデフォルト値だけが返されますが、バリデーターがない場合は何も返されず、最終的に / に正規化されます。ルートは有効なマウント先なので、そこにデプロイが進みます。非対話型の実行では、/app のデフォルト値に頼らず、毎回 --mount を明示的に渡してください。 これが、後述の ENVIRONMENT_MOUNT_MISMATCH の原因として「デフォルトのマウントを想定する」ことが挙げられている理由でもあります。原因となったフラグから離れた別のレイヤーで、後になってエラーが表面化するためです。

アプリの管理

既存の Cloud アプリを調査、操作するコマンドです。init / deploy を補完します。

ワークスペースはサーバー側で決定されます。 すべての読み取りコマンドは OAuth トークンからワークスペースを特定します。いずれのコマンドにも --workspace-id フラグはなく、ワークスペースを尋ねるプロンプトも表示されません。
ID の解決。 appId と envId は、共通リゾルバーによって次の順序で解決されます：明示的な引数／フラグ → 環境変数（WEBFLOW_APP_ID / WEBFLOW_APP_ENVIRONMENT_ID）→ webflow.json（cloud.app_id / cloud.environment_id、旧形式の cloud.project_id をフォールバックとして使用）→ 対話型 TTY プロンプト。アプリのディレクトリ内で実行する（そのため webflow.json から ID が解決される）のが一般的ですが、必須ではありません。
自動選択と --no-input の仕様。 ID が指定されていない場合、選択機能はワークスペースにアプリが 1 つだけある場合、またはアプリに環境が 1 つだけある場合に、その項目を自動選択します。そのため、アプリと環境がそれぞれ 1 つだけの構成では、CI を含め、非対話型で動作します。複数ある場合にコマンドがプロンプトを表示できない（--no-input、CI=true、TTY なし、または --json）と、エラーに機械可読な missingFlag を含めて 0 以外の終了コードで終了します。これにより、エージェントはフラグを指定して再実行できます。人間向けのエラーメッセージの例は、Missing required appId. Pass --app-id, set WEBFLOW_APP_ID, or add it to webflow.json. です。

missingFlag には 2 つの形式があります。両方に対応してください。 リゾルバーのエラーではフラグ記号のないキー（appId、environmentId、depId、yes）が示されます。apps init でフラグの互換性がない場合は、フラグの表記（--import、--site-id、--mount、--new）が示されます。形式が一方だと決めつけず、照合前に正規化してください（先頭の -- を取り除き、大文字と小文字を区別せずに比較します）。どちらの場合も、値は追加または削除するフラグを示します。相互に排他的なフラグの組み合わせでは、削除するフラグが示されるため、エラーに表示されたフラグを追加して再試行すると、いつまでも同じエラーが繰り返されます。
--json。 すべてのコマンドで --json を使用できます。生の API レスポンスを出力し、--fields は無視します。プログラムから解析する場合に使用してください。また、--json を指定すると、Using … from webflow.json の情報行も抑制されます。
--fields <comma-list>。 読み取りコマンドはテーブルを表示し、--fields で表示する列を指定できます（無効なフィールド名はネットワーク呼び出しの前にエラーになります）。各コマンドのデフォルトのフィールドと全フィールドは、以下に記載されています。

フィルターの動作（`list` コマンド）

apps list、apps environments list、apps env-vars list は、共通のフィルターモデルを使用します。

完全一致フィルター（--name、--branch、--key、--site、--status）は、大文字と小文字を区別して完全一致で照合します。
--q は、リソースの主要な名前フィールドのみを対象とする、大文字と小文字を区別しない部分一致（contains）です。対象はアプリ名、環境ブランチ、変数キーです。IDや変数の値は検索しません。候補を探すときに使用し、単一の項目を特定するときは完全一致フィルターを使用してください。
**複数のフィルターは AND 条件で結合されます。**完全一致フィルターと一致しない --q を併用すると、**空のページが返されます。これは、リソースが存在しないという意味ではなく、すべてのフィルターに一致するものがなかったという意味です。**フィルター適用後のページが空でも、アプリや変数が存在しないと判断しないでください。不在を報告する前に、フィルターを減らして再実行してください。
すべてのフィルター値は空でない必要があります（--q "" は何もしない指定ではなく、使用方法エラーです）。

apps list

ワークスペース内のすべてのアプリを一覧表示します。--fields のデフォルトは id,name,siteId,createdAt です（すべてのフィールド：id,name,description,siteId,appPath,sourceUrl,createdAt,siteName,shortName）。

フィルター：--site <site-id>（サイト ID の完全一致）、--name <name>（大文字と小文字を区別する完全一致）、--q <text>（アプリ名の大文字と小文字を区別しない部分一致）。

アプリ名はサイト内でのみ一意です。--name だけでは複数のサイトにあるアプリが一致する場合があり、--site だけでは多くのアプリが一致する場合があります。アプリを最大 1 つに絞り込むには、--site と --name を併せて指定してください。

--site は意図的に webflow.json の値をデフォルトとして使用しません。フィルターなしの apps list は、マニフェストのサイトに暗黙的に絞り込むのではなく、トークンから参照できるすべてのアプリを返します。

webflow apps list --json

# Resolve one app by name within a known site
webflow apps list --site 6234abc --name "Marketing" --json

# Discover apps whose name contains "mark" (case-insensitive)
webflow apps list --q mark --json

apps get [appId]

1 つのアプリの詳細を表示します。appId のデフォルトは webflow.json / WEBFLOW_APP_ID です。--fields のデフォルトは id,name,description,siteId,appPath,createdAt です（すべてのフィールド：id,name,description,siteId,appPath,sourceUrl,createdAt,siteName,shortName — apps list と同じフィールド一式です）。sourceUrl は、接続されている場合の GitHub リポジトリです（apps update --github-source を参照）。

webflow apps get app_abc123 --json

apps domains [appId]

アプリのドメインと公開 URL を表示します。--fields のデフォルトは id,url,lastPublished です（すべてのフィールドに fullSiteCompiledAt を追加）。

ページネーションに対応しています。--limit <n>（サーバー側の上限は 100）と、前のページの nextCursor から取得した --cursor <cursor> を指定します。ページを取得する際は、各ページで同じ --limit と、デフォルト以外の --fields を再指定してください。

webflow apps domains app_abc123 --json
webflow apps domains app_abc123 --limit 50 --cursor "$NEXT_CURSOR" --json

apps environments list [appId]

アプリの環境を一覧表示します。--fields のデフォルトは id,branch,publicUrl,latestDeploymentStatus,createdAt です（すべてのフィールド：id,branch,mount,publicUrl,latestDeploymentStatus,lastDeploymentSucceededAt,lastVariableModifiedAt,createdAt,updatedAt）。

**mount はテーブルのデフォルト項目に含まれません。**環境のマウントパスを確認するには、--json（API の完全な形式を返し、--fields を無視します）を使用するか、--fields id,branch,mount で明示的に指定してください。デフォルトの environments list テーブルには表示されません。

フィルター：--branch <branch>（大文字と小文字を区別する完全一致。ブランチはアプリごとに一意のため、環境を最大 1 つに絞り込みます）、--q <text>（ブランチの大文字と小文字を区別しない部分一致。候補の検索に使用します）。

webflow apps environments list app_abc123 --json

# Resolve the environment that builds `main`
webflow apps environments list --branch main --fields id,branch,publicUrl --json

apps deployments list

環境の最新のデプロイを新しい順に一覧表示します。appId 引数は不要です。WEBFLOW_APP_ID／WEBFLOW_APP_ENVIRONMENT_ID、webflow.json、またはピッカーからアプリと環境を解決します。--limit のデフォルトは 20 です。--fields のデフォルトは id,status,sourceType,commitHash,buildStartedAt です。

フィルター：--status <status>（下記の列挙値のいずれかと完全一致する必要があります。不正な値はネットワーク呼び出しの前に CLI によって拒否されます）。前のページの nextCursor を指定して --cursor でページネーションします。各ページで同じ --limit、--status、およびデフォルト以外の --fields を再指定してください。

webflow apps deployments list --limit 20 --json

# Most recent failed build
webflow apps deployments list --status failed --limit 1 --json

apps deployments get <depId>

1 件のデプロイの詳細を表示します（位置引数 <depId> は必須です）。アプリと環境は deployments list と同じ方法で解決されます。--fields のデフォルトは id,status,sourceType,commitHash,buildStartedAt です。

--wait は、デプロイが終端ステータス（success／failed／canceled／unstaged）に達するかタイムアウトするまで待機し、成功時は 0、それ以外は 1 で終了します。そのため、独自のポーリングループを用意しなくても CI のゲートとして機能します。--interval <seconds> でポーリング間隔を設定できます（5 秒未満は 5 秒に切り上げ）。--timeout <seconds> で待機時間の上限を設定できます（最大 30 分）。

webflow apps deployments get dep_abc123 --json

# Block until the build finishes; non-zero exit fails the CI step
webflow apps deployments get dep_abc123 --wait --interval 10 --timeout 900 --json

apps deployments redeploy <depId>

既存のデプロイを同じコミットで再実行し、新しいビルドをキューに追加します。**ロールバックするには、以前に成功したデプロイの ID を指定して再デプロイしてください。**アプリと環境は deployments list と同じ方法で解決されます。--dry-run でプレビューできます。

GitHub に接続されたアプリが必要です。apps deploy でローカルファイルからデプロイされたアプリは対象外です。再実行するコミットがないためです。

--idempotency-key <key> を指定すると、Idempotency-Key ヘッダーを送信するため、再試行時に重複が排除され、2 つ目のビルドがキューに追加されるのを防げます。指定する場合は、空でない印字可能な ASCII 文字列（制御文字、改行、非 ASCII 文字を含まないもの）が必要です。重複排除なしで実行するには、このフラグを省略してください。

**--wait（deployments get --wait と同じ動作）。**ビルドのキュー追加ではデプロイ ID がない 202 だけが返されるため、--wait はまずキュー追加の前後で環境のデプロイ一覧を比較して新しいデプロイを特定し、そのデプロイが終端ステータスに達するまで待機します。成功時は 0、それ以外は 1 で終了します。--interval <seconds>（5 秒未満は 5 秒に切り上げ）と --timeout <seconds>（最大 30 分）でポーリングを調整できます。これは get と同様です。デプロイをキューに追加してから deployments get で個別にポーリングする代わりに、このコマンド 1 つで再デプロイの結果を CI のゲートにできます。

webflow apps deployments redeploy dep_abc123 --dry-run --json
webflow apps deployments redeploy dep_abc123 --idempotency-key "$GITHUB_RUN_ID-redeploy" --json

# Roll back and block until the new build finishes; non-zero exit fails the CI step
webflow apps deployments redeploy dep_abc123 --wait --interval 10 --timeout 900 --json

# Roll back: find the last success, then redeploy it
webflow apps deployments list --status success --limit 1 --fields id --json

apps deployments trigger

解決された環境の現在の HEADをオンデマンドでビルドします。redeploy と同様ですが、<depId> は不要です。再実行する過去のデプロイはなく、環境に設定されたブランチが現在指しているものをビルドします。--dry-run でプレビューできます。--idempotency-key の仕様は redeploy と同じです。

redeploy と同様に、GitHub に接続されたアプリが必要です。

チェックアウト中のブランチではなく、環境に設定されているブランチをビルドします。両者が異なる場合、CLI は警告しますが、処理を中断することはありません。どのブランチが実際にビルドされるか不明な場合は、先に apps environments list --fields id,branch を確認してください。

redeploy および deployments get と同じ --wait／--interval／--timeout の仕様です。trigger も 202 のみを返すため、--wait はポーリングを開始する前に、キューに追加されたデプロイを特定します。

webflow apps deployments trigger --dry-run --json
webflow apps deployments trigger --json

# Build current HEAD and block until it finishes; non-zero exit fails the CI step
webflow apps deployments trigger --wait --interval 10 --timeout 900 --json

apps logs build <depId>

デプロイのビルドログです。depId は必須です — CLI は最新のデプロイを代わりに使用しません。省略すると、認証前にすぐエラーになり、機械可読な missingFlag: "depId" が返されます。まず apps deployments list を実行して ID を確認してください。--fields のデフォルトは timestamp,message です（すべてのフィールド：timestamp,message,phase）。

フィルター：--since <iso>（ISO 形式の日時以降のログのみ）、--q <substr>（メッセージの部分一致）、--limit <n>（デフォルトは 100）、--cursor <cursor>（前の nextCursor から取得したページネーションカーソル）。--level フィルターはありません。ページを取得する際は、毎回同じ --limit、デフォルト以外の --fields、--since、--q を再指定してください。

# Find a deployment ID first — `logs build` will not guess one
webflow apps deployments list --limit 1 --fields id --json

webflow apps logs build dep_abc123 --since 2026-07-14T00:00:00Z --q error --limit 100 --json

apps logs runtime [envId]

環境のランタイムログです。[envId] はアプリの環境が1つだけの場合、その環境をデフォルトで使用します。アプリに複数の環境があり、どれも指定されていない場合、CLI は TTY でプロンプトを表示します。プロンプトを表示できない場合（--no-input、CI=true、TTY なし、または --json）は、missingFlag: "environmentId" でエラーになります — その場合は環境を明示的に指定してください（引数、WEBFLOW_APP_ENVIRONMENT_ID、または cloud.environment_id）。フィルターは logs build と同じです（--since、--q、--limit、--cursor。--level はありません）。また、ページごとにフィルターを再指定するルールも同じです。

webflow apps logs runtime env_abc123 --q timeout --json

両方のログコマンドでのページネーション：レスポンスには nextCursor（base64url。すべて取得済みの場合は null）が含まれます。これをそのまま --cursor に渡すと、次のページを取得できます。

apps env-vars

Cloud アプリ環境の変数を、対話なしで管理します。4つのサブコマンドすべてで --app-id と --environment-id（共有リゾルバーを通じて webflow.json の値をデフォルトで使用）および --json を使用できます。シークレット値が出力、ログ、テレメトリに表示されることはありません — サーバーは読み取りのたびにシークレットをマスクして返し、CLI がマスクを解除することもありません。

apps env-vars list — --fields のデフォルトは key,isSecret です（すべてのフィールド：key,isSecret,value,id,environmentId）。デフォルトでは value は除外されます。--fields value を指定しても、シークレット値はマスクされた状態で返されます。

フィルター：--key <key>（完全一致、大文字と小文字を区別 — 最大1つの変数に解決されます。値が返されることはありません）および --q <text>（キーに対する、大文字と小文字を区別しない部分一致）。--q で値を検索することはできません — 設計上、環境変数の内容を検索する方法はありません。

webflow apps env-vars list --json

# Check whether one key is set, and whether it's a secret
webflow apps env-vars list --key API_KEY --json

apps env-vars set <key> [value] — 変数を1つ作成または更新します。[value] は省略できます。省略した場合は、パイプされた stdin から読み取るか、プロンプトで入力します（シークレットの場合に推奨。シェルの履歴に残りません）。--secret は値を暗号化します（省略した場合、既存のキーのシークレット設定は維持されます）。--dry-run は書き込みを行わずにプレビューします。

webflow apps env-vars set API_URL https://api.example.com --json
# secret — value read from stdin/prompt, never echoed:
printf '%s' "$TOKEN" | webflow apps env-vars set API_KEY --secret --json

apps env-vars delete <key> — 変数を1つ削除します。--dry-run はプレビューします。

webflow apps env-vars delete API_KEY --json

apps env-vars import <file> — .env（KEY=value）ファイルから一括で作成または更新します。--secret はファイル内のすべてのキーをシークレットとして設定します。--dry-run はプレビューします（値は KEY=******** と表示され、平文では表示されません）。キーごとの失敗は報告され、終了コードはゼロ以外になります。

webflow apps env-vars import .env.production --secret --json

apps environments create [appId]

アプリに環境を作成し、ブランチに紐付けてマウントパスで提供します。--branch と --mount はどちらも必須です。--dry-run はプレビューします。

デプロイは行われません — 環境は空の状態で開始します。 その後、apps deployments trigger を実行してビルドしてください。

--branch <branch> — この環境のビルド元となる Git ブランチです。有効なブランチ名である必要があり、このアプリの他の環境で使用されていないものでなければなりません。
--mount <path> — 環境を提供する URL パス（例：/app）です。サイト内で一意である必要があります。
--idempotency-key <key> — 任意の、再試行しても安定したキー（リクエストの requestId として送信）です。作成処理の再試行時に重複を防ぎます。deployments redeploy と同じ、印字可能な ASCII 文字に関するルールが適用されます。

webflow apps environments create --branch staging --mount /staging --dry-run --json
webflow apps environments create --branch staging --mount /staging --json
webflow apps deployments trigger --json   # the environment is empty until you do this

apps environments update [appId] [envId]

環境の --branch と --mount のいずれか、または両方を更新します（少なくとも1つが必須です）。一意性に関するルールは create と同じです。位置引数、WEBFLOW_APP_ID / WEBFLOW_APP_ENVIRONMENT_ID、webflow.json、または選択画面からアプリと環境を解決します。または、明示的な --app-id / --environment-id フラグでも指定できます。--dry-run で変更内容をプレビューできます。

デプロイは行いません。 --branch を変更した後は、apps deployments trigger を実行して新しいブランチをビルドしてください。実行するまでは、環境では引き続き古いビルドが配信されます。

webflow apps environments update --branch release --dry-run --json
webflow apps environments update env_abc123 --mount /v2 --json

apps environments delete [appId] [envId]

アプリから環境を削除します。アプリと環境の解決方法は environments update と同じです。確認が必要です。プロンプトを省略するには --yes を指定してください。非対話モードでこれを指定しない場合、削除せずに missingFlag: "yes" を返します。--dry-run で変更内容をプレビューできます。

webflow apps environments delete env_abc123 --dry-run --json
webflow apps environments delete env_abc123 --yes --json

apps link [appId]

webflow.json を書き込み、現在のディレクトリを既存のアプリと環境に紐付けます。アプリの検証は行いますが、作成もデプロイも行いません。新しいクローンからアプリを引き継ぐ場合や、ディレクトリを別のアプリ／環境に付け替える場合に使用します。--dry-run でマニフェストの変更をプレビューできます。

位置引数の [appId] は、--app-id、WEBFLOW_APP_ID、webflow.json より優先されます。環境は --environment-id で選択します。

ワークスペース ID が保存されるのは、--workspace-id を明示的に渡した場合のみです。アプリから取得または検証できないため、CLI は推測せず、指定された値を書き込みます。

webflow apps link app_abc123 --environment-id env_abc123 --dry-run --json
webflow apps link app_abc123 --environment-id env_abc123 --json

apps update [appId]

アプリの --name、--description、--github-source のいずれか、または複数を更新します（少なくとも1つが必須です）。--dry-run で変更内容をプレビューできます。appId のデフォルト値は webflow.json / WEBFLOW_APP_ID から取得されます。

--github-source <repo-url> は、リポジトリがまだ紐付けられていないアプリにリポジトリを追加するか、すでに別のリポジトリが紐付けられている場合に付け替えます。https://github.com/<owner>/<repo> の形式で指定してください。また、次の点に注意してください。

デプロイは行いません。 新たに紐付けたリポジトリからビルドするには、その後 apps deployments trigger を実行してください。
リポジトリの所有者に Webflow GitHub App がインストールされ、このワークスペースに接続されている必要があります。これは apps init --import と同じ前提条件です。
環境でビルドするブランチを変更する場合は、このフラグではなく apps environments update --branch を使用してください。--github-source はリポジトリを選択し、環境はブランチを選択します。

--json の出力： --dry-run の場合は変更計画です。実際に変更するキーのみが含まれ、dryRun: true も追加されます。そのため、名前のみを更新する場合、計画に githubSource キーは含まれず（null にはなりません）、実行時は 更新後のアプリオブジェクト全体（apps get --json と同じ形式）が出力されます。

webflow apps update app_abc123 --name "New Name" --description "Marketing site app" --json

# Attach a repo, then build it
webflow apps update app_abc123 --github-source https://github.com/acme/site --json
webflow apps deployments trigger --json

apps delete [appId]

アプリを削除します（またはアーカイブします。どちらになるかはサイトの種類に応じてサーバーが決定します）。確認が必要です。プロンプトを省略するには --yes を指定してください。非対話モード（--no-input / --json）で --yes を指定しない場合、削除せずに missingFlag: "yes" を返します。--dry-run では削除せずに影響をプレビューできます。

--json の出力： ドライランと実行時のどちらも 同じドキュメント形式（{ appId, name, action: "archive" | "hard_delete", siteId, siteName, permanent, dryRun, message }）であるため、どちらにも同じパーサーを使用できます。ドライランでは、name / siteId / siteName / action / permanent を埋めるために、まずアプリを読み込みます。実際の --json 実行では、必ず --yes が必要で（上記を参照）、この読み込みを完全に省略するため、name、siteId、siteName は常に null となり、action は削除レスポンスそのものから取得されます。message はドライランでは null で、実際に削除が行われると値が設定されます。

webflow apps delete app_abc123 --dry-run --json
webflow apps delete app_abc123 --yes --json

フレームワーク

フレームワーク	初期化時のスキャフォールド	デプロイ対応	パッケージによる検出
`nextjs`	✓（スタンドアロン＋サイト連携）	✓	`@opennextjs/cloudflare`
`astro`	✓（スタンドアロン＋サイト連携）	✓	`@astrojs/cloudflare`
`vite`	✓（スタンドアロン＋サイト連携）	✓	`vite`
`static`	✓（スタンドアロンのみ）	✓	該当なし — 下記を参照

cloud.framework に上記以外の値を指定すると、apps deploy はコード 1 で終了します。

static がスキャフォールドできるのはスタンドアロンアプリのみです — apps init --new --framework static は動作しますが、apps init --site-id ... --framework static（サイト連携）は動作せず、サイト連携型の static スキャフォールドはありません。既存の static プロジェクト（ビルド済み、または手書き）の場合、デプロイ時の検出にスキャフォールドは不要です。ルートに index.html があり、package.json がないディレクトリは static として自動検出されます（アセットのみ、ビルドなし、ワーカーなし）。また、webflow.json に明示的な { "cloud": { "framework": "static" } } を指定すると、ビルド／ランタイム関連ファイルが存在する場合でも、常にこれが優先されます。index.html とビルド／ランタイムの判定要素がある一方で、明示的な framework がないディレクトリは、推測されずに拒否されます。解釈を明示するには、cloud.framework を宣言してください。

スキャフォールドは初期化時に GitHub から取得されます。 CLI は Webflow-Examples/hello-world-{astro,nextjs,vite,static-app}* からスキャフォールドの tarball をダウンロードします（サイト連携型スキャフォールドは対応する *-devlink リポジトリから取得します）。それぞれ、インストール済み CLI が想定するバージョン付き（vN）ブランチに固定されています。そのため、apps init には github.com へのネットワークアクセスが必要です。各リリースは互換性のあるスキャフォールドブランチに固定されているため、古い CLI のインストールも引き続き動作します。

グローバルフラグ

フラグ	説明
`--no-input`	すべての対話型プロンプトを無効にします。CI／自動化で必要です。`CI=true` の場合、または TTY が検出されない場合は自動的に有効になります。
`--manifest <path>`	`webflow.json` のカスタムパスです。モノレポで使用します。
`--skip-update-check`	@webflow パッケージの更新確認をスキップします。代わりに、`WEBFLOW_SKIP_UPDATE_CHECKS=true` を設定することもできます。
`--verbose`	デバッグ用に、より多くの情報を表示します。

出力

apps deploy が成功すると、CLI は 2 種類の出力を表示します。

1. デプロイダッシュボードの URL — 成功時は常に表示されます。

https://webflow.com/dashboard/sites/{siteId}/webflow-cloud/projects/{appId}/environments/{environmentId}/deployments/{deploymentId}

これは必ずユーザーに提示してください。ここから、ビルドログ、デプロイ状況、履歴、環境設定を確認できます。

2. 公開アプリの URL — 条件付きで表示されます。

🌐 Your cloud app will soon be available at:
   https://{your-site}.webflow.io/{mount-path}

実際の URL が表示された場合は、公開アプリへのリンクとしてユーザーに提示してください。ドメインはユーザーの Webflow サイトのドメインで、パスはデプロイ時に使用した --mount の値（例：/、/app、またはユーザーが選択したその他のパス）です。後から webflow apps domains --json を使って、プログラムから公開 URL を取得することもできます。

出力が No domains found with the correct mount path configuration yet. の場合は、公開 URL を提示せず、状況の確認とドメイン設定のため、上記のダッシュボードのデプロイリンクを案内してください。

デプロイを確認するために、どちらの URL も取得したり curl したりしないでください — CLI が表示した内容をそのまま返してください。状況をプログラムから確認するには、代わりに webflow apps deployments list --json または webflow apps logs build --json を使用してください。

例

完全なワークフロー：スキャフォールド → GitHub → ダッシュボードで接続 → プッシュしてデプロイ（推奨）

CLI で手順 1 と 2 を実行します。**手順 3 は Webflow ダッシュボードで行う必要があります。CLI では実行できません。**手順 3 を行わないと、GitHub にプッシュしてもデプロイされません。

# 1. Scaffold locally (CLI)
webflow apps init --new --no-input \
  --app-name my-app \
  --framework nextjs \
  --workspace-id ws_abc123

# 2. Push to GitHub (CLI / git)
git init && git add . && git commit -m "init"
git remote add origin https://github.com/your-org/my-app.git
git push -u origin main

# 3. Connect in the Webflow dashboard (manual, dashboard-only):
#    a. Open the Cloud app → Settings → Git
#    b. Connect the GitHub account (if not already), pick the repo
#    c. Pick the branch to deploy from (e.g. main)
#    d. Confirm — the dashboard runs an initial deploy to verify the wiring
#
# After step 3, every push to the selected branch triggers a deploy automatically.
# Skip step 3 and push-to-deploy is NOT active — deploys must be manual or CI-driven.

プロジェクトアプリのワークフロー：init → 初回デプロイでサイトをプロビジョニング

# Agent-safe init — assumes the token sees a single workspace.
# If the token sees multiple workspaces, ask the user to run this command locally first.
webflow apps init --new --no-input \
  --app-name my-app \
  --framework astro

# First deploy creates site + app + environment on the backend,
# writes siteId / app_id / environment_id back to webflow.json,
# and writes WEBFLOW_SITE_ID to .env. Subsequent deploys are normal.
cd my-app
webflow apps deploy --no-input \
  --app-name my-app \
  --mount / \
  --environment main \
  --skip-update-check

サイトに接続された Astro アプリをローカルでスキャフォールドする

webflow apps init \
  --no-input \
  --app-name my-site-app \
  --framework astro \
  --mount /app \
  --site-id site_abc123

既存のアプリと最新のデプロイを確認する

# Which apps can this token see?
webflow apps list --json

# Details + live URLs for one app (or omit the ID inside the app dir)
webflow apps get app_abc123 --json
webflow apps domains app_abc123 --json

# Most recent deployments (newest first), then drill into one
webflow apps deployments list --limit 5 --json
webflow apps deployments get dep_abc123 --json

# Block until a build reaches a terminal status (exit 0 = success, 1 = not)
webflow apps deployments get dep_abc123 --wait --interval 10 --timeout 900 --json

# Read that deployment's build log, filtered. `logs build` requires the ID —
# it will not fall back to the latest deployment.
webflow apps logs build dep_abc123 --q error --json

環境変数を管理する

# Non-secret value inline
webflow apps env-vars set PUBLIC_API_URL https://api.example.com

# Secret value piped from stdin (stays out of shell history / logs)
printf '%s' "$DB_PASSWORD" | webflow apps env-vars set DB_PASSWORD --secret

# Bulk import a .env file, all keys secret; preview first
webflow apps env-vars import .env.production --secret --dry-run
webflow apps env-vars import .env.production --secret

# List (secrets shown masked) and delete
webflow apps env-vars list --json
webflow apps env-vars delete OLD_KEY

GitHub Actions CI/CD パイプライン（カスタム手順が必要な場合）

name: Deploy to Webflow Cloud

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      # Pin an exact version in CI: the @latest tag moves without notice.
      - name: Install Webflow CLI
        run: npm install -g @webflow/webflow-cli@latest

      - name: Deploy
        run: |
          webflow apps deploy \
            --no-input \
            --mount / \
            --environment main \
            --skip-mount-path-check \
            --skip-update-check
        env:
          WEBFLOW_API_TOKEN: ${{ secrets.WEBFLOW_API_TOKEN }}
          WEBFLOW_SITE_ID: ${{ secrets.WEBFLOW_SITE_ID }}
          # For project apps pre-first-deploy, omit WEBFLOW_SITE_ID

手動デプロイ（ローカル／単発）

webflow apps deploy \
  --no-input \
  --app-name my-app \
  --mount / \
  --environment main \
  --skip-mount-path-check \
  --skip-update-check

エラーハンドリング付きの手動デプロイ

webflow apps deploy --no-input --mount / --skip-mount-path-check --skip-update-check
if [ $? -ne 0 ]; then
  echo "Deploy failed. Log file:"
  webflow log
  exit 1
fi

ガイドライン

CI での Init と Deploy の使い分け

**apps init はローカルで一度だけ行うプロジェクトのセットアップ用です。CI では実行しないでください。**サイト接続モードではブラウザーウィンドウが開きます。ヘッドレス OAuth の手段はありません。ローカルで一度 apps init を実行して結果をコミットし、その後 CI では apps deploy を使用してください。

マウントパス

--no-input を指定する場合、--mount は必ず指定してください。CLI は webflow.json に保存されたマウントパスを読み取りません。
デフォルト値を想定しないでください。/ または /app を想定すると、アプリが別のパスを使用している場合に ENVIRONMENT_MOUNT_MISMATCH が発生します。環境設定にある Webflow ダッシュボードを確認するか、webflow apps environments list --json を実行して mount フィールドを確認してください（mount はデフォルトのテーブルには表示されません。--fields を使う場合は、--fields id,branch,mount のように明示的に指定する必要があります）。

確認ステップを追加しない

--no-input が設定されている場合、apps deploy の前に人による確認ステップを追加しないでください。無人で実行する CI が停止し、不要です。デプロイの処理には、回避すべき組み込みのプロンプトはありません。（例外として、apps delete は設計上、非対話モードで --yes が必須です。）

機械処理には `--json` を優先する

読み取り／管理コマンド（list、get、domains、environments、deployments、logs、env-vars）では、--json を指定し、テーブルを解析するのではなく構造化された出力を解析してください。--json は --fields を無視し、API の全データ形式を返します。

パッケージマネージャー

CLI は、存在するロックファイルにかかわらず、npm のみを使用します。pnpm と yarn のロックファイルは無視され、それらのプロジェクトでは通知なしに npm install が実行されます。

ビルド時のファイル管理

apps deploy の実行中、CLI は 2 つのファイルを一時的に置き換え、成功時または失敗時に元に戻します。

フレームワーク設定（next.config.ts／astro.config.mjs）— clouduser.* に名前を変更し、CLI テンプレートに置き換えた後、元に戻します。
wrangler.json — CLI テンプレートに置き換え（元のファイルは clouduser.wrangler.json に保存）た後、元に戻します。デプロイ中に wrangler.json を変更しないでください。

フレームワークが Astro で、@astrojs/react が存在しない場合、CLI は確認を求めずに npm install --save @astrojs/react を実行します。

Cloudflare バインディング（D1／KV／R2）

CLI はビルド時に wrangler.json のバインディングをマージします。種類ごとの固定上限はありません。ストレージの上限はハードコードされた CLI の件数ではなく、ワークスペースのクラウドストレージ利用資格によって決まります。D1 の場合は、バインディングに migrations_dir を設定してください。CLI がマイグレーションファイルを自動的にコピーします。

エラーハンドリング

CLI は、すべてのエラーで終了コード 1 を返します。終了コードを確認してください。stdout 内の絵文字やテキストパターンで判定しないでください。
管理コマンドでは、（JSON）エラーの missingFlag に、再実行時に指定するフラグ（appId、environmentId、yes）が示されます。
エラーが発生した場合は webflow log を使用して、エラーの完全なトレースを取得してください。

デプロイのバージョン管理

状況	送信されるバージョンタグ
作業ツリーがクリーン	`git@{40-char-hash}`
未コミットの変更あり	`git@{40-char-hash}+dirty`
Git リポジトリ外	`noversion@{ISO-timestamp}`

本番環境にデプロイする前に、すべての変更をコミットしてください。

既知の制限事項

apps deploy には --dry-run と --json がありますが、apps 形式でのみ使用できます — 非推奨のエイリアスである cloud deploy には、どちらもありません。出力形式の詳細は、deploy フラグの表を参照してください。ほかのすべての書き込み操作でも --dry-run を使用できます：apps init（スキャフォールドと --import の両方）、link、update、delete、environments create／update／delete、deployments redeploy／trigger、および env-vars の4つのサブコマンドすべてです。init の --dry-run は apps init のみに登録されており、cloud init エイリアスには登録されていない点に注意してください。
ログに --watch はありません — ログエンドポイントはポーリングできますが、ストリーミングには対応していません。ビルドを追跡するには、一定間隔でポーリングしてください。例外はデプロイで、apps deployments get／redeploy／trigger では、終了状態になるまで処理をブロックする --wait を指定できます。
apps logs build にはデプロイ ID が必要です — 最新のデプロイが既定で選ばれることはありません。まず apps deployments list で ID を取得してください。
deployments redeploy／trigger には、GitHub に接続されたアプリが必要です — apps deploy でローカルファイルからデプロイしたアプリは対象外です。
--q では値や ID は検索されません — リソースの主な名前フィールド（アプリ名、環境ブランチ、変数キー）のみが検索対象です。
ロールバックコマンドはありません。
ビルドサイズの上限は100 MBです — 104,857,600バイトを超えるビルドは、アップロード時に失敗します。

トラブルシューティング

`apps init` で `--app-name cannot be empty`（または必須フラグに関するエラー）が発生する

CLI は process.stdin.isTTY に基づいて対話型プロンプトを表示するかどうかを判断します。エージェントは TTY のないサブプロセスから CLI を呼び出すため、プロンプト部分は完全にスキップされ、最初の必須値が不足している場合はそのまま検証エラーが発生します。

対処方法： すべての必須フラグを明示的に渡してください。apps init の場合：

webflow apps init --new --no-input --app-name my-app --framework astro
# or, site-attached:
webflow apps init --no-input --app-name my-app --framework astro --mount /app --site-id site_abc123

プロンプトをスキップするために --no-input を渡すことは必須ではありません。TTY がなければプロンプトはすでにスキップされますが、指定すると動作が明確になり、このスキルの冒頭にある必須フラグの一覧とも一致します。

`apps init --new` が永久に停止する／戻ってこない

プロジェクトアプリモードでは、トークンに複数のワークスペースがある場合、ワークスペースの選択プロンプトが必ず表示されます。選択画面をスキップするには --workspace-id を渡してください。渡さない場合、TTY のない環境ではプロンプトで CLI が停止します。

対処方法： apps init --new に --workspace-id <id> を渡してください。ワークスペース ID は Webflow ダッシュボードの UI には表示されません。エージェントが ID を持っていない場合は、ユーザーに既存のプロジェクト内から対話形式で webflow apps deploy を実行してもらってください。事前確認のプロンプトでワークスペースを選択すると、webflow.json に cloud.workspace_id が書き込まれます。その後、エージェントはその値を読み取り、以降の実行時に --workspace-id を渡せます。単一ワークスペースのトークンには影響せず、選択は自動的にスキップされます。

管理コマンドが停止する、または ID 不足のエラーが発生する

読み取り／管理コマンドは、引数／フラグ、次に WEBFLOW_APP_ID／WEBFLOW_APP_ENVIRONMENT_ID、その次に webflow.json、最後にプロンプトの順で appId／envId を解決します。TTY のない環境で複数のアプリ／環境があり、何も渡されていない場合、コマンドは機械可読な missingFlag を返して終了します。

対処方法： アプリのディレクトリ内からコマンドを実行して（webflow.json から ID が解決されます）、または ID を明示的に渡してください — apps get <appId>、apps env-vars list --app-id <id> --environment-id <id>、apps logs runtime <envId>。アプリまたは環境がそれぞれ1つだけの構成では自動的に選択されるため、追加の指定は不要です。

site-attached を想定していたのに、provisioned の新しいサイトにデプロイされた

症状： ユーザーは既存の Webflow サイトへのデプロイを希望していたのに、apps deploy の出力に Creating Cloud app... / Cloud app created: <name> と表示され、ライブ URL がユーザーの意図したサイトではなく、新しく作成された <name>-<hash>.webflow.io になりました。

原因： webflow.json がプロジェクトアプリの初期化状態になっており、cloud.workspace_id は設定されている一方で siteId がありませんでした。これは通常、プロジェクトが以前 apps init --new でスキャフォールドされたためです。プリフライトフェーズでは明示的なフラグが優先されますが、フラグが渡されない場合はマニフェストの値が使われます。

予防策（主な修正方法）： apps deploy に --site-id <existing-site-id> を渡してください。プリフライトフェーズではフラグから識別情報を解決するため、これにより webflow.json の設定が上書きされ、デプロイ先が意図した Webflow サイトになります。site-attached でのデプロイが意図されている場合、スキルでは常に --site-id を渡してください。

webflow apps deploy --no-input \
  --site-id site_abc123 \
  --mount /app --environment main \
  --skip-mount-path-check --skip-update-check

新しいサイトがすでに作成された場合の復旧方法：

デプロイで作成された新しいプロジェクトアプリのサイトをそのまま使う場合 — 何もする必要はありません。以降のデプロイは同じサイトに行われます（または、曖昧さがある場合は新しいサイトの --site-id を渡してください）。
既存の Webflow サイトをデプロイ先に設定し直す場合。 自動プロビジョニングされたサイトは、作成後に既存のサイトへ再バインドできません。次の方法があります。
1. Webflow ダッシュボードから、または webflow apps delete <appId> --yes を実行して、プロジェクトアプリと自動プロビジョニングされたサイトを削除します。
2. webflow.json を編集して（cloud.workspace_id、cloud.app_id、cloud.environment_id、siteId を削除して）、--site-id <existing-site-id> を指定して apps init を再実行します。または、マニフェストを編集せずに apps deploy --site-id <existing-site-id> を直接実行します。プリフライトでは、これを新しい site-attached デプロイとして扱います。

デプロイ時の認証エラー

webflow auth login を実行し、ブラウザーでの認証フローを完了してください。CLI によって新しい WEBFLOW_API_TOKEN が .env に書き込まれます。ログイン後、デプロイを再試行してください。

CI ではブラウザー認証を行えません。認証エラーが発生した場合は、シークレット内の WEBFLOW_API_TOKEN が未設定か、有効期限切れです。シークレットを修正し、webflow auth login は実行しないでください。CI で従来の WEBFLOW_SITE_API_TOKEN を使用している場合、デプロイは成功しますが、実行ログに非推奨の警告が表示されます。警告を解消するには、シークレット名を WEBFLOW_API_TOKEN に変更してください。

別のワークスペースへのデプロイ

プロジェクトアプリ（--new）の場合： apps init または apps deploy に --workspace-id <new-id> を渡すと、webflow.json の cloud.workspace_id を上書きできます。または、webflow.json から cloud.workspace_id を削除し、init を再実行する（または既存のプロジェクトで対話形式のデプロイを実行する）と、再設定できます。

site-attached プロジェクトの場合： ワークスペースのコンテキストは認証トークンから暗黙的に決まります。webflow auth login を再実行し、ブラウザーで対象のワークスペースを選択してください。新しいトークンが .env の古いトークンに置き換わります。

最初のプロジェクトアプリのデプロイが `missing_scopes` で失敗する

.env に保存されたトークンに、Cloud アプリの作成に必要なスコープが含まれていません。webflow auth login を再実行してスコープを再承認し、デプロイを再試行してください。

最初のプロジェクトアプリのデプロイが「your workspace has reached its app limit」で失敗する

選択したワークスペース（cloud.workspace_id）がアプリの上限に達しています。ワークスペースのプランをアップグレードするか、Webflow ダッシュボードから（または webflow apps delete <appId> --yes を実行して）未使用のアプリを削除し、再試行してください。

最初のプロジェクトアプリのデプロイが workspace-not-found / 404 で失敗する

ワークスペース ID（--workspace-id フラグ、または webflow.json の cloud.workspace_id で指定）が解決できなくなっています。ワークスペースが削除されたか、トークンにアクセス権がありません。CLI はフラグを事前に検証せず、その値をそのまま使い、createCloudApp から返された 404 を表示します。修正方法：

apps init または apps deploy に --workspace-id <correct-id> を渡します。
または、webflow.json から cloud.workspace_id を削除し、空のディレクトリなら apps init --new --workspace-id <id> を再実行します。既存のプロジェクトなら、webflow apps deploy を対話形式で実行し、プリフライトのプロンプトでワークスペース ID を再設定します。

`ENVIRONMENT_MOUNT_MISMATCH`

--mount の値が、その環境に登録されているパスと一致しません。webflow apps environments list --json（mount フィールドを確認）またはテーブル形式の場合は --fields id,branch,mount（mount はデフォルトのフィールドセットに含まれていません）、あるいは Webflow ダッシュボードで正しいマウントパスを確認し、明示的に指定してください。

フレームワークを検出できない／フレームワークの明示的な指定が必要

cloud ブロックがあり、framework キーがない webflow.json ではエラーは発生せず、CLI は package.json からの検出にフォールバックします。従来のエラー 「webflow.json exists but doesn't contain valid framework information」 が発生するのは、cloud.framework にサポートされていない値が明示的に設定されている場合のみです。

フレームワークを引き続き検出できない場合（モノレポ、フレームワークの依存関係がない、設定が曖昧など）は、apps deploy の --framework フラグで修正してください。

webflow apps deploy --no-input --framework nextjs --mount /app --environment main ...

これにより cloud.framework が webflow.json に書き戻されるため、以降のデプロイではフラグを指定する必要がありません。または、マニフェストを直接編集してください。

{
  "cloud": {
    "framework": "nextjs"
  }
}

有効な値：nextjs、astro、vite、static。それ以外の値を指定すると、コード 1 で終了します。

ビルドに失敗し、完全なトレースが必要

webflow log

完全なエラートレースが記録された最新のログファイルのパスを表示します。

Markdown 対応

ログインしてコメント

基本情報

作者: webflow
リポジトリ: webflow/webflow-skills
カテゴリ: クラウド・DevOps
インストール数: 1,042
GitHub スター: 133

問題を報告

コマンド	常に渡すフラグ
`apps init`（サイトに接続）	`--no-input --app-name <3–39 chars> --framework <astro\|nextjs\|vite> --mount <path> --site-id <id>`
`apps init --new`（アプリ）	`--no-input --app-name <3–39 chars> --framework <astro\|nextjs\|vite\|static> --workspace-id <id>`
`apps init --import`（サイトに接続）	`--no-input --import <repo-url> --site-id <id> --mount <non-root path> --idempotency-key <key>`
`apps init --import --new`（プロジェクトアプリ）	`--no-input --import <repo-url> --new --idempotency-key <key>` — `--mount` は不要
`apps deploy`（サイトに接続）	`--no-input --mount <path> --environment <env> --site-id <id>` に加え、初回デプロイでは `--app-name`
`apps deploy`（プロジェクトアプリ、初回デプロイ）	`--no-input --mount <path> --environment <env> --workspace-id <id> --app-name <name>`