Kiro Crew でソフトウェアファクトリーを構築し、1 週間で 1000 件の PR をマージした方法

先週、Kiro Crew をフルタイムで開発している私たち3人は、7日間で 1,000 件の pull request をマージしました。1日あたり 120 件を超え、そのすべてが CI とレビューを通っています。Kiro Crew は、このフルタイムのエンジニア3人を中心に、500 人近い熱心なコミュニティコントリビューターとともに開発されています。

この数字を狙っていたわけではありません。並行して開発を進めるやり方が次々に限界にぶつかり、それを越えるたびに少しずつ到達した結果です。ボトルネックにぶつかるたびに、1人がより多くのセッションを回せる新しい進め方が生まれました。振り返ると、その変化は5つの段階に整理できます。最新の段階が、私たちが Crew Mode と呼んでいるものです。コーディングエージェントを使っているなら、あなたもこの梯子のどこかにいます。そして今いる段階が、次に壊れるものを教えてくれます。

段階 1: 1セッション、手作業。 開発者1人、エージェント1つ、CLI または IDE の中。自分の注意力がシングルスレッドだと気づくまでは、これで足ります。エージェントはすべてのステップの合間にあなたを待つので、あなたがボトルネックです。

段階 2: 複数セッション、手作業。 2つ目のタブを開き、3つ目を開きます。午後いっぱいくらいは助かります。やがて、どのタブでも同じプロジェクトの説明を繰り返し、どのタブが何をしているかを頭の中で管理していることに気づきます。セッションは互いのことを何も知らないので、それらをつなぐのはあなただけです。

段階 3: memory、ダッシュボード、cron、workflow。 Kiro Crew が本格的に始まったのはここです。memory によって、セッションは温まった状態で始まるようになりました。ダッシュボードによって、複数セッションの追跡が容易になりました。cron と monitor ループは、人の手を介さずにセッションを開始し始めました。workflow は、固定のものも動的に生成されるものも、1つのジョブのステップを複数のセッションにまたがってつなぎ、人間が1ステップずつ手でたどらなくてよいようにしました。これで1人が 10〜20 のアクティブなセッションを扱えるようになりましたが、その作業全体を調整するものではありませんでした。workflow のステップは、依然としておおむね順番に実行されます。cron はスケジュールで起きるのであって、別のセッションが終わったときに起きるわけではありません。セッションは別々のタスクやプロジェクトを担当できますが、更新をすべて読んで次に注意を向ける先を選ぶのは、人間のままでした。

段階 4: agent pipeline。 CI のパイプラインではなく、一般的な作業を対象にしたエージェントセッションの組み立てラインです。triage、実装、レビュー、マージがそれぞれ独立したステージとして自分のセッションを持ち、メッセージキューを通してのみ連携します。どのステージも他を待ちません。各ステージは自分のキューに項目が入った瞬間にそれを取り、互いのことを知らないまま、全ステージが同時に動き続けます。対して workflow は、ステップ3がステップ2を待つ鎖です。1人で 20 の同時セッションを超えられたのは、この pipeline のおかげでした。残る課題は、pipeline が人間の設計した固定の形だという点です。結果が計画を無効にしたときに再計画できず、人間が計画を書き直して、影響を受けた作業を振り直す必要があります。

段階 5: セッションをエージェント的に運用する。 ここまでの仕組みで、1人がおよそ 20 の同時セッションを扱えます。50 に近づけると、今度は人間の入力が限界になります。どのセッションにも、ゴールを定義し、起動し、問題を見張り、結果を判断し、次に何をするか決める人が必要です。この5つを 50 セッション分こなすと、それ自体がフルタイムの仕事になります。

Crew Mode は、どの単一セッションの外側にも属さないエージェントで、この手作業を自分でこなします。あらかじめ描かれた形をたどるのではなく、セッションの境界をまたいで結果に反応します。セッションは、Crew Mode が作り、初期情報を与え、見張り、閉じる実行単位になります。人間が持つのはゴールです。先週の数字は、pipeline と Crew Mode の初期バージョンが組み合わさって出たものです。開発は今も続いています。

これはどこで動くのか。プロセスが動く場所ならどこでも動きます。crew は1つの gateway とそれが所有するセッションの集まりであり、どのマシンの上にいるかを気にしません。現在、私たちの crew はラップトップ、EC2 インスタンス、クラウド開発デスクトップ上で動いており、今後は Fargate コンテナでも動く予定です。私自身は6〜10 台のマシンを同時に動かし、すべてを1つのダッシュボードから繋いでいます。合わせて 30〜50 のセッションが同時に稼働し、issue の triage、pull request 用のコード作成、レビュー、マージを進めています。crew が受け渡すエージェントジョブは、GitHub Actions や CodeBuild 上でも動きます。

crew 間の協調については早い段階で議論し、「将来の課題」として整理していました。その必要性を具体的にしたのが Crew Mode です。Crew Mode の調整役エージェントは、アクティブなセッションをすべて巡回してブロックされた作業を見つけ、結果を確認し、計画を更新します。50 セッションを超える規模になると、この調整役エージェント自体が次のボトルネックになります。コンテキストを失うこともあり、必要な専門性を持っていないこともあります。スーパーマネージャー1体では、この問題は解けません。役割、スコープ、協調の仕方が異なる複数のエージェントが必要です。1体が計画し、別の1体が実行し、さらに別の1体がレビューする、という形です。そのうえで crew 同士が結果を交換し、作業を互いにルーティングできるようになります。これを設計できたのは、監督役1体がスケールしなくなるのを見たあとでした。

私たちが本当に重視していること

「エージェントがエージェントを運用する」という言い回しは、まさに誇張を招きやすい類のものです。ですから率直に書きます。私たちのゴールは、現場のエンジニアが信頼できる機能を作ることです。現在の開発の大半は、Crew Mode を安全でガバナンス可能にすることに向いています。新しく派手な解決策を発明しようとしているわけではありません。複数のエージェントが自分のために働き始めると、4つのガバナンス上の問題が中心にきます。

• エージェント間の調整。 誰が何を依頼し、どのタスクを誰が持ち、何を試して却下したか。これがモデルのコンテキストの中にだけあると、次の compaction で消え、何が起きたのかを誰も再構成できません。明示的で永続的でなければなりません。
• memory。 何を覚えてよいか、どのエージェントが、どのプロジェクトについて、誰に見える形で覚えるか。あるエンジニアの訂正が、別のチームのコードベースを扱うセッションを黙って動かしてしまってはいけません。
• 権限制御。 エージェントが何をしてよいか、どのリポジトリで、どの環境に対して、そして何が人間の承認を要するか。プロンプトで丁寧にお願いするのではなく、ホスト側で強制します。
• すべての操作の記録。 コマンド、ファイル変更、承認、拒否のすべてを、エージェントが書き換えられない場所に記録します。信頼は、エージェントが「正しいことをしました」と言うことからは生まれません。履歴を追跡できることから生まれます。

これらは、エージェントが自社を代表してコードを push できるようになったとき、どの会社にも必要になる普通の統制です。エージェントの調整、明確な memory の境界、ホストレベルの権限、そしてエージェントが改変できない監査ログ。セッションを増やすことが効くのは、エンジニアがその作業を理解し、制御し、信頼できるときだけです。

コストは、エージェントの艦隊が数百セッション規模になると、別の問題として立ち上がります。エージェント本体の作業には、すでに値段がついています。調整はその上にもう一層を足します。セッションを温かく保つ、状態を確認する、結果をルーティングする、fan-out を支える、といった処理です。その規模になると、この追加分の請求が採用の障壁になり得ます。私たちは、定常的な監督に安価なモデルを使う、決定的なチェックはスクリプトに任せる、最小コンテキストでの起動、セッション知識の再利用、タスク単位の正確なコスト計上といった方法で、これを下げる道を探っています。

今日から使えること

ここでの学びは、私たちのツールを採用しなくてもすぐ適用できます。今いる段階から始めて、何がもうスケールしていないかを特定してください。次に進む前に、最小で役に立つ改善を1つ入れます。各段階は、次の段階への準備をしながら、それ自体で価値を出します。

• 同時セッション数を数える。 1つなら段階 1、タブが数枚なら段階 2、というように。この数が、次に解くべき問題を教えてくれます。そしてそれは、いちばん面白そうに聞こえる問題ではまずありません。
• 段階 1 から 2 は無料。効くのは段階 2 から 3。 タブを増やす前に、エージェントに memory を与えてください。最も安い形は、すべてのセッションが読むリポジトリ内のファイル1枚で、そこに自分の規約と、繰り返し言っている訂正を書いておくことです。どのツールを使っていても、並行セッションを負担から既定の状態に変えるのは、この1手です。
• 繰り返しの雑務を1つ、スケジュールに渡す。 新しい issue の triage や、不安定なチェックの再実行など、毎日手でやっているジョブを1つ選び、タイマーで始まるセッションに渡します。スケジュール実行されるセッションを1つ動かすほうが、それについてどれだけ読むよりも学べます。
• orchestrator の前に pipeline を作る。 セッションが同じ数種類の作業を繰り返しているなら、ステージに名前を付け、その間にキューを置きます。GitHub issue のラベルは、始めるには十分に良いキューです。ラベル1つにセッション種別1つ、各セッションは自分のラベルが付いたものを拾います。
• 段階 5 から始めない。 5つの務めを書き出し、どれが自分の1日を食べているかを見ます。私たちの場合は、50 を超えるセッション間の巡回でした。最初に自動化すべきはその務めであり、それがどれなのかは、体感できるだけのセッションを動かしてみて初めて分かります。
• ガバナンスは初日から始める。規模が出てからではない。 監査ログと権限制御の2つは、今すぐできます。エージェントがやったことを、エージェントが書き換えられない場所に記録し、何をしてよいかをプロンプトではなくホストレベルで決めます。どちらも2セッションのうちは安く、50 セッションになってからの後付けはほぼ不可能です。

私たちが実際に動かしているバージョンを試したい場合、Kiro Crew は memory、ダッシュボード、cron、workflow、pipeline を今日提供しており、基本的な Crew Mode は feature preview を有効にするとリポジトリで利用できます。いちばん速い始め方は、ラップトップにインストールし、リポジトリ1つに向け、スケジュール実行の雑務を1つ渡すことです。自分が寝ている間も動かしたくなったら、クラウドインスタンスへ移します。

この先どこへ向かうか

今は、人間が crew に具体的なゴールを渡します。この機能を出す、このリポジトリを green にする、といったものです。時間が経つにつれ、そのゴールはより抽象的になり、crew は作業を待つのではなく提案するようになるはずです。ただしそれが起きるのは、ガバナンスとコスト制御の機能が整い、十分にテストされたあとです。企業が制御も監査もできず、費用も負えない機能は、プロダクトではなくデモです。

Kiro Crew はオープンソースです。この記事のすべての背後にあるコード、アーキテクチャドキュメント、機能仕様は、公開リポジトリにあります: https://github.com/kirodotdev/KiroCrew。自分でこのようなソフトウェアファクトリーを作りたい方は、kiro.dev/crew で Crew を試してください。

この記事は Kiro ブログの How we built a software factory with Kiro Crew to merge 1000 PRs in a week を翻訳したものです。