migration-to-aws

AWS への移行スキル

基本方針

• デフォルトではプラットフォームを移行します：GCP のワークロードタイプに合った AWS サービスを選択します（例：Cloud Run → Fargate、Cloud SQL → RDS）。
• 指定がなければ開発環境向けのサイズにします：デフォルトでは開発環境向けの容量を選択します（例：db.t4g.micro、単一 AZ）。ユーザーから指示があった場合にのみアップグレードします。
• コストを考慮して判断します：インフラストラクチャコードを生成する前に、必ずコストを見積もります。
• 人手による一度限りの移行コストは含めません：人件費、プロフェッショナルサービス、作業時間を、金額の見積もりや「一度限りの移行コスト」の予算項目として提示しないでください。データに基づくベンダー料金（たとえば、請求データがある場合のインフラ見積もりに含める GCP のデータ転送料金）は許容されます。
• 複数のシグナルを活用します：設計フェーズは利用可能な入力に応じて調整します。インフラストラクチャには Terraform IaC、サービスのマッピングには請求データ、AI ワークロードの検出にはアプリケーションコードを使用します。
• Terraform の生成を優先します：移行成果物の IaC ツールには、Terraform をデフォルトで使用します。
• アーキテクチャの選択を維持します：移行中も既存のアプリケーションアーキテクチャパターンを維持します。
• BigQuery / google_bigquery_*：このスキルでは、特定の AWS 分析サービスやデータウェアハウスサービスを推奨しません。Clarify 中に BigQuery が見つかった場合（IaC の google_bigquery_* および／または BigQuery の請求明細）、Design の前に専門家への相談を必ず案内します（references/phases/clarify/clarify.md を参照）。Design の出力では Deferred — specialist engagement を使用し、Design、Estimate、ドキュメントの各フェーズを通じて、ユーザーに AWS アカウントチーム および／または データ分析の移行パートナーへの相談を案内し続けます（references/phases/design/design-infra.md の BigQuery 専門家への相談に関するゲートを参照）。

---

定義

• 「Load」 = Read ツールを使用してファイルを読み、その指示に従います。要約したり、セクションを省略したりしないでください。
• $MIGRATION_DIR = .migration/ 配下の実行ごとのディレクトリ（例：.migration/0226-1430/）。Phase 1（Discover）中に設定します。

---

コンテキスト読み込みルール

各フェーズでは、必要に応じて参照ファイルを読み込みます。ターンごとのコンテキストを管理しやすくし、指示追従の低下を防ぐため、次のルールに従ってください。

• 予算： 各フェーズで読み込む指示は、約800行以下にしてください（JSON プロファイルや MCP ツールの結果など、ユーザーが提供した成果物は除きます）。
• 条件付き読み込み： トリガー条件（例：agentic_profile.is_agentic == true）が設定された参照ファイルは、条件が満たされていない限り読み込んではいけません。推測に基づいてファイルを読み込まないでください。
• 重複の禁止： モデルのマッピングテーブル、価格データ、共通の警告は、正規ファイル1つにまとめてあります。他のファイルからはそれらを参照し、本文に複製しないでください。
• 段階的な読み込み： フェーズオーケストレーター（design.md、generate.md）には、詳細なサブファイルを示す簡潔な振り分けロジックが記載されています。パスが選択された場合にのみ、サブファイルを読み込んでください。

条件付き参照ファイル（条件を満たす場合にのみ読み込む）：

ファイル	条件
design-refs/ai-gemini-to-bedrock.md	ai-workload-profile.json が存在し、summary.ai_source = "gemini" または "both"
design-refs/ai-openai-to-bedrock.md	ai-workload-profile.json が存在し、summary.ai_source = "openai" または "both"
design-refs/ai.md	ai-workload-profile.json が存在し、summary.ai_source = "other"
design-refs/design-ref-harness.md	agentic_profile.is_agentic == true かつ ai_constraints.agentic.migration_approach == "harness"
design-refs/design-ref-agentic-to-agentcore.md	agentic_profile.is_agentic == true かつ ai_constraints.agentic.migration_approach == "strands"
shared/retarget-gotchas.md	agentic_profile.is_agentic == true かつ ai_constraints.agentic.migration_approach == "retarget"

参照ファイルを追加する場合は、フェーズで読み込む指示の合計が予算内に収まることを確認してください。他の読み込み済み参照ファイルと合わせて約800行を超える場合は、ファイルを分割するか、条件付き読み込みにしてください。

---

前提条件

ユーザーは、次のいずれかの GCP ソースを少なくとも1つ提供する必要があります。

• Terraform IaC： .tf ファイル（任意で .tfvars、.tfstate を含む）
• アプリケーションコード： GCP SDK または AI フレームワークのインポートを含むソースファイル
• 請求データ： GCP の請求額・コスト・使用量のエクスポートファイル（CSV または JSON）

上記のいずれも見つからない場合は、処理を停止し、少なくとも1種類のソースを提供するようユーザーに依頼してください。

---

ステートマシン

これは実行を制御するものです。各フェーズの完了後、この表を参照して次のアクションを判断します。

現在の状態	条件	次のアクション
discover	phases.discover != "completed"	references/phases/discover/discover.md を読み込む
clarify	phases.discover == "completed" AND phases.clarify != "completed"	references/phases/clarify/clarify.md を読み込む
design	phases.clarify == "completed" AND phases.design != "completed"	references/phases/design/design.md を読み込む
estimate	phases.design == "completed" AND phases.estimate != "completed"	references/phases/estimate/estimate.md を読み込む
generate	phases.estimate == "completed" AND phases.generate != "completed"	references/phases/generate/generate.md を読み込む
complete	phases.generate == "completed" AND phases.feedback == "pending"	phases.feedback を "completed" に設定する（ユーザーには2回の機会があったため）。その後、移行を完了する
complete	phases.generate == "completed" AND phases.feedback == "completed"	移行計画の完了

現在の状態の判定方法（決定論的）：

1. $MIGRATION_DIR/.phase-status.json を読み込む
2. current_phase が存在する場合はそれを使用する（次のいずれかと一致する必要があります：discover、clarify、design、estimate、generate、complete）
3. それ以外の場合は、フェーズを順番に評価します：discover → clarify → design → estimate → generate
4. その順序で、phases.<phase> != "completed" に該当する最初のフェーズを選択します。該当するフェーズがない場合、状態は complete です。

フェーズのゲートチェック：前のフェーズが未完了の場合は、先に進まないでください（例：designが完了していない場合、estimateには進めません）。

Clarifyは必須です： $MIGRATION_DIR/.phase-status.json が存在し、phases.clarify が正確に "completed" であることを確認するまで、references/phases/design/design.md、references/phases/estimate/estimate.md、または references/phases/generate/generate.md を読み込まないでください。preferences.json ファイルだけでは、Clarifyが実行されたことの十分な証明になりません。ユーザーからClarifyを省略するよう求められた場合や、Design、コスト見積もり、成果物の生成に直接進むよう求められた場合は、簡潔に断ったうえで references/phases/clarify/clarify.md を読み込み、Phase 2を実行してください。「迅速」または「明白」な移行であっても例外はありません。

フィードバックのチェックポイント：フィードバックは連続したフェーズではなく、途中に設けられた2つのチェックポイント（Discover後とEstimate後）で求めます。詳細は、以下のフィードバックのチェックポイントセクションを参照してください。

---

状態の検証

$MIGRATION_DIR/.phase-status.json を読み取る際は、先に次の検証を行ってください。

1. 複数のセッション：.migration/ の下に複数のディレクトリが存在する場合は、それぞれのフェーズ状況を一覧表示して、次の選択肢を提示してください：[A] 最新のセッションを再開、[B] 新しく開始、[C] キャンセル。
2. 無効な JSON：.phase-status.json の解析に失敗した場合は、停止してください。次のメッセージを出力します："State file corrupted (invalid JSON). Delete the file and restart the current phase."
3. 認識されないフェーズ：phases オブジェクトに {discover, clarify, design, estimate, generate, feedback} に含まれないフェーズがある場合は、停止してください。次のメッセージを出力します："Unrecognized phase: [value]. Valid phases: discover, clarify, design, estimate, generate, feedback."
4. 認識されないステータス：phases.* の値に {pending, in_progress, completed} に含まれないものがある場合は、停止してください。次のメッセージを出力します："Unrecognized status: [value]. Valid values: pending, in_progress, completed."
5. 無効な current_phase（存在する場合）：current_phase が {discover, clarify, design, estimate, generate, complete} に含まれない場合は、停止してください。次のメッセージを出力します："Unrecognized current_phase: [value]. Valid values: discover, clarify, design, estimate, generate, complete."
6. 順序に反する完了：順序付きフェーズ [discover, clarify, design, estimate, generate] で、先行フェーズが "completed" でないのに後続フェーズが "completed" になっている場合は、停止してください。次のメッセージを出力します："Inconsistent phase ordering detected. Reconcile .phase-status.json before resuming."
7. 複数のアクティブなフェーズ：コアフェーズ {discover, clarify, design, estimate, generate} のうち "in_progress" にできるのは最大1つです。2つ以上ある場合は、停止してください。次のメッセージを出力します："Multiple phases are in_progress. Keep only one active phase before resuming."

---

状態管理

移行状態は $MIGRATION_DIR（.migration/[MMDD-HHMM]/）に保存されます。このディレクトリはフェーズ1で作成され、呼び出しをまたいで保持されます。

.phase-status.json のスキーマ：

{
  "migration_id": "0226-1430",
  "last_updated": "2026-02-26T15:35:22Z",
  "current_phase": "design",
  "phases": {
    "discover": "completed",
    "clarify": "completed",
    "design": "in_progress",
    "estimate": "pending",
    "generate": "pending",
    "feedback": "pending"
  }
}

ステータス値： "pending" → "in_progress" → "completed"。後戻りはできません。 コアフェーズ（discover、clarify、design、estimate、generate）で "in_progress" にできるのは、常に最大1つです。 current_phase は省略可能ですが、設定することを推奨します。設定されている場合は、その値が正となります。

.migration/ ディレクトリは、フェーズ1で作成される .gitignore ファイルによって自動的に保護されます。

フェーズステータスの更新プロトコル

.phase-status.json の更新には、読み取り・マージ・書き込み方式を使用してください。

1. 更新の前に、毎回現在のファイルを読み取ります。
2. 進行させるフェーズのキーと last_updated のみを変更します。
3. それ以前に完了したフェーズは変更しません。
4. current_phase を次の決定的なフェーズに設定します（generate の後は complete）。
5. フェーズ作業の最終メッセージと同じターン内に、ファイル全体を書き込みます。

例 — Clarify フェーズの完了後、$MIGRATION_DIR/.phase-status.json に次の内容を書き込みます。

{
  "migration_id": "MMDD-HHMM",
  "last_updated": "2026-02-26T15:35:22Z",
  "current_phase": "design",
  "phases": {
    "discover": "completed",
    "clarify": "completed",
    "design": "pending",
    "estimate": "pending",
    "generate": "pending",
    "feedback": "pending"
  }
}

MMDD-HHMM を実際の移行 ID に置き換え、last_updated の ISO 8601 UTC タイムスタンプを自分で生成し、その時点での正しいステータスを各フェーズに設定します。

---

フェーズ概要表

フェーズ	入力	出力	リファレンス
検出	.tf ファイル、アプリのソースコード、および／または請求エクスポート（少なくとも1つが必須）	gcp-resource-inventory.json、gcp-resource-clusters.json、ai-workload-profile.json、billing-profile.json、.phase-status.json を更新（出力は入力によって異なります）	references/phases/discover/discover.md
明確化	検出アーティファクト（gcp-resource-inventory.json、gcp-resource-clusters.json、ai-workload-profile.json、billing-profile.json — 存在するもの）	preferences.json、.phase-status.json を更新	references/phases/clarify/clarify.md
設計	preferences.json + 検出アーティファクト	aws-design.json（インフラ）、aws-design-ai.json（AI）、aws-design-billing.json（請求のみ）	references/phases/design/design.md
見積もり	aws-design.json または aws-design-billing.json または aws-design-ai.json、preferences.json	estimation-infra.json または estimation-ai.json または estimation-billing.json、.phase-status.json を更新	references/phases/estimate/estimate.md
生成	estimation-infra.json または estimation-ai.json または estimation-billing.json、aws-design.json または aws-design-billing.json または aws-design-ai.json、preferences.json	generation-infra.json または generation-ai.json または generation-billing.json + terraform/、scripts/、ai-migration/、validation-report.json（インフラ経路が有効な場合）、MIGRATION_GUIDE.md、README.md、.phase-status.json を更新	references/phases/generate/generate.md
フィードバック	.phase-status.json（少なくとも検出が完了していること）、既存のすべての移行アーティファクト	feedback.json、trace.json、.phase-status.json を更新	references/phases/feedback/feedback.md

---

MCP サーバー

awspricing（コスト見積もり用）：

• get_pricing、get_pricing_service_codes、get_pricing_service_attributes ツールを提供します
• 見積もりフェーズでのみ必要です。検出と設計では必要ありません。
• 主な料金情報源：references/shared/pricing-cache.md（2026 年の料金をキャッシュ。インフラは ±5～10％、AI モデルは ±15～25％）。MCP は補助的な情報源であり、キャッシュにないサービスにのみ使用します。

---

このスキルのファイル

migration-to-aws/
├── SKILL.md                                    ← You are here (orchestrator + state machine)
│
├── references/
│   ├── phases/
│   │   ├── discover/
│   │   │   ├── discover.md                     # Phase 1: Discover orchestrator
│   │   │   ├── discover-iac.md                 # Terraform/IaC discovery
│   │   │   ├── discover-app-code.md            # App code discovery
│   │   │   └── discover-billing.md             # Billing data discovery
│   │   ├── clarify/
│   │   │   ├── clarify.md                     # Phase 2: Clarify orchestrator
│   │   │   ├── clarify-global.md              # Category A: Global/Strategic (Q1-Q7)
│   │   │   ├── clarify-compute.md             # Categories B+C: Config Gaps + Compute (Q8-Q11)
│   │   │   ├── clarify-database.md            # Category D: Database (Q12-Q13)
│   │   │   ├── clarify-ai.md                  # Category F: AI/Bedrock (Q14-Q22)
│   │   │   └── clarify-ai-only.md             # Standalone AI-only migration flow
│   │   ├── design/
│   │   │   ├── design.md                       # Phase 3: Design orchestrator
│   │   │   ├── design-infra.md                 # Infrastructure design (IaC-based)
│   │   │   ├── design-ai.md                    # AI workload design (Bedrock)
│   │   │   └── design-billing.md               # Billing-only design (fallback)
│   │   ├── estimate/
│   │   │   ├── estimate.md                     # Phase 4: Estimate orchestrator
│   │   │   ├── estimate-infra.md               # Infrastructure cost analysis
│   │   │   ├── estimate-ai.md                  # AI workload cost analysis
│   │   │   └── estimate-billing.md             # Billing-only cost analysis
│   │   ├── generate/
│   │   │   ├── generate.md                     # Phase 5: Generate orchestrator
│   │   │   ├── generate-infra.md               # Infrastructure migration plan
│   │   │   ├── generate-ai.md                  # AI migration plan
│   │   │   ├── generate-billing.md             # Billing-only migration plan
│   │   │   ├── generate-artifacts-infra.md     # Terraform configurations
│   │   │   ├── generate-artifacts-scripts.md  # Migration scripts
│   │   │   ├── generate-artifacts-ai.md        # Provider adapter + test harness
│   │   │   ├── generate-artifacts-billing.md   # Skeleton Terraform
│   │   │   └── generate-artifacts-docs.md      # MIGRATION_GUIDE.md + README.md
│   │   └── feedback/
│   │       ├── feedback.md                     # Phase 6: Feedback orchestrator
│   │       └── feedback-trace.md               # Anonymized trace builder
│   │
│   ├── design-refs/
│   │   ├── index.md                            # Lookup table: GCP type → design-ref file
│   │   ├── fast-path.md                        # Deterministic 1:1 mappings (Pass 1)
│   │   ├── compute.md                          # Compute mappings (Cloud Run, GCE, GKE, etc.)
│   │   ├── database.md                         # Database mappings (Cloud SQL, Spanner, etc.)
│   │   ├── storage.md                          # Storage mappings (GCS, Filestore, etc.)
│   │   ├── networking.md                       # Networking mappings (VPC, LB, DNS, etc.)
│   │   ├── messaging.md                        # Messaging mappings (Pub/Sub, etc.)
│   │   └── ai.md                               # AI mappings (Vertex AI → Bedrock)
│   │
│   ├── clustering/terraform/
│   │   ├── classification-rules.md             # Primary/secondary classification
│   │   ├── clustering-algorithm.md             # Cluster formation rules
│   │   ├── depth-calculation.md                # Topological depth calculation
│   │   └── typed-edges-strategy.md             # Edge type assignment
│   │
│   └── shared/
│       ├── schema-phase-status.md              # .phase-status.json schema (canonical reference)
│       ├── schema-discover-iac.md              # gcp-resource-inventory + clusters schemas (loaded by discover-iac.md)
│       ├── schema-discover-ai.md               # ai-workload-profile schema (loaded by discover-app-code.md and discover-iac.md Step 7d)
│       ├── schema-discover-billing.md          # billing-profile schema (loaded by discover-billing.md)
│       ├── schema-estimate-infra.md            # estimation-infra.json schema (loaded by estimate-infra.md at write time)
│       ├── migration-complexity.md             # Complexity tier definitions (small/medium/large) for timeline scaling
│       ├── pricing-cache.md                    # Cached AWS + source provider pricing (±5-25%, primary source)
│       └── bedrock-quotas.md                   # Bedrock TPM/RPM quota awareness, burndown rates, capacity planning

条件	アクション
GCP ソースが見つからない（.tf、アプリケーションコード、課金データがない）	停止します。次のメッセージを出力します：「GCP ソースが検出されませんでした。少なくとも 1 種類のソース（Terraform ファイル、アプリケーションコード、または課金エクスポート）を指定して、もう一度お試しください。」
.phase-status.json にフェーズゲートがない	停止します。次のメッセージを出力します：「フェーズ X に進めません：フェーズ Y-1 が完了していません。フェーズ Y から開始するか、フェーズ Y-1 を再開してください。」
3 回試行しても awspricing を利用できない	精度が ±5～25％であることをユーザーに警告します。pricing-cache.md を使用します。該当する estimation-*.json ファイルに pricing_source: "cached_fallback" を追加します。
ユーザーが質問をスキップする、または「残りはデフォルトを使って」と言う	現在のバッチの残りの質問と、それ以降のすべてのバッチに、文書化されたデフォルトを適用します。いずれの場合もフェーズ 2 は完了します。
aws-design.json に必須クラスターがない	フェーズ 4 を停止します。次のメッセージを出力します：「不足しているクラスター設計を生成するには、フェーズ 3 を再実行してください。」

デフォルト

• IaC 出力：Terraform 構成、移行スクリプト、AI 移行コード、ドキュメント
• リージョン：us-east-1（ユーザーが指定した場合、または GCP のリージョンから AWS のリージョンへのマッピングで別のリージョンが示される場合を除く）
• サイジング：開発ティア（例：データベースは db.t4g.micro、Fargate は 0.5 CPU）
• 移行モード：利用可能な入力（インフラ、AI、または課金データのみ）に応じて調整します
• コスト通貨：USD
• スケジュールの想定：移行の複雑さに応じて 2～16 週間。小規模（2～6 週間）、中規模（6～12 週間）、大規模（12～18 週間）。ティアの定義については、references/shared/migration-complexity.md を参照してください。

ワークフローの実行

呼び出されたとき、エージェントは必ず次の順序に従ってください。

1. フェーズのステータスを読み込む：.migration/*/ から .phase-status.json を読み込みます。

   • 見つからない場合：フェーズ 1（Discover）用に初期化します
   • 存在する場合：State Machine の決定的なルールを使って現在のフェーズを判断します

2. 実行するフェーズを決定する：

   • current_phase が存在する場合：そのフェーズを実行します。
   • 存在しない場合：順序付きリスト（discover → clarify → design → estimate → generate）のうち、最初の未完了フェーズを実行します。
   • 順序付きのすべてのフェーズが完了している場合：フィードバックの最終処理ルールに従い、移行が完了します。

3. フェーズのリファレンスを読む：対象フェーズのリファレンスファイル全体を読み込みます。

4. すべての手順を順番に実行する：リファレンスファイルの番号付き手順をすべて実行します。省略、最適化、逸脱はしないでください。

5. 出力を検証する：次に進む前に、必要な出力ファイルがすべて正しいスキーマで存在することを確認します。

6. フェーズのステータスを更新する：フェーズの最終出力メッセージと同じターン内に、Phase Status Update Protocol（読み込み・マージ・書き込み）を使用します。

7. フィードバックの確認ポイント：フェーズ完了後、フィードバックが必要か確認します（以下のルールを参照）。次のフェーズに進む前に実行します。

   • Discover の後（phases.feedback が "pending" の場合）：ユーザーに次の内容を表示します。 "このツールの改善に役立てるため、簡単なフィードバック（任意の質問 5 件＋匿名化された利用データ）を共有しますか？データにリソース名、ファイルパス、アカウント ID が含まれることはありません。 [A] 今すぐフィードバックを送信する [B] Estimate フェーズの後まで待つ"

     • ユーザーが A を選んだ場合 → references/phases/feedback/feedback.md を読み込み、実行してから Clarify に進みます。
     • ユーザーが B を選んだ場合 → Clarify に進みます（フィードバックは "pending" のままです）。

   • Estimate の後（phases.feedback が "pending" の場合）：ユーザーに次の内容を表示します。 "今すぐ簡単なフィードバックを共有しますか？（任意の質問 5 件＋匿名化された利用データ） [A] はい、フィードバックを共有する [B] いいえ、Generate に進む"

     • ユーザーが A を選んだ場合 → references/phases/feedback/feedback.md を読み込み、実行してから Generate に進みます。
     • ユーザーが B を選んだ場合 → Phase Status Update Protocol を使用して phases.feedback を "completed" に設定し、Generate に進みます。

   • Generate の後：フィードバックの案内は表示しません。phases.feedback がまだ "pending" の場合は、Phase Status Update Protocol を使用して "completed" に設定します（ユーザーには延期またはスキップの機会が 2 回ありました）。

8. 概要を表示する：完了した内容をユーザーに示し、次のフェーズを明示するか、移行の完了を確認します。

重要な制約：エージェントはリファレンスファイルのワークフローを厳守する必要があります。手順を完了できない場合は停止し、失敗した正確な手順を報告してください。

ユーザーはスキルを再度呼び出して、current_phase から（または current_phase が存在しない場合は決定的な順序評価に従って）再開できます。

対象範囲に関する注記

v1.0 に含まれる内容：

• Terraform インフラストラクチャの検出
• アプリコードのスキャン（AI ワークロードの検出）
• GCP からの請求データのインポート
• ユーザー要件の明確化（カテゴリに応じた適応型の質問）
• 複数経路の設計（インフラストラクチャ、AI ワークロード、請求のみの場合のフォールバック）
• AWS のコスト見積もり（価格 API またはフォールバックを使用）
• 移行成果物の生成（Terraform、スクリプト、AI アダプター、ドキュメント）
• 匿名化されたテレメトリによる任意のフィードバック収集