0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@d_mukaiyama
in

AWS Builder Centerの無料サンドボックスでStrands Agents × Amazon Bedrock AgentCoreのワークショップを試してみた

0
Last updated at Posted at 2026-08-12

はじめに

こんにちは。
この記事は「2026 Japan AWS Jr. Champions 真夏のQiitaリレー」13日目の記事となります。
過去の投稿（リンク集）はこちらからご覧ください。
https://qiita.com/ys-yoshida/private/6f7c7f85155a993e2c86

概要

2026年7月8日、AWS Builder Centerで「無料サンドボックス環境」が一般提供（GA）されました。個人のAWSアカウントやクレジットカード不要で、対象ワークショップを8時間試せる仕組みです。本記事では、この無料サンドボックスを使って「Building and scaling Agentic AI workflows」ワークショップに取り組み、Strands Agents SDKとAmazon Bedrock AgentCoreを触ってみた記録と、その過程でつまずいた点・学んだ点をまとめます。

目次

きっかけ：AWSの無料サンドボックス環境とは

これまでAWS Builder Centerのワークショップは、基本的に自分自身のAWSアカウントでリソースを作成しながら進める形式でした。しかし2026年7月8日、AWS Builder Centerは対象のワークショップから直接リクエストできる、無料かつ時間制限付きのサンドボックス環境の提供を開始し、個人のAWSアカウントやクレジットカードが不要なハンズオン環境が提供されるようになりました。

サンドボックスの主な特徴は次の通りです。

  • あらかじめプロビジョニングされたAWSアカウント上で、リソースのデプロイやコードの記述、実験を安全に行える
  • アクティベーションから8時間利用可能で、その後は自動的にクリーンアップされる
  • 週に1回リクエスト可能で、毎週日曜日にリセットされる。サンドボックス環境は15分以内に準備が整う
  • 提供開始時点では一部のワークショップが無料AWS環境の対象

■AWS Builder Center ワークショップ
https://builder.aws.com/build/workshops?tab=discover

無料でできるワークショップは生成AI／AIエージェント関連が比較的多く、記事執筆時点(2026年7月時点)では、日本語での説明がなく、英語の説明のみのワークショップが多かったです。ただし、マネジメントコンソールの方は普通に日本語でハンズオンができるので、英語がよほど苦手でない限りは問題なく進められると思います。

本記事では、無償サンドボックスが提供されているワークショップの中から「Building and scaling Agentic AI workflows（エージェンシー AI ワークフローの構築とスケーリング）」を選びました。なお本ワークショップは、記事執筆(2026年7月)時点で英語のみ対象となります。

■Building and scaling Agentic AI workflows
https://catalog.us-east-1.prod.workshops.aws/workshops/eb18d538-bf1f-49b9-9747-c474953deee1/en-US

試したワークショップの全体像

今回試したワークショップは、Strands Agents（オープンソースのエージェント構築SDK）とAmazon Bedrock AgentCoreを組み合わせて、ローカルのツール呼び出しから始まり、外部API連携、モデル/ツール設定、S3を使ったメモリ管理、Bedrock Knowledge Basesを使ったRAG、AgentCore GatewayによるMCP（Model Context Protocol）連携、最終的にAPI Gateway + Amazon Cognitoでの外部公開までを段階的に学ぶ構成でした。

具体的には以下のような流れです。

  1. ローカルツールを持つ基本エージェントの作成とLambdaへのデプロイ
  2. 外部APIとの連携によるツールの拡張
  3. 複数ツール・複数モデルの設定とsystem_promptによる挙動のカスタマイズ
  4. Amazon S3を使った会話メモリの永続化
  5. Amazon Bedrock Knowledge Basesを使ったRAG
  6. AgentCore GatewayでOAuth 2.0認証つきのMCPサーバーに接続
  7. Amazon API Gateway + Amazon Cognitoでのエージェント公開

以降、実際に手を動かして特に印象に残った4つのポイントに絞って振り返ります。

1点目：Strands AgentsでLambda上に最小構成のエージェントを作る

本ワークショップではまず、strands パッケージの Agent クラスと @tool デコレータを使って、ローカルツールを1つ持つだけの旅行アシスタントエージェントを作成し、Lambda関数としてデプロイしました。

以下はWorkshopより引用・抜粋

from strands import Agent, tool
from strands_tools import http_request
from typing import Dict, Any

TRAVEL_AGENT_PROMPT = """You are a travel assistant that can help customers book their travel. 
Think step-by-step. Limit your answers to the user prompt.

Tools available:
- Use the flight_search tool to provide flight carrier choices for their destination.
"""

@tool
def flight_search(city: str) -> dict:
    """Get available flight options to a city."""
    flights = {
        "Atlanta": ["Delta Airlines", "Spirit Airlines"],
        "Seattle": ["Alaska Airlines", "Delta Airlines"],
        "New York": ["United Airlines", "JetBlue"],
    }
    return flights[city]

def handler(event: Dict[str, Any], _context) -> str:
    travel_agent = Agent(
        model="us.amazon.nova-lite-v1:0",
        system_prompt=TRAVEL_AGENT_PROMPT,
        tools=[flight_search, http_request],
    )
    response = travel_agent(event.get("prompt"))
    return str(response)

ポイントは、Lambdaの handler 関数がそのままエージェントの呼び出し口になっていることです。Agent に渡す tools リストには、自作の flight_search に加えて、strands_tools が提供する汎用の http_request ツールも渡せます。これにより、天気予報のような外部REST APIへの問い合わせも、コードをほとんど書かずにエージェントの能力として追加できます。

system_promptの中で「天気予報は明示的に聞かれたときだけ返す」「GETメソッドのみ許可する」「詳細な日次予報は含めず5日分のサマリーのみ」といった振る舞いの制約を自然言語で書き込めるのも、Strands Agentsらしい体験でした。ツールの実装（何ができるか）と挙動の制御（いつ・どう使うか）が、コードとプロンプトにきれいに分離されている印象です。

image.png

この構成から少しずつ、発展させていく流れのワークショップでした。

なお、ワークショップの説明が英語である以上、プロンプトとLambdaをデプロイしてテストした際のエージェントの回答も、当然英語になってしまうのですが、プロンプトの部分に「日本語で答えて」のように入れると日本語で回答してくれるので、気になる方は試してみてください。

2点目：「Amazon Bedrock Knowledge Bases(KB)のIDがコードのどこにも書いてないのに検索できてる」の謎

まず、Lambdaにおける環境変数の使われ方を説明します。Bedrockのモデルにガードレールを設定する際、次のようなコードが使われます。

import os
from strands.models import BedrockModel

# ガードレールの情報を環境変数から読み込む
guardrail_id = os.getenv("GUARDRAIL_ID")
guardrail_version = os.getenv("GUARDRAIL_VERSION", "DRAFT")

model = BedrockModel(
    model_id="us.amazon.nova-lite-v1:0",
    guardrail_id=guardrail_id,
    guardrail_version=guardrail_version,
)

os.getenv("GUARDRAIL_ID")の戻り値がそのままBedrockModelに渡しています。os.getenvで実際に取ってくる値は、Lambdaの「設定」→「環境変数」タブで設定します。キーをGUARDRAIL_ID、バリューを実際のガードレールIDとして設定することで、ガードレールIDのハードコードを避けられます。ハードコードを避けることで、セキュリティの向上や設定変更の容易化といったメリットがあります。上記が典型的なLambda環境変数の使われ方です。

一方、Knowledge BasesをRAGとして使うラボで少し戸惑ったのが、retrieve ツールをインポートしてエージェントに渡すだけで、コード上にKnowledge BasesのIDや認証情報を一切書いていないのに検索が動いてしまうことでした。上と同じ発想で「Lambdaの環境変数にKnowledge Bases IDが設定されているのでは」と考えて確認してみましたが、少なくとも今回のワークショップ環境では、それらしい環境変数は見当たりませんでした。

気になったので、strands_toolsのretrieveツールの実装を GitHubのソースコード から直接確認してみました。KB IDの決定ロジックは次のようになっています。

default_knowledge_base_id = os.getenv("KNOWLEDGE_BASE_ID")
default_aws_region = os.getenv("AWS_REGION", "us-west-2")
...
kb_id = tool_input.get("knowledgeBaseId", default_knowledge_base_id)
region_name = tool_input.get("region", default_aws_region)

GUARDRAIL_IDの例と違い、こちらはtool_input.get("knowledgeBaseId", default_knowledge_base_id)という書き方になっています。つまり、ツール呼び出し時のパラメータとしてknowledgeBaseIdが明示的に渡された場合はそちらが優先され、環境変数KNOWLEDGE_BASE_IDはあくまで「未指定時のフォールバック」でしかありません。

これで、Lambdaの環境変数タブにKNOWLEDGE_BASE_IDが見当たらなかった理由にも納得がいきました。少なくとも「ブラックボックス」ではなく、「呼び出し側が明示的に渡すパラメータ」と「環境変数によるデフォルト値」の二段構えの設計になっていることは、ライブラリのソースコードから確認できました。

認証情報については、Lambda上で実行ロールの認証情報とデフォルトリージョンが自動的に利用される点は変わりません。コード上でAWS認証情報やリージョンを明示しなくてもBedrock APIを呼び出せるのは、Lambdaの実行環境がboto3にそのまま引き継がれるためです。

「エージェントが勝手に賢くなっている」ように見えて、実際にはツールのパラメータ設計とLambdaの実行ロールがうまく役割分担している、というような感じに理解しました。

image.png

3点目：AgentCore GatewayでMCP連携→気づいたらCognitoができていた話

AgentCore GatewayでMCPサーバーに接続するラボでした。手順に沿って進めると、AgentCore Gatewayの画面からAmazon Cognitoのユーザープールが作成されていて、最初は驚きました。他のリソースもコンソールからの作業の導線がいいので適当な理解でも何となくそれっぽいものがつくれてしまうのが、AWSの強みなのかなと感じました。

AgentCore Gatewayは、AIエージェントとツール（Lambda関数や既存のMCPサーバーなど）を仲介する集約ポイントで、Gateway自体へのアクセス（インバウンド）と、Gatewayから先のツールへのアクセス（アウトバウンド）をそれぞれ別に保護する仕組みを持っています。インバウンド側ではMCPの認可仕様に沿ってOAuthベースの認可を行います。GatewayはOAuth Protected Resourceとして振る舞い、認可サーバー（Amazon Cognito等）が発行したアクセストークンを検証します。これはAmazon Cognito、Okta、Auth0など、組織が使っているOAuth IDプロバイダと組み合わせて動作します。

このOAuth設定を毎回手動で行うのは手間なので、AgentCore SDKを使う場合はCognitoを使った認可設定（いわゆるCognito EZ Auth）を自動的に構成でき、手動でのインバウンド認可設定を省略できます。ワークショップのGatewayセットアップ用ヘルパー（GatewayClient など）を呼んだ際に、このEZ Authの仕組みが裏側でCognitoユーザープールとアプリクライアントを作成していた、というのが「勝手にCognitoができていた」ことの正体でした。

またアウトバウンド側、つまりGatewayが実際にLambda関数などのターゲットを呼び出す部分は、通常のIAMポリシーで制御します。ワークショップでは次のようなポリシーが登場しました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": ["bedrock-agentcore:GetGateway"],
      "Resource": ["arn:aws:bedrock-agentcore:us-west-2:<account-id>:gateway/*"],
      "Effect": "Allow"
    },
    {
      "Action": ["lambda:InvokeFunction"],
      "Resource": ["arn:aws:lambda:us-west-2:<account-id>:function:attractions"],
      "Effect": "Allow"
    }
  ]
}

つまり、「Gatewayの中に入るための鍵（インバウンド・OAuth/Cognito）」と「Gatewayが外のリソースを呼び出すための鍵（アウトバウンド・IAM）」という2種類の認可が別レイヤーで動いており、Cognitoが見えていたのはインバウンド側の話だった、と整理すると腑に落ちました。Gatewayは一般提供（GA）以降、OAuthに加えてIAMによる認可もサポートしており、既存のMCPサーバーへの接続も可能になっています。

image.png

4点目：API Gateway + Cognitoでエージェントを外部公開する

最後のラボでは、Lambda上のエージェントをAmazon API Gateway経由でHTTPエンドポイントとして公開し、その手前にAmazon Cognitoを使ったオーソライザーを設定しました。API Gatewayのオーソライザーとして、AgentCore Gatewayとは別にCognitoユーザープールベースの認可を組み込む形です。

やっていること自体は「Cognitoで発行したトークンを持っているリクエストだけAPI Gatewayを通す」という、一般的なサーバーレスAPIの認証パターンと同じでした。3点目のAgentCore Gateway内部のCognito（MCP接続用）と、今回4点目であげたAPI Gatewayオーソライザー用のCognito（HTTP公開用）は別物であり、「用途ごとに認可の対象が異なる」という点を意識すると混乱しにくいです。

学んだこと・気づき

  • Strands Agentsは、ツールの実装（Pythonコード）と挙動の制御（system_prompt）を分離できる点が扱いやすく、Lambdaの handler 関数をそのままエージェントの呼び出し口になるため、既存のサーバーレス構成に組み込みやすい。
  • strands_tools の retrieve のような組み込みツールは、内部で何を参照しているか（環境変数・IAMロール）を意識しなくてもエージェントを作成できる便利な機能。
  • AgentCore Gatewayの認可は「Gatewayに入るためのインバウンド認可（OAuth/Cognito）」と「Gatewayが外部を呼び出すアウトバウンド認可（IAM）」の2層構造になっている。Cognitoが自動生成されるのは、SDKのヘルパーがインバウンド認可設定を肩代わりしてくれているため。
  • 無料サンドボックスは、こうした複数サービスにまたがる構成を、自分のAWSアカウントの請求を気にせず一通り試せる点で学習コストを大きく下げてくれる。8時間・週1回という制約はあるが、今回のような複数ラボ構成のワークショップを一気に通しでやるには十分な時間だった。

終わりに

「無料になったから試してみた」という軽い気持ちで始めたワークショップでしたが、Strands AgentsによるLambda上でのエージェント実装から、Bedrock Knowledge Basesを使ったRAG、AgentCore GatewayのMCP連携とCognitoによる認可、API Gateway経由の公開まで、AIエージェントを実運用に近い形で構築する際に押さえておくべき要素を一通り体験できました。特にAgentCore Gatewayの認可まわりは最初戸惑いましたが、インバウンドとアウトバウンドで役割が違うと個人的には整理しました。無料サンドボックスが対象とするワークショップは生成AI・エージェント関連が多いので、同じように試してみたい方は一度AWS Builder Centerのワークショップ一覧を確認してみることをおすすめします。ワークショップをやるときにはまとまった時間を確保してから取り組んでください。所要時間が3時間と記載されているワークショップは、実際にその程度の時間を要する印象でした。私のように「2時間くらいで終わるだろう」と見積もらず、余裕を持って時間を確保してから取り組むことをおすすめします。

参考文献・参考サイト

※本記事は無料サンドボックス環境内でのワークショップ実施をもとにしています。ご自身のAWSアカウントで同様の構成を試す場合は、Lambda・Bedrock・API Gateway・Cognito等の各サービスに通常の料金が発生する点にご注意ください。
※本記事のコード一部は 「Building and scaling Agentic AI workflows」AWS Workshop Studio, https://catalog.workshops.aws/workshops/eb18d538-bf1f-49b9-9747-c474953deee1/en-US を参考に引用しています。
※本記事の構成図は作者自身が作成したものであり、具体的なアーキテクチャは公式ドキュメントをご参照ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?