AWSはKiro Crewを公開した。ただしハーネスは手元に残した

Kiro Crewはオープンソースなのでしょうか。はい、本当にそうです。しかも私が予想していたより多くの部分が公開されています。では、Kiro Crewを役立つものにしている中核までオープンソースなのでしょうか。それは別の質問です。そして、このローンチで面白いのはまさにその答えです。

8月4日、AWSはKiro CrewをApache 2.0ライセンスで公開しました。コーディングエージェントをセッション、スケジュール、メッセージング画面をまたいで動かし続ける永続型エージェントワークスペースです。Amazon社内ではMeshClawというサイドプロジェクトとして始まり、6か月足らずで3万9,000人を超える社内ビルダーに広がりました。今は公開リポジトリに置かれ、ガバナンスも公開されています。私は発表、リポジトリ、ライセンスを読み、リポジトリに実際に入っているものと、製品が動くために今もAWSへ依存しているものを対応づけて見ました。その境界は意図的です。どちら側の上に何かを作るにしても、先に理解しておく価値があります。

要点 - Kiro CrewはAWSの永続型エージェントワークスペースで、2026年8月4日にApache 2.0でオープンソース化されました。Amazon社内のサイドプロジェクトMeshClawとして始まり、公開前には3万9,000人超のビルダーが利用していました。 - 公開されているものは、Gateway（セッション、メモリ、スケジュール、承認、セキュリティポリシー）、ダッシュボード、CLI、デスクトップアプリ、AppsとApp SDK、スキル、そしてセキュリティスタック全体です。すべて読めて、フォークできて、セルフホストできます。 - 非公開のままなのはKiro CLIです。CrewがAgent Client Protocol経由で動かすエージェントエンジンに加え、Kiroのサインイン、モデルルーティング、クレジット課金もAWS側に残ります。CrewのエージェントプロバイダーはACPとkiro-cliに固定されているため、すべてのモデル呼び出しは引き続きAWSの商用製品を通ります。 - これは一部が開かれたベンダー製ハーネスであり、オープンなエージェントランタイムではありません。ハーネスそのものをMITで公開し、どのモデルも単なるエンドポイントとして扱うTrueForgeと比べると境界がよく見えます。 - それでも設計には価値があります。セルフホストされる状態、見えるメモリ、真面目に作られたセキュリティモデルは本物です。ただし、自分がどの層に依存するのかははっきり理解しておくべきです。

何が起きたのか

2026年8月4日、AWSはKiro Crewの発表を公開し、kirodotdev/KiroCrewリポジトリをApache 2.0で開きました。同じ週にSiliconANGLEとDevOps.comも取り上げ、私が確認した時点でリポジトリはおよそ3,400スター、400フォークでした。重要な事実は次のとおりです。

• Kiro Crewは開発エージェント向けの永続ワークスペースです。人が見ていない間に走る複数段階のタスク、スケジュール実行される定期ジョブ、PRやデプロイを監視して注意が必要になるまで見張るハートビート、並列に広がって結果を返すサブエージェントを扱います。

• 置き場所は自分で選べます。デスクトップアプリ、1行のインストール、GHCR上のDockerイメージ、あるいは自分で管理するリモートLinuxホストで動きます。状態（セッション、メモリ、チェックポイント）はAWSのコントロールプレーンではなく、自分のハードウェア上の~/.kiro/crewに保存されます。

• 操作経路はWebダッシュボード、CLI、デスクトップアプリ、またはメッセージングサービスです。Slack、Discord、Telegram、Teams、Webex、WeCom、WeChat、WhatsAppに対応します。

• 起源はOpenClawに着想を得たAmazon社内のサイドプロジェクトMeshClawです。発表によれば、公開前に3万9,000人を超える社内ビルダーへ広がり、約500人のコントリビューターが600件近い更新を出しました。

• ガバナンスも公開されています。MAINTAINERS.mdにはステアリング委員会が記載され、提案はプルリクエストとして提出され、議論されます。現時点のメンテナーはKiroとAWSのエンジニアですが、信頼できる外部コントリビューターが育てば外部メンテナーを加える方針も明記されています。

Kiro CrewはAWSが2026年8月4日に公開した、Apache 2.0のオープンソース永続型エージェントワークスペースです。人が付き添わない複数段階タスク、スケジュールジョブ、ハートビート、サブエージェントを実行し、ユーザー自身のハードウェアにセルフホストできます。AWSの発表とプロジェクトリポジトリで確認できます。

どの層が開いていて、どこが閉じているのか

報道ではこの部分がほとんど飛ばされていたので、私はリポジトリを自分で追いました。アーキテクチャは3層です。人が触るサーフェス（ダッシュボード、デスクトップ、CLI、メッセージング）、状態を持つGateway（セッション、メモリ、スケジュール、承認、セキュリティポリシー）、そして実際にモデルのループを回すエージェントセッションです。ライセンスの境界はこうなっています。

一番重い一線は設定ドキュメントにあります。agent.providerはacpに固定され、Kiro CrewはAgent Client Protocol経由でkiro-cliを動かします。すべてのモデル要求は、自分のKiroアカウントとそのモデル設定の下でkiro-cliが処理します。ワークスペース、メモリ、スケジュール、セキュリティ姿勢は自分のものです。フォークも検証もできます。一方、推論するエンジンと、それを計測して課金する仕組みはAWSのものです。

Kiro CrewのGateway、各種サーフェス、Apps、セキュリティ層はKiroCrewリポジトリでApache 2.0のオープンソースとして公開されています。ただし、その下のエージェントエンジンkiro-cliはAWSの非公開製品のままです。Crewのエージェントプロバイダーはkiro-cli上のACPに固定されているため、モデルへのアクセス、サインイン、クレジット課金はAWS管理のままです。

なぜ境界はそこに引かれているのか

雑に読むなら、AWSは善意でCrewをオープンソース化した、あるいは罠として公開した、となるでしょう。もっと役に立つ読み方は、境界が収益の線をなぞっていて、そのことをかなり正直に示している、です。

ワークスペースは配る。エンジンとメーターは残す。まともなオープンソース基盤ではよくある取引ですし、AWSも隠していません。発表にはCrewがKiro CLI上で動き、既存の.kiro設定をそのまま読むと書かれています。すでにKiroで仕事をしているなら、Crewはほとんど贈り物です。ステアリングファイル、スキル、カスタムエージェントをそのまま持ち込み、永続化、スケジューリング、十数種類のメッセージング接続まで無料で得られます。3万9,000人の社内ユーザーという数字は、単なるマーケティング文句ではなく、この形が大規模でも動くという証拠です。

ただし、公開によってAWSが何を得るかも見てください。Crewを入れるとKiroも入ります。初回起動でkiro-cliとデバイスコードによるサインインが設定されるからです。すべてのエージェントターンは、Kiroがルーティングするモデルに対してKiroクレジットで計測されます。Kiroのルーティング先にはBedrock上のClaudeと、中国のオープンモデル（Qwen、DeepSeek、GLM、MiniMax）が含まれます。ある初期ユーザーは個人プロジェクトだけで1週間に5,000クレジットを使い切りました。常時稼働するエージェントワークスペースが従量制モデルプランに何をするか、よく分かる数字です。オープンな層が非公開の層への入口を広げ、売上は非公開の層で生まれます。隠されてはいませんし、邪悪な話でもありません。ただ、はっきり見ておく価値はあります。同じ週には境界を別の場所に引いた完全オープンな代替も出たからです。

オープンな側には、もう一つ素直に評価したい点があります。セキュリティモデルがプロンプトではなくランタイム境界で強制されています。LinuxとmacOSではOSレベルのサンドボックス、既定拒否のコマンド、認証情報のマスキングがあります。Windowsでは明示的に許可しない限り、エージェントのサブプロセスを無制限に走らせるのではなく拒否する、フェイルクローズの姿勢です。すべてリポジトリ内にあるので、ベンダーの製品ページを信じる代わりに各層を自分で検証できます。オープンな部分が見せかけではなく本物だと言える最大の根拠はここです。

Kiro Crewのオープンなワークスペースは、非公開で従量課金のKiroエンジンへユーザーを導きます。インストールのたびにkiro-cliとKiroサインインが設定され、エージェントの各ターンはKiroクレジットへ課金されます。一方、セキュリティスタック（OSサンドボックス、既定拒否のコマンド、認証情報のマスキング、監査ログ）は本当に公開されており、リポジトリで監査できます。

TrueForgeと比べると境界が見える

Kiro Crewの2週間後、TrueFoundryはTrueForgeをMITライセンスで公開しました。この2つを並べると、ベンダーがエージェントスタックのどこまでを手放す意思があるのかを見る、きれいな自然実験になります。

TrueForgeがオープンソース化したのはハーネスそのものです。モデルを囲むループ、セッション、サンドボックス、承認、コンテキスト管理です。OpenAI互換のエンドポイントなら何でもつなげられるので、タスクを終えられる最も安いモデルに仕事を渡せます。商用層は、その下にある任意のゲートウェイで、使わない選択もできます。Kiro Crewはハーネスの周囲をすべて公開しました。永続化、スケジュール、各種サーフェス、セキュリティポリシーです。ハーネスそのものに当たるkiro-cliは閉じたままで、その背後のモデルプレーンが製品です。

どちらも不誠実ではありません。ただし、依存の仕方が違い、壊れ方も違います。TrueForgeをフォークすれば、動くエージェントランタイムは残ります。失うのはTrueFoundryのゲートウェイとサポートです。Kiro Crewをフォークすれば、優れたワークスペースは残りますが、その中にエンジンはありません。kiro-cliのプロトコル、価格、終了予定のどれかが変わった瞬間、その問題をフォーク側も引き継ぎます。自分のエージェントスタックで自作か購入かを考えているなら、一部だけ開かれた製品にはこう尋ねるべきです。ベンダーのロードマップが動いたとき、どの層が動かなくなるのか。私はエージェント型アーキテクチャ全般についても同じことを書きました。面白い問いはどのモデルかではなく、それを何が包み、その包みを誰が所有するかであることが多いのです。

杭州からの余談を一つだけ。Kiroのルーティングでは、Bedrock上のQwen、DeepSeek、GLM、MiniMaxがすでに普通の選択肢として扱われ、CrewにはWeComとWeChatのコネクターが最初から入っています。中国のモデルと中国のメッセージングサービスが、米国ベンダーのスタックにごく普通の部品として入っている。そうしたモデルの半分が作られている街から見ると、少しうれしくなる話です。

今、何をすべきか

Kiro Crewを評価するなら、順番は3つです。

1. 今日: 何かをインストールする前にリポジトリを読んでください。READMEのアーキテクチャ節、GOVERNANCE.md、MAINTAINERS.mdから始め、次にセキュリティ文書を読みます。オープンな層の価値は自分で検証できることなので、実際に検証してください。インストール自体は1行で、ダッシュボードは既定でローカルホストにバインドされます。

2. 今週: 範囲が限定され、リスクの低い仕事を一つだけ動かしてください。スケジュールされたPR監視、朝のダイジェスト、定期レビューなどです。Activity画面と監査ログで何をしているかを見て、クレジット消費も追ってください。永続型エージェントは眠っている間にもお金を使います。それは設計どおりに製品が動いている証拠であると同時に、予算の話でもあります。

3. 今月: 自分がどの層に依存するのかを決めてください。すでにKiroを使っている組織なら、Crewはかなり素直な「使う」でいいでしょう。ゼロからスタックを選ぶなら、TrueForgeのような完全に開かれたハーネスと境界を比べ、どちらかにチームのワークフローが固まる前にセルフホストのトレードオフまで考えてください。導入するならCrewはMCPに対応しているので既存ツールも持ち込めます。私がまとめたつなぐ価値のあるMCPサーバーは、最初の候補として悪くありません。

FAQ

Kiro Crewはオープンソースですか

ワークスペースはそうです。Gateway、ダッシュボード、デスクトップアプリ、CLI、Apps、スキル、セキュリティスタック全体がkirodotdev/KiroCrewリポジトリでApache 2.0として公開されており、AWSのコントロールプレーンなしで自分のハードウェアにすべてセルフホストできます。ただし、その下のエージェントエンジンkiro-cliはオープンソースではなく、Crewはそれなしでは動きません。したがって「オープンソース」はリポジトリの説明としては正確ですが、製品全体の説明としては不十分です。

Kiro CrewにはAWSアカウントが必要ですか

kiro-cli経由でモデルアクセスとクレジット課金を処理するKiroへのサインインは必要です。ローカル利用のためにAWSアカウントへ何かをデプロイする必要はなく、ワークスペースと状態は自分のマシンに残ります。常時稼働のリモート環境が欲しければ、kirocrew cloud launchで自分のAWSアカウント内のEC2へ1台用意できますが、普通のLinuxサーバーや自宅ラボでも動きます。

Kiro CrewはKiroの自律モードとどう違いますか

範囲です。自律モードは、見守っている間に1つのセッションで1つのタスクを処理します。Crewはセッションや再起動をまたいで残り、オンラインかどうかにかかわらずスケジュール仕事やイベント反応型の仕事を走らせ、複数のサブエージェントを並列に編成し、実行間でメモリ、学習内容、スキルを引き継ぎます。同じKiroエンジンの新しい操作面で、同じ.kiro設定を読みます。

Kiro Crewを別のエージェントエンジンやモデルプロバイダーで使えますか

現時点では使えません。エージェントプロバイダーはkiro-cli上のACPに固定されているため、モデルはKiroアカウントがルーティングする先から来ます。現在はClaudeに加え、Bedrock上のQwen、DeepSeek、GLM、MiniMaxなどのオープンモデルも含まれます。ガバナンスモデルは公開され、メンテナーは外部からの貢献も歓迎するとしています。将来エンジンを差し替えられる可能性はありますが、現在出荷されている設計はそうではありません。そこを前提に計画するのは勧めません。

結論

Kiro Crewは、非公開の商用エンジンを中心に置いた良いオープンソースプロジェクトです。そしてAWSは、この構成について多くのベンダーよりずっと率直です。開いている層は本物です。セルフホストされる状態、見えるメモリ、監査可能なセキュリティモデル、公開ガバナンスがあります。閉じている層も同じくらい本物です。ハーネス本体、サインイン、メーターがそこにあります。自分の依存が境界のどちら側にあるのかを理解して入るなら、Crewには時間を使う価値があります。その境界を別の場所に置きたいなら、同じ月にMITライセンスのハーネスも出ています。

自分のエージェントスタックで、オープンにする境界をどこへ置くべきか考えているなら、これは私がクライアントとよく話すテーマです。お問い合わせください。

情報源

• Kiro（AWS）「Kiro Crewの紹介」: https://kiro.dev/blog/introducing-kiro-crew/ （2026-08-04公開、2026-08-29参照）

• kirodotdev、KiroCrewリポジトリ（README、LICENSE、GOVERNANCE.md、セキュリティ文書）: https://github.com/kirodotdev/KiroCrew （2026-08-29参照）

• Kiro、Kiro Crew製品ページ（ライセンスと機能FAQ）: https://kiro.dev/crew/ （2026-08-29参照）

• SiliconANGLE「AWSがKiro Crewを公開、24時間週7日のコード開発に向けた自律型エージェントオーケストレーター」: https://siliconangle.com/2026/08/04/aws-launches-kiro-crew-autonomous-agentic-orchestrator-24-7-code-development/ （2026-08-04公開、2026-08-29参照）

• DevOps.com「AWS、Kiro AIコーディングツールにエージェント型ワークスペースを追加」: https://devops.com/aws-adds-agentic-workspace-to-kiro-ai-coding-tool/ （2026-08-05公開、2026-08-29参照）

• Playing AWS「Kiro Crewを1週間使ってみた（そして5,000クレジット超）」: https://www.playingaws.com/posts/what-is-kirocrew/ （2026-08-08公開、2026-08-29参照）