開発初心者のAWSデビューには、Amplify Gen2 よりも AWS Blocks を薦めたい
はじめに
この記事は、「これから開発を始めたい」「AIエージェントを使ったバイブコーディングでアプリを作って、AWSにデプロイしたい」という人に、AWS Blocks を薦める記事です。
AWS Blocks は、2026年6月にパブリックプレビューが公開されたOSSフレームワークです。TypeScriptでバックエンドのコードを書くと、そのコードがそのままAWS上のインフラになる、IfC(Infrastructure from Code)と呼ばれるカテゴリのツールです。
AWSでフルスタック開発を始めようとすると、同じくTypeScriptのコードファーストで開発できる Amplify Gen2 が候補に挙がるかと思います。
私は、去年 Amplify Gen2 を使ったAWSアプリ開発の入門書を書いており、その本を通して「開発はしたことがあるが、AWSは初めて」という人には Amplify Gen2 を薦めています。
この度 AWS Blocks という新しい入口ができました。そして「開発そのものがこれから」という人には、この AWS Blocks の方がよりお勧めできるのではないかなと思い始めてきました[1]。この記事では、その理由を説明します。
AWS Blocksは、事前準備が少ない
AWS Blocks の特徴は、開発を始めてからAWSで動かすまでの間に、事前に用意するモノと、事前に学ぶコトが少ないことです。
手元にNode.jsさえあれば、npm run dev で、ローカル環境で全機能が動きます。認証も、データベースも、ファイル保存も、リアルタイム通信も、すべてローカルのmock実装で動作します。最終的にAWSにデプロイする以上、AWSアカウントは必要になりますが、その作成すら後回しにして、まずはアプリを作り始めることができます。
データベースやファイル保存といったバックエンドの部品は、TypeScriptのコードを1行書くだけで手に入ります。例えばデータの保存場所を定義する1行は、ローカル開発中はファイルシステム上のストアとして動き、デプロイするとDynamoDBになります。書いた本人がDynamoDBを知らなくても、です。
動くものができたら npm run sandbox で、実際のAWS上に使い捨ての検証環境を作れます。そして npm run deploy で、そのまま本番相当の環境にデプロイできます。GitHubのリポジトリを用意する必要も、CI/CDパイプラインを組む必要もありません。
つまり、CDKもCloudFormationもIAMも学ばず、Gitの運用ルールも決めず、「アプリのコードを書いたら、AWSで動いている」に到達できます。AWS公式もアナウンスで、対象を「インフラツールを学ぶ必要なく、AWS上のバックエンド機能が欲しいアプリケーション開発者」と説明しています[2]。インフラの学習コストをまだ払っていない人、まさに「これから始める人」がターゲットのサービスなわけです。
AWS Blocksは、AIエージェントに優しい。
今の開発では、AIエージェントを使うことは当たり前になっています。そして開発初心者ほど、いわゆるバイブコーディングから始めるケースが多いでしょう。バイブコーディングでは、実際にコードを書くのはAIエージェントです。前の節で触れた「データの保存場所を定義する1行」も、あなたが書く必要はありません。「認証付きのTODOアプリを作って」と伝えれば、エージェントが書きます。なので「エージェントにとって扱いやすいか」は、そのままアプリの完成度に直結します。
前の節で書いた開発の流れは、実はすべてnpmコマンドだけで完結していました。そして、これが一番効いているのはAIエージェントです。エージェントはAWSコンソールをポチポチ操作できませんが、CLIで完結するなら、開発からデプロイまでの全工程を自走できます。
また、AWS Blocks は、AIエージェント向けのガイド(AGENTS.md)がnpmパッケージに同梱されていることがよく紹介されます。もちろんこれもAIエージェントにとって嬉しいことではありますが、本質はそこではないと思っています。それよりも、AIエージェントが 間違えようがない構造 になっていることが優しさに繋がっていると思っています。
- ローカルで全機能が動くので、エージェントが自分の書いたコードを即座に実行・検証できる。この試行錯誤のループが数秒で回る
- Node.jsのconditional exportsという仕組みにより、同じ1行のコードがローカル・デプロイ先で自動的に正しい実装に切り替わる。エージェントが環境ごとの条件分岐を書く余地がそもそもない
- クライアントとサーバーの間は型安全なRPC(ApiNamespace)で繋がっていて、APIのURLを手で設定したりリクエストを手組みしたりする箇所がなく、型定義やIFの連携でズレる余地が構造的に小さい
そして、これが初心者に嬉しい理由はシンプルです。「環境構築でハマる」「環境ごとの差異でハマる」「クライアントとサーバーの食い違いでハマる」といった初心者がつまずくはずだったポイントを、AIエージェントが吸収してくれます。人間は最後に npm run sandbox で、実際のAWS上での動作を確認するだけでいい。AIエージェントが働きやすい構造は、結果として初心者への優しさになるわけです。
Amplify Gen2 は、開発者にやさしい。が、、、
Amplify Gen2 も、TypeScriptのコードファーストでauth/data/storageを定義できる、優れたフルスタック開発プラットフォームです。では何が違うのでしょうか?
Amplify Gen2 の売りとして、GitHubリポジトリと繋ぐだけでpushやmergeのたびに自動ビルド・デプロイが走り、ブランチごとの環境やCI/CDをコンソールで一元管理できることが挙げられます。つまり、本番運用はGitHub連携(or他のGitツールとの連携)によるCI/CDが前提 の設計になっています。
開発者にとってこれは間違いなく楽です。画面をポチポチしてGitHubと繋ぐだけでCDが組み上がるのですから。ただしそれは、Gitでコードを管理していて、Gitを使った開発フローを知っていることが前提です。さらに業務で使う場合には、会社にGitHubのアカウントや活用できるルールが整備されていることも前提になります。
私は、仕事で内製化支援に関わることがあるのですが、「これから内製化で開発を始めてみるか」という段階の組織には、そもそもGitの基盤も運用ルールもないことがほとんどです。逆に運用ルールが厳しすぎてAmplifyと接続できない組織も良くあります。
そういう組織にAmplifyを導入しようとすると、GitHub連携が前提になっていること自体がネックになり、導入に難儀します。アプリを作って動かすこととは無関係なところに、壁が立っているわけです。
面白いのは、この「CI/CDの有無」が両側から不満の種になることです。
AWS Blocks にはCI/CDが付いてこないので、開発者からすると「CDを組むには環境の選定から自分でやる必要があって面倒」という不満が出ます。というか私は最初に触った時そう思いました。一方で Amplify Gen2 には「CI/CDが前提になっていて、その手前の整備が面倒」という不満が出ます。
同じ機能の有無が、経験者にはメリットに、これから始める人にはデメリットに、なり得るということです。ある程度経験を積んだ開発者ならCI/CDは簡単に構築できたほうが嬉しい。でも開発初心者には、そもそも CI/CDなんて存在しないほうが優しい のです。
管理しきれなくなったら、Amplify Gen2
とはいえ、アプリが育ってチームで開発するようになり、環境やデプロイをきちんと管理する必要が出てくると、AWS Blocks だけでやりくりするのはほぼ無理だと思っています。CI/CDが無いので、自前で組むなら環境の選定から始めることになります。
ですが、これは、単純な解決策があります。Amplify Gen2 に乗せてしまえばいいのです。
AWS Blocks は、Amplify Gen2 のバックエンドに埋め込めるように作られています。コードはBlocksのまま、デプロイ・ホスティング・CI/CDの管理は Amplify のコンソールに寄せる、ということが実際にできます。このあたりは以前に検証記事を書いたので、興味のある方は参照してみてください。
この統合作業自体はCDKの中身をある程度理解している必要があり、AIエージェントに頼る前提で考えても、初心者向けではないかもしれません。ただ、これは「管理しきれなくなるほどアプリが育った後」の話です。その段階になれば、開発に詳しい人を巻き込むなり、自分で学ぶなりする時期に来ているはずで、最初にBlocksを選んだことが行き止まりになるわけではありません。
実際に体験できるハンズオンを作ってみました
先日、AWS Blocksの社内勉強会を実施しました。それに併せて、この記事で書いた「事前準備の少なさ」と「AIエージェントとの相性」を実際に体験できるハンズオン作ったので、せっかくなのでGitHubで公開しました。
内容は、人間は原則コーディングせず、AIエージェント(Claude Code など)への指示と定型コマンドだけで、Cognito認証つきのAIチャットアプリ(Bedrock の Claude が応答)を作るというものです。チャットから GitHub の Issue を操作する MCP 連携まで実装し、ローカル(全モック・課金ゼロ)→ AWS への本番デプロイ → npm run destroy での後片付けまでを一気通貫で体験できます。
コードの変更はすべてプロンプトで指示し、人間は npm run dev や npm run deploy といった定型コマンドを実行して結果を確認するだけ。この記事で書いた「ハマる役はAIが引き受けてくれる」という感覚を、そのまま味わえる構成にしています。
(なお、AIが殆ど全てやってくれるので人間が暇になるのが、このハンズオンの難点です。)
まとめ
- AWS Blocks は事前準備が少ない。AWSアカウントの作成すら後回しにして開発を始められ、GitもCI/CDも要らず、CDK・IAM・DynamoDBの前提知識も要らない。
- npmコマンドだけで完結する開発は、コンソールを操作できないAIエージェントこそが一番の受益者。「間違える余地を構造で潰してある」ことと合わせて、初心者がハマるはずだったポイントをAIが吸収してくれる。
- Amplify Gen2 の強みであるGitHub連携・CI/CDは、Gitの基盤や運用ルールが無い人・ルールが厳しすぎる組織には、アプリ開発と無関係な壁になる。
- アプリが育ってAWS Blocksで管理しきれなくなったら、Amplify Gen2 に乗せることもできる。
新しいツールの比較は「何ができるか」で語られがちですが、「それは誰にとって嬉しいツールなのか」を考えると、そのツールに対する印象が変わってくることもあります。
これからAWSで開発を始める人、AIエージェントと一緒にアプリを作ってみたい人は、まず AWS Blocks から触ってみる選択肢もよいのではないでしょうか。
-
もっとも、AWS Blocks は、この記事を執筆した2026/07時点でまだプレビューなので、初心者に勧めるのはまだ早いと言われればその通りです。 ↩︎
-
原文は "application developers who want backend capabilities on AWS removing the need to learn infrastructure tools"。AWS Blocks Public Preview announcement ↩︎
NCDC株式会社( ncdc.co.jp/ )のテックブログです。 主にエンジニアチームのメンバーが投稿します。 募集中のエンジニアのポジションや、採用している技術スタックの紹介などはこちら( github.com/ncdcdev/recruitment )をご覧ください!
Discussion