Kiro Cloud Sessions の前提条件と、サンドボックスの中身

 こんにちは～　浮田です。  

■  TL;DR

• 2026年8月11日、Kiro CLI 2.17.0 のプレビュー機能として Cloud Sessions が公開されました。kiro-cli chat --cloud でクラウドの隔離サンドボックスにエージェントを立て、ターミナルを閉じても動き続け、--resume-id で別マシンから戻れる機能です
• 叩いてみたら起動するまでに3回転びました。app.kiro.dev 側のプラン、管理者トグル、GitHub App 連携。3つ揃わないと起動しません
• 一番時間を溶かしたのが管理者トグルです。CLI は「kiro-cli login しろ」としか言ってこないので、何度ログインし直しても直りません。手がかりは kiro-cli diagnostic の remote-sessions-endpoint-configured = false でした
• サンドボックスの正体は us-east-1 の EC2 上の Linux コンテナでした。ホスト名は ip-10-1-11-123.us-east-1.compute.internal
• そして本日のオチ。サンドボックスから AWS は触れません。認証情報が無いだけでなく、sts.amazonaws.com への通信自体が Squid プロキシに 403 で弾かれます。「鍵が無い」ではなく「鍵もなければドアも閉まっている」
• 結論：Cloud Sessions は「自分の環境をクラウドに引っ越す」機能ではなく、「エージェントだけを出張させる」機能です。持っていけるのはリポジトリに入っている設定だけで、手元のものは置いていくことになります

■  目次 

1. はじめに
2. Cloud Sessions とは、ざっくり
3. 起動するまでに3回転んだ
4. ようやく起動した ― サンドボックスの正体
5. 本題：ターミナルを閉じてもエージェントは動き続けるのか
6. CLI で投げて、Web で見て、別マシンで続ける
7. 設定が「半分だけ」ついてくる
8. 鍵が無いどころか、ドアが閉まっていた
9. 詰まったところまとめ
10. Kiro Crew との使い分け
11. まとめ

■  はじめに

Cloud Sessions が出たと聞いて、正直、機能そのものより先に気になったことがありました。

「そのサンドボックス、中はどうなってるんだ？」

マネージドと言われると急に中身が見えなくなるような感じがしませんか？

どこで動いていて、何が入っていて、どこまで手が届くのか。

特に気になったのは、そのサンドボックスから自分の AWS アカウントを触れるのかどうかでした。

触れるなら夢が広がるし、触れないならその閉じ方が知りたい。

というわけで叩いてみたんですが、中を覗く前に3回転びました。

検証環境

■  Cloud Sessions とは、ざっくり  

普段の kiro-cli chat は、当たり前ですが自分の PC の上でエージェントが動いています。

--cloud を付けると、エージェントの居場所がクラウドのサンドボックスに移ります。

言葉より表のほうが早いので、実際に触って確かめた差分を先に置いておきます。

下2行がこの記事の後半で効いてきます。ここを「クラウドに自分の環境が立つ」と読んでしまうと、後で必ずズレます。

たとえるなら引っ越しではなく出張です。

会社の資料（リポジトリに入れてある .kiro/）は鞄に入れて持っていける。

でも自宅の机の引き出しに入れてある自作のメモ（~/.kiro/）は、当然ながら持っていきません。出張先には机も椅子もあるけど、自分の引き出しの中身は無い。

この感覚を先に持っておくと、この後の挙動が全部きれいに説明できます。

■  起動するまでに3回転んだ  

Cloud Sessions を使うには、以下の3つがすべて揃っている必要があります。

1つでも欠けると起動しません。  

●   前提条件①：Kiro Pro 以上のプラン（app.kiro.dev 側）  

app.kiro.dev を開いたらこう言われました。

Upgrade to unlock Kiro Web Kiro Web is available on Pro, Pro+, and Power plans.

ここで「え？」となりました。IAM Identity Center 経由で Q Developer Pro は契約済みだったからです。

私の環境では、IAM Identity Center 側で Pro を契約していても app.kiro.dev 側のサブスクリプションは Free のままで、このメッセージが出ました。

公式ドキュメントでも Cloud Sessions の要件は「Pro 以上」と書かれているので、判定に使われるのは app.kiro.dev 側のプランだと理解しています。

普段 IAM Identity Centerでログインして使えている人間からすると「自分は Pro のはず」という思い込みから抜けにくいところでした。同じ環境の人は、まず app.kiro.dev の課金画面を開いてみてください。

●   前提条件②：管理者トグル「Cloud Sessions (Preview)」の有効化  

 プランを上げても、まだ動きません。IAM Identity Center 組織の場合、AWS コンソールの Kiro 設定画面で「Cloud Sessions (Preview) – formerly Kiro Web」のトグルを ON にする必要があります。

このとき CLI が出すエラーがこれです。

Authentication required or access denied. Run kiro-cli login in a new terminal, then retry.

……kiro-cli login をやれと言われたので、素直に何度もやりました。直りませんでした。

このメッセージ、管理者トグルの存在を一切示唆してくれません。

「認証が必要か、アクセスが拒否された」としか言っていないので、ログイン周りをひたすら疑い続けることになります。ログインし直せと言われて、ログインし直して、また同じことを言われる。この往復がいちばん時間を溶かしました。

決定打はこれでした。

kiro-cli diagnostic
※Kiro CLI の診断情報を一括で吐き出すコマンド

出力の中に、こういう項目があります。

remote-sessions-endpoint-configured = false

False。認証の問題ではなく、リモートセッションのエンドポイントがそもそも構成されていない。

ここでようやく「自分のログインの話じゃないんだ」と気づけました。

この一行に辿り着ければ、こっちのものです。あとは AWS コンソール側を疑うだけです。

画像の赤枠の部分をONにしてください。

もっとも、この項目も管理者トグルを直接示唆してくれるわけではありません。

エラーメッセージから設定画面まで、素直な導線は今のところ無いと思っておいたほうがいいです。

しかもこのトグル、名前をよく見ると formerly Kiro Web と書いてあります。旧「Kiro Web (Preview)」からのリネームです。

つまり過去に Kiro Web を有効化していた組織はそのまま使えて、触った記憶のない組織は無効のまま。管理者本人が「そんな設定した覚えないぞ」となるやつです。

なお私の環境では、トグルを有効化した後に再ログイン（kiro-cli logout → kiro-cli login）してから通るようになりました。

ただし正直に書いておくと、単に時間経過で反映されただけの可能性も否定できません。切り分けきれていないので、断定はしないでおきます。

●   前提条件③：GitHub App「Kiro-Agent」のインストール  

3つ目。Cloud Sessions はリポジトリをサンドボックスにクローンして動くので、GitHub（または GitLab）との連携が必須です。

Source provider not found
Cloud sessions require a source provider.
Connect one on kiro.dev: https://github.com/apps/Kiro-Agent/installations/new

これは親切でした。URL まで出してくれるので、踏んでインストールすれば終わりです。

前2つがこのくらい親切だったら、いいのに。（笑）

■   ようやく起動した ― サンドボックスの正体  

3つ揃えて、ようやくです。

kiro-cli chat --cloud --repo <対象リポジトリ>

--repo はヘルプ上 optional で、セッション内の /repo コマンドからも選べます。ただ最初から指定しておくとクローン対象が確定するので、迷いがなくておすすめです。

☁️ Cloud (Preview) · ~/kiro/ <フォルダ名> というプロンプトが出れば成功です。

ここまで長かった。

さて、せっかくクラウドの実行環境が手に入ったので、中を覗いてみます。

ここからが個人的に一番楽しいパートです。

$ pwd
/projects/sandbox/kiroblogs

$ cat /proc/sys/kernel/hostname
ip-10-1-11-123.us-east-1.compute.internal

いきなり小さな引っかかりポイントです。

プロンプトには ~/kiro/kiroblogs と出ているのに、pwd は /projects/sandbox/kiroblogs を返します。

プロンプトのほうは表示用の論理パスで、ファイルシステム上の実体はこちらでした。

エージェントにパスを指定して何かさせるときは、pwd の値のほうを見てください。

hostname コマンドは入っていなかったので、/proc から直接読みました。返ってきたのがこれです。

ip-10-1-11-123.us-east-1.compute.internal。

これはなんか見覚えがあるようなないような、、。us-east-1 の EC2 のプライベート DNS 名そのものですね。

つまり Cloud Sessions のサンドボックスは、us-east-1 の EC2 の上で動く Linux コンテナでした。

マネージドと言われると中身がブラックボックスに思えますが、覗いてみればいつもの EC2 だった。ここは普通に嬉しかったです。

環境変数も見てみます。

$ env | grep

AWS
AWS_EC2_METADATA_DISABLED=true

AWS_DEFAULT_REGION=us-east-1

AWS_REGION=us-east-1

AWS_EC2_METADATA_DISABLED=true。

明示的にメタデータが無効化されています。EC2 の上で動いているのに、メタデータサービスへの道は塞いでありました。

■  本題：ターミナルを閉じてもエージェントは動き続けるのか  

ここからが本題です。これができないと Cloud Sessions を使う意味がありません。

手順はこうしました。

1. --trust-all-tools を付けて起動（承認待ちで止まったら検証にならないので）
2. ファイル3つを作るタスクを投入
3. エージェントが作業を始めたのを確認
4. ターミナルウィンドウを×ボタンで閉じる（Ctrl+C ではありません。理由は後述）
5. 1分後に --resume-id で復帰

戻ってみたら、3ファイルすべてが作成済みで status=completed になっていました。会話履歴にはファイル書き込みと ls -la の実行ログが残っていて、切断した後もエージェントが作業を進めていたことが分かります。ちゃんと動いてる。

ただ、ここは正直に書いておきます。

今回のタスクは数十秒で終わる軽いものだったので、「閉じる前にはもう完成していた」可能性を完全には潰せていません。厳密にやるなら sleep を挟んだ重いタスクにするか、復帰後に ls -la --time-style=full-iso でタイムスタンプを見て「閉じた時刻より後に作られている」を示すべきでした。

ここは検証としての詰めが甘かった点として残しておきます。

●   Ctrl+C だと結果が変わります  

別の試行で、タスク実行中に Ctrl+C を押して抜けたことがありました。そのときはこうなりました。

● Cancelled

復帰後にエージェントに「できた？」と聞いたら「まだ作成していませんでした」。

タスクが死んでいました。

これ自体は Cloud Sessions 固有の挙動ではありません。Kiro CLI では Ctrl+C は昔から「実行中タスクのキャンセル」です。仕様どおりです。

問題は、クラウドだと失うものが大きいことです。

ローカルセッションなら、そもそも切断＝終了なので Ctrl+C でも×でも大差ありません。でもクラウドでは「離席しても走り続ける」が売りなので、Ctrl+C を押すか×を押すかで結果がまるで変わります。

理屈は通っています。Ctrl+C はユーザーが明示的に「やめろ」と言っているシグナルで、×は接続がロスしただけ。「意図的な中止」と「接続が切れた」をちゃんと区別しているわけで、設計としてはむしろ正しい。

正しいんですが……ターミナルを抜けるとき、反射で Ctrl+C 押しませんか。私は押します。走らせたまま離席したいなら、×で閉じる。指が覚えるまでは少しかかりそうです。

■  CLI で投げて、Web で見て、別マシンで続ける  

Cloud Session は「クライアントから独立して存在する」ので、CLI で作ったセッションが Web UI にもそのまま出てきます。

実際に、CLI で起動してファイル作成を終えたセッションを app.kiro.dev/session/<SESSION_ID> でブラウザから開いてみました。

会話履歴も、作成されたファイルも、クレジット消費量もそのまま表示されます。

しかも Web UI 側からプロンプトを入力すれば、同じサンドボックスに対して操作できます。 

地味にすごいのがここで、「CLI で投げて、外出先で Web から進捗を確認して、別マシンの CLI で続きをやる」が普通にできてしまいます。

セッションがクライアントではなくクラウド側に住んでいるという設計が、体験としてちゃんと効いていました。ここは触っていて一番気持ちよかったところです。

■  設定が「半分だけ」ついてくる  

Cloud Session を起動すると、毎回このメッセージが出ます。

Your cloud workspace doesn't have your local setup by default. Go to app.kiro.dev/settings/cloud-config to bring your

agents, MCP servers, hooks, and steering from ~/.kiro/ (home directory) to the cloud.

最初は「なんか英語書いてるな～」と読み飛ばしていました。読み飛ばしてはいけないやつでした。

• リポジトリの .kiro/ 配下（steering、spec、hooks、MCP）→ クローンと一緒に付いてくる
• ~/.kiro/（ホームディレクトリ）の個人設定 → 付いてこない
  

厄介なのは、エラーにならず、黙って素の状態で動くことです。

落ちてくれたら気づけるんですが、普通に返事をしてくるので気づけません。いつもと微妙に違う挙動をするエージェントと、気づかないまま作業を進めることになります。

対策としては app.kiro.dev/settings/cloud-config でクラウド用の設定を別管理できます。

ただしローカルとの同期は手動なので、ローカルの steering を育てている人は二重管理になります。

ここで冒頭の「出張」の話に戻ります。

Kiro の設定スコープの分離（プロジェクト設定とパーソナル設定）が、そのままクラウドとの境界線になっている。

ローカルで使っている限り、この2つの区別なんて意識しません。実行場所が変わった瞬間に、その区別が実害として出てくる。

設計を知っていれば読めた話で、当時の自分に教えてあげたいです。

■  鍵が無いどころか、ドアが閉まっていた    

AWS のブログを書いている人間として、ここが一番気になっていました。

このサンドボックス、私の AWS アカウントを触れるのか？

企画の段階では、こう予想していました。

「Kiro のサンドボックスのネットワーク許可リストには amazonaws.com が入っているはずだから、ネットワークは通る。あとは認証情報を渡すかどうかの話だろう」と。

叩いてみます。

$ aws sts get-caller-identity

Unable to locate credentials.

はい、認証情報はありません。ここまでは想定どおり。

AWS CLI 自体はインストールされているのに、鍵だけが無い状態です。

では、ネットワークはどうか。

$ curl -I https://sts.amazonaws.com

HTTP/1.1 403 Forbidden
Server: squid/6.13
X-Squid-Error: ERR_ACCESS_DENIED 0
Via: 1.1 ip-10-1-197-180.ec2.internal (squid/6.13)

403。

しかも返してきているのは AWS ではありません。squid/6.13 です。

同一 VPC 内に立っている Squid プロキシ（ip-10-1-197-180.ec2.internal）が、sts.amazonaws.com への通信を許可リスト外として弾いています。AWS のエンドポイントにはそもそも届いていない。

当初の目論見は完全に外しました。でも外れ方が面白かったです。整理するとこうなります。

つまりサンドボックスは三重にガードされています。

1. AWS 認証情報を注入しない
2. EC2 メタデータを明示的に無効化する（AWS_EC2_METADATA_DISABLED=true）
3. AWS エンドポイントへのネットワーク到達をプロキシで遮断する

先ほど見た AWS_EC2_METADATA_DISABLED=true が、ここで効いてきます。

EC2 の上で動いているコンテナなので、放っておくとメタデータ経由でホストのロールを拾えてしまうかもしれない。

そこを明示的に塞いである。1と3だけでは足りないと分かっていて、2を足している。この徹底ぶりを見て、「なるほど、そこまで考えてるのか」と少し感心しました。

「ネットワークは開いているが鍵が無い」ではなく、「鍵もなければドアも閉まっている」。ホテルの部屋は貸すけど、金庫の鍵は渡さないし、そもそも金庫のある部屋には行けない、みたいな状態です。

不便ではあります。でも納得もしています。

Cloud Sessions は他人のインフラの上で、こちらの承認を待たずに走る実行環境です。そこに AWS 認証情報が自動で入っていたら、それはそれで怖い。

既定で全部閉じておくというのは、プレビュー機能としては真っ当な判断だと思いました。

裏を返せば、AWS リソースを操作させたいなら、現時点では Cloud Sessions ではないということでもあります。

■  詰まったところまとめ  

特に②です。エラーメッセージが「kiro-cli login しろ」と誘導してくるので、何度ログインし直しても解決しません。ログイン地獄に入りかけたら、まず kiro-cli diagnostic を叩いてください。

■  Kiro Crew との使い分け  

※ Crew 側は今回未検証です。以下は公式ドキュメントに基づく比較です。

ざっくり言うと、Cloud Sessions は「エージェントをサッと出張させる」、Kiro Crew は「自分のインフラにエージェントを住まわせる」。

AWS リソースを触らせたいなら、現時点では Crew 一択です。

■  まとめ  

一番の収穫は、Cloud Sessions が移してくれるのは「エージェントの実行場所」だけで、「自分の環境」は移してくれないと腑に落ちたことでした。

リポジトリの .kiro/ は付いてくる。~/.kiro/ は付いてこない。

AWS の認証情報も付いてこないし、そもそもネットワークすら通っていない。引っ越しじゃなくて出張なんだ、と理解した瞬間に、観測した挙動が全部つながりました。

そして当初の目論見は完全に外しました。

「AWS のリソースを触らせて遊ぼう」と思って入ったら、鍵も無ければドアも閉まっていた。

でも、EC2 の上のコンテナで、メタデータを明示的に切って、Squid で外向き通信を絞る。閉じ方そのものが具体的に見えたのは、外した目論見の代わりとしては悪くない収穫でした。

本記事の内容は 2026年8月18日時点、kiro-cli-chat 2.18.1 での検証結果に基づきます。Cloud Sessions はプレビュー機能のため、今後の更新で仕様が変更される可能性があります。