AWS Blocks とは？ローカル実行からAWSデプロイまで1つのコードで完結する仕組みを試してみた
はじめに
AWS CDK Conference Japan 2026参加してきました！
AWS Blocks（@aws-blocks/blocks-appというnpmパッケージ）を使ったワークショップに参加し、認証付きTodoアプリを構築するというハンズオンです。
「ローカルで動かすコードと、AWS本番環境にデプロイするコードが別物になってしまう」というのはサーバーレス開発でよくあるつまずきポイントですが、AWS Blocksは「ローカル実行からAWSデプロイまでを1つのコードで完結させる」ことをコンセプトにしています。今回は実際に手を動かして体験した内容を、AWSやサーバーレスに詳しくない方にもわかるように補足を入れながら紹介します。
参考記事: https://dev.classmethod.jp/articles/build-aws-blocks-workshop/
AWS Blocksとは
AWS Blocksは、認証・データストレージ・リアルタイム通信といった機能を「ブロック」単位でコードに組み込めるnpmパッケージです。同じコードのまま、ローカル開発・AWS Sandbox環境・本番環境へとシームレスに移行できる点が特徴です。
比較としてはAWS Amplifyのような「バックエンドをコードで定義するフレームワーク」が近い立ち位置ですが、AWS Blocksはよりミニマルな構成で、npm run devだけですぐに動かせる手軽さが際立っていました。
なぜ必要か（背景・課題）
これまでサーバーレスアプリを作る場合、ローカル開発用のモック環境と、実際にAWSへデプロイする際のインフラ定義（CloudFormationやCDKなど）を別々に用意する必要があり、「ローカルでは動くのに本番で動かない」というギャップに悩まされることがよくありました。
AWS Blocksを使うと、ローカルではJSONファイルへの保存、AWS Sandbox環境ではCloudFormationによるDynamoDBテーブルへの保存というように、環境に応じてインフラが自動で切り替わるため、このギャップを埋めてくれます。
実際に使ってみる
前提条件
- Node.js / npmが使える環境
- AWSアカウント（Sandbox環境へのデプロイ以降で必要）
手順
認証付きTodoアプリを段階的に構築するハンズオンでした。
| Step | 内容 | メモ |
|---|---|---|
| 0 | プロジェクト作成 npm create @aws-blocks/blocks-app
|
--template bare オプションで最低限のテンプレートのみ取得できる |
| 1 | importの確認（AuthBasic / DistributedTable / Realtime） | |
| 2 | 認証ブロック new AuthBasic()
|
|
| 3 | 認証API公開 export const authApi
|
|
| 4 | スキーマ定義（Zodで型定義） | |
| 5 | データストレージ new DistributedTable()
|
|
| 6 | API実装（createItem / listItems） | |
| 7 | フロントエンド（Lit-HTMLでUI構築） | |
| 8 | Realtime発展（WebSocket pub/sub） |
npm create @aws-blocks/blocks-app@latest my-app -- --template bare # 最低限のテンプレートのみ
npm run dev # ローカル開発
npm run sandbox # Sandbox環境へデプロイ
npm run sandbox:destroy # AWSリソースを一括削除（お掃除）。課金が止まる
npm run devを実行するだけで、ローカルにブラウザ画面が立ち上がりました。
使用した技術・サービスは以下の通りです。
- AWS Blocks（npmパッケージ）
- API Gateway + Lambda + DynamoDB（バックエンド）
- CloudFront（本番フロントエンド・API配信）
- CloudFormation（インフラ管理）
- Zod（スキーマ定義。TypeScriptで「この形のデータしか受け付けない」というルールを定義できるライブラリ）
- Lit-HTML（フロントエンドUI構築用の軽量ライブラリ）
つまずいたポイント
npm run sandbox でAWSへ初回デプロイしようとした際、ビルドは通るのにデプロイで失敗しました。
エラー内容:
SSM parameter /cdk-bootstrap/hnb659fds/version not found.
Has the environment been bootstrapped? Please run 'cdk bootstrap'
原因は、CDK（AWSのリソースをコードで定義・構築するツール）でデプロイするには、AWSアカウント・リージョンごとに一度だけ「CDK Bootstrap」という初期セットアップ（S3バケットやIAMロールの自動作成）が必要だったためです。初めてCDKを触る場合はほぼ必須の手順でした。
対応手順（初回のみ）:
# 1. ブートストラップ実行（アカウント・リージョンにつき一度だけ）
npx cdk bootstrap aws://<アカウントID>/<リージョン>
# 例: npx cdk bootstrap aws://123456789012/us-east-1
# 2. 成功したらsandboxを再実行
npm run sandbox
ブートストラップは一度実行すればOKなので、「おまじない」として覚えておくとよさそうです。無事デプロイが成功すると、表示されました。
メリット・デメリット
メリット
- 環境（ローカル / Sandbox / 本番）が変わってもコードを書き換える必要がなく、
userIdをパーティションキーにしたデータ分離もそのまま機能する -
auth.requireAuth(context)の1行を入れるだけで認証保護がかけられ、逆に言うとこれを忘れると誰でも呼べてしまう点は注意が必要 - テンプレートに最初から
AGENT.mdが含まれており、Claudeなどの生成AIがプロジェクト構造を理解しやすいように設計されている -
npm run devだけで複雑なセットアップなしにすぐ試せる
デメリット・注意点
- 初回のAWSデプロイではCDK Bootstrapという追加手順が必要になる
- ローカルのデータは
.bb-data/にJSONで保存される仕組みのため、リポジトリの.gitignore設定など運用面での配慮が必要になりそう
実際にUIでアイテムを追加すると、.bb-data/に即座にJSONが生成されました（ローカル環境）。
{
"userId": "test",
"itemId": "mrpwsyfs",
"title": "add",
"createdAt": 1784351486296
}
ローカルは.bb-data/のJSON、Sandbox環境以降は実際のDynamoDBテーブルに切り替わりますが、コードは変わりません。DynamoDBコンソールを確認すると、テーブルmy-app-ba6034-kana-b5cd7e-my-app-itemsに、アプリから追加したデータ（userId: test / itemId: mrpxkzbv / title: xyz）がそのまま入っていることを確認できました。
まとめ
AWS Blocksは、認証・データストレージ・リアルタイム通信といった機能をブロック単位で組み込みながら、ローカルからAWS本番環境まで同じコードで一貫して開発できるフレームワークでした。「ローカルでは動くのに本番で動かない」というギャップに悩んだことがある人には特におすすめです。
次はRealtime機能（WebSocket pub/sub）をもう少し深掘りして試してみたいと思います。