Amplify Gen 2 アプリを SAM + GitHub Actions 構成に Kiro を使って移植してみた

いわさです。

以前、Kiro と Amplify Gen 2 を組み合わせて半自動の開発環境を構築しました。

https://dev.classmethod.jp/articles/kiroweb-amplifygen2-pr-kobito/

この構成は非常にうまく機能していて、1〜2週間で200を超えるPRをマージし、処理した Issue も同程度の数を消化しました。
Kiro と Amplify の自動デプロイのおかげで、開発→リリース→フィードバックのサイクルを高速に回すことができていました。

しかし、運用を続ける中で Amplify Gen 2 のフルスタック一括管理による課題が見えてきたので、Kiro IDE を使ってこのアプリケーションを SAM + GitHub Actions 構成に移植しました。
その過程を紹介します。

Amplify Gen 2 を使い続けて感じたこと

Amplify Gen 2 は Git リポジトリを1個指定するだけでフロントエンド・バックエンド・認証・CI/CD が全部揃います。
PoC や0→1のフェーズではスタートダッシュが速くて非常に強力でした。

一方で、アプリケーションが成長するにつれて以下のような課題が顕在化してきました。

• ビルド速度: フロントのちょっとした修正でもバックエンド含めてフルビルドが走り、毎回10~15分待つ
  • こちらの記事のようにビルド時間短縮は頑張りました！一定の効果はありましたが、それでも10分程度はかかってしまうので、もっと速くしたかったです。
• コスト: WAF やビルド時間の料金単価が若干割高。個人プロジェクトでもランニングコストが気になる。また個人で GitHub Actions の未使用枠があったので有効活用したい。
• CloudFormation 500リソース制限に到達: Amplify Gen 2 でアプリを成長させ続けると、バックエンド部分を AppSync リゾルバーで頑張ろうとするのでリソース数が大量になりがち。ハードリミットに到達してデプロイがエラーになり、一時的にアプリが動作しなくなった

1~2はもう少し頑張れそうな気もしたのですが、ただ3つ目が致命的で、Kiro 自体がこの問題の解決をギブアップしてしまう事態になりました。

こうした「環境一式をサクッと整えてくれる」便利さは Amplify に限らず様々な開発プラットフォームが提供してくれていますが、昨今は AI エージェントが導入部分のアプリケーション一式の実装、インフラでも IaC テンプレートの生成や CI/CD パイプラインの構築をやってくれるようになったので、フルマネージドな開発サービスの便利さ自体が大したメリットではなくなってきたかもなと個人的に感じつつあります。

そうなると、便利さゆえに柔軟性が出ない部分などのデメリットが目立つようになってきました。

また、そのコーディングエージェントを活用することでアプリケーション＆インフラ移行のハードルも従来よりかなり下がっているので、つらみを感じたら別の構成に乗り換えやすくなっています。

ということで今回は Kiro IDE を使って Amplify なフルスタックアプリケーションを AWS のサーバーレス構成 + GitHub での CI/CD に移植してみました。

Kiro IDE との移行の過程

移行方針の相談

まず Kiro に現状のコードベースを読み込ませて、移行の方向性を相談しました。

Kiro は全体像を把握した上で、技術選定について根拠を示しながら選択肢を提示してくれます。

バックエンド API 形式、IaC ツール、フロントエンドのホスティング方式、認証 UI、既存リソースの扱いなど、判断が必要な論点をひとつずつ整理してくれます。
一方的に決められるわけではなく、こちらが選択したり不明点を詰めたりしながら対話で進めることができます。

実装計画の生成

方針が固まると、Kiro が実装計画を生成しました。
今回は Kiro のプランモードを使っていました。（後述してますが、プランモードは今回の用途だと適していなかったかも。間違いました。。。）
プランモードはファイルへの書き込みを行わず計画策定に専念するエージェントモードで、タスク分解や実装ガイダンスを整理してくれます。

各タスクには目的、実装ガイダンス、テスト方針、Demo（完了条件）が記載されています。
なお、プランモードはセッション開始後にモード変更ができないので、計画をマークダウンに出力させて、別の Autopilot セッションでそれを読み込ませて実行しました。
振り返ると最初から Spec モードで始めても良かったかもしれません。

実装フェーズ

Kiro は計画に従ってタスクを順に実装していきます。
私がやったのは「ノンストップで最後まで進んでください」と指示したことくらいです。

SAM テンプレートの生成、Lambda 関数の REST 化、フロントエンドの API クライアント置換、認証フローの書き換え、GitHub Actions ワークフローの生成、テストモックの更新まで一気に完了しました。

途中で sam validate や npx vitest run による検証も自動で実行して、問題があればその場で修正してくれます。

その後 git push → GitHub Actions が走って本番環境にデプロイされ、カスタムドメインでアクセスできるところまで Kiro のセッション内で完結しました。

移行後の構成

ここは本質的なところではないのでほぼ割愛しますが、参考までに移行前後の構成を載せておきます。

デプロイ速度も１回あたり1~3分くらいになりました。速い！！

移行後の動作確認やコスト監視は引き続き続けましょう。
私の場合だと API Gateway に移行した後わかったのですが、どうやらこれまでは想定していたよりも無駄なリクエストが大量に発生していて、今度はそちらで料金が発生していました。別の環境に移行するとコスト単価が変わるので今度は別の課題が顕在化する可能性もあります。

さいごに

本日は Amplify Gen 2 で構築したアプリケーションを SAM + GitHub Actions 構成に移植した話を紹介しました。

Amplify は CI/CD パイプラインやホスティングも組み込みで提供してくれるので、最初の選択肢としては今でも良いと思っています。
ただ、アプリケーションが成長してくるとフルスタック一括管理のつらみが出てくることもあります。
そういった場面でも Kiro などを使えば以前よりは比較的簡単に移行できるので、Amplify での初期導入は引き続きありかなと思いました。今回みたいにステートレスなリソース（Cognito, DynamoDB など）はそのまま引き継げばいいですからね。