はじめに
こんにちは！
AIエージェント、最近はもう「チャットするだけ」の存在ではなくなってきましたよね。コードを書いて、依存関係を入れて、テストして、必要なら Git まで触ってほしい。そんな流れの中で、2026年4月2日に AWS が公開した Amazon Bedrock AgentCore Runtime の記事は、かなり重要なアップデートでした。今回追加されたのは、managed session storage（パブリックプレビュー） と InvokeAgentRuntimeCommand。これによって、セッションをまたいでファイル状態を持ち越しつつ、シェルコマンドを同じセッション内で直接実行できるようになりました。
今回のポイントをひと言でいうと、「考える仕事はエージェント、決まりきった仕事はコマンド、そして作業の記憶はファイルシステムに置く」 という分担が、かなり自然にできるようになったことです。AWS も、最近のエージェントではファイルシステムがコンテキストウィンドウの外側にある"主な作業記憶"になってきた、と説明しています。
先に結論
これまでのつらさは、かなりシンプルでした。
1つ目は、ファイルシステムが揮発性だったこと。AgentCore Runtime はセッションごとに専用の microVM を割り当てますが、停止やアイドルタイムアウトのあとに再開すると、新しい compute が立ち上がるため、ローカルのファイルは基本的にクリーンな状態に戻ります。デフォルトのアイドル停止は 15 分で、1 回の compute ライフサイクルは最大 8 時間です。
2つ目は、npm test や git push まで LLM にお願いするのは、ちょっと豪華すぎることです。既知のコマンドなのに、わざわざツール呼び出し経由で回すと、トークンコスト、レイテンシ、非決定性が増えます。AWS の公式説明でも、既知のコマンドは InvokeAgentRuntimeCommand、推論や設計が必要な処理は InvokeAgentRuntime と分けるのが基本になっています。
要するに、昨日の node_modules を今日も覚えていてくれるようになった、ということです。地味に見えて、これはかなり大きいです。プロジェクト展開、依存関係インストール、ビルドツール設定みたいな"準備運動"を毎回やり直さなくてよくなるので、エージェントがいきなり本題から仕事しやすくなります。
1. Managed session storage は何がすごいのか
managed session storage は、AgentCore Runtime に セッションごとの永続ディレクトリ を持たせる機能です。filesystemConfigurations に sessionStorage を追加して、たとえば mountPath を /mnt/workspace にしておくと、その配下に書いたファイルが stop/resume をまたいでも残ります。しかもストレージはセッション単位で分離されていて、別セッションのデータは読めません。
たとえば初回の invoke でエージェントに「リポジトリを落として、依存関係を入れて、セットアップして」と頼むとします。その時点で /mnt/workspace にはソースコード、node_modules、ビルド成果物、.git 履歴などが作られます。その後セッションを止めても、次回に 同じ runtimeSessionId で再開すれば、新しい microVM が立ち上がりつつ、同じストレージが再マウントされるので、前回の続きからそのまま作業できます。
ここで地味にうれしいのは、エージェント側のコードをあまり変えなくてよいことです。AWS の説明でも、エージェントは普通のローカルディレクトリのように read/write/mkdir/rename してよく、裏側ではランタイムが耐久ストレージへ非同期で同期してくれます。つまり「保存 API を明示的に叩く」ような専用ロジックを書かなくても、/mnt/workspace を普通に使えばよい設計です。
設定イメージはかなりシンプルです。
# イメージ
aws bedrock-agentcore-control create-agent-runtime \
--agent-runtime-name "coding-agent" \
--filesystem-configurations '[{
"sessionStorage": {
"mountPath": "/mnt/workspace"
}
}]'
mountPath は /mnt から始める必要があります。また、明示的に StopRuntimeSession を呼ぶ場合は、停止完了を待ってから再開するのが重要です。未反映データを durable storage に flush するためです。さらに、マウントされたパスは invoke 中にのみ利用可能 で、初期化フェーズでは使えません。
ただし、永続といっても永久保存ではありません。14 日間セッションが再開されないと削除され、agent runtime のバージョン更新後に同じ runtimeSessionId を使っても、ファイルシステムは新しい状態になります。さらに VPC モードで使う場合は、セッションデータ同期のために S3 への outbound 接続 が必要です。ここは PoC だと見落としやすいですが、本番ではかなり大事です。
2. InvokeAgentRuntimeCommand が地味に強い
もう片方の主役が InvokeAgentRuntimeCommand です。これは、実行中の AgentCore Runtime セッション内で shell command を直接実行する API で、出力は HTTP/2 の event stream として返ってきます。ここで一番大事なのは、command が agent と同じ container / 同じ filesystem / 同じ environment を見ることです。sidecar を立てたり、別プロセスにファイルを受け渡したりしなくても、agent がさっき書いたファイルを、その直後に command がそのまま読めます。
イベントは contentStart、contentDelta、contentStop の3種類です。contentDelta で stdout / stderr をリアルタイムに受け取り、最後の contentStop で exitCode と status を確認できます。つまり、2分かかるテストでも最後まで待たずに失敗を早めに検知できます。
向いているのは、npm test、git push、lint、ビルド、依存関係インストールのような 既知のコマンドで確定できる仕事 です。逆に、「コードを読んでバグの原因を考える」「JIRA を読んで実装方針を決める」といった 推論が必要な仕事 は agent 側に寄せるのが自然です。ここを分けるだけで、処理の責務がかなりきれいになります。
コードイメージはこんな感じです。
import uuid
import boto3
client = boto3.client("bedrock-agentcore", region_name="us-west-2")
response = client.invoke_agent_runtime_command(
agentRuntimeArn=AGENT_ARN,
runtimeSessionId=str(uuid.uuid4()),
qualifier="DEFAULT",
contentType="application/json",
accept="application/vnd.amazon.eventstream",
body={
"command": '/bin/bash -c "cd /mnt/workspace && npm test"',
"timeout": 300,
},
)
実運用では、session ID は 33 文字以上必要なので UUID を使うのが無難です。timeout は 1〜3600 秒 の範囲です。
ただし、ここにも少しクセがあります。各 command は 毎回新しい bash process で起動する one-shot 実行なので、前の command でやった cd や export は次に引き継がれません。必要な状態は cd /mnt/workspace && export NODE_ENV=test && npm test のように、command 自体の中に書く必要があります。さらに、git や npm などの開発ツールは microVM に標準搭載ではないため、Dockerfile に含めるか runtime 時に導入する必要があります。なお、command 実行は runtime をブロックしないので、同じセッション上で agent invoke と並行させることもできます。
3. 2つを組み合わせると、AIコーディングの流れがきれいになる
実務でいちばんイメージしやすいのは、JIRA を起点にした修正フローです。AWS のドキュメントでも、同じ session の中で、1) agent に不具合修正を考えさせる → 2) command でテストを回す → 3) 通ったら git で branch 作成・commit・push する、というパターンが紹介されています。
流れとしては、だいたいこんな感じです。
-
InvokeAgentRuntimeで「JIRA-1234 を読んで /mnt/workspace を修正して」と頼む -
InvokeAgentRuntimeCommandでcd /mnt/workspace && npm testを実行する - テストが通ったら
git checkout -b ...、git add -A、git commit、git pushを流す - 翌日に作業を再開するときは、同じ
runtimeSessionIdで呼び直す
ここが今回いちばん面白いところです。
agent が考える。platform が実行する。filesystem が覚えている。
この役割分担がきれいに成立すると、AIエージェントが「その場しのぎのチャット相手」ではなく、継続して作業する開発メンバーっぽい存在 になってきます。もちろん完全自動化はまだ慎重に扱うべきですが、少なくとも PoC から実務寄りへ一段進んだ感じはかなりあります。
4. 導入前に見ておきたいポイント
最後に、導入前にここだけは見ておきたいポイントをまとめます。
-
InvokeAgentRuntimeCommandを使うにはbedrock-agentcore:InvokeAgentRuntimeCommand権限 が必要です。さらに、2026年3月17日以降に作成した agent は自動対応ですが、それ以前にデプロイした agent は再デプロイが必要です。 - セキュリティは shared responsibility model です。AWS は microVM レベルの隔離を提供しますが、どの command を実行するか、どの secrets に触れられるか、どの principal に許可するか は利用者側の責任です。command の入力内容と request ID は CloudWatch Logs に送られ、API 呼び出しメタデータは CloudTrail に残ります。一方で、stdout / stderr はサービス側には記録されません。
- command 側の制約として、session ID は 33 文字以上、timeout は 1〜3600 秒 です。テストやビルドの長さに応じて timeout をちゃんと分けた方が安全です。
- session storage 側の制約として、14 日アイドルで削除、version 更新でリセット、明示 stop の完了待ちが必要、VPC モードでは S3 への接続が必要 という点は先に押さえておいた方がハマりにくいです。
まとめ
いかがでしたか？
今回のアップデートは、単に「ファイルが残せるようになった」「コマンドが打てるようになった」という話ではありません。
AIエージェントを、"会話する存在" から "継続して作業する存在" に近づけるアップデート だと思います。managed session storage は作業の継続性を作り、InvokeAgentRuntimeCommand は決定的な処理を LLM から切り離してくれます。そしてその両方が同じ session / 同じ filesystem の上で動くから、開発フローがかなり自然になります。
特に、コーディングエージェントや開発自動化を本気で考えている人にとっては、かなり見逃せない内容です。まずは小さめの coding agent で、/mnt/workspace を永続化し、テストだけ InvokeAgentRuntimeCommand に切り出してみる。その時点で、「あ、これ今までよりだいぶ実務っぽいな」と感じるはずです。AWS の記事を読んでいても、今回のテーマはかなり明確でした。エージェントに全部やらせるのではなく、適材適所に分担させる。 その第一歩として、とても良いアップデートだと思います。