Amazon 社員 3.9 万人の日常業務を支える AI エージェント Kiro Crew の使い方大公開
2026-09-02 | Author : 稲田 大陸 (いなりく)
はじめに
こんにちは ! ソリューションアーキテクトの いなりく です !
この連載では 毎月 Kiro の最新情報 をお届けしていますが、今回は少し毛色が違います。これまでずっと「エンジニアの道具」だった Kiro に、そうでないものが出てきたからです。
Kiro IDE はエディタでした。Kiro CLI はターミナルで動きます。どちらも素晴らしい道具ですが、正直に言えば使う人を選びます。私も社内で Kiro を勧めるとき、相手が非エンジニアだと「これは、ちょっと難しいかもしれません」と言葉を濁していました。ターミナルを開いてもらうところから説明が必要だからです。
2026 年 8 月 5 日、Kiro Crew をオープンソース として公開しました。 Apache 2.0 ライセンスで GitHub で公開 されています。
そして Kiro Crew には、ターミナルが要りません。ブラウザで開くダッシュボード、デスクトップアプリ、さらには Slack などのコミュニケーションツールからも使えます。目的別の画面 (Apps) が最初からいくつも入っていて、会議の議事録づくりや資料作成は専用の画面から進められます。
さらにもうひとつ。それは、Kiro Crew はいきなり世に出てきた新製品ではないということです。Amazon 社内で 3.9 万人を超えるビルダーが、すでに日常業務で使っていたツールでした。
そして正直に言うと、これを使っているチームと使っていないチームの差は、これから急速に開くと思っています。理由は本文で書きますが、ひと言でいえば「人が席にいない時間も仕事が進む」かどうかの差は、積み上がると取り返しがつかないからです。
本記事では、前半で「何が変わったのか」を 3 点に絞って整理し、後半で「実際に何を任せているか」を 15 個並べます。要点を先に 3 つだけ挙げておきます。
- ターミナルを開かない人にも渡せる。ダッシュボード・デスクトップアプリ・チャットから使える
- 契約は Kiro 1 本のまま。IDE / CLI / Crew を各自が勝手に選べる
- 「席を離れている時間」こそ、いちばん自動化の余地がある
なお、Kiro の仕様駆動開発 (Spec-Driven Development) についてはこの連載の 6 月号「 進化し続ける Kiro の仕様駆動開発を一度立ち止まって整理する」で扱いました。あちらが「1 つの機能をきちんと作る」話なら、今回は「日々の仕事を回し続ける」話です。この記事は Kiro Crew と一緒に書いています。
builders.flash メールメンバー登録
builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。
3.9 万人が使っていたツールが、外に出た
Kiro Crew は、Amazon 社内の MeshClaw という個人プロジェクトとして始まりました。3 人のエンジニア (Bolin Chen、Zejiang (Joe) Guo、Zezhen Xu) が、社内に存在しなかったシンプルなものを求めて作り始めたものです。
タスクを投げて、その場を離れ、戻ってきたらレビューする価値のある成果ができている。1 つのプロンプトに付き添い続けるのではなく、複数のタスクを同時に走らせられる。
彼らはまず自分たちのために作りました。やがて社内の他のビルダーが使い始め、それぞれが自分のワークフローに合わせて拡張していきます。誰かが自分の作業の穴に気づいて必要なピースを足すと、それはその人だけでなく、後から来る全員に残る。この積み重ねが起きました。
実際にブログでは 6 か月足らずで社内 39,000 人を超えるビルダーに採用され、500 人近いコントリビューターが 597 件の更新を、平均で週 143 コミットのペースで届けてきたとのことです。そして公式ブログは、これを支えたのがエンジニアだけに限らない多様な職種のコミュニティだったと書いています。私自身も MeshClaw だった時代から触っていたビルダーの一人です。
Kiro Crew はすでに Amazon 社員が実際に日常業務で使い、使いづらいところは自分たちで直してきた実績のあるソリューションなのです。本記事では実際に私がどのように活用しているかを公開します。
第 1 部 : 何が変わったのか
変化 1 : 入口が変わった
Kiro ファミリーを、使う人の視点で並べてみます。
|
|
動く場所
|
主な使い手
|
|---|---|---|
|
Kiro IDE
|
エディタ |
エンジニア |
|
Kiro CLI
|
ターミナル |
エンジニア |
|
Kiro Crew
|
ブラウザ / デスクトップアプリ / Slack・Telegram・Discord ほか |
職種を問わない |
技術的には、Kiro Crew は Kiro CLI の上に乗る層です。裏側では Kiro CLI がエージェントのランタイムとして動いていて、Kiro Crew はその上でセッション・メモリ・スケジュール・承認を束ねています。
でも使う人にとっての違いは「入口」です。入口はいくつもあります。
- デスクトップアプリ : macOS 版 ( .dmg ) と Linux 版 ( .AppImage ) が配布されていて、自前の Python を同梱しているのでツールチェーンの準備は要りません。開くだけで動きます
- Web ダッシュボード : ブラウザで localhost:5476 を開くだけです
- Slack / Telegram / Discord / Teams / Webex などのチャット : スマホからでも同じ作業ができます
非エンジニアの同僚に渡すときも、「デスクトップアプリを入れて、Kiro のアカウントでサインインして」と伝えるだけで済みます。ターミナルは登場しません。
変化 2 : ライセンスが Kiro で統一されている
組織に広げることを考えると、ここがかなり大きいと思っています。
Kiro Crew は Kiro CLI の上で動くので、必要なのは同じ Kiro のアカウントとプランです。つまり会社としては Kiro を契約するだけで、IDE を使いたい人は IDE を、ターミナルが好きな人は CLI を、ブラウザや Slack から使いたい人は Crew を、それぞれが勝手に選べます。Crew のために別の契約を積む必要はありません。
「エンジニアにはこのツール、非エンジニアには別のツールを追加で契約」という話にならないのは、導入を進める立場からするとありがたい構造です。契約は 1 本のまま、使い方だけが人数分に広がります。
そして Kiro Crew は非エンジニア専用ではありません。私自身、開発の仕事でも毎日使っています。IDE でコードを読み、CLI で手を動かし、Crew に長い仕事を預ける ―― この 3 つは排他ではなく、同じ .kiro 設定を共有しながら並行して使えます。ステアリングファイル、スキル、カスタムエージェントは追加設定なしで持ち込めるので、移行という感覚もありません。入口が 1 つ増えたと考えるのが正確です。
変化 3 : 帰った後も、残っている
AI エージェント、まだ「自分が席にいる間だけ動くもの」だと思っていませんか ?
ターミナルを閉じたら終わり。ノート PC を閉じたら終わり。会議に入れば止まり、帰宅すれば止まる。優秀な部下が何人もいるのに、彼らはあなたが席に座っている時間だけしか働けない ―― これは、AI エージェントの使い方としてまだ半分です。
AI エージェントを RPA のような「定型作業の自動化ツール」だと捉えていると、本来の力を引き出せません。感覚として近いのは、優秀な部下が何人か、フルリモートで一気にチームに入ってきた状態です。背景を説明すれば自分で考えて動くし、わからないことは質問してくる。複数の仕事を同時に任せられる。
Kiro Crew を使い始めて、私はこの感覚にもうひとつ付け足したくなりました。
その部下たちは、あなたが退勤した後もオフィスに残っています。
Kiro Crew の性質
公式ドキュメントは Kiro Crew の性質を 4 つ挙げています。部下の比喩で言い換えると、こうなります。
|
公式の言葉
|
部下の比喩で言うと
|
|---|---|
|
Persistent (永続)
|
あなたが帰ってもオフィスに残っている |
|
Self-learning (自己学習)
|
一度注意したことは、次から間違えない |
|
Self-evolving (自己進化)
|
繰り返す仕事は、手順書にして残してくれる |
|
Runs where you choose (実行場所を選べる)
|
どのオフィスに常駐させるかは、あなたが決める |
SSH トンネルのみで接続
そして「常駐させる」と聞くと、そのマシンの前に座らないと使えないように思えるかもしれません。逆です。Gateway は自宅サーバーやクラウドインスタンスにも常駐させられて、接続は SSH トンネル 1 本で済みます。
ssh -NL 5476:localhost:5476 <host>
# あとはブラウザで http://localhost:5476 を開くどこからでも手元で接続可能
Slack から !dashboard と打てば、HMAC-SHA256 で署名された presigned リンクが返ってきます。ダッシュボードは既定でループバックにバインドされる (外部に開かない) 設計なので、ポートを世界に晒す必要はありません。
つまり、朝ダッシュボードで投げた仕事の続きを、移動中にスマホの Slack から確認できる。ワークスペースもその状態も、どこにも移していません。1 つの Gateway を、別の窓から覗いているだけです。
第 2 部 : 実際に任せていること
ここからは実例です。私が実際に動かしたものから順に、15 個並べます。
1. 席を離れている間に、働かせておく
第 1 部で「あなたが帰った後もオフィスに残っている」と書きました。その具体例がこれです。
ダッシュボードの Schedule に、時間で動く仕事を登録しておけます。使い方は大きく 2 つで、溜まったものを仕分けさせるのと、新しいものを集めさせるのです。
(a) 未読メールを毎朝仕分けさせて、対応が必要なものだけ受け取る
これが個人的にいちばん「もう戻れない」と思った使い方です。 私の受信トレイは、放っておくと配信リストの一斉通知やセミナー告知で埋まります。その中に、個人から届いた「返事が必要なメール」が混ざっています。
Before
朝いちに未読を上から順に開いて、返事が必要なものを探す。件数が多い日は 15〜20 分。しかも急いでいると見落とす。【要実測】
After
出社した時点で「今日返事が必要なのはこの 2 件です」という通知が届いている。
Kiro Crew には Outlook を読む MCP サーバーが繋がっているので、受信トレイの未読を取得できます。あとは何の対応を必要とみなすかを日本語で書いて渡すだけです。私が指定した条件はこれです。
- 配信リスト宛の一斉通知、セミナー・イベント告知、ニュースレター、自動レポートは除外する
- 残ったもののうち、個人から個人宛に届いていて、質問や依頼、期限が含まれるものを選ぶ
- 1 件以上あったときだけ通知する。0 件なら何も言わない
登録ジョブについて
登録されたジョブは、こう保存されました。
{
"name": "outlook-triage",
"schedule": { "kind": "cron", "cron_expr": "0 9 * * MON-FRI" },
"timezone": "Asia/Tokyo",
"silent": true,
"persistent_session": false
}0 9 * * MON-FRI は平日の朝 9 時。土日は動きません。そして読み取り専用で動くよう明示的に指示しています ―― 返信も送信も既読化もしません。仕分けて教えるところまでが仕事です。判断も操作も人間が持ったまま、探す手間だけを渡している形です。
「未読を全部見て探す」が「対応が必要なものだけ渡される」に変わる。 メールの量が多い人ほど効きます。
ジョブを止めることも可能
なお「特定の返信を待っているあいだだけ見張って、届いたら通知してこのジョブ自身を止める」という指示もできます。用が済めば自分で消えるので、一時的な見張りを気軽に仕掛けられます。
(b) 毎朝決まった時刻に、集めておいてもらう
こちらは非エンジニアの方でもそのまま真似できる使い方です。私はこの連載を毎月書いているので、Kiro の新しい発表を見落とすと困ります。
Before
思い出したときに公式ブログを開き、GitHub のリリース一覧を見る。忘れると 2 週間気づかない。
After
毎朝 8 時に勝手に見に行ってくれて、新しいものがあったときだけ通知が来る。
作るときにやったことは、日本語で条件を書いて渡しただけです。
毎朝 8 時に、公式ブログの新着と GitHub の新しいリリースを確認して。前回から新しいものがあったときだけ、タイトルと URL と公開日、それから「今月の連載で扱う価値があるか」の一行コメントを付けて教えて。何もなければ通知しないで。
登録ジョブについて
これで登録されたジョブが、こう保存されました。
{
"name": "kiro-content-radar",
"schedule": { "kind": "cron", "cron_expr": "0 8 * * *" },
"timezone": "Asia/Tokyo",
"silent": true,
"persistent_session": false,
"minimal_context": true
}ポイントは 3 つあります。
- silent : true ―― 変化がないときは黙っています。毎朝「新着なし」を受け取ると、人は 3 日で通知を読まなくなります
- timezone : Asia/Tokyo ―― ジョブごとにタイムゾーンを持てます。祝日や休暇をスキップする skip_dates も指定できて、スキップした日は最終実行時刻を更新しないので「前回以降」の判定が自然にずれません
- persistent_session : false ―― 毎回まっさらなセッションで動きます。毎日走るポーリング系のジョブは、これを付けないと会話が延々と太っていきます
見張り方は、ほかにも選べます
同じ Schedule でも、(a) は 溜まったものを仕分ける役、(b) は 外から新しいものを拾ってくる役です。どちらも私が寝ているあいだに動いて、朝には結果だけが置かれています。 自分が見ていない時間が無駄にならないのが、ここでの効き目です。
そして見張れる対象は、 繋いだツールの数だけ増えます。(a) で Outlook の受信トレイを読めているのは、Outlook 用の MCP サーバーを繋いでいるからです。同じやり方で、チャット、チケット、リポジトリ、社内システムにも手が届きます。すでに使っているツールを持ち込めるので、「Kiro Crew のために業務を移す」必要はありません。
2.「前に言ったよね」を、覚えている
Before
新しいチャットを開くたびに、前提から説明し直す。
After
説明しない。
仕組みでコンテキストを保持
Kiro Crew は、好み・作業中のプロジェクト・日次の履歴をファイルとして持ち続けます。実際に私の環境では、こうなっています。
~/.kiro/crew/workspace/memory/
├── preferences.md # 好み・スタイル
├── projects.md # 作業中の内容・決定・ブロッカー
└── history/
├── 2026-08-05.md # 日ごとの会話サマリー
└── 2026-08-10.md日次履歴は時間とともに解像度が落ちる設計になっていて、直近は全詳細、古くなるにつれて要約だけになり、1 年を超えると自動で消えます。放っておくとコンテキストが太っていく問題を、仕組みの側で処理しているわけです。
そしてもう 1 つがレッスンです。会話の中で「そうじゃなくて」と訂正すると、それが抽出されて以降の振る舞いが変わります。実際、この記事を書く途中で私が「そういう予防線はいらない」と言ったら、それがレッスンとして保存され、次から書き方が変わりました。
3. 繰り返す手順は、Markdown 1 枚にする
Before
毎回同じ説明をチャットに書く。
After
SKILL.md を 1 枚置いて、以降は勝手に読まれる。
実際のスキル
スキルは frontmatter 付きの Markdown です。実物の形はこうです。
---
name: web-preview
description: ローカルサーバーを立てたとき、ダッシュボードの Browser タブを
自動で開かせるためのマーカーを出す
triggers: preview, dev server, npm run dev, localhost
---
# 本文
このスキルが有効化されたときにエージェントが読む、手順・例・リファレンス。
triggers に書いた語がユーザーの発言に現れると、自動で読み込まれます。全セッションに常時読ませることも、話題が出たときだけ全文を読ませることもできます。
そして重要なのが、この形式は Kiro IDE / CLI の steering と同じという点です。IDE で書いた資産がそのまま動きます。
4. 資料づくり ― チャットで説明すると .pptx が返ってくる
PPTX Maker App は、作りたいスライドをチャットで説明すると、本物の .pptx を返してくれます。面白いのは、構成中のスライドが SVG でライブプレビューされるところで、ブリーフ → アウトライン → アートディレクション → 各スライドと、成果物が順に画面に現れます。
スタイルとテンプレートが分離しているので、同じ内容を別の見た目に付け替えることもできます。手持ちの .pptx テンプレートを読み込ませて、その配色やレイアウトに合わせてもらうこともできます。
5. 会議 ― 文字起こしから議事録・図・タスクまで並列で
おそらく非エンジニアにいちばん刺さるのはこれです。
Before
録音を聞き直して議事録を書き、タスクを拾い出して起票する。会議 1 時間につき 30 分。【要実測】
After
会議が終わった時点で、議事録と図とタスク一覧ができている。
Meetings App
Meetings App は、ライブ会議を文字起こししながら、複数のエージェントが並列で構造化ノート、図 (HTML / Mermaid)、アクションアイテムの抽出を進めます。抽出されたタスクは、起票する前にレビューを通せます。
6. 調べもの ― 放置して安全な調査エンジン
Research Lab は、ひとつの問いを対話的にサブ問いのツリーへ分解 (grill tree) してから、サイクルごとに調査して findings を積んでいきます。成功条件を自然言語で書いておくと毎サイクル検証され、5 サイクル連続で新しい発見がなければ停滞として扱われます。
そして設計として重要なのが、Research Lab は調べて報告するだけで、システムに書き込まないという明示的な境界です。サブエージェントは読み取り・調査系のツールしか持ちません。だから離席して回しても影響範囲が小さい。行動が必要になったら、承認フローのある通常のエージェントに引き渡されます。
市場調査や技術調査を投げて、会議に出て、戻ってきたらレポートを読むという使い方ができます。
実行モードが 2 つある
ここはソースを読んで気づいた部分です。Research Lab には性格の違う 2 つの実行モードがあります。
|
|
Agent (adaptive) ― 既定
|
Dynamic Workflow
|
|---|---|---|
|
制御フロー
|
LLM が毎サイクルの司令塔。次に何を調べるかを実行時に決める |
決定論的な再帰スキャフォールド。plan → explore → finalize が固定 |
|
LLM の出番
|
ループ全体を運転する |
末端の 1 回ずつの呼び出しだけ |
|
向いている場面
|
進む道が読めず、出てきた手がかりを追いたいとき |
手順が決まっていて、再現性が欲しいとき |
「調べ方そのものを考えてほしい」のか「決めた手順で漏れなく回してほしい」のか ―― 調査の性質で選べるようになっているわけです。
そして Dynamic Workflow 側に、reserve-and-finalize という仕掛けが入っています。最後の何ラウンドかが最初から予約されていて、上限まで探索し続けた結果レポートを書かずに終わる、という事故が起きません。「調べ切って力尽きる」を構造で防いでいます。放置して回す道具として、これは効きます。
コード実行の境界が明確
ワークフロー本体はサンドボックス内で実行され、import も eval も open も使えません。安全な組み込みと決められたインターフェースだけで、しかも実行前に検証を通ります。エージェントが書いたコードを走らせる場所として、境界がはっきりしています。
7. 多ステップの仕事を、計画から任せる
Schedule が「時間で動かす」仕組みなら、Task Runner は「仕事を渡して完遂させる」ための App です。専用のページを持っていて、渡し方も 3 つあります。やりたいことを普通の言葉で説明する、書いた仕様を貼る、YAML を渡す。
私が良いと思ったのは、走らせる前に計画を見せてもらえることです。いきなり実行させることもできますが、まず手順に分解させて、それを読んでから GO を出せます。認識がズレていたらこの時点で分かります。
走り出すと、実行ごとに専用のページができて、ステップごとの進捗が記号で見えます (✅ 完了 / 🔄 実行中 / ❌ 失敗 / ⏳ 待機）。一時停止・再開・リトライ・停止はいつでもできます。
私は週次や月次の活動を Outlook や Slack などを漁ってレポートするのに活用しています。
Task Runner のイメージ
おまけ : 机の上の遊び心
プリセットの App には明らかに実務ではないものも入っています。これがこのプロジェクトの性格をよく表していると思うので紹介させてください。
- Mochi : デスクトップに住むペット型のコンパニオンです。透明でクリックスルーの窓に居て、あなたのために watch list を持ち、自分の 1 日の予定を立てて再計画します。通知はマージされ、静音モードでは保留されます。移動や表情の変化はモデルを呼ばないので、トークンを消費しません。癒されましょう。
- Agent Worlds : 稼働中のエージェントを、ピクセルアートのキャラクターとして表示します。オフィス、ウィザードの塔、深海ラボといったテーマのシーンがあり、別モニターにポップアウトできます
業務の重い App から、机の上のペットまで。3.9 万人がそれぞれの必要に応じて足してきた結果がこれなのだと思うと、なんだか納得します。バックログに埋もれたままになりそうな細かい改善や、そのワークフローの中で生きている人だけが思いつく機能が積み上がってきた ― そういうツールです。
そして、こういう「業務じゃないもの」が入っていることは、非エンジニアに渡すときに案外効きます。とっつきやすさが違います。
おわりに
Kiro IDE はエディタを開ける人の道具で、Kiro CLI はターミナルを開ける人の道具でした。Kiro Crew は、誰でも使うことができます。この差は思っていたよりずっと大きくて、私が社内で「これは、ちょっと難しいかもしれません」と言葉を濁していた相手にも、いま渡せるようになりました。
しかもこれは「乗り換え」ではありません。Kiro を契約していれば、IDE を使うか、CLI を使うか、Crew を使うかは各自の自由です。エンジニアはこれまでどおり IDE と CLI を使いながら、長い仕事だけ Crew に預けられます。契約は 1 本のまま、選択肢が増えただけです。
そして冒頭に書いた「差が開く」という話に戻ります。私が 6 時間おきの見張りを 1 つ仕掛けただけで、寝ている間も情報が集まってくる状態になりました。これを 10 個仕掛けているチームと、毎朝手で GitHub を開いているチームでは、1 年後にどうなるか。想像はつくと思います。
もし試すなら、すでに 1 セッションを超えて広がっている作業から始めるのがおすすめです。監視が必要な依頼、定期的なレビュー、時間のかかる調査。「自分が待っているだけの時間」がある作業ほど、効果がはっきり出ます。
最後に、この記事の作り方について書いておきます。
冒頭に書いたとおり、この記事は Kiro Crew と一緒に書きました。ただし執筆のルールとして、「コンテンツは私が自分の意思を込めて書く。あなたは与えられた情報とコンテキストを、読みやすく整理・整形することに徹する」という指示を与えています。だから、私が思ってもいないことが生成されることはありません。
それでは、良い Kiro Crew ライフを !
筆者プロフィール
稲田 大陸 (いなりく / @inada_riku)
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト
AWS Japan で働く筋トレが趣味のソリューションアーキテクト。製造業のお客様を支援させていただいています。最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、Kiro のブログなどを執筆しています。
