Amazon Bedrock AgentCore RuntimeのInteractive Shellsとは：AIエージェントを端末から調査・デバッグする前に確認すべきこと

このテーマをもう少し広げて見るなら、AWS MCP Serverのクロスアカウント対応とは：AIコーディングエージェントに複数AWSアカウントを触らせる前に確認すべき権限設計 と OpenAI GPT-5.5/GPT-5.4とCodexのAmazon Bedrock一般提供とは：導入前に見るAPI・リージョン・料金 も合わせて確認してください。Interactive Shellsの実行権限を考える時に、AIエージェントへ複数AWSアカウントを触らせる権限設計も合わせて確認できます。

Amazon Bedrock AgentCore Runtimeに、実行中のagent sessionへ端末として入るInteractive Shellsが加わりました。AWS公式Recent Announcements RSSでは、InvokeAgentRuntimeCommandShellによってWebSocket越しに永続的なterminalを開ける機能として案内されています。

ただし、これは「AIエージェントの中へ気軽に入れる便利機能」とだけ読むと危ない更新です。shellは調査を速くしますが、権限、接続先、sessionの扱い、同時接続上限、秘密情報、手作業変更の再現性まで一緒に設計しないと、本番runtimeでは強すぎる入口になります。

この記事は2026年6月8日時点で、AWS公式RSS、AgentCore RuntimeのInteractive Shellsドキュメント、Shell executionドキュメント、AgentCore CLIドキュメント、Amazon Bedrock AgentCore製品ページを確認して整理しています。Amazon Watch JapanはAmazonおよび関係会社とは非提携の情報整理サイトであり、本記事は投資助言ではありません。

3行まとめ

実行中sessionに入る

InvokeAgentRuntimeCommandShellでrunning agent session内にterminalを開き、状態確認や臨時調査に使います。

同じshellの状態を引き継ぐ

environment variables、working directory、command historyを同じshell内で扱えるため、単発実行とは向く作業が異なります。

権限と上限を先に見る

shell専用permission、READY状態のruntime ARN、session_id、shellId、同時shell上限、接続時間上限を確認します。

まず開発・検証runtimeでone-shot commandから疎通を確認し、その後にinteractive shellを開く順番が堅実です。

• AgentCore RuntimeのInteractive Shellsは、InvokeAgentRuntimeCommandShellでrunning agent session内に永続的なterminalを開く機能です。
• 単発実行向けのInvokeAgentRuntimeCommandとは違い、environment variables、working directory、command historyを同じshell内で引き継ぐため、調査やデバッグに向きます。
• 試す前に、bedrock-agentcoreのInvokeAgentRuntimeCommandShell権限、READY状態のruntime ARN、session_idとshellId、runtimeあたり10 shell上限、1時間接続上限、既存agentの再デプロイ条件を確認する必要があります。

Interactive Shellsで何が変わるのか

1. 1従来の見方

   ログやメトリクスを中心に、runtimeの外側から挙動を確認します。

2. 2shell接続

   microVM内の状態、ファイル、環境変数、作業ディレクトリをterminalで確認します。

3. 3運用上の変化

   調査の自由度が上がる一方で、通常のアプリAPIより強い運用権限として扱う必要があります。

便利なdebug accessほど、誰が、どのruntimeに、どの目的で入るのかを先に決めておく必要があります。

Interactive Shellsのポイントは、AgentCore Runtimeを「APIで呼ぶ対象」だけでなく、「実行中sessionの状態をterminalで調べる対象」として扱えるようになることです。AWSの説明では、AI coding agentやAmazon Kiroのような開発者向けagentをAgentCore Runtimeでhostしている場合に、microVM内の状態確認、ファイル確認、臨時コマンド、環境調査へ使う場面が想定されています。

この変化は、AgentCore Runtimeを本番導入するチームにとって大きいです。従来のログやメトリクスでは見えにくい「いまsession内で何が起きているか」を端末から追える一方で、端末操作は通常のアプリAPIより強い運用権限になりやすいからです。

新APIはInvokeAgentRuntimeCommandShell

公式ドキュメントでは、Interactive ShellsはInvokeAgentRuntimeCommandShell operationとして説明されています。接続はWebSocketを使い、terminal input/outputを双方向に流します。色、cursor control、full-screen applicationのようなterminalらしい挙動も扱えるため、単なる「コマンド実行API」ではなく、PTY-backedの対話的な入口として見るべきです。

根拠

AWS公式RSSは、この更新をAgentCore Runtimeがinteractive shellsをサポートした発表として扱っています。ドキュメント側でも、InvokeAgentRuntimeCommandShellがrunning AgentCore Runtime session内にpersistentなinteractive terminalを開く、と整理されています。

注意点

API名だけを見ると、既存のcommand実行APIの拡張に見えます。しかし、運用上は「shell stateを持つ接続」です。どのruntimeに、誰が、どのsessionで、どのshellとして入るのかを決めずに有効化すると、調査と変更作業の境界が曖昧になります。

同じAgentCore Runtimeに端末で入る

Interactive Shellsは、別の管理サーバーや新しい踏み台環境を作る話ではありません。InvokeAgentRuntimeやInvokeAgentRuntimeCommandと同じagent runtimeを対象に、active sessionへshell connectionを開く機能です。

条件

接続には、AgentCore Runtime endpoint ARNとREADY状態のruntimeが必要です。さらに、2026年6月8日時点のドキュメントでは、2026年6月5日より前にdeployしたagentは、runtimeを更新するために再デプロイが必要とされています。

確認項目

まず見るべきなのは、API clientの実装ではなく、接続対象のruntimeです。ARN、region、READY状態、deploy時期、shell権限を分けて確認してください。ここが曖昧なままshellを開こうとすると、権限エラーやruntime未到達をagent実装の問題と誤解しやすくなります。

便利さより先に運用条件を見る

Interactive Shellsが便利なのは、shell内の状態が残るからです。cdした場所、exportした環境変数、履歴を保ったまま調査できます。これは、長めの障害調査やagent runtime内の環境確認では強力です。

下振れ

一方で、状態が残るということは、調査手順の再現性が落ちるということでもあります。誰かがshell内で一時変更を行い、その状態を前提に追加調査を続けると、後から何が変わったのか追いにくくなります。本番runtimeでは、shellを開く前に「見るだけ」「一時変更まで」「恒久変更は禁止」などの線引きが必要です。

one-shot commandとinteractive shellをどう使い分けるか

項目	内容	見方
one-shot command		疎通確認、定型コマンド、短い診断、結果を記録しやすい処理に向きます。
interactive shell		状態を見ながら進める調査、working directoryや環境変数を引き継ぐデバッグに向きます。
実装観点		one-shotはHTTP response、interactive shellはWebSocket framesとして扱う点も切り分けの材料になります。

まずone-shot commandでruntime到達性とpermissionの一部を切り分け、必要な場合にinteractive shellへ進むと混乱が減ります。

AgentCore Runtimeには、shell executionとして大きく2つのモードがあります。単発コマンドを実行するInvokeAgentRuntimeCommandと、対話的なterminalを開くInvokeAgentRuntimeCommandShellです。

新しいInteractive Shellsを、既存のone-shot commandの上位互換として扱うのはおすすめしません。用途が違います。

主な違いは次の通りです。

• API: one-shot commandはInvokeAgentRuntimeCommand、interactive shellはInvokeAgentRuntimeCommandShell。
• protocol: one-shot commandはHTTP/2のstream、interactive shellはWebSocketのpersistent connection。
• shell state: one-shot commandは毎回fresh process、interactive shellは同じshell内で状態を保持。
• 出力: one-shot commandはstructured eventsとexit code、interactive shellはraw terminal I/Oに近いbinary frames。
• 再接続: one-shot commandは各callが独立し、interactive shellはshellIdで同じshellへ戻ります。
• 向く用途: one-shot commandはCI、定型診断、疎通確認。interactive shellは環境調査、debug、terminal UI。

one-shot commandは定型実行に向く

InvokeAgentRuntimeCommandは、単発のコマンドを実行し、stdout/stderrとexit codeを確認したい場面に向きます。CI/CDのgate、決まった診断コマンド、health check、machine-readableな確認では、状態を残さないことがむしろ利点です。

評価基準

同じコマンドを誰が実行しても同じ結果に近づけたいなら、one-shot commandを先に検討するのが自然です。たとえば、runtime内のファイル有無、特定プロセスの確認、軽い疎通、build前後の決まった検査は、interactive shellに入る前の切り分けにも使えます。

注意点

one-shot commandは毎回fresh shell processとして扱うため、前回のcdやexportを引き継ぐ前提では使えません。この性質を欠点としてではなく、再現性を保つための設計として読んでください。

interactive shellは調査とデバッグに向く

Interactive Shellsは、同じsessionの中で何度も入力しながら調べる用途に向きます。working directoryを移動し、環境変数を見て、ファイルを確認し、必要に応じてlong-running commandを流すような作業です。

評価基準

端末UI、色、cursor control、full-screen applicationが必要なら、one-shot commandよりinteractive shellのほうが合っています。AI coding agentのように、実行環境の中身を人間が見ながら調整したい場面では特に分かりやすい違いが出ます。

注意点

ただし、状態を引き継ぐshellは監査の難易度も上げます。調査中に何を見て、何を変更し、どの出力を根拠に判断したのかを、CloudWatch logs、操作記録、incident ticketなど外側の記録と結びつける運用が必要です。

出力形式とprotocolを実装観点で見る

one-shot commandはHTTP/2のrequest-response streamとして扱われ、structured eventsとexit codeを受け取る設計です。interactive shellはWebSocketでbinary framesを流すため、terminal clientやreconnect処理の実装を考える必要があります。

確認項目

アプリケーション内にterminal体験を組み込むなら、WebSocket切断、reconnect、buffer replay、client側のframe処理を設計対象に入れてください。単にAWS SDKでAPIを呼ぶだけの実装より、UIと運用が絡みます。

接続前に確認するIAM、runtime状態、再デプロイ

IAM permission

bedrock-agentcoreのInvokeAgentRuntimeCommandShellを明示的に許可できるか確認します。

runtime endpoint ARN

接続先のruntime endpoint ARN、region、READY状態を確認します。

既存agentのdeploy時期

2026年6月5日以前にdeployしたagentでは、Interactive Shellsのための再デプロイ条件を疑います。

通常invokeの権限があることと、shellを開けることは同じではありません。

Interactive Shellsで最初に詰まりやすいのは、agentのコードではありません。多くの場合、権限、runtime ARN、READY状態、region、deploy時期の確認不足です。

IAM permissionはshell専用に確認する

Interactive Shellsを呼ぶには、bedrock-agentcore serviceのInvokeAgentRuntimeCommandShell permissionが必要です。runtimeを通常invokeできる権限があるからshellも開ける、と決めつけないほうが安全です。

条件

本番runtimeでは、shell権限を通常のagent利用権限と分けるべきです。開発者がagentを呼ぶ権限、SREが障害時にshellへ入る権限、CIがone-shot commandを実行する権限は、同じではありません。

注意点

最小権限のIAM policyは、対象runtime ARN、対象region、利用者role、break-glass手順と合わせて設計してください。この記事では具体的なpolicy例を断定せず、公式ドキュメントで必要permissionを確認したうえで、権限分離の観点に絞ります。

READY状態のruntime endpoint ARNを用意する

Prerequisitesとして、valid AgentCore Runtime endpoint ARNとREADY状態のruntimeが必要です。接続できない場合は、まずruntimeの存在、ARN、region、状態を見てください。

確認項目

確認順は次のように分けると切り分けやすくなります。

1. CLIやSDKが使うAWS profileとregionが意図通りか。
2. 指定しているruntime ARNが最新のdeploy先か。
3. runtimeがREADYか。
4. shell用permissionが付与されているか。
5. 既存runtimeがInteractive Shells対応後にdeployされているか。

下振れ

runtimeがREADYではない、ARNが古い、regionが違う、featureがtarget regionで有効ではない場合、ValidationExceptionやruntime未到達のような形で失敗します。agent codeの修正に入る前に、接続前提を潰すのが近道です。

2026年6月5日以前のdeployは再デプロイを疑う

2026年6月8日時点のInteractive Shells docsでは、2026年6月5日より後に作成されたagentsはinteractive shellsを自動的にサポートし、それ以前にdeployしたagentはruntime更新のため再デプロイが必要と説明されています。

根拠

この条件は公式ドキュメント内のPrerequisitesに記載されています。公開後にドキュメントが変わる可能性はありますが、少なくとも今回の記事作成時点では、既存runtimeで最初に切り分けたい確認点です。

注意点

「AgentCore Runtimeならすべてすぐ使える」と読まないほうが安全です。既存の検証環境でshellだけ失敗する場合は、権限だけでなくdeploy時期も見てください。

session_idとshellIdをどう設計するか

1. 1session_id

   どのruntime sessionに接続するかを指定します。省略時はconnectionごとに新しいsessionが作られます。

2. 2shellId

   同じshellへ戻るために使います。detach後に再接続するなら保存が必要です。

3. 3reconnect command

   detach時に出る再接続情報を保存し、同じsession_idとshellIdで戻れるか確認します。

4. 4reconnection buffer

   戻った直後の出力確認には役立ちますが、監査ログや恒久ログの代替にはしません。

再接続を運用に含めるなら、IDの保存場所、共有範囲、失効時の扱いまで決めておく必要があります。

Interactive Shellsの運用で最も間違えやすいのが、session_idとshellIdの扱いです。どちらも再接続に関わりますが、意味は同じではありません。

session_idはruntime sessionを指定する

session_idは、どのruntime sessionに接続するかを指定するためのIDです。ドキュメントでは、session_idを省略するとconnectionごとに新しいsessionが作られると説明されています。

条件

同じagent sessionを継続して調べたいなら、session_idを保存し、再接続時にも同じ値を使う必要があります。障害調査では、incident ticketや調査ログにsessionの識別子を残しておくと、後から何を見たのか追いやすくなります。

注意点

どのsessionに入っているか分からない状態で調査を続けると、別の実行環境を見ているのに同じ問題だと誤認する可能性があります。AIエージェントはsessionごとに状態が異なる場合があるため、通常のアプリdebug以上にsessionの識別が効いてきます。

shellIdは同じshellへ戻るために必要

shellIdは、同じshellへreconnectするための識別子です。ドキュメントでは、reconnectには同じsession_idとshellIdを保存・再利用する必要があると説明されています。

根拠

Interactive Shells docsでは、shellIdをclient側で保持し、SDKのReconnectConfigで一時的なnetwork interruptionに対応するbest practiceが示されています。CLIでも、detach後にruntime、region、session ID、shell IDを含むreconnect commandが出る流れが説明されています。

注意点

shellIdは「分かりやすい名前なら何でもよい」と雑に扱わないでください。Error handlingでは、shell ID formatがinvalidな場合にRuntimeClientError (424)が起きること、1-128文字の英数字、underscore、hyphenである必要があることが説明されています。

reconnect bufferはログ保存ではない

Interactive Shellsにはreconnection bufferがあります。公式ドキュメントでは、reconnect時に最大256KBのrecent outputをreplayできるとされています。

条件

これは、network interruptionから戻るためのbufferです。長いbuild log、巨大な調査出力、secretを含む可能性があるdumpを保存するためのログ基盤ではありません。

注意点

長時間の調査や大量出力を扱うなら、CloudWatch logs、アプリ側のstructured logs、artifact保存、one-shot commandのJSON outputなど、別の記録方法と併用してください。reconnect bufferに依存すると、重要な前後関係が欠ける可能性があります。

上限とエラーは運用ルールとして読む

項目	内容	見方
maximum frame payload size: 64KB		大きな入力や出力は分割し、巨大なpayloadをterminalへ流し込まない前提にします。
frame rate: 250 frames/sec		高頻度出力やterminal UIを使う場合は、frame制約に触れないか確認します。
maximum connection duration: 1 hour		長時間作業はdetach、reconnect、作業中断のルールを前提にします。
concurrent shell sessions per runtime: 10		閉じ忘れ、複数人の同時接続、不要shellのcleanupを運用ルールに入れます。
reconnection buffer: 256KB		再接続時の補助として扱い、ログ保存や監査証跡は別に用意します。
エラー分類		AccessDeniedException、RuntimeClientError、ConflictExceptionなどを権限、状態、競合に分けて読みます。

2026年6月8日時点の公式docs上の値です。上限に触れた後の対応を、利用前に決めておくことが重要です。

Interactive Shellsのquotaは、単なる数字ではなく運用ルールです。チームで使うなら、上限に触れたときの対処を先に決めておく必要があります。

2026年6月8日時点の公式docsでは、主な値は次のように整理されています。

• maximum frame payload size: 64KB。大きな入力は分割する。
• frame rate: 250 frames/sec。高頻度出力やterminal UIに注意する。
• maximum connection duration: 1 hour。長時間作業はreconnect前提にする。
• concurrent shell sessions per runtime: 10。閉じ忘れ対策が必要。
• reconnection buffer: 256KB。ログ保存の代替にしない。

concurrent shellはruntimeあたり最大10

同時に開けるactive shell sessionsは、runtimeあたり最大10と説明されています。10個すでに開いている場合、新しいconnectionは拒否されます。

根拠

ドキュメントのQuotas and limitsでは、concurrent shell sessions per runtimeが10と示されています。これは「1ユーザーあたり」や「アカウント全体」と断定するものではなく、runtimeあたりの上限として扱います。

注意点

チーム運用では、detachしたままのshell、複数人の同時調査、terminal clientの自動reconnectが重なり、上限に触れやすくなります。誰が開いたshellをいつ閉じるか、incident終了時に何をcleanupするかを決めておくべきです。

1時間接続上限とframe制約を見る

maximum connection durationは1時間で、上限に達するとconnectionがclose code 1008で閉じると説明されています。frame payloadは64KB、frame rateは250 frames/secという制約もあります。

条件

長時間のdebug sessionでは、1時間を超える前提でreconnectをテストしてください。大きなfile pasteや大量出力を流すterminal UIは、frame payloadやframe rateの制約に触れる可能性があります。

下振れ

重いbuild、長いログtail、全量dump、full-screen toolの多用は、interactive shellよりone-shot command、ログ基盤、保存済みartifactの確認に寄せたほうが安定する場合があります。

エラーは権限、状態、競合に分けて読む

Interactive ShellsのError handlingでは、WebSocket upgrade時に起きる代表的なerrorとして、ValidationException、AccessDeniedException、ResourceNotFoundException、RuntimeClientError (424)、ThrottlingException、ConflictExceptionが挙げられています。

確認項目

AccessDeniedExceptionならpermission、ResourceNotFoundExceptionならruntime ARN、ValidationExceptionならsession ID、region、READY状態、RuntimeClientError (424)なら10 open shells、shell ID format、runtime unreachableを疑います。ConflictExceptionは同じshellIdを同時にclaimしようとした狭いrace conditionとして扱われ、retryが対処になります。

注意点

424を「AWS側の一時的なエラー」と一括りにすると切り分けを誤ります。response bodyのerror fieldを見て、上限、format、runtime unreachableを分けて読んでください。

AgentCore CLIで試す前の最小確認フロー

1. CLI設定とruntime確認

   profile、region、対象runtime ARN、READY状態を確認します。

2. one-shotで疎通

   interactive shellへ入る前に、単発コマンドで到達性とpermissionの一部を切り分けます。

3. shellを開く

   working directoryや環境変数が同じshell内で残ることを確認します。

4. detachとreconnect

   Ctrl+]でdetachし、reconnect commandを保存して同じshellへ戻れるか確認します。

5. closeとcleanup

   shellを明示的に閉じ、runtimeあたり10 shell上限に不要に近づかない運用を確認します。

コマンドを丸暗記するより、疎通、接続、再接続、終了の順で確認するほうが実務では役に立ちます。

AgentCore CLIは、Interactive Shellsを試す入口として分かりやすい選択肢です。ドキュメントでは、agentcore exec --itでbuilt-in terminal experienceを使えると説明されています。

ただし、手順をコマンド集として丸暗記するより、確認順を決めるほうが実務では役に立ちます。

まずCLI設定とruntimeを確認する

AgentCore CLI docsは、Python agent projectの作成、local test、observability、deploy、invoke、cleanupまでを扱っています。Interactive Shellsだけを見る前に、CLIが使うprofile、region、runtime指定、deploy済みruntimeの状態を確認してください。

確認項目

最低限、次の順番で見ると混乱が減ります。

1. AgentCore CLIが現在のprofileとregionで動くか。
2. 対象runtime ARNを明示できるか。
3. one-shot commandで簡単な疎通を確認できるか。
4. agentcore exec --it --runtime <runtime-arn> --region <region>の形で接続対象を明示できるか。
5. detach後にreconnect commandを保存できるか。

注意点

この記事では、CLIのinstall手順やagent projectの作成手順は詳説しません。公式CLI docsの内容が更新されやすいため、実行前には公式手順を見直してください。

one-shotで疎通してからinteractive shellを開く

いきなりinteractive shellへ入るより、one-shot commandでruntime到達性とpermissionの一部を切り分けるほうが堅実です。ドキュメントでも、agentcore exec "ls -la /tmp"のように--itを付けないone-shotの例、--jsonでmachine-readable outputを得る例が示されています。

評価基準

one-shotが通るなら、runtime ARN、region、基本的なCLI設定はある程度切り分けられます。そのうえでinteractive shellが失敗するなら、shell専用permission、session ID、shell ID、同時shell上限、feature availabilityを疑いやすくなります。

注意点

one-shotが通ったからshellも必ず通る、とは限りません。bedrock-agentcore:InvokeAgentRuntimeCommandShellはshell専用に確認してください。

再接続まで試して初めて運用検証にする

Interactive Shellsは、開けるだけでは検証として足りません。detachし、session_idとshellIdを使って戻れるか、1時間接続上限や同時shell上限に触れたときの挙動をどう扱うかまで見る必要があります。

確認項目

検証環境では、次のような小さなtest caseを作るとよいでしょう。

• shellを開き、working directoryや環境変数が同じshell内で残ることを確認する。
• Ctrl+]でdetachし、出力されたreconnect commandを保存する。
• 同じsession_idとshellIdで戻れるか確認する。
• shellを明示的に閉じ、runtimeあたり10 shell上限に不要に近づかない運用を確認する。
• 大量出力や長時間実行をinteractive shellへ流すべきか、one-shotやログ基盤へ逃がすべきか判断する。

下振れ

端末が開けることだけを成功条件にすると、本番導入時に閉じ忘れ、権限過多、秘密情報の露出、操作記録不足が出ます。検証はreconnectとcleanupまでを含めてください。

本番runtimeで許可する前のセキュリティ設計

break-glass寄りに扱う

常用権限ではなく、incident ticketや承認と紐づけて許可範囲を決めます。

環境を分ける

開発runtimeと本番runtimeで権限を分け、read-only調査と変更操作も切り分けます。

secret露出を前提にする

環境変数や出力に認証情報が含まれる可能性を前提に、貼り付けや共有のルールを決めます。

状態変更を記録する

terminal操作でファイルやprocess状態を変えられるため、作業目的、操作内容、cleanupを残します。

セキュリティ設計では便利さではなく、権限、露出、変更、監査の条件差を明確にします。

Interactive Shellsは、開発環境では便利でも、本番runtimeでは強い権限です。shellから見えるもの、触れるもの、残る状態を前提に設計する必要があります。

shell権限はbreak-glass寄りに扱う

本番runtimeでshellを許可するなら、常用権限ではなくbreak-glassに近い扱いから始めるのが安全です。誰が、どのruntimeに、どの目的で、どの時間帯に、どの承認で入れるのかを決めます。

条件

次のようなルールを先に置くと、便利さとリスクのバランスを取りやすくなります。

• 開発runtimeと本番runtimeで権限を分ける。
• 本番shell接続はincident ticketや承認と紐づける。
• read-only調査と変更操作を分ける。
• shell終了とcleanupをincident終了条件に入れる。
• secretを含む出力を外部に貼り付けないルールを明文化する。

注意点

「開発者全員がいつでも本番runtimeへ入れる」状態は避けるべきです。AIエージェントのruntimeは、外部サービスのtoken、社内API、データ処理環境、user contextを扱うことがあります。

secretsや認証情報の露出を前提に設計する

shellからは、環境変数、working directory、command history、recent outputが見える可能性があります。agentが使うsecretやcredential providerの設計と、shell accessの設計は切り離せません。

確認項目

AgentCore IdentityやSecrets Manager参照を使っている場合でも、shellから何が見えるかは別問題です。secret valueを出力しない、credentialをfileに残さない、debug commandで環境変数を全量dumpしない、recent output bufferにsecretを流さない、といった運用が必要です。

関連リンク

AgentCore IdentityとSecrets Manager参照の整理は、公開済みの<a href="https://amzn-watch.blog.mo-gmo.com/amzn-21-agentcore-identity-secrets-manager/" rel="noopener">Amazon Bedrock AgentCore Identityが既存Secrets Manager参照に対応：AIエージェントの認証情報管理で確認すべきこと</a>で詳しく扱っています。この記事のshell権限と合わせて読むと、secret管理とdebug accessを分けやすくなります。

端末操作で状態を変えるリスクを明記する

Interactive Shellsは、環境調査だけでなく、手作業で状態を変える入口にもなり得ます。障害時には助かる一方で、後から再現できないtemporary fixが残るリスクもあります。

評価基準

運用ルールでは、read-only調査、temporary workaround、恒久変更、データ削除を分けてください。特に本番runtimeでは、shell内での変更をdeploy pipelineの外側に置くのか、禁止するのか、例外時にどう記録するのかを決める必要があります。

上振れと下振れ

上振れは、agent runtime内の問題を短時間で切り分けられることです。下振れは、端末で直したつもりの状態がコードやIaCに戻らず、次のdeployで消える、または原因不明の差分として残ることです。

関連記事と読み分ける

AgentCore Identity

外部サービスやsecretをどう扱うかを確認する記事です。shell接続時のsecret露出を考える前提になります。

Step Functions連携

AIエージェントをworkflowへ組み込むときの責任範囲や失敗時の扱いを確認する記事です。

OpenSearch連携

検索基盤やretrievalの設計を確認する記事です。Interactive Shellsとは調査対象が異なります。

Bedrock新コンソール

操作面や管理画面の変化を確認する記事です。terminal debugとは別の入口として読み分けます。

同じAgentCore周辺でも、認証情報、workflow、検索基盤、操作画面、terminal debugでは確認すべきリスクが変わります。

AgentCore RuntimeのInteractive Shellsは、Amazon Watch Japanで直近扱ってきたAgentCore関連トピックとつながります。ただし、関心軸は異なります。

AgentCore Identity記事は認証情報管理の話

AgentCore Identityの記事は、AIエージェントが外部サービスやsecretをどう扱うかの話です。Interactive Shellsの記事では、shell接続によってsecretや環境情報が見える可能性を中心に扱います。

読み分け

secretの保存、参照、provider設計を知りたいならAgentCore Identity記事を先に読んでください。shellから誰が何を見られるか、障害調査時にどこまで触れるかを決めたいなら、この記事のセキュリティ設計が中心です。

Step Functions記事はworkflowに組み込む話

公開済みの<a href="https://amzn-watch.blog.mo-gmo.com/amzn-27-step-functions-agentcore-reasoning-step/" rel="noopener">AWS Step FunctionsのAgentCore推論ステップとは：AIエージェントをワークフローに組み込む前に確認すべきこと</a>は、AgentCoreをworkflowへ組み込む観点の記事です。

読み分け

Step Functionsは、agent実行をbusiness workflowやapproval flowに組み込む話です。Interactive Shellsは、runtime sessionの中を運用者が調べる話です。実行の設計と調査の設計を混ぜないほうが、権限も監査も整理しやすくなります。

OpenSearch記事は検索基盤、Bedrock新コンソール記事は操作面

Agentic AIの検索基盤を考えるなら、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-31-opensearch-serverless-nextgen-agentic-ai/" rel="noopener">次世代Amazon OpenSearch Serverlessの記事</a>が近いです。Bedrockの操作面や互換API、Projects運用を確認したいなら、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-25-bedrock-redesigned-console-openai-anthropic-apis/" rel="noopener">Amazon Bedrock新コンソールの記事</a>が補助線になります。

注意点

検索基盤、agent workflow、secret管理、runtime debugは、それぞれ別の設計領域です。Interactive Shellsは、これらの設計を置き換える機能ではなく、runtime上で起きていることを調べるための運用入口として捉えるのがよいです。

まとめ：すぐ試してよい条件、先に整える条件

項目	内容	見方
すぐ試してよい条件		開発・検証runtimeで、runtime ARN、region、READY状態、shell専用permission、reconnectとcloseの確認手順がそろっている場合です。
先に整える条件		本番runtime、複数人利用、secret露出、長時間作業、監査証跡が関わる場合は、権限と運用ルールを先に整えます。
推奨順		one-shot commandで疎通を確認し、その後にinteractive shellを開き、detach、reconnect、closeまで検証します。

Interactive Shellsはdebug accessを強くする機能です。早く触る価値はありますが、本番許可は条件を分けて判断します。

Interactive Shellsは、AgentCore RuntimeでAIエージェントを運用するチームにとって、debug accessを大きく変える機能です。特に、AI coding agent、社内tool実行agent、長めのsessionを持つagentでは、terminalで状態を確認できる価値が出ます。

すぐ試してよいケース

開発・検証runtimeで、対象runtime ARNが明確で、shell専用permissionを限定でき、再接続とcleanupまで試せるなら、早めに触っておく価値があります。one-shot commandで疎通を確認し、その後にinteractive shellを開く順番がおすすめです。

条件

試す前に、次の5点を満たしているか確認してください。

• bedrock-agentcoreのInvokeAgentRuntimeCommandShellを明示的に許可できる。
• Runtime endpoint ARNとregionが分かっている。
• runtimeがREADYである。
• 既存agentの場合、2026年6月5日以前deployの再デプロイ条件を確認している。
• session_idとshellIdを保存し、reconnectとcloseまで検証する。

先に整えるべきケース

本番runtime、複数人運用、secretを多く扱うagent、長時間作業、CI/CD用途では、先に設計を整えるべきです。Interactive Shellsは万能の操作口ではありません。定型実行はone-shot command、観測はログやメトリクス、secret管理はAgentCore IdentityやSecrets Manager側で整理するほうが向く場面があります。

評価基準

「terminalで見られるから便利」ではなく、「terminalで見てもよい人、見てもよいruntime、残すべき記録、変えてよい範囲」が決まっているかで判断してください。ここが決まっていない本番runtimeでは、機能検証より運用設計が先です。

控えめな更新通知

Amazon Watch Japanでは、AWS、Amazon Bedrock、AgentCore、Amazonの公式発表と製品更新を月次ページにも整理しています。2026年6月の重要トピックを続けて追う場合は、<a href="https://amzn-watch.blog.mo-gmo.com/monthly-topics-2026-06/" rel="noopener">2026年6月 重要トピックまとめ</a>も合わせて確認してください。

---

次に読むなら

参照した主な情報源

• AWS What’s New Recent Announcements RSS, 2026年6月8日確認: https://aws.amazon.com/about-aws/whats-new/recent/feed/
• AWS Docs, "Interactive Shells (Terminals) – Amazon Bedrock AgentCore", 2026年6月8日確認: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-get-started-command-shell.html
• AWS Docs, "Shell execution – Amazon Bedrock AgentCore", 2026年6月8日確認: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-shell-execution.html
• AWS Docs, "Get started with the AgentCore CLI – Amazon Bedrock AgentCore", 2026年6月8日確認: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-get-started-cli.html
• Amazon Bedrock AgentCore product page, 2026年6月8日確認: https://aws.amazon.com/bedrock/agentcore/