![[アップデート] OpenClaw 的な使い方を Kiro CLI で実現する「Kiro Crew」がリリースされたので触ってみた](https://images.ctfassets.net/ct0aopd36mqt/4uTbTE9O9jUJCOs80dZ0Ao/e2da592b5eaaad0f5993d6ff64a12467/aws-kiro.png?w=3840&fm=webp)
[アップデート] OpenClaw 的な使い方を Kiro CLI で実現する「Kiro Crew」がリリースされたので触ってみた
いわさです。
Kiro CLI はターミナルからエージェントに指示を出せるツールですが、基本的にはセッションを開いてその場で作業して終わり、という使い方になります。
先日、Kiro から「Kiro Crew」がオープンソースでリリースされました。
Kiro CLI を裏側のエージェント実行エンジンとして使いつつ、その上に Gateway を被せてセッション管理やメモリ、スケジュール、Slack などの外部チャネル連携を追加するオーケストレーション層です。
上記公式ブログを読むと、OpenClaw に触発されたことに言及されています。
OpenClaw のフォークではなく、Amazon 内部で「MeshClaw」として開発されていたプロジェクトがベースとのこと。
OpenClaw は、ローカルのエージェントを Slack などの外部チャネルから操作したり、セッションをまたいで記憶を引き継いだりできるツールです。
私も以前 Lightsail にセットアップして紹介したことがあります。
Kiro Crew の公式 FAQ では、ACP（Agent Client Protocol）経由で Kiro CLI 上で動作し、既存の .kiro 設定をそのまま読み込むと説明されています。
It runs on the Kiro CLI using ACP, and reads your existing .kiro configuration.
今回はこちらを macOS にインストールして、Slack の接続設定まで試してみたので紹介します。
実際に確認してみる
インストール
macOS・Linux・Windows に対応しています。
今回は macOS で試します。
GitHub Releases からインストーラーをダウンロードします。
インストールすると KiroCrew.app が追加されます。
セットアップと Kiro CLI との関係
初回起動時にセットアップウィザードが始まります。
マシン上の他のエージェントツールの設定を検出してインポートできる仕組みです。
私の環境では Claude Code の設定が6件検出されました。
メモリとワークスペースをインポートできます。Merge only なので既存設定は上書きされません。
インポートが終わるとメイン画面が表示されます。
ここで気づいたのですが、Kiro CLI にログイン済みの状態だと Kiro Crew で追加のログインを求められません。
そのまま接続済みの状態になりました。
Kiro Crew は Kiro CLI の認証をそのまま使っているようです。
つまり、デスクトップアプリが直接エージェントを動かしているわけではなく、Kiro Crew Gateway がセッションや接続先を管理して、実際の処理は Kiro CLI に渡している構成っぽいです。
Slack やブラウザなど複数の入り口から同じ Gateway に接続して、セッションを共有する仕組みになっています。
タスクを実行してみる
サジェストされていた「今日のAWS新着ニュースを確認」を実行してみます。
ちなみにこのサジェスト内容、Claude Code からインポートしたメモリをもとにパーソナライズされているっぽいです。普段の作業内容に沿った候補が並んでいました。
エージェントが AWS What's New のフィードを取得して、当日のニュースをまとめてくれました。
この操作自体は Kiro CLI や Kiro IDE でやるのと変わらないですね。
Gateway とブラウザダッシュボード
OpenClaw と同じように、Slack などマルチチャネルを使って Gateway 経由でローカル PC のセッションにリモートアクセスできる点が、これまで Kiro 単体ではできなかった部分だと思います。やってみましょう！！
デスクトップアプリとは別に、ブラウザからもダッシュボードにアクセスできます。
Gateway はローカルで動作しており localhost:5476 で開けました。
OpenClaw をセットアップしたときと非常に似た流れですね。
kirocrew token
認証用の URL が生成されるので、ブラウザで開くとデスクトップアプリと同じセッションが見えます。
同じ Gateway に繋がっているので、デスクトップアプリで作ったセッションがブラウザでもそのまま見える感じです。
ローカルデスクトップの Kiro Crew を終了すると、このブラウザからもセッションにアクセスできなくなります。
Slack と接続する
Kiro Crew の設定画面から Slack の接続を試してみます。
まず Kiro Crew のダッシュボードで Settings → Channels を開きます。
Slack のセクションに「Create Slack App」のボタンがあり、押すと Slack API のアプリ作成ページに飛びます。
マニフェストが事前に埋め込まれているので、スコープやイベント購読の設定は自動で入った状態です。
ワークスペースを選択して認可を進めると、Slack App が作成されます。
作成後、Slack API 側で以下を取得します。
- Socket Mode を有効化して App-Level Token（
xapp-...）を発行（connections:writeスコープ付き） - OAuth & Permissions で Bot Token（
xoxb-...）を取得 - 自分の Slack Member ID をプロフィールからコピー
Kiro Crew の設定画面に戻って、App Token・Bot Token・Owner Slack Member ID をそれぞれ入力して保存しました。
ただ、保存しただけでは接続ステータスが変わりませんでした。
Kiro Crew アプリケーションを再起動したところ、Slack のステータスが「Connected」に変わりました。
ここまでで Kiro Crew 側からは Slack に接続できている状態です。
なお、Slack 側から DM やチャンネルメッセージを送ってみましたが、今回は応答が返ってきませんでした。
/kirocrew スラッシュコマンドも試してみます。Slack API 側では登録されているのですが...
実際に打ってみると「有効なコマンドではありません」と表示されてしまいました。
公式ドキュメントによると、DM は全メッセージを処理する always モード、チャンネルは @mention で反応する mention モードがデフォルトとのこと。
alwaysprocesses every message in DMs, whilementionresponds only when the bot is mentioned in group channels.
次回はメンション付きのメッセージや、イベント購読の設定まわりを改めて確認してみます。
さいごに
本日は Kiro Crew を macOS にインストールして、Kiro CLI が実行基盤として動いていることの確認と、ローカル Gateway 経由での Slack 接続設定まで試しました。
Kiro CLI を置き換えるものではなく、その上にセッション継続・メモリ・外部チャネル接続を乗せるための層、という理解で良さそうです。
OpenClaw っぽい使い方を Kiro CLI ベースで作れるようになった、という感じですかね。
Slack のメッセージ応答は今回間に合わなかったので、次回はそのあたりを確認してみたいと思います。
