🏔️

【AWS公式】ヘルスケアAIエージェント - Amazon Bedrock AgentCore を活用した構築を徹底解説

山田航司（Koji Yamada）

2025/10/27に公開

本ブログはAWS AI Agent ブログ祭り(Zenn: #awsaiagentblogfes, X: #AWS_AI_AGENT_ブログ祭り)の第1日目です。

 はじめに
 AWS SamplesこのヘルスケアAIエージェントプロジェクトは AWS Samples (github.com/aws-samples)に含まれるサンプルコードです。
このリポジトリについて:

GitHub: amazon-bedrock-agents-healthcare-lifesciences

ライセンス: MIT License

目的: ヘルスケア・ライフサイエンス分野でのAIエージェント実装例を示す

 プロジェクト全体の構成

 図の説明このリポジトリは4つの主要コンポーネントで構成されています:
amazon-bedrock-agents-healthcare-lifesciences/
├── agents_catalog/              ← ① すぐ使える専門エージェント集（28種類以上）
│   ├── 01-biomarker-discovery/  
│   ├── 02-clinical-trial/       
│   └── ...
│
├── multi_agent_collaboration/   ← ② マルチエージェント協調
│   ├── cancer_biomarker_discovery/
│   └── clinical_trial_protocol/
│
├── evaluations/                 ← ④ エージェント性能評価フレームワーク
│
├── ui/                          ← ③ Web UI（旧方式用）
│
└── agentcore_template/          ← 今回の記事でデプロイする対象
    └── この図の構成要素を作るための空のテンプレート（図には直接登場しない）

 ②Multi-Agent Collaboration の実例
 がんバイオマーカー発見エージェント概要:
がん治療の臨床試験における成功率は約5%と非常に低いです。バイオマーカーによる患者層別化（どの患者にどの治療が効くか）により、臨床開発の成功確率を2〜5倍に向上できることが知られています。
バイオマーカー（生体指標）とは、がんの存在を示す生物学的分子のことで、別名で腫瘍マーカーとも呼ばれます。血液、体液、組織などから見つかります。
このプロジェクトでの3種類のバイオマーカー:

Genomic（ゲノム）: 遺伝子発現データ（21遺伝子のRNA発現レベル）

Clinical（臨床）: 人口統計、腫瘍ステージ、生存状況

Radiology/Imaging（画像）: CT/PET-CTスキャンから得られる腫瘍の特徴
アーキテクチャの構成:
中央: Strands Orchestrator Agent（オーケストレーター）がユーザーの質問を分析し、4つの専門エージェントにタスクを割り当て、結果を統合
4つの専門エージェント:

Agent 1: Database specialist - 自然言語→SQL変換、Redshift検索

Agent 2: Clinical evidence researcher - PubMed(米国国立医学図書館（NLM）が提供する生物医学文献データベース) API経由で文献検索

Agent 3: Medical Imaging expert - SageMaker経由でCTスキャン解析

Agent 4: Statistician - 統計分析、Kaplan-Meierチャート(時間経過に伴う生存率の変化)生成
動作例: 「化学療法を受けた患者で、生存率と相関する上位5つのバイオマーカーは？棒グラフも生成して」
1. User → 質問

2. Orchestrator → LLMで分析
  判断: Database specialist + Statistician が必要

3. Database specialist
   • 自然言語→SQL変換
   • Redshiftから化学療法患者のバイオマーカーデータ取得
   • 結果: 遺伝子発現値（各遺伝子がどれだけ発現しているか（RNA量）を示す数値）と生存データ（Dead/Alive）

4. Statistician
   • 生存回帰分析実行
   • p値が最も低い上位5つを特定
   • 棒グラフ生成

5. Orchestrator → 結果統合
  LLMで最終回答生成

6. User ← 「上位5つのバイオマーカー: GDF15 (p=0.001), POSTN (p=0.003)...」
        + 棒グラフ画像　を受け取る
このシステムの特徴:

マルチモーダル: 臨床、ゲノム、CTスキャン画像データを統合

多様なツール: Text2SQL、統計モデル、文献検索、画像処理

透明性: Chain of thought（思考の連鎖）を表示して信頼性を向上
agentcore_templateとの関係:

このシステムは、agentcore_templateと同じ技術スタックを使用しています:
AgentCore Runtime上で動作
Strands Agentsフレームワークを使用
各専門エージェントは独自のツールを持つ
Orchestratorが全体を調整
agentcore_templateを使えば、このような高度なマルチエージェントシステムを構築できます。
参考: multi_agent_collaboration/cancer_biomarker_discovery

 本記事の位置付けこの記事で扱う内容:

1. 全体像の説明（上記セクション）: プロジェクト構成とマルチエージェント協調の例

2. AgentCore Templateの説明（このセクション以降）: アーキテクチャ解説とデプロイ手順

 AgentCore Template「エンタープライズグレードのAIエージェントを作るための、インフラ込みのスターターキット」
このテンプレートは Amazon Bedrock AgentCore を使用しています。
Amazon Bedrock AgentCore とは:

• AWSが提供するフルマネージドなエージェント実行基盤

• 5つのコンポーネント: Runtime, Gateway, Memory, Identity, Observability

• Strands Agentsフレームワークと組み合わせて使用可能

既存のエージェント (agents_catalog/): すぐ使える専門エージェント

AgentCore Template: 自分で作るための土台（あなたのユースケースに合わせてカスタマイズするため、空っぽ）
デプロイ直後:
✅ インフラは完成（Runtime, Gateway, Memory, Identity, Observability）
✅ Claude と会話できる
❌ 実用的なツールはない（サンプルのみ。自分でカスタマイズする。）

 Strands Agents フレームワークこのテンプレートは Strands Agents という、AWSが開発したオープンソースSDKを使用しています。
主な特徴:
Model-first design（モデル第一設計）
Foundation Model（LLM）がエージェントの知能の中核。高度な自律推論を可能にする。
MCP統合
Model Context Protocol (MCP) をネイティブサポート
柔軟なモデル選択
Anthropic Claude、Amazon Nova (Premier, Pro, Lite, Micro) など

 Agentic Loop（エージェントループ）
Strands Agentsの中核となる概念が Agentic Loop です。エージェントは Model Loop（推論・ツール選択）と Tool Loop（ツール実行）を繰り返して複雑なタスクを段階的に解決します。
重要性: 自律性、反復性、柔軟性（ツール(MCPやプログラム関数など)を組み合わせる）
具体例: 患者情報取得エージェント
ユーザーからの質問
user_input = "患者ID 12345の最新検査結果を教えて"

Agentic Loop（内部処理の流れ）
1. Prompt → Agent起動

2. [Model Loop 1] 
LLM: "患者情報を取得する必要がある"
→ Tool選択: search_patient

3. [Tool Loop 1]
search_patient(12345) 実行
→ 結果: {name: "山田太郎", age: 45}

4. [Model Loop 2]
LLM: "次に検査結果を取得する必要がある"
→ Tool選択: get_lab_results

5. [Tool Loop 2]
get_lab_results(12345) 実行
→ 結果: {blood_pressure: "140/90"}

6. [Model Loop 3]
LLM: "情報が揃ったので最終回答を生成"
→ Tool選択: なし（終了）

7. Return final response
"山田太郎さん（45歳）の最新検査結果: 血圧 140/90"
このように、Agentic Loopによってエージェントは自律的に必要なツールを選択・実行し、複雑なタスクを段階的に解決します。

 AgentCore Template のアーキテクチャ全体像
テンプレートに使用されている、Amazon Bedrock AgentCoreは5つのコンポーネントで構成されています。
開発者は、Amazon Bedrock AgentCoreを使用することで、実世界のデプロイに不可欠なスケール、信頼性、セキュリティを備えた AI エージェントを本番環境へ迅速に投入できます。

 1. Amazon Bedrock AgentCore Runtime役割:  安全でサーバーレスな専用ホスティング環境（Docker コンテナベース）
主要メリット:

使った分だけ課金: 動的プロビジョニング、エージェントが LLM 応答を待機中は通常課金なし

長時間実行（最大8時間）: 複雑なマルチステップタスク、エージェント協調に対応

セッション分離: 専用 microVM で各ユーザーを隔離

大容量ペイロード（最大100MB）: 画像・音声・動画などマルチモーダルデータに対応

フレームワーク・モデル非依存: Strands, LangGraph, CrewAI / Bedrock, OpenAI, Gemini 等

 2. Amazon Bedrock AgentCore Gateway役割: エージェントと外部ツールの標準化された接続レイヤー
主要メリット:

MCP サーバーとして機能: エージェントがツールと対話する単一アクセスポイント

複数のツールタイプをサポート: Lambda 関数、OpenAPI 仕様、MCP サーバーなど

自動変換: REST API を MCP 互換ツールに自動変換

安全な認証管理: OAuth 認証（Gateway Authorizer）など

 3. Amazon Bedrock AgentCore Memory役割: エージェントの状態管理とコンテキスト永続化
主要メリット:

短期記憶と長期記憶の両方をサポート: Short-term（即時）+ Long-term（学習）

ユーザー理解: 中断した会話の再開やユーザの好み・傾向を記憶する仕組み

簡単な構築: 複雑なメモリインフラストラクチャ管理を排除

 4. Amazon Bedrock AgentCore Identity役割: エージェントの包括的な認証・認可管理
主要メリット:

双方向認証: インバウンド（ユーザー→エージェント）+ アウトバウンド（エージェント→リソース）を統合管理

企業 IdP 連携: Okta, Microsoft Entra ID, Cognitoなどとシームレスに統合

監査証跡とコンプライアンス支援: すべてのエージェントアクションをログ記録

階層的なアクセス制御: エージェントごとに一意の ARN、階層レベルでポリシー適用

 5. Amazon Bedrock AgentCore Observability役割: エージェント特有の動作を可視化・分析
主要メリット:

統合された運用ダッシュボード: 本番環境でのトレース、デバッグ、監視

エージェントワークフロー: 各ステップの詳細な可視化

包括的なメトリクス: レイテンシー、リソース使用率、エラー率、リクエストパターンなど

 AgentCore Template デプロイ手順
 このセクションの位置づけREADMEの手順に加えて、実際に遭遇した問題と解決方法を記載します。

 前提条件（Prerequisites）
 1. AWS アカウント必要なもの:
アクティブな AWS アカウント
適切な権限（CloudFormation, Lambda, Cognito, Bedrock などを作成できる）

 2. AWS CLI のインストールと設定こちらの手順を参照
本記事での試行設定は:
デフォルトリージョン: us-east-1
デプロイ先: us-west-2（環境変数で上書き）

 3. Bedrock モデルアクセスの有効化Amazon Bedrock Console にアクセスし、左メニューから「Model access」を選択。以下のモデルへのアクセスをリクエスト:
Anthropic Claude 3.7 Sonnet
Anthropic Claude 3.5 Haiku
確認方法:
aws bedrock list-foundation-models --by-provider Anthropic --region us-west-2
今回の試行では、Claude 3.7 Sonnetを使用

 4. Python 3.10 以上確認方法:
python3 --version
Python 3.10 のインストール（macOS の場合）:
brew install python@3.10

# インストール確認
python3.10 --version
なぜ 3.10+ が必要か:

agentcore CLI の依存パッケージが Python 3.10+ を要求
3.9 以下では一部の機能が動作しない可能性がある

 デプロイ手順
 ステップ0: ツールのカスタマイズ（デプロイ前の準備）
 サンプルツールの確認デフォルトで含まれているツール:
1. ローカルツール: get_system_info
コードを表示（クリックして展開）python:agent/agent_config/tools/sample_tools.py
from typing import Dict, Any
from strands import tool

@tool(
    name="Get_system_info",
    description="Gets basic system information"
)
def get_system_info() -> Dict[str, Any]:
    """Agent のシステム情報を返すサンプルツール"""
    return {
        "status": "operational",
        "version": "1.0.0",
        "capabilities": ["text_processing", "memory_storage", "tool_execution"]
    }
このツールの役割:
Agent がツールを呼び出せることを確認するためのデモツール
Agent コンテナ内で実行（外部アクセス不要）
最小限の実装例
2. Gateway Lambda ツール: echo_message
コードを表示（クリックして展開）prerequisite/lambda/python/lambda_function.py
def echo_message(message: str) -> str:
    """受け取ったメッセージをそのまま返すサンプルツール"""
    return f"Echo: {message}"

def lambda_handler(event, context):
    """Lambda のエントリーポイント"""
    extended_tool_name = context.client_context.custom["bedrockAgentCoreToolName"]
    resource = extended_tool_name.split("___")[1]
    
    if resource == "echo_message":
        message = event.get("message")
        if not message:
            return {"statusCode": 400, "body": "❌ Please provide message"}
        return {"statusCode": 200, "body": f"👤 Message echo: {echo_message(message)}"}
    
    return {"statusCode": 400, "body": f"❌ Unknown toolname: {resource}"}
このツールの役割:
Gateway が Lambda を呼び出せることを確認するためのデモツール
Lambda 関数として実行（Agent コンテナの外）
外部ツール統合の実装例

 患者検索ツールの追加今回の実装: 実用的な患者検索ツールを追加してカスタマイズする形で進めます
1. healthcare_tools.py を作成:
コードを表示（クリックして展開）agent/agent_config/tools/healthcare_tools.py
from typing import Dict, Any
from strands import tool

# 5人分の患者モックデータベース
PATIENT_DATABASE = {
    "12345": {
        "patient_id": "12345",
        "name": "山田太郎",
        "age": 45,
        "blood_pressure": "140/90",
        "diagnosis": "高血圧",
        "notes": "減塩食と運動療法を推奨"
    },
    "12346": {
        "patient_id": "12346",
        "name": "佐藤花子",
        "age": 38,
        "blood_pressure": "120/80",
        "diagnosis": "健康",
        "notes": "定期検診で異常なし"
    },
    "12347": {
        "patient_id": "12347",
        "name": "鈴木一郎",
        "age": 62,
        "blood_pressure": "150/95",
        "diagnosis": "高血圧、糖尿病",
        "notes": "投薬治療中、月1回の経過観察が必要"
    },
    "12348": {
        "patient_id": "12348",
        "name": "田中美咲",
        "age": 29,
        "blood_pressure": "110/70",
        "diagnosis": "健康",
        "notes": "妊娠初期、定期的な産科検診を推奨"
    },
    "12349": {
        "patient_id": "12349",
        "name": "高橋健太",
        "age": 55,
        "blood_pressure": "135/85",
        "diagnosis": "境界型高血圧",
        "notes": "生活習慣改善で経過観察中"
    }
}

@tool(
    name="search_patient",
    description="患者IDで患者情報を検索します"
)
def search_patient(patient_id: str) -> Dict[str, Any]:
    """患者IDで患者情報を検索する"""
    patient = PATIENT_DATABASE.get(patient_id)
    
    if patient:
        return {"status": "success", "data": patient}
    else:
        return {
            "status": "error",
            "message": f"患者ID {patient_id} が見つかりませんでした",
            "available_ids": list(PATIENT_DATABASE.keys())
        }
2. agent_task.py を更新:
コードを表示（クリックして展開）agent/agent_config/agent_task.py
from agent.agent_config.tools.sample_tools import get_system_info
from agent.agent_config.tools.healthcare_tools import search_patient  # ← 追加

# Agent が使えるツールのリスト
tools=[get_system_info, search_patient]  # ← search_patient を追加
今回は、デフォルトサンプルツールとしては、ローカルツールを選択（モックデータベースで十分）
補足: 本番環境で実際のデータベース（RDS/DynamoDB）を使う場合は、Gateway Lambda ツールとして lambda_function.py に実装し、api_spec.json にスキーマを追加します。

 ステップ1: インフラストラクチャのデプロイ
 1-1. Python環境のセットアップ（ローカル）ローカル
├── .venv/                    ← Python仮想環境
│   └── agentcore CLI         ← AWS APIを呼び出す開発者ツール
│
↓ AWS API経由で操作
│
AWS クラウド
├── CloudFormation            ← インフラ作成
├── Lambda                    ← Agent ツール実行
└── AgentCore Runtime         ← Agent 本体が動く（Dockerコンテナ）

agentcore CLI は開発者ツール（Terraform や AWS CDK と同じ）
ローカルから AWS API を呼び出してクラウドにリソースを作成
Agent 本体は後で Docker イメージ化されて AWS クラウドで動く
仮想環境の作成:
コードを表示（クリックして展開）cd agentcore_template

# Python 3.10 を明示的に指定（前提条件で確認・インストール済み）
python3.10 -m venv .venv
source .venv/bin/activate

# Python バージョン確認
python --version
# → Python 3.10.x であることを確認

# 依存パッケージインストール
uv pip install -r dev-requirements.txt

 1-2. インフラのデプロイ（CloudFormation）⚠️ 注意1: デプロイ先リージョンの確認
prereq.sh は AWS CLI のデフォルトリージョン設定を自動的に読み取ります（前提条件で確認済み）。
今回の試行: us-west-2 にデプロイ
前提条件での確認結果: デフォルトリージョンは us-east-1
対応: 環境変数で us-west-2 を指定（AWS CLI のグローバル設定は他のプロジェクトでも使用される。環境変数はこのターミナルセッションのみ有効。プロジェクトごとに異なるリージョンを使い分けられる）
# ターミナルセッション中のみ有効（他のプロジェクトに影響しない）
export AWS_DEFAULT_REGION=us-west-2
export AWS_REGION=us-west-2

# 確認
echo $AWS_DEFAULT_REGION
# → us-west-2
⚠️ 注意2: Cognito MFA 設定の変更
MFA（Multi-Factor Authentication）とは:
2段階認証のこと（パスワード + SMS認証コード）
テンプレートのデフォルト設定:
# prerequisite/cognito.yaml（オリジナル）
MfaConfiguration: 'OPTIONAL'  # ← ユーザーが選択可能
問題:

OPTIONAL にすると SMS 設定（電話番号検証）が必要
SMS 設定なしでデプロイするとエラー
今回の対応: 開発環境のため MFA を無効化
修正方法:
# prerequisite/cognito.yaml を編集
MfaConfiguration: 'OFF'  # OPTIONAL → OFF に変更
影響:
✅ デプロイが簡単になる（SMS 設定不要）
✅ 開発・デモ環境では十分
❌ 2段階認証は使えない
本番環境での推奨:
MFA を OPTIONAL または ON に設定
SMS 設定を追加（Amazon SNS の設定が必要）
デプロイ実行:
chmod +x scripts/prereq.sh
./scripts/prereq.sh myapp  # プレフィックスを指定
処理フロー:
S3 バケット作成: myapp-<ACCOUNT_ID>
Lambda コードの ZIP 化: prerequisite/lambda/python を ZIP 化
S3 に Lambda コードをアップロード
CloudFormation スタック 1: Infrastructure
Lambda Function（Gateway ツール用: echo_message）
IAM Role（Gateway 用）
IAM Role（Runtime 用）
SSM Parameters（設定値保存）
CloudFormation スタック 2: Cognito
Cognito User Pool
Cognito User Pool Client（Web用）
Cognito User Pool Client（Machine用: M2M認証）
Cognito Domain
SSM Parameters（Cognito設定値）
Knowledge Base 作成（オプション）
デプロイ結果の確認:
chmod +x scripts/list_ssm_parameters.sh
./scripts/list_ssm_parameters.sh
表示される内容 :18個のパラメータ

 ステップ2: AgentCore Gateway 作成
Gateway の役割: Agent と外部ツール（Lambda）を接続する橋渡し
python scripts/agentcore_gateway.py create --name myapp-gw
Gateway で設定される認証:
Inbound 認証（Agent → Gateway）
誰が Gateway にアクセスできるか
認証方式: Cognito JWT（JSON Web Token = デジタル身分証明書）
許可するクライアント: Machine Client（Step 1 で作成）
Outbound 認証（Gateway → Lambda）
Gateway が Lambda を呼び出す権限
認証方式: Gateway IAM Role（Step 1 で作成）
作成されるもの:
Gateway（MCP プロトコル対応）
Lambda ターゲット（Step 1 で作成した Lambda 関数に接続）

 ステップ3: AgentCore Identity 設定（Credentials Provider）
Credentials Provider の役割: Agent が Gateway にアクセスする時に必要な JWT トークンを自動取得する仕組み
python scripts/cognito_credentials_provider.py create --name myapp-cp
なぜ必要か:
Agent Runtime は Gateway にアクセスする時に JWT トークンが必要
Credentials Provider が Cognito から自動的にトークンを取得してくれる
手動でトークンを管理する必要がなくなる
仕組み:
Agent Runtime
    ↓ 「Gateway にアクセスしたい」
Credentials Provider
    ↓ Cognito に自動アクセス（Machine Client ID + Secret）
    ↓ JWT トークンを取得
    ↓ Agent Runtime に渡す
Agent Runtime
    ↓ JWT トークンを使って Gateway にアクセス

 ステップ4: AgentCore Memory 作成
目的: Agent の会話履歴と学習内容を保存
Memory の種類:

Short-term Memory: セッション内の会話履歴（今回使用）

Long-term Memory: セッション跨ぎの学習内容（今回は未使用）
Memory の3つの戦略:

SEMANTIC（事実抽出）: 「患者ID 12345 は山田太郎さん」

SUMMARY（会話要約）: 「前回の会話で血圧について質問された」

USER_PREFERENCE（ユーザー設定）: 「詳細な説明を好む」
戦略の実装コード（クリックして展開）scripts/agentcore_memory.py
strategies = [
    {
        StrategyType.SEMANTIC.value: {
            "name": "fact_extractor",
            "description": "Extracts and stores factual information",
            "namespaces": ["support/user/{actorId}/facts"],
        },
    },
    {
        StrategyType.SUMMARY.value: {
            "name": "conversation_summary",
            "description": "Captures summaries of conversations",
            "namespaces": ["support/user/{actorId}/{sessionId}"],
        },
    },
    {
        StrategyType.USER_PREFERENCE.value: {
            "name": "user_preferences",
            "description": "Captures user preferences and settings",
            "namespaces": ["support/user/{actorId}/preferences"],
        },
    },
]

memory = memory_client.create_memory_and_wait(
    name=name,
    strategies=strategies,
    description="Memory for my app template agent",
    event_expiry_days=30
)
Memory 作成:
python scripts/agentcore_memory.py create --name myapp
作成されるもの:
Memory ID: myapp-<RANDOM_ID>
イベント保持期間: 30日（デフォルト）
3つの戦略（SEMANTIC, SUMMARY, USER_PREFERENCE）
動作例:
User: "My name is Taro"
Agent: "I'll remember that your name is Taro"
  → Memory に保存

User: "What is my name?"
Agent: "Your name is Taro"
  → Memory から取得

 ステップ5: Agent Runtime セットアップとデプロイ
目的: Agent が実際に動く実行環境を設定してデプロイ
⚠️ 注意: Agent 名は必ずプレフィックス（myapp）で始めること

 5-1. SSM パラメータから値を取得./scripts/list_ssm_parameters.sh
必要な値:

必須: /app/myapp/agentcore/runtime_iam_role

OAuth 使用時のみ:
/app/myapp/agentcore/cognito_discovery_url
/app/myapp/agentcore/web_client_id


 5-2. Agent Runtime 設定agentcore configure \
  --entrypoint agent/main.py \
  -er arn:aws:iam::<ACCOUNT_ID>:role/MyAppStackInfra-RuntimeAgentCoreRole-XXXXX \
  --name myappHealthAgent
対話形式で設定:

Requirements file: agent/requirements.txt（自動検出）

ECR Repository: Auto-create を選択

Authorization: IAM または OAuth を選択

今回: IAM（開発用）

OAuth: エンドユーザー向け公開時に使用


Memory: Short-term only を選択
Long-term は処理に時間がかかる（120-180秒）ため開発段階では不要

IAM vs OAuth の違い:


認証方式
用途
認証情報
使用例


IAM
開発者・管理者
AWS CLI の認証情報

agentcore invoke コマンド

OAuth
エンドユーザー
Cognito ログイン
Streamlit UI（app_oauth.py）

今回の選択: IAM（開発・デモ環境）
重要な注記:
Runtime の認証（IAM/OAuth）と Gateway の認証（M2M）は独立している
Gateway への接続は M2M 認証（Credentials Provider）で自動化される
作成される設定ファイル（.bedrock_agentcore.yaml）:
Agent 名: myappHealthAgent
Platform: linux/arm64（AWS Graviton）
Memory: Short-term only（30日保持）
Observability: 有効（CloudWatch Logs, X-Ray）

 5-3. Agent Runtime デプロイ⚠️ 重要: 古い設定ファイルの削除
rm -f .agentcore.yaml
理由:

.agentcore.yaml = 古い設定ファイル

.bedrock_agentcore.yaml = 新しい設定ファイル（5-2で作成）
古い設定が残っていると新しい設定が反映されない
デプロイ実行:
agentcore launch
何が起きるか:
CodeBuild でビルド（約61秒）
Docker イメージビルド（ARM64, 約305MB）
ECR にプッシュ
Runtime デプロイ
Agent Runtime にコンテナをデプロイ
Memory を接続（ステップ4で作成）
Gateway を接続（ステップ2で作成）
Observability を有効化（CloudWatch Logs, X-Ray）
デプロイされる Agent の構成:
agent/
├── main.py              # エントリーポイント
├── requirements.txt     # 依存パッケージ
└── agent_config/
    ├── agent.py         # Agent 定義（Claude 3.7 Sonnet）
    ├── agent_task.py    # ツール設定
    └── tools/
        ├── sample_tools.py      # デフォルトツール（get_system_info）
        └── healthcare_tools.py  # 追加ツール（search_patient）← ステップ0で追加

 5-4. Agent 動作確認IAM 認証の場合（今回）:
agentcore invoke '{"prompt": "Hello"}'
OAuth 認証の場合:
python tests/test_agent.py myappHealthAgent -p "Hello"
テスト結果:
✅ Agent が正常に応答
✅ Session ID が発行される
✅ Gateway 経由でツールが利用可能

 5-5. Observability（監視機能）自動有効化: ステップ5-2 の agentcore configure で自動的に有効化されます
何が有効化されるか:

CloudWatch Logs: Agent の実行ログ

X-Ray トレーシング: Agent の推論ステップ、ツール呼び出し、モデル対話を記録

GenAI Observability Dashboard: Agent の動作を可視化
ダッシュボードの表示（オプション）:
CloudWatch で Transaction Search を有効化
手順

GenAI Observability Dashboard にアクセス
ログの確認:
aws logs tail /aws/bedrock-agentcore/runtimes/myappHealthAgent-XXXXX-DEFAULT --follow
Agent が使えるツール:
ローカルツール（Agent コンテナ内で実行）:

get_system_info: システム情報取得（デフォルト）

search_patient: 患者検索（Step 0 で追加）
Gateway ツール（Lambda 経由で実行）:

echo_message: メッセージエコーバック（サンプル）
Strands 組み込みツール:

current_time: 現在時刻取得

 遭遇した問題と解決方法問題1: ModuleNotFoundError
エラー内容: ModuleNotFoundError: No module named 'agent'
原因: .bedrock_agentcore.yaml の source_path が agent/ ディレクトリのみを指していた
解決方法:
# .bedrock_agentcore.yaml を編集
source_path: /path/to/agentcore_template  # 親ディレクトリ
問題2: ParameterNotFound (Knowledge Base ID)
原因: Knowledge Base を作成していない場合、パラメータが存在しない
解決方法:
# agent/main.py を編集
try:
    os.environ["KNOWLEDGE_BASE_ID"] = get_ssm_parameter(...)
except Exception as e:
    logger.warning(f"Knowledge Base ID not found: {e}")
    os.environ["KNOWLEDGE_BASE_ID"] = ""
問題3: NameError (logger 未定義)
解決方法:
# agent/main.py を編集
# Logging setup (must be before using logger)
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)
デプロイ成功後の確認:
agentcore invoke '{"prompt": "Hello! Can you introduce yourself?"}'

 ステップ6: Streamlit UI の起動目的: Agent Runtime を呼び出すためのローカル UI
ローカル
├── Streamlit UI (app.py)
│   ↓ boto3 で AWS API 呼び出し
│   ↓
AWS クラウド
└── AgentCore Runtime
    └── Agent コンテナ（実行中）
        └── search_patient ツール（Step 0 で追加）
重要: Streamlit UI はローカルで動作、Agent は AWS で動作
Streamlit UI の起動:
cd agentcore_template
source .venv/bin/activate
export AWS_DEFAULT_REGION=us-west-2

streamlit run app.py --server.port 8501
ブラウザで開く: http://localhost:8501
使い方:
サイドバーで Agent を選択（myappHealthAgent）
チャット入力欄に質問を入力
何が起きているか:
Streamlit UI が質問を Agent Runtime に送信（boto3 経由）
Agent が search_patient ツールを呼び出し（Step 0 で追加したツール）
モックデータベースから患者情報を取得
Agent が結果を整形して返答
Streamlit UI に表示
利用可能な患者ID（Step 0 で作成）:
12345: 山田太郎（45歳、高血圧）
12346: 佐藤花子（38歳、健康）
12347: 鈴木一郎（62歳、高血圧・糖尿病）
12348: 田中美咲（29歳、妊娠初期）
12349: 高橋健太（55歳、境界型高血圧）

 さらに拡張するには
 1. Gateway Lambda ツール (prerequisite/lambda/python/)外部システム連携が必要な場合はLambdaツールを追加します。
# lambda_function.py に追加
def get_lab_results(patient_id: str) -> dict:
    # 外部API呼び出し
    response = requests.get(f"https://lab-api.example.com/results/{patient_id}")
    return response.json()
特徴:
Lambda 関数として実行
外部システム連携
データベースアクセス
追加手順:

lambda_function.py に関数追加

api_spec.json にスキーマ追加
Lambda を再デプロイ（./scripts/prereq.sh）
Gateway を再作成

 2. Knowledge Base (prerequisite/docs-rag/)医療文献やガイドラインを参照する場合はKnowledge Baseを追加します。
# 医療文献PDFをアップロード
cp medical_guidelines.pdf prerequisite/docs-rag/

# Knowledge Base 作成
python prerequisite/knowledge_base.py --mode create
特徴:
ドキュメント検索（RAG）
医療文献、ガイドライン参照

 重要なアップデート情報⚠️ Important Update (September 17, 2025): The new recommended way to deploy agents is using the Strands framework and Amazon Bedrock AgentCore. This codebase is iteratively being updated shortly to reflect these new best practices. The existing deployment methods for individual agents and the entire stack are still functional, we also provide the following examples with the new framework.
何が起きているのか？
このリポジトリは移行期にあります。旧方式と新方式は全く別のサービスを使用しています。

 技術的な違い

項目
旧方式
新方式


API
Amazon Bedrock Agents
Amazon Bedrock AgentCore

エージェント実体
AWS リソース
Docker コンテナ

デプロイ方法
CloudFormation ワンクリック

agentcore CLI（6ステップ）

CloudFormation
全部入り（14エージェント）
基盤のみ（S3, Lambda, IAM）

ツール接続
Lambda Action Group
Gateway + MCP

フレームワーク
なし（boto3直接）
Strands

実行環境
AWS マネージド
AgentCore Runtime（microVM）

UI
React App（本格的）
Streamlit（シンプル）

カスタマイズ
困難
容易

状態: ✅ 推奨方式（"recommended way" - 2025年9月17日以降）
今回は新方式を選択

 重要な注意事項amazon-bedrock-agents-healthcare-lifesciencesのREADMEに記載されている重要な注意事項:
Legal Notes より引用:

"This solution is for demonstrative purposes only. It is not for clinical use and is not a substitute for professional medical advice, diagnosis, or treatment. The associated notebooks, including the trained model and sample data, are not intended for production."
"このソリューションはデモンストレーション目的のみです。臨床使用を目的としておらず、専門的な医療アドバイス、診断、治療の代替ではありません。関連するノートブック（学習済みモデルやサンプルデータを含む）は、本番環境での使用を想定していません。"

認証方式	用途	認証情報	使用例
IAM	開発者・管理者	AWS CLI の認証情報	`agentcore invoke` コマンド
OAuth	エンドユーザー	Cognito ログイン	Streamlit UI（`app_oauth.py`）

項目	旧方式	新方式
API	Amazon Bedrock Agents	Amazon Bedrock AgentCore
エージェント実体	AWS リソース	Docker コンテナ
デプロイ方法	CloudFormation ワンクリック	`agentcore` CLI（6ステップ）
CloudFormation	全部入り（14エージェント）	基盤のみ（S3, Lambda, IAM）
ツール接続	Lambda Action Group	Gateway + MCP
フレームワーク	なし（boto3直接）	Strands
実行環境	AWS マネージド	AgentCore Runtime（microVM）
UI	React App（本格的）	Streamlit（シンプル）
カスタマイズ	困難	容易

アマゾンウェブサービスジャパン (有志)Publication

この Publication に投稿している記事は、アマゾンウェブサービスジャパン合同会社または Amazon Web Services, Inc. 所属社員による個人の見解であり、所属する組織の公式見解ではありません。参加したい従業員の方は、Sugiyama Suguru までお知らせください。

はじめに

AWS Samples

プロジェクト全体の構成

図の説明

②Multi-Agent Collaboration の実例

がんバイオマーカー発見エージェント

本記事の位置付け

AgentCore Template

Strands Agents フレームワーク

Agentic Loop（エージェントループ）

AgentCore Template のアーキテクチャ全体像

1. Amazon Bedrock AgentCore Runtime

2. Amazon Bedrock AgentCore Gateway

3. Amazon Bedrock AgentCore Memory

4. Amazon Bedrock AgentCore Identity

5. Amazon Bedrock AgentCore Observability

AgentCore Template デプロイ手順

このセクションの位置づけ

前提条件（Prerequisites）

1. AWS アカウント

2. AWS CLI のインストールと設定

3. Bedrock モデルアクセスの有効化

4. Python 3.10 以上

デプロイ手順

ステップ0: ツールのカスタマイズ（デプロイ前の準備）

サンプルツールの確認

患者検索ツールの追加

ステップ1: インフラストラクチャのデプロイ

1-1. Python環境のセットアップ（ローカル）

1-2. インフラのデプロイ（CloudFormation）

ステップ2: AgentCore Gateway 作成

ステップ3: AgentCore Identity 設定（Credentials Provider）

ステップ4: AgentCore Memory 作成

ステップ5: Agent Runtime セットアップとデプロイ

5-1. SSM パラメータから値を取得

5-2. Agent Runtime 設定

5-3. Agent Runtime デプロイ

5-4. Agent 動作確認

5-5. Observability（監視機能）

遭遇した問題と解決方法

ステップ6: Streamlit UI の起動

さらに拡張するには

1. Gateway Lambda ツール (prerequisite/lambda/python/)

2. Knowledge Base (prerequisite/docs-rag/)

重要なアップデート情報

技術的な違い

重要な注意事項

Discussion

1. Gateway Lambda ツール (`prerequisite/lambda/python/`)

2. Knowledge Base (`prerequisite/docs-rag/`)