Claude Codeのmigration-to-awsプラグインでGCPからAWSへの移行を計画する

migration-to-awsは、Terraformで管理しているGCP(Google Cloud)の環境をAWSへ移すための計画を、Claude Codeの上で作るプラグインです。Amazon Web Servicesが提供し、リソースの洗い出し、移行要件の聞き取り、AWSサービスへの対応づけ、月額見積もり、実行計画までを5段階で進めます。

注意点が1つあります。Claude公式のマーケットプレイスのページには掲載されている一方、配布元のGitHubリポジトリでは2026年4月にこのプラグインが削除されています。この記事では、プラグインが何をするかと、導入前に突き合わせておきたい食い違いの両方を扱います。

5段階のワークフローは何を出力するのか

マーケットプレイスのページによると、プラグインは「Discover(探索)」「Clarify(確認)」「Design(設計)」「Estimate(見積もり)」「Execute(実行計画)」の5段階で進みます。方針は、GCPのサービスに対応するAWSサービスへ載せ替える「リプラットフォーム」です。

ここで作られるのは計画書です。削除直前のスキル定義では、IaCコードの生成は行わず、設計・見積もり・実行計画を出す範囲と書かれていました。AWS側のTerraformやCDKを書いてくれるわけではなく、実際の構築は別の作業になります。

前提はTerraformだけなのか

スキルの前提条件は、1つ以上の.tfファイルです。.tfvarsや.tfstateは任意で、.tfが見つからなければ、その場で止めて提供を求めます。

アプリのコード走査とGCPの請求データの取り込みは、削除直前のスキル定義では「今後の版で対応」と書かれていました。ところが配布元に残るCodex向けの定義ファイル(plugin.json)の説明文には、利用状況・地域・請求データを評価して、AWSへの移行か現状維持かを勧めるとあります。説明文は広い範囲を謳っていて、スキル本体が実際に扱う入力はTerraformのファイルだった、という差があります。

どちらを信じるかは、手元で動かして確かめるのが確実です。Terraformを使っていない環境では、少なくとも削除直前のスキル定義に従う限り、Discoverの段階で止まります。

8つの質問と、答えなかったときの既定値

Clarifyの段階では、回答方法を4つから選びます。

質問の主題は、移行期限、最優先の関心事、チームのAWS経験、トラフィックの傾向、データベースの要件、コストへの敏感さ、GCPに残す予定の有無、準拠すべき規制の8つです。モードCの既定値は次のとおりです。

既定値のまま進めると、「新人チームがコスト最優先でGCPから完全に出る」という前提の設計になります。本番のワークロードなら、モードAかBで自分の状況を答えたほうが設計の前提が実態に合います。

GCPからAWSへの対応づけはどう決まるのか

Designの段階は二段構えです。

1. 高速対応表(fast-path)に載っているリソースは、判断を挟まず1対1で決める。信頼度は「deterministic」
2. 載っていないものは、サービス分野ごとの評価基準で選ぶ。信頼度は「inferred」

高速対応表に載っていたのは、次の9種類です。

表に無いリソースは、分野ごとの評価基準で6項目を見ます。移行の障害になる非互換、運用モデルの相性、Clarifyで答えた好み、機能の対応状況、同じクラスタ内の他リソースとの関係、構成の単純さです。種類が分からないリソースは「未対応」として警告に回し、残りの処理を続けます。つまりレポートの警告欄が、手動で設計し直す対象の一覧になります。

プロジェクト本体(google_project)や監視・ログ系のリソースなどは、AWS側に対応物を置かない扱いです。AWSのアカウント構成は手作業の領域で、監視とログはCloudWatchに任せる、という整理です。

スキルの既定は開発向けの小さい構成です。たとえばデータベースはAurora Serverless v2の0.5 ACUで見積もられ、リージョンは指定がなければus-east-1、期間の想定は8〜12週間です。本番相当の数字が欲しいなら、サイズを明示して頼む必要があります。

見積もりは実価格か、キャッシュか

Estimateの段階は、MCPサーバーawspricingでAWSの料金を引きます。接続は最大3回試し、すべて失敗したらプラグイン同梱の料金表に切り替えます。切り替えた場合は、estimation.jsonにpricing_source: fallbackと記録され、レポートに誤差の注意が出ます。同梱の料金表が古いほど、警告は強くなる作りです。

• 30日以内: 概算で、精度は±15〜25%
• 30〜60日: 精度が下がっている旨の注意
• 60日超: 精度が大きく落ちている旨の警告

もう1つのMCPサーバーawsknowledgeは、設計の検証に使われます。リージョンでの提供有無、機能の対応状況、制約を調べる役目で、結果は参考情報です。検証に失敗しても設計は止まらず、validation_status: "skipped"と記録されます。

接続先は、プラグインの.mcp.jsonで次のように定義されていました。

{
  "mcpServers": {
    "awsknowledge": {
      "type": "http",
      "url": "https://knowledge-mcp.global.api.aws"
    },
    "awspricing": {
      "type": "stdio",
      "command": "uvx",
      "args": ["awslabs.aws-pricing-mcp-server@latest"],
      "timeout": 120000
    }
  }
}

awspricingはuvxで起動するため、Pythonのツール管理コマンドuvが使える環境が前提です。

実行計画は何を含むのか

Executeの段階は、移行を週単位の工程にします。削除直前のスキル定義にあった工程は、計画と準備、検証用の試作、本構成の構築、データ移行、切り替え、後片付けです。

進捗は、作業ディレクトリの.migration/MMDD-HHMM/に状態ファイルとして保存されます。.phase-status.jsonが現在の段階を持つので、会話を閉じても同じ呼び出しで続きから再開できます。.migrationの中身が誤ってコミットされないよう、段階1で.gitignoreも自動生成される仕様でした。

導入前に確認すること: マーケットプレイスとリポジトリの食い違い

マーケットプレイスのページは、このプラグインを「Install in Claude Code」付きで掲載し、導入数2,370を表示しています。「Plugin source」のリンク先はawslabs/agent-pluginsです。

一方、そのリポジトリの履歴では、プラグインは2026年3月9日に追加され、4月27日に「remove migration-to-aws plugin」というコミットで削除されています。事実関係は次のとおりです。

• マーケットプレイス定義(.claude-plugin/marketplace.json)に登録されているのは8つで、migration-to-awsは含まれない
• plugins/migration-to-awsディレクトリに残っているのは、Codex向けの.codex-plugin/plugin.jsonだけで、スキルも.mcp.jsonもない
• READMEのプラグイン一覧にはAvailableの行が残っているが、Claude Code向けのインストール例にはこの名前が出てこない

削除直前のREADMEには、導入手順として次のコマンドがありました。

/plugin marketplace add awslabs/agent-plugins
/plugin install migration-to-aws@agent-plugins-for-aws

ただし、いまのリポジトリのマーケットプレイス定義には、この名前のエントリがありません。この手順が成功するかどうかは、リポジトリの定義からは裏づけが取れません。試すなら、マーケットプレイスを追加したあとの/pluginの一覧にmigration-to-awsが出るかを先に見てください。出なければ、導入手段が無い状態です。

削除直前のスキルの中身は、Gitの履歴から読めます。移行方針を検討する材料として使う場合は、次のようにスナップショットを取り出せます。

git clone https://github.com/awslabs/agent-plugins
cd agent-plugins
git show 38fc9a16^:plugins/migration-to-aws/skills/gcp-to-aws/SKILL.md

履歴上のスキルは、SKILL.mdとreferences/の下の段階別ファイルで構成されています。内容は読めるので、自分のCLAUDE.mdやプロジェクトのスキルに移植する元ネタになります。ライセンスはApache-2.0です。

同じリポジトリの他のプラグインとの関係

リポジトリのトップには、Agent Toolkit for AWSが公開済みで、このリポジトリの有用なプロジェクトは時間をかけてそちらに移る旨の案内があります。コードをAWSに載せる用途なら、構成提案から見積もりまでを担うDeploy on AWSプラグインが、同じリポジトリで案内されているプラグインです。Lambdaを軸にした設計ならaws-serverlessプラグインが受け皿になります。

使う前に決めておきたいこと

移行計画を作る道具として見ると、このプラグインの価値は、見積もりの前に8つの質問で前提を固定させる点にあります。AI任せの移行相談で起きがちな「前提が曖昧なまま数字だけ出る」状態を避けやすい作りです。

反対に、出てくるのは開発向けサイズの計画です。本番の移行判断に使うなら、モードA/Bで要件を答え、サイズを指定し、見積もりの出どころ(liveかfallbackか)を確かめてから、人間が設計を読み直す流れになります。

配布元の状況が定まらないうちは、プラグインの導入に依存せず、履歴上のスキル定義を自分の環境に取り込んで使う道もあります。