コンテンツにスキップ
これは最新の機能を備えた最新リリースですが、長期サポートは提供されません。サポートを継続するには、新しいリリースごとにアップグレードするか、四半期ごとの安定版リリースをご利用ください。

For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

AWS Bedrock AgentCore

Page as Markdown
Solo Enterprise for agentregistry を AWS Bedrock AgentCore ランタイムに接続し、エージェントと MCP サーバーを AgentCore にデプロイできるようにします。
このガイドでは、Solo Enterprise for agentregistry を AWS Bedrock AgentCore に接続し、レジストリからエージェントと MCP サーバーを AgentCore にデプロイできるようにする方法を説明します。完了すると、レジストリを AgentCore 環境に向ける Runtime リソースと、レジストリとデプロイ済みワークロードの間でトラフィックをルーティングするマネージドゲートウェイが用意されます。
始める前に

  1. OIDC プロバイダーをセットアップします。このガイドでは、Keycloak をインストール済みであることを前提とします。General setup タブに従って、必要なレルム設定、クライアント、シークレットを含めて Keycloak をインストールしてください。
  2. Solo Enterprise for agentregistry を Amazon EKS にインストールします。インストール後、現在のターミナルセッションで次の環境変数が設定されていることを確認します。
    echo "AWS_REGION: $AWS_REGION"
echo "AWS_ACCOUNT_ID: $AWS_ACCOUNT_ID"
echo "KEYCLOAK_ISSUER: $KEYCLOAK_ISSUER"
  3. オプション: エージェントと MCP サーバー間の通信を支援し、ランタイム認可ポリシーを適用するためにマネージドゲートウェイを作成する場合は、Solo Enterprise for agentgateway のライセンスキーを取得します。キーを取得するには、アカウント担当者にお問い合わせください。
ステップ 1: ランタイム IAM ロールを設定する

CloudFormation テンプレートを生成し、アカウントにデプロイします。このテンプレートは、Solo Enterprise for agentregistry がユーザーに代わって Bedrock AgentCore リソースをデプロイおよび管理するために引き受ける IAM ロールと、必要なすべての IAM ポリシーを作成します。これらのポリシーには、Solo Enterprise for agentregistry が AgentCore にデプロイするエージェントと MCP サーバーのバンドルをステージングするために作成する S3 ソースバケットへのアクセスが含まれます。バケット名は are-<partition>-<hash>-<account-id>-<region> です。また、以前のバージョンで作成されたインストールが引き続き機能するように、テンプレートは以前のバージョンで使用されていた bedrock-agentcore-codebuild-sources-* と agentcore-* のバケット名も許可します。CloudFormation を使用すると、アカウントに作成されるすべてのリソースについて、レビューと監査が可能な定義を得られます。
  1. AWS CloudFormation テンプレートを生成し、YAML ファイルに保存します。このテンプレートは、指定したアカウント ID にスコープされ、次の部分で構成される単一の IAM ロールを定義します。
    • 信頼ポリシーは、ロールを引き受けられる主体を制御します。このポリシーは特定のユーザーやロールではなく AWS アカウント全体を信頼するため、EKS に Solo Enterprise for agentregistry をインストールしたときに選択した ID オプションに関係なく、同じテンプレートを使用できます。AWS は、次の条件が満たされた場合にのみ assume-role 呼び出しを許可します。呼び出し元 ID 自身のポリシーが、EKS インストール時に付与した sts:AssumeRole 権限を許可していること、かつ呼び出しにロールと一致する External ID が含まれていることです。External ID は arctl がこのロール用に生成して信頼ポリシーに埋め込むシークレット値であるため、ロール ARN へのアクセスを得た人でも、External ID も渡さなければロールを引き受けることはできません。Solo Enterprise for agentregistry は、ステップ 2 で Runtime リソースに追加する値に基づいて、各呼び出しで External ID を送信します。
    • 権限ポリシーは、ロールが実行できる操作を制御します。このロールには、AWS 管理の BedrockAgentCoreFullAccess ポリシーと、AgentCore デプロイにも必要な S3、CloudWatch、Cognito、IAM アクセス用のインライン BedrockAgentCoreSupplementalAccess ポリシーがアタッチされます。
    • スタック出力は、後の手順で取得するロール ARN と External ID です。
    arctl runtime setup bedrock-agent-core --aws-account-id $AWS_ACCOUNT_ID > cloudformation.yaml
    Note
    デフォルトでは、テンプレートが生成するロールの名前は AgentRegistryAccessRole-<suffix> です。サフィックスは 6 桁のランダムな 16 進文字で構成されます。AWS アカウントの命名規則に合わせるなど、自分でロール名を付けるには、--role-name オプションを含めます。後でこのスタック用にテンプレートを再生成する場合に同じ名前を再度渡す必要があるため、選択した名前を控えておいてください。
    External ID と Role Name は CLI 出力に表示され、cloudformation.yaml ファイルにも埋め込まれます。ただし、External ID パラメーターには NoEcho: true が指定されているため、スタックを describe したりコンソールで表示したりすると、AWS によってマスクされます。後で使用できるように、この時点で CLI 出力から External ID を必ず控えておいてください。
    出力例:
    # External ID: NzqfvveAy0XSEsL4ZtKcHR1li-3puJAbipQDQG8ylmg
# Role Name: AgentRegistryAccessRole-a11111

  2. External ID を環境変数に保存します。<external-id> は、前の手順の値に置き換えます。
    export AWS_EXTERNAL_ID="<external-id>"
  3. オプション: デプロイする前にテンプレートを確認します。
    cat cloudformation.yaml
  4. CloudFormation スタックをデプロイします。
    1. スタックの名前を選択します。
      export STACK_NAME="<stack-name>"
    2. AWS スタックを作成します。このテンプレートは IAM ロールを作成するため、--capabilities CAPABILITY_NAMED_IAM フラグが必要です。CloudFormation テンプレートが IAM リソースを作成する場合、AWS は明示的な承認を求めます。コマンドが成功すると、CLI 出力に StackId と OperationId が表示されます。
      aws cloudformation create-stack \
  --stack-name $STACK_NAME \
  --template-body file://cloudformation.yaml \
  --region $AWS_REGION \
  --capabilities CAPABILITY_NAMED_IAM
      出力例:
      {
  "StackId": "arn:aws:cloudformation:us-west-2:1234567890:stack/agentregistry-cli-stack/1a1aaa11-1111-11a1-aa11-1111a1111aa1",
  "OperationId": "1aaa1a1a-1111-11aa-1a1a-1aaa11a1a111"
}

    3. スタックが CREATE_COMPLETE になるまで待ちます。
      aws cloudformation wait stack-create-complete \
  --stack-name $STACK_NAME \
  --region $AWS_REGION
  5. CloudFormation テンプレートによって作成された IAM ロールの RoleArn を環境変数に保存します。Solo Enterprise for agentregistry はこのロールを引き受けて、AWS アカウント内の Bedrock AgentCore リソースをデプロイおよび管理します。
    export AWS_ROLE_ARN=$(aws cloudformation describe-stacks \
  --stack-name $STACK_NAME \
  --query 'Stacks[0].Outputs[?OutputKey==`RoleArn`].OutputValue' \
  --output text \
  --region $AWS_REGION)
echo $AWS_ROLE_ARN
    Note
    以前のバージョンの arctl でこのスタックをデプロイした場合は、Solo Enterprise for agentregistry が AgentCore にデプロイするエージェントと MCP サーバーのバンドルをステージングするために作成する arn:aws:s3:::are-* ソースバケットへのアクセスも IAM ロールに付与するよう、スタックを更新します。この許可がないと、レジストリサーバーがバケットの作成を拒否されるため、AgentCore へのデプロイは Ready=False 状態のままになります。

    テンプレートを再生成するときは、スタックがすでに作成したロールの名前を --role-name フラグで渡し、既存の External ID を UsePreviousValue=true で保持します。そうしないと、arctl が新しいロール名と External ID を生成し、IAM ロールが置き換えられ、Runtime リソースが依存する信頼ポリシーが無効になります。
    arctl runtime setup bedrock-agent-core \
  --aws-account-id $AWS_ACCOUNT_ID \
  --role-name <existing-role-name> > cloudformation.yaml

aws cloudformation update-stack \
  --stack-name $STACK_NAME \
  --template-body file://cloudformation.yaml \
  --parameters ParameterKey=ExternalId,UsePreviousValue=true \
  --region $AWS_REGION \
  --capabilities CAPABILITY_NAMED_IAM

aws cloudformation wait stack-update-complete \
  --stack-name $STACK_NAME \
  --region $AWS_REGION
  6. オプション: AWS アカウントでアウトバウンド Web ID フェデレーションを有効にします。この機能を有効にすると、AgentCore にデプロイするエージェントは、自分がどのエージェントであるかを証明する短期トークンを AWS から要求できます。Solo Enterprise for agentregistry は、IAM ロールが付与する iam:GetOutboundWebIdentityFederationInfo 権限を使用してアカウントのトークン発行者を検索し、マネージドゲートウェイが各エージェントのトークンをその発行者に対して検証します。これにより、ゲートウェイはエージェントを識別し、エージェントごとにアクセスポリシーを適用できます。
    aws iam enable-outbound-web-identity-federation
ステップ 2: AgentCore ランタイムを登録する

AWS Bedrock AgentCore ランタイムを Solo Enterprise for agentregistry に登録します。このランタイムは、レジストリサーバーを AWS アカウントに接続し、エージェントと MCP サーバーを Bedrock AgentCore にデプロイできるようにします。
  1. OpenTelemetry コレクターのロードバランサーホスト名を取得します。レジストリは、コントロールプレーンとあわせて OTel コレクターをデプロイします。エージェントと MCP サーバーのランタイムは、このエンドポイントを使用してトレースとメトリクスをエクスポートします。
    export OTEL_HOST=$(kubectl -n agentregistry-system get svc \
  agentregistry-enterprise-telemetry-collector \
  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
echo "OTel endpoint: http://${OTEL_HOST}:4318"
  2. AWS Bedrock AgentCore ランタイムを登録します。
    arctl apply -f- <<EOF
apiVersion: ar.dev/v1alpha1
kind: Runtime
metadata:
  name: agentcore
spec:
  type: BedrockAgentCore
  telemetryEndpoint: http://${OTEL_HOST}:4318
  config:
    roleArn: $AWS_ROLE_ARN
    externalId: $AWS_EXTERNAL_ID
    region: $AWS_REGION
EOF
    出力例:
    ✓ Runtime/agentcore created

  3. Solo Enterprise for agentregistry に接続されているランタイムの一覧を表示し、Bedrock AgentCore ランタイムが含まれていることを確認します。
    arctl get runtimes
    出力例:
    NAME                 TYPE
agentcore            BedrockAgentCore
kubernetes-default   kubernetes
local                local

ステップ 3: マネージドゲートウェイを作成する (任意)

Bedrock AgentCore は、各エージェントと MCP サーバーを、これらのランタイム間やランタイムから EKS クラスターへのネットワークパスがない分離されたマネージドランタイムとして実行します。AgentCore 内のエージェントと MCP サーバー間のルーティングを有効にし、実行時にエージェントがアクセスできる対象を制限するには、マネージドゲートウェイを作成します。
ゲートウェイは、MCP とエージェントを認識するプロキシである Solo Enterprise for agentgateway を基盤とし、Kubernetes Gateway API によって支えられています。マネージドゲートウェイを作成する前に、EKS クラスターに両方のコンポーネントをインストールしておく必要があります。AgentCore ランタイムアーキテクチャ全体におけるゲートウェイの位置付けについて詳しくは、ランタイムアーキテクチャを参照してください。
Note
どのような場合にゲートウェイが必要ですか。
  • AgentCore にデプロイされた MCP サーバー: AgentCore にデプロイされた MCP サーバーは、パブリックエンドポイントを持たない分離されたコンピューティング環境で実行されます。エージェントは、ランタイム間のトラフィックをプロキシするマネージドゲートウェイ経由でのみ、それらに到達できます。
  • RuntimeAccessPolicies: ゲートウェイは RuntimeAccessPolicy リソースを適用し、実行時にエージェントが他のエージェントを呼び出したり、特定の MCP サーバーツールにアクセスしたりできるかどうかを制御します。詳細については、エージェントから MCP サーバーへを参照してください。
Runtime に spec.config.gatewayRef を設定すると、レジストリはパブリック URL のリモート MCP サーバーを含む すべての MCP サーバー URL を、ゲートウェイ経由でルーティングされるように書き換えます。エージェントがパブリック MCP サーバーにのみ接続し、RuntimeAccessPolicy の適用が不要な場合は、このステップをスキップし、Runtime から gatewayRef フィールドを省略してください。
  1. Solo Enterprise for agentgateway をインストールします。このインストールにより、マネージドゲートウェイが使用する enterprise-agentgateway GatewayClass が作成されます。
    1. Solo Enterprise for agentgateway のライセンスキーを環境変数に保存します。キーを取得するには、アカウント担当者にお問い合わせください。
      export AGENTGATEWAY_LICENSE_KEY=<agentgateway-license-key>
    2. Solo Enterprise for agentgateway のバージョンを設定します。
      export AGENTGATEWAY_VERSION=v2026.9.3
    3. Gateway、HTTPRoute、および関連リソースを含む標準 Gateway API CRD をインストールします。
      kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.1/standard-install.yaml
    4. Solo Enterprise for agentgateway CRD をインストールします。
      helm upgrade -i enterprise-agentgateway-crds \
  oci://us-docker.pkg.dev/solo-public/enterprise-agentgateway/charts/enterprise-agentgateway-crds \
  --create-namespace \
  --namespace agentgateway-system \
  --version "${AGENTGATEWAY_VERSION}"
    5. Solo Enterprise for agentgateway のコントローラーとデータプレーンをインストールします。
      helm upgrade -i enterprise-agentgateway \
  oci://us-docker.pkg.dev/solo-public/enterprise-agentgateway/charts/enterprise-agentgateway \
  -n agentgateway-system \
  --version "${AGENTGATEWAY_VERSION}" \
  --set-string licensing.licenseKey="${AGENTGATEWAY_LICENSE_KEY}"
    6. コントロールプレーン Pod が実行中であることを確認します。
      kubectl get pods -n agentgateway-system
      出力例:
      NAME                                                     READY   STATUS    RESTARTS   AGE
enterprise-agentgateway-controller-7d9f8b6d4c-xvpzk     1/1     Running   0          45s

  2. マネージドゲートウェイを作成します。Gateway リソースは、Kubernetes Gateway API に基づく Gateway に変換され、Solo Enterprise for agentgateway が導入した enterprise-agentgateway GatewayClass を使用します。
    arctl apply -f- <<EOF
apiVersion: ar.dev/v1alpha1
kind: Gateway
metadata:
  name: gateway-agentcore
spec:
  kubernetes: {}
EOF
    出力例:
    ✓ Gateway/gateway-agentcore created

  3. ゲートウェイが phase=ready になるまで待ちます。
    arctl get gateways
    PHASE 列に ready が表示されるまで、1 分ごとにこのコマンドを繰り返します。
    NAME               PROVIDER   MODE      PHASE
gateway-agentcore  agentcore  managed   ready

    Note
    ゲートウェイが phase=failed になった場合は、arctl get gateway gateway-agentcore -o yaml でゲートウェイの詳細を確認し、エラーメッセージを調べます。
  4. ゲートウェイプロキシ Pod が作成され、実行中であることを確認します。レジストリは Solo Enterprise for agentregistry のインストールネームスペースに基盤となる Kubernetes Gateway リソースを作成し、Solo Enterprise for agentgateway はそれを Gateway と同じ名前の Deployment として調整します。
    kubectl get pods -n agentregistry-system -l gateway.networking.k8s.io/gateway-name=gateway-agentcore
    出力例:
    NAME                                 READY   STATUS    RESTARTS   AGE
gateway-agentcore-64c4bf7c4c-gzfhj   1/1     Running   0          93s

  5. 作成したゲートウェイを spec.config.gatewayRef フィールドで参照するよう Runtime を更新します。
    arctl apply -f- <<EOF
apiVersion: ar.dev/v1alpha1
kind: Runtime
metadata:
  name: agentcore
spec:
  type: BedrockAgentCore
  telemetryEndpoint: http://${OTEL_HOST}:4318
  config:
    roleArn: $AWS_ROLE_ARN
    externalId: $AWS_EXTERNAL_ID
    region: $AWS_REGION
    gatewayRef:
      name: gateway-agentcore
EOF
    フィールド説明
    spec.config.gatewayRef.nameこの Runtime にアタッチする Gateway リソースの名前です。同じネームスペースに存在する必要があります。設定すると、レジストリはすべてのエージェント MCP サーバー URL をゲートウェイ経由でルーティングするように書き換えます。
ステップ 4: ハーネスランナーを設定する (ハーネスエージェントのみ)

ハーネスエージェントを AgentCore にデプロイする場合は、使用するハーネスタイプごとに Runtime でハーネスランナーイメージを設定する必要があります。ハーネスエージェントは、レジストリカタログに追加したプラグイン、スキル、システムプロンプトから構成されるエージェントです。独自のエージェントコードを実行する代わりに、レジストリは事前ビルド済みのハーネスランナーコンテナを AgentCore にデプロイし、そのコンテナがエージェントを組み立てて実行します。サポートされるハーネスタイプは Claude Code と OpenClaw の 2 つです。
ハーネスランナーについて

ハーネスランナーは、起動時にレジストリからエージェント定義で定義されたコンポーネントを受け取り、それらをハーネス用に設定するコンテナです。
  • Plugins はプラグインディレクトリとしてマウントされます。各プラグインは、会話中にハーネスが呼び出せるスラッシュコマンドを追加します。
  • Skills はハーネス設定ディレクトリにリンクされ、利用可能なワークフローとして自動検出されます。
  • Instructions はワークスペースのシステムプロンプトファイルに書き込まれ、セッション開始時に読み込まれます。
  • MCP servers は、MCP サーバー定義に追加した URL で設定されます。ハーネスエージェントが AgentCore にデプロイされた MCP サーバーと通信するには、エージェントと MCP サーバー間のルーティングを支援するマネージドゲートウェイを設定し、Runtime の spec.config.gatewayRef フィールドでそのゲートウェイを参照する必要があります。gatewayRef を設定すると、すべての MCP サーバー URL は代わりにゲートウェイ経由でルーティングされるように書き換えられます。
  • Model は、Model カタログエントリの spec.model フィールドを使用してハーネスに渡されます。
エージェント固有のコンポーネントに加えて、各ハーネスランナーにはハーネスの組み込み機能が含まれます。Claude Code では、ソフトウェアエンジニアリングツール (コードの読み取り、書き込み、編集、シェルコマンドの実行、コードベースの検索)、組み込みスラッシュコマンド (/code-review、/deep-research、/security-review など)、git と GitHub の操作が含まれます。
Note
AgentCore では、各ハーネスイメージをランタイムと同じ AWS アカウントおよびリージョン内のプライベート ECR リポジトリに保存する必要があります。 レジストリはランタイム作成時に ECR イメージ URI を AgentCore に渡し、AgentCore の実行ロールはその特定のリポジトリへのプルアクセスを許可します。

ハーネスイメージ自体には、プラグイン、スキル、指示、MCP 設定ではなく、ハーネスバイナリのみが含まれます。レジストリは、エージェントのカタログ定義からそれらをバンドルアーカイブにパッケージ化し、ステップ 1 で AgentCore ソースアーティファクト用にすでに作成した同じ S3 バケットにアップロードします。起動時に、ハーネスランナーはこのバンドルをダウンロードして検証し、エージェントを組み立てます。このバケットを自分で作成または管理する必要はありません。
ハーネスランナーイメージを設定する

使用するハーネスタイプごとに、次の手順を繰り返します。
  1. ハーネスランナーイメージ用のプライベート ECR リポジトリを作成します。
    aws ecr create-repository \
  --repository-name agentregistry/agentcore-claude-runner \
  --region $AWS_REGION
    aws ecr create-repository \
  --repository-name agentregistry/agentcore-openclaw-runner \
  --region $AWS_REGION
    出力例:
    {
  "repository": {
    "repositoryUri": "802411188784.dkr.ecr.us-east-1.amazonaws.com/agentregistry/agentcore-claude-runner",
    ...
  }
}

  2. リポジトリ URI を環境変数に保存します。
    export CLAUDE_HARNESS_IMAGE_REPO=$(aws ecr describe-repositories \
  --repository-names agentregistry/agentcore-claude-runner \
  --region $AWS_REGION \
  --query 'repositories[0].repositoryUri' \
  --output text)
echo $CLAUDE_HARNESS_IMAGE_REPO
    export OPENCLAW_HARNESS_IMAGE_REPO=$(aws ecr describe-repositories \
  --repository-names agentregistry/agentcore-openclaw-runner \
  --region $AWS_REGION \
  --query 'repositories[0].repositoryUri' \
  --output text)
echo $OPENCLAW_HARNESS_IMAGE_REPO
  3. Docker を ECR レジストリに認証します。
    aws ecr get-login-password --region $AWS_REGION \
  | docker login --username AWS --password-stdin \
    ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com
  4. 公開済みのハーネスランナーイメージをプルし、ECR リポジトリにプッシュします。<published-image> は Solo アカウントチームから提供されたハーネスランナーイメージ参照に、<tag> はバージョンタグに置き換えます。
    export CLAUDE_HARNESS_IMAGE_TAG="<tag>"
docker pull <claude-published-image>
docker tag <claude-published-image> ${CLAUDE_HARNESS_IMAGE_REPO}:${CLAUDE_HARNESS_IMAGE_TAG}
docker push ${CLAUDE_HARNESS_IMAGE_REPO}:${CLAUDE_HARNESS_IMAGE_TAG}
export CLAUDE_HARNESS_IMAGE_REF="${CLAUDE_HARNESS_IMAGE_REPO}:${CLAUDE_HARNESS_IMAGE_TAG}"
echo $CLAUDE_HARNESS_IMAGE_REF
    export OPENCLAW_HARNESS_IMAGE_TAG="<tag>"
docker pull <openclaw-published-image>
docker tag <openclaw-published-image> ${OPENCLAW_HARNESS_IMAGE_REPO}:${OPENCLAW_HARNESS_IMAGE_TAG}
docker push ${OPENCLAW_HARNESS_IMAGE_REPO}:${OPENCLAW_HARNESS_IMAGE_TAG}
export OPENCLAW_HARNESS_IMAGE_REF="${OPENCLAW_HARNESS_IMAGE_REPO}:${OPENCLAW_HARNESS_IMAGE_TAG}"
echo $OPENCLAW_HARNESS_IMAGE_REF
  5. ハーネスイメージ参照を含めるように Runtime リソースを更新します。設定したハーネスタイプごとに 1 つのエントリを追加します。この Runtime に対して初めてハーネスエージェントをデプロイすると、レジストリは AgentCore 実行ロールのスコープを自動的に設定し、構成済みの ECR リポジトリからプルできるようにします。
    arctl apply -f- <<EOF
apiVersion: ar.dev/v1alpha1
kind: Runtime
metadata:
  name: agentcore
spec:
  type: BedrockAgentCore
  telemetryEndpoint: http://${OTEL_HOST}:4318
  config:
    roleArn: $AWS_ROLE_ARN
    externalId: $AWS_EXTERNAL_ID
    region: $AWS_REGION
    harnessImages:
      claude-code: "${CLAUDE_HARNESS_IMAGE_REF}"
      openclaw: "${OPENCLAW_HARNESS_IMAGE_REF}"
    gatewayRef:
      name: gateway-agentcore
EOF
    フィールド説明
    spec.config.harnessImages.claude-codeClaude Code ハーネスランナーの ECR イメージ URI です。
    spec.config.harnessImages.openclawOpenClaw ハーネスランナーの ECR イメージ URI です。
次のステップ


BYO エージェント
エージェントをスキャフォールドしてレジストリカタログに追加し、Solo Enterprise for kagent へのデプロイを開始できるようにします。
ハーネスエージェント
プラグイン、スキル、指示からエージェントを構成し、AWS Bedrock AgentCore にデプロイします。

MCP サーバー
Solo Enterprise for agentregistry で MCP サーバーを作成、ビルド、公開、実行します。
Azure AI Foundry