gcp-to-aws

GCP-to-AWS 移行スキル

基本方針

• デフォルトではリプラットフォームを行います：GCP のワークロードタイプに適合する AWS サービスを選択します（例：Cloud Run → Fargate、Cloud SQL → RDS）。
• 指定がない場合は開発環境向けのサイズを選択します：デフォルトでは開発環境向けの容量を使用します（例：db.t4g.micro、単一 AZ）。アップグレードはユーザーの指示があった場合にのみ行います。
• 人手による一度限りの移行費用は含めません：人件費、プロフェッショナルサービス、作業時間を、金額見積もりや「一度限りの移行費用」という予算項目として提示しないでください。データに基づくベンダー料金（請求データがある場合にインフラストラクチャ見積もりに含める GCP のデータ転送アウトバウンド料金など）は含めてもかまいません。
• 複数のシグナルを活用します：利用可能な入力に応じて設計フェーズを調整します。インフラストラクチャには Terraform IaC、サービスのマッピングには請求データ、AI ワークロードの検出にはアプリケーションコードを使用します。
• 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）で設定します。

---

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

各フェーズでは、必要に応じて参照ファイルを読み込みます。1 回あたりのコンテキスト量を管理し、指示に従う能力の低下を防ぐため、次の点に従ってください。

• 予算： 各フェーズで読み込む指示は約 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-anthropic-to-bedrock.md	ai-workload-profile.json が存在し、summary.ai_source が "anthropic" である
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-resource-inventory.json と ai-workload-profile.json の両方が存在する場合、設計用参照ファイルの合計は約 800 行の予算に近づきます。AI 設計用参照ファイルを読み込む前に、次の警告をユーザーに表示してください。

"⚠️ インフラストラクチャと AI ワークロードを含む、大規模なハイブリッドスタックです。完全で正確な提案を行うため、移行を 2 回に分けて実行することをおすすめします。

パス 1 — インフラストラクチャ： Terraform ファイルのみを指定して実行すると、インフラストラクチャのマッピング、Terraform の生成、コストの見積もりを行えます。

パス 2 — AI ワークロード： アプリケーションコードのみを指定して実行すると、Bedrock モデルの推奨、プロバイダーアダプター、AI 移行成果物を取得できます。

両方を組み合わせて実行しますか？（Y/N）"

ユーザーが続行を選択した場合は、複合実行を進めてください。インフラストラクチャの指示を忠実に保つため、インフラストラクチャ用参照ファイルを読み込んだ後に AI 用参照ファイルを読み込んでください。ユーザーが続行を希望しない場合は停止し、入力ソースの種類を 1 つに絞って再実行するよう指示してください。

この警告は参考情報であり、実行を妨げるものではありません。

---

前提条件

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

• 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 を読み込み、フェーズ2を実行してください。「簡単な」移行や「明白な」移行であっても例外はありません。

フィードバックチェックポイント：フィードバックは順次進むフェーズではありません。Discover の後と Estimate の後に挟まれる2つのチェックポイントで提示します。詳細は、以下のフィードバックチェックポイントのセクションを参照してください。

ハンドオフゲートのオーケストレーション（フェイルクローズ）

フェーズ完了時の処理を実行する際は、references/shared/handoff-gates.md を読み込んでください。

1. 単一の $MIGRATION_DIR：移行全体で同じ実行ディレクトリを使用します。複数の .migration/*/ セッション間で成果物を混在させないでください。
2. ディスクから再読み込み：各フェーズの開始前（および各ハンドオフゲートの前）に、必要な成果物を $MIGRATION_DIR/ から読み込みます。チャットの記憶に頼らないでください。
3. HANDOFF_OK の場合のみ進行：オーケストレーターが HANDOFF_OK | phase=<name> | artifacts=... を出力した場合に限り、フェーズは完了です。この出力がない状態で次のフェーズを読み込まないでください。
4. GATE_FAIL の場合：失敗を示す行を平易な言葉でユーザーに出力します。ゲートを通過させるために成果物を変更しないでください。次のフェーズに進まないでください。再実行するフェーズをユーザーに伝えてください。
5. 再開：後続フェーズの完了後に前のフェーズを再実行するには、ユーザーの明示的な確認が必要です。後続フェーズは "pending" にリセットする必要があります。handoff-gates.md の再開表を参照してください。

Generate フェーズでは、migration-report.html を書き込む前に references/shared/validate-artifacts.md も読み込みます。

---

状態の検証

$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つです。複数ある場合は停止します。次の内容を出力します："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 は補助的な情報源であり、キャッシュにないサービスにのみ使用します。

---

このスキルのファイル

gcp-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–Q13b)
│   │   │   ├── 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)
│       ├── handoff-gates.md                    # Fail-closed phase handoff protocol (GATE_FAIL / HANDOFF_OK)
│       ├── validate-artifacts.md               # Pre-report validation (Generate Step 0; read-only)
│       ├── 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 を読み込みます。

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

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

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

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

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

5. 出力を検証する：次に進む前に、必要な出力ファイルがすべて存在し、正しいスキーマになっていることを確認します。フェーズオーケストレーターは shared/handoff-gates.md に従って完了ハンドオフゲートのチェックを実行します。

6. ハンドオフゲート：shared/handoff-gates.md に従って HANDOFF_OK または GATE_FAIL を出力します。GATE_FAIL の場合は停止します。フェーズのステータスを更新したり、次のフェーズを読み込んだりしないでください。

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

8. フィードバックチェックポイント：フェーズ完了後、フィードバックのタイミングかどうかを確認します（以下のルールを参照）。これは次のフェーズに進む前に実行します。

   • 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回ありました）。

9. 概要を表示する：実施した内容をユーザーに示し、次のフェーズを強調するか、移行が完了したことを確認します。

重要な制約：エージェントはリファレンスファイルのワークフローに厳密に従う必要があります。ステップを完了できない場合は、停止して失敗したステップを正確に報告します。

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

対象範囲の注記

v1.0 に含まれるもの：

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