AWS の技術ブログ

全3894件

2026/11/06

本記事は 2026 年 11 月 5 日に Kiro ブログで公開された「 Introducing bots in Kiro Crew 」を翻訳したものです。図 1: Kiro Crew の Bot の一覧火曜日の朝、あなたはいくつかのエージェントのセッションを立ち上げるところから 1 日を始めます。1 つは認証モジュールのリファクタリング、もう 1 つは不安定なテスト（flaky test）の原因の調査、3 つ目は新機能のリリースに必要なデータベース移行の計画の下書きです。さらにもう 1 つが、今日このあとの引き継ぎに使うオンコールのまとめを仕上げています。せっかくなので、前から温めていたアイデアを調べるセッションも始めます。自分のコードベースをセマンティック検索できるようにするというアイデアで、業界の優れた事例もあわせて調べさせます。これらを動かしてから、その日最初の打ち合わせに向かいます。戻ってくるころには、作業がかなり進んでいるはずです。ところが戻ってみると、リファクタリングは、前に承認したはずのツールを信頼するかどうかの判断待ちで、ほぼずっと止まっていました。不安定なテストには修正が入っていますが、なぜその修正にしたのかがはっきりしません。移行計画の下書きはできていますが、大幅な手直しが必要です。引き継ぎのまとめはできたものの、そのエージェントはその後ずっと何もせずに待っています。調査の結果は論文とオープンソースのプロジェクトを集めただけで、どの手法が自分のコードベースに実際に合いそうかの比較はありません。エージェントは並行して動きました。しかしあなたは、セッションごとにどこで手を止めたかを思い出し、実際に何が終わったのか、何がまだ残っているのか、自分が下すべき重要な判断がどこにあるのかを把握し直さなければなりません。並行して動かすタスクが増えるほど、セッションのあいだでコンテキストを受け渡したり、どのセッションが終わり、どのセッションがあなたの入力を待っているかを確かめたりする時間が増えていきます。作業を止めずに正しい方向へ進め続ける責任は、依然としてあなたにあります。 2026 年 11 月 5 日、Kiro Crew で Kiro の Bot の一般提供が始まりました。Bot は、エージェントによる作業を組み立てて進めるための新しい方法です。ばらばらのセッションで作業する代わりに、作業の特定の部分を受け持つエージェントを Bot として定義し、カスタマイズします。Bot はそれぞれ名前を持ち、長く動き続けます。Bot は自分のメモリを持ち、自分でセッションを動かすので、あなたがセッションを 1 つずつ追いかける必要はなくなります。Kiro Crew はもともと、あなたの仕事の進め方から学習します。Bot によって、その学習が蓄積される場所が変わります。 Bot はそれぞれ名前とアバター、そして続いていく 1 つのチャットを持ちます。あなたはそのチャットで方向を示し、結果を受け取りに戻ってきます。Bot を作るときは、コードベースに合った調査を続ける、といったゴールを決めます。Bot はそのゴールに向けて自分から動きます。作業を追跡するための自分のメモを持っているので、決めたことや未解決の項目を確認できます。Bot が持つものはすべて、Kiro Crew の中のその Bot 専用のワークスペースに置かれます。そこにはあなたがカスタマイズできるダッシュボードもあり、セッションを 1 つも開かずに作業の状況を確かめられます。図 2: devbot という Bot の、続いていく 1 つのチャットやるべき作業があると、Bot はセッションを並行して立ち上げて見守り、計画からそれていくものを軌道に戻し、結果を 1 つのチャットに持ち帰ります。あるタスクにあなたの判断が要るときは、Bot はあなたに尋ねつつ、答えに左右されない部分の作業を続けます。チャットでスケジュールを設定することもできます。たとえば、あなたが 1 日を始める前に夜間のビルドの失敗を Bot に調べさせたり、毎週金曜日にリリースノートを用意させたりできます。 Bot には、その仕事に必要なツールと権限だけを与えます。たとえば調査用の Bot は Web を検索し、ファイルを読めますが、ファイルを変更することはできません。デプロイ用の Bot はデプロイのスクリプトを実行でき、変更を加える前に毎回あなたの承認を求めます。Bot がツールの追加をあなたに頼むこともできますが、あなたがその依頼を承認するまで何も変わりません。Bot はそれぞれ自分のメモリを持つので、デプロイ用の Bot がリリースの進め方について学んだことと、調査用の Bot が学んだことは混ざりません。学んだことを分けておくことで、各 Bot はあなたの判断を自分の担当の範囲に当てはめます。こうして、あなたの手元には、あなたが関わるべき作業が残ります。何をもって良しとするかを決め、結果を確かめ、個々のセッションに逐一指示を出すのではなく、プロセス全体の舵を取ります。判断の理由を作業と一緒に残す作業の部分ごとに、判断を左右する固有のコンテキストや細かな事情があります。エージェントがこれらのタスクをまたいで実行するあいだ、あなたは意図とコンテキストを部分から部分へつなぎ、トレードオフをはっきりさせ、各エージェントの判断の背後にある方針を言い直し続けなければなりません。 Kiro の Bot では、あなたの方針が見える形で残り、あとから手直しできます。Kiro Crew の学習は Bot ごとに積み上がっていきます。そのため、単発のタスクではなく、続いていく役割そのものを任せられます。Bot は自分の専門について、あなたが目指す成果、トレードオフの理由、変更に課される制約、すでに下した判断を理解しています。ある Bot が issue の受け付けを受け持ち、別の Bot がリリースの準備を受け持つといった形で、それぞれがその作業のためにあなたが決めたルールに従います。Bot は、ノート PC、Mac mini、EC2 インスタンスなど、あなたが Kiro Crew を動かしている場所で動きます。Bot のクルーは全体として、開発作業のあらゆる場面で、あなたのレビューの基準、リリースのプロセス、あなた独自の好みを支えます。1 つの汎用的なワークフローに押し込められることはありません。あなたの判断の基準は、続いていく会話と、あなたが返すフィードバックを通じて形になります。あとの作業が同じ判断に依存するとき、Bot はあなたの方針を引き継いで進めます。制約が変わったら Bot に伝えてください。Bot は新しい方針に従い、その内容は確認できるメモとして残ります。Bot があなたとともに変わっていくあいだも、あなたの判断は作業の裏付けとして残り続けます。あなたの役割は、並行するタスクの調整から、方向を決め、あなたの入力が必要なものだけをレビューすることへと移ります。修正や判断を重ねるたびに、Bot はあなたの意図をより正確に理解するようになります。開発の進め方に合わせてクルーを組むまず、開発のプロセスを、繰り返し発生する役割や、タスクをまたいで続く役割に分けて整理します。最初は、説明でき、評価もできるプロセスを 1 つ選びます。作業の目的が変わるところや、別のツール、権限、レビューが必要になるところに Bot を足します。作業がどのように Bot に届くか、どの情報源を参照するか、役に立つ引き継ぎとはどういうものか、どんなときにあなたの入力を求めてほしいかについて、境界を決めます。最初は Bot に任せたい作業の範囲と性質に合った境界から始め、結果や無駄を評価しながら少しずつ見直していきます。たとえば issue のトリアージを行う Bot を作り、初めはチケットのキューにだけアクセスできるようにしておき、あとから Slack や、ほかの issue の受け付け経路へのアクセスを足していく、といった進め方ができます。 Bot ごとに専門に合わせて調整する最初に作る Bot の組み合わせの例を挙げます。Bot ごとに、使えるツール、権限、何をもって作業完了とするかが違います。どの Bot も、ほかの Bot に手を加えずに調整できます。受け付け用の Bot は、チケットのキューに入った新しい issue を読み、ラベルを付け、重複していそうなものに印を付けます。バグとされたものには、再現手順の下書きを書きます。チケットにコメントはできますが、クローズはできません。ビルドの健全性を見る Bot は、CI パイプラインを 30 分ごとに確かめます。新しい失敗を、すでに分かっている不安定なテストと切り分け、対応が必要なものだけを持ち帰ります。コードレビュー用の Bot は、新しいプルリクエストを 1 つずつ、あなたがこれまでに下した判断に照らして確かめます。採用すると決めたエラー処理のパターンや、使わないと決めた依存関係といった過去の判断を覚えているので、レビューが毎回ゼロから始まることはありません。コメントを残したり変更を求めたりはできますが、承認やマージはできません。リリースの準備を担う Bot は、各リリースの前のチェックリストを受け持ちます。マージされた変更にテストとリリースノートがあることを確かめ、何かを出荷する前にあなたの承認を求めます。 Bot が覚えていることは、どれも表示、編集、削除できます。余計なレビュー、少しずれた結果、無駄な手順が見つかったら、その場で Bot を直接調整することもできます。従うルールを変えたり、ワークフローが変わったときにツールを足したり、権限を絞ったりできます。たとえば、リリースの準備を担う Bot をあなたの作業に合わせて調整していけば、いずれは簡単な変更を CI が通った時点でマージさせることもできるでしょう。Bot ごとに別々に調整できるので、あらゆる種類の作業に 1 つのルールを押し付ける必要はありません。図 3: Bot の設定。権限、モデル、ワーカーのモデルを Bot ごとに選べるこの調整が積み重なって効いてくるのが、繰り返し行う作業です。ビルドの健全性を見る Bot に、CI パイプラインを 30 分ごとに確かめ、新しい失敗を調べ、対応が必要なものを持ち帰るよう伝えます。スケジュールで動いた記録は作業ログに残り、あなたが見るべき発見や判断が必要な事柄はチャットに戻ってきます。想定済みの失敗を Bot が追いかけていたら、そのことを Bot に指摘してください。以降の実行では、その区別が反映されます。図 4: Bot のスケジュール。Bot が自分で動くハートビートと、あなたが設定したスケジュールが並ぶ Bot はそれぞれメモを付けています。メモは、Bot が問題を調べ、タスクを終え、あなたから学ぶにつれて育っていく、プロジェクトについての実務上の理解です。メモを見れば Bot が何を引き継いでいるかが分かり、作業ログを見ればこれまでに何が行われたかを把握できます。何度か実行したら、スケジュールや入力を調整したり、結果にフィードバックを返したりして、プロセスを細かく調整し続けます。セッションの管理から Bot の管理へプロセスの中で自然に引き継ぎが起きる場所ごとに、Bot を作ります。Bot それぞれに固有の要件とアクセス権を与え、前の工程から何を受け取るべきかを決めます。そうして、役割ごとの区別を保ち、それぞれを個別に調整できる状態のまま、クルーを育てていきます。 Bot は、ワーカーエージェントにまたがる並行のセッションを自分で取りまとめられます。ただし、Bot がどこまで自分から動くかは、あなたが許した範囲までです。Bot ごとに動かすモデルを選べ、ワーカーエージェントには別のモデルを選ぶこともできます。Bot は性能の高いモデルで計画を立て、ワーカーエージェントは速くて安いモデルで決まった確認をこなす、という分担ができます。Bot がスケジュールで動く作業や繰り返しの作業を多く担うようになるほど、あなたは結果をレビューし、各 Bot が受け持つ作業によりよく合うように調整することに時間を使えるようになります。図 5: Bot が動かすワーカーのセッション Bot が取りまとめている作業は、ダッシュボードで見える形にできます。活動やレポートをどのように見たいかを Bot に伝えると、その作業の今の状態が、Bot が管理するダッシュボードにまとめて表示されます。チャットは、あなたが目を通すべき発見、引き継ぎ、質問に絞られたままです。活動の中身を確かめたいときは、関連するセッションを開いてレビューできます。図 6: GitHub の issue を扱う Bot のゴールとマイルストーンと、その横に並ぶ Bot が管理するダッシュボード。直近 1 週間に報告された issue をトピックごとに図にしている。原文の記事ではこの画面を動画で紹介しているため、ここではその 1 コマを載せた（動画は原文の記事で見られる）。時間がたつにつれて、クルーはあなたの実際の開発の進め方を映すようになり、各 Bot は自分が受け持つ作業の要件と境界を担うようになります。そのプロセスをどう変えるか、どこであなたが判断するかは、あなたが決めます。 Kiro の Bot を使ってみる始めるには、Kiro Crew のサイドバーで Bot のワークスペースを開き、Bot を追加して、ベースにするエージェントとして既定のエージェントかカスタムエージェントを選びます。カスタムエージェントを選ぶと、そのプロンプト、モデル、ツール、スキルを Bot が使うので、今あるチャットを変えずに、すでに使っている設定をもとに Bot を作れます。まずは、今まさにセッションをまたいでコンテキストをつなぎ直す手間がかかっている役割を 1 つ選びます。1 回で見直せるくらいに範囲が狭く、繰り返す価値があるほど役に立つものがよいでしょう。Bot に名前を付け、何を見てほしいかを伝え、一緒に作業しながら調整し、スケジュールも足してみてください。続いて、プロセスの中の次の役割にも Bot を足し、あなたの仕事がタスクを任せる形からプロセスを任せる形へと変わっていく様子を確かめてください。 Kiro Crew をダウンロードして始めましょう。詳しくは Kiro Crew のページをご覧ください。原文の著者 Kyle Seaman（Product Lead）、Helen Hasbun（Product Marketing）翻訳者について稲田大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログなどを執筆しています。

AWS の技術ブログ

コンテンツ