エージェントに分離されたセッションを使用する
Amazon Bedrock AgentCore ランタイムを使用すると、各ユーザーセッションを分離し、ユーザーセッション内の複数の呼び出し間でコンテキストを安全に再利用できます。AI エージェントワークロードには、固有の運用特性があるため、セッション分離が不可欠です。
-
実行環境の完全な分離: AgentCore Runtime の各ユーザーセッションは、分離されたコンピューティング、メモリ、ファイルシステムリソースを持つ独自の専用microVM を受け取ります。これにより、あるユーザーのエージェントが別のユーザーのデータにアクセスできなくなります。セッションが完了すると、microVM 全体が終了し、メモリがサニタイズされてすべてのセッションデータが削除され、セッション間の汚染リスクがなくなります。
-
ステートフル推論プロセス: ステートレス関数とは異なり、AI エージェントは実行サイクル全体で複雑なコンテキスト状態を維持し、複数ターンの会話の単純なメッセージ履歴は維持しません。AgentCore Runtime は、異なるユーザー間の完全な分離を確保しながら、セッション内でこの状態を安全に保持し、データ境界を損なうことなくパーソナライズされたエージェントエクスペリエンスを可能にします。
-
特権ツールオペレーション: AI エージェントは、さまざまなリソースにアクセスする統合ツールを通じてユーザーに代わって特権オペレーションを実行します。AgentCore Runtime の分離モデルは、これらのツールオペレーションが適切なセキュリティコンテキストを維持し、異なるユーザーセッション間の認証情報の共有やアクセス許可のエスカレーションを防止します。
-
非決定的プロセスの確定的セキュリティ: AI エージェントの動作は、基盤モデルの確率的性質のため、非決定的である可能性があります。AgentCore ランタイムは、エージェントの実行パターンに関係なく、一貫性のある決定論的な分離境界を提供し、エンタープライズデプロイに必要な予測可能なセキュリティプロパティを提供します。
注記
AgentCore はsession-to-user間のマッピングを強制しません。クライアントバックエンドは、ユーザーとそのセッション IDs の関係を維持する必要があります。さらに、クライアントバックエンドは、ユーザーあたりのセッションの最大数など、ユーザー間ライフサイクル管理のロジックを実装する必要があります。完全なセッション分離ガイダンスについては、AgentCore ランタイムのセキュリティのベストプラクティス」を参照してください。
トピック
エフェメラルコンテキストについて
デフォルトでは、セッションに関連付けられたコンピューティング (microVM) はエフェメラルです。メモリに保存されたデータやディスクに書き込まれたデータは、コンピューティングライフサイクルでのみ保持されます。これには、会話履歴、ユーザー設定、中間計算結果、エージェントが保持するその他の状態情報が含まれます。
セッションの停止/再開サイクルにわたってファイルシステムデータを保持するには、コンピューティングの終了後も存続する永続ディレクトリであるセッションストレージを設定します。AgentCore ランタイムのファイルシステム設定」を参照してください。
セッションの存続期間を超えて保持する必要がある構造化データ (ユーザーの会話履歴、学習した設定、重要なインサイトなど) には、AgentCore Memory を使用します。このサービスは、エージェントワークロード専用に設計された専用永続ストレージを提供し、短期メモリ機能と長期メモリ機能の両方を備えています。
拡張会話とマルチステップワークフロー
各リクエストの後に終了する従来のサーバーレス関数とは異なり、AgentCore は、ライフサイクルごとに最大 8 時間持続するエフェメラルコンピューティングによってバックアップされた分離セッションをサポートします。これにより、以前のやり取りによって確立されたコンテキストに基づいて各呼び出しが構築されるため、同じ環境に複数の呼び出しを実行できるため、複数ステップのエージェントワークフローの構築が簡素化されます。InvokeAgentRuntime エージェントの推論と、同じセッション内での決定的なシェルコマンドの実行InvokeAgentRuntimeCommandの両方に使用できます。
AgentCore ランタイムセッションのライフサイクル
セッションの作成
アプリケーションが提供する一意の runtimeSessionId を使用して、最初の呼び出し時に新しいセッションが作成されます。AgentCore ランタイムは、セッションごとに専用の実行環境 (microVM) をプロビジョニングします。コンテキストは、同じセッションへの呼び出し間で保持されます。InvokeAgentRuntime と の両方が同じセッションでInvokeAgentRuntimeCommand動作します。コマンドはエージェントと同じコンテナ、ファイルシステム、および環境を表示します。
セッションの状態
セッション状態はコンピューティングライフサイクルによって決定され、次のいずれかになります。
-
アクティブ: 同期リクエストの処理、コマンドの実行、またはバックグラウンドタスクの実行。同期呼び出しとコマンド実行アクティビティは、ランタイムセッションへの呼び出しに基づいて自動的に追跡されます。バックグラウンドタスクは、ping でHealthyBusy」ステータスで応答することでエージェントコードによって通信されます。
-
アイドル: リクエストまたはバックグラウンドタスクを処理しない場合。セッションの処理は完了しましたが、今後の呼び出しで引き続き使用できます。
-
停止: セッション用にプロビジョニングされたコンピューティング (microVM) が終了し、セッションが停止しました。これは、非アクティブ (デフォルトは 15 分)、コンピューティングの最大有効期間 (デフォルトは 8 時間)、StopRuntimeSession API の呼び出しによる明示的な停止、またはヘルスチェックに基づいてコンピューティングが異常であると判断された場合に発生する可能性があります。セッションは次の呼び出し時にアクティブに戻り、新しいコンピューティングがプロビジョニングされます。ライフサイクル設定は同じです (例: idleRuntimeSessionTimeout と maxLifetime は最大 8 時間です)。エージェントAgentCoreランタイム ARN が削除されるまで、セッション自体は有効です。ランタイムがセッションストレージで設定されている場合、設定されたマウントパスのファイルシステムデータは停止/再開サイクルにわたって保持されます。AgentCore ランタイムのファイルシステム設定」を参照してください。
セッションの使用方法
セッションを効果的に使用するには:
-
33 文字以上のユーザーまたは会話ごとに一意のセッション ID を生成する
-
関連するすべての呼び出しに同じセッション ID を渡す
-
ユーザーや会話ごとに異なるセッション IDsを使用する
会話にセッションを使用する例
# First message in a conversation response1 = agent_core_client.InvokeAgentRuntime( agentRuntimeArn=agent_arn, runtimeSessionId="user-123456-conversation-12345678", # or uuid.uuid4() payload=json.dumps({"prompt": "Tell me about AWS"}).encode() ) # Follow-up message in the same conversation reuses the runtimeSessionId. response2 = agent_core_client.InvokeAgentRuntime( agentRuntimeArn=agent_arn, runtimeSessionId="user-123456-conversation-12345678", # or uuid.uuid4() payload=json.dumps({"prompt": "How does it compare to other cloud providers"}).encode() )
関連する呼び出しに同じ runtimeSessionId を使用することで、会話全体でコンテキストが維持され、エージェントが以前のやり取りに基づいて一貫したレスポンスを提供できるようになります。
プロトコル別のセッションヘッダー
エージェントを呼び出すときは、適切なセッションヘッダーを含めて、リクエストが同じmicroVM にルーティングされるようにします。ヘッダーは、エージェントが設定したプロトコルによって異なります。
| プロトコル | セッションヘッダー |
|---|---|
|
MCP |
|
|
HTTP |
|
|
A2A |
|
|
AG-UI |
|
MicroVM の維持: Amazon Bedrock AgentCore はセッションヘッダーを使用して、リクエストを同じ microVM インスタンスにルーティングします。クライアントは、レスポンスで返されたセッション ID をキャプチャし、以降のすべてのリクエストに含めて、セッションのアフィニティを確保する必要があります。一貫したセッション ID がないと、各リクエストが新しいmicroVM にルーティングされ、コールドスタートによるレイテンシーが増加する可能性があります。
ステートレスモードやステートフルモードなどの MCP プロトコルの詳細については、「MCP セッション管理と microVM の維持」を参照してください。