AWS Blocksで開発体験向上：AgentCore Runtime上のリサーチエージェントと会話するNext.jsのWebアプリ開発

はじめに

2026年6月、AWSからAWS Blocksが発表されました。
そこでAWS BlocksのHostingや新規作成したbb-agentcore-runtime（カスタムAWS Block）を使いAmazon Bedrock AgentCore Runtime上のOpen Deep Researchと会話する検証用のWebアプリを作成してみました。
AWS Blocksを使うことにより、AWSアカウントなしでローカル開発し、そのままAWS本番環境にデプロイでき、開発者体験を向上することができました。

想定対象読者

• AWS Blocksに興味がある方
• フルスタックアプリやチャットボットを開発し、AWSにデプロイしたい方
• AWSやCDKの知識がある方（本来その知識は不要ですが、この記事はBlockの内部実装やフローまで踏み込むため）

この記事を読むとわかること

• AWS Blocksの概要、仕組みやフロー
• カスタムBlockを作成すべきかの判断や実現方法
• Next.js、assistant-uiを使った認証付きチャットUIの仕組み

AWS Blocksの概要

AWS Blocksは内部でAWS CDKを使っており、主な違いは下記です。

項目	AWS CDK	AWS Blocks
概要	Infrastructure as Code(IaC)。アプリとは別にインフラをコードとして明示的に実装する。	Infrastructure from Code(IfC)。アプリのロジックを書くとインフラが自動生成され、AWS知識なしで開発できる
学習コスト	AWSサービスとCloudFormationの理解が前提で学習コストは高め。インフラ専門知識が求められる	AWSやCDKの知識がほぼ不要で低い。AIエージェント向けファイル同梱でAI駆動開発にも最適化
ローカル開発	基本的にサポート無し（LocalStackは商用不可）	モック実装を標準搭載・AWSアカウント不要
対応言語	TypeScriptを中心にPython / Java など	TypeScriptのみ（フロントエンドは多数。モバイルも）
型安全性	CDK側は安全だが、アプリ側はOpenAPI等の仕組みが必要	スキーマ定義からDB・API・フロントまで型が自動伝播
抽象度	リソースレベル(L1/L2/L3コンストラクトを自分で選定)	ユースケースレベル(Block内部でL1〜L3を隠蔽)
対応リソース	L1: 全CloudFormation L2: 多数 L3: 主要ユースケースレベル	主要ユースケースレベル（記事下部のビルトインBlock一覧を参照）
想定ケース	大規模本番、マイクロサービスなど	フルスタックアプリ、AIエージェント/チャットボット、イベント駆動ワークフロー

AIチャットWebアプリ nextjs-agentcore-aws-blocks-demo

今回作った検証用のAIチャットWebアプリには3つのモードがあります。

• Chat: Amazon Bedrockのモデルと直接会話するシンプルなAIチャット
• Search: DuckDuckGo / Tavily / AgentCore Web Search(MCP)に対応したWeb検索
• Open Deep Research: AIが会話しながら自律的に複数ソースのWeb検索を行い、包括的なレポートを作成するAIリサーチエージェント

ソースコードはGithubで公開しています。

ログイン画面

今回は検証用のため、一般的に推奨されるOAuthやCognitoを使わず、@aws-blocks/bb-auth-basicを使いユーザー情報用のテーブルやJWTセッションを使ったサインアップ、ログインを実現しました。

@aws-blocks/bb-auth-basicは内部で@aws-blocks/bb-kv-storeを使っています。

AWS本番環境ではサインアップするとDynamoDBのテーブルにユーザーが追加されます。

一方、ローカル開発では .bb-data/my-app-auth-users/store.json にユーザーが追加されます。

{
  "demouser": "\"{\\\"hash\\\":\\\"$2b$12$9xxx\\\",\\\"createdAt\\\":\\\"2026-07-17T16:32:47.623Z\\\"}\""
}

フローチャートは下記になります

チャット画面

AgentCore Runtimeを使わない素のチャット画面です。assistant-uiのサンプルを踏襲しています。
@assistant-ui/react-ai-sdkが提供するuseChatRuntime hookを使い、NextJSのRoute Handlerである/api/chat経由で、Amazon Bedrockのモデル(Nova, Claude Sonnetなど)をストリーミング応答表示させています。

AWS本番環境では@aws-blocks/hostingにより、AWS LambdaのHostingComputedFunctionでNextJSのServer Side Rendering(SSR)やRoute Handlerが実行されます。

検索画面

Search Provider(DuckDuckGo / Tavily / AgentCore Web Search)を切り替えて検索結果一覧を表示する画面です。NextJSのRoute Handlerである/api/searchのRoute Handler内で、AgentCore Web Searchを選んだ場合のみ@modelcontextprotocol/sdkのStreamableHTTPClientTransportでAgentCore Gateway(MCPサーバー)にSigV4署名付きで接続し、web-search___WebSearchツールを呼び出します。
Open Deep Researchのリサーチエージェントが内部的に使っているのと同じAgentCore Gatewayを、単体のツールとして切り出して動作確認できます。

Amazon Bedrock AgentCoreのWeb Searchを使っています

検索プロバイダとして採用しているDuckDuckGoはAPIキー不要で手軽な反面、安定性やレート制限に不安が残ります。Tavilyは検索特化のサービスとして安定していますが、AWSとは別にアカウント登録とAPIキー管理が必要です。それに対しAgentCore Web Searchは、AWSアカウント内でIAMによる認可だけで完結し、追加の契約やシークレット管理が不要な点がメリットです。

検索画面のフローは次の通りです。

Open Deep Research画面

@assistant-ui/react-ag-uiが提供するuseAgUiRuntime hookを使い、フロントエンドからAgentCore Runtime上のOpen Deep ResearchエージェントへAG-UIプロトコル(SSE)で直接接続します。BlocksのTS API(aws-blocksのHandler Lambda)は会話開始時に一度だけ短期STSクレデンシャルを発行するだけで、SSEストリーミング自体には一切関与しません。

AG-UIプロトコルについて

AG-UIは、エージェントのバックエンドで起きた動的なイベント(メッセージのストリーミング、ツール呼び出し、状態更新など)を、フロントエンドに伝えるためのオープンなイベントベースプロトコルです。LangGraph・Strands Agents・CrewAIといった複数のエージェントフレームワークと、React・Angular・Vueといった複数のフロントエンドの組み合わせに対応することを狙って設計されており、バックエンドとフロントエンドの実装を疎結合にできます。

Amazon Bedrock AgentCore RuntimeはこのAG-UIプロトコルをネイティブにサポートしており、AG-UIモードでデプロイされたコンテナに対しては「透過的なプロキシ」として振る舞います。認証(SigV4またはOAuth 2.0)・セッション分離・スケーリング・可観測性はすべてAgentCore Runtime側が肩代わりしてくれるため、コンテナ側はポート8080でPOST /invocationsとGET /pingを公開するだけで済みます。本デモのservices/agentcore-agentでは、この/invocationsをag-ui-langgraphパッケージが自動的に用意してくれるため、LangGraphのグラフをAG-UI準拠のFastAPIサーバーとしてラップするだけでこの要件を満たせています。

前述の通り、TS APIはSSEストリーミングに一切関与しませんが、これは最初からそうだったわけではありません。当初はTS API(aws-blocksのHandler Lambda)がAG-UIのリクエスト/レスポンスをAgentCore RuntimeのInvokeAgentRuntimeへ中継するプロキシ構成を検討していましたが、以下の理由から、フロントエンドがAgentCore Runtimeへ直接接続する現在の構成に転換しました。

• Lambda・API Gatewayの実行時間制限: Lambdaは(Function URLのストリーミング対応を含めても)15分のハード上限があります。API Gateway経由の場合はさらに厳しく、統合タイムアウトはデフォルト29秒で、2024年6月のアップデートで緩和された後も最大300秒(5分)までしか延長できません。ディープリサーチのような長時間のエージェント実行やSSEでの長時間ストリーミングには、どちらも力不足です。デフォルトで最大8時間(maxLifetimeのデフォルト28800秒)まで1セッションを維持できるAgentCore Runtimeに対し、中継Lambda/API Gatewayを挟む構成はここがボトルネックになります
• AgentCore GatewayはAG-UIに対応していない: AgentCore Runtimeが提供するエージェント向けの接続レイヤーには、ツールに接続するMCP、エージェント同士を接続するAgent2Agent(A2A)、そしてユーザーに接続するAG-UIの3種類がありますが、これらはそれぞれ別の仕組みです。AgentCore GatewayはMCP(およびA2Aのパススルー)向けの入口であり、AG-UIのトラフィックをGateway経由で流す経路は用意されていません。そのため、仮にGatewayを中継点として使おうとしても構成できず、AG-UIはAgentCore Runtimeに直接繋ぐ以外の選択肢がありませんでした

これらを踏まえ、TS APIは会話開始時に短期STSクレデンシャルを発行するだけの役割に留め、SSEストリーミング自体には一切関与しない現在の構成に落ち着きました。

AWSアーキテクチャ

AWSアーキテクチャとBlockの関係は下記になります。右下が今回作成したカスタムAWS Blocksです。

フォルダ構成

後述するコマンドで作成されるフォルダ構成をベースにしています。（ただし、services/を除く）

• package.json npm workspaces: ["aws-blocks", "packages/*"]、script、dependenciesを定義するルートのpackage.json
• .bb-data/ ローカル開発時の各Blockの永続化先(後述)
  • my-app-auth-users/ AuthBasicが管理するユーザー情報を保存するディレクトリ(AWSではDynamoDB)
  • settings.json AppSettingがローカルで生成するJWT署名用シークレットなどの設定値を保存するJSON 現在はauth-jwt-secretのみ(AWSではSSM Parameter Store)
• aws-blocks/ AWS Blocks(IfCレイヤー・CDKレイヤー)をまとめるワークスペース
  • package.json npm exports
  • index.ts AWS Blocks利用時のメインコード new Scope, AuthBasic, AgentCoreRuntime, ApiNamespace
  • index.cdk.ts CDK拡張用コード new cdk.App, Hosting
  • pipeline.cdk.ts CI/CD用(@aws-blocks/pipeline)
  • scripts/ ローカル開発サーバー起動などのスクリプト置き場
• packages/ カスタムBlockなどnpm packageを格納するワークスペース
  • bb-agentcore-runtime/ 今回新規作成カスタムBlock。AgentCore Runtimeのデプロイと短期クレデンシャル発行を担う
    • package.json npm conditional exportsでcdk/aws-runtime/mockの実装を切り替えるパッケージ定義
    • src/ srcディレクトリ
      • index.aws.ts 本番: STS AssumeRoleで短期クレデンシャル発行
      • index.cdk.ts CDK: Runtime + Gateway構築
      • index.mock.ts ローカル: ほぼ空実装（今回はPythonであり、別途起動するため）
      • types.ts 型定義
• services/ npm workspaces外のワークスペース用
  • agentcore-agent/ LangGraph(Python)。今回の意図とは違うがAgentCore CLIでもAgentCore Runtimeにデプロイ可
    • pyproject.toml Python依存関係・プロジェクト定義
    • Dockerfile AgentCore Runtimeへデプロイするコンテナイメージ定義
    • main.py ag-ui-langgraphでラップしたFastAPI(AG-UIサーバー)
    • open_deep_research/ open_deep_researchにAgentCore WebSearchを追加する改造を実施
• src/ Next.jsのソースコード
  • app/ Next.js App Router
    • .blocks-sandbox/config.json/route.ts AWS Blocksのsandboxモード用設定を返すRoute Handler
    • api/ バックエンドRoute Handlerを格納するディレクトリ
      • chat/route.ts Vercel AI SDK経由でBedrockモデルを呼び出す
      • search/route.ts DuckDuckGo/Tavily/AgentCore Web Searchを切り替えて検索する
      • mcp-discover/route.ts ユーザーが追加したMCPサーバーのツール一覧を取得する
  • page.tsx React UIコンポーネント（他にもtsx多数）

工夫した点など

AWS Blocksのnextjsテンプレートを利用し、@aws-blocks/hostingを活用

初めにnpm create @aws-blocks/blocks-app@latest my-app --template nextjsコマンドを実行し、環境（前述のフォルダ構成）を作成しました。

aws-blocksのテンプレートにはdefault, nextjs, react, auth-cognito, demo, bare, backend, amplifyが用意されており簡単に環境を構築することができます。
各テンプレートの実装詳細はcreate-blocks-app/templates/nextjsなどで確認することができます。

nextjsテンプレートの特徴としては、aws-blocks/scripts/server.tsのstartDevServer()によりBlocks APIのバックエンドとNext.jsのフロントエンド(next dev)の両方を起動し、両者をつなぐプロキシまで面倒を見てくれる点があります。
今回はこれに加えてPython製のAgentCore Runtime開発サーバー(FastAPI/uvicorn)をconcurrentlyで加えておりnpm run dev一発でTS/Next.js/Pythonの3プロセスすべてが立ち上がります。
@aws-blocks/hostingはCloudFront + S3 + Lambda(SSR/画像最適化/ISR再検証)一式を面倒みるCDK L3コンストラクト(HostingConstruct)で、Next.js/Nuxt/Astro/SPA向けのフレームワークアダプタがビルド成果物からDeployManifestを作り、それをこのL3コンストラクトに渡してプロビジョニングする構成になっています。今回はSSR Lambdaに対してBedrockのInvokeModel権限とAgentCore Gatewayの呼び出し権限を追加で付与しています(/api/searchや/api/chatがSSR Lambda上で動くため)。

assistant-uiによるチャットUIの実現

assistant-uiを使うことにより、ChatGPT, Claude, Grok, Gemini, PerplexityライクなAIチャットUIを簡単に実現できます。Demoサイトの左上から切り替えて確認できます。また、ExamplesやShowCaseといったAI Agentアプリも簡単に実現することができます。

今回は、以下のようなコマンドを実行しました。

• npx assistant-ui@latest init
• npx assistant-ui@latest add thread-list threadlist-sidebar assistant-sidebar

上記と公式の手順やnpx assistant-ui@latest create(別環境)を参考に、ストリーミング、Markdown表示、音声認識、TTS、会話スレッドなどを簡単に実現することができました。

assistant-uiのランタイムは差し替え可能な設計になっており、本デモでは同じThread UIコンポーネントに対して2種類のランタイムを使い分けています。Chat画面はuseChatRuntime(Vercel AI SDK連携)、Open Deep Research画面はuseAgUiRuntime(AG-UI連携)です。バックエンドの技術スタックが全く違っても、共通のAssistantRuntimeで抽象化され、フロントエンドのチャットUIといった機能はそのまま使い回せる点がassistant-uiの強みだと感じました。

カスタムBlock bb-agentcore-runtime

下記のビルトインBlock一覧を探しても、残念ながらAgentCore Runtimeはありません。
bb-agentはAIエージェント向けのBlockで、OllamaやStrands Agent SDKに対応している便利なBlockですが、bb-async-jobというSQSとNode.jsのLambdaを使うため今回には不適です。
AgentCore CLIは便利ですが、Webアプリなどのフルスタック向けではなく、別にデプロイする必要があります。
CDKレイヤーとしてaws-blocks/index.cdk.tsにaws-cdk-lib/aws-bedrockagentcoreを追記できますが、ローカル開発体験に課題が残ります。
そこでカスタムBlockとしてbb-agentcore-runtimeを作成しました。

設計判断ルールは下記になります。

CDKレイヤー(aws-blocks/index.cdk.ts)を使うべきケース

1. ビルトインBlocksがなく、AWSリソースを単純に使いたい場合
2. カスタムドメインなどの環境固有の設定を構成する場合
3. 既存のCDKアプリケーションに統合する場合

カスタムBlockを使うべきケース

1. 複数のAPIメソッドで同じAWSリソースとSDKの定型コードを繰り返している場合
2. ビルトインBlockを持たないAWSリソースに対して、ローカル開発のサポートが必要な場合
3. プロジェクトやチーム間で再利用可能な機能を共有したい

ローカル・本番・CDKをどう1つのパッケージで切り替えるか

{
  "exports": {
    ".": {
      "cdk": { "types": "./src/index.cdk.ts", "default": "./src/index.cdk.ts" },
      "aws-runtime": "./src/index.aws.ts",
      "types": "./src/index.mock.ts",
      "default": "./src/index.mock.ts"
    },
    "./cdk": { "types": "./src/index.cdk.ts", "default": "./src/index.cdk.ts" }
  }
}

bb-agentcore-runtimeは同じAgentCoreRuntimeクラスに対して3つの実体を持ちます。CDK合成時はindex.cdk.ts、Lambdaランタイムではindex.aws.ts、それ以外(ローカルのnpm run dev)ではindex.mock.tsが使われます。呼び出し側のアプリケーションコードは環境分岐を一切書かず、import { AgentCoreRuntime } from 'bb-agentcore-runtime'とするだけで、実行コンテキストに応じた実装がNode.jsのconditional exportsによって自動的に解決されます。今回、ローカル用のindex.mock.tsはPythonのため空実装でフロントが無認証で直接localhost:8080のAG-UIサーバーに繋ぐ形になっています。

AgentCore Web SearchをCDKでデプロイ

本デモの開発に着手した2026年6月20日頃の時点では、Web検索用のGatewayにコネクタ形式のターゲットを追加する手段は、CloudFormationのAWS::BedrockAgentCore::GatewayTargetにもCDKのL1/L2コンストラクトにも存在せず、この実装ではその部分だけAwsCustomResourceでAWS SDKのCreateGatewayTargetを直接呼び出すことで実現していました。
なお、その後aws-cdk-lib 2.261.0(2026年7月2日リリース)で、CloudFormationやCDKのL1コンストラクトが追加されましたが、L2コンストラクトではconnector形式はまだ対応されていないようです。

注意点・残課題など

• AWS Blocksはまだプレビュー版のため、破壊的変更が入る可能性があります。
• 今回bb-agentcore-runtimeという名前にしましたが、bbはBuiltin Blocksの略の可能性がある点、既存のBlock名はAWSリソース名を避けて抽象化している点から、cb-agent-runtimeもしくは具体化して、cb-deep-researchというBlock名が適切でした。
• 現デモではHITL(Human-in-the-loop)はまだ実装・検証していません。LangGraphのinterrupt()を使えば、AG-UIのRUN_FINISHED(outcome.type === "interrupt")イベント経由で@assistant-ui/react-ag-ui側のrequires-action状態として表示できる想定です。
• 現デモではag-ui-langgraphかGraph構造の問題によりOpen Deep Researchのthinkingやツール呼び出しの過程などストリーミング表示ができていません。

付録: AWS Blocksの一覧

AWS BlocksのビルトインBlock一覧

AWS公式の一覧はBlocks referenceを参照

Block名称	実装先パス	AWSリソース	ローカル開発時の実現方法	依存先Block
Agent	packages/bb-agent	Bedrock (InvokeModel権限のみ)	ローカルモデル(Ollama等) / 未設定時はCanned応答	bb-async-job, bb-distributed-table, bb-file-bucket, bb-logger, bb-realtime
AppSetting	packages/bb-app-setting	SSM Parameter Store	ローカルJSONファイル	bb-logger
AsyncJob	packages/bb-async-job	SQS Queue + Lambda (SqsEventSource)	インプロセスキュー処理	bb-logger
AuthBasic	packages/bb-auth-basic	専用リソースなし (AppSetting/KVStore合成)	本番と同一コード (KVStoreのローカル実装に依存)	bb-app-setting, bb-kv-store, bb-logger
AuthCognito	packages/bb-auth-cognito	Cognito User Pool + UserPoolClient + Group	インメモリ + .bb-data/<id>/state.json (AWS不要)	bb-app-setting, bb-kv-store, bb-logger
AuthOIDC	packages/bb-auth-oidc	Cognito User Pool + IdP連携 (Google/GitHub/Okta等)	インプロセス スタブIdP (OidcClientEngine)	bb-app-setting, bb-kv-store, bb-logger
CronJob	packages/bb-cron-job	EventBridge Scheduler + Lambda	インプロセス スケジュール実行	bb-logger
Dashboard	packages/bb-dashboard	CloudWatch Dashboard	503を返すスタブルート (ローカル未対応)	(なし)
Database	packages/bb-data	Aurora Serverless v2 (PostgreSQL) + RDS Data API / fromExisting() で既存DB接続可	PGlite (インプロセス組み込みPostgres)	bb-app-setting, bb-logger
DistributedDatabase	packages/bb-distributed-data	Aurora DSQL (CfnResource)	PGlite + DSQL検証レイヤ (DsqlMockEngine)	bb-logger
DistributedTable	packages/bb-distributed-table	DynamoDB Table	ローカルJSONファイル	bb-logger
EmailClient	packages/bb-email-client	Amazon SES (ConfigurationSet)	ローカルJSONファイルにキャプチャ (実送信なし)	bb-logger
FileBucket	packages/bb-file-bucket	S3 Bucket	ローカルファイルシステム (.bb-local/<name>/)	bb-logger
KnowledgeBase	packages/bb-knowledge-base	Bedrock Knowledge Base + S3 Vectors + S3 Bucket	TF-IDF検索インデックス (ローカルファイル対象)	bb-logger
KVStore	packages/bb-kv-store	DynamoDB Table	ローカルJSONファイル	bb-logger
Logger	packages/bb-logger	CloudWatch Logs (LogGroup)	本番と同一実装 (stdout/stderr)	(なし)
Metrics	packages/bb-metrics	CloudWatch EMF (Lambdaログ経由・専用リソースなし)	本番と同一実装 (EMF形式JSONをstdout)	bb-logger
Realtime	packages/bb-realtime	API Gateway WebSocket API + Lambda + DynamoDB (DistributedTable経由)	ローカル開発サーバ内WebSocket (mock-middleware)	bb-app-setting, bb-distributed-table, bb-logger
Tracer	packages/bb-tracer	AWS X-Ray (Lambda active tracing設定)	ローカルJSONトレースファイル	bb-logger

今回は一部しか使っていませんが、一般的なユースケースは満たせていると思います。

AWS Blocksのパッケージ一覧

ビルトインBlock以外のパッケージは以下です。

package名	実装先パス	役割
@aws-blocks/core	packages/core	フレームワークの中核。Scope(リソース境界を定義するCDKコンストラクトのベースクラス)、ApiNamespace等のAPI定義プリミティブ、CDK用のcdk/(blocks-backend, stack-metadata, synth-guard等)、クライアント用のclient/、共通設定/暗号/SDKレジストリのcommon/を提供。CLIとしてblocks-generate-spec(型定義生成)・blocks-telemetry(テレメトリ)のbinを持つ。@aws-blocks/hostingと@aws-blocks/pipelineに依存し、両者を内部で利用。全Blockが依存する土台。
@aws-blocks/blocks	packages/blocks	全19 Building Block + coreのプリミティブを1つの入口からimportできるようにする再エクスポート専用パッケージ（import { Scope, KVStore, AuthBasic } from '@aws-blocks/blocks'）。全bb-*パッケージおよびauth-common/coreに依存。blocks-vendorizeというbinスクリプトも持つ（core/scriptsを再エクスポートしたベンダリング用CLI）。
@aws-blocks/hosting	packages/hosting	Webアプリホスティング用の低レベルCDK L3コンストラクト。CloudFront + S3 + Lambda + WAF + 監視 + DNSを一括プロビジョニングするHostingConstructと、Next.js/Nuxt/Astro/Nitro/SPA向けのフレームワークアダプタ（ビルド実行→DeployManifest生成→コンストラクトへ引き渡し）を提供。Block一覧のBlockではなく、フロントエンドのデプロイ基盤。
@aws-blocks/pipeline	packages/pipeline	CDK PipelinesベースのCI/CD構築パッケージ。ブランチ毎に自己変異型CodePipeline V2を作成し、GitHub(CodeConnections経由)からのsynth→自己更新→ステージ順デプロイ(承認/ベイクタイム対応)を提供するPipelineコンストラクトをエクスポート。
@aws-blocks/auth-common	packages/auth-common	AuthBasic/AuthCognito/AuthOIDCの3認証Blockが共有する型（BlocksAuth, AuthUser, AuthState等）とUIコンポーネント（Authenticator等、/ui）、Cookieセキュリティポリシー（/cookies）を提供する共通ライブラリ。カスタム認証Block自作時にも利用可能。coreのみに依存。
@aws-blocks/data-common	packages/data-common	bb-data・bb-distributed-dataの2つのSQL系Blockが共有する内部専用ライブラリ（READMEにも直接依存しないよう明記）。DatabaseEngineインターフェース、DatabaseBase、SQLインジェクション対策の`sql`タグ付きテンプレート、Kyselyアダプタ、マイグレーションランナーを提供。
foundations	packages/foundations	再エクスポートパッケージ
@aws-blocks/create-blocks-app	packages/create-blocks-app	新規プロジェクトのスキャフォールディングCLI（npx @aws-blocks/create-blocks-app）。aws-blocks/ワークスペースの作成、CDKインフラ設定、テンプレートからのスターターコード生成を担当。他パッケージへの依存なし（実行時にテンプレートを展開する独立ツール）。

ビルトインBlock以外にも@aws-blocks/hosting(CDN)や@aws-blocks/pipeline(CI/CD)といった便利なパッケージが用意されています。

まとめ

• AWS Blocksを使い、AWSアカウントなしでローカル開発しつつ、そのまま本番環境にもデプロイできました
• ビルトインBlockにないAWSサービス(AgentCore Runtime)であっても、カスタムBlockとして「ローカルはmock実装・本番はAWS SDK・CDKはインフラ定義」という3実体をconditional exportsで切り替えるパターンさえ踏襲すれば、既存のビルトインBlockと同じ開発体験(npm run dev一発、環境分岐コードなし)をすることができました
• ぜひ、皆さんもカスタムBlockを作ってみましょう

参考資料

• aws-devtools-labs/aws-blocks - GitHub
  • AWS Blocksリポジトリ本体。特にpackages/bb-async-job, packages/create-blocks-app/templates/nextjs, packages/hosting, test-apps/hosting-ssr, test-apps/extending-blocks-guideを参考にした
• AWS Blocks公式ドキュメント
• Amazon Bedrock AgentCore公式ドキュメント
• Introducing Web Search on Amazon Bedrock AgentCore - AWS Blogs
• AG-UI Agent Runtime - assistant-ui