Dockerなし、Windows、東京リージョンでAmazon Bedrock AgentCore FASTをデプロイする

はじめに

Amazon Bedrock AgentCore の フルスタックスターターテンプレート FAST（Fullstack AgentCore Solution Template） は、Amplify・AgentCore Runtime・Gateway・Memory・Code Interpreter を組み合わせた画面付きエージェントアプリケーションを CDK で一括デプロイできる便利なテンプレートです。

個人的にはこのFASTテンプレートをベースにすれば、大体のやりたいことはできてしまう認識です。
AIエージェントをとりあえず触ってみたい人は、FASTテンプレートのデプロイから始めてみましょう！

こちらの記事がとても分かりやすいです！
参考：https://dev.classmethod.jp/articles/bedrock-agentcore-fast-fullstack-template/

しかし、実際にデプロイしてみると、以下の2つの課題に直面しました。

1. Docker が使えない環境（企業Windows PCでBIOS仮想化が無効、WSL2が利用不可）
2. 東京リージョン（ap-northeast-1）へのデプロイ（デフォルトは us-west-2 前提）

本記事では、これらの課題をどのように解決したかをまとめます。

AgentCore FAST とは

FAST は、Amazon Bedrock AgentCore を使ったフルスタックなエージェントアプリケーションを素早く構築するためのスターターテンプレートです。

アーキテクチャ概要

バックエンドは CDK で単一スタックとしてデプロイされ、以下のリソースが作成されます。

• Cognito User Pool（ユーザー認証 + M2M認証）
• AgentCore Runtime（エージェント実行環境）
• AgentCore Gateway（MCP プロトコルによるツール連携）
• AgentCore Memory（会話履歴の保持）
• API Gateway + Lambda（フィードバック API）
• DynamoDB（フィードバックデータ保存）
• Amplify Hosting（フロントエンド配信）

認証は1つの Cognito User Pool に対して、ユーザーログイン用クライアント（Authorization Code Flow）と M2M 認証用 Machine Client（Client Credentials Flow）の2つが同居する構成です。

エージェントパターンは strands-single-agent（Strands Agents）と langgraph-single-agent（LangGraph）の2つが用意されています。

問題1: Docker が使えない環境でのデプロイ

症状

cdk deploy を実行すると、以下のエラーが発生しました。

Error: spawnSync docker ENOENT

原因

FAST のデフォルト設定では、Docker を2箇所で使用しています。

① AgentCore Runtime のコンテナイメージビルド

config.yaml の deployment_type: docker 設定により、AgentRuntimeArtifact.fromAsset() が Dockerfile からコンテナイメージをビルドします。

② Feedback Lambda の Python 依存関係バンドル

元のコードでは @aws-cdk/aws-lambda-python-alpha の PythonFunction を使用しており、これは内部で Docker を使って Python の依存関係をインストールします。

解決策

① deployment_type を zip に変更

infra-cdk/config.yaml を修正します。

backend:
  pattern: strands-single-agent
  deployment_type: zip  # docker → zip に変更

zip モードでは、Docker の代わりに Lambda（Custom Resource）を使ってデプロイパッケージを作成します。CDK の synth 時にエージェントコードを base64 エンコードして CloudFormation テンプレートに埋め込み、zip-packager Lambda が S3 上でパッケージングを行います。

deployment_typeは、dockerとzipのどちらかを選択できる設計となっています。

② Feedback Lambda を標準の lambda.Function に変更

PythonFunction（Docker 必須）を標準の lambda.Function に置き換えます。
なお、このLambda関数はユーザーからのフィードバック（Good/Bad）を受け取り、DynamoDBに保存する機能です。

以下はinfra-csk/lib/backend-stack.tsの修正です。

// 変更前: Docker が必要
import { PythonFunction } from "@aws-cdk/aws-lambda-python-alpha"
const feedbackLambda = new PythonFunction(this, "FeedbackLambda", { ... })

// 変更後: Docker 不要
import * as lambda from "aws-cdk-lib/aws-lambda"
const feedbackLambda = new lambda.Function(this, "FeedbackLambda", {
  runtime: lambda.Runtime.PYTHON_3_13,
  architecture: lambda.Architecture.ARM_64,
  code: lambda.Code.fromAsset(path.join(__dirname, "..", "lambdas", "feedback")),
  handler: "index.handler",
  // ... 他の設定
})

Python の依存関係（pydantic 等）は Powertools Lambda Layer に含まれているため、lambda.Code.fromAsset でソースコードのみをパッケージすれば動作します。

PythonFunctionはDockerを使って依存関係のバンドリングを行います。今回はDocker不要にするため、lambda.Functionとlambda.Code.fromAssetに変更しています。

Powertools Layer が arm64 用の場合、Lambda のアーキテクチャも ARM_64 に合わせる必要があります。不一致だと No module named 'pydantic_core._pydantic_core' エラーが発生します。

問題2: Windows 環境での ZIP パスセパレータ問題

症状

deployment_type: zip に変更してデプロイは成功するものの、AgentCore Runtime で以下のエラーが発生しました。

ModuleNotFoundError: No module named 'gateway'

原因

CDK の readDirRecursive メソッドが path.join() を使ってファイルパスを構築していました。Windows では path.join() がバックスラッシュ（\）を使うため、zip-packager Lambda（Linux）に渡されるファイル名が gateway\utils\gateway_access_token.py のようになり、正しいディレクトリ構造が作られませんでした。

解決策

infra-csk/lib/backend-stack.ts の readDirRecursive メソッドで、POSIX セパレータを明示的に使用するように修正しました。

// 変更前: Windows では backslash になる
const relativePath = path.join(prefix, entry.name)

// 変更後: 常に forward slash を使用
const relativePath = [prefix, entry.name].join("/")

加えて、zip-packager Lambda 側にも防御的なパス正規化を追加しました。

# zip-packager/index.py
for filename, content_b64 in agent_code.items():
    # Windows のバックスラッシュを正規化
    normalized_filename = filename.replace("\\", "/")
    file_path = package_dir / normalized_filename
    file_path.parent.mkdir(parents=True, exist_ok=True)
    file_path.write_bytes(base64.b64decode(content_b64))

問題3: ZIP 更新が AgentCore Runtime に反映されない

症状

パスセパレータの修正後に再デプロイしても、AgentCore Runtime は依然として古い ZIP を使い続け、同じ ModuleNotFoundError が発生しました。

原因

S3 のオブジェクトキーが deployment_package.zip で固定されていたため、CloudFormation から見ると Runtime リソースのプロパティ（bucketName + objectKey）が変わらず、Runtime の更新がトリガーされませんでした。

zip-packager Lambda（Custom Resource）は新しい ZIP を作成・アップロードしていましたが、Runtime リソース自体は更新されないため、古い ZIP のまま動作していました。

解決策

S3 オブジェクトキーにコンテンツハッシュを含めることで、コード変更時に CloudFormation が Runtime リソースの更新を検知できるようにしました。
以下、infra-csk/lib/backend-stack.tsの185-202行目あたりの修正です。

// コンテンツハッシュを生成
const contentHash = this.hashContent(JSON.stringify({ requirements, agentCode }))
const objectKey = `deployment_package_${contentHash}.zip`

// Custom Resource と Runtime の両方で同じ objectKey を使用
zipPackagerResource = new cdk.CustomResource(this, "ZipPackager", {
  serviceToken: provider.serviceToken,
  properties: {
    BucketName: agentCodeBucket.bucketName,
    ObjectKey: objectKey,  // ハッシュ付きキー
    // ...
  },
})

agentRuntimeArtifact = agentcore.AgentRuntimeArtifact.fromS3(
  {
    bucketName: agentCodeBucket.bucketName,
    objectKey: objectKey,  // 同じハッシュ付きキー
  },
  agentcore.AgentCoreRuntime.PYTHON_3_12,
  ["opentelemetry-instrument", "basic_agent.py"]
)

これにより、コードが変わるとハッシュが変わり → objectKey が変わり → Runtime リソースが更新される、という流れが実現されます。

本事象はAgentCore Runtime自体の問題ではなく、CloudFormationの仕組みです。CloudFormationはrソースのプロパティが変わらない限り、そのリソースの更新をスキップします。
Lambda関数も同様で、CDKのlambda.Code.fromAsset()は内部的にアセットのハッシュをS3キーに含めているため、コード変更時に自動的にLambdaが更新されます。

問題4: 東京リージョンでのモデル ID

症状

デプロイ後、エージェントを呼び出すと以下のエラーが発生しました。

ValidationException: The provided model identifier is invalid.
└ Bedrock region: ap-northeast-1
└ Model id: us.anthropic.claude-sonnet-4-5-20250929-v1:0

原因

FAST のデフォルトでは us. プレフィックス付きのクロスリージョン推論プロファイルが使われています。これは US リージョン専用で、ap-northeast-1 からは利用できません。

解決策

AWS ドキュメントを確認し、ap-northeast-1 をソースリージョンとしてサポートする global. プレフィックスの推論プロファイルに変更しました。

patterns\strands-single-agent\basic_agent.pyの88行目あたり、patterns\langgraph-single-agent\langgraph_agent.pyの88行目あたりを修正します。

# 変更前: US リージョン専用
bedrock_model = BedrockModel(
    model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0", temperature=0.1
)

# 変更後: 東京リージョン対応（Global 推論プロファイル）
bedrock_model = BedrockModel(
    model_id="global.anthropic.claude-sonnet-4-5-20250929-v1:0", temperature=0.1
)

ap-northeast-1 で利用可能な主な Claude Global 推論プロファイル:

モデル	推論プロファイル ID
Claude Sonnet 4.5	global.anthropic.claude-sonnet-4-5-20250929-v1:0
Claude Sonnet 4	global.anthropic.claude-sonnet-4-20250514-v1:0
Claude Haiku 4.5	global.anthropic.claude-haiku-4-5-20251001-v1:0
Claude Opus 4.5	global.anthropic.claude-opus-4-5-20251101-v1:0

上記の推論プロファイルは2026年2月現在のものなので、最新の推論プロファイルIDを確認の上、ご利用ください。

問題5: Marketplace 権限の不足

症状

モデル ID を修正した後も、以下のエラーが発生する場合があります。

AccessDeniedException: Model access is denied due to IAM user or service role 
is not authorized to perform the required AWS Marketplace actions 
(aws-marketplace:ViewSubscriptions, aws-marketplace:Subscribe)

原因

現在の Amazon Bedrock では、Anthropic などのサードパーティモデルは AWS Marketplace 経由で提供されています。初回呼び出し時に自動サブスクリプションが行われるため、実行ロールに Marketplace 権限が必要です。

AWS ドキュメントによると:

Marketplace 権限を持つユーザーが一度モデルを呼び出せば、アカウント全体で有効化される。有効化後は Marketplace 権限なしでも呼び出し可能。

とのことです。
なので、既に別プロジェクトで利用しているモデルであれば、特に権限付与は必要なさそうです。

解決策

AgentCore Runtime の実行ロールに Marketplace 権限を追加します。

// infra-cdk/lib/utils/agentcore-role.ts
new iam.PolicyStatement({
  sid: "MarketplaceModelAccess",
  effect: iam.Effect.ALLOW,
  actions: [
    "aws-marketplace:ViewSubscriptions",
    "aws-marketplace:Subscribe",
  ],
  resources: ["*"],
}),

または、Marketplace 権限を持つ IAM ユーザーで CLI から一度モデルを呼び出して有効化する方法もあります。

aws bedrock-runtime converse \
  --model-id "global.anthropic.claude-sonnet-4-5-20250929-v1:0" \
  --messages '[{"role":"user","content":[{"text":"hello"}]}]' \
  --region ap-northeast-1

一度有効化されれば、以降は Marketplace 権限なしでもモデルを利用できます。

Anthropic モデルは初回利用時に FTU（First Time Use）フォームの提出が必要な場合があります。Bedrock コンソールの Model catalog から対象モデルを選択して確認してください。

デプロイ手順

以上の修正を実施したうえで、以下でデプロイしてきましょう。

1. CDK依存関係のインストール

cd infra-cdk
npm install

2. バックエンドデプロイ

対象アカウント・リージョンで初めてCDKを使う場合、ブートラップが必要です。

cdk bootstrap

ブートストラップが終わったらデプロイします。
だいたい5-10分程度かかります。

cd ..
python scripts/deploy-frontend.py

完了するとAmplifyAppId、CognitoUserPoolId、AmplifyUrlなどの出力が表示されます。

4. フロントエンドのデプロイ

プロジェクトルートに戻って実行します。

cdk bootstrap

このスクリプトが自動的に以下を行います：

• CDK スタック出力から aws-exports.json を生成
• npm 依存関係のインストール
• フロントエンドのビルド
• Amplify Hosting へのデプロイ

5. Cognito ユーザーの作成（admin_user_email を設定しなかった場合）

1. AWS コンソールで Cognito を開く
2. FAST-stack-user-pool を選択
3. 「ユーザー」タブ → 「ユーザーを作成」
4. メールアドレスと一時パスワードを入力し、「メールを検証済みにする」にチェック

admin_user_email を設定すればデプロイ時に Cognito ユーザーが自動作成されます。
設定したメールアドレスに一時パスワードが届くので、一時パスワードでログイン後に新しいパスワードを設定します。

まとめ

FAST を Docker なし・東京リージョンでデプロイするために行った修正の一覧です。

問題	修正対象	修正内容
Docker 依存（Runtime）	config.yaml	deployment_type: docker → zip
Docker 依存（Feedback Lambda）	backend-stack.ts	PythonFunction → lambda.Function + ARM_64 アーキテクチャ指定
Windows パスセパレータ	backend-stack.ts	path.join() → [].join("/") で POSIX パス強制
パスセパレータ防御	zip-packager/index.py	filename.replace("\\", "/") 追加
ZIP 更新未反映	backend-stack.ts	S3 オブジェクトキーにコンテンツハッシュを含める
モデル ID	basic_agent.py	us. → global. プレフィックスに変更
Marketplace 権限	agentcore-role.ts	aws-marketplace:Subscribe 等の権限追加

FAST は非常によくできたテンプレートですが、US リージョン + Docker 環境を前提としている部分があります。本記事の修正を適用すれば、Docker が使えない企業環境や東京リージョンでも問題なくデプロイ・運用できます。