はじめに
はじめに
AWS Blocks は、AWS が公開したオープンソースの TypeScript フレームワークです。データベースや認証、リアルタイム通信、AI エージェントといったバックエンドの機能を「ブロック」として組み合わせるだけで、フルスタックアプリケーションを構築できます。公式の言葉を借りると「事前構築済みのモジュールからバックエンドを組み立て、コードからインフラを生成する（compose backend capabilities from pre-built modules that generate infrastructure from code）」フレームワークです。
特徴的なのは、npm run dev を叩くとローカルマシンだけで動くフル機能のアプリが立ち上がり、準備ができたら同じコードをコード変更ゼロで AWS にデプロイできる、という開発体験です。AWS アカウントは開発を始める時点では不要で、デプロイする段階で初めて必要になります。
この記事では、AWS Blocks がどういうフレームワークなのか、どんなブロックが用意されているのか、そして AI コーディングエージェント（Kiro など）とどう連携するのかを、実際の構築例も交えて整理していきます。執筆時点（2026年6月）で AWS Blocks は Preview 段階です。仕様や API は今後変わる可能性がある点は、最初にお伝えしておきます 🙏
この記事で扱う内容は次のとおりです。
- AWS Blocks の全体像と設計思想
- 用意されているブロックの一覧
-
npm createからnpm run devまでの始め方 -
AGENTS.mdを介した AI エージェントとの連携 - Agent Block で AI チャットアプリを作る具体例とハマりどころ
AWS Blocks の全体像 🗺️
AWS Blocks のアプリは、大きく「フロントエンド」「ブロックで構成したバックエンド」「AWS 上のインフラ」の3層で考えると理解しやすいです。開発者が書くのは上の2層で、一番下のインフラはブロックから自動生成されます。
以下の図は、開発者が触る範囲と自動生成される範囲の関係を示しています。
この図のポイントは2つあります。1つ目は、フロントエンドとバックエンドの型がコード生成なしで自動的に連動することです。データスキーマを一度定義すれば、フロントエンドの型が自動で更新されます。2つ目は、開発者は AWS CDK やリソースを直接書かなくてよいことです。ブロックを組み合わせると、その下の CDK 定義とインフラが内部で生成されます。
そして、この同じコードが「ローカル」と「本番（AWS）」の両方で動きます。ローカルではモック実装が使われ、デプロイすると本物の AWS リソースに切り替わります。この切り替えにコードの書き換えは要りません。
なぜ「Blocks」という発想なのか 🤔
AWS でフルスタックアプリを作ろうとすると、これまでは「やりたいこと」と「書かなければいけないこと」の間に距離がありました。アバター画像をアップロードしたいだけなのに、S3 バケットの設定、IAM ポリシー、署名付き URL の発行、Lambda の権限まわりと、本質ではない作業がついて回ります。AWS Blocks はこの距離を縮めることを狙っています。
設計思想は、公式が挙げる4つの強みに集約されています。
| 強み | 内容 |
|---|---|
| ⚡ 秒速のローカル開発 |
npm run dev で完全に機能するローカル環境が起動する |
| 🔒 コード生成なしの型安全 | データスキーマを一度定義すればフロントエンドの型が自動で連動する |
| 🤖 エージェント対応 | steering ファイルを npm パッケージに同梱し、AI コーディングエージェントを支援する |
| 🪜 上限のない拡張性 | 必要なら 1 レイヤーを AWS CDK に降ろして細かくカスタマイズできる |
最後の「上限のない拡張性」は地味ですが重要です。抽象化されたフレームワークでよくある不満は「簡単なことは簡単だが、込み入ったことをやろうとすると壁にぶつかる」という点です。AWS Blocks は、いざとなればブロックの内側にある CDK レイヤーへ降りていける設計になっているので、フレームワークの天井に頭をぶつけても抜け道があります。公式の表現では "No ceiling on what you can build" と言い切っています。
用意されているブロック一覧 📦
ブロックは、アプリでよく使う機能をひとまとまりにしたものです。そしてブロックの面白いところは、ローカルではモック実装で動き、AWS にデプロイすると裏側で対応する AWS サービスが自動的にプロビジョニングされる、という点です。「どのブロックがどの AWS サービスになるのか」を、公式の Blocks リファレンスをもとに整理したものが以下の表です。
| カテゴリ | ブロック | 役割 | 対応する AWS サービス |
|---|---|---|---|
| 認証 | AuthBasic | ユーザー名／パスワード＋JWT セッション。試作・社内ツール向け | （ユーザー情報は DynamoDB に格納） |
| 認証 | AuthOIDC | Google・GitHub・Okta などの OIDC サインイン | 各 OIDC プロバイダー |
| 認証 | AuthCognito | MFA・ソーシャル・SAML・パスキー対応の本番向け認証 | Amazon Cognito |
| データ | KVStore | シンプルな Key-Value ストア。キャッシュやフラグに | Amazon DynamoDB |
| データ | DistributedTable | スキーマ検証・セカンダリインデックス・リッチクエリ対応 | Amazon DynamoDB |
| データ | Database | 本格的な PostgreSQL（Kysely・マイグレーション・RLS） | マネージド PostgreSQL（Aurora 系） |
| データ | DistributedDatabase | スケールゼロ＆マルチリージョン書き込みのサーバーレス SQL | サーバーレス分散 SQL（Aurora DSQL 系） |
| データ | FileBucket | 署名付き URL でのアップロード／ダウンロード | Amazon S3 |
| 通信 | Realtime | 型付き WebSocket の Pub/Sub チャンネル | API Gateway（WebSocket） |
| 非同期 | AsyncJob | 投げっぱなしのバックグラウンド処理 | Amazon SQS ＋ AWS Lambda |
| 非同期 | CronJob | スケジュール実行 | Amazon EventBridge |
| AI | Agent | ストリーミング・ツールコーリング・HITL 承認・会話永続化 | Amazon Bedrock（ローカルは canned provider） |
| AI | KnowledgeBase | RAG・意味検索向けの知識ベース | Amazon Bedrock Knowledge Bases |
| 連携 | EmailClient | トランザクションメール送信 | Amazon SES |
| 設定 | AppSetting | 設定値・シークレットを1つ保持 | AWS Systems Manager Parameter Store |
| 監視 | Metrics | カスタムメトリクス | Amazon CloudWatch（EMF） |
| 監視 | Logger | 構造化 JSON ログ | Amazon CloudWatch Logs |
| 監視 | Tracer | 分散トレーシング | AWS X-Ray |
| 監視 | Dashboard | メトリクス定義から自動生成される監視ダッシュボード | Amazon CloudWatch |
| ホスティング | Hosting | フロントエンドのデプロイ（SSR 対応、CDK レイヤー） | Amazon CloudFront など |
💡 認証の
AuthBasic・AuthOIDC、データのDatabase/DistributedDatabase、Hostingなどは、公式ドキュメントが具体的な AWS サービス名を明示していない箇所もあります（Databaseは「マネージド PostgreSQL にデプロイ」とだけ記載）。表のうち AWS サービス名が括弧書きや「〜系」になっているものは、挙動からの推定を含みます。
ブロックの数はプレビュー時点でおよそ20種類あり、認証・データ・リアルタイム・AI・監視まで、アプリに必要な定番機能がひととおり揃っています。これらを組み合わせるイメージを、公式が挙げている例で説明します。たとえば AI エージェントへこんなふうに頼むと、複数のブロックが一気に組み上がります。
ユーザーアバター用の FileBucket と、アップロード時にサムネイルを生成する AsyncJob、そして処理が終わったら UI に通知する Realtime チャンネルを追加して。
文章で頼んだ機能が、そのまま FileBucket + AsyncJob + Realtime という3つのブロックの組み合わせに対応しています。ここが「ブロックを組み合わせる」という発想の分かりやすいところです。
使い始める：npm create から npm run dev まで 🚀
実際に始めるのはとてもシンプルです。プロジェクトの雛形を作って、開発サーバーを起動するだけです。
# プロジェクトの雛形を生成
npm create @aws-blocks/blocks-app@latest my-app
# ディレクトリへ移動して開発サーバーを起動
cd my-app
npm run dev
# → http://localhost:3000 で起動
ここで動いているアプリは、AWS につながっていません。データベースは PGlite としてローカルで動き、AI モデルの呼び出しはモックが返ってきます。つまり AWS アカウントを持っていなくても、ネットワークがなくても、フル機能のアプリを触れる状態になります。
ローカルで作り込みが終わったら、同じコードを AWS にデプロイします。このとき、デプロイのためにアプリのコードを書き換える必要はありません。ローカルで動かしていたものが、そのまま本番のリソースで動きます。これが AWS Blocks の体験のなかでいちばん気持ちのいいところだと思います。
AI エージェントとの関係：AGENTS.md と steering files 🤝
AWS Blocks は「エージェント対応」を最初から設計に組み込んでいます。これは単なる飾りではなく、プロジェクトの中に AI コーディングエージェント向けの「読みもの」を同梱している、という具体的な仕組みです。
鍵になるのが、プロジェクト生成時にルートへ配置される AGENTS.md です。これは AI エージェント向けの指示書で、たとえば「ブロックを使う前に node_modules/@aws-blocks/blocks/docs/<package-name>.md のドキュメントを読みなさい」といった内容が書かれています。
クラスメソッドの検証記事では、AI コーディングエージェントの Kiro がこの AGENTS.md を検出し、そこから参照されているドキュメント群（bb-agent.md は約34KB あったそうです）を自分で読み込んでから実装を進めた、という挙動が報告されています。プロジェクトルートの AGENTS.md と npm パッケージ内の docs/ ディレクトリが、Kiro にとって事実上の steering files（エージェントに正しいやり方を教える舵取りファイル）として機能した、という整理です。
以下の図は、エージェントがブロックを実装するまでに何を読むかという流れを示しています。
この図のポイントは、エージェントが「いきなりコードを書き始める」のではなく、まず指示書とブロックのドキュメントを読んでから実装に入る、という順序が仕込まれていることです。フレームワーク側がエージェントに正しいアーキテクチャを教える、という発想がここに表れています。
実例：Agent Block で AI チャットアプリを作る 💬
ここからは、クラスメソッドの検証記事をもとに、Agent Block を使って AI チャットアプリを作る流れを追っていきます。
セットアップ
検証では Docker コンテナの中で作業しています。Node.js 22 のコンテナを起動して、その中で雛形を作るやり方です。
# Node.js 22 のコンテナを起動
docker run -it --rm -v $(pwd)/project:/work -w /work --network host node:22 bash
# プロジェクトを生成して開発サーバーを起動
mkdir my-chat-app && cd my-chat-app
npx @aws-blocks/create-blocks-app@latest . --yes
npm run dev
エージェントへの依頼内容
そのうえで、Kiro に対して次のような内容を依頼しています。
- Agent Block を使った AI チャット機能を追加する
- モデルは Claude Haiku 4.5 を指定する
- 入力欄・送信ボタン・履歴表示があるチャット UI を作る
- AuthBasic による認証を維持する
このとき使われたブロックは、ApiNamespace（API 定義）、AuthBasic（認証）、DistributedTable（DynamoDB によるデータ永続化）、Realtime（WebSocket でのリアルタイム更新）、そして Agent Block（AI 推論の抽象化）でした。
Agent Block のコード
生成された Agent Block の構成は、おおよそ次のような形です。
const agent = new Agent(scope, 'chat-agent', {
inferenceOnly: true,
model: {
deployed: {
provider: 'bedrock',
modelId: 'global.anthropic.claude-haiku-4-5-20251001-v1:0',
},
},
systemPrompt: '...',
});
ポイントは2つあります。
-
inferenceOnly: trueを指定すると、会話履歴の永続化を伴わない、純粋な推論だけのモードになります。 -
model.deployedでデプロイ先のモデルを指定します。ここでは Bedrock 上の Claude Haiku 4.5 を使っています。
ローカルと本番の自動切り替え
このアプリのいちばん面白いところは、ローカルと本番でモデルの挙動が自動的に切り替わる点です。
ローカルで npm run dev を実行している間は、Agent Block の CannedProvider が自動で適用され、"This is a canned mock response" という固定のモック応答が返ってきます。AI モデルにつながっていなくても、チャット UI の動作確認はできるわけです。
そして同じコードを AWS にデプロイすると、今度は Bedrock 上の Claude Haiku 4.5 から本物の応答が返ってきます。コードを書き換えていないのに、環境に応じて挙動が切り替わります。
以下の図は、同じコードがローカルと本番で別のプロバイダーにつながる様子を示しています。
この図のポイントは、分岐が「コードの中の if 文」ではなく「実行環境」によって行われていることです。開発者はモックと本番のどちらを使うかを意識して書き分ける必要がありません。
デプロイの流れ
デプロイは、AWS の認証情報を環境変数で渡して npm run deploy を実行します。
docker run -it --rm \
-v $(pwd)/project/my-chat-app:/work -w /work \
-e AWS_ACCESS_KEY_ID=XXXX \
-e AWS_SECRET_ACCESS_KEY=XXXX \
-e AWS_SESSION_TOKEN=XXXX \
-e AWS_DEFAULT_REGION=ap-northeast-1 \
node:22 bash -c "npm run deploy"
所要時間は、初回デプロイが約10分、更新デプロイが約4分だったと報告されています。デプロイ時には CloudFormation、IAM、Lambda、DynamoDB、S3、CloudFront、Bedrock といったリソースの権限が必要になり、事前に CDK bootstrap（npx cdk bootstrap aws://ACCOUNT_ID/ap-northeast-1）と、Bedrock 側での Claude Haiku 4.5 のモデルアクセス有効化を済ませておく必要があります。
ハマりどころと現実 ⚠️
ここまで読むと「文章で頼むだけでアプリが完成する」ように聞こえるかもしれませんが、実際にはそう単純ではありませんでした。クラスメソッドの検証では、生成されたコードをそのまま使えたわけではなく、8件の手修正が必要だったと報告されています。代表的なものを挙げてみます。
| ハマりどころ | 内容 |
|---|---|
inferenceOnly の未指定 |
指定しないと会話履歴の永続化を伴う動作になり、stream() + complete() 実行時に FileBucket アクセスが発生してローカルでエラーになった |
| リージョン固有のモデル ID | Kiro は US リージョン向けの us.anthropic.claude-haiku-4-5-... を生成したが、ap-northeast-1 では global. prefix の global inference profile を指定する必要があった |
| ファイル形式の不一致 | Kiro が jsx を生成したが、プロジェクトは lit-html ベースだった |
| その他 | 型エラー、import の誤り、WebSocket 構成の問題など |
特に2つ目のリージョン固有の設定は、AWS に慣れていても引っかかりやすいポイントです。エージェントは「一般的な使い方」のコードは出せても、東京リージョン特有の Bedrock 設定や、永続化モードの細かい挙動までは面倒を見きれていなかった、ということになります。
ただ、ここで強調しておきたいのは、検証記事の総括の部分です。手修正は必要だったものの、ローカルで動作確認した最終版の aws-blocks/index.ts と src/index.ts を、デプロイのために追加で書き換える必要はなかった、と報告されています。つまり「ローカルで完成させたコードがそのまま本番で動く」という AWS Blocks の中心的な約束は、実際に成り立っていたわけです。エージェントが生成したコードの手直しと、フレームワークの透過的な環境切り替えは、別の話として評価できます。
競合・類似サービスとの位置づけ 🧭
AWS でフルスタック開発を支援するサービスというと、これまでも AWS Amplify などがありました。AWS Blocks がそれらとどう違うのかは、現時点で公式が詳細な比較を出しているわけではないので、断定は避けます。
そのうえで、AWS Blocks の輪郭を整理すると、次のような特徴が際立ちます。
- TypeScript のコードでバックエンドを「ブロックの組み合わせ」として表現する点
- ローカル（モック）と本番（AWS）を同じコードで透過的に切り替える点
- AI コーディングエージェント向けのドキュメントをパッケージに同梱している点
特に3つ目は、生成AI 時代に合わせて設計されたフレームワークらしさが出ています。「人間が読むドキュメント」だけでなく「エージェントが読む steering files」を最初から用意する、という発想は、これからのフレームワークの一つの方向性かもしれません。
まとめ 🎁
AWS Blocks は、TypeScript のブロックを組み合わせてフルスタックアプリを構築し、ローカルで作ったものをコード変更なしで AWS にデプロイできるオープンソースフレームワークです。データベースや認証、リアルタイム通信、AI エージェントといった機能が事前構築済みのブロックとして用意されていて、必要なら内側の CDK レイヤーまで降りてカスタマイズできます。
検証例からわかったのは、AI エージェントとの組み合わせは強力だけれど万能ではない、ということでした。エージェントは AGENTS.md を読んでブロックの正しい使い方を学び、それなりに動くコードを生成してくれます。一方で、リージョン固有の設定や永続化モードの挙動など、最後の詰めは人間の手が必要でした。
AWS Blocks の本質は「ローカルで完成させたコードが、書き換えなしでそのまま本番で動く」という一点に尽きる、ということです。モックと本番の切り替えをコードに書かなくていい、という体験は、AI 機能のように「とりあえずローカルで挙動を固めたい」場面でとても効いてきます。
最後に改めてお伝えすると、AWS Blocks は執筆時点（2026年6月）で Preview 段階です。試すときは、仕様が変わる前提で気軽に触ってみるのがよさそうです 😊