この記事では、Kiro CrewをAmazon WorkSpacesのLinux（Ubuntu）環境にインストールした手順 を、どのステップにどれだけ手間がかかったのかも含めて、実際に踏んだとおりに残します。
動機は単純で、使ってみたかったから。手元にAmazon WorkSpacesのLinux版があったので、そこに入れました。
作業時間はトータルで30分くらい。そのうち大半は前提ミドルウェアの用意に消えて、Kiro Crew本体のインストールは1コマンドで終わります。
Kiro Crewとは
Kiro Crew は、AWSが2026年8月5日にオープンソース（Apache 2.0）として公開した、永続型の開発ワークスペースです。
「Claude CoworkのKiro版」というとイメージが近いかもしれません。
標準だとコマンドラインで動くKiro CLIを、ブラウザからも操作できるようにしたアプリといった位置づけです。
Kiro CLIとは別物というより、Kiro CLIをベースに、その上で動く管理基盤ですね。
ちなみに、Kiro Crewはもともと、Amazon社内で3人のエンジニアが始めた MeshClaw という個人プロジェクトだったそうです。
そこから6か月足らずで 社内39,000人を超えるビルダーが日常業務で使うツール になり、500人近いコントリビューターが597件の更新を、平均で週143コミットのペースで積み上げてきたとのこと。しかも参加者はエンジニアだけではなかったそうです。
AWS社内で十分に使い込まれてから公開されたツールということになります。
Kiro IDE / Kiro CLI との違い
Kiroファミリーを、使う人の視点で並べるとこうなります。
| 動く場所 | 主な使い手 | |
|---|---|---|
| Kiro IDE | エディタ | エンジニア |
| Kiro CLI | ターミナル | エンジニア |
| Kiro Crew | ブラウザ / Slack・Discord など | 職種を問わない |
技術的には、裏側でKiro CLIがエージェントのランタイムとして動き、Kiro Crewはその上でセッション・メモリ・スケジュール・承認を束ねる役割を担っています。
ポイントなのは、これまでのKiroからの 乗り換えではない という点。
既存の .kiro 設定（ステアリングファイル、スキル、カスタムエージェント）はそのまま持ち込めますし、Kiroを契約していればIDEもCLIもCrewも各自が好きに選べます。
Crewのために別契約を積む必要はありません。
Kiro Crewって何ができるの？
じゃあ、Kiro Crewを入れると何ができるの？という話ですが、
初期状態でいくつもの Apps（目的別の画面）が入っていて、代表的なものはこのあたりです。
| App | できること |
|---|---|
| Task Runner | 多ステップの仕事を計画→実行。走らせる前に計画をレビューできる |
| Meetings | 会議の文字起こしから議事録・図・タスク抽出を並列で |
| Research Lab | 問いをサブ問いに分解して調査。書き込み系ツールを持たないので放置しても安全 |
| PPTX Maker | チャットで説明すると本物の .pptx が返ってくる |
| Issue Radar | IssueやPRのトリアージ |
| Mochi | デスクトップに住むペット。実務ではない |
一番使い勝手がよさそうなのが「Schedule」です。cronでジョブを登録できて、たとえばこんな指定ができます。
kirocrew cron add "kiro-content-radar" "公式ブログとGitHubの新着を確認する" \
--cron "0 8 * * *"
GUIからも設定でき、好きなタイミングでKiro CLIにやってほしいことを指定できます。
登録したジョブには silent（変化がないときは黙る）、timezone、persistent_session（毎回まっさらなセッションで動かす）といったオプションを付けられます。ほかに、状態が変わるまで見張り続けるHeartbeatと、外部イベントをきっかけに動くWebhookもあります。
このcronやHeartbeatは、Kiro Crewが起動している間しか動きません。ローカルPCに入れて夜は電源オフという使い方だと、この機能は使えないことになります。
作ってみた環境情報
実際に構築した環境はこちらです。
| 項目 | 値 |
|---|---|
| OS | Ubuntu 24.04 LTS |
| kiro-cli | 2.20.2 |
| kirocrew | 0.4.1rc1 |
| インストール先 | ~/.local/bin/ |
WorkSpacesのバンドルはUbuntu 24.04 LTS（Standard、2vCPU / 4GiB）を選択しました。
Linuxのほうが設定がシンプルだなと思ったので。
Kiro Crewは複数のエージェントを並列で動かすため、Meetingsで議事録を回したり、Task Runnerで長い仕事を投げたりするなら、Performanceバンドル以上のほうが快適だと思います。
Kiro Crewを動かすのに必須のミドルウェア一覧
Kiro Crewを動かすには、事前にいくつかのミドルウェアをインストールしておく必要があります。
以下が、公式ドキュメント（https://kiro.dev/docs/crew/installation/ ）に記載されている前提条件です。
| ミドルウェア | 必須バージョン | 推奨バージョン | 用途 |
|---|---|---|---|
| Python | 3.10+ | 3.12 | バックエンドランタイム |
| Node.js | 22+ | 24 LTS | ダッシュボードのビルド（プリビルドwheelを使う場合は不要） |
| pipx | 任意 | 最新 | kirocrewのインストールに使用 |
| kiro-cli | 最新 | 最新 | LLMとの通信に必須 |
注意: プリビルドのwheelファイル（
curlインストールスクリプト経由）を使う場合、Node.jsは不要です。ソースからビルドする場合のみ必要です。
先にお伝えしておくと、Ubuntu 24.04のWorkSpacesを選んだ場合、この表のうち実際に追加インストールが必要なのはkiro-cliとpipxだけ でした。24.04には標準でPython 3.12が入っているからです。
一方、Ubuntu 22.04バンドルを選ぶとPythonが3.10なので、動作要件は満たすものの推奨バージョンには届きません。ここが最初の分岐点になります。
| バンドル | 標準Python | 追加作業 |
|---|---|---|
| Ubuntu 24.04 | 3.12 | 不要 |
| Ubuntu 22.04 | 3.10 | deadsnakes PPAから3.12を導入（後述） |
これから作るなら、24.04を選んでおくのが無難です。
手順0: 必須ミドルウェアのインストール
所要時間の目安：15〜20分
一番時間を食うのがこのステップです。逆に言うと、ここさえ抜ければ残りは10分程度で終わります。
Python 3.12 のインストール（Ubuntu/Debian）
Ubuntu 24.04を使っている場合は、まず入っているバージョンを確認してください。
python3 --version
# Python 3.12.3
3.12が返ってくれば、このセクションは丸ごとスキップできます。
Ubuntu 22.04など、3.10や3.11しか入っていない環境では、deadsnakes PPAから追加します。
# deadsnakesリポジトリを追加（Ubuntu）
sudo apt update
sudo apt install -y software-properties-common
sudo add-apt-repository ppa:deadsnakes/ppa -y
sudo apt update
# Python 3.12 インストール
sudo apt install -y python3.12 python3.12-venv python3.12-dev
# バージョン確認
python3.12 --version
# Python 3.12.x
⚠️ ハマりポイント
deadsnakes PPAには
python3.12-pipというパッケージは存在しません。python3.12-venvを入れておけば、python3.12 -m ensurepipでpipを用意できます。ついapt install python3.12-pipと打ってエラーになりがちなので注意してください。
社内プロキシ配下のWorkSpacesだと、PPAの追加時に通信が弾かれることがあります。その場合は /etc/apt/apt.conf.d/ にプロキシ設定を書くか、素直に24.04バンドルを使ってください。
Node.js 24 LTS のインストール（ソースビルドが必要な場合のみ）
先に結論を書くと、公式のインストールスクリプトを使う限りNode.jsは不要 です。私も最初に入れましたが、結果的に使いませんでした。
ソースからビルドする場合だけ、以下を実行します。
# NodeSource リポジトリを使ったインストール
curl -fsSL https://deb.nodesource.com/setup_24.x | sudo bash -
sudo apt install -y nodejs
# バージョン確認
node --version
# v24.x.x
WorkSpacesの標準バンドルはディスク容量が控えめなので、使わないものは入れないほうがいいと思います。
pipx のインストール
Kiro Crewのインストールスクリプトが内部でpipxを使うため、これは事前に入れておきます。
# pipxをインストール
sudo apt install -y pipx
pipx ensurepath
# バージョン確認
pipx --version
Ubuntu 24.04では、
python3 -m pip install --user pipxはPEP 668の制限でexternally-managed-environmentエラーになります。apt経由で入れるのが確実です。
pipx ensurepath を実行すると、~/.local/bin がPATHに追加されます。このあとの手順3にも関わるので、ここで通しておくと後がラクです。
kiro-cli のインストール
Kiro CrewはKiro CLIをエージェントのランタイムとして使うので、CLIが入っていないと何も動きません。ここは必須です。
KIRO_CLI_SKIP_SETUP=1 bash <(curl -fsSL https://cli.kiro.dev/install) <<< "y"
# PATHを通す
export PATH="$HOME/.local/bin:$PATH"
# バージョン確認
kiro-cli --version
# kiro-cli 2.x.x
KIRO_CLI_SKIP_SETUP=1 を付けているのは、対話式のセットアップウィザードを飛ばすためです。WorkSpaces上のターミナルでも普通に動きます。
kiro-cli へのログイン
kiro-cli login
組織のStart URLとリージョンを入力し、ブラウザでデバイスコードを承認します。
ここはWorkSpaces環境ならではの注意点があります。WorkSpacesのデスクトップに入っているFirefoxで認証を完了させる 必要があります。手元のWindows側のブラウザで承認しても、WorkSpaces内のCLIには反映されません。
IAM Identity Centerを使う場合は、以下のようにオプションを渡すと対話入力を省けます。
kiro-cli login \
--identity-provider https://d-xxxxxxxxxx.awsapps.com/start \
--region ap-northeast-1 \
--use-device-flow
--use-device-flow を付けると、ブラウザの自動リダイレクトを待たずに、コード入力で認証できます。リモートデスクトップ環境では、こちらのほうが確実でした。
なお、前述のとおりKiro CrewのライセンスはKiroに統一されているので、ここでログインできればCrew側で追加のサインインは発生しません。
手順1: 前提確認
所要時間の目安：1分
ミドルウェアがそろったら、いよいよ本番です。
各ミドルウェアのバージョンをまとめて確認します。
python3.12 --version # Python 3.12.x
node --version # v22.x.x 以上
pipx --version # 任意
kiro-cli --version # kiro-cli 2.x.x
Node.jsを入れていない場合は node --version がエラーになりますが、公式スクリプトでインストールするなら問題ありません。
手順2: kirocrew インストール
所要時間の目安：2〜3分
公式のインストールスクリプトを使えば、1コマンドでインストールできます。
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh
インストールログ（抜粋）:
Resolving KiroCrew (stable channel) ...
Verified signed manifest.
Downloading kirocrew 0.4.1rc1 ...
Verified SHA-256.
Installing with pipx ...
Installed kirocrew 0.4.1rc1 (channel: stable).
内部的には pipx を使って、Python仮想環境に隔離した形でインストールされ、~/.local/bin/kirocrew にバイナリが配置されます。
署名済みマニフェストの検証とSHA-256チェックが自動で走るので、この工程は待つだけです。
手順3: PATH確認
所要時間の目安：1分
インストールスクリプトが自動でPATHを設定してくれますが、反映されていない場合は以下を実行します。
export PATH="$HOME/.local/bin:$PATH"
# 永続化
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
WorkSpacesのUbuntuはデフォルトシェルがbashなので、~/.bashrc への追記でOKです。zshに変えている人は ~/.zshrc に読み替えてください。
手順4: インストール確認
所要時間の目安：1分
kirocrew --version
# kirocrew 0.4.1rc1
バージョンが返ってくればインストールは完了です。手順0を除けば、ここまで5分ほどです。
手順5: 初期設定（要ターミナル操作）
所要時間の目安：3分
対話形式なので、ターミナルで直接実行します。
kirocrew setup
設定項目：
| 項目 | 推奨値 |
|---|---|
| ワークスペースディレクトリ | デフォルト（Enter） |
| Slack連携 | 不要なら n
|
| スラッシュコマンド名 | デフォルト /kirocrew（Enter） |
| タイムゾーン | Asia/Tokyo |
| AWS上での起動 | 不要なら n
|
タイムゾーンは必ず Asia/Tokyo にしてください。 Kiro Crewはcronスケジュールでタスクを回せるので、ここがUTCのままだと「毎朝9時に実行」のつもりが夕方に走ることになります。ジョブごとにタイムゾーンを個別指定することもできますが、全部に書いて回るのは面倒です。
Slack連携は、私は最初 n にしましたが、あとで繋いでおけばよかったと思った項目です。 Slackを繋いでおくと、!dashboard と打つだけで署名付きのダッシュボードリンクが返ってきます。ダッシュボードは既定でループバック（外部に開かない）にバインドされる設計なので、ポートを外に晒さずに済みます。WorkSpacesに常駐させて外から様子を見たい場合は、ここで繋いでおくのが早いです。
「AWS上での起動」を聞かれたときは、WorkSpacesもAWS上だし y かな、と一瞬迷いました。これはEC2などにデプロイして外部公開する構成向けの設定なので、WorkSpacesの中で個人的に使うだけなら n で問題ありません。
手順6: 動作確認
所要時間の目安：1分
kirocrew doctor
依存関係、kiro-cliのログイン状態、ポートの空き状況などをまとめてチェックしてくれます。ここで警告が出たら、大抵はkiro-cliのログインが切れているか、PATHが通っていないかのどちらかです。
手順7: Gateway起動
所要時間の目安：2分
kirocrew gateway
起動後、表示されるURLにブラウザでアクセスします。
http://localhost:5476?token=<TOKEN>
この localhost は WorkSpaces内から見たlocalhost です。WorkSpacesのデスクトップに入っているFirefoxを開いて、このURLを貼り付けます。手元のWindows端末のブラウザからは開けません。
トークン付きのURLなので、コピーはターミナルから直接行ってください。初回はダッシュボードの機能説明が数枚表示され、最後にチャット欄への入力を促されます。試しに日本語で話しかけると、そのまま日本語で返ってきました。
手元の端末から開きたい場合
Kiro CrewのGatewayは、SSHトンネル1本で手元のブラウザから触れる設計になっています。
ssh -NL 5476:localhost:5476 <host>
# あとはブラウザで http://localhost:5476 を開く
自宅サーバーやEC2に常駐させている人は、これが正攻法です。
ただし WorkSpacesはデフォルトでSSHが開いていません。 使うなら、WorkSpaceのENIにVPC内から到達できる経路（Client VPN、Direct Connect、踏み台など）とsshdの有効化が必要で、社内のセキュリティポリシーによっては現実的でない場合もあります。
補足: サービス登録（常時起動）
ログアウト後も動かし続けたい場合は、systemdサービスとして登録できます。
kirocrew service install
ポートを変えたい場合：
KIROCREW_PORT=5477 kirocrew service install
WorkSpacesで使うなら、ここまでやって初めて意味が出てきます。 ターミナルで kirocrew gateway を叩いたままにしていると、セッションが切れた時点で止まってしまうからです。
サービス登録が済んだら、試しにジョブをひとつ仕掛けてみてください。
kirocrew cron add "morning-check" "AWSの新着ニュースを確認して、新しいものがあれば教えて" \
--cron "0 8 * * MON-FRI"
これで平日の朝8時に、WorkSpacesにログインしていなくてもジョブが走ります。--silent を付けて、変化があったときだけ通知するようにしておくと使いやすいです。
ただし、WorkSpacesの実行モードには注意してください。
| 実行モード | Kiro Crewの常時起動 |
|---|---|
| AlwaysOn | 動き続ける |
| AutoStop | 切断後、一定時間が経つとインスタンスごと停止する |
AutoStopは使った時間だけの課金なので安いのですが、切断後にインスタンスごと止まるため、cronやHeartbeatは動きません。
離席中も動かしておきたいならAlwaysOn一択です。日中の作業補助として使うだけならAutoStopでも足ります。
かかった時間と手間のまとめ
最後に、実際にかかった時間を整理しておきます。
| ステップ | 内容 | 所要時間 |
|---|---|---|
| 手順0 | ミドルウェア一式の準備 | 15〜20分 |
| 手順1 | 前提確認 | 1分 |
| 手順2 | kirocrewインストール | 2〜3分 |
| 手順3〜4 | PATH設定と確認 | 2分 |
| 手順5 | 初期設定 | 3分 |
| 手順6 | 動作確認 | 1分 |
| 手順7 | Gateway起動 | 2分 |
| 合計 | 約30分 |
つまずきポイントを3つに絞るとこうなります。
- Pythonのバージョン — Ubuntu 24.04バンドルを選べば、この手間はゼロになる
- 認証をどのブラウザでやるか — WorkSpaces内のFirefoxで完結させる
- Gatewayのlocalhost — 手元の端末からは開けない。外から見たいならSlack連携かSSHトンネル
逆に言えば、この3つを事前に把握していれば15分程度で終わる作業です。
Kiro Crew本体のインストールは1コマンドなので、大半の時間は環境を整えるほうに消えます。
インストールしてちょっと使ってみた感想としては、
「Kiro CLIを管理するローカルのWeb UIで、コマンドラインがとっつきにくい人の助けになるツールだな」
と感じました。
Kiro Crewでは、
- Kiro CLIをブラウザのチャットで動かせる
- サブエージェント（Kiro CLIでチームを組ませて多重実行）もWebで設定できる
- EMAみたいなスケジュール実行もWebで設定できる
- Slack、Discordと連携できるので、Kiro CLIの共有利用も楽
- アーティファクトデプロイ機能を使えば、簡単なサイト共有もWebでポチポチできる
ので、使いようによっては、KiroがWorkSpacesやEC2に常駐する保守・運用メンバーになってくれる感覚だと思います。
まだ触りはじめたばかりなので、cronやSkillをどこまで実用に落とし込めるかは、しばらく使ってから別記事にしたいと思います。
Kiro CLI単体の使い方については別記事で書いているので、そちらもあわせてどうぞ。
👉 関連記事：Kiro-CLIを使ってEC2とセキュリティグループ一覧を簡単に一覧化してみた