きっかけ:読んでもよくわからなかった
2026年8月4日、AWSからKiro Crewがを公開されました。簡単に言うと
「AIエージェントをずっと動かし続けるための仕組み」
というもののようです。
READMEを読み、ソースコードも読んでみたのですが、正直、頭の中でうまく整理ができませんでした。
こういうとき、自分はだいたい同じことをします。
「読んでもわからないなら、作ってみる」
Kiro Crewはkiro-cliというツールでAIを動かしているのですが、その部分を、普段から自分が使っているClaude Code CLIに置き換えて、自分なりに作ってみることにしました。名前はclaude-crewです。夏休みの自由研究気分でやってみました。
このブログでは、
- Kiro Crewは具体的に何ができるものなのか
- 実際にどうやって作ったか
- 本家と比べて、あえて作らなかった部分
- ローカルで動かすことにした理由(セキュリティの話)
- あえて昔のWindows風の見た目にした話
について書いていきます。Kiro Crew本家のGitHubリポジトリを参考にしながら作ったもので、コードはGitHubに公開しています。
そもそもKiro Crewって何?
一言で言うと、「永続的で、複数の窓口を持つAIエージェント・オーケストレータ」です。
順番に説明します。
まず永続的というのは、ずっと動き続けるという意味です。普通、AIとのチャットはターミナルを閉じたら終わりですが、Kiro Crewはバックグラウンドでプロセスとして動き続けます。さっきまで話していた続きを、別のパソコンやスマホから続けることもできます。
複数の窓口というのは、同じAIに、CLI(ターミナル)からも、Slackからも、Telegramからも、Webのダッシュボードからも話しかけられるということです。
窓口は違っても、中身は同じ1つの会話です。
オーケストレータというのは、「1回質問して1回答えて終わり」
ではないということです。定期的にタスクをこなしたり(cronのような仕組み)、複数の作業を分担させたり、これまでのやり取りを覚えていたりします。
AWSの発表とリポジトリを見た限り、Kiro Crewには具体的にこんな機能があるようです。
- 全ての窓口(CLI/Slack/Telegram/ダッシュボード)を1つのAIエージェントにつなげるGatewayというプロセス。
kiro-cliをACP(Agent Client Protocol)という仕組み経由で動かしている - 会話をまたいで覚えている永続メモリ
- 定期実行のスケジュール機能
- 承認ワークフロー。危険そうな操作の前に、人間がOKを出さないと実行されない仕組み
- サンドボックスと、あとから改ざんできない監査ログ
- WebとデスクトップのAI状況を見るためのダッシュボード
- 開発者向けツールとの連携(プルリクエストの監視、障害調査、チケットの仕分けなど)
盛りだくさんです。ただ、読んで「なるほど」と思うのと、なぜこの機能が必要なのか、これが無かったら何が壊れるのかを理解するのは、別の話でした。後者は自分で作ってみて初めてわかりました。
実際に作ったもの:claude-crew
全体の骨組み(1つの常駐プロセスが複数の窓口をまとめ、安全のための仕組みが必ず挟まる、という設計)はそのまま真似して、中で実際にAIを動かす部分だけ、kiro-cliからClaude Code CLIに置き換えました。
| Kiro Crew(本家) | claude-crew(自作) |
|---|---|
kiro-cliをACP経由で操作 |
claudeコマンドをヘッドレスモード(画面なしモード)で操作 |
| Gateway(Slack/Telegram/CLI/ダッシュボードをまとめる) | Gateway(CLI/ダッシュボードのみ。Slack等は後述の理由で見送り) |
| 永続メモリ | 好み・作業履歴・学んだことをファイルに保存し、新しい会話のたびに読み込ませる |
| スケジュール機能 | cron / taskrunner / subagent / heartbeat |
| 承認ワークフロー | 危険な操作の前に人間のallow(許可)/deny(拒否)を待つ仕組み |
| サンドボックス+署名付き監査ログ | macOSのSeatbelt/LinuxのbubblewrapによるOSレベルの隔離+ハッシュチェーンで改ざん検知する監査ログ |
一番苦労したところ:セキュリティ
正直、作り始める前はここまで大変だと思っていませんでした。ずっと動き続けて、勝手にコマンドを実行できるAIは、「ルールでダメと言ってあるから大丈夫」だけでは信用できません。そこでclaude-crewには3段階の安全装置を用意しました。上の段階が破られても下の段階で止まるように、という考え方です。
1つ目はPreToolUseゲートです。
AIが何か操作(ファイルを読む、コマンドを実行する、URLを取得するなど)をしようとするたびに、実行される直前に必ず1回チェックが入ります。
このツールは許可されているか、このファイルのパスは触ってはいけない場所じゃないか、このコマンドは危険なパターンに一致しないか、を確認します。
ただこれはルールでしかないので、書き方を工夫すれば(難読化すれば)すり抜けられる可能性があります。
2つ目はOSサンドボックスです。
ルールだけでは突破される可能性があるので、実際に動いているclaudeプロセス自体を、OSの機能(macOSならsandbox-exec、Linuxならbubblewrap)で外側から閉じ込めています。たとえルールをすり抜けても、OS自体が書き込みを拒否します。
これは実際に手元で確認しました。
サンドボックスの中からecho x > ~/どこかのファイルを実行すると、"Operation not permitted"ときっぱり拒否されます。
3つ目は署名付き監査ログです。
ゲートが下したすべての判断は記録されます。ここで少し難しいのは、そのゲート自身がサンドボックスの中で動いていることです。
もしゲートが乗っ取られたら、自分自身の記録を書き換えてしまうかもしれません。なので、ゲートは署名されていない仮のメモを書き溜めるだけにして、サンドボックスの外側にいる、署名の鍵を持った別のプロセスが、そのメモを定期的に回収し、改ざん検知できる形で正式な記録に変換するようにしました。
これを作っている途中に実際にバグを見つけました。
メモの中に1行でも変な形式の記述が混ざると、それ以降ずっと記録が止まってしまう不具合です。自分で自分のシステムを壊そうとしてみて、初めて見つかった類のバグでした。
この上に乗っているのが承認ワークフローです。
これはKiro Crew本家の説明にも載っている機能で、最初は後回しにしていました。
作るときに気づいたのですが、ヘッドレスモード(画面なしモード)には人間に聞くための対話の仕組みがそもそもありません。なので、人間の返事を待つという動作を、文字通り一定時間ごとに確認し続ける形で実装しました。
危険な操作をしようとすると、ゲートが返事待ちのファイルをディスクに書き出してそこで止まり、小さなダッシュボード(またはコマンドライン)から人間がallow(許可)かdeny(拒否)をクリックするまで待ち続けます。一定時間返事がなければ自動的に拒否扱いになります。
UIの話:あえて昔のWindows風に
ダッシュボードは、外部のライブラリに一切頼らない、1つのHTMLファイルです。データはServer-Sent Eventsという仕組みでリアルタイムに流れてきます。作っている途中、見た目は好きにしていいんだよなと気づいて、1985年頃のMS-DOS Executive風にしてみました。斜線模様のタイトルバー、立体的なボタン、等幅フォントです。機能的な意味は特にありません。UI層は自分で書いた数百行のCSSなので、少し遊んでみただけです。
実際にどうやって作ったか
一気には作らず、小さな段階(フェーズ)に分けて進めました。
まずセッションを維持する仕組みから始め、次にメモリ、次にスケジュール機能、次にセキュリティ層全体、次にデーモン化とダッシュボード、最後に承認ワークフローという順番です。
各段階が終わるたびに、2種類の独立したレビューを必ず挟みました。
1つは過剰に複雑になっていないかを見るレビュー、もう1つはセキュリティの穴がないかを専門に見るレビューです。
指摘された内容は必ず実際に手元で再現してから直す、というルールも徹底しました。
この過程で、実際にいくつか本物の脆弱性が見つかりました。たとえば、承認ワークフローの決定を記録する関数に、パストラバーサル(本来アクセスできないはずのファイルパスに抜け道でアクセスできてしまうバグ)が見つかりました。
放置していたら、ダッシュボードのトークンさえ知っていれば、設定ファイルを勝手に書き換えられる状態でした。
動くことをちゃんと確認するのも、今回は手を抜かないようにしました。
サンドボックスが機能しているかは、実際に許可されていない場所に書き込みを試みて、失敗することを目で確認しました。
プロセスの自動復旧は、実際にkill -9で強制終了させて、何秒後に復活するかを計測しました。トークンが漏れる経路がないかは、許可されていない発信元から実際にダッシュボードを開いて、拒否されることを確認しました。
「見て確認できないものは、動いているとは言わない」というのを自分のルールにしていました。
本家と比べて、あえて作らなかったところ
いくつか、意図的に手を出さなかった部分があります。
SlackやTelegramとの連携は作りませんでした。
今の自分には、チャットアプリ経由で自分のAIエージェントに話しかけたい場面がまだないからです。あとで使うかもしれないからで機能を足すのは、先回りしすぎた機能追加になると思いました。
もし将来必要になっても、Gatewayの作り自体は、セッション管理やセキュリティ層に手を入れずに新しい窓口を足せるように設計してあります。
開発者ツールとの連携は、プルリクエストのレビューのみ実装し、障害調査、チケットの仕分けなどは作っていません。
理由は同じで、今そこまで必要としていないからです。
また、デスクトップアプリは作らず、ブラウザのダッシュボードだけにしました。外部ライブラリへの依存をゼロに保つためです。
クラウドには置かず、あえてローカル(自分のパソコン)で動かすことにしました。
セキュリティ上の判断です。
ダッシュボードをどこかにホスティングしようと思い、VercelやAWSも検討したのですが、両方ともやめました。
このシステムは実際にシェルコマンドを実行できる本物のプロセスを動かし、署名用の秘密鍵を持っていて、ずっと動き続けるAIエージェントを管理しています。
こういうものは、必要が無い限り、誰でもアクセスできるインターネット上のサーバーには置くべきじゃないと考えました。
代わりに全部自分のパソコンの中だけで動かし、TailscaleというプライベートなVPNを使って、スマホや他のパソコンからダッシュボードにアクセスできるようにしています。
Tailscaleのtailscale serveという機能を使うと、ドメインを買わなくても、ちゃんとしたHTTPSの証明書が無料で手に入るのも助かりました。
構成図
実際の動きを見る
(21秒の短いデモ動画です。レトロなダッシュボード、リアルタイム接続、そしてBashコマンドの実行が人間の承認待ちでブロックされる様子が見られます。)
この夏休みの自由研究で得たもの
AWSが説明しているKiro Crewは、よく考えられたアイデアだと思います。
ずっと動き続けるAIエージェントには、住み処、記憶、安全装置、複数の入り口が必要で、どれも理にかなっています。
違う実行エンジンの上でゼロから自分の手で組み立て直してみたことで、READMEを読むだけではわからなかったことが、自分の中でようやく腑に落ちました。
読んでもなんとなくわかったつもりのまま止まっているものがあれば、「自分で作ってみる」のが一番の近道かもしれません。
ソースコードは、設計の参考としてKiro Crew本家のGitHubリポジトリを一貫して参照しながら作りました。claude-crewのコード自体もGitHubで公開しています。
これは個人の自由研究で、AWSとは一切関係のない非公式のプロジェクトです。
最後まで読んでいただきありがとうございました。