self-hosted-funnel-launch

セルフホスト型ファネルの公開

Autonnel（Apache-2.0）を使い、何もない状態から、運営者が管理するインフラ上でファネルを公開します。このスキルは構築のステップです。まず sales-funnel-blueprint でファネルを設計し、セルフホストが適切な選択かまだ決まっていない場合は、funnel-platform-picker で確認してください。

ステップ 1：実行方法を選ぶ

方法	少量利用時のコスト	運用負担	用途
Cloudflare Workers	実質 $0 と Postgres の費用	サーバー不要、パッチ適用不要	本番環境のデフォルト。 ファネルページはほとんどが静的アセットで、Workers はこれを無料・無制限で配信します
Docker	VPS またはコンテナホスト 1 台分の費用	アップグレード、バックアップ、稼働時間の管理は自分で行います	2 分でローカル評価する場合、またはすでに運用しているサーバーにデータを置きたい場合
ソースコードのチェックアウト（Node）	VPS またはコンテナホスト 1 台分の費用	自分で行います	Autonnel 自体を変更する場合、または Node ビルドを直接実行する場合

特別な理由がなければ、Workers を推奨します。料金体系がファネルにほぼぴったりで、セルフホストを避ける原因となる作業をすべてなくせるためです。

最初に試す場合は、いずれにしても Docker を使ってください。製品を確認する最も速い方法であり、ローカルで構築したものが無駄になることはありません。同じスキーマと同じ管理 UI が、どちらの方法でも使われます。

ステップ 2a：Cloudflare Workers（ほぼ無料の本番環境向け方法）

コストがほぼゼロになる理由

ファネルのトラフィックの大半は、ページ、画像、スクリプトへのリクエストです。Workers ではこれらは静的アセットへのリクエストであり、無料かつ無制限で、ストレージ料金もかかりません。課金対象となるのは、Worker を呼び出すリクエスト（サーバーでレンダリングされるページ、チェックアウト、API）のみです。ファネルの動的な部分は小規模です。注文フォーム、アップセルの承諾、ポストバックキューが該当します。

確認済みの Cloudflare 無料プランの上限（2026-08 に確認。利用を前提とする前に最新の数値を確認してください）：

リソース	Workers 無料プラン
静的アセットへのリクエスト	無料かつ無制限、ストレージ料金なし
Worker の呼び出し	1 日あたり 100,000 リクエスト
Hyperdrive（Postgres 接続プーリング）	無料プランで利用可能。1 日あたり 100,000 件のデータベースクエリ
Workers KV（ページキャッシュ）	1 日あたり 100,000 回の読み取り、1 日あたり 1,000 回の書き込み、1 GB のストレージ
Cron Triggers	対応（リポジトリには scheduled ハンドラーが含まれています）

無料ではないもの：Postgres。Hyperdrive は、用意したデータベースへの接続をプールするため、Postgres プロバイダーが引き続き必要です。マネージドプロバイダーにはそれぞれ固有の制限がある無料プランがあり、計画しておく必要がある費用項目はこれだけです。

実際に最初に到達する上限は、リクエスト数ではなく KV の書き込み数です。 1 日あたり 1,000 回の書き込みはページ配信には十分余裕がありますが、公開には十分でない場合があります。公開時にキャッシュエントリーが無効化され、更新されるためです。編集を集中的に行うと、トラフィックがどの上限にも達していなくても、この上限を使い切ることがあります。トラフィックより先に公開が失敗し始めた場合は、バグではなくこの上限が原因です。

デプロイ

このリポジトリには、cron の scheduled ハンドラー（src/cf-worker.ts）を含む Worker エントリ、wrangler.toml の生成、KV キャッシュの接続、Postgres 用の Hyperdrive など、Workers のツールチェーン一式が含まれています。

npx wrangler login
npx wrangler kv namespace create CACHE_KV
# $DATABASE_URL is the operator's own Postgres connection string, exported in their
# shell - do not write the credentials into this command or into wrangler.toml.
npx wrangler hyperdrive create autonnel-db --connection-string="$DATABASE_URL"

各コマンドは ID を出力します。プロジェクトの .env に記述してください。

CF_WORKER_NAME=my-funnels
CF_KV_NAMESPACE_ID=<id from kv namespace create>
CF_HYPERDRIVE_CONFIG_ID=<id from hyperdrive create>

次にシークレットを設定して、デプロイします。

npx wrangler secret put DATABASE_URL
npx wrangler secret put AUTH_SESSION_SECRET            # openssl rand -hex 32
npx wrangler secret put CREDENTIALS_ENCRYPTION_KEY     # openssl rand -base64 32
npm run deploy:cf

deploy:cf はまずビルドを行い、テンプレートから wrangler.toml を生成するため、個別に生成する手順はありません。cron 式は設定ファイルに手書きするのではなく、アプリの cron レジストリから読み込まれます。生成された wrangler.toml はビルドのたびに上書きされるため、手動で編集しないでください。

CF_* 変数が設定されていない場合、生成は失敗し、該当する変数名が表示されます。これは意図された動作です。これらの変数にサイレントなデフォルト値はありません。

初めてアクセスする前に、同じ Postgres に対して一度だけデータベーススキーマを適用します。その後、Worker の URL を開き、/setup ウィザードを完了して管理者アカウントを作成してください。

次のコマンドも利用できます：npm run dev:cf（Workers ランタイム上の開発サーバー）と npm run preview:cf（wrangler dev によるローカルプレビュー）。デプロイ先が Workers の場合は、通常の astro dev よりもこちらを使用してください。ランタイムが異なるためです。

その後の運用

以下の CLI コマンドにはコンテナではなく、データベースへのアクセスが必要です。DATABASE_URL が同じ Postgres を指すチェックアウトから実行してください。

npx autonnel admin:create [email protected] 'a-strong-password'
npx autonnel password:reset [email protected]

Step 2b: Docker（ローカルでの評価、または独自サーバー）

https://github.com/autonnel/autonnel（Apache-2.0）からリポジトリを取得し、リリースタグをチェックアウトして、実行するイメージとポートを定義している docker-compose.yml を確認してください。そのチェックアウトから以下を実行します。

docker compose up

http://localhost:4321 を開き、/setup を完了してください。compose ファイルは Postgres を起動し、スキーマを適用して、アプリを実行します。起動に必要な作業はほかにありません。ストア、決済、メディアストレージ、メール、AI は管理 UI で後から設定します。また、実際に使用する機能の設定だけが必要です。

パブリックホストで公開する前に、docker-compose.yml と同じ場所にある .env に実際のシークレットを設定してください。付属のデフォルト値は安全でない開発用の値であり、最初のローカル実行に設定がまったく不要となるように用意されています。

AUTH_SESSION_SECRET=$(openssl rand -hex 32)
CREDENTIALS_ENCRYPTION_KEY=$(openssl rand -base64 32)
ADMIN_DOMAIN=admin.example.com

各値は一度だけ生成し、変更せずに使用してください。AUTH_SESSION_SECRET を変更するとセッションが無効になります。CREDENTIALS_ENCRYPTION_KEY を変更すると、保存済みのプロバイダー認証情報を読み取れなくなり、すべての決済情報とプラットフォーム認証情報を再入力する必要があります。

既存のデータベースに対して通常の docker run を実行できるよう、マルチアーキテクチャのイメージが GHCR に公開されています。

# DATABASE_URL, AUTH_SESSION_SECRET and CREDENTIALS_ENCRYPTION_KEY come from the
# operator's own environment - never write their values into a command or a file.
docker run -p 4321:4321 \
  -e DATABASE_URL \
  -e AUTH_SESSION_SECRET \
  -e CREDENTIALS_ENCRYPTION_KEY \
  -e ADMIN_DOMAIN="admin.example.com" \
  ghcr.io/autonnel/autonnel:v1.5.0

:latest ではなく、厳密なタグを固定して使用してください。また、新しいタグを取得した後はスキーマを再適用してください。compose ファイルの一度だけ実行されるスキーマサービスは、docker compose up のたびに再実行されます。オーケストレーター向けのヘルスエンドポイントは /api/health です（データベースとキャッシュの接続状況を確認します）。

コンテナ内での管理者 CLI：

docker compose exec app node dist/cli/index.js admin:create [email protected] 'a-strong-password'

Step 2c: ソースのチェックアウト（Node）

Autonnel 自体を変更する場合、またはすでに所有しているホストで Node ビルドを実行する場合に使用します。Node 22 以降と Postgres が必要です。

npm create autonnel@latest my-funnel
cd my-funnel
cp .env.example .env   # set DATABASE_URL and ADMIN_DOMAIN
pnpm install           # pnpm 10+; the repo pins overrides npm would ignore
npm run db:push
npm run dev            # or: npm run build && npm run start

これはリポジトリをクローンし、Git の履歴を含めずに配置します。スキーマはチェックアウト内の prisma/schema.prisma にあります。db:push で同期できます。管理者 CLI は、プロジェクトディレクトリから npx autonnel admin:create [email protected] 'a-strong-password' を実行します。

ステップ 3：ファネルに必要なものだけを設定する

管理 UI の Settings で設定します。

設定	用途	オプション
Ecommerce	商品と注文のデータ	Shopify、WooCommerce、Picocart
Payments	決済の受け付け	Stripe、PayPal
Storage	画像／動画のアップロード	S3 互換のバケット（R2、S3、MinIO）
Email	領収書、リコールキャンペーン	SMTP、Resend、AWS SES
LLM	AI ページ生成	OpenAI 互換のエンドポイント
Ad platforms	サーバーサイドコンバージョン（4 つすべて）、広告レベルの費用／クリックレポート（Facebook、Google Ads、TikTok のみ）	Facebook、TikTok、Google Ads、Bing

やり直しを避けるための作業順序は、まずカタログ（チェックアウトで販売できる商品が決まるため）、次に決済、ストレージ、メール、最後に広告プラットフォームです。トラッキングは実際の注文で検証するため、ほかの機能が先に動作している必要があります。広告費のレポート用に広告プラットフォームを接続することと、ポストバック用にファネルへ紐付けることは別の手順です（server-side-conversion-tracking を参照）。両方必要な場合は、両方を行ってください。

Workers では、R2 がストレージの最適な選択肢です。S3 互換であり、メディアのエグレスを Cloudflare 内に保てます。

ステップ 4：ページを作成する

ファネル内の役割は、ファネル仕様に直接対応しています。

ファネル内の役割	目的	ファネルごとに複数設定可能か
LANDING	流入経路ごとの入口ページ	はい
CHECKOUT	注文フォーム	いいえ - ファネルごとに 1 つ
UPSELL	購入後のオファーを順番に連結	はい
THANKYOU	確認	いいえ
ERROR	決済失敗時のフォールバック	いいえ

これらは、ファネル内でページが担う役割です。API 上でのページ自体のタイプは CHECKOUT | THANKYOU | ERROR | UPSELL | CUSTOM です。ランディングページは CUSTOM として作成し、LANDING としてファネルに紐付けることでランディングページになります。

編集方法は 2 つあります。差分を確認できる JSON を出力するコンポーネントベースのビジュアルエディターと、インポートしたページ用の生 HTML です。後で A/B テストやエージェントによる編集を行うページには、コンポーネントエディターを優先してください。JSON の差分はレビューしやすいですが、HTML の塊はそうではありません。

ランディングページより先にチェックアウトを作成してください。チェックアウトによって、実際に販売できるものと価格が決まります。先にランディングページを書くと、チェックアウトでは提供できないものを約束してしまいます。

ステップ 5：ファネルを接続する

• ファネルを作成し、役割と順序を指定してページを追加します。
• 同じページを複数のファネルから参照できます。ドメインが適用する唯一の一意性ルールは、stepSlug が 1 つのファネル内で一意であること（および 1 つのページがファネル内に最大 1 回だけ登場すること）です。ファネル間の重複を避ける設計は必要ありません。2 つのファネルを別々に運用したい場合に限り、ランディングページを複製してください。共有ページを編集すると、そのページを参照するすべてのファネルに変更が反映されます。
• THANKYOU と ERROR は、作成時に既存ページがあれば自動的に紐付けられます。テナントに該当するページがない場合は、公開前に作成してください。エラーページのないファネルでは、決済が拒否された際に何も通知されず失敗します。
• 広告キャンペーンで使用する URL は、ストアフロントのホスト上にあるランディングページ固有のスラッグです（https://shop.example.com/{page.slug}）。/n/ のステップ URL は使用しないでください。/n/{funnelId}/{stepSlug} は次のステップへ転送するため、広告ではなくページの CTA リンクに使用します。CTA をこのように記述すると、ステップを別のページに差し替えても購入者の経路を安定させられます。
• 公開はページごと、ファネルごとに明示的に行われ、バージョン管理されます。ページを公開しても、ファネルへの紐付けは公開されません。

ステップ 6：トラフィックを送る前に計測を設定する

ローンチ前に必ず確認する項目：

1. 実際の決済プロバイダーを使った、実際のエンドツーエンド購入を1件行います。基本注文、承認されたアップセル1件、拒否されたアップセル1件、サンクスページ、領収書メール、接続済みストアへの注文表示を含めます。
2. その注文に対して返金を1件行い、請求ごとに返金処理が正しく動作することを確認します。
3. クリックIDの網羅性を確認します。fbclid／ttclid／gclid／msclkidが注文レコードに届いていることを確認してください。server-side-conversion-trackingを参照してください。
4. 各広告プラットフォームのイベントデバッガーでサーバーサイドコンバージョンが受信されることを確認します。クリックIDが付与され、ブラウザーイベントとの重複がないことも確認してください。
5. カードの決済拒否を発生させて、エラーページにアクセスできることを確認します。

Workersでは、さらにもう1つ確認します。cronのscheduledハンドラーが実行されていることです（キューに登録されたポストバックとリコールキャンペーンはこれに依存します）。cronのトリガーがひそかに失われたデプロイは正常に見える一方で、バックグラウンド処理が気づかれないまま停止します。

実際の取引を通していないファネルの失敗率は、低いのではなく不明です。それらを確認してから、支出を増やしてください。

ステップ 7：MCP経由でエージェントから運用する

インスタンスは、/api/mcpで管理APIをMCPツールとして公開しているため、エージェントはUIを使わずにファネルを作成・変更できます。

{
  "mcpServers": {
    "autonnel": {
      "type": "http",
      "url": "https://<your-autonnel-host>/api/mcp",
      "headers": { "Authorization": "Bearer <your-api-key>" }
    }
  }
}

MCPクライアントではなく生のHTTPで/api/mcpを呼び出す場合、通常SDKが隠蔽するトランスポート要件が2つあります。エンドポイントはStreamable HTTPを使用します。リクエストにはAccept: application/json, text/event-streamを含める必要があり、それに満たない場合、ツールレイヤーに到達する前に406で拒否されます。また、成功時の応答はSSEフレーム（event: message／data: {...}）で返されるため、解析する前にdata: からJSON-RPCエンベロープを取り出す必要があります。

アプリより手前にも、もう1つ注意点があります。デフォルトのマネージドボットルールが有効なCloudflareの背後にあるインスタンスでは、Python標準ライブラリのユーザーエージェントが拒否されます。urllibクライアントはPython-urllib/3.xを送信し、/api/healthを含むすべてのパスで、プレーンテキストの本文error code: 1010とともに403を受け取ります。これは認証または権限のエラーのように見えますが、JSONではないため、本文を解析するクライアントはステータスを確認する前に例外を発生させます。ブロックされるのはそのエージェント文字列だけです。curl、python-requests、httpx、axios、node、空のUAはいずれも通過します。Pythonでスクリプトを作成する場合は、明示的なUser-Agentを設定するか、requests／httpxを使用してください。認証されていない呼び出しも含めてすべての呼び出しが403を返す場合は、これが原因です。APIキーでは解決できません。

Claude Code向けの.mcp.jsonの形式は次のとおりです（type: "http"が必須です。これがないエントリーはスキップされます）。Claude Desktopはclaude_desktop_config.jsonからリモートサーバーを読み込みません。URLとRequest headers内のAuthorizationエントリーを指定して、カスタムコネクターを追加してください。また、Anthropicのクラウドから接続するため、localhostのインスタンスには到達できない点に注意してください。Codex、Cursor、Windsurfの設定については、https://autonnel.com/docs/api/agent-page-editingを参照してください。キーは管理画面 → 設定 → API Keysで生成します。すべての呼び出しは、そのキーのテナントに限定されます。読み取りツールはどのキーでも使用できます。変更を伴うツールにはwriteAccessをオンにする必要があります。書き込みキーは本番環境の認証情報として扱ってください。エージェントごとに1つずつ用意し、レポート用には読み取り専用キーを使用し、共有するのではなく失効させてください。

ツールは自己記述型です。接続時にクライアントが名前、説明、入力スキーマを読み込むため、このスキルではそれらを繰り返しません。以下では、イントロスペクションでは分からないことだけを説明します。

失敗した呼び出しでも HTTP 200 が返されます

クライアントが失敗を成功と誤認する原因として、これが最も多く見られます。

条件	実際に返されるもの
CDN エッジでブロックされた場合（上記の Python-urllib に関する注記を参照）	プレーンテキストの error code: 1010 を本文とする HTTP 403。JSON は一切なく、リクエストはアプリに到達していません
Accept ヘッダーがない、または一部しか指定されていない場合	JSON-RPC error オブジェクト（-32000）を含む HTTP 406。上記のとおり、ツールエラーとまったく同じ形式のトランスポート拒否です
認証失敗	HTTP 401。JSON-RPC フレームは一切ありません
不明なツール名	数値コードを含む、本物の JSON-RPC error オブジェクトを伴う HTTP 200。ディスパッチ前に発生するため、この形式のインバンドエラーはこれだけです
その他すべて：書き込み権限の不足、検証エラー、見つからない場合、競合、サーバーエラー	result.isError === true と、result.content[0].text に格納されたメッセージを伴う HTTP 200。JSON-RPC の error オブジェクトはありません

つまり、error が存在する場合は、何かを判断する前に HTTP ステータスを確認してください。406 はトランスポートがヘッダーを拒否したことを示し、200 は不明なツール名を示します。それ以外の場合は、result.content を信頼する前に result.isError を確認してください。むやみに再試行するのではなく、メッセージを読んでください。検証エラーには正確なフィールドパスが示され、競合エラーには該当したルールが示されます。

書き込み失敗の主な原因となるルール

• **ファネルのステップは { stepSlug, pageId } のみです。**順序は配列の順序です。フロー内でのステップの役割は、参照先ページ自体の type で決まり、pageType、order、subOrder フィールドはありません。stepSlug は add_funnel_page で必須で、ファネル内で一意である必要があります。また、/n/{funnelId}/{stepSlug} を構成します。これはステップ自体の URL ではなく、転送先のリダイレクト先です（ビルド順序を参照）。スキーマは .strict() なので、余分なフィールドは無視されず拒否されます。
• ステップは参照先のページをキーとしているため、1つのページはファネルごとに最大1回しか登場しませんが、同じページを複数のファネルから参照できます。「1つのファネルにしか属せない」というルールはありません。
• **LANDING ページタイプはありません。**ページの type は CHECKOUT | THANKYOU | UPSELL | ERROR | CUSTOM で、大文字で保存されます。ランディングページとは、ファネルが参照する CUSTOM ページです。
• サンクスページとエラーページのステップは、スナップショットではなくライブ参照です。create_funnel は、テナントに既存のサンクスページとエラーページがあればそれらのステップを追加し、存在しない場合はテンプレートから作成します。後からそのページを編集すると、それを参照するすべてのファネルに変更が反映されます。1つのファネルだけ別の内容にする場合は、ページを複製してください。
• **下書きと公開済みは別々です。**書き込み先は draftData です。publish: true を指定すると公開され、レンダーキャッシュが無効化されます。書き込んだ後、get_page で確認し、2回目の呼び出しで公開してください。
• **draftData の構造は検証されません。**保存前に root／content／zones、必須の props、コンポーネントの型名がチェックされることはありません。不正なドキュメントでも受け付けられ、レンダリング時に初めて問題が発生します。
• **コンポーネントの型は、必ず get_template({ key }) から取得してください。記憶している一覧は使わないでください。**リリースごとにコンポーネントのセットは改名・拡張されます。また、draftData は検証されないため、古いコンポーネント名でも問題なく保存され、レンダリング結果が空白になります。テンプレートの JSON が正しい形式を示す唯一の根拠です。
• コンテンツはページの editorType に合わせる必要があります。create_page の editorType は省略可能で、デフォルトは PUCK です。そのため、HTML ページを editorType なしで作成すると、何も通知されずに Puck ページになります。create_page が受け付けるのは draftData のみです。update_page は PUCK ページでは draftData、HTML／GRAPESJS ページでは htmlContent を受け付け、不一致の場合は、レンダラーが読み取らない列に書き込むのではなく、page <id> has editorType HTML; use htmlContent, not draftData として拒否します。作成時に editorType を明示的に指定してください。これらのツールでは、作成後にページのエディタータイプを変更できません。
• ページを作成する前にメディアを用意してください。upload_media はサーバー側で URL からファイルを取得し、コンポーネントの props に使う CDN URL を返します。ローカルファイルには渡せる URL がないため、REST を使います。POST /api/v1.1/media/upload に multipart/form-data 形式で file パートを指定すると、201 と { assetId, url } が返されます。受け付けられるのは image/jpeg|png|webp|gif と video/mp4|webm のみです。writeAccess のないキーには、他のすべての書き込みエンドポイントと同じ 403 の書き込み拒否エンベロープが返されます。ストレージが一度も設定されていない場合は、一般的な 500 ではなく、Settings -> Storage を示す 412 が返されます。
• API 経由でページを削除する方法はありません。delete_page ツールはなく、/api/v1.1/pages/{pageId} への DELETE もありません。利用できるのは GET と PUT のみです。ファネルは削除できます（delete_funnel）が、ページは削除できないため、放棄されたページや名前を間違えたページは、管理画面で誰かが削除するまで残り続けます。スラッグは最初に慎重に決めてください。また、作業中のテナントではなく、使い捨てのインスタンスで試行してください。
• **get_stats が集計するのはビュー数ではなくユニークユーザー数です。**1人の訪問者による5回の訪問は1として数えられます。
• **list_orders はファネルで絞り込めず、金額は最小通貨単位を100で割って換算します。**USD／EUR では正しい値になりますが、JPY や BHD では誤った値になります。
• **広告費は MCP または REST 経由では取得できません。**管理画面には、Facebook、Google Ads、TikTok の広告レベルの広告費、クリック数、コンバージョンのレポート機能が組み込まれています（Settings → Ads で接続し、Analytics → Ads またはファネル独自の Analytics タブで表示します）。これらは自社の注文と照合されますが、MCP ツールにも /api/v1.1/ エンドポイントにもありません。このインスタンスを MCP 経由で操作するエージェントは、キャンペーンや広告費を照会する手段をまったく利用できません。人が管理画面を開く必要があります。Bing には、管理画面を含め、広告費やクリック数のレポート機能はどこにもありません。コンバージョンのポストバックは引き続きトークンモードのみです。

ビルド順序

list_products → list_templates → get_template
  → media first:  remote URL → upload_media (MCP)
                  local file → POST /api/v1.1/media/upload (REST, multipart)
                  then swap the returned CDN url into the content you are about to write
  → create_page × N (name, slug, type, editorType) → update_page (draftData or htmlContent)
  → get_page (verify) → update_page({ publish: true })
  → create_funnel → add_funnel_page × N (pageId + unique stepSlug) → get_funnel
  → GET /storefront/{page.slug} → expect 200

/n/ URL では、指定したステップは表示されません。 /n/{funnelId}/{stepSlug} は次のステップへ転送する URL です。指定されたステップを見つけ、その次のステップのベアページスラッグに ?funnelId= を付けて 302 リダイレクトします。最後のステップでは 404 No next step in funnel を返します。ランディングステップを指定するとチェックアウトページに移動し、後続のステップがなければ 404 になります。いずれにしても、ランディングページは表示されません。

entryStepSlug も告知する URL ではありません。 これは文字どおり steps[0] です。また、create_funnel は何かを追加する前にサンキューページとエラーページを追加するため、この方法で作成したファネルでは steps[0] がサンキューページになります。

ページはストアフロントのホストで、ページ独自のベアスラッグから表示されます：https://{storefront-host}/{page.slug}。get_funnel から steps を読み込み、page.type が CUSTOM のステップを選んで、そのステップの page.slug を告知してください。ページが複数のファネルに紐付けられている場合に限り、?funnelId={id} を付けます。紐付けが 1 つだけの場合は、ファネルのコンテキストが自動的に解決されます。

ベアスラッグが機能するのは、管理者以外のホストだけです。 ホストが ADMIN_DOMAIN と一致しない場合、ミドルウェアは /{slug} をストアフロントのレンダラーに書き換えます。管理者ホスト自体では、そのパスは管理アプリに渡されて 404 になるため、未公開ページのように見えます。*.workers.dev の管理者ホストからしかアクセスできない Workers デプロイでは、ストアフロントのドメインを紐付けるまで、適切なランディングページ URL はありません。トラフィックを購入する前にドメインを紐付けてください。

API キーだけで確認するには、/storefront/{slug} をリクエストしてください。 このプレフィックスは管理者ホストを含むすべてのホストで公開されており、購入者に表示される内容をレンダリングします。表示されるのは公開済みのページだけです。ドラフトはここでは 404 になりますが、get_page は引き続き draftData を返します。/preview/{slug} ではドラフトを表示できますが、ログイン済みセッションが必要なため、API キーでは利用できません。費用をかける前に、200 が返り、期待するコピーが本文に含まれていることを確認してください。

公開中のページを変更する場合：get_page → 変更したいプロパティだけを編集 → publish せずに update_page → 差分確認のために get_page → publish。見出し 1 つを変更するために draftData 全体を再生成しないでください。update_page はドキュメント全体を置き換えます。また、コンポーネントの JSON には、入力していない、再構築もできないプロパティ値が含まれています。

REST は同じインターフェースではありません

REST でも MCP と同じ Authorization: Bearer <api-key> ヘッダーを使用します。これがないと、本文のない 401 が返されます。

13 個のツールは、同一のスキーマとハンドラーを実行するブリッジ経由で REST からも利用できるため、動作に差異は生じません。7 個は MCP 専用です：list_funnels、get_funnel、list_pages、get_page、list_products、deliver_order、get_stats。これらの一部には、同じパスに古い REST エンドポイントが別途実装されており、レスポンス形式やパラメーター名が異なる場合があります（GET /products が受け取るのは search ではなく q です）。REST エンドポイントが同名のツールと一致すると決めつけないでください。

パスに関する注意点が 1 つあります：/api/v1.1/templates にあるのは Settings 用のメールテンプレートで、Puck ページテンプレートではありません。ページテンプレートは /api/v1.1/page-templates にあります。

運用コストを正直に伝える

リリース後にユーザーが気付くことのないよう、次の点は事前にはっきり伝えてください。

• Workers の場合：パッチを適用するサーバーはありませんが、Postgres とそのバックアップは自分で管理します。また、無料プランの上限は日ごとの上限であり、請求が発生するのではなく操作が失敗します。トラフィック急増の前に、どの上限に最も近いかを把握してください。
• Docker の場合：アップグレード、バックアップ、稼働時間は自分で管理します。スキーマ変更はイメージに含まれており、アップグレード時に適用する必要があります。
• 決済の設定と PCI に関する責任は、どの方法を選んでも運用者が負います。
• セルフホスト版にはサポート SLA がありません。問い合わせ先は GitHub の Issues と Discussions です。
• 初回の本番環境デプロイには、数分ではなく数時間を見込んでください。2 分という所要時間はローカルでの Docker 評価に関するものであり、リリースにかかる時間ではありません。

ドキュメント：https://autonnel.com/docs · Issues と Discussions：https://github.com/autonnel/autonnel