はじめに
2026年6月、AWS Blocks がパブリックプレビューとしてリリースされました。
Blocks の大きな売りのひとつが 「AWS アカウント不要でローカル完結の開発体験」 です。Amplify Gen 2 を使っている身としては、真っ先にこう思いました。
「これ、Amplify のサンドボックス（
ampx sandbox）の代わりになるのでは？」
結論から言うと、代替ではなく補完 でした。ただし、その「補完」の中身を掘り下げると、Amplify プロジェクトが業務アプリに成長するフェーズで非常に現実的な拡張手段になり得ることが見えてきました。
本記事では、実際に Amplify Gen 2 プロジェクトに Blocks を統合する検証を行い、ローカル開発の実態と「補完関係」の具体像を整理します。
AWS Blocks とは
軽く触れておきます。
AWS Blocks は、フルスタックアプリケーション向けのバックエンドツールキットです。各「Block」は以下の3レイヤーを1パッケージに収めた自己完結型モジュールになっています。
| レイヤー | 内容 |
|---|---|
| インフラ定義 | CDK Construct（DynamoDB テーブル、Lambda 関数など） |
| ランタイムコード | Lambda 上で動くアプリケーションロジック |
| ローカル実装 | インメモリストアなど、AWS アカウント不要で動くモック |
この3レイヤー構造により、同じコードがローカルでもクラウドでも動くのが特徴です。
利用可能な Block（2026年6月時点）
| カテゴリ | Block | AWS サービス |
|---|---|---|
| データ |
KVStore, Database, DistributedTable, FileBucket
|
DynamoDB, Aurora SQL, S3 |
| 認証 |
AuthBasic, AuthCognito, AuthOIDC
|
Cognito |
| 非同期処理 |
AsyncJob, CronJob
|
SQS, EventBridge |
| AI |
Agent, KnowledgeBase
|
Bedrock |
| 通信 |
Realtime, EmailClient
|
API Gateway WebSocket, SES |
| 可観測性 |
Logger, Metrics, Tracer, Dashboard
|
CloudWatch |
| ホスティング | Hosting |
CloudFront + S3 |
公式見解：「補完関係」
AWS の公式ドキュメントでは、Blocks と Amplify の関係について以下のように述べられています。
AWS Amplify is a set of tools and services for building full-stack applications. AWS Blocks and Amplify are complementary. Amplify provides hosting, CI/CD, and a managed backend experience, while AWS Blocks focuses on type-safe infrastructure-from-code with local-first development.
Complementary = 補完関係
「置き換え」ではなく「役割分担」という整理です。具体的に得意領域を並べると、こうなります。
| 領域 | Amplify が得意 | Blocks が得意 |
|---|---|---|
| CRUD + リアルタイム同期 | ○（AppSync Subscription） | △（Realtime Block はあるが AppSync が高機能） |
| 認証・認可 | ○（Cognito + 宣言的アクセス制御） | △（AuthCognito Block はあるが Amplify UI 連携なし） |
| 認証×データの統合制御 | ○（allow.owner() 等で AppSync リゾルバレベルの認可） |
✕（認可ロジックは自前実装） |
| ホスティング・CI/CD | ○（Amplify Hosting 統合） | ✕（自前構築） |
| 定期実行・バッチ | ✕（CDK 手書きが必要） | ○（CronJob / AsyncJob） |
| RDB + SQL マイグレーション | △（DynamoDB 中心、RDS 対応は限定的） | ○（Database） |
| AI エージェント | △（Amplify AI Kit） | ○（Agent / KnowledgeBase） |
| ローカル高速開発 | ✕（サンドボックス必須） | ○（AWS アカウント不要） |
この表を見ると、お互いに「✕」の部分を相手が「○」で埋めていることがわかります。
特に Amplify の「認証 × データ」の統合力は特筆に値します。Cognito のユーザー情報と AppSync のアクセス制御が宣言的に結びついており、owner ベースの行レベルアクセス制御やグループベースの認可が簡単に実現できます。
以降の検証で述べますが、本機能は Amplify Sandbox を立ち上げないとローカルでは動きません。ここがひとつの大きなポイントになりそうです。
では実際に統合するとどうなるのか、検証してみました。
実際に Amplify プロジェクトに Blocks を統合してみる
Amplify Quickstart をベースとして、Blocks を統合していきます。
Quickstart を素のままで普通にデプロイするとこんな感じの画面となります。
統合アーキテクチャ
既存の Amplify Gen2 プロジェクトに Blocks を追加した構成です。
統合のポイントは3つです。
-
Nested Stack で共存 —
backend.createStack('blocks')で Amplify の下に新スタックを追加 - Cognito の橋渡し — Amplify の User Pool 情報を Blocks Lambda の環境変数に注入
-
出力の統合 — Blocks API URL を
amplify_outputs.jsonのcustomセクションに出力
実装コード
amplify/backend.ts（変更は3行だけ）
既存の Amplify バックエンド定義に、Blocks の初期化を1行追加するだけです。既存の auth / data の定義には一切手を加えません。
import { defineBackend } from '@aws-amplify/backend';
import { auth } from './auth/resource';
import { data } from './data/resource';
import { initBlocks } from './blocks.js'; // ← 追加
export const backend = defineBackend({ auth, data }); // ← export 追加
await initBlocks(backend); // ← 追加
amplify/blocks.ts（新規 — Amplify と Blocks を繋ぐ統合関数）
Amplify の backend オブジェクトから Nested Stack を作り、Cognito の設定を環境変数で Blocks 側に渡します。これが「橋渡し」の役割を担うファイルです。
import { createBlocksBackend } from '../aws-blocks/index.cdk.js';
export async function initBlocks(backend: any) {
// Amplify の管理下に Nested Stack として Blocks 用スタックを作成
const blocksStack = backend.createStack('blocks');
const sandboxMode = process.env.AMPLIFY_SANDBOX === 'true';
const blocks = await createBlocksBackend(blocksStack, sandboxMode);
// Amplify の Cognito 設定を Blocks Lambda に環境変数で注入（橋渡し）
if (backend.auth?.resources?.cfnResources) {
const { cfnUserPool, cfnUserPoolClient } = backend.auth.resources.cfnResources;
blocks.handler.addEnvironment('COGNITO_USER_POOL_ID', cfnUserPool.ref);
blocks.handler.addEnvironment('COGNITO_CLIENT_ID', cfnUserPoolClient.ref);
blocks.handler.addEnvironment('COGNITO_REGION', blocksStack.region);
}
// Blocks API URL をフロントエンドから参照できるよう amplify_outputs.json に出力
backend.addOutput({ custom: { blocks_api_url: blocks.apiUrl } });
}
aws-blocks/index.ts（新規 — Block API 定義）
Blocks のバックエンドロジック本体です。KVStore を定義し、Todo の CRUD を API として公開します。Blocks の通信プロトコルは JSON-RPC 2.0 で、1つの HTTP エンドポイントに対して method フィールドで呼び出す関数を指定するシンプルな仕組みです。REST のように URL を分けず、GraphQL のようにスキーマ定義も不要なので、コード量が少なく済みます。
ローカルでは KVStore がインメモリで動き、デプロイ時には DynamoDB に差し替わります。
import { ApiNamespace, Scope } from '@aws-blocks/blocks';
import { KVStore } from '@aws-blocks/bb-kv-store';
// Scope = アプリの名前空間。Block にアイデンティティを与える
const scope = new Scope('amplify-plus-blocks');
// KVStore: ローカルではインメモリ、デプロイ時は DynamoDB になる
const todosStore = new KVStore(scope, 'todos', {});
// ApiNamespace で定義した関数が、そのまま JSON-RPC のメソッドになる
export const api = new ApiNamespace(scope, 'api', (context) => ({
async createTodo(content: string) {
const id = crypto.randomUUID();
const todo = { id, content, createdAt: Date.now() };
await todosStore.put(id, JSON.stringify(todo));
return todo;
},
async listTodos() {
const todos: Array<{ id: string; content: string; createdAt: number }> = [];
// scan() で全件取得（DynamoDB の Scan 相当）
for await (const { key, value } of todosStore.scan()) {
if (value) todos.push(JSON.parse(value));
}
todos.sort((a, b) => b.createdAt - a.createdAt);
return todos;
},
async deleteTodo(id: string) {
await todosStore.delete(id);
return { success: true };
},
}));
aws-blocks/scripts/server.ts（新規 — ローカルサーバー起動）
npm run dev で呼ばれるスクリプトです。Blocks が提供する startDevServer を使い、ローカルの HTTP サーバーを起動します。
import { startDevServer } from '@aws-blocks/blocks/scripts';
import { fileURLToPath } from 'node:url';
import { dirname, join } from 'node:path';
const __dirname = dirname(fileURLToPath(import.meta.url));
startDevServer({
backendPath: join(__dirname, '..', 'index.ts'),
port: 3001,
});
package.json（scripts 追加）
concurrently で Blocks ローカルサーバーと Angular dev server を同時に起動します。
{
"scripts": {
"blocks:dev": "tsx watch aws-blocks/scripts/server.ts",
"dev": "npx concurrently \"npm run blocks:dev\" \"npm run start\""
}
}
npm run dev で Blocks ローカルサーバーと Angular dev server が同時に起動します。
テンプレート CLI は動かない...
公式の --template amplify は現時点でエラーになります。
npx @aws-blocks/create-blocks-app@latest my-app --template amplify -y
# → ENOENT: no such file or directory, open '.../templates/amplify/package.json'
オプション無しであれば動きます。今回はテンプレートのソースを参考に手動で統合しました。
ビルド検証結果
| 検証項目 | 結果 |
|---|---|
npm install |
成功 |
ng build（フロントエンド） |
成功 |
tsc --noEmit（バックエンド型チェック） |
成功 |
npx ampx sandbox（クラウドデプロイ） |
要回避策（後述） |
統合自体は問題なく、既存の Amplify ビルドパイプラインと干渉しないことが確認できました。ただし ampx sandbox については非互換があります（後述の「npm run sandbox について」で解説）。
ローカルで動かしてみる
ビルドが通ったので、npm run dev でローカル開発を立ち上げてみます。
AppSync（GraphQL）はローカルでは動かない
npm run dev を実行すると、Blocks ローカルサーバーと Angular dev server は起動しますが、既存の Todo 機能（AppSync 経由）はエラーになります。
AppSync はクラウド上のサービスなので、サンドボックスを立てない限りローカルからは接続できません。これが「Amplify Data はサンドボックス必須」の実態です。
Todo の向き先を Blocks に切り替える
そこで、Todo 追加ボタンの呼び出し先を AppSync から Blocks API に切り替えます。
変更前（AppSync 経由）では generateClient で GraphQL を呼んでいましたが、変更後は単純な fetch + JSON-RPC に置き換わります。GraphQL のクエリ構築が不要になり、コードがシンプルになります。
// 変更前: AppSync (GraphQL) — サンドボックス必須
import { generateClient } from 'aws-amplify/data';
const client = generateClient<Schema>();
await client.models.Todo.create({ content: 'やること' });
// 変更後: Blocks (JSON-RPC) — ローカルで動く
await fetch('http://localhost:3001/aws-blocks/api', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
jsonrpc: '2.0',
id: '1',
method: 'api.createTodo',
params: ['やること'],
}),
});
通信プロトコルが GraphQL から JSON-RPC 2.0 に変わるだけで、フロントエンド側の変更は呼び出し部分のみです。
ただし、AppSync の allow.owner() のような宣言的アクセス制御は使えなくなります。Blocks 側で同等の制御を行うには、CognitoVerifier.requireAuth(context) で JWT を検証し、ユーザーごとのデータ分離を自前で実装する必要があります。今回のローカル検証では認証を外していますが、本番運用では考慮すべきポイントです。
検証結果
todo 機能としては問題なく動作することを確認できました。
| 検証項目 | 結果 |
|---|---|
| Blocks ローカルサーバー起動 | 成功 |
| Todo 作成 / 一覧 / 削除 | 全て成功 |
| CORS（localhost:4200 → 3001） | 自動許可済み |
| AWS アカウント | 不要 |
| ブラウザでの動作 | 成功 |
ローカルで動く範囲、動かない範囲
ここまでの検証を整理すると、Blocks のローカル開発で動くのは Blocks で書いた部分だけ です。Amplify の Auth・Data・Storage はサンドボックスなしでは動きません。そしてそれは単なる制約ではなく、サンドボックスと引き換えに得ている価値（宣言的認可、リアルタイム同期、Amplify UI 連携）でもあります。
npm run sandbox について
ちなみに Blocks 単体で使う場合は、npm run dev（ローカル）の他に npm run sandbox というコマンドもあります。これは本物の AWS リソース（DynamoDB、Lambda 等）に対して一時的な環境をデプロイするもので、Lambda ホットスワップにより数秒で変更が反映されます。Blocks はバックエンド全体を1つの Lambda にバンドルする構造なので、日常の開発で変わるのはほぼ Lambda コードだけ。だからホットスワップが効きやすくなります。
Amplify 統合時はこの npm run sandbox は使わず、ampx sandbox に統合されます。ampx sandbox を実行すると Amplify リソース（Cognito、AppSync）と Blocks の Nested Stack が一緒にデプロイされる形です。
ampx sandbox との非互換
ただし現時点では、Blocks を統合した状態で npx ampx sandbox をそのまま実行するとエラーになります。
[ERROR] Missing --conditions=cdk: Building Blocks will silently load
mock implementations instead of CDK constructs.
Fix: Set NODE_OPTIONS="--conditions=cdk" before running CDK synth
Blocks は Node.js の conditional exports でローカルモックと CDK Construct を切り替えています。--conditions=cdk が設定されていないと、モック実装がロードされてしまい CDK synth が失敗します。Blocks 独自の npm run sandbox はこのフラグを自動設定しますが、Amplify CLI（ampx）はまだこの仕組みを認識していません。
回避策:
NODE_OPTIONS="--conditions=cdk" npx ampx sandbox
環境変数を明示的に設定すれば動作します。将来的には Amplify CLI 側が自動で対応することが期待されます。
Blocks が本当に効くのは「業務アプリ化」フェーズ
ここまでの検証で、Blocks は「Amplify の代替」ではなく「Amplify で対応しにくい領域を埋める補完ツール」であることが確認できました。では、具体的にどういうタイミングで Blocks を足す判断になるのか。
検証とドキュメント分析を通じて見えてきたのは、Amplify で始めたプロジェクトが「業務アプリ」に成長するフェーズで Blocks の価値が発揮されるのではないかという仮説です。
Amplify プロジェクトの成長モデル
Phase 1: MVP / プロトタイプ
└── Amplify のみで十分（Auth + Data + Hosting）
→ Blocks は不要
Phase 2: 業務要件の複雑化
└── 「DynamoDB だと辛い」「定期バッチが欲しい」が出始める
→ Blocks を検討するタイミング
Phase 3: 本格的な業務アプリ
└── Amplify (Auth, Hosting, CI/CD) + Blocks (API, DB, Batch, AI)
→ CDK 全面移行を回避しつつ段階的に拡張
Phase 1 で Blocks を入れる理由はありません。Amplify の Auth + Data + Hosting で十分に速く MVP が作れます。
問題は Phase 2 です。業務アプリに成長すると、「月次で売上集計バッチを回したい」「CSV を非同期でインポートしたい」「DynamoDB のクエリパターンでは表現できないデータ集計がある」といった要件が出始めます。
従来はこのタイミングで CDK への全面移行（= 大規模リライト）を検討する必要がありました。Blocks があれば、backend.ts に3行追加するだけで Amplify のエコシステム内に留まったまま拡張できます。ホスティング・認証・CI/CD はそのまま、複雑なバックエンド機能だけ Blocks で段階的に足していく形です。
業務アプリで頻出する要件と Blocks の対応
| 要件 | Amplify だけ | + Blocks |
|---|---|---|
| RDB + SQL マイグレーション | DynamoDB は辛い | Database |
| 月次バッチ処理 | CDK で手書き |
CronJob 1行 |
| 非同期ジョブ（CSV インポート等） | CDK で手書き |
AsyncJob 1行 |
| メール通知 | 自前構築 | EmailClient |
| AI チャットサポート | Amplify AI Kit |
Agent + KnowledgeBase
|
これらは「Amplify 標準機能では対応しにくく、かつ業務アプリではよく求められる」要件です。
Agent Block のバックエンドは Amazon Bedrock（Bedrock Agents） です。ツール呼び出しや会話永続化を備えていますが、AgentCore Runtime のような自律的なマイクロVM実行やカスタムフレームワーク統合（Strands、LangGraph 等）には対応していません。シンプルな RAG チャットや定型的なツール呼び出しには十分ですが、複雑なマルチステップエージェントには別途 AgentCore の検討が必要です。
Database Block のバックエンドは Aurora Serverless v2（PostgreSQL 互換）です。通常の RDS PostgreSQL は現状選択できません。また、マルチリージョン対応が必要な場合は DistributedDatabase（Aurora DSQL）も用意されていますが、DSQL はシーケンスやトリガーなど一部機能に制約があります。
まとめ
現時点での評価
| 項目 | 評価 |
|---|---|
| Amplify Gen 2 への統合 | 可能（Nested Stack パターン） |
| 既存コードへの影響 | 最小限（backend.ts 3行追加） |
| ローカル完全実行 | Blocks 部分のみ可能（Amplify サービスはサンドボックス必須） |
Amplify + Blocks を検討すべきタイミング
以下の条件に当てはまり始めたら、Blocks の導入を検討する価値があります。
- DynamoDB では表現しきれないデータ操作が出てきた（RDB + マイグレーションが必要）
- 定期実行・非同期バッチが必要になった
- AI 機能や KnowledgeBase を追加したい
- CDK への全面移行は避けたいが、Amplify の枠を超えた機能が欲しい
Blocks はまだ Preview 段階ですが、GA 後は「Amplify で始めたプロジェクトが成長した先の現実的な選択肢」として存在感を増していくのではないかと感じました。今後のアップデートに注目していきたいところです。