概要

アーキテクチャとプロンプトについては解説しました。ここからは、通常は置き去りにされがちな部分です。つまり、実際に何が壊れたのか、どこをより良くできるのか、そしてこの仕組みを自分のAWSアカウントにどうデプロイするのか、です。

これまで、サーバーレス構成と5層のコスト抑制ガードレール、そしてシステムプロンプトのパターンと、6つすべてのツールの裏にあるプロンプトエンジニアリングを見てきました。最後のこのパートは実務面です。開発でつまずいたポイント（落とし穴）と、リポジトリをフォークして自分で動かせるようにするための手順を順を追って説明します。

壊れた点

Bedrockモデルへのアクセス

最初のデプロイはうまくいきました。Lambda関数が作成され、API Gatewayが稼働し、DynamoDBもプロビジョニングされました。ところが最初のエンドポイントを呼ぶと、Bedrockからアクセス拒否が返ってきました。有益なエラーメッセージはなく、ただの一般的な拒否でした。

原因はこれです。Claude Sonnet & Haikuで最初にデプロイしたときは、モデルを呼び出す前にモデルアクセスを手動で有効化する必要がありました。これは一度きりの手順です。最初はIAMポリシーの問題だと思い、間違ったところをデバッグして時間を使ってしまいました。しかしAmazon Novaでは、デフォルトで有効化されているため、これは当てはまりません。

注: 2025年後半の時点では、Bedrockのファウンデーションモデルは手動での有効化なしでデフォルト利用可能です（Anthropicのものも含む）

ただし、Anthropicモデルには1つだけ独自の要件があります。最初のClaude呼び出しの前に、一度きりのFirst Time Use（FTU）フォームを提出する必要があります。これは、Amazon Bedrockコンソールでモデルカタログから任意のAnthropicモデルを選択することで完了できますし、またはPutUseCaseForModelAccess APIを呼び出しても完了します。アカウントまたは組織レベルで一度提出すれば、同じAWS Organization内のすべてのアカウントに引き継がれます。

加えて、IAMロールに必要なAWS Marketplace権限（aws-marketplace:Subscribe、aws-marketplace:Unsubscribe、aws-marketplace:ViewSubscriptions）があること、およびAWSアカウントで有効な支払い方法が設定されていることを確認してください。Bedrockは最初の呼び出し時にバックグラウンドでモデルを自動サブスクライブし、この権限がその成功に必要です。

エラー応答におけるCORS

Lambda関数はcurlとスモークテスト経由では正しい結果を返していました。しかしフロントエンド側では「Failed to fetch」というエラーが出ました。

問題はこれです。レスポンスヘルパーは成功応答にはCORSヘッダーを設定していましたが、エラー応答には設定していませんでした。Lambdaが400または429を返したとき、ブラウザはレスポンス全体をブロックしました。

修正方法 — あらゆるレスポンスパスにCORSヘッダーを含めることです:

CORS_HEADERS = {
    "Access-Control-Allow-Origin": "*",
    "Access-Control-Allow-Headers": "Content-Type",
    "Content-Type": "application/json",
}

def ok(data):
    return {"statusCode": 200, "headers": CORS_HEADERS, "body": json.dumps(data)}

def error(status, message, code):
    return {"statusCode": status, "headers": CORS_HEADERS,
            "body": json.dumps({"error": message, "code": code})}

Lambdaのレスポンスヘッダーではオリジンに*を使っています。レスポンスヘルパーがCloudFrontのドメインを知らないためです。実際のオリジン制限はAPI Gatewayの層で行われ、allowedOriginsはCloudFrontドメインのみにスコープされています。APIが認証トークンではなく、レート制限と日次の上限で保護する仕組みになっているため、Lambdaレベルの*はここでは問題ありません。

私が何度も学び直している教訓はこれです。curlだけでなく、必ず実際のフロントエンドからエラーパスをテストすること。curlはCORSを気にしません。

DynamoDBのシード手順

最初のデプロイの後、python scripts/seed_dynamodb.pyを実行してtools_enabled: trueという設定行を書き込む必要があります。これがないと、予算の遮断Lambda（パート1のレイヤー5）には書き込む行が存在しません。安全網が接続されていない状態になります。

"""最初のデプロイの直後に一度だけ実行します。"""
import boto3

返却形式: {"translated": "翻訳されたHTML"}dynamodb = boto3.resource("dynamodb", region_name="ap-southeast-1")
table = dynamodb.Table("dr-toolkit-usage")

table.put_item(Item={
    "pk": "config",
    "sk": "global",
    "tools_enabled": True,
    "disabled_reason": None,
})
print("Config seeded — tools_enabled: True")

これは、おそらくCloudFormationのカスタムリソースで処理できますが、この規模のプロジェクトであれば、デプロイ後に1行スクリプトを実行するほうが簡単です。

改善できる点

ストリーミングレスポンス。 現状ではユーザーが全レスポンスを受け取るまでに2〜5秒待ちます。Bedrockは invoke_model_with_response_stream に対応しており、出力を単語ごとに表示できるはずです。利用可能な中で最も大きいUX改善です。

より良い可観測性。 ツールキットにはCloudWatchログはありますが、構造化されたメトリクスはありません。ツールごとの呼び出し回数、エラー率、トークン使用量を表示するダッシュボードは、ぜひ追加したいところです。

入力バリデーション。 Lambdasは、フロントエンドから送られてきたものをスキーマ検証なしで受け取ります。素早い修正で、予期しないエラーの一群を取り除けます。

自分でデプロイする

このツールキットを自分のAWSアカウントで動かす方法を説明します。

前提条件

• AWS CLI を設定済み（aws sts get-caller-identity が動けばOK）
• Node.js ≥ 24（Serverless Framework と Next.js 用）
• Python 3.14（別のバージョンを使う場合は serverless.yml の runtime を更新してください）
• Bedrockモデルアクセス を有効化（使用したいモデルに対して）:
  • 現在のデフォルト: amazon.nova-pro-v1:0 と amazon.nova-lite-v1:0
  • Claude、Nova Premier、または Bedrock Model Catalog 内の任意のモデルでも動作します
  • デプロイで使う正確なモデルIDは models.config.json を確認してください

デプロイ手順

# 1. リポジトリをクローンする
git clone https://github.com/romarcablao/dr-toolkit-on-aws.git
cd dr-toolkit-on-aws

# 2. `models.config.json` を更新し、すべてをデプロイ（バックエンド + フロントエンド + スロットル + キャッシュ無効化）
./scripts/deploy.sh

# 3. DynamoDB をシード（最初のデプロイのみ）
python scripts/seed_dynamodb.py

# 4. 6つのエンドポイントをスモークテストする
python scripts/test_tools.py <API_URL>

デプロイスクリプトが行うこと: npx serverless deploy、API Gateway のスロットル設定、models.config.json からフロントエンド設定を生成、Next.jsの静的エクスポートをビルド、S3 へ同期、CloudFront のキャッシュを無効化。

部分デプロイもサポートされています:

./scripts/deploy.sh --skip-backend    # フロントエンドのみ
./scripts/deploy.sh --skip-frontend   # バックエンドのみ

デプロイ後

serverless.yml の CORS を、CloudFront のドメインで更新します:

httpApi:
  cors:
    allowedOrigins:
      - 'https://your-cloudfront-domain.cloudfront.net'

予算アラートを設定します: AWSコンソール → Billing → Budgets → Create budget → $10/月 → dr-toolkit-budget-alert を指す SNS アクション（100%で）

緊急時の制御

# すべてのツールを即時に無効化
aws dynamodb put-item \
  --table-name dr-toolkit-usage \
  --region ap-southeast-1 \
  --item '{"pk":{"S":"config"},"sk":{"S":"global"},"tools_enabled":{"BOOL":false}}'

# 再有効化
aws dynamodb put-item \
  --table-name dr-toolkit-usage \
  --region ap-southeast-1 \
  --item '{"pk":{"S":"config"},"sk":{"S":"global"},"tools_enabled":{"BOOL":true}}'

自分のツールを追加する

1. Lambdaハンドラ — functions/ 内の任意のハンドラをコピーし、TOOL_NAME とシステムプロンプトを変更する
2. 設定（Config） — ツールを models.config.json に追加する
3. ルート — serverless.yml に httpApi イベントを持つ関数ブロックを追加する
4. フロントエンド — useToolSubmit フックを使って frontend/src/app/tools/your-tool/page.tsx 配下にページを作成する
5. ホームページ — ツール配列にカードを追加する
6. デプロイ: ./scripts/deploy.sh

次は？あなたの番です

アーキテクチャはパート1にあります。プロンプトはパート2にあります。デプロイ手順は上記の通りです。さあ挑戦です:

このツールキットを自分のAWSアカウントにデプロイしてください。

リポジトリをフォークして ./scripts/deploy.sh を実行し、動かしてみてください。予算の設定も忘れないでください。約10分で完了し、ガードレールによって月あたり$10未満に抑えられます。

動き始めたら、次を試してみましょう:

• あなた自身のCloudFormationテンプレートの1つをDR Reviewerに貼り付ける。どんなギャップを検出するか確認してください。
• 実際のインフラパラメータでDR Strategy Advisorを実行する。今日すでに整備されている内容と、推奨内容を比較してください。
返却形式: {"translated": "翻訳されたHTML"}
• 実際のインシデントノートをポストモーテム・ライターに投げてみてください。構造化された出力が、あなたが本当に使いたいものかどうか確認します。

さらに進めたい場合：

Kiroで7つ目のツールを追加する。 これは、最初の6つがどのように作られたかです。Kiroでプロジェクトを開き、（「AWSの設定を取り込み、ポリシー違反をフラグするコンプライアンスチェッカー」のように）作りたいツールを自然言語で説明し、コードを書く前にKiroに要件と実装計画を含む仕様（spec）を生成させます。Kiroは仕様駆動のワークフローなので、自由形式のプロンプトではなく、構造化された計画からハンドラー、システムプロンプト、コンフィグのエントリのひな形が用意されます。セキュリティ監査、コスト最適化、コンプライアンスチェック——同じアーキテクチャで、プロンプトが異なるだけです。第2部の「ハンドラー」パターンのおかげで、コード側はほぼコピペで済みます。面白いのは仕様を書くことと、システムプロンプトを調整することです。

ここにあるものを改善する。 ストリーミング応答、入力バリデーション、CloudWatchのダッシュボード。

まとめ

この連載では、AWS上でのサーバーレスAIプロジェクトのライフサイクル全体を扱いました。アーキテクチャ設計（第1部）、プロンプトエンジニアリング（第2部）、そして現場での学びとデプロイ（第3部）です。

ツールキットが推奨するDR戦略——バックアップ＆リストア、パイロットライト、ウォームスタンバイ、マルチサイトのアクティブ/アクティブ——は、そのままAWSディザスタリカバリ（DR）ワークロードに関するホワイトペーパーから来ています。このホワイトペーパーは素晴らしいのですが、4つの戦略を理解することと、自社のインフラに対する実際のランブックを持つことの間にはギャップがあります。これらのツールは、そのギャップを埋めようとしています。

試す / フォークする：

ライブデモ： https://dr-toolkit.thecloudspark.com

DR Toolkit

AWSの構築者向けの、AIによる災害復旧（DR）計画ツール。Amazon BedrockでDRの態勢を計画し、文書化し、監査します。生成AIにより加速されたレジリエンス計画。

dr-toolkit.thecloudspark.com

ソースコード： github.com/romarcablao/dr-toolkit-on-aws

dr-toolkit/
├── serverless.yml             # Serverless Framework

参考:

• AWS 上でのワークロードのディザスタ リカバリ — AWS ホワイトペーパー
• Amazon Bedrock デベロッパーガイド
• Amazon Bedrock モデルカタログ
• Amazon Bedrock クロスリージョン推論
• Amazon Bedrock — Anthropic Claude パラメータ
• CloudFront の Origin Access Control