AIエージェント100体並列実行！生産性を最大化するソフトウェア開発戦略

はじめに：AIエージェント活用の最前線と直面する課題

AIエージェントの活用が急速に進む現代において、多くの企業がその可能性を最大限に引き出そうと試みています。特に、SuperagentのようなAIエージェントIDEを開発する企業では、最先端のAI/ML企業と密接に連携し、彼らがどのように技術の限界を押し広げているかを目の当たりにしています。そこから見えてくるのは、「より多くのトークン（処理能力）が、より多くの利益につながる」という共通認識です。つまり、トークンの消費を最大限に活用すること（トークンマキシング）が、大きな成果を得るための鍵であるとされています。

しかし、ここで一つの疑問が浮上します。「どこにトークンを費やすべきか？」多くのチームがコーディングに大量のトークンを投入しているものの、期待するほどの増分価値が得られていないのが現状です。これは、投資に対するリターンが徐々に減少していく状況と言えるでしょう。このような課題に対し、私たちはソフトウェア開発プロセスを根本から見直し、生産性を最大化するためのアプローチを模索しました。

この問題に取り組むため、私たちは自身の二つの大きな関心事である「コーディング」と「サプライチェーン・製造業」を結びつけました。特に、トヨタのリーン生産方式、そしてその思想を平易に解説した名著『ザ・ゴール』から着想を得ています。本記事では、『ザ・ゴール』の考え方をソフトウェア開発プロセスに応用し、いかにしてAIエージェントを効率的に活用し、100体ものエージェントを並列実行しながらも健全な開発サイクルを維持するかについて、具体的な戦略をご紹介します。

ソフトウェア開発プロセスを「製造ライン」として捉える

『ザ・ゴール』では、いかなるプロセスにおいても、その目標を明確にし、スループット（単位時間あたりの生産量）、在庫、そしてボトルネックを特定することが重要だと説かれています。私たちはこの考え方をソフトウェア開発に適用し、開発プロセス全体を製造ラインとして捉え直しました。エンジニアとして個々のタスクに集中するのではなく、ラインマネージャーの視点からソフトウェア開発サイクル全体を見渡すことで、ボトルネックを発見し、改善点を見出すことができます。

一般的なソフトウェア開発プロセスは、以下のステップで構成されます。

トリガー（Trigger）: 顧客からのフィードバック、システム障害、新たな要件など、コードベースに変更が必要となるきっかけとなるイベントです。
計画（Plan）: コード変更が行われる前に、どのような変更が必要か、どのように実装するかなどを検討するステップです。これは必ずしも明示的なステップとして認識されないこともありますが、一般的には何らかの計画が伴います。
コーディング（Coding）: 実際のコードを書く作業です。多くのチームがここに大量のトークンを投入していると見られます。
レビュー（Review）: 作成されたコード（プルリクエストなど）が、品質基準や要件を満たしているかを確認するステップです。
マージ（Merge）: レビューが承認されたコードをメインブランチに統合するステップです。

これらのステップのうち、現状では「コーディング」の多くはエージェントによって駆動される傾向がありますが、それ以外の「計画」「レビュー」「マージ」の各ステップは、人間による高い介入が必要となる「人間主導」の側面が強いと私たちは認識しています。

『ザ・ゴール』の教訓：目標、スループット、ボトルネック

『ザ・ゴール』の中心的な教訓は、「プロセスの目標とは何か」を定義することです。ソフトウェア開発における私たちの「目標」は、最終的に顧客価値につながるものですが、測定可能な「スループット」として「マージされたプルリクエスト（PR）」を設定できます。そして、この製造ライン全体のスループットは、各ステップのスループットの中で最も低いもの、つまり「ボトルネック」によって決定されます。

私たちの内部プロセスを分析した結果、以下のような傾向が見られました。

トリガー: 多くのトリガー（問題提起）が発生し、たくさんのPRが作成される可能性があります。
計画: 人間主導の部分が多く、スループットはやや低めです。
コーディング: PRが大量に生成される、まさに「爆発的な」状態です。私たちのGitHubリポジトリには、常に400件ものオープンなPRが存在することもあります。
レビュー: 人間が一つ一つ確認する必要があるため、この段階でスループットが劇的に低下します。これは典型的なボトルネックです。

この場合、全体の生産性を決定しているのは、明らかに「レビュー」のステップであり、これが現在のボトルネックとなっています。ボトルネックが特定できれば、その部分の容量を増やすことで、プロセス全体のスループットを向上させ、一貫性のある意味のある成果を出すことが可能になります。以下では、各ステップのボトルネックを解消し、容量を増やすための具体的な戦略を見ていきましょう。

各ステップにおけるボトルネック解消戦略

1. トリガー（Trigger）の最適化

トリガーの段階では、AIエージェントの活用によってPRの生成を自動化し、初期段階でのプロセスを加速させることが可能です。具体的なアプローチとしては、以下の例が挙げられます。

SentryやGitHubからの自動PR作成: エラー監視ツール（Sentry）やバージョン管理システム（GitHub）からのイベントをトリガーに、エージェントが自動的にPRを作成するように設定します。例えば、新しいバグ報告があった際に、エージェントが関連する単体テストを作成し、意図的にそれを失敗させます。その後、その単体テストをパスするようなPRを自動生成し、オープンする、といった一連のワークフローです。
Cronジョブの活用: 定期的なチェックやメンテナンス作業として、エージェントがCronジョブとして実行され、必要に応じてPRを生成することもできます。

これにより、多くのPRが迅速に生成され、開発サイクルの初期段階が効率化されます。

2. 計画（Plan）の強化

計画ステップは人間主導の側面が強いですが、エージェントがより良い計画を立てるための支援をすることで、その品質と効率を向上させることができます。重要なのは、エージェントに高品質なコンテキストとドキュメントを提供することです。

高品質なドキュメントとコンテキスト: エージェントがコードベースやビジネスロジックを正確に理解できるように、最新かつ詳細なドキュメントを用意することが不可欠です。これにより、エージェントは人間の意図に沿った、より質の高い計画を立案できるようになります。
Observational Memoryの活用: エージェントが過去の成功例や失敗例、環境の状態を記憶し、学習する「Observational Memory」のような技術も、計画プロセスの強化に非常に有効です。
コードベースの文書化: 人間が作成した設計やコーディング規約（MDファイルなど）をエージェントが参照できるように適切に文書化し、エージェントがそれに従ってコードを生成するように誘導します。これにより、人間のデザイン意図がエージェントによる実装に反映されやすくなります。

3. コーディング（Coding）の並列化

コーディングフェーズは、既に多くのエージェントやツールが利用されており、その並列化については頻繁に議論されています。ここでは、その能力をさらに引き出すためのいくつかの戦略を紹介します。

Worktreesやブランチ戦略の活用: GitのWorktrees機能や、データベースのブランチ、仮想マシン（VM）などを活用することで、複数のエージェントや開発者が同時に異なるコードベースや環境で作業できるようになります。これにより、並列でのコーディング作業が容易になります。
専用コーディングツールの活用: 私たちが提供するSuperagentのようなコーディング支援ツールは、この問題を解決するために設計されており、効率的なコード生成と管理をサポートします。

このフェーズでは、既に多くの並列処理能力が存在するため、それを最大限に引き出すための環境整備が重要です。

4. レビュー（Review）の効率化とエージェント支援

レビューは現在の多くのプロセスでボトルネックとなりがちなステップです。ここでの目標は、人間のレビューアの負担を軽減しつつ、品質を維持・向上させることです。

質の高い単体テストの維持: ビジネスロジックの形状をカプセル化するような、適切に保守された単体テストは非常に重要です。モックされたものではなく、実際のコードベースの動作を検証するテストを「実際のコード」として扱うべきです。これにより、エージェントが生成したコードの品質を人間が確認する際の強力な検証手段となります。
エージェントによるレビューラウンド: Code Rabbitのようなレビューツールを活用し、エージェントに初期的なレビューを行わせます。これは、人間が確認する前に、潜在的な問題や改善点を特定するのに役立ちます。私たちはすべてのPRでCode Rabbitをトリガーするよう設定しています。
自己駆動型バリデーション: エージェントが製品を駆動し、視覚的に検証したり、ログを分析したりして、コード変更の妥当性を確認する仕組みです。これにより、人間が介入する前に多くの検証フェーズを自動化できます。
並列実行可能なコードベースの構造化: コードベースをモジュール化し、並列でテストや検証を実行できるように構造化することで、レビュープロセスのボトルネックを緩和できます。

5. マージ（Merge）プロセスの工夫

マージのステップは、最終的なコードの統合であり、ほとんどが人間主導で行われるべきだと考えられています。すべてのPRを自動的にマージすることは推奨されませんが、特定の環境でエージェントを賢く活用することで、効率を高めることができます。

Canary/Staging環境での自動マージ: 社内では、Canary環境やStaging環境では、ほぼすべての変更を自動的にマージしたり、よりリスクを許容してマージしたりすることがあります。そこで、エージェントがCronジョブなどとしてスモークテストを実行し、問題がないことを確認します。
検証済みブランチへの統合: Canary環境でエージェントによって十分に検証されたコードのみを、クリーンなメインブランチにプルすることで、メインラインの安定性を保ちつつ、開発速度を向上させることが可能です。

まとめ：一貫したスループットと大規模並列実行へ

本記事で強調したいのは、「プロセスの目標を明確にすること」の重要性です。製造ラインとしてのソフトウェア開発プロセスを理解し、ボトルネックを特定し、各ステップでエージェントと人間が協力することで、一貫したスループットを実現できます。そして、一つのノード（ステップ）でスループットが増加すれば、他のすべてのノードもそれに応じてスケールアップし、最終的に100体ものAIエージェントを健全に並列実行できる体制が整います。

Q&A: エージェントと人間のレビューの役割について

Q: レビューはエージェントが行うべきでしょうか、それとも人間が行うべきでしょうか？ A: 私たちは「エージェント駆動のレビュー」という表現を用いています。エージェントによるレビューを盲目的に信頼すべきではありません。エージェントは間違いを犯すことが多々あるため、エージェントからのフィードバックを人間が検証することが重要です。重要なのは、人間主導の意図や設計（計画フェーズでのアーキテクチャ設計など）に基づいて、エージェントがそれを検証できるようにすることです。私たちは、計画やアーキテクチャ設計に多くの時間を費やすことで、エージェントがより適切なレビューを行えるようになると考えています。

このアプローチにより、AIエージェントの力を最大限に引き出し、かつ人間の知見と判断力を効果的に組み合わせることで、ソフトウェア開発の生産性を飛躍的に向上させることが可能になります。ぜひ、『ザ・ゴール』を読んで、ご自身の開発プロセスにおけるボトルネックと目標を再定義してみてください。

参考動画

How to run 100 agents in parallel & keep your sanity by Kid from Superagent

ポイント