翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# エージェントに分離されたセッションを使用する
<a name="runtime-sessions"></a>

Amazon Bedrock AgentCore ランタイムを使用すると、各ユーザーセッションを分離し、ユーザーセッション内の複数の呼び出しにわたってコンテキストを安全に再利用できます。AI エージェントワークロードには、固有の運用特性があるため、セッション分離が不可欠です。
+  **実行環境の完全な分離**: AgentCore ランタイムの各セッションは、分離されたコンピューティング、メモリ、ファイルシステムリソースを持つ独自の専用microVM を受け取ります。これにより、あるセッションの実行環境が別のセッションに属するデータにアクセスできなくなります。セッションが完了すると、microVM 全体が終了し、メモリがサニタイズされてすべてのセッションデータが削除され、セッション間の汚染リスクがなくなります。
+  **ステートフル推論プロセス**: ステートレス関数とは異なり、AI エージェントは実行サイクル全体で複雑なコンテキスト状態を維持し、複数ターンの会話の単純なメッセージ履歴は維持しません。AgentCore Runtime は、異なるセッション間の完全な分離を確保しながら、セッション内でこの状態を安全に保持し、データ境界を損なうことなくパーソナライズされたエージェントエクスペリエンスを可能にします。
+  **特権ツールオペレーション**: AI エージェントは、さまざまなリソースにアクセスする統合ツールを通じてユーザーに代わって特権オペレーションを実行します。AgentCore Runtime の分離モデルは、これらのツールオペレーションが適切なセキュリティコンテキストを維持し、異なるセッション間の認証情報の共有やアクセス許可のエスカレーションを防止します。
+  **非決定的プロセスの確定的セキュリティ**: AI エージェントの動作は、基盤モデルの確率的性質のため、非決定的である可能性があります。AgentCore ランタイムは、エージェント実行パターンに関係なく、一貫性のある決定論的な分離境界を提供し、エンタープライズデプロイに必要な予測可能なセキュリティプロパティを提供します。

**注記**  
AgentCore はsession-to-user間のマッピングを強制しません。クライアントバックエンドは、ユーザーとそのセッション IDs の関係を維持する必要があります。さらに、クライアントバックエンドは、ユーザーあたりのセッションの最大数など、ユーザー間ライフサイクル管理のロジックを実装する必要があります。完全なセッション分離ガイダンスについては、[AgentCore ランタイムのセキュリティのベストプラクティス](runtime-security-best-practices.md)」を参照してください。

**Topics**
+ [エフェメラルコンテキストについて](#ephemeral-context)
+ [拡張会話とマルチステップワークフロー](#extended-conversations)
+ [AgentCore ランタイムセッションのライフサイクル](#session-lifecycle)
+ [セッションの使用方法](#using-sessions)
+ [プロトコル別のセッションヘッダー](#session-headers-by-protocol)
+ [Amazon Bedrock AgentCore ライフサイクル設定を構成する](runtime-lifecycle-settings.md)
+ [実行中のセッションを停止する](runtime-stop-session.md)

## エフェメラルコンテキストについて
<a name="ephemeral-context"></a>

デフォルトでは、セッションに関連付けられたコンピューティング (microVM) はエフェメラルです。メモリに保存されたデータやディスクに書き込まれたデータは、コンピューティングライフサイクルの間のみ保持されます。これには、会話履歴、ユーザー設定、中間計算結果、エージェントが保持するその他の状態情報が含まれます。

セッションの停止/再開サイクル間でファイルシステムデータを保持するには、コンピューティングの終了後も存続する永続ディレクトリである**セッションストレージ**を設定します。[AgentCore ランタイムのファイルシステム設定](runtime-filesystem-configurations.md)」を参照してください。

セッションの有効期間を超えて保持する必要がある構造化データ (ユーザーの会話履歴、学習した設定、重要なインサイトなど) の場合は、AgentCore Memory を使用します。このサービスは、エージェントワークロード専用に設計された専用の永続的ストレージを提供し、短期メモリ機能と長期メモリ機能の両方を備えています。

## 拡張会話とマルチステップワークフロー
<a name="extended-conversations"></a>

各リクエストの後に終了する従来のサーバーレス関数とは異なり、AgentCore はエフェメラルコンピューティングによってバックアップされた分離セッションをサポートします。セッションは、microVMs ではライフサイクルごとに最大 8 時間、インスタンスでは最大 14 日間続きます。これらのセッションでは、複数ステップのエージェントワークフローを構築し、以前のインタラクションのコンテキストに基づいて、呼び出しごとに同じ環境に複数の呼び出しを行うことができます。エージェントの推論`InvokeAgentRuntimeCommand`と、同じセッション内での決定的なシェルコマンドの実行`InvokeAgentRuntime`の両方に使用できます。

## AgentCore ランタイムセッションのライフサイクル
<a name="session-lifecycle"></a>

 **セッションの作成** 

アプリケーションが提供する一意の runtimeSessionId を使用して、最初の呼び出し時に新しいセッションが作成されます。AgentCore ランタイムは、セッションごとに専用の実行環境 (microVM) をプロビジョニングします。コンテキストは、同じセッションへの呼び出し間で保持されます。`InvokeAgentRuntime` と の両方が同じセッションで`InvokeAgentRuntimeCommand`動作します。コマンドはエージェントと同じコンテナ、ファイルシステム、および環境を表示します。

 **セッションの状態** 

セッション状態はコンピューティングライフサイクルによって決定され、次のいずれかになります。
+  **アクティブ**: 同期リクエストの処理、コマンドの実行、またはバックグラウンドタスクの実行。同期呼び出しとコマンド実行アクティビティは、ランタイムセッションへの呼び出しに基づいて自動的に追跡されます。バックグラウンドタスクは、ping でHealthyBusy」ステータスで応答することでエージェントコードによって通信されます。
+  **アイドル**: リクエストやバックグラウンドタスクを処理しない場合。セッションの処理は完了しましたが、今後の呼び出しで引き続き使用できます。
+  **停止**: セッション用にプロビジョニングされたコンピューティング (microVM) が終了し、セッションが停止しました。これは、非アクティブ (デフォルトは 15 分）、コンピューティングの最大有効期間 (デフォルトは 8 時間）、[StopRuntimeSession](https://docs.aws.amazon.com/bedrock-agentcore/latest/APIReference/API_StopRuntimeSession.html) API の呼び出しによる明示的な停止、またはヘルスチェックに基づいてコンピューティングが異常であると判断された場合に発生する可能性があります。セッションは次の呼び出し時にアクティブに戻り、新しいコンピューティングがプロビジョニングされます。ライフサイクル設定は同じです (例: idleRuntimeSessionTimeout と maxLifetime は最大 8 時間です）。エージェントAgentCoreランタイム ARN が削除されるまで、セッション自体は有効です。ランタイムがセッションストレージで設定されている場合、設定されたマウントパスのファイルシステムデータは停止/再開サイクルにわたって保持されます。[AgentCore ランタイムのファイルシステム設定](runtime-filesystem-configurations.md)」を参照してください。

**注記**  
サービスがセッションをプロビジョニングまたは破棄している間、同じセッションをターゲットとする 2 番目のオペレーションは再試行可能な HTTP 409 `RetryableConflictException` () を返します`Session operation in progress, please retry`。このウィンドウは短いです。すでに実行中のセッションは影響を受けません。短いエクスポネンシャルバックオフで再試行します。

## セッションの使用方法
<a name="using-sessions"></a>

セッションを効果的に使用するには:
+ 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 を使用することで、会話全体でコンテキストが維持され、エージェントが以前のやり取りに基づいて一貫したレスポンスを提供できるようになります。

## プロトコル別のセッションヘッダー
<a name="session-headers-by-protocol"></a>

エージェントを呼び出すときは、適切なセッションヘッダーを含めて、リクエストが同じmicroVM にルーティングされるようにします。ヘッダーは、エージェントの設定済みプロトコルによって異なります。


| プロトコル | セッションヘッダー | 
| --- | --- | 
| MCP |  `Mcp-Session-Id`  | 
| HTTP |  `X-Amzn-Bedrock-AgentCore-Runtime-Session-Id`  | 
| A2A |  `X-Amzn-Bedrock-AgentCore-Runtime-Session-Id`  | 
| AG-UI |  `X-Amzn-Bedrock-AgentCore-Runtime-Session-Id`  | 

 **MicroVM の維持**: Amazon Bedrock AgentCore はセッションヘッダーを使用して、リクエストを同じ microVM インスタンスにルーティングします。クライアントは、レスポンスで返されたセッション ID をキャプチャし、その後のすべてのリクエストに含めて、セッションのアフィニティを確保する必要があります。一貫したセッション ID がないと、各リクエストが新しいmicroVM にルーティングされ、コールドスタートによるレイテンシーが増加する可能性があります。

ステートレスモードやステートフルモードなどの MCP プロトコルの詳細については、[「MCP セッション管理と microVM の維持](runtime-mcp-protocol-contract.md#mcp-session-management)」を参照してください。