こんにちは!ADWAYS DEEEに新卒として入社した中西です。配属されてからは主に運用開発業務に携わっています。直近では、担当サービスのデプロイフローの中に、CodeDeployを組み込むプロジェクトを行っていました。配属される前はインフラの知識がほぼゼロの状態からスタートしましたが、最近では苦手意識もなくなり成長できたと感じています!
本題ですが、先日アマゾンウェブサービスジャパン合同会社様が開催してくださった、AWSのワークショップに参加させていただきました。弊社のエンジニアが全員参加のものとなり、現地に到着する前は他の企業様とも合同で行うのかと思っていましたが、なんと弊社の貸切で開催されました。
ワークショップの内容は直近で一般提供(GA)が開始された、話題のAmazon Bedrock AgentCoreに関するものでした。
今回はそのワークショップがどのようなものであったかについて話していきます。
ワークショップの概要
今回開催されたワークショップの概要としては以下になります。 - 場所: アマゾンジャパン 目黒オフィス - 参加者: ADWAYS DEEEに所属するエンジニア - 内容: - 前半 AgentCoreの概要 - 後半 ハンズオンで実際にAgentCoreの体験
ワークショップの内容
前半: AgentCoreの概要
ワークショップの前半では、Amazon Bedrock AgentCore自体がどのようなサービスなのかについて、スライドを用いて詳しく説明していただきました。
Amazon Bedrock AgentCoreは、AIエージェントを安全かつ大規模にデプロイして運用するための基盤サービスであり、以下の7つのサービスで構成されています。
| サービス名 | 説明 |
|---|---|
| Runtime | 構築したAIエージェントをホストするコンテナ環境を提供 |
| Identity | AIエージェントへアクセスするための認証管理を担う |
| Gateway | 既存のAPIやLambda関数をMCP対応ツールに変換し接続できる。セマンティック検索でツールを自動発見も可能 |
| Memory | 短期記憶(セッション内の会話)と長期記憶(ユーザー嗜好、要約)を自動管理 |
| Browser | Webオートメーション用のマネージドブラウザ。数百並列セッションへ自動スケール |
| Code Interpreter | AI が生成したコードを、完全に隔離した環境内でセキュアに実行 |
| Observability | CloudWatch統合による監視機能。モデル呼び出し、トークン使用量、レイテンシを追跡できる |
後半: 実践的なハンズオン
後半では、AWS Workshop Studioを使用した実践的なハンズオンが行われました。Workshop Studioは、AWSが提供する学習環境です。事前に構築された環境で即座にハンズオンを開始できるため、環境構築に時間を取られることなく学習に集中できました。
今回のワークショップでは、AgentCoreを構成する7つのサービスのうち、以下の6つのサービスについて実際に手を動かしながら学ぶことができました。 1. Code Interpreter 2. Runtime 3. Identity 4. Gateway 5. Observability 6. Memory
各モジュールは約15分から45分程度で完了する構成になっており、体感的には段階的に複雑さが増していく設計でした。
1. Code Interpreter: セキュアなコード実行環境の構築
最初のモジュールでは、AWSのコストを見積もるエージェントを題材に、Code Interpreterを使って隔離されたサンドボックス環境でPythonコードを安全に実行する方法を学びました。
このエージェントは、LLMでユーザーのアーキテクチャを解釈し、AWS Pricing MCP Serverで価格情報を取得します。そして、AgentCore Code Interpreterで正確な計算をします。AI が苦手とする正確な演算処理を安全に行えるのが、このモジュールの重要なポイントです。
実装では、CodeInterpreterクラスを使用してセッションを開始し、セキュアなサンドボックス環境でコードを実行します。
from bedrock_agentcore.tools.code_interpreter_client import CodeInterpreter # Code Interpreterの初期化 code_interpreter = CodeInterpreter(region="ap-northeast-1") code_interpreter.start() # Pythonコードの実行 response = code_interpreter.invoke("executeCode", { "language": "python", "code": calculation_code }) # セッションの終了 code_interpreter.stop()
このセクションを通じて、AIが生成したコードを本番環境で安全に実行するための基盤技術を理解できました。
2. Runtime: エージェントのデプロイとスケーリング
Runtimeモジュールでは、作成したエージェントをAWSのクラウド環境にデプロイする方法を学びました。ここでの重要なポイントは、実装言語・フレームワークに依存せず、特定のAPIを実装したDockerコンテナであれば動かすことができる点です。
エージェントのデプロイは、agentcoreコマンドを使用してたったの3ステップで完了します。
# 1. エージェントの設定
uv run agentcore configure \
--entrypoint deployment/invoke.py \
--name cost_estimator_agent \
--execution-role <IAM_ROLE_ARN> \
--region ap-northeast-1
# 2. エージェントのデプロイ
uv run agentcore launch
# 3. エージェントの呼び出し
uv run agentcore invoke '{"prompt": "How much does t3.micro cost?"}'
実際にデプロイしたエージェントは、最大8時間の長時間実行まで対応できます。料金としては実際の稼働時間のみ課金の対象となり、LLM の応答待ち時間は計算対象外になっているため、コスト効率が良い点が印象的でした。
参考: prepare_agent.py
3. Identity: OAuth 2.0による安全な認証
Identityモジュールでは、デプロイしたエージェントへのアクセスを保護するための認証を実装する方法を学びました。AgentCore Identityは、エージェントへのアクセスを安全に管理し、GitHub、Google、Microsoft、Slackなどを認証プロバイダーとして利用できます。
ハンズオンでは、AWSのCognitoを使用して、OAuth 2.0によるエージェント間の認証を設定しました。この認証は、M2M(Machine-to-Machine認証)と呼ばれるものです。特に便利だったのは、@requires_access_tokenデコレータを使用することです。これにより、開発者は複雑な認証の詳細を意識せずに、安全なAPI呼び出しを実装できます。
from bedrock_agentcore.identity.auth import requires_access_token @requires_access_token( provider_name=OAUTH_PROVIDER, scopes=[OAUTH_SCOPE], auth_flow="M2M" ) async def call_runtime_with_auth(prompt: str, access_token: str = None) -> str: """アクセストークンを使用してRuntimeを呼び出す""" headers = {"Authorization": f"Bearer {access_token}"} response = requests.post(RUNTIME_URL, headers=headers, json={"prompt": prompt}) return response.text
この仕組みにより、開発者は認証の詳細を意識することなく、保護されたエージェントへのアクセスを実装できます。アクセストークンはAgentCore Identityによって自動的に管理され、関数の引数として注入されます。
4. Gateway: 既存APIのMCP化
Gatewayモジュールは、個人的に最も印象に残ったセクションです。このモジュールでは、既存のAPIをMCP対応ツールに変換し、エージェントから利用できるようにする方法を学びました。
ハンズオンでは、デプロイしたコスト見積もりエージェントと、Gateway経由で提供されるメール送信ツールを組み合わせて、見積もり結果をメールで通知する仕組みを実装しました。
AgentCore Gatewayは、OpenAPI、Smithy、AWS Lambdaといった様々なAPI実装形式をMCP(Model Context Protocol)に変換できます。さらに、Salesforce、Slack、Jira、Asana、Zendeskなどの代表的なサービスについては1-clickでの統合も提供されています。エージェントからは、MCPClientを使用してGatewayに接続し、ツールを利用します。
from strands import Agent from strands.tools.mcp import MCPClient from mcp.client.streamable_http import streamablehttp_client # Gatewayへの接続 def create_transport(): return streamablehttp_client( GATEWAY_URL, headers={"Authorization": f"Bearer {access_token}"} ) mcp_client = MCPClient(create_transport) # Gatewayからツールを取得してエージェントに統合 with mcp_client: gateway_tools = mcp_client.list_tools_sync() agent = Agent(tools=[local_tool, *gateway_tools]) result = agent("タスクの実行")
この設定により、エージェントはMCPクライアント経由で自動的にこれらのツールを発見し、必要に応じて利用できるようになります。Gateway設定では、先ほど作成したOAuth認証情報も統合できます。
参考: test_gateway.py
5. Observability: CloudWatch統合による運用監視
Observabilityモジュールでは、デプロイしたエージェントの動作をCloudWatchで監視する方法を学びました。AgentCore Observabilityは、モデル呼び出し、トークン使用量、レイテンシなどの詳細なメトリクスを自動的に収集します。

上の図は、AgentCore RuntimeのObservability画面です。セッションごとにトレース情報が表示され、各トレースのSpan数、エラー数、スロットル数、実行時間などを一覧できます。トレースIDをクリックすると、詳細なトレース情報を確認でき、エージェントの動作を詳細に分析できます。
ハンズオンでは、実際にエージェントを実行しながらCloudWatchコンソールでメトリクスを確認し、ログストリームからデバッグ情報を取得する演習をしました。
また、収集したテレメトリデータはOpenTelemetry(OTEL)形式で出力できます。そのため、CloudWatchだけでなく既存のAPMやログ分析ツールとも連携可能です。本番環境でエージェントを運用する際には、このObservability機能が不可欠だと感じました。
6. Memory: 文脈を理解するエージェント
最後のMemoryモジュールは、最も高度な内容でした。AgentCore Memoryを使用すると、エージェントは短期記憶(セッション内の会話履歴)と長期記憶(ユーザーの嗜好や過去の選択パターン)を持つことができます。
ハンズオンでは、MemoryClientを実装して、エージェントの会話履歴を自動的に保存・読み込みする仕組みを構築しました。
from bedrock_agentcore.memory.client import MemoryClient # Memoryの初期化 memory_client = MemoryClient(region_name="ap-northeast-1") memory = memory_client.create_memory_and_wait( name="cost_estimator_memory", strategies=[{"userPreferenceMemoryStrategy": {...}}], event_expiry_days=7 ) # 短期記憶: イベントの保存 memory_client.create_event( memory_id=memory_id, actor_id="user_123", session_id=session_id, messages=[(user_message, "USER"), (assistant_message, "ASSISTANT")] ) # 短期記憶: イベントの取得 events = memory_client.list_events( memory_id=memory_id, actor_id="user_123", session_id=session_id, max_results=5 ) # 長期記憶: ユーザーの好みを取得 memories = memory_client.retrieve_memories( memory_id=memory_id, namespace=f"/preferences/user_123", query="User preferences", top_k=3 )
この仕組みにより、エージェントは以下のような会話ができます。
- 短期記憶: セッション内の会話履歴を保存し、複数の見積もりを比較
- 長期記憶: ユーザーの好みや決定パターンを学習し、パーソナライズされた提案を生成
- セッションが切れた後でも、同じactor_idで再開すれば過去の好みを参照可能
長期記憶は自動的にセマンティック検索可能な形式で保存され、関連する情報を効率的に取り出せる設計になっています。
短期記憶を長期記憶に移行する際には、Memory Strategyを使用します。AgentCore Memoryは4つのストラテジーを提供しており、用途に応じて選択できます。
- SemanticMemoryStrategy: 会話から得られた事実や知識に注目
- SummaryMemoryStrategy: 要点や決定事項に注目
- UserPreferenceMemoryStrategy: ユーザーの好みや選択パターンに注目
- CustomMemoryStrategy: カスタムプロンプトで特定の情報に注目
これにより、どの情報を長期記憶に移行するかを細かく制御できます。
参考: test_memory.py
各モジュールは独立して学べる構成になっていますが、最終的にはこれらを組み合わせることで本番環境に耐えうるエージェントを構築できます。認証機能、外部ツールの活用、過去の文脈の理解、動作の監視など、必要な要素が全て揃っていることを実感しました。特に印象的だったのは、各サービスが独立して動作するだけでなく、相互に連携することでより強力なエージェントシステムを構築できる点でした。

特に印象に残った技術
今回のワークショップで特に印象に残ったのが、AgentCore Gateway と Runtime の組み合わせによる活用の可能性です。
Gatewayは、既存のAPIやLambda関数をMCP(Model Context Protocol)対応ツールに変換し、エージェントから簡単に利用できるようにする機能を提供します。これにより、社内の既存システムや外部のサービスを、わずかな設定でAIエージェントのツールとして活用できるようになります。
さらに、Runtime で社内の様々な MCP Server をホストし、Gateway 経由で統合できます。これにより、各エンジニアが個別に環境構築することなく、AIエージェントから社内のツールやデータに簡単にアクセスできる基盤を構築できます。ドキュメント検索、ログ解析、データベース照会など、これまで個別に管理していたツールを一元化できます。その結果、どのAIエージェントからでも利用できるようになり、エージェントの活用の幅が大きく広がります。
まとめ
今回、初めてAWSのワークショップに参加させていただき、Amazon Bedrock AgentCoreについて多くの学びを得ることができました。ワークショップ当日は開催前にチームで目黒に集まり食事をしてから会場入りするなど、普段とは違う環境で良いリフレッシュにもなりました。
Memory機能による文脈の保持、Identity機能による安全な認証、Observabilityによる運用監視など、実際の業務で活用できる場面がたくさんありそうです。これから、今回学んだ技術を実際の業務の中でどう活かせるか、様々な場面を探していきたいと思います。
なお、本記事で紹介したコード例は、sample-amazon-bedrock-agentcore-onboardingのGitHubリポジトリで公開されていますので、興味のある方はぜひご覧ください。
最後までご覧いただきありがとうございました!

ワークショップ参加者の声
ワークショップに参加した社内エンジニアから寄せられた感想をご紹介します。参加者は、AgentCoreの技術的な可能性を理解しつつも、実際のプロダクション環境への適用には様々な検討事項があることを認識していました。
便利だと思った点 - Memoryで短期記憶および長期記憶への自動的な移行をマネージドで提供していること - Code Interpreterで非決定的な思考はモデルに、決定的な動作はインタープリタに任せられること - AgentCore Gatewayを用いてMCPでないものをMCPとして扱えること
プロダクトで使えそうなこと - Memoryの短期記憶・長期記憶を活用してAI Chatを独自に作る際の工数を削減できそう - 問い合わせ対応システムの一次・二次回答に活用し、DBやログを読んで状況に合わせた回答を生成 - 汎用的なツールを社内公開しておき、様々なAIエージェントから使えるようにする(RAGなども提供)
難しそうなポイント - 個々のツールの動作検証をどう行うか、SDK・基盤の選定、エージェンティックループとワークフローの使い分け - セキュリティの担保が難しい(DBやログへのアクセス範囲、データマスキングのコストと品質のトレードオフ) - システム的なモニタリングは揃っているが、エージェントの品質評価(正確性など)は自力実装が必要