はじめに
こんにちは！ yu_Matsuです
来週からいよいよ AWS re:Invent 2025 が開幕します！
今年はありがたいことに現地参加できる予定なのですが、現場でいろいろ情報収集する上で、今年の生成AIサービス周りでかなり大きなアップデートだった Amazon Bedrock AgentCore に関して改めておさらいしてみたいと思ったので、どうせなら記事にしてみようと筆を取りました。
re:Inventを迎えるにあたり、何かしらの復習に役立てていただけますと幸いです。
Amazon Bedrock AgentCore
概要
Amazon Bedrock AgentCore (以降AgentCore) は、AIエージェントを安全かつ大規模に展開、運用するために最適な、フルマネージドのエージェントプラットフォームサービスです。今年の7月にプレビュー版が公開され、10月にGAされました！
従来のBedrock Agentsと何が違うの？と思う方もいらっしゃるかと思いますので、簡単に違いをまとめますと以下になります。
-
Bedrock Agents：
コンソール上からポチポチでエージェントを作成できる反面、フレームワーク（LangGraphやMastraなど）やLLMを柔軟に選択できない。簡単にエージェントを作ってみたい場合に向いている -
AgentCore：
自分たちが実装したエージェントを「AWS上で展開、運用」できる。あらゆるフレームワークやLLMを利用可能だが、エージェントの実装力がある程度求められる。より高度なエージェントを実装したい場合や本番運用したい場合に向いている
AgentCoreには下画像に示すような機能が存在し、それぞれAIエージェントを開発、運用する上でかなり便利なものになっています。
今回はこの中で Runtime、Identity、Gateway についておさらいしてみたいと思います。
Runtime
AIエージェントのホスティング機能であり、AgentCoreの中核となる機能です。前述の通り、自分で実装したAIエージェントをホスティングするのですが、その際にあらゆるフレームワーク (Strands Agents、LangGraph、LlamaIndex、Google ADK、OpenAI Agents SDKなど) 、あらゆるLLMを柔軟に選択可能となっています。
最大8時間のワークロードがサポートされているため、複雑な推論も問題なく実行できますし、もちろん テキスト・画像・音声・動画などのマルチモーダルにも対応しています。
Runtimeのホスティングの方法としては２パターンありまして、一つは下画像のようにコンテナベースになります。エージェントのコードとDockerFileを元にCodeBuild上でイメージをビルド → ECRにプッシュするイメージです。もちろんこの流れは全てAgentCoreが実行してくれます。
もう一つは、今月頭に追加された新機能である Direct Code Deploy になります。現在はこちらが推奨となっていまして、コードのzipファイルやAWSから提供されるtemplate(サンプルコードのようなもの)をS3にアップロードすることによって、コンテナを介さなくてもRuntimeにデプロイできるようになりました。
また、Runtimeでは、エージェントを MCPサーバー や A2Aサーバー としてデプロイすることも可能です。A2Aに関しては公式からサンプルが提供されているため、気になる方は試してみて下さい。
AgentCore Runtimeへのデプロイは、コンソールからだけでなくAgentCore CLIを利用してローカル環境から実施することも可能です。（本記事ではCLIを利用しています）
Identity
AgentCore Identityは、AIエージェントのための認証・認可インフラを提供する機能になります。エージェントやツール、後述するGatewayが、「誰が」、「何にアクセスできるか」を管理するため、下画像のように Inbound Auth と Outbound Auth の２方向の認証が提供されています。
-
Inbound Auth：
「誰がエージェントやツール、Gatewayを呼び出せるか」の認証になります。Inbound Authには、AWS標準の認証であるIAM認証のほか、OAuth 2.0対応IdPの JSON ウェブトークン (Okta, Microsoft Entra IDなど)を使用することが出来ます。 -
Outbound Auth：
「エージェントやツール、Gatewayが何にアクセスできるか」の認証になります。API Key と OAuth クライアント を選択することができ、OAuth クライアントとしては Google, Microsoft, Slack, GitHub, Oktaなどがデフォルトのプロバイダーとしてサポートされています。（サポート外のプロバイダーもカスタムで設定可能） Cognitoを利用したM2M認証（ユーザーが介入しない認証）と、ユーザーによって認証を分ける USER_FEDERATION認証（3LO） が設定可能です。
また、認証のユーザーのトークンは、Token Vault と呼ばれる機能で安全に管理されており、エージェント、Gatewayが必要な時だけ取り出して利用します。Token Vault は Secrets Manger と統合されているため、後から確認することも可能です。
Gateway
AgentCore Gatewayは、既存のAPI（もちろん外部サービスも）やLambdaなどを、エージェントが利用するMCPサーバーに変換する機能になります。MCPサーバーを自分で実装する必要がなく、OpenAPI定義やLambda関数などがあれば、MCP互換ツールとして簡単に利用できるようになります。
変換する対象は ターゲット と呼ばれ、以下が対象になります
-
REST API：
既存のAPI。APIの定義（OpenAPIスキーマ or Smithy schema）を用意するだけで、それらを元にMCPサーバーに変換してくれます。Outbound認証として、Smithy schemaの場合はIAM認証、OpenAPIスキーマの場合は Identityで触れた API Key と OAuthクライアント を選択できます。 -
Integration：
デフォルトのプロバイダー（Microsoft, Slack, Confluenceなど）に関しては、ツールテンプレートが用意されているので、REST APIのようにAPI定義を用意する必要はありません。（Identityと違ってGoogleはデフォルトのプロバイダーにないので注意！）こちらもOutbound認証としてAPI Key と OAuthクライアント を選択できます。 -
Lambda：
Lambdaを直接MCP化できます。Outbound認証はIAM認証を選択することになります。 -
MCPサーバー：
既存のMCPサーバーを統合することもできます。公開されているMCPサーバー等の認証が必要なものはOutbound認証としてOAuthクライアントが選択できます。特に認証が必要ないMCPサーバーの場合は「認証なし」にもできます。
これらのターゲットは複数設定することもでき、Gateway側で1つのエンドポイントに統合してくれますし、認証も自動で注入してくれるので、エージェントから利用する際に煩雑になることもありません。
試してみる
説明ばかりでは理解が進まないので、簡単なAIエージェントをAgentCodeで構築してみました。お題としては、Gateway、Identityも触れられるように、GitHubの自分のリポジトリのIssueを操作できるエージェントになります。
1. GitHub で Personal Access Token (以下PAT) を取得する
まずは、AIエージェントがGitHubを操作する際に必要な認証情報であるPATを取得します。
GitHubアカウントの「Developer Setting」から「Personal access tokens」の「Fine-grained personal access tokens」を開いて、右上の「Generate new token」を押下します。
すると以下の画面が開くので、適当なトークン名を入力します。
「Repository access」に関しては、今回の操作対象のリポジトリを１つ選択します。
「Permissions」として、今回はIssuesのRead/Write許可を設定します。（他にも機能を持たせたい場合はPermissionsを追加する必要があります。）
「Generate token」を押下するとPATが生成されますので、手元に控えておきます。
2. AgentCore Identity で GitHub への Outbound Auth 認証を作成
後ほど作成する AgentCore Gateway が GitHub を操作するための Outbound Auth 認証を作成します。
まず画面上部の検索バーにて「Amazon Bedrock AgentCore」を検索し、コンソールを開きます。すると、左メニューに「アイデンティティ」がありますのでそちらをさらに開きます。
Identityのコンソールでは説明パートで載せた画像のようなイメージ図とともに仕組みの説明があり、その下に「アウトバウンド認証」の項目があります。アウトバウンド認証の「OAuthクライアント/APIキーを追加」を押下すると種類を問われるので、今回は「APIキーを追加」を選択します。
すると、APIキーを入力するモーダルが出ますので、キーの名前とAPIキーを入力します。APIキーは先ほど取得したPATになります。
「追加」ボタンを押下すると、APIキータイプのOutboud Auth認証が作成されます。
設定したAPIキーは Secrets Manager に登録され、いつでも確認できますが、値を Secrets Manager からは変更できないことに注意してください。
3. AgentCore Gateway で Gateway の作成
次に、Gateway を作成します。
AgentCoreのコンソールの左メニューから今度は「ゲートウェイ」を開きます。
ページ中断にゲートウェイ一覧があるので、「ゲートウェイを作成」を押下します。
ゲートウェイ作成画面が開くので、必要な情報を入力していきます。
ゲートウェイ名は適当なもので良いですが、「インバウンド認証設定」は「JSON Web Tokens(JWT)を使用」を選択、JWTスキーマには「Cognitoを利用した設定のクイック作成」を選択します。これにより、Gatewayの Inbound Auth認証 のプロバイダーとして利用するCognitoが自動的に作成されます。
その下の「IAM許可」は「新しいサービスロールを作成して使用」を選択します。
次に、Gateway のターゲットを作成します。
「ターゲットタイプ」には今回は「REST API」を選択します。（GitHubはツールテンプレートが用意されていないため、「統合」は選択できません）
「REST APIタイプ」には「OpenAPIスキーマ」を選択し、OpenAPIスキーマはS3に格納したものを見に行くように設定します。
※事前にスキーマ格納用の適当なS3バケットを作成して、以下のようなOpenAPIスキーマを格納しておきます。
----------------------------------------
OpenAPIスキーマ
------------------------------------------
{
"openapi": "3.0.0",
"info": {
"title": "GitHub Issues API for AgentCore",
"version": "1.0.0"
},
"servers": [{ "url": "https://api.github.com" }],
"paths": {
"/search/issues": {
"get": {
"operationId": "searchIssues",
"summary": "Issues を検索",
"parameters": [
{
"name": "q",
"in": "query",
"required": true,
"schema": { "type": "string" }
},
{
"name": "sort",
"in": "query",
"schema": {
"type": "string",
"enum": ["created", "updated"],
"default": "created"
}
},
{
"name": "order",
"in": "query",
"schema": {
"type": "string",
"enum": ["asc", "desc"],
"default": "desc"
}
},
{
"name": "per_page",
"in": "query",
"schema": { "type": "integer", "default": 10 }
}
],
"responses": { "200": { "description": "検索結果" } },
"security": [{ "bearerAuth": [] }]
}
},
"/repos/{owner}/{repo}/issues": {
"get": {
"operationId": "listIssues",
"summary": "Issues 一覧",
"parameters": [
{
"name": "owner",
"in": "path",
"required": true,
"schema": { "type": "string" }
},
{
"name": "repo",
"in": "path",
"required": true,
"schema": { "type": "string" }
},
{
"name": "state",
"in": "query",
"schema": {
"type": "string",
"enum": ["open", "closed", "all"],
"default": "open"
}
}
],
"responses": { "200": { "description": "一覧" } },
"security": [{ "bearerAuth": [] }]
},
"post": {
"operationId": "createIssue",
"summary": "Issue 作成",
"parameters": [
{
"name": "owner",
"in": "path",
"required": true,
"schema": { "type": "string" }
},
{
"name": "repo",
"in": "path",
"required": true,
"schema": { "type": "string" }
}
],
"requestBody": {
"required": true,
"content": {
"application/json": {
"schema": {
"type": "object",
"required": ["title"],
"properties": {
"title": { "type": "string" },
"body": { "type": "string" },
"labels": { "type": "array", "items": { "type": "string" } },
"assignees": {
"type": "array",
"items": { "type": "string" }
}
}
}
}
}
},
"responses": { "201": { "description": "作成完了" } },
"security": [{ "bearerAuth": [] }]
}
},
"/repos/{owner}/{repo}/issues/{issue_number}": {
"get": {
"operationId": "getIssue",
"summary": "Issue 詳細",
"parameters": [
{
"name": "owner",
"in": "path",
"required": true,
"schema": { "type": "string" }
},
{
"name": "repo",
"in": "path",
"required": true,
"schema": { "type": "string" }
},
{
"name": "issue_number",
"in": "path",
"required": true,
"schema": { "type": "integer" }
}
],
"responses": { "200": { "description": "詳細" } },
"security": [{ "bearerAuth": [] }]
},
"patch": {
"operationId": "updateIssue",
"summary": "Issue 更新",
"parameters": [
{
"name": "owner",
"in": "path",
"required": true,
"schema": { "type": "string" }
},
{
"name": "repo",
"in": "path",
"required": true,
"schema": { "type": "string" }
},
{
"name": "issue_number",
"in": "path",
"required": true,
"schema": { "type": "integer" }
}
],
"requestBody": {
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"title": { "type": "string" },
"body": { "type": "string" },
"state": { "type": "string", "enum": ["open", "closed"] }
}
}
}
}
},
"responses": { "200": { "description": "更新完了" } },
"security": [{ "bearerAuth": [] }]
}
},
"/repos/{owner}/{repo}/issues/{issue_number}/comments": {
"post": {
"operationId": "addComment",
"summary": "コメント追加",
"parameters": [
{
"name": "owner",
"in": "path",
"required": true,
"schema": { "type": "string" }
},
{
"name": "repo",
"in": "path",
"required": true,
"schema": { "type": "string" }
},
{
"name": "issue_number",
"in": "path",
"required": true,
"schema": { "type": "integer" }
}
],
"requestBody": {
"required": true,
"content": {
"application/json": {
"schema": {
"type": "object",
"required": ["body"],
"properties": { "body": { "type": "string" } }
}
}
}
},
"responses": { "201": { "description": "コメント作成" } },
"security": [{ "bearerAuth": [] }]
}
},
"/issues": {
"get": {
"operationId": "listUserIssues",
"summary": "自分の Issues",
"parameters": [
{
"name": "filter",
"in": "query",
"schema": {
"type": "string",
"enum": ["assigned", "created", "mentioned"],
"default": "assigned"
}
},
{
"name": "state",
"in": "query",
"schema": {
"type": "string",
"enum": ["open", "closed", "all"],
"default": "open"
}
}
],
"responses": { "200": { "description": "一覧" } },
"security": [{ "bearerAuth": [] }]
}
}
},
"components": {
"securitySchemes": {
"bearerAuth": { "type": "http", "scheme": "bearer" }
}
}
}
次に、「アウトバウンド認証設定」を行います。
タイプとして「APIキー」を選択し、先ほどIdentityで作成したAPIキーを選択します。
ここまでできたら、「ゲートウェイを作成」を押下して作成完了です。
作成されたゲートウェイの詳細を確認し、「ゲートウェイリソースURL」を控えておきます。（後で利用します）
また、「インバウンドID」の項目を見ると、Cognitoが自動で作成され、設定されていることがわかります。ここでは「検出URL」を控えておきます。
作成されたCognitoも見てみます。
ユーザープールとアプリケーションクライアントが作成されていることがわかります。
ここで、アプリケーションクライアントの「クライアントID」と「クライアントシークレット」、「ログインページ」タグから「カスタムスコープ」を確認し、こちらも控えておきます。
4. AgentCore Identity で Resource Credential Provider の作成
次に、AIエージェントが他のリソースや外部サービス、Gatewayを利用する際の認証周りを管理、設定してくれる Resource Credential Provider を作成します。
AgentCore Identityを開き、今度は「OAuthクライアントを追加」します。
プロバイダーは、今回は「カスタムプロバイダー」を選択します。
「プロバイダーの設定」では、設定タイプを「検出URL」にし、先ほどCognitoで確認した「クライアントID」、「クライアントシークレット」、Gateway作成後に控えた「検出URL」を入力し、「OAuthクライアントを追加」することで、Resource Credential Providerの作成が完了です。
今回はプロバイダーにCognitoを利用しており、アプリケーションクライアントを通して M2M(Machine to Machine)認証 を行うパターンになっています。M2M認証とは、人間のユーザーを介さずにアプリケーションやサービス同士が直接通信する際の認証方式です。
作成された Resource Credential Provider は、アウトバウンド認証一覧から確認できるので、名前を控えておきます。
5. AIエージェントの実装とデプロイ
ここまでで AgentCore Identity と Gateway の作成が一通り完了しましたので、いよいよAIエージェントの実装とそのデプロイになります。
記事スペースの都合もあり、３分クッキングではないですが、実装したエージェントのコードが以下になります。
----------------------------------------
AIエージェントのコード
------------------------------------------
import os
from typing import Dict, Any
from bedrock_agentcore.runtime import BedrockAgentCoreApp
from bedrock_agentcore.identity.auth import requires_access_token
from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp.mcp_client import MCPClient
from mcp.client.streamable_http import streamablehttp_client
app = BedrockAgentCoreApp()
async def get_access_token(cognito_scope: str) -> str:
@requires_access_token(
provider_name="xxxxxx", # 4.で作成したOAuthクライアント名
scopes="github-assistant-gateway/genesis-gateway:invoke", # 3. で控えたアプリケーションクライアントのスコープ
auth_flow="M2M",
force_authentication=False,
)
async def _get_token(*, access_token: str) -> str:
return access_token
token = await _get_token()
return token
def get_full_tools_list(client):
more_tools = True
tools = []
pagination_token = None
while more_tools:
tmp_tools = client.list_tools_sync(pagination_token=pagination_token)
tools.extend(tmp_tools)
if tmp_tools.pagination_token is None:
more_tools = False
else:
more_tools = True
pagination_token = tmp_tools.pagination_token
return tools
async def access_github(payload: Dict[str, Any], gateway_url: str, cognito_scope: str) -> Dict[str, Any]:
try:
access_token = await get_access_token(cognito_scope)
def create_streamable_http_transport():
transport = streamablehttp_client(
gateway_url,
headers={"Authorization": f"Bearer {access_token}"}
)
return transport
mcp_client = MCPClient(create_streamable_http_transport)
with mcp_client:
tools = get_full_tools_list(mcp_client)
agent = Agent(
name="github_assistant_agent",
model=BedrockModel(model_id="us.anthropic.claude-haiku-4-5-20251001-v1:0"),
system_prompt="""
あなたはGitHub Issues管理アシスタントです。
【あなたができること】
- GitHub Issues操作
- Issueの一覧取得・検索・フィルタリング
- Issueの作成（タイトル、本文、ラベル、アサイニー設定）
- Issueの更新（状態変更、コメント追加、ラベル編集）
- Issueの詳細情報取得
- コメントの投稿と管理
【ツール選択の方針】
- ユーザーがGitHub Issuesに関する意図を述べたら適切なツールを使う
- 例：「Issueを作成」「一覧を取得」「コメントを追加」など
- 複合依頼（例：「検索して一覧を表示」）は適切な順序で実行する
【GitHub Issues ツール利用ルール】
- 利用可能なツール名は tool_config の一覧（tools/list）に従う
- 代表例: `issues___list`, `issues___get`, `issues___create`, `issues___update`, `issues___create_comment` など
- `issues___list`:
- パラメータ: `owner`, `repo`, `state`（open/closed/all）, `labels`, `sort`, `direction`
- ページング: `page` と `per_page` パラメータでページングをサポート
- `issues___create`:
- 必須: `owner`, `repo`, `title`
- オプション: `body`, `labels`, `assignees`
- `issues___update`:
- 必須: `owner`, `repo`, `issue_number`
- オプション: `state`, `title`, `body`, `labels`, `assignees`
- `issues___create_comment`:
- 必須: `owner`, `repo`, `issue_number`, `body`
【応答ルール】
- Issue情報を提示する際は、以下を明確に表示：
- Issue番号、タイトル、状態（Open/Closed）
- 作成者、作成日時
- ラベル（ある場合）
- 本文の要約（長い場合）
- 操作結果は明確に報告（成功/失敗、変更内容）
- エラーが発生した場合は、分かりやすく原因と対処法を説明
ユーザーの意図を正しく読み取り、適切なツールを選択し、明確で実用的な結果を返してください。
""",
tools=tools,
)
user_message = payload.get("prompt", "")
response = agent(user_message)
return response
except Exception as e:
error_msg = f"エージェント実行エラー: {str(e)}"
return {
"error": error_msg,
"details": "エージェントの実行中にエラーが発生しました。"
}
@app.entrypoint
async def github_agent(payload: Dict[str, Any]):
gateway_url = os.environ.get("GATEWAY_URL")
if not gateway_url:
raise ValueError("環境変数 GATEWAY_URL が設定されていません")
try:
response = await access_github(payload, gateway_url, cognito_scope)
return response
except Exception as e:
error_msg = f"エントリーポイントでエラー発生: {str(e)}"
return {
"error": error_msg,
"details": "エージェントの起動に失敗しました。環境変数を確認してください。"
}
if __name__ == "__main__":
app.run()
要点をかいつまんで簡単に説明しますと、まず get_access_token 関数で、エージェントが Gateway にアクセスするための認証トークンを取得しています。この際、AgentCoreのライブラリから提供されている requires_access_tokenデコレータを利用しています。このデコレータが、内部で自動的にM2M認証でOAuthプロバイダーと通信し、認証トークンを取得してくれるため、ユーザーは複雑な処理を書く必要がありません。
async def get_access_token(cognito_scope: str) -> str:
@requires_access_token(
provider_name="xxxxxx", # 4.で作成したOAuthクライアント名
scopes="github-assistant-gateway/genesis-gateway:invoke", # 3. で控えたアプリケーションクライアントのスコープ
auth_flow="M2M",
force_authentication=False,
)
async def _get_token(*, access_token: str) -> str:
return access_token
token = await _get_token()
return token
メイン部分である access_github関数では、get_access_token関数を呼び出し、認証トークンを取得したのちに、実行時の環境変数として渡される GatewayのURL と認証トークンを元に streamablehttp_client、MCPClient を用いてGatewayにより変換されたGitHub APIのツール群との通信を確立しています。
async def access_github(payload: Dict[str, Any], gateway_url: str, cognito_scope: str) -> Dict[str, Any]:
try:
access_token = await get_access_token(cognito_scope)
def create_streamable_http_transport():
transport = streamablehttp_client(
gateway_url,
headers={"Authorization": f"Bearer {access_token}"}
)
return transport
mcp_client = MCPClient(create_streamable_http_transport)
...
そして、get_full_tools_list関数により、ツール一覧を取得し、Agentを定義、実行しています。
def get_full_tools_list(client):
more_tools = True
tools = []
pagination_token = None
while more_tools:
tmp_tools = client.list_tools_sync(pagination_token=pagination_token)
tools.extend(tmp_tools)
if tmp_tools.pagination_token is None:
more_tools = False
else:
more_tools = True
pagination_token = tmp_tools.pagination_token
return tools
async def access_github(payload: Dict[str, Any], gateway_url: str, cognito_scope: str) -> Dict[str, Any]:
...
with mcp_client:
tools = get_full_tools_list(mcp_client)
agent = Agent(
name="github_assistant_agent",
model=BedrockModel(model_id="us.anthropic.claude-haiku-4-5-20251001-v1:0"),
system_prompt="""
あなたはGitHub Issues管理アシスタントです。
...
""",
tools=tools
)
user_message = payload.get("prompt", "")
response = agent(user_message)
return response
実装したエージェントをデプロイしていきたいと思います。
デプロイは AgentCore Runtime のコンソールからも行えますが、CLIからも実行できますので、今回はそちらを試してみたいと思います。
bedrock-agentcore-starter-toolkit というツールを利用しますので、作業ディレクトリにて仮想環境を立ててインストールします。
$ uv init
$ uv venv
$ source .venv/bin/activate
$ pip install bedrock-agentcore-starter-toolkit
また、エージェントのコードと同じ階層に requirements.txt も配置しておきます。
bedrock-agentcore>=0.1.21
bedrock-agentcore-starter-toolkit>=0.1.21
strands-agents>=1.0.0
boto3>=1.34.0
mcp[cli]>=0.1.0
それではCLIコマンドを実行していきます。agent.py、requirements.txtがある階層で実行します。また、実行にあたりSTS等でローカルに一時的な認証を通しておきます。
まずは agentcore configure を実行し、Runtimeの設定を行います。
$ agentcore configure --entrypoint agent.py
すると、以下のメッセージが出るので、適当なエージェント名を入力します。
次に、requirements.txtのパスを聞かれますが、そのままEnter。
Deploy Configuration では、コンテナベースでのデプロイか、直接デプロイかを聞かれますが、推奨されている 直接デプロイ を選択します。
Execute Role はそのままEnterで自動生成させます。
S3 Bucket は直接デプロイの際に必要で、エージェントのコードの格納先になります。こちらも自動生成させます。
Authorization Configuration はデフォルトの IAM authorization を利用するので、noを選択。ここでAIエージェントのInbound Auth認証が設定されます。
Request Header Allowlis は今回は no を選択。
Memory Configuration も今回はスキップします。こちらの設定でエージェントのメモリ（簡単にいうと会話履歴のようなもの）を管理させることもできます。
以上で設定が完了です。成功すると、以下のようなメッセージが出ます。
設定内容は、.bedrock_agentcore.yaml という名前で保存され、後から確認可能です。
Runtimeの設定を変更したい場合は、基本的に agentcore configure コマンドを再々実施する方法と、.bedrock_agentcore.yamlを直接編集する方法がありそうですが、.bedrock_agentcore.yamlを直接編集する場合は後述する agentcore launch を実施してデプロイし直さないとRuntimeに反映されないことに注意！
設定が完了したので、デプロイしていきます。
デプロイのコマンドは agentcore launch なのですが、今回はRuntimeの環境変数として GATEWAY_URL を設定したいので、以下のコマンドを実行します。
agentcore launch --env GATEWAY_URL=xxxxx(3.で控えたゲートウェイのURL)
しばらく待って、デプロイが無事成功したら以下のようなメッセージが出ます。
自動的に生成されたロググループや、GenAI Observablity Dashboardの案内もありますね。
それでは、動作確認してみます。
GitHubのリポジトリ上に存在する Issue 一覧を取得してもらおうと思いますので、適当にIssueを作っておきます。
エージェント実行のコマンドは以下になります。「{GitHubユーザー名}/{リポジトリ名}のIssue一覧を取得してください」と聞いてみます。
$ agentcore invoke '{"prompt": "{GitHubユーザー名}/{リポジトリ名}のIssue一覧を取得してください"}' \
--agent github_assistant_agent \
--user-id "test-user"
--agent にはデプロイ時に設定したエージェント名を、--user-id には適当な値を設定します。
実行に成功すると以下のような出力が得られます！
一部省略していますが、あらかじめ作成した5件のIssueとその詳細を問題なく取得できていることがわかります！
これで、GitHubのIssueを操作できるAIエージェントをAWS上にホスティングすることができました！🎊
さいごに
AgentCoreの登場により、今まで自分たちで頑張ってコンテナ上等でホスティングしていた作業が必要無くなったのはかなりありがたかったです！
最初は少し Identity と Gateway の役割や設定の理解に苦しみましたが、公式のドキュメントや試してみた系の記事を通してかなり理解が深まりました。
今年の re:Invent ではどのような発表があるのでしょうか。楽しみですね！
できれば現地でホットな情報を記事にできればなぁ、と考えています...
本記事は以上になります。最後までご精読いただきありがとうございました！