AgentCore ランタイムセッションでシェルコマンドを実行する
InvokeAgentRuntimeCommand オペレーションを使用すると、実行中の AgentCore ランタイムセッション内でシェルコマンドを直接実行し、HTTP/2 経由で出力をストリーミングできます。コマンドは、エージェントと同じコンテナ、ファイルシステム、および環境で実行されます。これは、 InvokeAgentRuntime で使用されるのと同じセッションです。これにより、テストの実行、git オペレーション、環境設定などの決定的なオペレーションの推論タスクやコマンドにアプリケーションが エージェントを使用するワークフローが可能になります。
InvokeAgentRuntimeCommand を呼び出すには、 アクセスbedrock-agentcore:InvokeAgentRuntimeCommand許可が必要です。
仕組み
InvokeAgentRuntimeCommand は、アクティブな AgentCore ランタイムセッションのコンテナ内でシェルコマンドを実行し、出力をストリーミングします。
同じエージェント、同じセッション
InvokeAgentRuntimeCommand は、 InvokeAgentRuntime と同じエージェントのランタイムとセッションで動作します。個別のリソースは作成しません。でデプロイしたエージェントは、アクティブなセッションでエージェントの呼び出しとコマンド実行の両方CreateAgentRuntimeを受け入れます。
注記
AgentCore ランタイムmicroVM には、デフォルトでgitは 、npm、または 言語ランタイムなどの開発者ツールは含まれていません。コマンドが依存するツールは、 (Dockerfile を介して) コンテナイメージに含めるか、実行時に動的にインストールする必要があります。
レスポンスは、次の 3 つのイベントタイプのストリームです。
| イベント | メトリック | Contains |
|---|---|---|
|
|
最初のチャンク |
コマンドが開始されたことを確認します |
|
|
実行中 |
|
|
|
最後のチャンク |
|
ストリームをリアルタイムで出力します。結果は実行時に表示され、終了後は表示されません。
前提条件
-
bedrock-agentcore:InvokeAgentRuntimeCommandIAM 許可 -
有効な AgentCore ランタイムエンドポイント ARN
注記
2026 年 3 月 17 日以降に作成されたエージェントは、コマンドの実行を自動的にサポートします。この日付より前にエージェントをデプロイした場合は、再デプロイしてエージェントのランタイムを更新する必要があります。
コマンドを実行する
例
コーディングエージェントのワークフローの例
一般的なパターンは、InvokeAgentRuntime推論に を使用し、同じセッションで決定論的な操作InvokeAgentRuntimeCommandに を使用することです。
End-to-endのコーディングエージェントのワークフローの例
import boto3 import json client = boto3.client('bedrock-agentcore', region_name='us-west-2') AGENT_ARN = 'arn:aws:bedrock-agentcore:us-west-2:account-id:runtime/my-agent' SESSION_ID = 'session-id-at-least-33-characters-long' def run_command(command, timeout=60): """Helper to run a command and return the exit code.""" response = client.invoke_agent_runtime_command( agentRuntimeArn=AGENT_ARN, runtimeSessionId=SESSION_ID, contentType='application/json', accept='application/vnd.amazon.eventstream', body={'command': command, 'timeout': timeout} ) for event in response.get('stream', []): if 'chunk' in event and 'contentStop' in event['chunk']: return event['chunk']['contentStop'].get('exitCode') return None # Step 1: Invoke the agent to analyze and write a fix response = client.invoke_agent_runtime( agentRuntimeArn=AGENT_ARN, runtimeSessionId=SESSION_ID, payload=json.dumps({"prompt": "Read JIRA-1234 and implement the fix in /workspace"}).encode() ) # Process agent response... # Step 2: Run tests deterministically exit_code = run_command('/bin/bash -c "cd /workspace && npm test"', timeout=300) # Step 3: If tests pass, commit and push if exit_code == 0: run_command('/bin/bash -c "cd /workspace && git checkout -b fix/JIRA-1234"') run_command('/bin/bash -c "cd /workspace && git add -A && git commit -m \'Fix JIRA-1234\'"') run_command('/bin/bash -c "cd /workspace && git push origin fix/JIRA-1234"')
エージェントはコードを書き込みます。プラットフォームは コマンドを実行します。それぞれが最善を尽くします。
一般的なユースケース
- テストスイートの実行
-
エージェントがコードを書き込んだら、プロジェクトのテストスイートをコマンドとして実行します。ストリーミングレスポンスを使用すると、障害を早期に検出し、特定のエラー出力をエージェントにフィードして反復できます。
/bin/bash -c "cd /workspace && npm test 2>&1" - Git オペレーション
-
分岐、コミット、プッシュは決定論的な操作です。エージェントが作業を完了した後にコマンドとして実行し、バージョン管理ロジックを LLM から遠ざけます。
/bin/bash -c "cd /workspace && git add -A && git commit -m 'Fix issue'" - 依存関係のインストール
-
エージェントクローンリポジトリの呼び出し、パッケージのインストール、ビルドツールのセットアップの前に、環境をブートストラップします。この準備は、直接コマンドとしてより高速かつ確実に実行されます。
/bin/bash -c "pip install -r requirements.txt" - ビルドとコンパイル
-
ステップとアセット生成を、指定されたとおりに実行する必要がある既知のコマンドでコンパイルします。
/bin/bash -c "cd /workspace && cargo build --release" - リンティングと検証
-
エージェントがコードを書き込んだ後、コミットする前に、コード品質チェックを検証ゲートとして実行します。
/bin/bash -c "cd /workspace && npx eslint src/ --format json" - 環境検査
-
ランタイム状態、インストール済みパッケージ、使用可能なツールをチェックする - エージェント障害のデバッグに役立ちます。
/bin/bash -c "python --version && node --version && git --version" - データオペレーション
-
データセットの取得、結果のアップロード、データ変換の実行 - 直接コマンドとしてより高速に実行されるネットワークおよびコンピューティングオペレーション。
/bin/bash -c "aws s3 cp s3://my-bucket/data.csv /workspace/"
主な設計選択肢
- ワンショット、非インタラクティブ実行
-
各コマンドは新しい bash プロセスを生成し、完了 (またはタイムアウト) まで実行して、 を返します。コマンド間に永続的なシェルセッションはありません。これは、エージェントフレームワークがコマンド実行を使用する方法と一致します。コマンドを作成し、実行し、出力を読み、次に何をするかを決定します。
- HTTP/2 経由のストリーミングレスポンス
-
出力は生成されたとおりに到着し、完了するまでバッファされません。ストリーム
npm testに 2 分かかる は、リアルタイムになります。アプリケーションは最初の数秒で障害を検出し、フル実行を待つのではなく、早期にキャンセルできます。 - コンテナの分離
-
コマンドは、エージェントコードと同じコンテナ内で実行されます。同じファイルシステム、環境変数、インストールされたパッケージが表示されます。エージェントが書き込んだファイルは
/workspace/fix.py、 を実行するコマンドにすぐに表示されますcat /workspace/fix.py。 - ランタイムへのノンブロッキング
-
コマンドを実行しても、エージェントの呼び出しはブロックされません。エージェントを呼び出し、同じセッションでコマンドを同時に実行できます。プラットフォームは同時実行を処理します。
- コマンド間でステートレス
-
各コマンドは新しい - シェル履歴なし、以前のコマンドからの環境変数の変更は引き継がれません。状態が必要な場合は、コマンド自体でエンコードします:
cd /workspace && export NODE_ENV=test && npm test。
セキュリティに関する考慮事項
ヒント
すべてのランタイムセキュリティレコメンデーションの統合ビューについては、AgentCore ランタイムのセキュリティのベストプラクティス」を参照してください。
重要
責任 AWS 共有モデルでは、ユーザーは AgentCore ランタイムセッションで実行するコマンドのセキュリティに責任を負います。 は、microVM レベルで安全なインフラストラクチャと分離 AWS を提供します。実行するコマンド、処理するデータ、および設定したアクセスコントロールは、お客様の責任となります。
コマンド実行のセキュリティ境界は microVM です。各 AgentCore ランタイムセッションは、独自のカーネル、メモリ、ファイルシステムを持つ分離されたmicroVM で実行されます。実行するコマンドは、他の顧客のワークロードにアクセスしたり、VM の境界からエスケープしたりすることはできません。ただし、VM 内では、コマンドはコンテナファイルシステム、および設定した認証情報またはシークレットにフルアクセスできます。
CloudWatch Logs を使用した監査
AgentCore Runtime は、リクエスト ID と入力コマンドをエージェントの Amazon CloudWatch Logs ロググループに送信します。これらのログを使用して、コマンドアクティビティをモニタリングし、セッションで実行されたコマンドの監査証跡を維持できます。コマンド実行出力 (stdout および stderr) はアプリケーションにストリーミングされ、サービスによってログに記録されません。
CloudTrail を使用した監査
AWS CloudTrail は、アカウントに InvokeAgentRuntimeCommand API コールを記録します。各レコードには、発信者 ID、タイムスタンプ、送信元 IP アドレス、応答ステータスなどのメタデータが含まれます。CloudTrail はリクエストまたはレスポンスペイロードを記録しません。CloudTrail を使用してコマンドを実行したユーザーとタイミングを監査し、リクエスト ID を使用して CloudWatch Logs ログと関連付けて、実行されたコマンドを確認します。
機密性の高いワークロードの場合は、次のような追加のコントロールを実装することを検討してください。
-
IAM ポリシーを使用して呼び出せるプリンシパルを制限する
InvokeAgentRuntimeCommand -
ネットワーク内にトラフィックを保持するように VPC エンドポイントを設定する
-
予期しないコマンドパターンを検出するための CloudWatch Logs メトリクスフィルターとアラームの設定
-
CloudTrail ログの不正アクセスの試みを定期的に確認する
エラー処理
InvokeAgentRuntimeCommand オペレーションを使用すると、次のエラーが発生することがあります。
- ValidationException
-
リクエストパラメータが無効である場合に発生します。エージェント ARN、セッション ID、およびコマンドが正しくフォーマットされていることを確認します。コマンドは 1 バイト~64 KB、タイムアウトは 1~3600 秒、セッション ID は 33 文字以上にする必要があります。
- ResourceNotFoundException
-
指定されたエージェントのランタイムまたはセッションが見つからない場合に発生します。エージェント ARN が正しく、セッションがアクティブであることを確認します。
- AccessDeniedException
-
必要なアクセス許可がない場合に発生します。IAM ポリシーに アクセス
bedrock-agentcore:InvokeAgentRuntimeCommand許可が含まれていることを確認します。 - ThrottlingException
-
リクエストレート制限の 25 TPS を超えた場合に発生します。エクスポネンシャルバックオフと再試行ロジックをアプリケーションに実装します。
ゼロ以外の終了コードで完了するコマンドは API エラーではありません。contentStop イベントexitCodeで をチェックして、コマンド自体が成功したかどうかを確認します。status の は、コマンドが指定されたタイムアウトを超えたTIMED_OUTことを示します。
ベストプラクティス
InvokeAgentRuntimeCommand オペレーションを使用する場合は、次のベストプラクティスに従ってください。
-
InvokeAgentRuntimeCommand決定論的操作 (テスト、git、ビルド) には を使用し、推論タスクInvokeAgentRuntimeには を使用します。決定論的操作を LLM 経由でルーティングしないでください。 -
コマンドが依存する開発者ツール (、、言語ランタイムなど)
npmを Dockerfilegit経由でコンテナイメージに含めます。 -
コマンドが成功したかどうかを判断するには、必ず
contentStopイベントexitCodeで を確認してください。 -
適切なタイムアウトを設定します。テストスイートには 5 分かかる場合がありますが、 には 30 秒しか必要ない
git push場合があります。 -
ストリーミング出力を段階的に処理して、障害を早期に検出します。長時間実行されるコマンドは、完了するのを待たずにキャンセルできます。
-
各コマンドは新しい bash
cd /workspace && export NODE_ENV=test && npm testプロセスを開始するため、&&連鎖 ( など) を使用してコマンド自体の状態をエンコードします。 -
セッション ID UUIDs を使用して、33 文字の最小要件を満たします (例:
12345678-1234-1234-1234-123456789012)。 IDs