
AgentCore Runtime のインタラクティブシェルで Kiro CLI を動かしてみた
はじめに
前回の記事では、AgentCore Runtime のインタラクティブシェルに接続して microVM の中身を調査しました。
公式ブログで紹介されていたインタラクティブシェルのユースケースに Kiro が言及されており、今回は実際にインストールして動かしてみました。
前提条件
- AgentCore Runtime が作成済みで
agentcore exec --itでインタラクティブシェルに接続できる状態 - Runtime の作成手順は前回記事を参照
パターンA: シェル内で直接インストール
インタラクティブシェルに接続
eval $(aws configure export-credentials --format env)
docker run --rm -it \
-e AWS_ACCESS_KEY_ID \
-e AWS_SECRET_ACCESS_KEY \
-e AWS_SESSION_TOKEN \
-e AWS_REGION=us-west-2 \
node:20-slim sh -c "npm install -g @aws/agentcore 2>/dev/null && \
agentcore exec --it --runtime arn:aws:bedrock-agentcore:us-west-2:123456789012:runtime/<RUNTIME_ID> --region us-west-2"
agentcore CLI を Docker 経由で実行しています。--region を明示すれば .bedrock_agentcore.yaml が不要なため、プロジェクトディレクトリのマウントも不要です。
Kiro CLI のインストール
シェル接続後、ARM64 バイナリを直接インストールします。
curl -fsSL https://cli.kiro.dev/install | KIRO_CLI_SKIP_SETUP=1 bash
export PATH="$HOME/.local/bin:$PATH"
[agentcore-runtime-user@localhost /]$ kiro-cli --version
kiro-cli 2.6.0
10秒ほどでインストールが完了しました。非 root ユーザー(agentcore-runtime-user)の $HOME/.local/bin に配置されます。
AWS CLI のインストール
Kiro CLI の use_aws ツールは内部で AWS CLI を呼び出すため、別途インストールが必要です。
curl -fsSL "https://awscli.amazonaws.com/awscli-exe-linux-aarch64.zip" -o /tmp/awscliv2.zip
unzip -q /tmp/awscliv2.zip -d /tmp
/tmp/aws/install --install-dir $HOME/.local/aws-cli --bin-dir $HOME/.local/bin
rm -rf /tmp/aws /tmp/awscliv2.zip
[agentcore-runtime-user@localhost /]$ aws --version
aws-cli/2.34.63 Python/3.14.5 Linux/6.1.161-18.298.amzn2023.aarch64 exe/aarch64.amzn.2023
認証方式
用途に応じて3つの方式から選べます。デバイスコード認証は IdC(IAM Identity Center)ログイン、残り2つは API キー方式です。
デバイスコード認証(インタラクティブシェルならでは)
kiro-cli login --use-device-flow
以下は、IAM Identity Center を用いた組織アカウントでのログイン例です。
✔ Select login method · Use with Your Organization
✔ Enter Start URL · https://d-XXXXXXXXXX.awsapps.com/start
✔ Enter Region · us-east-1
Confirm the following code in the browser
Code: RFFG-XXXX
Open this URL: https://d-XXXXXXXXXX.awsapps.com/start/#/device?user_code=RFFG-XXXX
Device authorized
Logged in successfully
詳細は下記記事を参照してください。
ターミナルに URL とコードが表示されるので、ローカル PC のブラウザーで URL を開いてコードを入力すれば認証が完了します。
KIRO_API_KEY 環境変数(ヘッドレス実行・自動化向き)
export KIRO_API_KEY="<YOUR_API_KEY>"
SSM Parameter Store → KIRO_API_KEY(チーム・運用向き)
export KIRO_API_KEY=$(aws ssm get-parameter \
--name "/kiro/headless/api-key" \
--with-decryption \
--query 'Parameter.Value' \
--output text \
--region us-east-1)
今回は SSM パラメータを us-east-1 に作成していたため --region us-east-1 を指定しています。Runtime と同じ us-west-2 に作成する場合は読み替えてください。
execution_role に ssm:GetParameter を付与します。SecureString をカスタマー管理キーで暗号化している場合は、利用する KMS キーに対する kms:Decrypt も必要です。キーをシェルに直接書く必要がなく、チームでの運用に向いています。
ヘッドレスモードの動作確認
kiro-cli chat --no-interactive --trust-all-tools "What is 2+2? Answer in one word."
> Four.
▸ Credits: 0.02 • Time: 2s
対話モードの動作確認
kiro-cli chat
> What is 2+2? Answer in one word.
Four.
▸ Credits: 0.02 • Time: 2s
──────────────────────────────────────
> テスト
こんにちは!何かお手伝いできることはありますか?
▸ Credits: 0.02 • Time: 3s
対話モードも動作しました。
use_aws ツールの動作確認
use_aws ツールは MMDS(microVM Metadata Service)経由で取得した execution_role の認証情報を使って AWS API を呼び出します。
許可された操作(sts:GetCallerIdentity)
kiro-cli chat --no-interactive --trust-all-tools \
"Run sts get-caller-identity using the use_aws tool"
Running aws cli command (using tool: aws):
Service name: sts
Operation name: get-caller-identity
Region: us-west-2
Label: STS Get Caller Identity in us-west-2 - Completed in 0.661s
| 項目 | 値 |
|------|-----|
| Account | 123456789012 |
| Arn | arn:aws:sts::123456789012:assumed-role/AgentCore-...-tUZS2JYNHvVd/BedrockAgentCore-... |
execution_role として動作していることが確認できました。
拒否された操作(ec2:DescribeRegions)
kiro-cli chat --no-interactive --trust-all-tools \
"List the AWS regions using the use_aws tool with ec2 describe-regions"
● Execution failed after 0.770s:
aws: [ERROR]: An error occurred (UnauthorizedOperation) when calling the DescribeRegions operation:
You are not authorized to perform this operation.
execution_role に許可されていない操作は IAM で拒否されます。
パターンA の永続性について
シェル内で手動インストールしたツールは、Runtime の再デプロイで失われる可能性があります。
パターンB: Dockerfile にプリインストール
bedrock-agentcore-starter-toolkit の基本(agentcore configure → agentcore launch)は上記の記事で紹介しています。今回はカスタム Dockerfile で Kiro CLI と AWS CLI をプリインストールする応用例です。
ファイル構成
patternB/
├── agent.py — Strands エージェント(最小構成)
├── requirements.txt — strands-agents, bedrock-agentcore
├── Dockerfile — Kiro CLI + AWS CLI プリインストール
├── .bedrock_agentcore.yaml — Starter Toolkit 設定
└── .dockerignore
Dockerfile
ARM64 向けに Kiro CLI と AWS CLI v2 をプリインストールします。
FROM ghcr.io/astral-sh/uv:python3.12-bookworm-slim
WORKDIR /app
ENV UV_SYSTEM_PYTHON=1 UV_COMPILE_BYTECODE=1
RUN apt-get update -qq && \
apt-get install -y -qq curl unzip && \
apt-get clean && rm -rf /var/lib/apt/lists/*
# Kiro CLI
RUN curl -fsSL https://cli.kiro.dev/install | KIRO_CLI_SKIP_SETUP=1 bash && \
cp /root/.local/bin/kiro-cli* /usr/local/bin/
# AWS CLI v2 (ARM64)
RUN curl -fsSL "https://awscli.amazonaws.com/awscli-exe-linux-aarch64.zip" -o /tmp/awscliv2.zip && \
unzip -q /tmp/awscliv2.zip -d /tmp && \
/tmp/aws/install && \
rm -rf /tmp/aws /tmp/awscliv2.zip
COPY requirements.txt requirements.txt
RUN uv pip install -r requirements.txt
RUN uv pip install "aws-opentelemetry-distro>=0.10.1"
ENV AWS_REGION=us-west-2
ENV AWS_DEFAULT_REGION=us-west-2
ENV DOCKER_CONTAINER=1
EXPOSE 8080
EXPOSE 8000
COPY . .
CMD ["opentelemetry-instrument", "python", "-m", "agent"]
ポイントは KIRO_CLI_SKIP_SETUP=1 でインタラクティブなセットアップをスキップしていることです。ビルド後のバイナリを /usr/local/bin/ にコピーしてパスを通しています。
agent.py(最小構成)
from strands import Agent
from strands.models import BedrockModel
from bedrock_agentcore.runtime import BedrockAgentCoreApp
app = BedrockAgentCoreApp()
@app.entrypoint
async def entrypoint(payload):
message = payload.get("prompt", "")
model = BedrockModel(model_id="anthropic.claude-3-5-haiku-20241022-v1:0", region="us-west-2")
agent = Agent(model=model)
stream_messages = agent.stream_async(message)
async for message in stream_messages:
if "event" in message:
yield message
if __name__ == "__main__":
app.run()
Runtime のコンテナデプロイには HTTP エンドポイントを持つエージェントプロセスが必要なため、最小構成で配置しています。Kiro CLI はインタラクティブシェル側で利用します。
.bedrock_agentcore.yaml
agentcore configure を実行しなくても、このファイルを直接書けばデプロイできます。
.bedrock_agentcore.yaml(全文)
default_agent: agent
agents:
agent:
name: agent
language: python
entrypoint: agent.py
deployment_type: container
platform: linux/arm64
container_runtime: none
aws:
execution_role_auto_create: true
account: '123456789012'
region: us-west-2
ecr_auto_create: true
network_configuration:
network_mode: PUBLIC
protocol_configuration:
server_protocol: HTTP
observability:
enabled: true
memory:
mode: NO_MEMORY
デプロイ
eval $(aws configure export-credentials --format env)
docker run --rm \
-e AWS_ACCESS_KEY_ID \
-e AWS_SECRET_ACCESS_KEY \
-e AWS_SESSION_TOKEN \
-e AWS_REGION=us-west-2 \
-e AGENTCORE_SUPPRESS_RECOMMENDATION=1 \
-v "$(pwd)/patternB:/work" \
-w /work \
python:3.12-slim sh -c "
pip install -q bedrock-agentcore-starter-toolkit &&
agentcore launch
"
agentcore launch は内部で CodeBuild を使い、ARM64 向けの Docker イメージをビルドして ECR にプッシュし、Runtime をデプロイします。今回は1分12秒で完了しました。ECR リポジトリ・IAM ロール・CodeBuild プロジェクトは全て自動作成されます。
動作確認
インタラクティブシェルに接続すると、追加インストール不要で Kiro CLI と AWS CLI が利用できます。認証はパターンAと同様に必要です。
$ agentcore exec --json --runtime arn:aws:bedrock-agentcore:us-west-2:123456789012:runtime/<RUNTIME_ID> "kiro-cli --version"
{"success":true,"exitCode":0,"stdout":"kiro-cli 2.6.0\n","stderr":""}
$ agentcore exec --json --runtime arn:aws:bedrock-agentcore:us-west-2:123456789012:runtime/<RUNTIME_ID> "aws --version"
{"success":true,"exitCode":0,"stdout":"aws-cli/2.34.63 Python/3.14.5 Linux/6.1.161-18.298.amzn2023.aarch64 exec-env/AWS_BedrockAgentCore_Runtime exe/aarch64.debian.12\n","stderr":""}
Lambda 版との比較
以前、Lambda で Kiro CLI を動かす記事を公開しました。
Lambda 版は非対話モード・API キー認証専用です。PTY がないため対話モードは成立せず、実行中の CLI に人間が入って操作することもできません。AgentCore Runtime のインタラクティブシェルでは対話モード・デバイスコード認証が加わり、Kiro CLI のユースケースが広がります。
使い分けの目安
Lambda が向いているケース
- 散発的な呼び出し(1日数回、イベントドリブン)
- 15分以内で完了するタスク
- CI/CD パイプラインへの組み込み
AgentCore Runtime が向いているケース
- 対話モードで人間とやり取りしながら作業する
- 15分を超える長時間タスク
- I/O 待ちが多いワークロード(LLM 応答待ちの間は CPU 課金されない)
- チームで同じ環境を共有したい
共通点
- 使っていないときはコンピュート課金が発生しない(セッション終了後。ただし ECR・S3 等の周辺リソースは別途課金されます)
- コールドスタートはどちらも発生する
- ヘッドレスモード・use_aws・IAM 制御はどちらでも使える
料金の詳細は公式の料金ページを確認してください。
後片付け
# パターンA: CloudFormation スタック削除(Runtime + IAM ロール含む)
aws cloudformation delete-stack --stack-name AgentCore-StrandsShellTest-default --region us-west-2
# パターンB: Runtime 削除
aws bedrock-agentcore delete-runtime --runtime-id <RUNTIME_ID> --region us-west-2
# パターンB: ECR リポジトリ削除(starter-toolkit がデフォルトで作成する名前)
aws ecr delete-repository --repository-name bedrock-agentcore-agent --force --region us-west-2
# パターンB: CodeBuild プロジェクト削除
aws codebuild delete-project --name bedrock-agentcore-agent-builder --region us-west-2
# パターンB: CodeBuild ソースバケット削除
aws s3 rb s3://bedrock-agentcore-codebuild-sources-123456789012-us-west-2 --force
# パターンB: IAM ロール削除(ポリシーをデタッチしてから削除)
ROLE_NAME="AmazonBedrockAgentCoreSDKRuntime-us-west-2-<SUFFIX>"
aws iam list-attached-role-policies --role-name $ROLE_NAME --query 'AttachedPolicies[].PolicyArn' --output text \
| xargs -n1 aws iam detach-role-policy --role-name $ROLE_NAME --policy-arn
aws iam delete-role --role-name $ROLE_NAME
ROLE_NAME="AmazonBedrockAgentCoreSDKCodeBuild-us-west-2-<SUFFIX>"
aws iam list-attached-role-policies --role-name $ROLE_NAME --query 'AttachedPolicies[].PolicyArn' --output text \
| xargs -n1 aws iam detach-role-policy --role-name $ROLE_NAME --policy-arn
aws iam delete-role --role-name $ROLE_NAME
# SSM パラメータを作成した場合
aws ssm delete-parameter --name "/kiro/headless/api-key" --region us-east-1
まとめ
AgentCore Runtime のインタラクティブシェルで Kiro CLI を動かしてみました。Lambda 版では PTY がないため使えなかった対話モードと、通常の CLI ログインフローとして扱えなかったデバイスコード認証が、インタラクティブシェルでは自然に動作しました。use_aws ツールも execution_role の権限で機能し、IAM による権限制御も確認できました。
一時的な検証ならパターンAの直接インストール、継続利用ならパターンBの Dockerfile へのプリインストールが向いています。今回は基本動作を確認できたので、次はより実践的なユースケースでの活用方法を検証してみたいと思います。









