AWSブログリレー：【解説付き】25新卒がAmazon Bedrock AgentCoreを触ってみた!

この記事は2025 Japan AWS Ambassadors に選出されている
クラウドインテグレーション事業部　松田 啓佑さんに監修をいただき執筆しております。

目次

1. はじめに
2. Amazon Bedrock AgentCoreとは？
3. サービス概要
4. 機能について
5. Bedrock AgentCoreのメリット
6. 料金
7. 実際に触れてみた
8. まとめ

1. はじめに

この記事はアイレット25卒社員によるAWSブログリレーのAmazon Bedrock AgentCore編です。
AWSブログリレーでは、これからAWSについて勉強される未経験の方やエンジニア職以外の方向けに1記事1AWSサービスについて解説するブログリレーとなっております。
本記事では、任意のフレームワーク／モデルで作ったエージェントを安全に本番運用へ押し上げる基盤Amazon Bedrock AgentCoreについて、サービス概要から実体験までお話しさせていただきます。

2. Amazon Bedrock AgentCoreについて

1. サービス概要

Amazon Bedrock AgentCore は、任意のフレームワーク／モデルで作ったエージェントを安全にスケール運用できるようにするマネージド基盤です。AI エージェントを強化するツール群、動的に伸縮する実行基盤、信頼性・統治のためのコントロールを提供し、各サービスを独立または組み合わせて利用できます。
対応フレームワーク（例：CrewAI、LangGraph、LlamaIndex、Strands）やBedrock内外のモデルに依存しない柔軟性が特徴です。

2. 機能について

Amazon Bedrock AgentCore は、エージェントの実行を担う Runtime、外部ツール接続を集約する Gateway、代理実行や認可を司る Identity、短期・長期の文脈を保持する Memory、動作を可視化する Observability、ブラウザ操作を安全に行う Browser、コードを隔離実行する Code Interpreterを組み合わせて、本番向けに安全かつ拡張可能なエージェント運用基盤を提供します。

3. Bedrock AgentCoreのメリット

Bedrock AgentCoreの強みは「好きなフレームワークやモデルのまま、エージェントを安全に本番運用へ押し上げる土台」を提供している点です。
実行は専用のRuntimeが担い、サーバレスかつ隔離環境で長時間対話や多並列に耐える設計と待っています。
これにより、アプリ側の実装を極力変えずに、スケール・信頼性・セキュリティの要件をクラウド標準へ寄せられます。また、Gateway で API／Lambda／既存サービス（MCP 準拠ツールを含む）を“発見して安全に使える”形へ標準化し、Identity で OAuth 2.0・API キー・SigV4 などによる認証とユーザー代理実行を一元化することも可能です。これに加え、Observability を有効化することで、CloudWatch のダッシュボードやトレースを通じて実行経路・メトリクス・ログを統合的に把握することも可能です。
Bedrock AgentCoreを使用することで、最終的にネットワーク統制や監査要件を崩さずに検証から本番への移行が軽くなり、将来のフレームワーク差し替えにも耐える運用基盤になることが期待されています。

4. 料金

料金は前払い不要の従量課金で、各機能を必要に応じて組み合わせます。「使った資源・回数にだけ払う」設計が一貫しており、エージェントのI/O待機が多い、ツール呼び出しが突発的に増えるなどといった現実の負荷に合わせてコストを最適化しやすい点が特徴です。
正式な見積もり時は、AgentCoreの料金ページとBedrock全体の料金ページを併せて最新情報を確認してください。

参考元：https://aws.amazon.com/jp/bedrock/agentcore/pricing/

5. 実際に触れてみた

5.1 やってみたこと

今回、Notion公式が提供するMCP Server実装を活用し、AgentCore Runtime環境での運用基盤を構築する形で機能検証を行いました。
今回の検証では、以下2つの技術的課題に焦点を当てております。

課題1：既存MCP実装の効率的な活用
Notion公式が提供するMCP Serverは、Node.js/TypeScriptで実装されています。
これをPythonベースのAgentCore Runtime環境で利用するには、通常であれば全体をPythonで再実装する必要があり、以下の課題が生じる懸念があります。

• 公式実装の継続的なアップデートへの追従コスト
• 機能の完全性を保証するための検証コスト

そこで本検証では、既存のDockerコンテナ化されたMCPサーバーがある場合、AgentCore Runtimeと分離配置することで効率的に統合できるかを実証することを目的としました。
これが実現できれば、公式実装をそのまま活用しながら、AgentCore Runtimeの機能を最大限に引き出すことが可能になります。

課題2：Strands AgentsとAgentCore Runtimeの統合検証
Strands Agentsには、AgentCore RuntimeをToolとして呼び出す機能が存在します。
本検証では、この機能を実際に活用し、以下を確認することを目指しました。

• ローカルで動作するStrands Agentから、AWS上のAgentCore Runtimeを呼び出せるか
• AgentCore Browser（AWS公式提供）とカスタムRuntime（Notion MCP）を同一エージェントで併用できるか
• マルチツール統合時の動作安定性とユーザー体験

これらの検証を通じて、今後のツール拡張における再利用可能な設計パターンを確立することを目指しました。

詳しい実装内容は以下のGithubをご参照ください。
https://github.com/SakutoHata/bedrock-agentcore_withNotionMCP

5.2 アーキテクチャ設計について

5.2.1 設計方針

本構成では、MCP ServerをECS Fargate上に分離配置し、AgentCore RuntimeからはHTTP経由でJSON-RPC通信を行う設計を採用しました。
具体的な理由としては、以下の点が挙げられます。

1. 公式実装をそのまま活用
AgentCore Runtimeは通常Pythonで実装されたツールを内包しますが、Notion公式のMCP ServerはNode.js/TypeScript実装です。
再実装するコストをなくすため、公式Dockerイメージを改変せず利用するようにしました。
これにより、MCPサーバ側のアップデート追従が容易になります。

2. スケーラブルな実行基盤（ECS + Fargate + ECR）

Lambda（タイムアウト・セッション管理の課題）やEC2（運用負荷）と比較し、Fargateは各MCPサーバーごとに最適なリソースを独立設定でき、サーバー管理不要でスケール可能な点で優位性があります。

3. VPC閉域ネットワークによる安定したセッション管理
MCP Serverとの通信にHTTP/JSON-RPCを採用し、内部ALBとVPC内配置を組み合わせることで、以下を実現しました。

• セッションの安定性向上：VPC内の固定エンドポイント経由で接続することで、パブリックインターネット経由と比較してレイテンシが低く、接続断のリスクが軽減されます。MCP Serverの長時間セッションもVPCエンドポイント・内部ALBを経由した安定した通信で維持可能です。
• 統一エンドポイント化：内部ALBのパスベースルーティングにより、複数MCPサーバーを単一エンドポイントで管理できます。

[AgentCore Runtime (VPC内)]
↓
[内部ALB (VPC内・統一エンドポイント)]
├─ /notion/* → Notion MCP (Fargate)
├─ /slack/* → Slack MCP (Fargate)
└─ /github/* → GitHub MCP (Fargate)

4. 将来的なMCPサーバー拡張への対応
この構成の最大の利点は、新しいMCPサーバーを追加する際の拡張性です。
他のMCPサーバーを追加する場合、以下の4ステップで完結します。

1. ECRリポジトリ作成：公式DockerイメージをビルドしてECRにプッシュ
2. ECSタスク・サービス定義：Fargateタスクとして新しいMCPサーバーを起動
3. ALBルーティング追加：パスパターン（例：/slack/*）で新しいMCPサーバーへ振り分け
4. Runtime側クライアント統合：MCPClientFactoryでエンドポイントパスを指定

既存のTerraformコードをテンプレートとして再利用できるため、公式DockerイメージさえあればAgentCore Runtime化が可能です。
また、各MCPサーバーは独立したFargateタスクとして動作するため、リソース設定やスケーリングも個別に最適化できます。

5.2.2 システム構成図

最終的に、ローカルにあるチャットアプリからStrands Agentを経由して、AgentCore RuntimeをMCPとして呼び出し、AgentCore Browserと組み合わせて横断的なタスクが実行可能になるような構想です。

5.3 実装内容

5.3.1 閉域ネットワーク基盤の構築

まず、AgentCore RuntimeとMCP Serverが安全に通信できる環境をTerraformで構築しました。
プライベートサブネット内にRuntimeとMCP Serverを配置し、NAT Gateway経由で外部のNotion APIにアクセスする構成です。

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(
    local.common_tags,
    {
      Name = "${var.project_name}-vpc"
    }
  )
}

ECR、CloudWatch Logs、Secrets Manager用のVPCエンドポイントを配置することで、イメージのPullや認証情報の取得を閉域内で完結させています。

resource "aws_vpc_endpoint" "ecr_dkr" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.${local.region}.ecr.dkr"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.vpc_endpoints.id]
  private_dns_enabled = true

  tags = merge(
    local.common_tags,
    {
      Name = "${var.project_name}-ecr-dkr-endpoint"
    }
  )
}

また、内部ALBを配置してMCP Serverへのアクセスを統一エンドポイント化しました。

resource "aws_lb" "main" {
  name               = "${var.project_name}-mcp-alb"
  internal           = true # Private ALB
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = aws_subnet.private[*].id

  enable_deletion_protection = false
  enable_http2               = true

  tags = merge(
    local.common_tags,
    {
      Name = "${var.project_name}-mcp-alb"
    }
  )
}

# Target Group - Notion MCP
resource "aws_lb_target_group" "notion_mcp" {
  name        = "${var.project_name}-notion-mcp"
  port        = 8000
  protocol    = "HTTP"
  vpc_id      = aws_vpc.main.id
  target_type = "ip"

  health_check {
    enabled             = true
    healthy_threshold   = 2
    interval            = 30
    matcher             = "200-399"
    path                = "/health"
    port                = "traffic-port"
    protocol            = "HTTP"
    timeout             = 5
    unhealthy_threshold = 5
  }

  deregistration_delay = 30

  tags = local.common_tags
}
...
# Listener - Port 8000 (Notion MCP)
resource "aws_lb_listener" "notion_mcp" {
  load_balancer_arn = aws_lb.main.arn
  port              = "8000"
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.notion_mcp.arn
  }
}

これにより、将来的に複数のMCPサーバーを追加する際も、既存の構成を活かせます。

5.3.2 既存Docker実装の活用とRuntime構築

Notion MCP Serverのコンテナ化
公式リポジトリのDockerfileをそのまま利用しました。マルチステージビルドで本番環境に必要な依存のみを含むイメージを構築できるため、アップデート時はベースイメージを更新してビルドするだけです。

AgentCore Runtimeの実装
Python側で実装が必要なのは、MCP Serverとの通信レイヤーのみです。
JSON-RPCクライアントを実装し、HTTP経由でMCP Serverと通信できるようにしました。

class NotionMCPClient:
    def __init__(self, endpoint: str) -> None:
        self.endpoint = endpoint.rstrip('/')
        self.session_id: Optional[str] = None

    async def _send_request(self, method: str, params: Dict[str, Any]) -> Dict[str, Any]:
        payload = {
            "jsonrpc": "2.0",
            "id": str(uuid.uuid4()),
            "method": method,
            "params": params,
    }
    ...

セッション管理とタイムアウト（60秒）を組み込むことで、Notion API側の遅延にも対応しています。
Strandsツールの定義では、@toolデコレータで型ヒント付きの関数を作成しました。

def create_notion_tools():
    """Create Strands Tools for Notion MCP"""
    tools = []

    @tool
    async def create_notion_page(
        title: str,
        content: Optional[str] = None,
        parent_id: Optional[str] = None
    ) -> str:

        try:
            # Use default parent_id from environment if not provided
            if not parent_id:
                parent_id = os.environ.get("NOTION_DEFAULT_PARENT_ID")
                if not parent_id:
                    return json.dumps({
                        "success": False,
                        "error": "parent_id is required (NOTION_DEFAULT_PARENT_ID not set)"
                    }, ensure_ascii=False)

            arguments = {
                "parent_id": parent_id,
                "title": title
            }

            if content:
                arguments["content"] = content
                ...

環境変数でデフォルトページを指定できるようにし、これをAgentCore Runtimeにデプロイしてinvoke_agent_runtime API経由で呼び出せる状態にします。

5.3.3 マルチツール統合と動作検証

ここからが本検証の本題です。ローカルで動作するStrands Agentから、AgentCore Browser（AWS公式）とNotion MCP（カスタムRuntime）の両方を呼び出せるようにします。

ツールの統合
Browserツールはstrands_agents_toolsから直接インポートし、Notionツールはboto3のbedrock-agentcoreクライアントでinvoke_agent_runtimeを呼び出すラッパークラスとして実装しました。

from strands import Agent
from strands_tools.browser import AgentCoreBrowser  # AWS公式Browser (from strands-agents-tools package)

# Notion MCPを直接importする（パッケージの競合を避けるため）
import importlib.util
notion_spec = importlib.util.spec_from_file_location(
    "notion_mcp_custom",
    str(Path(__file__).parent.parent / ".aws_agentcore_runtime" / "tools" / "strands_tools" / "notion.py")
)
notion_module = importlib.util.module_from_spec(notion_spec)
notion_spec.loader.exec_module(notion_module)
AgentCoreNotion = notion_module.AgentCoreNotion  # カスタムNotion MCP (from .aws_agentcore_runtime/)

print("✅ Libraries imported successfully!")

def create_agent():

    # Tool 1: AWS Official Browser (aws.browser.v1)
    print("[Tool 1] Initializing AgentCoreBrowser (AWS Official)...")
    agent_core_browser = AgentCoreBrowser(region="ap-northeast-1")
    print("  ✅ AWS Official Browser ready")

    # Tool 2: Notion MCP (AgentCore Runtime)
    print("[Tool 2] Initializing AgentCoreNotion (Runtime)...")
    notion_mcp = AgentCoreNotion(
        region="ap-northeast-1",
        runtime_id="notion_mcp_standalone-40NmvE5Zay"
    )
    print("  ✅ Notion MCP ready (Runtime: notion_mcp_standalone-40NmvE5Zay)")

    # Create agent with AWS Browser + Notion tools
    print("[Agent] Creating Strands Agent...")
    agent = Agent(
        tools=[agent_core_browser.browser, notion_mcp.notion],
        system_prompt="..."
    )
    ...
    return agent

# Initialize agent globally
strands_agent = create_agent()

これにより、ローカルのStrands AgentからAWS上のカスタムRuntimeを透過的に利用できます。

Streamlit UIの構築
動作確認用のチャットUIをStreamlitで構築しました。@st.cache_resourceでRuntime一覧をキャッシュし、リージョンやRuntimeをUIから切り替えられるようにしています。
実際にプロンプトを実行すると、BrowserツールとNotionツールを統合したAgentが動的に生成され、「Web検索→情報整理→Notionへ保存」という一連のフローが実行されます。

動作例
試しに「アイレット株式会社について調べて、Notionにまとめて」というプロンプトを実行してみました。
AgentはまずBrowserツールで公式サイトや会社情報を収集し、その結果をもとにNotionツールで自動的にページを作成しました。
この例では、AWS公式のBrowserと、今回構築したカスタムRuntimeのNotion MCPが協調動作し、2つの異なるRuntimeがシームレスに連携できることを実証できました。

実際にチャットを行うと以下のようにUIでは表示され

Notionでの記載が成功していることが確認できました。

実行前：

実行後：

※Strands Agentのログ

🚀 Starting analysis...
アイレット株式会社について調べて、情報をまとめさせていただきます。まず、ブラウザを使って公式サイトや関連情報を収集します。

Tool #1: browser
Tool #2: browser
正確な会社名で検索してみます。

Tool #3: browser
...
Tool #6: browser
検索結果が読み込まれているようです。正しい会社名のURLを探してみます。

Tool #7: browser
...
Tool #11: browser
素晴らしい情報が得られました！アイレット株式会社について詳しい情報を取得できました。続けて会社情報のページにアクセスして、より詳細な企業情報を収集します。

Tool #12: browser
会社情報へのリンクを直接探してみます。
...
Tool #16: browser

収集した情報をもとに、Notionにアイレット株式会社についてのページを作成して整理します。

Tool #17: notion

## アイレット株式会社についての調査結果

アイレット株式会社について調査し、Notionにまとめました。主なポイントは以下の通りです：

### 企業概要
- **会社名**: アイレット株式会社（iret, Inc.）
- **主力サービス**: cloudpack（クラウドパック）
- **事業内容**: AWS、Google Cloud、Oracle Cloud Infrastructureの総合支援

### 特筆すべき実績・認定
1. **AWSプレミアティアサービスパートナー**として11年連続認定
2. **日本初**のAPNプレミアコンサルティングパートナー（2013年認定）
3. 世界で150社、日本でわずか15社しかない認定企業
4. AWS認定資格保有者が**2,000名超**
5. **2,500社以上**の支援実績

### 主要サービス
- **AWS総合支援**: 請求代行（最大10%割引）、運用・保守、構築、定額プラン
- **Google Cloud総合支援**: 請求代行、監視・運用、AI導入支援
- **OCI総合支援**: 請求代行、導入・移行支援、監視・運用
- **生成AI導入支援**: 各クラウドプラットフォームでのAI活用支援

### 特徴
- 24時間365日の監視・障害対応
- 日本円での月額定額制に対応
- 請求書払いに対応
- 無料の導入相談会を定期開催

アイレット株式会社は、日本のクラウド業界における先駆者的存在として、企業のデジタル変革を技術・運用の両面から包括的に支援する専門企業であることがわかりました。

5.4 検証結果と考察

5.4.1 達成できたこと

今回の検証を通じて、以下の4点を確認できました。

既存Docker実装の効率的な活用
Notion公式のMCP ServerをDockerfileごとそのまま利用し、Pythonへの再実装を避けることができました。
アップデート時はDockerビルドだけで済むため、公式の更新に追従しやすく、AgentCore Runtimeの恩恵も受けられます。

Strands Agents統合の実現
ローカルで動作するStrands Agentからinvoke_agent_runtime APIを使ってAgentCore Runtimeを呼び出し、AgentCore Browserと併用できることを実証しました。
AWS公式ツールとカスタムツールをシームレスに統合する設計パターンが確立できたと考えています。

セキュリティと拡張性の両立
ECS Fargateでの分離配置とVPCエンドポイントによる閉域化により、RuntimeとMCP Serverを独立してスケールさせながら、セキュリティも確保できました。
AgentCore標準のGateway、Identity、Browser、Observabilityといった機能とも統合できています。

インフラの再現性
Terraformで一貫管理することで、構成の再現性と整合性を担保できました。
デプロイスクリプトと合わせて、環境構築を自動化できる形になっています。

5.4.2 今後の展望

本検証で最も重要なのは、公式DockerイメージさえあればAgentCore Runtime化できるという汎用的なパターンを確立できた点です。
今後は、必要に応じて他のMCPサーバーも同様に統合できることがわかりました。
また、内部ALBによるパスベースルーティングで複数MCPサーバーを動的に振り分けたり、Runtime間で相互通信してより高度なワークフローを構築したりと、様々な拡張が見込めます。
この設計パターンが、今後のツール拡張における再利用可能な基盤になることを期待しています。

6. まとめ

いかがでしたでしょうか。AgentCore は、手元のフレームワーク／モデルをそのまま活かしつつ、安全に本番運用へ押し上げる“土台”として有効だと確認できました。
今回は Notion MCP を改変せず取り込み、 Runtimeで運用する構成を Terraform で実装し、更新追随・独立スケール・再現性を検証しました。
あわせて、コストはツール呼び出しやメモリ利用に直結するため、観測に基づくチューニングを前提に設計する重要性も理解いただけたのではないでしょうか。
本記事が、AgentCore の実運用設計や MCP 連携を考える皆さまの一助になれば幸いです。
最後までお読みいただき、ありがとうございました。