猫でもわかるKiro Web ― 端末を閉じても働き続けるKiroの正体

Last updated at 2026-09-28Posted at 2026-09-28

はじめに

2026年9月26日のJAWS-UG 栃木オフライン #10 -秋の登壇祭り-で、「猫でもわかるKiro Web」というテーマで10分登壇しました。本記事は、その発表内容を資料を開かなくても理解できるように再構成した紹介記事です。

発表資料はこちらです。

地域支部に参加する楽しみの一つは、その土地の美味しいものを食べることです。今回は栃木支部運営さんが「小山のランチスポット情報」を事前に周知してくださったので、その中で気になったお店で昼食を済ませてからの参戦としました。

内容は2026年9月26日時点のスナップショットです。Kiroは更新が非常に速く、特にKiro CLI v3、Kiro Web、Kiro Mobile、Kiro Crewは変更が続いています。実際に使うときは、利用中のバージョンと最新の公式ドキュメントを確認してください。

本記事のサンドボックスのスペック（CPU、メモリ、ストレージ、Docker、Bubblewrap）は、Kiro Web上でKiro自身に調べさせた実機調査の結果です。公式には公表されていない情報なので、いつ変わってもおかしくないものとして読んでください。

私はこれまでKiro CLI（旧Amazon Q Developer CLI）を推し活してきましたが、今回はKiro Webの推し活です。

今回伝えたかったことは、大きく以下の3つです。

Kiroは形態ごとに別々だったエージェント本体を「統一エージェントハーネス」へ一本化しつつある。Kiro Webは公開当初からこの新系列で提供されている
Kiro WebはAWSクラウド上の隔離されたサンドボックスで動くKiroで、端末を閉じても働き続ける。開発に十分なスペックの環境が追加料金なしで使える
Automation（スケジュール実行）とKiro Mobileを組み合わせると、物理マシンを用意しなくても「勝手に働き続けるKiro」が作れる。Kiro Crewを入れる前に、Kiro Webで足りないか考える価値がある

一言でまとめると、Kiro Webは「物理マシンなしで働き続けるKiro」であり、Kiro Crewの前にまず試して欲しい選択肢だということです。

前提①：最近の注意事項 ― GPT-5.6系のCreditsが変更（値上がり）されました

本題の前に、Kiroを使う上で最近気をつけて欲しい話です。

2026年9月14日に、KiroでのGPT-5.6系（Sol / Terra / Luna）のCredits体系が変更されました。1Mトークンのコンテキストに対応した代わりに、倍率が上がっています。

時期	Sol	Terra	Luna	コンテキスト / 課金
2026-07-14 提供開始	2.4x	1.2x	0.6x	272K固定・単一レート
2026-07-31 引き下げ	2.4x	1.0x	0.1x	272K固定・単一レート
2026-09-14 1M対応（272K以下）	4.4x	2.2x	1.1x	1M・short rate
2026-09-14 1M対応（272K超）	8.8x	4.4x	2.2x	1M・shortの2倍

いままでGPT-5.6 Lunaを使って節約志向だった方が、一番ダメージを受けます（0.1x → 1.1xで11倍）
Kiro CLIの/modelコマンドで表示されるCredits情報では、272K超でshortの2倍になることが省略されています
Amazon Bedrock側のGPT-5.6は8月3日時点で1M対応済みですが、こちらは値上げされていません

補足: 公式のAvailable modelsページには、272Kトークンまではshort context rate、272Kトークン超はその2倍（Sol 8.8x、Terra 4.4x、Luna 2.2x）で課金されると明記されています。1Mコンテキストの対象はIDE、CLI、Webの3形態です。

前提②：Kiro 5兄弟のいま

Kiroには2026年9月時点で、IDE、CLI、Web、Mobile、Crewの5つの形態があります。私は「Kiro 5兄弟」と呼んでいますが、これは公式用語ではなく私の整理です。

5つのうち3つは改名、または前身を持っています。誕生順に並べると次の通りです。

日付	出来事
2025-07-14	IDE プレビュー（waitlist制）
2025-11-17	IDE / CLI GA。CLIはAmazon Q Developer CLIから改名
2025-12-02	Webの前身「Kiro autonomous agent」
2026-04-13	CLI v2.0.0リリース。Windowsネイティブ対応
2026-05-07	Kiro Web（Preview）発表
2026-06-17	Kiro Mobile（iOS）（Preview）発表
2026-07-14	IDE v1.0リリース
2026-08-04	Kiro Crew発表（Amazon社内の「MeshClaw」という個人プロジェクトが出発点）
2026-09-01	Kiro Web GA

2026年9月26日時点の各Kiroのバージョンは次の通りです。

形態	最新バージョン	最新リリース日	備考
IDE	v1.1.70	2026年9月24日	ー
CLI	v2.23.1	2026年9月23日	v3.0.0リリース間近。Early Accessは`--v3`オプションで起動
Web	ー	2026年9月22日	バージョン番号は付与されない。最新リリース日はChangelog掲載日
Mobile	1.0（Build 30）	2026年9月18日	プレビュー。メールでの招待制
Crew	v0.7.0	2026年9月25日	ー

Kiro Webだけバージョン番号がありません。ブラウザで使うSaaSなので、利用者側でバージョンを選ぶ余地がなく、Changelogの掲載日で追いかけることになります。

① IDEとCLIが抱えていた問題と、統一エージェントハーネス

長男IDEと次男CLIの間にあった溝

同じKiroという名前でも、IDEとCLIには次のような違いがありました。

論点	IDE	CLI	何が困るか
セッションの保存形式	独自	独自	セッションを入口間で移動させることが構造的に不可能
権限設定の書き方	前方一致の`trustedCommands`と部分一致の拒否リスト	正規表現の`allowedCommands` / `deniedCommands`	同じ意図の設定を2回、違う文法で書く必要がある
コンパクション（要約）戦略	独自	独自	会話が長引くと、形態によって挙動が変わる
機能の偏り	Spec駆動開発、Powers	プランモード、コード解析	片方でしか使えない機能がある

補足: カスタムAgent機能は、IDE v1.0リリース時に実装済みです。

Webを公開する前に、3つあったハーネスを1つにした

Kiro Webを一般公開する前、Kiroは形態ごとに別々のエージェント本体（ハーネス）を持っていました。公式ブログ「One agent, every surface」によると、その内訳は次の通りです。

#	形態	言語	理由
1	IDE	TypeScript	VS Code OSSの拡張モデルに合わせるため
2	CLI	Rust	性能のため
3	Web（公開前）	Python	最新のエージェント研究に近い環境のため

Web版を独自エージェントのまま一般公開すると、今後3系統分の重複コストを払い続けることになります。そこでKiroは、1つのハーネスに統合してから公開する道を選びました。

統一エージェントハーネスとACP

用語を2つだけ押さえておきます。

ハーネス（harness）：Kiroの頭脳。AIエージェント本体で、独立したプロセスとして動く。会話履歴、ツール実行、コンテキスト管理、権限評価、LLMプロバイダとの通信を担当する
ACP（Agent Client Protocol）：頭脳と画面（IDE、CLI、Web、Mobile）をつなぐ共通の通信プロトコル

頭脳がどこで動くかで、2つに分かれます。

頭脳が動く場所	画面	ACPの通り道	何をするか
ローカル（PC、EC2）	IDE（v1.0〜）、CLI（v3〜）	stdio	ローカルのファイル・シェルを操作
クラウド（サンドボックス）	Web、Mobile	WebSocket（Kiro独自拡張）	リポジトリをclone、変更はPRで返す

補足: 公式ドキュメント「How Kiro works」の“Where the agent runs”に、この分け方が説明されています。

ユーザから見ると、IDEとCLIにとっては破壊的変更です。移行のされ方は形態ごとに違います。

#	形態	旧系列	新系列	移行のされ方
1	IDE	0.x	v1.0（公開済み）	自動更新が段階的に配信中
2	CLI	2.x	v3（早期アクセス）	`kiro-cli --v3`で自分からオプトイン
3	Web	未公開版	公開版	リリース当初から統一エージェントハーネス
4	Mobile	ー	1.0（Build 28〜）	同上

つまり、Kiro Webは旧系列を経験していない、最初から新系列の子です。IDEやCLIのように「どのエンジンで動いているか」を気にする必要がありません。

② Kiro Webの特徴

ブラウザから使えるKiro

Kiro Webは、ブラウザから使えるKiroです。ローカルPCにIDEを入れずに、AWSクラウド上の隔離されたサンドボックスでエージェントに開発作業をさせられます。

観点	内容
入口	ブラウザ（app.kiro.dev）
実行場所	AWSクラウド上のサンドボックス（us-east-1）
ハーネス	最初から統一エージェントハーネスの系列
利用条件	2026年9月時点では有料プラン（Pro、Pro+、Pro Max、Power）が必要。無料枠では使えない
リポジトリ連携	GitHub、GitLabとの連携が前提
成果物の返し方	ブランチを作ってPull Requestを開く

実装をクラウドへ委任しやすい一方で、リポジトリ連携の範囲や実行権限は、事前に確認して使うのが大切です。

補足: 公式のSetup & First Runでは、GitHubはKiro Agent GitHub appの認可、GitLabはPersonal Access Tokenで接続します。エージェントがブランチ作成・PR作成をするには、リポジトリへの書き込み権限が必要です。また、エージェントはリポジトリ内の指示（悪意あるものを含む）を読んで従うため、信頼できるリポジトリだけを選ぶよう警告されています。

サンドボックス内のファイル構成

サンドボックスにファイルを置く方法は3つあります。

Kiroに作らせる
ローカルからアップロードする
GitHub・GitLabからクローンする

GitHubリポジトリをクローンすると、次のように配置されます。

GitHub: kamogashira-sys/test-repository
  ├── .git/
  ├── .gitignore
  ├── README.md
  ├── hello.py
  └── test_hello.py

        │ Clone
        ▼

サンドボックス: /projects/sandbox/test-repository
  ├── .git/
  ├── .gitignore
  ├── README.md
  ├── hello.py
  └── test_hello.py

パスはセッション単位で/projects/sandbox/*に作られます。実機で確認した範囲では、同時に動かせるタスクは10件でした。

経済化を目指すならKiro Webがおすすめの理由

ここが今回の目玉です。

AWS EC2（us-east-1）上のサンドボックスのスペックは、公式には公表されていません。そのため、Kiro Web上でKiro自身に調べてもらいました。実機調査であり、公式非公表である点に注意してください。

構成は、外側から順に次の3層でした。

ホストマシン：AWS EC2
  └── Dockerコンテナ（OS：Amazon Linux 2023）
        └── Bubblewrap（bwrap）による追加の隔離層
              └── 実際に動いているプロセス・シェル

Dockerコンテナの上に、さらにBubblewrap（bwrap）で隔離層を作る二重の安全対策になっています。

スペックは次の通りです。

項目	内容	備考
CPU	4コア8スレッド（試した限りではIntel、AMDのx86_64）	Arm系が割り当てられるかは未確認
メモリ	30GiB（起動直後で1.3GiBほど使用）	ー
ストレージ	メインボリューム（`/projects`等）：125GB サンドボックスワークスペース（`/projects/sandbox`）：89GB	`/dev/nvme1n1`（メイン）と`/dev/loop0`（ワークスペース）を個別にマウント

開発には十分なスペックの環境が、プラン料金の範囲内で追加料金なしに使えます。ローカルPCのスペックや、常駐マシンの電気代を気にしなくてよいのは大きな利点です。

補足: 公式のSandboxページでは、タスクごとにサンドボックスを起動し、認可済みリポジトリをclone、タスク完了後に破棄する流れと、headless Chrome・Playwright MCP・Chrome DevTools MCPがプリインストールされていることが説明されています。スペックの記載はありません。

「サンドボックスだから何でもOK」ではない

サンドボックスは使い捨ての箱であって、渡したSecretsやIAM権限の強さまで自動で適正化してくれる機能ではありません。この点は前回記事「Kiro５兄弟のいまどきのセキュリティ基礎知識」で詳しく書いたので、Kiro Webへ本気で委任する前にそちらも読んでもらえると嬉しいです。

③ Kiro Webを「働き者」にする：Automation、Mobile、実例

スケジュール実行したいならAutomationがある

Kiro Webには、プロンプトをスケジュール実行するAutomationがあります。人がセッションを開始しなくても、決めた時刻にエージェントがリポジトリに対して作業し、必要ならPull Requestを開いてくれます。

1つのAutomationに最大5つのスケジュールを追加でき、形式は次の3つです。

形式	内容	例
時間単位（Hourly）	1時間〜の間隔で毎時0分に実行	6時間ごと
毎日（Daily）	指定した時分に1日1回	毎日 6:00
CRON	cron式で自由に指定	`cron(0 13 * * ? *)`

補足: 公式のAutomationsページによると、スケジュールはUTCで評価されます（一覧画面にはローカル時刻とUTCが併記されます）。カスタムスケジュールの最短間隔は1時間で、それより短いcron式は送信できません。プロンプトは最大10,000文字です。Automationの実行結果は通常のセッションと同じ一覧に並ぶので、何をしたかを後から追えます。

外出先でiPhoneから作業状況を確認したい

Kiro Mobile（プレビュー版、今はiOSのみ）を使うと、外出先から進捗を確認できます。

設定が楽
Kiro Webとほぼ同じ機能
Autonomousモードのon/offが可能
Build with specのon/offが可能

Kiro Mobileは「スマートフォンでコードを書くIDE」ではありません。Kiro Webと同じクラウドセッションを見る2つ目の窓です。

補足: 公式のMobileページは2026年9月時点で「Documentation coming soon」で、Apple TestFlight経由の早期アクセスとして提供されています。セッションと設定はKiro Webと同期されます。

私の作ったKiro Web上のアプリ：Kiro公式更新チェック

Automationの実例として、私が作った「Kiro公式更新チェック」を紹介します。

毎日6時にKiro公式サイトのRSSをチェックし、前日との差分をSlackへ通知する
ワークフローは日本語のプロンプトで指示している
要約された情報がSlackに届く

Kiroは更新が非常に速いので、毎朝Slackを見れば追いつける状態を、物理マシンなしで作れました。

補足: スケジュールはUTC評価なので、日本時間の6時に動かしたい場合は前日21時（UTC）に設定します。cron式ならcron(0 21 * * ? *)です。

そのKiro Crew、本当に必要ですか？

Kiro Crewは、自分のPCやサーバーでGatewayを常駐させてKiro CLIを駆動する「住み込み」型のオーケストレータです。Slack連携やcronなど魅力的な機能がありますが、常駐させる物理マシンが必要です。

Kiro Webの方がいい場合があります。比較すると次の通りです。

観点	Kiro Web（＋Automation、Mobile）	Kiro Crew
実行場所	AWS上のサンドボックス	自分のPCやサーバー
物理マシン	不要	必要（常駐）
スケジュール実行	Automation（ネイティブ対応）	cron
外出先からの確認	Kiro Mobile	Slackなどのチャネル
分離単位	タスクごとに使い捨て	単一の常駐Gateway
成果物	Pull Request	ローカルの変更、チャネルへの返答
向いている用途	リポジトリに対する定期作業、PRベースの開発委任	ローカル環境に常駐させたい、チャネル連携中心の運用

補足: Kiro CrewとKiro Webのサンドボックスの違い（隔離と遮蔽、常駐と使い捨て）は、前回記事で詳しく比較しています。

「定期的にリポジトリを見てPRを出して欲しい」「外出先から進捗を見たい」程度なら、Kiro Web＋Automation＋Mobileで足ります。物理マシンが不要なのが最大のポイントです。

実務で確認するチェックリスト

始める前に

有料プラン（Pro以上）に加入しているか。無料枠ではKiro Webは使えない
GitHub / GitLabの連携で、エージェントに見せるリポジトリを必要最小限に絞ったか
エージェントがブランチ作成・PR作成できる書き込み権限があるか
信頼できないリポジトリ（悪意ある指示を含む可能性）を混ぜていないか

サンドボックス

サンドボックスのスペックは公式非公表であり、変わり得ることを理解したか
渡すSecrets、環境変数、IAM権限は必要最小限か
ネットワークの許可先（Internet Access設定）を確認したか
MCPサーバーを追加する場合、それがサンドボックスの制限の外側で動き、エージェントと同じ権限でコード・Secrets・認証情報にアクセスできることを理解したか（信頼できレビュー済みのものだけ追加。出典）

Automation

スケジュールがUTCで評価されることを踏まえて時刻を設定したか
「該当する作業がなければ何もしない」という条件をプロンプトに入れたか（空PRの防止）
実行結果のセッションを定期的に確認しているか

まとめ

今回の結論を以下の3点に戻ってまとめます。

ハーネスは、IDE、CLI、Webとも同じ統一エージェントハーネスへ向かっている。Kiro Webは最初から新系列なので、エンジンの違いを気にせず使える
Kiro Webは、端末を閉じても働き続ける働き者。サンドボックス環境（実機調査では4コア8スレッド、30GiB、125GB）はAWSさんの出血大サービスなので、感謝して常識の範囲で使う
スケジュール起動（Automation）にネイティブ対応し、Kiro Mobileを使えば外出先から進捗も確認できる。Kiro Crewを入れる前に、Kiro Webで足りないか考えてみる

Kiro 5兄弟はできる子です。しかし、全員に同じことをさせる必要はありません。

物理マシンを用意せずに、働き続けるKiroが欲しい。 そう思ったら、まずKiro Webを試してみてください。