翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
CLI または SDK AWS を使用してインスタンスの使用を開始する
このチュートリアルでは、 AWS コマンドラインインターフェイス (AWS CLI) と SDKs を使用して、インスタンスコンピューティングタイプでエージェントをホストする方法について説明します。まず、Amazon Elastic Compute Cloud (Amazon EC2) インフラストラクチャを定義するキャパシティープロバイダーを作成し、それを使用するエージェントランタイムを作成して、最後にエージェントを呼び出します。
前提条件については、「インスタンスの使用を開始する」を参照してください。
注記
これらの例のパラメータ名は、AgentCore コントロールプレーンモデルに従います。信頼できるリクエストとレスポンスの形状については、「Amazon Bedrock AgentCore Control API リファレンス」を参照してください。
ステップ 1: キャパシティープロバイダーを作成する
CreateCapacityProvider オペレーションを使用して EC2 インフラストラクチャを定義します。リクエストは、 permissionsConfiguration (AgentCore がキャパシティープロバイダーの運用に使用する IAM ロール) と、起動テンプレートを介して EC2 インスタンスを記述computeConfigurationする を受け取ります。次の例では、単一の許可されたインスタンスタイプと永続的な EBS ボリュームを持つ Linux キャパシティープロバイダーを作成します。
例
GPU ワークロードを実行するには、サポートされている GPU インスタンスタイプを に含めますallowedInstanceTypes。AgentCore はインスタンスに GPU ドライバーをプロビジョニングするため、標準のコンテナイメージはドライバーをバンドルせずに動作します。サポートされているファミリーは、g4dn、、g5、g6、g6e、gr6、g6fgr6fg7e、、および ですinf2。サポートされていないファミリーのアクセラレーターインスタンスタイプを含めると、リクエストは で失敗しますValidationException。詳細については、「GPU インスタンスタイプを使用する」を参照してください。
キャパシティープロバイダーをランタイムに関連付けるREADY前に、ステータスが GetCapacityProviderになるまでポーリングします。ステータスが になった場合はCREATE_FAILED、 statusCodeと を調べstatusReasonて原因を特定します。
ステップ 2: キャパシティープロバイダーでエージェントランタイムを作成する
キャパシティープロバイダーを参照capacityProviderConfigurationする を使用してエージェントランタイムを作成します。キャパシティープロバイダーで定義されたボリュームをエージェントのファイルシステムにマウントするには、ボリュームを名前で参照filesystemConfigurationsするcapacityProviderVolumeエントリを に追加します。マウントパスは、単一のサブディレクトリ ( など) /mntを持つ の下にある必要があります/mnt/scratch。
エージェントランタイムには独自の がありlifecycleConfiguration.maxLifetime、デフォルトは 28800 秒 (8 時間) です。この値は、キャパシティープロバイダーが で設定maxLifetimeする 以下である必要がありますec2Configuration.lifecycleConfiguration。ステップ 1 のキャパシティープロバイダーは、その値を 3600 秒 (1 時間) に設定するため、ランタイムのデフォルトである 8 時間はそれを超え、 で失敗CreateAgentRuntimeしますValidationException。したがって、次の例では、キャパシティープロバイダーの制限内にあるランタイムを maxLifetime 1800 秒に設定します。
注記
どちらのリソースもlifecycleConfigurationメンバーを使用しますが、構造は異なります。キャパシティープロバイダーのバージョンは idleInstanceTimeout maxLifetimeおよび を受け取り、インスタンスに適用されます。エージェントランタイムのバージョンは idleRuntimeSessionTimeout を受け取りmaxLifetime、セッションに適用されます。詳細については、「Amazon Bedrock AgentCore ライフサイクル設定の構成」を参照してください。
を指定するnetworkConfigurationときは、 を渡さないでくださいcapacityProviderConfiguration。インスタンスランタイムは、キャパシティープロバイダーの からネットワークを継承するためec2Configuration.vpcConfiguration、両方の指定は で失敗しますValidationException。
例
ステップ 3: エージェントを呼び出す
microVM-backed ランタイムと同じ方法でランタイムを呼び出します。呼び出しruntimeSessionId間で同じ を再利用して、セッションを同じインスタンスに保持します。これにより、エージェントは以前の呼び出しのデータにアクセスできます。コラボレーションエージェントを共同配置するには、キャパシティープロバイダーを共有する複数のランタイムruntimeSessionIdで同じ を使用します。
例
エージェントのレスポンスは、最後の引数として名前を付けた出力ファイルに CLI AWS が書き込むストリーミング BLOB です。この例では ですresponse.json。標準出力には runtimeSessionId、contentType、および statusCodeフィールドのみが含まれるため、出力ファイルを読んでエージェントが返した内容を確認してください。
- AWS SDK
-
-
boto3 を使用してインスタンスでエージェントランタイムを呼び出す Python の例。
import boto3 import json client = boto3.client("bedrock-agentcore", region_name="us-west-2") response = client.invoke_agent_runtime( agentRuntimeArn="arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/my_instances_agent-suffix", runtimeSessionId="project-xyz-0000000000000000000000000000", # 33+ chars; reuse to keep the session payload=json.dumps({"prompt": "Analyze the sales data and summarize the key trends."}).encode(), qualifier="DEFAULT", ) print("Agent response:", json.loads(response["response"].read()))
-
は 33 文字以上にruntimeSessionIdする必要があります。
新しいセッションの最初の呼び出しは、アカウントに EC2 インスタンスをプロビジョニングしてエージェントを起動するため、通常、それ以降の呼び出しよりも時間がかかります。同じセッションへのそれ以降の呼び出しでは、実行中のインスタンスが再利用され、はるかに高速に返されます。
AgentCore は、これらのインスタンスを Amazon EC2 マネージドインスタンスとしてプロビジョニングします。Amazon EC2 マネージドインスタンスは、デフォルトで DescribeInstancesおよび EC2 コンソールビューに表示されません。プレーンaws ec2 describe-instancesコールではリストされません。これらを表示するには、 マネージドリソースを含めます。
aws ec2 describe-instances --include-managed-resources \ --filters "Name=tag-key,Values=bedrock-agentcore:capacity-provider-id"
インスタンスの可視性の管理の詳細については、「マネージドリソースの可視性設定」を参照してください。
1 つのインスタンスで複数のエージェントを共同配置する
2 つのエージェントランタイムが同じキャパシティープロバイダーを参照し、同じ でそれらを呼び出すとruntimeSessionId、両方のエージェントは同じ EC2 インスタンスで実行されます。そこで、ファイルシステム設定で設定されたボリュームを共有できます。エージェントは、その共有ボリュームでファイルを読み書きすることで共同作業を行います。各エージェントは個別に呼び出され、それ以外の場合は 状態を共有しません。たとえば、テストランナーはボリュームに結果を書き込むことができ、同じセッションで呼び出されたコードアナライザーは結果を読み取ることができます。共有インスタンス上のエージェント間の境界については、「ランタイムインスタンスのセキュリティモデルとアクセス許可」を参照してください。
import boto3 import json client = boto3.client("bedrock-agentcore", region_name="us-west-2") session_id = "collab-session-000000000000000000000" # Agent A — created on capacity provider "my_capacity_provider" client.invoke_agent_runtime( agentRuntimeArn="arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/test-runner-suffix", runtimeSessionId=session_id, payload=json.dumps({"prompt": "Run the test suite for project ABC"}).encode(), qualifier="DEFAULT", ) # Agent B — a different runtime that shares the SAME capacity provider and session ID, # so it runs on the same instance as Agent A and can read the files Agent A wrote to the shared volume. client.invoke_agent_runtime( agentRuntimeArn="arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/code-analyzer-suffix", runtimeSessionId=session_id, payload=json.dumps({"prompt": "Analyze the code for project ABC"}).encode(), qualifier="DEFAULT", )
各エージェントは、ランタイムの実行ロールから派生した独自の IAM 認証情報を使用して実行されるため、同じインスタンスを共有していても、コラボレーションエージェントに異なるアクセス許可を付与できます。ただし、同じインスタンス上のエージェントは互いに分離されていないため、どのエージェントも別のエージェントの認証情報を読み取ることができます。相互に信頼されているエージェントのみを共同配置します。詳細については、「ランタイムインスタンスのセキュリティモデルとアクセス許可」を参照してください。
クリーンアップ: セッションの停止と削除
警告
アカウントでプロビジョニングされた Amazon EC2 インスタンスと Amazon EBS ボリュームの継続的な料金を回避するには、このチュートリアルを完了するときに不要になったセッションとキャパシティープロバイダーを削除します。
セッションは同じインスタンスで複数のエージェントランタイムをホストできるため、AgentCore は 2 つの異なるオペレーションを提供します。
-
セッション内のエージェントランタイムを停止する – ランタイム ARN とセッション ID によって識別される、セッション内の単一のエージェントランタイムを
StopRuntimeSession停止します。同じセッションとインスタンスを共有する他のエージェントランタイムは影響を受けません。 -
セッションの削除 – はセッション全体
DeleteCapacityProviderSessionを削除し、アカウントで作成された EC2 リソース (インスタンス、ネットワークインターフェイス、永続的な EBS ボリューム) のプロビジョニングを解除するため、インフラストラクチャとストレージのコストの発生を停止します。
セッションで特定のエージェントランタイムを停止するには、ランタイム ARN とセッション ID を使用して StopRuntimeSession オペレーションを呼び出します。
例
セッションを削除し、永続 EBS ボリュームを含むすべてのリソースのプロビジョニングを解除するには、キャパシティープロバイダー ID とセッション ID DeleteCapacityProviderSession を使用して を呼び出します。オペレーションはべき等で非同期です。AgentCore がインスタンスを終了し、ボリュームをバックグラウンドで削除している間、すぐに が返されます。
セッション IDsは呼び出し時に指定する値であり、キャパシティープロバイダーのセッションを一覧表示するオペレーションはありません。後で各セッションを削除できるように、使用したruntimeSessionId値を記録します。それらがなくなった場合は、まだ実行中のインスタンスを見つけ、キャパシティープロバイダーを削除してすべてのセッションのプロビジョニングを解除できます。
aws ec2 describe-instances --include-managed-resources \ --filters "Name=tag-key,Values=bedrock-agentcore:capacity-provider-id" \ --query 'Reservations[].Instances[?State.Name!=`terminated`].[InstanceId,State.Name]'
例
キャパシティープロバイダーを削除する
キャパシティープロバイダーが不要になった場合は、 DeleteCapacityProviderオペレーションで削除します。キャパシティープロバイダーを削除すると、関連付けられたすべてのセッションとその永続的ストレージが停止および削除されるため、IDsします。最初にセッションを削除する必要はありません。ただし、キャパシティープロバイダーを参照するランタイムを削除する必要があります。関連するバージョン、エンドポイント、またはランタイムを最初に削除すると、削除リクエストが で失敗しますValidationException。オペレーションは非同期です。キャパシティープロバイダーを ID で識別します。