2026年11月5日、AWSは開発作業の環境であるKiro Crewで、ボット機能の一般提供を発表しました。11月5日付のVentureBeatも、継続的な仕事を持つボットが作業を分担し、途中の判断を記憶する機能として報じています。定刻に動かすにはCrewの実行環境が稼働している必要があります。
外部に頼んでいる予約システムの改修で、朝に「昨夜のテストが失敗」とだけ届いたとします。どの変更で何を確認したテストか分からなければ、依頼先へ聞き直すところから始まります。何も届かない日は、全部通ったのか、テストや確認そのものが動かなかったのかも区別できません。小規模チームが委託先へテスト失敗の情報を渡す場合に絞って、この機能を試す条件を整理します。
一度の質問で終わらず決めた仕事を持ち続けます
通常のチャットでも、貼り付けたテスト結果をその場で整理できます。ここでいうボットは、決めた目的に沿ってAIが継続して作業する仕組みです。Kiro Crewでは、名前を付け、目的と途中経過を同じ会話で扱い続ける仕組みです。ボットごとに記憶と作業場所を持ち、個別の調査を別の作業セッションに割り振り、結果を元の会話に集められます。新しいボットに、以前の別のチャットが引き継がれるわけではありません。
今回の例なら、「毎朝、決めた試験の結果を見て、次に人が確かめることを整理する」という役割です。報告の見本や、どこまでを確認済みとするかを同じボットに伝え、訂正後も同じ条件で扱えるか確かめます。記憶が別々でも、ファイルへのアクセスは別の問題です。公式文書では、アクセスできるファイルや道具は設定した権限とセキュリティポリシーに従います。
朝の報告を読んだ人が動ける形にします
ここからは架空の例です。島田市の小規模事業者が、練習用の予約フォームについて、委託先との引継ぎを試すとします。夜間に自動で動くテストは、予約の空きがなくなったときに申込みを止めることを確認するものです。ボットに依頼する範囲は、用意した架空の試験結果を読むところから、報告案を作るところまでです。
夜間テストを動かす仕組みと、朝にボットが結果を読む作業は別にします。たとえば、試験側は毎日午前2時に結果を残す予定とし、ボットには午前8時半に報告案を作るよう設定する想定です。人が先に、試験番号と予定、結果が記録される場所、委託先に渡してよい項目を決めます。報告案には実行番号と時刻、失敗した試験の名前、実際に観察した結果、元の記録の参照先、次に確認する人を残します。たとえば実行T-18で「満枠で送信操作後に、受付済みと表示」と記録されていれば、その表示を観察結果として引用します。実際に予約が登録されたかは、別の記録がなければ不明です。原因は推測で埋めず、委託先へ登録記録の確認を頼む文章にします。
予定していたT-19の記録がない場合は「結果未確認」とし、失敗扱いにも合格扱いにもしません。人が試験を走らせる側の記録を確認します。別のテストの成功通知を受け取っても、番号が違えば穴は埋まりません。ボットの報告と人が管理する予定表を分けると、報告が届かない場合も確認を始められます。たとえば午前9時までに報告案がなければ、担当者は元の試験記録を直接見ます。試験記録もなければ試験担当へ、試験記録はあるのに報告案がなければボットの運用担当へ確認します。記録が見つかる前に停止理由を決めつけません。
定刻に動く前提と操作できる範囲を確かめます
Kiro Crewではスケジュールで作業を動かせます。設定済みの作業がチャットを閉じていても動けるのは、処理を受け付けるCrewのゲートウェイが稼働している場合です。画面を閉じてよいことと、実行環境を止めてよいことは別です。スケジュールでの実行や、割り振られた作業の実行もクレジットを消費します。クレジットは利用量を数えるための単位です。
公式文書によると、新しく作ったボットの初期モードはTrustです。適用されるセキュリティポリシーの範囲で、操作のたびの承認を求めず進みます。NormalやReadsには承認の設定がありますが、一部の組み込み操作には例外があります。試行では実案件のコードや通知先を接続せず、架空のデータだけを置いた環境を使います。Crewが承認を求める設定と、実行する端末や接続先が実際に読み書きを許す範囲を別々に確認します。試行の報告案は担当者が受け取り、委託先への送信は人が行います。
引継ぎの正確さを測ってから続けるか決めます
テスト失敗、結果なし、正常の三つの架空記録を用意します。正常のT-20は「試験記録上は合格」と書き、サービス全体の動作確認まで済んだと広げないようにします。担当者は正解を手元に置き、ボットの報告を元の記録に戻って確認します。確認したいのは、番号の取り違えがないか、証拠のない原因を断定していないか、未確認の日に人へ確認を回せるかです。記録の照合をやり直す回数や、担当者が引継ぎに掛けた時間も試行中に残せます。三つの事例すべてで記録と報告が対応し、想定外のアクセスや送信がなく、報告が来ないときの代替確認もできた場合に、次の模擬試行へ進みます。番号の混同や根拠のない断定があれば、修正した条件で同じ事例をやり直します。
試す価値があるのは、毎回同じ場所から結果を受け取り、担当者が同じ種類の聞き直しを繰り返している場合です。そもそも実行番号や結果の保管先が決まっていない場合は、委託先との間で試験記録と受取方法を先にそろえます。試せる環境や契約上の条件が分からない場合は、自社のアカウントと運用の条件を確認してから判断します。
島田市で外注先との引継ぎや確認の流れを整えたい方には、LIFESEEDSのAI活用・業務効率化支援で、業務に合わせた試行範囲をご相談いただけます。お問い合わせでは、今使っている報告書の項目や困っている場面をお知らせください。
コメント