launch-with-aws

AWS で起動する

CLI スクリプトを使用して、AWS への移行を最初から最後まで実行します。ユーザーのウェブアプリケーションを受け取り、分析して、コスト見積もり付きの移行計画を生成し、デプロイ可能な AWS Blocks インフラストラクチャコードを提供します。

AWS MCP サーバーの使用を推奨しますが、必須ではありません。このスキルは、あらゆるエージェント環境で CLI スクリプトを使用して単独で動作します。

スクリプトの呼び出し

すべてのコマンドは以下を介して実行します。

python3 scripts/launch_with_aws.py <command> [args...]

ここで、scripts/ はこのスキルのディレクトリからの相対パスです。コマンドを実行する前に、エージェントは作業ディレクトリをスキルのルートに設定する必要があります。

必須ファイル：launch_with_aws.py、launch_config.py、auth.py、auth_callback_server.py、launch_api_client.py、archive.py、サービスモデル。MCP 経由で読み込む場合は、実行前にすべてを取得し、ディレクトリ構造を維持したまま一時ディレクトリに書き込んでください。

各コマンドは、成功すると標準出力に JSON を出力し、失敗すると標準エラー出力に JSON エラーを出力してゼロ以外の終了コードで終了します。

任意のコマンドに追加できるグローバルフラグが 2 つあります。--region <region> は、サービスが移行を実行するリージョンを選択し、--aws-mcp-url <url> は、エージェントが接続している AWS MCP サーバーの URL を渡します。手順 2 を参照してください。

依存関係：Python 3.10 以降および boto3。スクリプトは起動時に両方を確認し、いずれかが不足している場合は明確なエラーメッセージを表示して終了します。

サポート対象のアプリケーションタイプ

バイブコーディングプラットフォームで構築されたフルスタックアプリ、およびフロントエンドのウェブアプリケーションとウェブサイト（静的サイト、SPA、静的エクスポート対応の SSR フレームワーク）。

オリジンプラットフォーム	対象範囲
Lovable	Lovable で生成されたフルスタックアプリ（React + Supabase）
Bolt.new	Bolt.new で生成されたフルスタックアプリ（React + Supabase）
Replit	Replit でホストされたフルスタックアプリ（React + Express.js + PostgreSQL）

フレームワーク	例
React エコシステム	React、CRA、Vite + React、Gatsby、Docusaurus
Vue エコシステム	Vue、Nuxt（静的エクスポート）、VitePress
Angular	Angular
Svelte エコシステム	Svelte、SvelteKit（静的エクスポート）
静的エクスポート対応 SSR	Next.js、Nuxt、Astro、SvelteKit
その他の最新フレームワーク	Astro、Solid、Preact、Lit、Eleventy
Vite（汎用）	Vite ベースのあらゆるアプリ

その他のフレームワークも動作する場合があります。ユーザーのアプリがこれらに該当しない場合は、以下のサポート対象外のアプリケーションの処理を参照してください。

移行されるものとそのまま残るもの

Lovable / Bolt.new アプリ（Supabase バックエンド）：

コンポーネント	動作
フロントエンドとホスティング	AWS（S3 + CloudFront + Lambda）に移行されます
エッジ関数 / サーバー関数	AWS Lambda に移行されます
AI 呼び出し（例：Lovable AI Gateway）	Amazon Bedrock に移行されます
データベース（Supabase DB）	Supabase に残り、移行されません
認証（Supabase Auth）	Supabase に残り、移行されません
ストレージとリアルタイム機能	Supabase に残り、移行されません

AWS でホストされるアプリケーションから、データベース、認証、ストレージ、リアルタイム機能のために、引き続き Supabase が呼び出されます。

Replit アプリ（Express.js + PostgreSQL）：

コンポーネント	動作
フロントエンドとホスティング	AWS（S3 + CloudFront + Lambda）に移行されます
サーバーロジック（Express.js）	AWS Lambda（API Gateway）に移行されます
データベース（PostgreSQL）	スキーマとコードは AWS（Aurora Serverless / DynamoDB）に移行されます。既存のデータは移行されません。お客様がデータを別途エクスポートしてインポートする必要があります。
認証（Replit Auth）	コードは AWS（Cognito）に移行されます。既存のユーザーアカウントは移行されません。お客様が Cognito でユーザーを再作成するか、招待する必要があります。
リアルタイム機能（WebSockets）	AWS（API Gateway WebSocket）に移行されます
ファイルストレージ	AWS（S3）に移行されます。既存のファイルは移行されません。

Replit アプリのインフラストラクチャとコードは AWS ネイティブのサービスに移行されますが、既存のデータ、ユーザーアカウント、ファイルはお客様が別途移行する必要があります。

入力の解決

ユーザーの入力をローカルディレクトリのパスに解決します。

• ユーザーがローカルパスを指定した場合：そのパスをそのまま渡します。
• ユーザーがGitHub URLを指定した場合：リポジトリをローカルにクローンし、そのディレクトリを使用します。
• どちらも指定されていない場合：現在の作業ディレクトリを使用します。アプリのディレクトリに見えない場合は、ユーザーにパスを尋ねます。

フロー

スクリプトコマンドを順番に実行し、各ステップで結果をユーザーに提示します。

1. 認証

python3 scripts/launch_with_aws.py auth-start

必ず最初に実行します。すぐに次の JSON を返します。

• すでに認証済みの場合：{"authenticated": true, "reusedCachedSession": true, "baseUrl": "..."}
• サイレント更新に成功した場合：{"authenticated": true, "reusedCachedSession": false, "baseUrl": "..."}
• 対話型サインインが必要な場合：{"authenticated": false, "signInUrl": "https://...", "pid": 12345, "port": 54321, "baseUrl": "..."}

authenticated が false の場合は、直ちに signInUrl をユーザーに表示（ブラウザーで開けるようにするため）し、同じ応答内で auth-wait を呼び出します。

python3 scripts/launch_with_aws.py auth-wait <pid>

ここで <pid> は auth-start の応答に含まれる pid の値です。ユーザーがブラウザーでのサインインを完了するまで（または 600 秒経過してタイムアウトするまで）処理がブロックされます。成功すると {"authenticated": true, "baseUrl": "..."} が返されます。

ID プロバイダーが有効期限を設定していない場合でも、セッションの有効期間は最長 90 日です。それ以降は、再度対話型フローが必要になります。

認証せずに現在のセッションを確認する場合、またはサインアウトする場合：

python3 scripts/launch_with_aws.py session-status
python3 scripts/launch_with_aws.py sign-out

session-status は、セッションの有無と、トークンおよびセッション全体の有効期限までの時間を報告します。sign-out は、リフレッシュトークンの失効をベストエフォートで試み、ローカルの ~/.launch-with-aws/session.json を削除します。共有または信頼できないワークステーションでは、作業が終わったら sign-out を実行してください。

2. Launch を作成する

ローカルディレクトリの場合は、以下のデータ取り扱いに関する確認文をそのまま提示し、明示的な承認を待ちます。

ソースコードは、アプリケーションを分析して移行計画を生成するため、[regionName], [region]（[sourceLabel]）の AWS サービスを使用する Launch にアップロードされます。後で実行を承認した場合、AWS がホストするエージェントが計画に従ってソースコードのコピーを変更し、ダウンロード可能な移行済みスナップショットを生成します。アップロードされたソースコードと関連する Launch データは、転送中および保存時に暗号化され、復旧のため最長 48 時間保持されます。お客様のデータが AI モデルのトレーニングに使用されることはありません。Git の履歴、Git で無視されるファイル、および一般的な機密ファイルのパターンに一致するファイルは除外します。機密ファイルのフィルタリングはベストエフォートです。プロジェクトにシークレットが含まれていないか確認してください。続行しますか？または、代わりに [otherRegions regionName] で移行を実行するには、その旨を返信してください。

resolve-region の結果からリージョンの各フィールドをそのまま設定し、otherRegions の各項目を代替として提示します。エージェントが AWS MCP サーバーに接続されている場合は、そのサーバーの URL をそのまま渡します。スクリプトはそこからリージョンを読み取り、それがシグナルとして扱われるかどうかを判断します。

python3 scripts/launch_with_aws.py resolve-region [--aws-mcp-url https://aws-mcp.<region>.api.aws/mcp]

{"region": ..., "regionName": ..., "source": ..., "sourceLabel": ..., "baseUrl": ..., "otherRegions": [{"region": ..., "regionName": ...}]} を返します。

ユーザーが明示的に確認するまで、create-launch を呼び出さないでください。応答がない場合、または曖昧な場合は、承認されていないものとして扱います。otherRegions の項目を指定することは、リージョンの選択と承認の両方を意味します。その項目の region を --region として渡し、再度確認を求めないでください。

python3 scripts/launch_with_aws.py create-launch <app-directory> [name] --region <region>

ディレクトリを ZIP 圧縮してアップロードし、その後 Launch を作成します。launch.launchId と作成先の region を含む完全な launch オブジェクトを返します。このリージョンが、ユーザーの保存済みデフォルトになります。Launch は作成されたリージョン内にのみ存在します。後続のコマンドでは、毎回その Launch の --region を渡してください。

Launch は analyzing ステータスで開始し、分析と計画の作成が自動的に進行します。

3. Launch のステータスをポーリングする

python3 scripts/launch_with_aws.py get-launch-status <launch-id> --region <region>

status が planned（実行準備完了）または failed になるまでポーリングします。それ以外のステータスはユーザーに報告してください。主なステータスの推移は次のとおりです。

• analyzing → アプリの種類と依存関係を検出中
• planning → 移行計画を生成中
• planned → 実行準備完了
• executing → デプロイ中
• completed → 完了
• failed → failureReason を確認

4. Launch の詳細を取得して確認する

python3 scripts/launch_with_aws.py get-launch <launch-id> plan,cost_estimate --region <region>

Launch の詳細をすべて取得します。2 番目の引数には、カンマ区切りの include リストとして analysis、plan、execution、cost_estimate、download_url を指定できます。

費用の見積もりと計画をユーザーに提示します。応答の costEstimate フィールドには、estimatedMonthlyCost、region、およびサービスごとの費用内訳である services が含まれます。

確認ゲート — 以下を提示し、明示的な承認を待ちます。

移行の概要

• アプリの種類：[analysis から検出した種類]
• アーキテクチャ：[plan の移行先アーキテクチャ]
• 月額費用の見積もり：$X.XX/月（[costEstimate.region] の料金）
• 移行の実行先：[regionName], [region]

続行しますか？AWS が管理する環境で移行を実行し（お客様に費用は発生しません）、ダウンロード可能な移行済みスナップショットを生成します。

ユーザーが明示的に確認するまで、start-launch-execution を呼び出さないでください。

5. 実行を開始する

python3 scripts/launch_with_aws.py start-launch-execution <launch-id> --region <region>

デプロイを開始します。その後、status が completed または failed になるまで get-launch-status でポーリングします。ポーリングの間隔は最低 30 秒空けてください。

6. ダウンロードする

python3 scripts/launch_with_aws.py get-launch-download-url <launch-id> --region <region>

ダウンロード URL 全体を必ずユーザーに提示してください。ユーザーは、移行済みスナップショットを直接ダウンロードする際、または参照用に URL が必要になる場合があります。

7. Launch の一覧表示または削除

python3 scripts/launch_with_aws.py list-launches
python3 scripts/launch_with_aws.py delete-launch <launch-id> --region <region>

list-launches は両方のリージョンを照会し、各 Launch の region を含む items を返します。1 つのリージョンを照会するには --region を追加してください。到達できないリージョンがある場合、コマンドが失敗するのではなく、そのリージョンは errors の下に報告されます。ただし、照会したすべてのリージョンで失敗した場合は、そのエラーでコマンドが終了します。

8. 移行後：移行したコードをローカルに適用する

ダウンロード URL を取得した後、ユーザーのプラットフォームに合わせてコマンドを調整してください（POSIX でない場合）。

ステップ A：ダウンロードして展開する

curl -L -o /tmp/migration-snapshot.zip "<download_url>"
mkdir -p /tmp/migration-output
unzip -o /tmp/migration-snapshot.zip -d /tmp/migration-output

ステップ B：ローカルのワークスペースを準備する

ユーザーの作業ディレクトリに変更がないことを確認します。

cd <user-app-directory>
git status

コミットされていない変更がある場合は、まずユーザーにコミットするか、スタッシュするよう伝えてください。作業ツリーに変更がある状態では、絶対に続行しないでください。

ステップ C：移行を適用する（3-way merge）

移行用のブランチを作成し、移行したファイルを重ねます。

cd <user-app-directory>
git checkout -b aws-migration
rsync -a /tmp/migration-output/ .
git status
git diff --stat

ユーザーと一緒に変更内容を確認します。特に、次の追加項目を取り上げてください。

• aws-blocks/ — AWS Blocks のインフラストラクチャ定義
• DEPLOY.md — デプロイ手順
• 変更された設定ファイル

ユーザーの既存ファイルと競合する場合は、その内容を提示し、解決方法を尋ねてください。

ステップ D：DEPLOY.md に従う

プロジェクトのルートにある DEPLOY.md ファイルを読み、ユーザーの AWS アカウントにアプリをデプロイする手順に従ってください。一般的な手順は次のとおりです。

1. AWS 認証（aws login --profile aws-migrate --region us-east-1）
2. CDK のブートストラップ（初回のみ）：npm install && npx cdk bootstrap
3. デプロイ：npx cdk deploy --all --progress events
4. CDK の処理完了時に出力される CloudFront URL を確認します。

重要： 必ず移行後の出力に含まれる DEPLOY.md を読んでください。このファイルは、このアプリとアーキテクチャに合わせて生成されています。記憶にあるデプロイ手順を前提にしないでください。

サポート対象外のアプリケーションの取り扱い

分析中に failureReason がサポート対象外のアプリタイプを示して起動に失敗した場合（またはユーザーのスタックがサポート対象リストに一致しない場合）：

1. ユーザーに次のように伝えます。「このアプリタイプは、現時点では Launch with AWS で直接サポートされていません。この種類のアプリケーションのデプロイに役立つ他のスキルを検索します。」

2. アプリタイプに基づいて、関連するスキルを検索します（例：aws-serverless、aws-containers、aws-database、aws-deployment、aws-cdk、aws-ai-ml）。