この記事は、弊社エンジニア ダニエル が執筆した英語ブログ I let an agent build a full-stack kanban app on AWS Blocks before I touched an AWS account をもとに、要点をかいつまんで日本語でまとめたものです。 コードや実装の詳細、検証の全文は元記事のほうがずっと面白いので、技術的なところまで読みたい方はぜひそちらを！ ソースコードも公開しています: https://github.com/danielzeljko/aws-blocks-demo

https://medium.com/@daniel_z./i-let-an-agent-build-a-full-stack-kanban-app-on-aws-blocks-before-i-touched-an-aws-account-038cd5b577d3

はじめに

こんにちは、ベンジャミンのイケハタです。
先日のAWS Summit NewYork 2026でAWS新サービス「AWS Blocks」の発表がありました！

弊社Global Innovation Groupでは今回題材にした AWS Blocks について、実は公式発表よりも前の段階から、AWS Blocks 開発チームより プライベートなプロダクトフィードバックの依頼をいただいていました。発表前のプロダクトを触らせてもらい、こちらからも何度かフィードバックを返す、というやりとりを事前に重ねてきています。
なので今回のタスク管理アプリも、ただ新しいフレームワークを試した、というだけの話ではありません。出てくる前から手を動かして向き合ってきたプロダクトを、改めて「エージェントにフルスタックで作らせる」というお題で検証した、という背景があります。こういう一次情報に近いところで技術と付き合えるのは、なかなか楽しいですよ。

さらに今回、AWS Blocksの Product Manager の方からこんなコメントもいただきました！

“We met Daniel and team in January and since then we have depended on his continued feedback and advice on improving AWS products like Amplify and Blocks. His eye for details and developer experience, as well as helpful feedback is something we value highly here in AWS.”

— Praneeta, Sr. Product Manager for CDK, Amplify and Blocks

元記事でやっていること

ここからが本題。「コーディングエージェントに、極力手を出さずにフルスタック開発をどこまで任せられるか」を試した記事です。お題は Trello風のタスク管理アプリ。これを AWS Blocks というフレームワークの上で、Claude Code に作らせてみた、という内容ですね。
タスク管理アプリを選んだ理由は「必要な要素が全部入りだから」。認証、DB、ファイル保存、リアルタイム更新、非同期・定期処理、型が同期したフロント……と、モリモリです。
そして一番のポイントがこれ。バックエンドもインフラもエージェントが書いて、エンジニアがAWSにログインする前にアプリが丸ごと動いた ということです。

AWS Blocks ってどんなもの？

ざっくり言うと「ビルディングブロックを組み合わせてアプリを作る」フレームワークです。1つのブロックの中に、

• インフラ定義（CDK）
• それを動かすSDK呼び出し
• ローカル用のモック

がまとめて入っていて、ローカルではモック、AWS上では本物のサービスとして、同じコードがそのまま動くのがミソ。環境ごとの分岐を書かなくていいわけですね。
起動も npm run dev 一発で、バックエンドとフロントがまとめて立ち上がります。AWSの認証情報も cdk bootstrap もいりません。これは各ブロックのローカルモックが手元で動くからで、この時点ではAWSには一切デプロイされておらず、すべてローカルで完結しています。記事タイトルの「AWSにログインする前に動いた」もこの意味で、AWSに権限なしでデプロイできる、という話ではない点に注意です。

どんなブロックを使ってる？

アプリの機能ごとに、対応するブロックをはめていくイメージです。どのブロックも「ローカルでは○○／AWS上では△△」という二つの顔を持っているので、その対比で並べてみます。

認証（AuthBasic）: ローカルはモック、AWSは Amazon DynamoDB + JWT（Cognito は未使用。AuthCognitoオプション では Cognito を使う構成も選べます）。ユーザー名/パスワードでのログインとそのUIが付いてくるので、ログインフォームは一度も書かなかったとのこと
ボード/カード（DistributedTable）: ローカルはディスク上のJSON、AWSは DynamoDB
コメント（Database / SQL）: ローカルは WASM版Postgres（PGlite）、AWSは Aurora
添付ファイル（FileBucket）: ローカルはディスク、AWSは S3
リアルタイム更新（Realtime）: ローカルは自前で立ち上がるWebSocketサーバー、AWSは API Gateway の WebSocket API
非同期処理（AsyncJob）: ローカルはプロセス内で実行、AWSは SQS + Lambda（招待メールの送信などに使用）
メール送信（EmailClient）: ローカルはコンソール出力、AWSは SES
定期実行（CronJob）: ローカルでもスケジュールが動き、AWSは EventBridge（日次ダイジェストの送信に使用）
AIアシスタント（KnowledgeBase / Agent）: ローカルは軽量な代替（ヘルプ検索はTF-IDF）、AWSは Amazon Bedrock（Bedrock未対応のアカウント向けに簡易フォールバックあり）

ここで先ほどの「AWSにログインせずに動いた」と矛盾しないか、と思うかもしれません。ポイントは、今回エージェントが動かしていたのは全ブロックの“左側”（ローカルのモック）だけだということ。右側（実サービス）の姿になるのは npm run deploy でAWSにデプロイした後で、同じコードがそのまま実サービスに切り替わります。つまり認証もキューもメールもcronもAIも、開発中はすべてローカルで完結していて、AWS側は未稼働——という状態でした。詳しいコード例は元記事にたくさん載っています。

なお、一般的な本番Webサービスで必要になる機能がすべてブロック化されているわけではなさそうです。たとえば WAFのようなエッジ/セキュリティ周りは、今のブロックの顔ぶれには見当たりません。公式ドキュメントに載っていないものは現時点では対象外と考えておくのが無難で、足りない部分は素のCDKで自分で足していく形になりそうです。対応ブロックの最新の一覧や正確な対応範囲は、公式ドキュメントで確認してください: https://docs.aws.amazon.com/blocks/latest/devguide/what-is-blocks.html

デプロイもコマンド一発

AWSに載せるのは、ローカル開発とは別の明示的なステップです。npm run deploy を打って初めてAWSに反映され、中身は普通のCDKデプロイなので、当然ながら通常どおりAWSの認証情報・権限が必要になります（権限なしで載るわけではありません）。逆に言えば、ローカルでファイルを保存してホットリロードがかかっても、それが勝手にAWSへpushされることはなく、AWSに届くのはこのコマンドを打ったときだけ。デプロイすると、Lambda + API Gateway が立って、各ブロックの裏に実サービス（DynamoDB / Aurora / S3 / SQS / EventBridge / SES など）がまとめてプロビジョニングされます。最後までCDKなので、いつものスタックやコンソールもそのまま使えるのが安心ですね。

UIをいじりながら本物のサービスだけ試したいときは、npm run sandbox でバックエンドだけAWSに置き、フロントはローカルでホットリロード、という中間モードもあります（npm run sandbox:destroy で片付け）。

なおこの元記事では、各マイルストーンでコミット前にコードレビュー・セキュリティレビュー・型チェックを走らせる運用にしていました。問題を境界（コミット・デプロイの手前）で表面化させておくことで、おかしな変更がそのままAWSに載ってしまう事故を防ぐ、という考え方です。

CI/CDについても触れておきます。元記事では GitHub Actions 経由のデプロイなど CI/CD には触れていませんが、デプロイの実体は素のCDK（cdk deploy）なので、CI上で走らせる構成自体は普通に組めると思います。

このサービスの何が良いのか？

ダニエルが「ここが違った」と挙げているのは主に2つです。

ローカルファーストの開発ループ アプリ全体が、AWSアカウントなし・デプロイ待ちなしで手元のPCで動く。保存→ホットリロード→確認、という普通のローカル開発の体験のまま、実サービスと同じ挙動を試せる。しかもデプロイされるのは同じコードなので、「自分の環境では動く」に本当の意味がある、と。

型安全性 フロントがバックの戻り値の型をそのまま使うので、API側のフィールド名を変えると、フロントの該当箇所が即エラーになる。両者がずれようがなく、エージェントが脱線しにくいのもこのおかげだそうです。

気になったところ（FAQ）

記事を読んで「で、実際どうなの？」と思いそうなところを、現時点でわかる範囲で補足します。AWS Blocks 自体がまだ新しいプロダクトなので、ここは「今の理解」くらいの温度感で読んでもらえると。

Q. 新規アプリ開発でメリットがある？ 既存のAWSリソースを取り込んでBlocks化することはできる？

メリットがハッキリ出るのは、やはり ゼロから作る新規アプリ です。各ブロックは「インフラ定義＋SDK＋ローカルモック」を1セットで持っていて、必要なものを最初からブロックで組み上げていく前提の作りになっています。だからこそ、ローカルファーストの開発ループや端から端までの型安全といった旨味が最大限に効きます。

ただ、デプロイ層は素のCDKで、ブロック自体も普通のCDK construct です。なので「既存のCDKアプリにブロックを足していく」くらいの混在はできるはず。既存リソースをブロックに“引き取らせる”ところまで踏み込めるかは未検証の領域なので、このあたりは今後の情報解禁に期待ですね。

Q. Amplify と Blocks は何が違うの？

どちらも「TypeScriptでフルスタックを組んで、裏側はCDKでAWSに展開する」点は似ています。ざっくりした違いはこんな感じです。

• ローカル開発: ここが一番の違い。Blocks は各サービスに“本物と同じ挙動のローカルモック”が付いていて、AWSにデプロイせず丸ごとローカルで動かせます。Amplify もサンドボックスはありますが、基本は自分のAWSアカウントへデプロイして確認するスタイルです。
• 構成の自由度: Amplify はデータ周りが GraphQL（AppSync）を中心とした“決まった形”に寄っています。Blocks は KV / テーブル / SQL / ファイル / リアルタイム / 非同期・定期処理 / AI…と、用途別のブロックを選んで組む形で、各ブロックが特定のAWSサービスに対応します。
• デプロイ層: Blocks は最後まで素のCDKなので、普段のスタックやコンソールがそのまま使えます。

おおまかには「Amplifyの手軽さは残しつつ、ローカルファーストと“素のCDKに開けている”ところを強めたもの」というイメージで捉えると分かりやすいかなと思います。とはいえ Blocks はまだ新しいので、細かい違いは今後のドキュメント整備で固まっていくはずです。

まとめ

CDKスタック・Lambda・フロントのクライアントの間を行き来して「全部ひとつになってくれ……」と思ったことがある人なら、試す価値ありです！

発表前のプロダクトに早い段階から関わり、それをエージェント開発の検証台にしてしまう——こういう動き方が好きな方には、きっと刺さる内容だと思います。コードや検証の詳細は、ぜひ弊社エンジニアの元記事で！