9月19日、Kiro.devが「How we built a software factory with Kiro Crew to merge 1000 PRs in a week」と題した記事を公開した。この記事では、3人のエンジニアチームがAIエージェント基盤「Kiro Crew」を活用して1週間で1,000件のPRをマージした過程と、その背後にある5段階の開発手法について詳しく紹介されている。

3人で1週間、1,000件のPR

3人のフルタイムエンジニアが7日間で1,000件のPR（1日あたり120件超）をマージした。全件がCIとレビューを通過している。この数字はあらかじめ目標として設定したものではなく、並列処理の限界に何度もぶつかりながら改善を重ねた結果として到達したものだ。

その変遷を振り返ると、5つのステージとして整理できるという。

5段階で見る「AIエージェントの並列化」

Stage 1：1セッション、手動。 開発者1人、エージェント1つ。エージェントは毎ステップで人間の入力を待つため、人間がボトルネックになる。

Stage 2：複数タブ、手動。 タブを2枚、3枚と増やす。しばらくは有効だが、プロジェクトの文脈を毎回説明し直す手間と、「どのタブが何をしているか」を頭で管理するコストが積み上がる。

Stage 3：メモリ・ダッシュボード・cron・ワークフロー。 Kiro Crewが提供する機能群を組み合わせるフェーズだ。セッションが「暖かい状態」（文脈を持った状態）で起動できるよう、メモリ機能を導入。ダッシュボードで複数セッションを一覧管理し、cronで人間を介さずセッションを開始する。ワークフローが複数セッションにまたがる工程を連鎖させることで、1人で10〜20のアクティブセッションを管理できるようになった。

Stage 4：エージェントパイプライン。 トリアージ・実装・レビュー・マージの各工程を独立したステージとして切り分け、メッセージキューで連結する。工場の組み立てラインに近い構造で、各ステージは互いを知らずとも同時に稼働できる。これで1人あたり20以上の並列セッションが実現した。ただし、パイプラインの形は人間が設計した固定構造であり、途中の結果が計画を覆した場合は人間が介入して再設計する必要がある。

Stage 5：Crew Mode。 50セッションを超えると、「目標設定・起動・監視・結果判定・次工程の決定」という5つの管理作業が毎セッションに発生し、それだけで一日が埋まる。Crew Modeはこれらの管理作業自体をエージェントに委譲する仕組みだ。

Crew Modeの核心：「管理のエージェント化」

Crew Modeは個々のセッションの外側に存在し、セッションを作成・監視・終了させながら結果に応じて計画を更新するエージェントだ。人間はゴールだけを渡す。

現在のKiro Crewは、EC2インスタンス、クラウド開発デスクトップ、ラップトップなど複数のマシン上で動作し、単一のダッシュボードからまとめて管理できる。記事の著者自身は6〜10台のマシンを同時に稼働させ、30〜50セッションを常時アクティブに保っているという。エージェントが引き受けたジョブはGitHub ActionsやCodeBuild上でも実行される。

今後はCrew同士が役割を分担して協調する仕組みも検討中だ。「計画担当・実行担当・レビュー担当」のようにエージェントが役割を持ち、Crew間でタスクをやり取りする設計で、1つのスーパーバイザーが50以上のセッションを管理するスケールの壁を突破することを目指している。

ガバナンスとコストという現実問題

複数エージェントが並列で動く環境では、ハイプになりがちな「エージェントがエージェントを操作する」という概念の裏側に、解決すべき4つのガバナンス課題がある。

• エージェント間の調整記録： 何を依頼したか、どのタスクを誰が持つか、何が試みられて棄却されたか。これがモデルのコンテキスト内だけに存在すると、コンテキスト圧縮のタイミングで消える。永続化が必須だ。
• メモリの境界： あるエンジニアの修正が、別チームのリポジトリを操作するセッションに無言で影響してはならない。
• パーミッション制御： エージェントがどのリポジトリ・環境に対して何をできるかは、プロンプトで「お願い」するのではなく、ホスト側で強制する。
• 改ざんできない操作ログ： すべてのコマンド・ファイル変更・承認・拒否を、エージェントが編集できない場所に記録する。

コストも無視できない。セッション数が数百規模になると、セッションの暖機維持・ステータス確認・結果ルーティングといった調整レイヤーのコストが追加で発生する。これへの対策として、定型的な監視には安価なモデルを使う、決定論的チェックはスクリプトで代替する、などの手法を検討中だと述べている。

今日から使えるアドバイス

記事では、ツールに関わらず即日適用できる実践的な指針も挙げている。

• まず並列セッション数を数える。 タブが1枚ならStage 1、数枚ならStage 2。数字が「次に何が壊れるか」を教えてくれる。
• Stage 2→3の移行が最も費用対効果が高い。 タブを増やす前に、まずエージェントにメモリを与える。最安の実装は「リポジトリ内の1ファイル」で、規約や繰り返しの修正内容を書いておくだけでいい。
• 定期的なchoreを1つスケジュール実行に渡す。 フレーキーなテストの再実行や新規イシューのトリアージを、タイマー起動のセッションに任せてみる。
• オーケストレーターより先にパイプラインを作る。 GitHubイシューのラベルを「キュー」として使い、ラベルごとにセッションタイプを割り当てるだけで十分な出発点になる。
• ガバナンスはDay 1から始める。 セッションが2つしかない段階でも、操作ログとパーミッション制御だけは入れておく。50セッションになってから後付けするのはほぼ不可能だ。

Kiro Crewはオープンソースで公開されており、コードとアーキテクチャドキュメントはGitHubで参照できる。Crew Modeの基本機能はフィーチャープレビューを有効にすることで試用可能だ。

詳細はHow we built a software factory with Kiro Crew to merge 1000 PRs in a weekを参照していただきたい。