コンセプト

プレビューと公開

すべての変更が本番前にプレビュー URL を通じて配布される理由。

Showly について最も意見が分かれている点: プロダクションでは、プレビューされていないものは何も受け取りません。 このページでは、その理由と、それが実際に何を意味するのかについて説明します。

プレビューとは

プレビューは、不変のビルド アーティファクトとルーティング可能な URL です。内容は次のとおりです。

  • パッチが適用されたコミット SHA
  • ライブプロダクションアーティファクトとの差分
  • ビルドログ
  • 結果のチェック (lint、型チェック、カスタム CI フック)
  • それを作成したエージェントまたは人間

認証済みワークスペースのプレビューは、分離された名前空間に存在します。クローラーによってブロックされ (X-Robots-Tag: noindex)、有効期限はなく、本番環境とシークレットを共有することもありません。アカウントなしで作成され、未請求の公開トライアルは別のフローで、請求されない場合は引き続き約 1 時間後に期限切れになります。

プレビューのトリガー方法

ビルドを生成するには 3 つの方法があります。

  • あなたのエージェント (MCP より Claude Code / Codex) は、変更をステージングした後、create_preview を呼び出します。
  • 接続された GitHub からビルドします。 Web と MCP は、接続されたブランチを解決し、パスワードで保護されたプライベート プレビューを作成できます。 Pro+ ワークスペースでは、代わりにワークスペース メンバー アクセスを選択できます。プッシュ自動デプロイはデフォルトでオフになっており、明示的に有効にすると、プライベート ワークスペース メンバーのプレビューのみが作成され、ライブ リリースは作成されません。現在、無人自動デプロイには Pro+ と静的ビルド ターゲットが必要です。サポートされていないランタイム ターゲットはアプリ内通知でスキップされます。 (ソースは、ビルド環境に入ることのない、有効期間が短くスコープが設定された GitHub アプリ トークンを使用してクローン化されます。)
  • 再試行/再構築 失敗またはキャンセルされた展開は、ダッシュボードの 再構築 ボタンまたは retry_deployment MCP ツールから再構築できます。 Showly はソースバンドルを保持するため、再アップロードせずにワンクリックで再構築できます。

すべてのパスは同じアーティファクトとプレビュー URL に到達します。プレビュー ビルドは無料です。 実稼働デプロイメントが成功すると、15 クレジットが消費されます。失敗した生産 導入ではそうではありません。ビルドが失敗すると、デプロイメントには失敗ステージが続きます。 エラー コード、メッセージ、ビルド ログの末尾が表示されるので、再試行する前に理由を確認できます。

パスワード アクセスの場合、Showly は、あいまいな文字が削除された短い XXX-XXX 共有コードを生成します。代わりに、6 ～ 128 文字の任意のパスワードを選択できます。プレーンテキストは、プレビューが作成されたとき、またはそのパスワードが変更されたときにのみ表示されます。 URL + パスワードのコピー を使用して、転送準備完了の資格情報ブロックをコピーします。既存のパスワードは、ローテーションするまで有効です。機密性の高い内部レビューの場合は、Pro 組織アクセスを優先するか、より長いパスワードを選択してください。

パブリッシュとは

パブリッシュとは、_既存のプレビュー アーティファクト_を運用ルートに昇格させることです。 Showly は公開時に再構築しません。あなたが承認したアーティファクトが出荷されるアーティファクトです。これがロールバックを安全にする理由です。ロールバックは「ルート ポインターを元に戻す」ことであり、「ビルドを再実行する」ことではありません。

プレビューとライブは別のアドレスです。プレビューは非公開のままであり、公開 URL に変わることはありません。公開すると、サイトのライブ アドレスの実稼働環境が作成されます。ソース プレビューは明示的に削除されるまで利用でき、プランによる有効期限はありません。

承認とは

承認は、公開の承認を許可されたワークスペース メンバーによる記録された決定です。役割は owner、admin、developer、deployer、viewer です。 MCP 以降に作成された公開リクエストには、owner または admin からの 1 つの承認が必要です。この決定は永続的です。たとえ承認者が明日ワークスペースを離れたとしても、監査記録にはその承認者がリビジョン N の承認者として指名されます。要求者は自分の要求を承認することはできず、拒否は最終的なものとなります。

承認ワークフローは、approvalWorkflows 権限によって制御されます。いつ 無効になっている場合、リクエスタは明示的なブラウザアクションを使用して公開するか、 エージェントの 2 段階の publish_site 確認。 OTP/MFA 登録は行われません。 要求され、放棄された承認ゲートは監査ログに記録されます。

ロールバックとは

エディターの ロールバック ボタンは、ライブ ルート ポインターを以前のアーティファクトに交換します。ロールバックは、独自の確認コントロールを備えた独立した高リスクのアクションのままです。 roll-back-from アーティファクトは _kept_ です。ロールバックが間違った呼び出しであったことが判明した場合は、後で再プロモートできます。

パブリッシュ ループが重要な理由

一般的な Showly パブリッシュは次のようになります。

  1. エージェントが create_change_plan に電話 → 人間が計画をレビューします。
  2. エージェントが apply_site_patch + create_preview を呼び出します → プレビュー URL が生成されます。
  3. 人間がプレビューを訪問し、重要なフローを実行します。
  4. オプション: run_checks は、ワークスペースのカスタム チェック マトリックスを実行します。
  5. エージェントが request_publish に電話をかける → 保留中の承認が作成されます。このツールは、webApprovalUrl ディープ リンクを含む承認エンベロープ (下記を参照) を返します。
  6. ワークスペースのメンバーは、webApprovalUrl を開き、リクエストを承認 (または拒否) します。
  7. 人間が Web UI で [公開] をクリックします。 OTP 設定は必要ありません。パブリッシュにより、承認されたプレビュー デプロイメントが運用環境にプロモートされ、そのプレビュー デプロイメントの ID に設定された sourceDeploymentId が保持されます。

request_publish は承認封筒を返します。

{
  "approvalId": "apr_...",
  "deploymentId": "dep_...",
  "state": "pending",
  "expiresAt": "2026-05-31T10:00:00.000Z",
  "reused": false,
  "webApprovalUrl": "https://showly.ai/app/deployments/dep_.../publish"
}

state は、pending、approved、denied、または expired のいずれかであり、同じ展開に対する既存の保留中の承認が新しい承認ではなく返された場合、reused は true になります。 publish_site は、2 段階のデプロイメント限定の人的確認フローとして、MCP を通じても利用できます。

各ステップは監査可能です。各ステップには、本番環境に到達しない明らかな障害モードがあります。

ホットフィックスについてはどうですか?

ホットフィックスは引き続き、最初にプライベート プレビューを通過します。緊急バイパスはありません。 公開するには、準備ができたプレビュー、明示的な公開確認が必要です。 ワークスペースに必要な承認はすべて含まれますが、OTP 登録は含まれません。