Kiro Crew、みんなで使えていますか ? ~ チームで Kiro Crew を使うために、知っておきたい 6 つの使い方 ~
2026-11-04 | Author : 深澤 真愛
はじめに
こんにちは、ソリューションアーキテクトの深澤です。
Kiro Crew は 2026 年 8 月に公開された新しいツールです。 builders.flash では、いなりくさんが、Kiro Crew に仕事を任せる使い方 を紹介しました。 みなさん、使い始めましたか? ターミナルを使わない人でも、席を離れている間でも、Kiro Crew なら仕事を任せられるようになりました。
そして、AI を手元で使い始めると、次はチームで使いたくなってきませんか ?
チームで使うときの 1 つ目の課題は、各自の Kiro Crew が持つ知識とルールがチームで揃っていないということです。 同じプロジェクトに取り組んでいても、知識とルールが人によって違えば、同じことを頼んでも前提や振る舞いが異なります。
2 つ目の課題は、生成物の扱いです。 AI で作る速さが上がった分、1 人が作るダッシュボードや分析結果、資料といった生成物の量が増えました。 生成物の数が増えると、どれをどこまで自分が確認したか、どこをチームに直してほしいかを管理するだけでも大変です。 チャットで修正を頼むと、その指示がやりとりの中に埋もれてしまうこともあります。 さらに、生成したものをチームと共有する方法にも困ります。 Amazon 社内でも、ビジネス側の業務で Kiro を使っているメンバーから、「作ったダッシュボードをチームに共有したい」という声がありました。
Kiro Crew には、チームで AI を活用するための仕組みがあります。例えば、以下のような体験を実現できます。
- Kiro Crew に与える知識とルールをチームで揃える
- 作ったものは Artifact に保存し、バージョンとコメントを管理する
- Artifact Deploy で URL を発行して渡す
この記事では、チームで Kiro Crew を使うための 6 つの使い方を、実際の画面を見ながら紹介します。
ご注意
本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。
builders.flash メールメンバー登録
builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。
Kiro Crew をチームで使う流れ
プロジェクトの月次ダッシュボードを Kiro Crew で作り、チームメンバーに共有するというユースケースで見ていきましょう。 まずチームの知識とルールを揃え、その上でダッシュボードを作って保存し、修正とレビューを経て共有します。
1. 知識を共通にする (Knowledge)
プロジェクトのルールに則ってタスクを進める時、チームメンバーが知っているコンテキストが異なっている場合、それぞれの Kiro Crew は異なった前提のもとでダッシュボードを作ってしまいます。
Knowledge は、Kiro Crew に参照してほしい資料を自分で登録することができる場所です。 ファイル、フォルダ、URL を追加すると、Kiro Crew が中身を分割して索引を作ります (公式ドキュメント)。 依頼の内容が登録した資料に関係するときや、保存した資料を使うよう頼んだときに、エージェントが関係する部分を検索して読みます。 ライブラリ全体を毎回読み込むわけではありません。
今回は、集計ルール、用語集、商品カテゴリ一覧の 3 つの文書が入ったチームの共有フォルダを登録しました。
資料のどこを読めばよいかを、人が指定する必要はありません。 Kiro Crew が関係する部分を自分で検索して読みます。 確実に参照させたいときは、3 章の依頼文 (「集計ルールと用語集に沿って」) のように、資料の名前を依頼に入れると効果的です。
MCP で取る情報と、Knowledge に入れる資料の使い分け
Slack や社内 Wiki を MCP サーバーでつないでいれば、資料はその場で取得できます。 それでも Knowledge に入れる意味はあるのでしょうか。 使い分けの目安は次の表の通りです。
|
|
MCP で情報を取得する
|
Knowledge に登録する
|
|---|---|---|
|
適している情報
|
最新の情報を知りたいもの (Slack の直近の会話、チケットの状態、カレンダー) |
変更が少ない資料 (設計方針、集計ルール、用語集、規約) |
|
探し方
|
エージェントが文脈から判断して取りに行く |
事前に登録しておいた資料から関連部分を検索する |
|
対象
|
MCP サーバーがあるシステム |
手元の PDF や docs、共有フォルダ、任意の URL |
更新が頻繁な情報は MCP で取り、MCP でつながっていない資料や、チームで前提として共有したい資料は Knowledge に入れる、と分けると効果的に両者を利用することができます。
チームでの使い方
Knowledge は各自の Kiro Crew に登録されるため、チームで利用したいときは、全員が同じフォルダやドキュメントのリンクをそれぞれの Knowledge に登録します。エンジニアも、設計書や ADR を Knowledge に入れておけば、コードを書きながら Kiro Crew に「この設計方針で」と指示することができます。
2. ルールを共通にする (Steering)
1 章では、資料を Knowledge で揃えました。 ただ、レポートの書き方や、お客様への連絡で気をつけることといった仕事の進め方は、まだ各自のやり方で進めています。このままでは、同じ依頼をしても、生成物の表現や仕事の進め方が人によって変わってしまいます。
Steering は、仕事の進め方のルールを Markdown で書いておく仕組みです。 ワークスペースの .kiro/steering/ にファイルを置くと、そのワークスペースのセッションはルールを自動で引き継ぎます (公式ドキュメント)。 毎回の依頼文にルールを書き添える必要はありません。 Kiro Crew は Kiro CLI の上で動き、.kiro の設定を共有するため、Kiro IDE や Kiro CLI 用に書いた .kiro/steering/ のファイルも、追加の設定なしでそのまま使えます (builders.flash 2026 年 9 月号)。
今回は、営業企画チームの作業ルールを 1 つのファイルにまとめました。書いたのは、たとえば次のようなルールです。
- レポートの冒頭に、結論を 3 行以内でまとめる
- 前月比が大きく動いた指標には理由を添える。データから読み取れないときは「要確認」と書き、推測で断定しない
- 数値は、Knowledge の資料か渡されたデータにあるものだけを使う
- メールや Slack の文面は下書きまで作り、送信は人が行う
どのルールも、全ての指示に対して守ってほしいルールです。 Knowledge は依頼に関係するときだけ検索して読まれるため、こうしたルールは毎回読み込まれる Steering に書きます。
Knowledge との役割の違い
Knowledge との役割の違いは、次の表の通りです。
|
|
Steering
|
Knowledge
|
|---|---|---|
|
中身
|
仕事の進め方のルール、規約、確認すること |
参照してほしい資料そのもの |
|
分量
|
短くまとめる。毎回読み込まれる |
長くてもよい。必要な部分だけ読まれる |
|
置き場所
|
ワークスペースの .kiro/steering/ |
各自の Kiro Crew のライブラリ |
|
配布方法
|
リポジトリを共有する |
各自が同じソースを登録する |
チームで同じファイルを利用する場合は、.kiro/steering/ を含むリポジトリを共有するのが基本です。 自分のホームディレクトリにある ~/.kiro/steering/ に置いたファイルは、ワークスペースに関係なく、すべてのセッションで読み込まれます。 Kiro の Steering のドキュメント には、チームで使う方法として、中央のリポジトリから ~/.kiro/steering/ にダウンロードする方法や、MDM で配る方法も挙げられています。
3. 作ったものを Artifact に保存する
Knowledge と Steering を整理したので、そのルールに従ってプロジェクトのダッシュボードを生成してみます。架空の会社 AnyCompany のダミーデータを利用して、売上ダッシュボードを生成します。Kiro Crew に「集計ルールと用語集に沿って、売上ダッシュボードを作って」と頼みました。
Artifact に保存
今後もこのダッシュボードを利用するため、Artifact として保存します。 Artifact は、Kiro Crew のチャットで作った表やダッシュボードなどの生成物を保存しておく仕組みです。 保存した生成物は専用のライブラリに入り、バージョン履歴やコメントを持ちます ( 公式ドキュメント )。 チャットで「これを Artifact に保存して」と頼むだけで、Artifact に保存することができます。
Artifact の確認方法
保存した Artifact は、ダッシュボードの Artifacts パネルで確認できます。 翌月、数値を差し替えて更新すると、新しいバージョンとして保存されます。画像では、数値が更新された v2 として保存されたことが確認できます。
前のバージョンに戻したいときは、バージョン履歴から戻すことが可能です。
4. 修正して、別の案も試す (ウィジェット・フォーク)
保存したダッシュボードの配色と並び順を変えたくなりました。 修正の指示は文章で書いてもよいのですが、Kiro Crew はチャットの中に操作できる画面を出すことができます。 これを ウィジェット と呼びます。 ボタンやフォームを持つ HTML がチャットメッセージの中に表示され、操作した内容が Kiro Crew に送信されます (公式ドキュメント)。
Artifact の更新
フォームで選んで送信すると、Kiro Crew がその選択内容を参照し Artifact を更新します。
別の案も試したい場合
別の案も試したいときは、セッションをフォークします。 フォークすると、それまでの文脈を引き継いだ新しいセッションタブができ、以後は独立して進みます ( 公式ドキュメント )。 2 つのタブでそれぞれ別案を作り、両方を Artifact に保存して並べることで比較しながら選択することができます。
5. レビューしてコメントをつける
チームに公開する前に、ダッシュボードを確認しながらコメントや修正指示を記載しましょう。Artifact のダッシュボードにはライブプレビューがあり、生成物に対してコメントをつけることができます。チャットで指示すると修正指示がエージェントとのやり取りの中で埋もれてしまうことがありますが、コメントとして記載すれば、Artifact 上に残すことができます。
コメント内容を生成物に反映させるには
コメント内容を生成物に反映させたい時は、コメントビュー下部の「エージェントに対応を依頼」からエージェントを実行することができます。
コメント内容が売上ダッシュボードに反映されたことが確認できました。
6. チームメンバーにも共有する
自分のチェックを済ませたので、次はチームメンバーにも共有します。
Artifact は自分の Kiro Crew に保存されています。 同僚の Kiro Crew からは見えませんし、Kiro Crew を使っていないマネージャーも開けません。 そこで使えるのが Artifact Deploy です。 Artifact を自分の AWS アカウントの S3 と CloudFront に配置し、公開 HTTPS URL を発行します (公式ドキュメント)。 受け取った側は、Kiro Crew も AWS アカウントも持たずに、ブラウザで URL を開けます。
公開範囲に注意する
Artifact Deploy には、閲覧できる人を絞る設定はありません。 URL には認証がかからないので、URL を知っている人なら社外の人も開くことができます。 公式ドキュメントにも、公開した内容は誰でも見られるので公開してよいものだけを公開するよう書かれています (公式ドキュメント)。
アクセスを絞りたい場合は、公開先の CloudFront ディストリビューションに AWS WAF を関連付けます (AWS WAF による保護を使用する)。 たとえば、会社のネットワークの IP アドレスからのアクセスだけを許可するルールを作成し紐づけることができます。 ただし、WAF で絞れるのは接続元の IP アドレスなどの条件だけのため、閲覧できる人を個別に指定することはできません。 WAF は Kiro Crew の機能ではないため、AWS 側で自分で設定します。 なお、静的サイトの公開では、アカウント内の CloudFront ディストリビューション 1 つを複数のサイトで共有します (公式ドキュメント)。 そのため、WAF の設定は同じアカウントで公開したすべてのサイトに適用されます。 また、公開し直すと共有の設定が更新されることがあるため、手動で関連付けた WAF が公開し直した後も有効であることを確認してください。
事前準備
公開する前に、Kiro Crew と AWS の両方で準備が必要です。
まず、App Store で Artifact Deploy アプリを有効にし、サイドバーから開いた Artifact Deploy コンソールに、公開先の AWS アカウントのプロファイルを登録します。 公開できるかどうかは、管理者がガバナンス設定の capabilities.publish と config.json の publish.allowed_destinations で決めています。 公開の操作が表示されない、または拒否される場合は、管理者に公開の許可を依頼してください。 次に、Kiro Crew が生成する最小権限の IAM ポリシーを、自分でロールに適用します。 Kiro Crew は IAM を書き換えません。
また、公開の操作と期限切れの公開物の削除は、どちらも kirocrew:managed=true タグが付いたリソースだけが対象です。 先ほどロールに適用した IAM ポリシーも、このタグが付いたリソースだけを操作できる内容になっています。 公開物には既定で 72 時間の TTL (公開期限) が付くため、公開に使うリージョンごとに reaper (期限切れの公開物を自動で消す仕組み) を作っておく必要があります。 reaper がないと、公開は拒否されます。 期限なしで公開する場合は、reaper は不要です。 登録できるのは、~/.aws/config に設定した名前付きプロファイルです。
手順の詳細は、公式ドキュメント の AWS setup を参照してください。
公開と更新
Artifact を公開します。 なお、Artifact の種類が webapp の場合は、アプリの内容に応じて、Lambda や DynamoDB テーブルもあわせて作られます。
公開を確定する前に、プレビューが表示されます。プレビューには、作成されるリソース、リージョン、費用の見積もりが出ます。 内容を確認して公開を確定すると、CloudFront の URL が発行されます。 なお、事前スキャンで認証情報が見つかった場合は、公開できません。
内容を直したときは、同じ Artifact から再度公開します。 既存のサイトがその場で更新されて URL は変わらないので、渡した相手に URL を送り直す必要はありません。
おわりに
この記事では、AI をチームで利用する際に起こる、知識とルールが人によって違うという課題と、生成物が増えすぎて管理しきれない、という 2 つの課題を Kiro Crew で解決する方法をご紹介しました。 知識とルールは Knowledge と Steering で揃え、生成物は Artifact に保存し、Artifact Deploy で公開して URL を共有することで、Kiro Crew をより活用しながらチームでタスクを進めることができます。
どれも、各自の Kiro Crew で設定するだけで使い始めることができます。 まずは、チームの資料が入ったフォルダを Knowledge に登録し、普段の仕事のルールを Steering のファイル 1 枚にまとめるところから試してみてください。
生成物を公開する際は、公開する範囲に気をつけてください。 Artifact Deploy で発行した URL は、知っている人なら誰でも開くことができます。 社内の数値や顧客の情報を含むものは、公開せずに扱いましょう。
1 人で使っていた Kiro Crew を、チームで使うきっかけになればうれしいです。
