メインコンテンツへ移動
AIチュートリアル

GoLiveでエージェント構築アプリをデプロイ：ホスティング、データベース、ドメイン、認証、メール、決済

GoLiveのインストール方法、コーディングエージェントによるアプリの公開方法、実行前のプロバイダー変更の確認方法、デプロイ結果の検証方法、ドリフトの検出方法、所有権ドキュメントの作成方法、リソースを安全に削除する方法を学びます。チュートリアルでは、アルファ版でテスト済みのプロバイダー、実験的な機能、重要な制限事項についても説明します。

約22分で読了
GoLiveでエージェント構築アプリをデプロイ：ホスティング、データベース、ドメイン、認証、メール、決済

GoLiveの機能

GoLiveは、エージェントが構築したアプリケーションをソースコードから実際のインフラストラクチャへ移行するためのオープンソースのAgent Skillです。リポジトリを調査し、必要なサービスを検出し、プロバイダー固有の変更を提案して承認を求め、ユーザー自身のアカウントを通じて変更を適用し、確認可能な範囲で結果を検証します。

このプロジェクトは、アプリケーションの生成と、実際のユーザー向けの運用との間にある隔たりを埋めるために設計されています。アプリによっては、ホスティング、データベース、環境変数、認証、カスタムドメイン、トランザクションメール、テストモード決済などが必要になる場合があります。

GoLiveのアカウントや、ホスト型GoLiveバックエンドは必要ありません。また、製品テレメトリーも含まれていません。プロバイダーへのアクセスは、引き続きユーザー自身のアカウントとログイン情報に紐づきます。

アルファ版に関する注意: 現在のリリースは0.1.0-alpha.3です。使い捨ての本番リソースを使っていくつかのフローを実施済みですが、プロジェクトのロードマップにある広範なチェックリストは、すべてのローンチフローが完了していることを示すものではありません。

主な機能

  • リポジトリ検出: GoLiveはアプリケーションを調査し、必要と思われるインフラストラクチャとサービスを特定します。
  • プロバイダーの維持: アプリケーションがすでに使用しているプロバイダーを保持し、自動的に置き換えることはありません。
  • 承認優先の実行: プロバイダーへの変更を行う前に、接続先アカウント、リソースの詳細、変更内容、利用可能な費用情報を提示します。
  • 人間による引き継ぎ: サインアップ、ブラウザログイン、本人確認、購入、受信トレイへのアクセスなど、人間だけが行える操作はユーザーの管理下に残ります。
  • 検証: GoLiveは確認可能な結果をチェックし、阻止された項目や未検証の項目を明確に報告します。
  • ライフサイクル記録: 作成したリソースを記録し、オンデマンドのgolive statusによるドリフトチェックをサポートし、引き継ぎ用の成果物を生成できます。
  • 管理された削除: 実行中に作成されたリソースは、別途計画・承認された削除ワークフローを通じて削除できます。
  • プロバイダーのガイド付きサポート: 組み込みアダプターのないプロバイダーについては、公式CLI、公式MCP連携、API、またはダッシュボードの手順を使ったベストエフォートのフローを試行できます。

現在のアルファ版の範囲

最も確立されているアルファ版のフローは、2つのホスティングプロバイダーと2つのデータベースプロバイダーを対象としています。

  • ホスティング: VercelとNetlify。
  • データベース: SupabaseとNeon。
  • カスタムドメインDNS: PorkbunとGoDaddyでは、Vercelと連携したレコード書き込みフローを実環境でテスト済みです。
  • トランザクションメール: Resendのドメイン設定、DNS検証、実際のアプリケーションからの送信をテスト済みです。
  • 決済: Stripeのテストモードキー、Webhook登録、署名付きイベントの検証、実際のテストカード決済を実施済みです。
  • 認証: Supabase Authのポリシー設定と、オプトイン方式のサインアップフローには実環境での証拠があります。パスワード回復とアカウント分離は実装済みでモックテストもありますが、同等レベルの実環境検証はまだ完了していません。

実環境でテスト済みのアプリケーションの組み合わせは、VercelとSupabase、NetlifyとNeonです。その他の組み合わせは、同じレベルの実環境での証拠ではなく、モックテストの対象となっている場合があります。Cloudflare DNSは実験的で、アルファ版の検証済みフローにはまだ含まれていません。

前提条件

GoLiveをインストールする前に、次のものを準備してください。

  • Node.js 20以降。
  • npmとnpx。
  • GitHubおよびSkills CLIのインストール経路を使用する場合はGit。
  • スキルを読み込み、コマンドを実行できるコーディングエージェント。

インストールはCodexとClaude Codeで確認済みです。その他のエージェントクライアントは現在未検証です。

Skills CLIでGoLiveをインストールする

すべてのプロジェクトで一度だけスキルをインストールするには、任意のディレクトリから次のコマンドを実行します。

npx skills add https://github.com/mikehasa/golive-skill --skill golive --global

対話型インストーラーでエージェントを選択します。矢印キーで移動し、Spaceで選択し、Enterで確定します。

Codex向けに非対話形式でインストール

npx skills add https://github.com/mikehasa/golive-skill --skill golive --global --agent codex --yes

Claude Code向けに非対話形式でインストール

npx skills add https://github.com/mikehasa/golive-skill --skill golive --global --agent claude-code --yes

プロジェクトローカルにインストールするには、プロジェクトのリポジトリからコマンドを実行し、--globalを省略します。インストールによって、スキルの指示、プロバイダーのリファレンス、ビルド済みランタイムがコピーされます。プロバイダーのアカウントへの接続やアプリケーションのデプロイは行われません。

npmからインストールする

同じリリースをgolive npmパッケージから利用できます。この経路では、GitやSkills CLIなしでスキルをインストールできます。

Codexへのインストール

npx golive@alpha install --agent codex

Claude Codeへのインストール

npx golive@alpha install --agent claude

現在のプロジェクトではなくホームディレクトリにインストールするには、--globalを追加します。

npx golive@alpha install --agent codex --global

npmインストーラーは既存の保存先を上書きせず、プロバイダーのアカウントにも接続しません。どちらのインストール経路にも同じプロジェクトリリースが含まれています。

npmパッケージでは、個別のターミナル操作も利用できます。

npx golive@alpha help
npx golive@alpha version
npx golive@alpha detect
npx golive@alpha menu
npx golive@alpha plan
npx golive@alpha verify
npx golive@alpha handoff

ターミナルの apply 操作には、承認済みのプラン ID と明示的な確認が必要です。これらのコマンドは個別の操作を実行するものであり、完全な会話型スキルのワークフローの代わりにはなりません。

コーディングエージェントで GoLive を開始する

コーディングエージェントでアプリケーションのリポジトリを開きます。新しくインストールしたスキルが表示されない場合は、スキルを再読み込みするか、新しいエージェントセッションを開始してください。

Codex では、チャットで次のようにスキルを呼び出します。

$golive Help me take this app live.

Claude Code では、次を使用します。

/golive Help me take this app live.

より具体的な指示を自然言語で指定することもできます。

Use the golive skill to take this app live. Keep the providers it already uses.
Show me the destination accounts and plan before changing anything.
Use test resources for now.

golive skill はターミナルコマンドではありません。Skills CLI をインストールしても、グローバルな golive 実行ファイルは追加されません。コーディングエージェントは、インストールされたスキルディレクトリに含まれる CLI を実行します。npm パッケージでは、別途 npx golive@alpha からコマンドを利用できます。

デプロイのワークフローを理解する

通常の実行では、すぐにリソースを作成するのではなく、管理された手順に従います。

  1. 調査: GoLive がリポジトリを分析し、既存のプロバイダー連携と不足しているインフラストラクチャを検出します。
  2. 確認: アプリから判断できない場合、使用するプロバイダーまたはアカウントをエージェントが尋ねます。
  3. 認証: 別のターミナルまたはブラウザーでプロバイダーへのログイン手順を完了します。
  4. 宛先の確認: GoLive が接続先のアカウント、チーム、または組織を確認するため、リソースの作成先を検証できます。
  5. 計画: エージェントが、リソース名、利用可能な場合は ID、設定、変更内容、および関連する費用情報を提示します。
  6. 承認: プランを承認するまで、プロバイダーへの変更は適用されません。
  7. 適用: GoLive が承認済みのリソースをプロビジョニングし、接続します。
  8. 検証: エージェントがデプロイ、連携、およびアプリケーションの観測可能な動作を確認します。
  9. 記録: 作成されたリソースと検証結果が保存され、後でのステータス確認、引き継ぎ、または削除に利用できます。

承認後にプランが変更された場合、GoLive は再度の承認を要求します。認証やドメインの接続など、一部の作業は初回デプロイ後のフォローアッププランで実行されることがあります。

例: すでに Supabase を使用しているアプリをデプロイする

リポジトリに Supabase 連携はすでに含まれているものの、ホスティングプロバイダーが選択されていないとします。次のように開始します。

$golive Take this app live using test resources. Keep its existing Supabase integration.

GoLive は、Vercel、Netlify、または別のプロバイダーを使用するか尋ねる場合があります。Vercel を選択すると、アルファ版で実際にテストされている Vercel と Supabase のパスに従います。その後、既存の Supabase プロジェクトを使用するか、新しい使い捨てのテストプロジェクトを作成するかを判断します。

別途認証を求められる場合があります。

vercel login
supabase login

ログイン後、接続されている Vercel チームと Supabase 組織をエージェントに特定させます。プランを承認する前に、これらの宛先を慎重に確認してください。

承認済みのプランには、ホスティングプロジェクトの作成、データベースプロジェクトの作成または選択、必要な環境値の転送、アプリケーションのデプロイ、結果の検証などが含まれる場合があります。完了すると、GoLive は本番 URL、検証の証拠、および未完了のチェックを報告します。

セットアップ中の認証情報を保護する

プロバイダーのシークレットは、プロバイダーのワークフローで特定の安全な方法が明示的に必要とされる場合を除き、エージェントのチャットに貼り付けないでください。macOS では、GoLive は必要な API キーの入力にネイティブの非表示入力ダイアログを使用できます。ダイアログには、キーが必要な理由と保存先が表示されます。値はチャットやコマンド出力に表示されず、ローカルの認証情報ファイルに直接書き込まれます。

その他のプラットフォームでは、エディターがフォールバックとして使用されます。要求されている内容を引き続き確認し、可能な場合は適切な権限範囲のテスト用認証情報を使用して、宛先アカウントが正しいことを確認してください。

ホームページ以外も検証する

デプロイ URL が正常に取得できたことは、始まりにすぎません。検証は、アプリケーションの実際の動作に合わせる必要があります。選択したパスに応じて、GoLive は次のような項目を確認できます。

  • ホスティングのデプロイが完了し、アプリケーションを提供しているか。
  • データベースの環境変数がデプロイに組み込まれているか。
  • アプリケーションがデータベースに接続できるか。
  • 対応しているパスで、認証付き CRUD またはセッション分離のチェックが成功するか。
  • カスタムドメインに必要な DNS レコード、所有権の証明、HTTPS 応答があるか。
  • Resend が送信ドメインを検証し、アプリケーションが実際の送信を実行できるか。
  • Stripe のテスト決済が、署名検証済みの Webhook イベントに到達するか。

GoLive が観測できないものは、明示的に未検証のままにする必要があります。たとえば、GoLive は受信者の受信トレイを確認しないため、メールが受信トレイに届いたことは人間が確認します。

デプロイのドリフトを確認する

GoLive には、記録された期待値と観測可能なプロバイダーの状態を比較するオンデマンドの golive status ワークフローが実装されています。これは継続的な監視やアラートではなく、ドリフトチェックです。

golive status

npm インストールを使用している場合は、インストールされているアルファ版で利用可能なターミナル操作について、パッケージのヘルプを確認してください。

npx golive@alpha help

手動でプロバイダーを変更した後、プロジェクトを別の所有者に引き渡す前、または廃棄を計画する前に、ステータスチェックを実行してください。アクセスできないリソースや検証できないリソースは、正常だと判断せず、調査すべき指摘事項として扱います。

引き継ぎ記録を作成する

引き継ぎワークフローは、GoLiveが認識しているインフラストラクチャの所有権に関する文書を作成します。READMEには、golive handoff --writeが使い捨てのVercel専用フィクスチャで実行され、生成された成果物が監査されて、認証情報のような値が含まれないことを確認したと記載されています。

golive handoff --write

引き継ぎは、プロジェクトをクライアントや別の開発チームに移管する前に役立ちます。生成されたドキュメントとJSON版を確認し、すべてのプロバイダーアカウントとリソース所有者を確認してください。シークレットは、適切な安全な経路で別途共有します。

使い捨てリソースを安全に廃棄する

テストデプロイが不要になったら、スキルに削除計画を作成させます。

$golive Plan teardown for the resources created by this project. Show me everything that will be removed before deleting anything.

廃棄処理には承認ゲートがあります。実環境での検証では、使い捨てのNetlifyプロジェクトについて、--confirm-destroyなしでは削除がブロックされ、明示的な確認後に削除されることを確認しました。テスト済みのクリーンアップには、DNSレコード、Resendの送信キー、GoLiveが作成したStripeのテストモード用エンドポイントも含まれています。

廃棄計画では、共有データベース、ドメイン、DNSゾーン、メール設定、決済エンドポイント、価値のあるデータが保存されている可能性のあるプロジェクトを必ず確認してください。GoLiveがリソースを削除できることは、削除が適切であることを意味しません。

高度なヒント

初期の実験ではテスト済みの組み合わせを優先する

現時点で最も強い根拠を得るには、VercelとSupabase、またはNetlifyとNeonから始めてください。他の組み合わせも動作する可能性はありますが、モックによるカバレッジは実環境での完了済みの実行と同等ではありません。

明示的なテストリソースを使用する

アルファ版を評価する際は、使い捨てリソースまたはテストリソースを指定してください。Stripeのサポートはテストモードでのみ明確に検証されています。READMEでは、同等のライブモード決済対応、返金処理、サブスクリプション処理、権限付与の検証については主張していません。

Supabase Authのオプションの認証フローは慎重に宣言する

Supabase Authのポリシー設定では、承認済みの計画を通じて、サインアップ、メール確認、パスワードの最小長、メーラー設定、サイトURL、リダイレクト許可リストを管理できます。オプションのサインアップフローは、次のような設定で有効にします。

auth:
  e2e: true

パスワード回復とアカウント分離にも設定フラグがあります。

auth:
  recovery: true
  isolation: true
  identityPath: /your-identity-route
  isolationPath: /your-rows-route

これら後者のフローは実装済みで、モックによるカバレッジもありますが、アルファ版のドキュメントによると、まだ実環境での検証は完了していません。分離には想定された動作を持つアプリケーションルートが必要です。ルートがない場合や適切でない場合は、誤って成功と判定するのではなく、引き継ぎタスクが生成されます。

確認フラグを安全ゲートとして扱う

実稼働システムに影響を与える可能性のある操作には、明示的なゲートが使用されます。プロジェクトで説明されている例には、DNS書き込み用の--confirm-dns、一部の実アカウントまたはライブ値を扱う操作用の--confirm-live、廃棄用の--confirm-destroyがあります。正確な計画と対象を確認せずに、これらのチェックを回避しないでください。

組み込みアダプターとガイド付きプロバイダーを区別する

未対応のプロバイダーについては、GoLiveはダッシュボードの案内に切り替える前に、公式CLI、公式MCP統合、またはAPIを確認します。これはあくまでベストエフォートの支援です。完了度や検証の深さは保証されないため、自動化を継続できない場合は、具体的なブロッカーと次のアクションが示されることを想定してください。

リリース機能の実験は慎重に行う

このプロジェクトには、実装済みですが実環境ではまだ検証されていない、プレビュー、リリースチェック、プロモーション、ロールバックの機能が含まれています。プレビュー動作はgolive.yamlでオプトインします。

release:
  preview: true

プロモーションとロールバックには、追加のオプトイン値を使用します。

release:
  preview: true
  promote: true
  rollback: true

これらの機能はまだ実環境で検証されていないため、管理されたテスト環境でのみ使用し、生成された各計画を確認してください。デプロイに成功すると、プロバイダーのデプロイ識別子を.golive/state.jsonに記録できます。これにより、後続の機能は曖昧なURLではなく、特定のデプロイを参照できます。

重要な制限事項

  • このプロジェクトは初期アルファ版ソフトウェアです。
  • すべてのフレームワークや、新規ユーザーのアカウント設定が検証されているわけではありません。
  • 専用バックエンドサーバー、コンテナ、オブジェクトストレージ、監視、分析、バックグラウンドジョブ、その他いくつかのローンチカテゴリは、引き続きロードマップ項目です。
  • 継続的な監視とアラートは含まれておらず、ステータスチェックはオンデマンドです。
  • Cloudflare DNSは、検証済みのアルファ版経路ではなく、試験的な機能です。
  • Supabaseのパスワード回復とアカウント分離は実装済みですが、実環境での検証は完了していません。
  • Supabase Auth向けのResendカスタムSMTPは実装済みで、モックによるカバレッジもありますが、実環境では検証されていません。
  • ガイド付きプロバイダーには、組み込みアダプターと同じ完了保証や検証保証はありません。

結論

GoLiveは、エージェントが構築したアプリケーションを、自分で所有するインフラストラクチャへ移行するための、承認主導の方法を提供します。使い捨てリソースから始め、実環境でテスト済みのプロバイダーの組み合わせを優先し、変更を承認する前に対象アカウントを確認して、未解決の指摘事項をすべて確認してください。デプロイが実証できたら、ステータスチェックと引き継ぎドキュメントを使って運用上のコンテキストを保持し、テストリソースが不要になった時点でゲート付きの廃棄ワークフローを使用します。