AWS Blocks（プレビュー）とは？Amplifyとの違いや実務への応用を解説

はじめに：AWS Blocksとは何か？

2026年6月16日、AWSから新しいオープンソースのTypeScriptフレームワーク「AWS Blocks（プレビュー版）」が発表されました。インフラ管理ツール（IaC：Infrastructure as Code）の学習コストをかけずに、データベース・ユーザー認証・ファイルアップロード・バックグラウンドジョブ・AIエージェントといったバックエンド機能を、TypeScriptのコードだけで組み立てられる開発者向けフレームワークです。

本記事の結論を先にまとめると、AWS Blocksは「ローカルでの爆速な開発体験」と「本番でのAWSの堅牢性・拡張性（AWS CDK）」を、一本のコードで両立させるフレームワークです。その代わり本番デプロイはAWS CDK／CloudFormationの上に乗るため、エッジ環境のような瞬時デプロイとは性質が異なります。この「両立」と「代償」をどう評価するかが、採用判断の軸になります。

以下では、(1) 具体的に何を書くと何が動くのか、(2) 既存の「AWS Amplify」との立ち位置の違い、(3) サーバーレス構成やローカル実行の範囲（LocalStackの代替になるか）といった限界と代償、(4) どんなチームに向くのか、の順で実務家の視点から解説します。

AWS Blocksの3つの特徴

AWS Blocksが提供する価値は、開発者がインフラ構築に時間を奪われず、本来のビジネスロジックや機能開発に集中できる点に尽きます。それを支えるのが、次の3つの特徴です。

1. 完全なローカル開発環境

AWSアカウントを連携しなくても、データベース・ユーザー認証・リアルタイムメッセージングといった機能を、すべてローカルPC上で即座に立ち上げて検証できます。各Blockはローカル実装を持ち、たとえばデータ保存はメモリ上、認証はローカルのJWTで動きます。AWSリソースのプロビジョニング待ちが発生しないため、変更が即座に反映され（ホットリロード）、プロトタイプ開発とテストのサイクルが大幅に短くなります。

2. AWSデプロイとCDKへのトランスパイル

ローカルでの検証を終えて本番へデプロイする際、アプリケーションのコードを書き換える必要はありません。デプロイを実行すると、Blocksの記述は自動的に「AWS CDK（Cloud Development Kit）」のリソース定義へトランスパイル（変換）され、実際のAWSリソースとして展開されます。ローカルでエミュレートしていた各Blockが、そのままAWSのマネージドサービスへ置き換わるイメージです（具体的な対応は後述の例で示します）。インフラ専任のエンジニアがいなくても堅牢な構成を安全に組めるのが強みです。

3. フルスタックでの型安全性

バックエンドで定義したデータスキーマの型が、コード生成ステップを挟まずにフロントエンドのコードまで直接連携されます。APIの仕様やDBカラムを変更すると、フロントエンド側で即座にTypeScriptのコンパイルエラーとして検知できます。対応フロントエンドは、SPA（Vite + React）からSSR環境（Next.js・Nuxt・Astro）まで、モダンなWeb開発の主流を広くカバーします。

ここで誤解しやすいのですが、AWS Blocks自体がフロントエンドの画面（UI）を生成するわけではありません。あくまでバックエンドで定義した型情報をReactやNext.jsなどのフロントエンドへ連携し、型安全に呼び出せるようにする役割です。「バックエンド特化」でありながら主要なフロントエンドフレームワークの名前が挙がるのは、このためです。

具体例：Todoアプリで「書く→動く→デプロイ」を体感する

抽象的な説明だけではイメージしづらいので、公式ドキュメントのチュートリアル（認証付きTodoアプリ）に沿って、実際に何を書き、何が起きるのかを具体的に見ていきます。

プロジェクト作成と構成

次のコマンドでプロジェクトを作成します。

npx @aws-blocks/create-blocks-app

生成される構成はシンプルで、バックエンド定義（aws-blocks/index.ts）とフロントエンド（src/app.tsx）が分かれているだけです。

my-todo-app/
├── aws-blocks/
│   └── index.ts   # バックエンド定義（Blockの宣言とAPI）
├── src/
│   └── app.tsx    # フロントエンド（APIを直接import）
└── package.json

バックエンドを「書く」

aws-blocks/index.ts に、認証とデータテーブルを宣言します。これがそのままバックエンドの実体になります。

import { ApiNamespace, Scope, DistributedTable, AuthBasic } from '@aws-blocks/blocks';

const scope = new Scope('todo-app');

const auth = new AuthBasic(scope, 'auth');
const todos = new DistributedTable(scope, 'todos', {
  schema: { id: 'string', title: 'string', completed: 'boolean', userId: 'string' },
  key: { partition: 'userId', sort: 'id' },
});

続けて、これらのBlockを使うAPIメソッドを同じファイルに定義します。クライアント用のSDK初期化やエンドポイントURLの設定は不要です。

export const api = new ApiNamespace(scope, 'api', (context) => ({
  async createTodo(title: string) {
    const user = await auth.getCurrentUser(context);
    const id = crypto.randomUUID();
    await todos.put({ id, title, completed: false, userId: user.userId });
    return { id, title, completed: false };
  },
  async listTodos() {
    const user = await auth.getCurrentUser(context);
    const results = [];
    for await (const item of todos.query({ where: { userId: user.userId } })) {
      results.push(item);
    }
    return results;
  },
}));

export { auth };

フロントエンドは型付きAPIを直接呼ぶ

フロントエンド（src/app.tsx）は、バックエンドのAPIをそのままimportして呼び出します。

import { api, auth } from '../aws-blocks/index.js';

クライアント生成ステップもAPI URLの設定もありません。バックエンドのメソッドシグネチャを変えれば、フロントエンドは即座にコンパイルエラーになります。これが「コード生成なしの型安全」の実体です。

ローカルで動かす

npm run dev で開発サーバーが立ち上がり、http://localhost:3000 で認証付きのTodoアプリがそのまま動きます。AWSアカウントは不要です。このとき各Blockはローカル実装で動作します。

• DistributedTable … 構造化データをメモリ上に保存
• AuthBasic … ローカルのJWTトークンで認証
• ApiNamespace … ローカルHTTPサーバー経由でRPC

コードを変更するとホットリロードで即反映されるため、ブラウザを見ながら実装を進められます。

デプロイすると何がAWSに展開されるか

ローカルと同じコードが、デプロイ時に各Blockへ対応するAWSサービスへ自動的に解決されます。主な対応は次のとおりです。

• DistributedTable → DynamoDB テーブル（インデックス付き）
• AuthBasic → ユーザー情報を保持する DynamoDB（認証基盤）
• ApiNamespace → API Gateway + Lambda

デプロイには2つのモードがあり、用途で使い分けます。

# sandbox: 実AWS上の高速・使い捨て環境（Lambdaホットスワップで数秒）
npm run sandbox

# 本番: ホスティング込みのフルCDKデプロイ（CloudFormationスタック）
npm run deploy

つまり「書いたTypeScriptがローカルでそのまま動き、同じコードがDynamoDB・Lambda・API Gatewayとして展開される」というのが、AWS Blocksの開発体験の核心です。

AWS Amplify（Gen 2）との立ち位置の違い

AWSでフロントエンドとバックエンドを統合開発するツールといえば、「AWS Amplify」やその最新版「Amplify Gen 2」を思い浮かべる方も多いでしょう。両者は何が違い、どちらを選ぶべきなのでしょうか。

違いは「どちらを起点にバックエンドを生やすか」

Amplifyは、モバイルアプリやWebフロントエンドの開発者に向けた「包括的なSDKとホスティング機能のセット」であり、フロントエンド主導でバックエンドリソースを構築していくアプローチをとります。対してAWS Blocksは、名前のとおりバックエンドの構築に軸足を置いたTypeScriptフレームワークで、Amplifyのようにホスティングやフロントエンド向けSDKまでを一括で抱え込むわけではありません。バックエンドのロジックやリレーショナルデータベース（Postgresなど）のスキーマ設計を主軸に置きつつ、必要に応じてCDKでインフラを柔軟にカスタマイズしたい、というニーズに直接応えます。

両者とも、最終的にReact/Next.jsと組み合わせて使う点は共通しています。違いは機能の有無ではなく、「どちらを起点にバックエンドを生やすか」という設計思想にある、と捉えると整理しやすいでしょう。

採用時の注意点

現状、Amplify SDK自体がフロントエンド開発の絶対的なデファクトスタンダードとして定着しきっているとは言い難く、そこにAWS Blocksという似て非なる選択肢が加わりました。導入や技術スタック決定の際には、それぞれのツールが提供する抽象化の度合いや、得意とするデータモデル（NoSQLかRDBか）の違いを、PoC（概念実証）で事前に検証することを強く推奨します。

限界と代償：サーバーレス構成とローカル実行の範囲

魅力的な開発体験の一方で、本番運用やローカル検証に向けては押さえておくべき性質があります。ここでは「完全サーバーレス構成の可否」「LocalStackの代替になりうるか（ローカル実行の範囲）」「ローカルとsandboxの開発体験の違い」の3点を見ていきます。

完全サーバーレス構成は可能か

実は、チュートリアルの標準構成（DistributedTable・AuthBasic・ApiNamespace）は、デプロイ時にDynamoDB・Lambda・API Gatewayへ解決されます。つまり標準のまま使えば、バックエンドはすでに「ほぼ完全サーバーレス」だということです。

注意が必要なのは、本格的なリレーショナルDBが欲しいケースです。AWS BlocksにはPostgreSQLを提供するDatabase Blockがあり、これはAWS上ではRDS系へ展開されるため、DynamoDBのようなアイドル時ゼロコストのサーバーレス性とは性質が変わります（Aurora Serverlessなどの選択肢はありますが、考慮事項が増えます）。「DynamoDBベースで割り切れるか、Postgresが要るか」が、サーバーレス度を左右する分岐点になります。

LocalStackの代替になるか？ローカル実行の本当の範囲

「AWSアカウント不要でローカル実行できる」と聞くと、SQSやS3のイベントを起点にLambdaを呼ぶようなイベント駆動の構成も、LocalStack（OSS版が有料化し、手軽に立てづらくなった）の代わりにローカルで試せるのでは、と期待したくなります。結論から言うと、AWS Blocksはその用途の汎用的な代替にはなりません。

AWS Blocksのローカル実行は、「任意のAWSサービスをエミュレートする」ものではなく、フレームワークが提供するBlockだけをローカル実装（メモリ／ファイルシステム）で動かす仕組みです。import文が実行コンテキストごとに解決先を切り替える「conditional exports」によって、ローカルではローカル実装に解決され、データはプロジェクト直下の.bb-data/に保存されます。つまりローカルで動くのは、Blockとして用意された機能の範囲に限られます。

したがって、扱いたいイベント駆動が一級のBlockで表現できるかが分岐点になります。

• Blockで表現できる場合：バックグラウンドジョブ（AsyncJob）やリアルタイムpub/sub（Realtime）、ファイル操作（FileBucket）はBlockなのでローカル実装を持ちます。「ジョブを積んで処理する」型のイベント駆動であれば、LocalStackなしでローカル試験できます。
• 生のAWSプリミティブを組む場合：S3のObjectCreatedイベントやSQS→Lambdaのトリガを直接組みたいときは、Blockを持たないリソースとして、CDK layer（aws-blocks/index.cdk.ts、いわゆるエスケープハッチ）でCDKコードを書きます。公式ドキュメントもSQSキューをこの方法の例に挙げています。

// aws-blocks/index.cdk.ts — Blockの無いリソースはCDKで直接足す
const queue = new sqs.Queue(stack, 'my-queue');
queue.grantSendMessages(stack.handler);

重要なのは、このCDK layerで書いたリソースにはローカル実装が無いという点です。これらは「デプロイして初めて実在するAWSリソース」であり、ローカルでイベントトリガが発火するわけではありません。つまり、LocalStackで行っていた「生のSQS/S3トリガをローカルでstubして検証する」というニーズを、AWS Blocksがそのまま肩代わりすることはありません。初期は標準Blockで素早く構築し、本番に向けてCDKで細かく作り込めるという段階的な進化はAWS Blocksの利点ですが、その自由度の領域（生のAWSリソース）はローカル再現の対象外になる、という関係です。

ローカルとsandboxの二層的な開発体験

では、ローカルで再現できない挙動はどう検証するのでしょうか。ここにAWS Blocksの設計思想がよく表れています。Blocksは「すべてをローカルでエミュレートする」のではなく、用途の異なる2つの環境を行き来する開発体験を前提にしています。

• ローカル（npm run dev）：AWSアカウント不要・オフライン・即時ホットリロード。ただし動くのはBlockのローカル実装のみ。日々のロジック実装やUI確認に使います。
• sandbox（npm run sandbox）：Lambdaのホットスワップで数秒でデプロイされる、開発者ごとに分離された実AWS環境。実サービス上で動くため、ローカル実装と挙動が異なる部分——DynamoDBのクエリ性能、IAMの権限境界、そして前述の生のイベントトリガなど——の確認に使います。

LocalStackが「ローカルにAWSを再現する」アプローチだったのに対し、AWS Blocksは「実AWSを数秒で立てて本物で確かめる」アプローチを採っている、と捉えると分かりやすいでしょう。イベント駆動の結合テストは、ローカルのstubではなくsandboxで行うのが正規ルートです。なお、ホスティング込みの本番デプロイ（npm run deploy）はフルCDK／CloudFormationのプロビジョニングが走るため数分単位を要し、Cloudflare（Workers/Pages）のような瞬時デプロイを最優先する用途とは性質が異なる点も、合わせて理解しておくとよいでしょう。

AWS Blocksは「誰」向けのフレームワークか？

ここまでの特徴と代償を踏まえると、AWS Blocksは次のようなターゲット層・ユースケースに最もマッチすると考えられます。

最適な開発チームとユースケース

• インフラ専任のエンジニアはいないが、AWSの堅牢性と拡張性を活かしたサービスを構築したいスタートアップやSaaS開発チーム
• 初期は少人数で素早くプロトタイプを構築しつつ、将来は事業スケールに合わせてCDKで細かくインフラをカスタマイズしたいプロダクトチーム
• TypeScriptのエコシステム（Next.jsやReactなど）を中心に、フロントからバックまで型安全なフルスタック開発を実現したいWebアプリケーションエンジニア

逆に、数秒での高速なデプロイサイクルを最優先とする小規模プロジェクトや、インフラ構成を初期段階から完全に自前でコントロールしたいチームにとっては、AWS Blocksの抽象化が必ずしも最適解にならないケースもあります。

まとめ：プレビュー版をどう評価すべきか

AWS Blocksは、「ローカルではTypeScriptを書くだけで動き、同じコードがDynamoDB・Lambda・API Gatewayとして展開され、必要になればCDKへ降りて作り込める」という、バックエンド構築のハードルを大きく下げるフレームワークです。標準構成はほぼサーバーレス、日常のイテレーションはsandboxで数秒、という開発体験には実務的な魅力があります。

ただし現時点ではプレビュー版です。本記事のスタンスとしては、クリティカルな本番プロダクトへの全面採用は正式版を待つべきで、いまはPoCで自社の要件（DynamoDB中心で足りるか、本番デプロイの重さを許容できるか）を見極める段階だと考えます。まずは、お手元のターミナルで npx @aws-blocks/create-blocks-app を実行し、Next.jsやReactと組み合わせたローカル開発の快適さを実際に体感してみてください。

参考文献

AWS、AWS上でアプリケーションバックエンドを構築するためのオープンソースフレームワーク「AWS Blocks」を発表（プレビュー） https://aws.amazon.com/about-aws/whats-new/2026/06/aws-blocks-preview

AWS Blocks ドキュメント（Getting started） https://docs.aws.amazon.com/blocks/latest/devguide/getting-started.html