続・AWS Amplifyの、何が良いのか？

Transcript

1. 2026年08月11日（火） 続・AWS Amplifyの、何が良いのか？ 言語化したその日に、結論が動いた話 赤神 青空
2. ▪「愛用してるのに言えない」を徹底調査した 前回のあらすじ 3つの実体験（自作 / Vercel / Amplify）の差分から、 結論を「CDKに地続きのマネージドDX」と言語化した。 手軽なのに、資産が自分のAWSアカウントに残る。それが良さだ、と。 01 02 03 設計思想・機能・競合・弱点を裏取り 結論の一文にたどり着いた 満足して動画を公開した 徹底調査した 今ココ あらすじ 言語化できた 発表した 2/18
3. ▪公開直後のタイムラインで、AI時代のAWS構成論に出会う ところが、その日のうちに 動画を公開 → RTされる 言語化は 界隈の方に 直後 完了したはず 今ココ あらすじ 届いた → そして 別の見方 「今なら他にも 選択肢があるよね」 3/18
4. ▪反論として読む前に、実感として刺さってしまった 正直、思い当たる節があった 反発よりも先に、「確かに」が来てしまった。 私自身、Amplify以外のホスティングも気軽になってきた VercelもCDKも、以前ほど構えずに選べるようになった そもそもAmplifyを、その程度にしか見ていなかった 「ホスティングとバックエンドをよしなにしてくれるやつ」 周りの会話でも、だいたいその粒度で語られていた 手軽さの話に終始して、それ以上の話になりにくい 今ココ あらすじ 4/18
5. ▪この見方に反論できないのは、当然だった そこで気がついた 前作の私は、Amplifyを 「機能の塊」としてしか見ていなかった。 見ていたもの 手軽なホスティング、よしなにやってくれるバックエン ド。 見ていなかったもの Gitの操作に紐づいて、環境が生まれて消えていく仕組み。 機能で比べる限り、この見方には勝てない。だから、比べ方を変えることにした。 今ココ あらすじ 5/18
6. 01 検証 この見方、どこまで本当か 今ココ 検証 6/18
7. ▪Lambdaserving層は、確かにコモディティ化した Web Adapter + Function URL 「手軽にホスティング」は、もうAmplifyの専売ではない。 普通のWebアプリがほぼそのままLambdaで動く Dockerfileに1行足すだけでLWAが有効になる Function URLを通せば最小労力で公開できる AWS自身が公式に紹介している実装パターン Amplifyの制約を避ける目的でLWAを選ぶ例すらある Amplify管理下のCloudFrontにはLambda@Edgeを差し込めない 今ココ 検証 7/18
8. ▪Amplify以外の道が現実的になっている 選択肢は、確かに増えた この数年で、選べるものが一気に増えた。 Lambda Web Adapter + Function URL Lambda MicroVMs（2026年6月発表） CDKで直接デプロイする構成 Vercelなど、AWS外のホスティング 今ココ 検証 8/18
9. ▪万能な部品が増えるほど起きること そして象徴的だった一言 「万能すぎる分、既存サービスの選定が全部難しくなる」 部品は増えた LWA・MicroVMs・CDK直……選択肢は豊富になった。 気づき 選定の難しさこそ、Amplifyが消してくれていたコストで は？ 言説の中に、Amplifyの良さの証拠が埋まっていた。 今ココ 検証 9/18
10. 02 再価格付け これはAmplify批判ではなかった 今ココ 再価格付け 10/18
11. ▪価値のデフレは一様ではない AIが安くしたもの、していないもの AIが安くした 書くコスト（CDK直書きがほぼゼロに） 決断のコスト（構成検討をAIに任せられる） 抽象レイヤーを挟む理由そのもの AIでも安くならない 運用するコスト（動かし続けるのは人間側） 一時環境の生成・削除・保護の面倒 生成物を保守する認知負荷 「Amplifyを使わなくなった」は、安くなった部分だけを見た評価なのかもしれない。 今ココ 再価格付け 11/18
12. ▪差し出せるものと、差し出したくないもの 良さの棚卸し Amplifyの良さ（だと思っていたもの）の棚卸し ⼿軽なホスティング コモディティ化 決断‧選定の省略 AIが安くした Gitに紐づくライフサイクル 残る 資産がAWSに残る 残る serving層そのもの 構成を考えなくていい PRごとの⼀時環境‧⾃動削除‧保護 CDKに地続き（前作の結論） LWA + Function URL でも⼗分楽 CDK直書きのコストがほぼゼロに 運⽤コストはAIでもデフレしない CDK直デプロイ派とも同じ⼟台 上2つは差し出せる。下2つは、差し出したくなかった。 上2つは他でも手に入る。下2つが、手放したくなかったもの 今ココ 再価格付け 12/18
13. 03 残ったもの 反論に晒されて、初めて見えた 今ココ 残ったもの 13/18
14. ▪Gitに紐づくデプロイライフサイクル 手放したくなかったのは、これだった PRを作る → 環境が立つ Gitにpush 自動 バックエンドごと するだけ 自前でやると 一時的に構築 パイプライン構築と一時環境の運用管理が、それ自体プロジェク トになる。 今ココ 残ったもの 自動で消える → PRクローズで レビュー後 一時環境を削除 だから servingは譲れても、ここは譲りたくない。 14/18
15. ▪言語化には、続きがあった 気づいたこと 言語化は、調査で仮になり、反論に晒されて、締まる。 調査だけでは 材料は揃うが、どれが核かは決まらない。 反論が来ると 「手放したくないもの」だけが残る。それが核。 手軽さと選定の省略は差し出せた。ライフサイクルは差し出せなかった。 今ココ 残ったもの 15/18
16. ▪続編の一文改めて、結論 Amplifyの良さは、 Gitに紐づくデプロイライフサイクルを丸ごと肩代わりしてくれること。 servingは コモディティ化した。そこはもう良さではない。 ライフサイクルは PRごとに環境が生えて消える。運用ごと任せられる。 そして資産はAWSに残る——前作の結論は、土台として生きている。 今ココ 結論 16/18
17. ▪続編の持ち帰り まとめ 01 serving層はコモディティ LWAやMicroVMsで「手軽さ」はもう専売ではない。 02 AIは決断を安くする 抽象レイヤーの価値は再価格付けされ続ける。 03 それでも運用は残る Gitに紐づくライフサイクルの肩代わりが、残った良さ。 今ココ 結論 17/18
18. ▪それでも、と思うこと 最後に 良さの賞味期限は、思っていたよりずっと短い。 言語化してわかったのは 何が良いかの答えは、時代のほうが先に動かしてくるとい うこと。 それでも 好きなものが、次の時代でも居場所を持ってほしいと思っ ている。 Amplifyがこの時代にも独自のポジションを築けるように、進化してほしい。 今ココ 追記 18/18