2026.06.22 aws

AWS Blocksとは？TypeScriptで作るAWS用バックエンド基盤【Preview】

AWSは2026年6月16日、AWS BlocksのPublic Previewを公開しました。データベース・認証・リアルタイム通信・AIエージェントといったバックエンド機能を「Block」という部品として組み合わせ、TypeScriptだけでAWS上のバックエンドを構成できるオープンソースフレームワークです。本記事では、AWS Blocksの定義と公開の経緯、「コードからインフラを生成する」仕組み、提供されるBlockの種類、AWS CDKやAmplify Gen2との使い分け、環境構築からデプロイまでの手順、そしてPreview段階での採用判断までを、公式ドキュメントとnpmの一次情報に基づいて整理します。同じ「Blocks」でもEC2 Capacity Blocksとは別物である点も最初に切り分けます。

目次

まとめ｜AWS Blocksの位置づけと現時点での採用判断

AWS Blocksは、インフラ定義を別ファイルで書かずに、アプリケーションコードからインフラを生成する「infrastructure from code」型のフレームワークです。最大の特徴は、npm run devでAWSアカウント不要のローカル環境が立ち上がり、同じコードを無変更でAWSにデプロイできる点にあります。フレームワーク自体は無償で、課金は実際に使ったAWSサービス分のみです。

結論として、PoCや社内ツール、新規SaaSの立ち上げを素早く回したいチームには有力な選択肢です。一方、現行はバージョン0.1.x系のPublic Previewであり、仕様もパッケージも頻繁に変わります。本番のミッションクリティカルな基盤や、長期にわたって構成を固定したい要件では、現時点での全面採用は見送るのが妥当です。判断の軸は「Previewの変化を許容できるフェーズかどうか」に集約されます。

AWS Blocksの定義とPreview公開の経緯｜既存の同名概念との区別

AWS Blocksの定義｜TypeScriptでバックエンドを定義するオープンソース基盤

AWS Blocksは、バックエンド機能を「Block」という単位で提供するTypeScript製のオープンソースフレームワークです。1つのBlockは、クラウドリソース・実行時API・ローカル実装をまとめた完結した機能単位で、それぞれが個別のnpmパッケージとして公開されています。必要なBlockを選んで組み合わせると、AWSのベストプラクティスに沿ったインフラ構成が自動的に定義されます。開発者はインフラ構築ツールを新たに覚える必要がなく、アプリケーションのロジックに集中できる設計です。アンブレラパッケージの@aws-blocks/blocksが、各Blockとコアランタイムをまとめて再エクスポートします。

Public Preview公開日と現行バージョン｜2026年6月時点の0.1.x系

公開日は2026年6月16日。GitHubリポジトリはaws-devtools-labs/aws-blocksで管理されています。npm registryで確認できる最新版は@aws-blocks/blocksが0.1.4、@aws-blocks/coreが0.1.3で、いずれも初回公開が2026年6月15日、直近の公開が同年6月19日です。公開からわずか数日で5つのバージョンが出ている点からも、APIが固まりきっていないことが読み取れます。検証や記事化を行う際は、実行日と生成された@aws-blocks/*各パッケージのバージョンを必ず記録しておくと、再現性を確保できます。

混同しやすい既存概念との区別｜Capacity Blocks・building blocksとの違い

「AWS Blocks」という語は、新フレームワーク以前から別の文脈で使われてきました。検索結果でも、GPUを予約する「EC2 Capacity Blocks for ML」、VPCの「CIDR blocks」、学習用の「AWS building blocks（AWSの構成要素）」といった無関係な概念が混在します。これらはいずれもバックエンド開発フレームワークとは別物です。本記事が扱うAWS Blocksは、2026年6月に登場したアプリケーションバックエンド構築用のTypeScriptフレームワークを指します。検索意図を取り違えないよう、ここで一度切り分けておきます。

AWS Blocksの動作原理｜コードからインフラを生成する仕組み

infrastructure from codeとIaCの違い｜インフラ定義を別途書かない設計

従来のInfrastructure as Code（IaC）では、CloudFormationテンプレートやTerraformの記述、CDKのスタック定義など、インフラ用のコードをアプリとは別に書きます。AWS Blocksが掲げる「infrastructure from code」は、この前提を反転させます。new DistributedTable(scope, 'todos', {...})のように書いたアプリケーションコードそのものから、デプロイ時にインフラ構成が生成される仕組みです。インフラ専用の記述を別管理しないぶん、定義の二重化や型の不一致が起きにくくなります。IaCそのものの背景や意義については、Infrastructure as Codeがなぜ注目されているのかを参照すると、両者の違いがより明確になります。

同一コードが3つの文脈で動く仕組み｜ローカル・CDK合成・Lambda実行

AWS Blocksは、Node.jsのconditional exports（条件付きエクスポート）を使い、同じ記述を実行文脈ごとに別の実装へ切り替えます。文脈は3つです。

  1. ローカル開発：Blockはインメモリやファイルシステムのストレージとして動作し、アプリは自分のマシン上で完結する
  2. CDK合成：BlockはCDKコンストラクトを生成し、CloudFormationテンプレートが作られる
  3. Lambda実行：BlockはAWS SDK経由で実際のAWSサービスを呼び出す

たとえばnew KVStore(scope, 'todos')という1行は、開発時にはローカルストア、デプロイ時にはDynamoDBテーブル、本番ではSDK呼び出しへと姿を変えます。コードは一切書き換えません。この「書いたコードを変えずに環境を移す」設計が、AWS Blocksの中核です。

ローカル開発の実体｜PGlite・インメモリによるモックとその限界

ローカル環境は、Database BlockがPGliteで動くPostgres、認証はローカルのJWTトークン、リアルタイムはローカルのWebSocketサーバーといった「モック実装」で構成されます。AWSアカウントも認証情報も不要で、npm run devだけで認証付きのアプリがlocalhost:3000で動きます。ただし、ローカルはあくまでモックです。IAM・ネットワーク・サービスクォータ・レイテンシといったAWS固有の挙動は、ローカルでは再現されません。データの永続性もモック実装に依存するため、本番同等の永続性検証はAWSへのデプロイ後に行う必要があります。ここを理解せずにローカルの動作だけで判断すると、デプロイ後に想定外の差異に直面します。

エンドツーエンドの型安全｜スキーマからフロントまでコード生成なし

Web向けでは、データスキーマからフロントエンドまで型が一貫して流れます。TypeScriptのジェネリクスと型推論で伝播するため、コード生成のステップやビルド工程は挟みません。データベースBlockのカラム型を変えると、フロントエンド側で即座に型エラーが表示されます。一方、SwiftやKotlin、Dart（Flutter）向けのネイティブクライアントは仕組みが異なり、blocks.spec.jsonから型付きクライアントを生成するビルド時のコードジェネレーターと、JSON-RPCでバックエンドを呼ぶランタイムライブラリの組み合わせで実現します。Web版は生成なし、モバイル版は生成あり。この区別を押さえておくと、対応プラットフォームごとの開発体験を正しく見積もれます。

提供される主要Blockの種類とAWSサービスとの対応関係

データ系Block｜Database・DistributedTable・KVStoreの永続化先

データを扱うBlockは、永続化先のAWSサービスが決まっています。型安全なPostgresインターフェースを提供するDatabase（およびDistributedDatabase）は、ローカルではPGlite、AWS上ではマネージドなAurora PostgreSQLにデプロイされます。Zodスキーマで構造化データを定義するDistributedTableと、キーバリュー型のKVStoreは、デプロイ時にDynamoDBテーブルになります。DistributedTableはセカンダリインデックスにも対応します。リレーショナルな整合性が要るならDatabase、キー単位の高速な読み書きならDistributedTableやKVStoreと、用途で選び分ける構成です。

認証・リアルタイム・ファイル・ジョブ系Block｜本番サービスへの対応

アプリの土台となる機能も、Blockとして揃っています。認証はAuthBasic（ユーザー名・パスワードのJWTセッション）が手軽な入口で、本番要件に応じてAuthCognitoやAuthOIDCを選べます。Realtimeはpub/subを提供し、本番ではAPI Gatewayのマネージドな仕組みでWebSocket通信を担います。FileBucketはアップロード・ダウンロードを扱い、ローカルのファイルシステムがクラウドの挙動を模します。バックグラウンド処理のAsyncJobと、スケジュール実行のCronJobは、本番ではマネージドなコンピュート上で動きます。バックエンドのデプロイ先はAWS Lambda、API公開はAPI Gatewayが受け持つ構成です。手軽なAuthBasicのまま本番に出さず、要件に合う認証Blockへ切り替える判断が実務上のポイントになります。

AI系Block｜AgentとKnowledgeBaseによるBedrock連携のRAG実装

生成AI向けには、AgentとKnowledgeBaseの2つのBlockがあります。Agent Blockはツール呼び出し・会話の永続化・人間による承認（human-in-the-loop）に対応し、KnowledgeBase Blockと組み合わせると、自社データに接続したRAG（検索拡張生成）を構成できます。これらのAI系Blockは、内部でAmazon Bedrockを利用します。AWSが提供する別のエージェント基盤を併用したい場合は、オールTypeScriptで構築できるStrands Agentsの特徴も比較対象になります。エージェント実装の選択肢として、Block内で完結させるか、専用フレームワークを併用するかを検討材料にできます。

AWS BlocksとCDK・Amplify Gen2・SAMの使い分け

AWS CDKとの関係｜Blocksの土台でありいつでも降りられる設計

AWS BlocksのアプリケーションはCDKアプリケーションです。任意のCDKコンストラクトをBlockと並べて使えますし、既存のCDKスタックにAWS Blocksを組み込むこともできます。抽象化では表現しきれない細かい制御が必要になったら、CDKに「降りて」リソースを直接設定できる――つまり、抽象化に閉じ込められない設計です。CDKそのものの考え方を押さえたい場合は、AWS CDKの基本概念を先に理解しておくと、Blocksが何を肩代わりしているかが見えてきます。CDKを直接書く自由度は残しつつ、定型部分をBlockで省く、という位置関係です。

Amplify Gen2との違い｜補完関係と自動統合の実際

AWS公式は、BlocksとAmplifyを競合ではなく補完関係と説明しています。Amplifyはホスティング・CI/CD・マネージドなバックエンド体験を提供し、AWS Blocksは型安全なinfrastructure from codeとローカルファースト開発に重心を置きます。プロジェクト作成用CLIはAmplify Gen2のプロジェクトを自動検出し、統合する仕組みも備えます。TypeScriptでバックエンドを定義しローカルで素早く回す体験は、Amplify Gen2のローカル開発とも近く、どちらを主軸に据えるかは「ホスティングまで含めて任せたいか、インフラ生成と移植性を重視するか」で分かれます。両者を併用する構成も想定されています。

SAM・Serverless Frameworkとの比較｜デプロイ単位と抽象度の違い

SAMやServerless Frameworkは、Lambdaを中心としたサーバーレス構成をテンプレートや設定で定義するツールです。AWS Blocksとの違いは抽象度にあります。SAMやServerless Frameworkが「関数とイベントを宣言する」レイヤーであるのに対し、AWS Blocksは「データベースや認証といった機能Blockを組み合わせる」より上位のレイヤーで、しかもローカル実行と型安全をひとまとめに提供します。下表に主要な観点を整理します。

観点 AWS Blocks AWS CDK Amplify Gen2 SAM / Serverless Framework
定義の主役 アプリコード（IfC） インフラコード（IaC） バックエンド定義＋ホスティング 関数・イベント定義
言語 TypeScript TypeScript他多言語 TypeScript YAML/設定中心
ローカル実行 標準（モック） 限定的 対応 ローカルエミュレート
成熟度 Preview（0.1.x） 安定（GA） 安定（GA） 安定（GA）

新規のフルスタックを素早く立ち上げるならBlocks、細粒度のインフラ制御や既存資産との統合ならCDK、ホスティングまで一括ならAmplify、と役割で選ぶのが実務的です。

AWS Blocksの始め方｜環境構築からAWSデプロイまでの手順

前提環境とプロジェクト作成｜Node.js 22以上と初期化コマンド

必要な環境はNode.js 22以降とnpm 10以降です。新規プロジェクトはnpm create @aws-blocks/blocks-app@latest my-appで作成し、ディレクトリへ移動してnpm installを実行します。生成されるのは、バックエンドを記述するaws-blocks/index.tsとフロントエンドのsrc/を含む構成です。既存プロジェクト内でコマンドを実行すれば、そこへaws-blocks/のバックエンドを後から追加することもできます。AWSアカウントはこの段階では不要です。

ローカル起動からAWSデプロイまでの流れ｜npm run devとCDKデプロイ

セットアップ後はnpm run devでローカル開発サーバーが起動し、localhost:3000で各Blockがローカル実装のまま動きます。認証・データ保存・APIルーティングがアカウントなしで確認できます。コード変更はホットリロードで即座に反映されます。本番へ出す段になって初めてAWSアカウントを用意し、同じコードをデプロイします。デプロイ時にBlockがCDKコンストラクトへ展開され、CloudFormationテンプレートとして実体化される流れです。ローカルで作り込んでからデプロイに進むため、最初からAWSに触れる必要がありません。

料金とテレメトリ｜フレームワーク無償・従量課金とデータ収集の無効化

フレームワーク自体に追加料金はありません。費用が発生するのは、デプロイ後にアプリが使うAWSサービス（Lambda、DynamoDB、Aurora、API Gatewayなど）の標準料金分だけです。デプロイ先は全商用リージョンに対応します。なお、起動時には匿名の利用データが収集される旨の通知が表示されます。これを止めたい場合は、環境変数AWS_BLOCKS_DISABLE_TELEMETRY=1を設定して無効化できます。社内ポリシーで外部へのデータ送信を制限している場合は、この設定を導入手順に組み込んでおくとよいでしょう。

AWS Blocksを採用すべき場面と見送るべき場面の判断基準

採用が向くケース｜PoC・社内ツール・新規SaaSの素早い立ち上げ

AWS Blocksが力を発揮するのは、スピードが価値になる場面です。データベース・認証・ファイルアップロード・バックグラウンドジョブ・AIエージェントを1回の作業で足し、ローカルでフルスタックを検証してからAWSへ出す――この流れは、PoCやプロトタイプ、社内向けツール、新規SaaSの初期立ち上げと相性が良いです。AWSの各サービスを個別に深く学ばなくても動くものが作れるため、検証サイクルを短縮できます。TypeScriptで統一したい開発チームにとっては、学習コストの面でも入りやすい選択肢です。

採用を見送るべきケース｜本番ミッションクリティカルと長期固定要件

逆に、現時点で全面採用を避けるべき場面もはっきりしています。第一に、停止が許されない本番のミッションクリティカルな基盤です。0.1.x系のPublic Previewは仕様変更が前提で、破壊的変更が入る可能性を織り込む必要があります。第二に、構成を長期間固定して運用したい要件です。数日で複数バージョンが出る状況では、バージョン追従の運用コストが無視できません。第三に、IAMやネットワーク、レイテンシといったAWS固有の挙動を厳密に作り込む要件では、モック前提のローカル開発の恩恵が薄く、結局AWS上での検証が中心になります。これらに当てはまるなら、CDKやAmplify Gen2など成熟した選択肢を主軸にするのが妥当です。

導入時の実務上の注意点｜0.1.x系のバージョン固定とモック前提の検証

採用する場合でも、いくつか前提を固めておく必要があります。@aws-blocks/*各パッケージのバージョンはlockファイルで固定し、@latestでの無自覚なアップデートを避けます。ローカルはモックなので、永続性・IAM・ネットワーク・サービスクォータの検証はAWSサンドボックスへのデプロイ後に必ず行います。認証は手軽なAuthBasicのまま本番に出さず、AuthCognitoやAuthOIDCへ切り替える前提で設計します。Previewという性質上、公式の更新情報を定期的に確認し、破壊的変更の有無を追う運用も欠かせません。

よくある質問

AWS Blocksの検討時に出やすい疑問を、公式情報と現行バージョンの事実に基づいて整理します。

AWS Blocksは無料で使えますか？

フレームワーク自体は追加料金なしで利用できます。オープンソースとして公開されており、ローカル開発だけならAWSアカウントも不要です。費用が発生するのは、AWSへデプロイした後にアプリが使う各サービス（Lambda、DynamoDB、Auroraなど）の標準料金分だけです。

AWS BlocksとAWS Amplifyはどう違いますか？

競合ではなく補完関係です。Amplifyはホスティングやマネージドなバックエンド体験を提供するのに対し、AWS Blocksは型安全なinfrastructure from codeとローカルファースト開発に重心を置きます。プロジェクト作成CLIはAmplify Gen2を自動検出して統合でき、併用も想定されています。

AWS Blocksは本番環境で使えますか？

商用リージョンへのデプロイ自体は可能ですが、2026年6月時点ではバージョン0.1.x系のPublic Previewです。仕様変更が前提のため、停止が許されないミッションクリティカルな本番基盤での全面採用は、現段階では慎重に判断すべきです。

対応しているフロントエンドフレームワークは何ですか？

WebではNext.js、Nuxt、Astro、React、Vue、Svelte、Angularに対応します。ネイティブモバイルはSwift、Kotlin、Dart（Flutter）向けのクライアント生成に対応し、デスクトップアプリも視野に入っています。Webは型が直接流れ、モバイルは生成クライアント経由という違いがあります。

AWSアカウントがなくても使えますか？

ローカル開発だけならAWSアカウントは不要です。npm run devでPostgres・認証・リアルタイム・ファイル保存・バックグラウンドジョブを含むローカル環境が起動します。アカウントが必要になるのは、実際にAWSへデプロイする段階だけです。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る