ソフトウェアファクトリー導入ガイド：クロール・ウォーク・ラン

ソフトウェアファクトリーアプローチ

ソフトウェアファクトリーアプローチ（クラウド上で動作する閉ループのエージェント型ワークフロー）は人気が高まっていますが、導入にはハードルが高いと感じる方も多いでしょう。本記事では、ローカルでの対話型エージェントから、自動化されたクラウド開発への移行を「クロール（這う）、ウォーク（歩く）、ラン（走る）」のステップで解説します。

クロール

私が話す多くのエンジニアリングリーダーやプラットフォームエンジニアは、すでにクラウドエージェントを使ったシンプルな自動化を通じて、ソフトウェアファクトリー構築の「クロール」段階に入っています。

これらの自動化は、「トリガー → エージェント活動」と捉えると分かりやすいです。

例えば：

Issue の再現とトリアージ：新規に作成されたすべての Issue をエージェントが確認し、再現手順を実行してラベル付けを行う
コードレビュー：PR が作成されると自動的にレビューを行い、コメントを残す
モニタリング：Sentry アラートに応答し、問題のデバッグと修正を行うエージェントを用意する
CI の自己修復：ロールバックすべき PR や解決すべきマージコンフリクトを特定して、破綻した CI を修復する
ドキュメントの自動更新：ユーザー向けドキュメントを更新し、変更履歴（changelog）を生成する
検証：browser-use および computer-use エージェントが視覚的に QA を実施し、変更を検証する
シンプルなバグ修正：エージェントがユーザー報告の単純な問題を特定し、修正する

これらすべてのアプローチに共通するのは、ソフトウェアライフサイクルの特定の部分を自動化している点です。シンプルな自動化から始めるのはリスクもコストも低く、より複雑なマルチステージタスクにおいてエージェントを効果的に活用するための直感を養うのに役立ちます。

アラートモニタリング用のサンプル自動化

これらの自動化は、自社独自のインフラ（例：Claude Code SDK を Docker コンテナに入れ、トリガー用にサーバーを接続する）を使って構築されることもあれば、トリガーに基づいてエージェントを実行するように設計された汎用クラウドエージェント自動化プラットフォームを利用することもあります。また、サイクルの特定のステージ専用に特化したプラットフォーム（例：専用エージェント型コードレビュアーや AI SRE）を使用する場合もあります。

ポイントソリューションをパッチワークのように組み合わせることから始めるのは問題ありませんが、ほとんどのチームはやがてこのアプローチの限界に直面します。

具体的には：

設定方法によっては、これらの自動化間でコンテキストが共有されない場合があります。つまり、ある側面（例えばコードレビュー）を改善しても、トリアージや QA など他のステージには波及しません。
これらの個別の自動化が全体の生産性を実際に向上させているかどうかを把握するグローバルビューがなく、PR あたりのコスト、サイクルタイム、自動化率などの重要指標を体系的にテスト・改善する方法もありません。これらをトラッキングするには、開発ステージ全体を横断して機能するシステムが必要です。
ポイントソリューションごとに独自のセットアップとメンテナンスの負担が発生します。管理すべきセキュリティ表面積も大きくなります。可観測性（observability）のための統一インターフェースもありません。チームは最終的に、中央集約型の設定、監査、ガバナンスを望むようになります。

ウォーク

これらの課題はすべて、より包括的なアプローチが必要であることを示唆しています。「クロール」段階を経験した組織は、「エージェント型開発を真にスケールさせるために必要なシステムとは何か？」と自問します。

より具体的には、以下のような問いを立てます：

開発はどこで行うべきか？ローカルか、クラウドか？どのようなインターフェース経由か？
成功した自動化された開発プロセスとはどのようなものか？主要な指標は何か？
AI 主権（AI sovereignty）に関する姿勢はどうするか？コーディングエージェントのデータを自社で所有することはどれほど重要か？モデルプロバイダーへの依存度はどの程度まで許容できるか？
開発プロセスを時間とともにどのように改善していく計画か？スピードを上げつつコストを制御するにはどうすればよいか？改善が進んでいることをどのように確認するか？
モデルやエージェントが進化していく中で、将来を見据えた対応はどう行うか？モデルアクセスに影響を与える可能性のある規制リスクを考慮に入れているか？
エンジニアは開発プロセスに具体的にどのように参加すべきか？デザイナー、PM、その他のビルダーについても同様である。
開発をどのように保護するか？ソフトウェア生産プロセスが侵害された場合の計画はあるか？

これらの問いについて深く考えたエンジニアリングリーダーやプラットフォームチームの多くは、クラウドソフトウェアファクトリーアプローチに類似した結論に至ります。彼らが求めるのは以下の通りです：

デフォルトでのクラウドでの開発。エージェントをサンドボックス内で実行する方が、ローカルで自由に動かすよりも安全だから
コーディングエージェントおよびそれらがアクセスするツールやシステムの中央集約型ガバナンス
監査や生産性理解のために、エージェントが何をしたかの完全なトレース
リスク最小化とパフォーマンス最適化のための、モデルおよびハーネスのオプション選択
チームが既に使用しているすべてのツールとの開発統合（例：Slack/Teams、Jira、Github など）
人間が介入するためのエスケープハッチ。ライブエージェントのステアリングまたは作業を内側の開発ループに持ち込むことで可能になる
開発の全フェーズにおいてエージェント間で機能する共有コンテキストレイヤー
テスト、評価（evals）およびベンチマークを可能にするアプローチ。これにより、チームはシステムが時間とともに改善されていることに確信を持てる

企業がファクトリーアプローチを採用すると決めた後、次の課題は「既存のポイント自動化からそこへどう到達するか」です。これは通常、(1) その自動化の周りにさらにインフラを整備するか、(2) ファクトリーインフラを提供する Warp Factories のようなプラットフォームに移行するかに帰結します。

これは従来の「自作 vs 購入（build vs. buy）」の意思決定として位置付けるべきではありません。どちらの道を選んでも、社内チームがある程度の構築作業を行う必要があると想定してください。なぜなら、ファクトリーアプローチを機能させるためには、そのファクトリーがチームのコンテキストやワークフローに深く統合されていなければならないからです。より正確には、自動化インフラを完全にゼロから構築するのか、それとも先行投資を提供してくれるパートナーと組むのかという違いです。

例えば、どちらの道を選んでも、組織固有のスキルを構築し、コードベースに合わせてチューニングする必要が生じると想定してください。組織固有の MCP や内部コンテキストソースを公開し、設定することも必要でしょう。しかし、エージェントの実行・管理、ステアリング、作業の引き継ぎ、有効性の測定、コンピュータ操作などを行うためのクラウドインフラ自体を構築したくないと思うかもしれません。経験則としては、あらゆる組織に必要な部分ではなく、あなたの組織に特化した部分の構築に焦点を当てることです。

どのアプローチを選択した場合でも、ウォーク フェーズにおける最大のマイルストーンは、シンプル な製品サーフェスに対してエンドツーエンドで最初のファクトリーをデプロイすることです。これはマーケティングサイトや社内アプリでも構いません。

シンプルなプロジェクトから始める利点は、リスクが低く複雑さも最小限のまま、ループ全体を回せることです。リポジトリ数、コード行数、サービス依存関係、人間のステークホルダーなどを増やすと複雑さが増し、自動化の準備ができていないように感じられることがあります。まずはシンプルなループを確実に回せる状態に持っていく方が賢明です。

目標は、トリアージ → スペック作成 → 実装 → レビュー → 検証 → モニタリングという流れを実現するマルチエージェントシステムです。詳細は以下の通りです：

人間またはモニタリングエージェントによって新しい Issue がシステムに入る
トリアージエージェントが実行され、Issue の理解と再現を試みる。タスクが自動化可能だと判断したら → 実装エージェントに引き渡す。スコープの関係でスペックが必要なら → スペックエージェントが人間と反復してスペックを作成する。曖昧な場合は → 人間の入力を得て再実行するか、とりあえず Issue を保留にする
[必要に応じて] スペックエージェントが実行され、人間がスペックを確認し、その後実装エージェントに引き渡す
実装エージェントがコードを書く
コードレビューエージェントがコードをレビューする
検証エージェントが computer-use やその他の検証を行う
人間がコードと検証結果を確認する。必要に応じて、ステップ 2、3、4 または 5 に戻る
CI / CD
リリース（Ship it）
モニタリングエージェントが実行され、必要に応じて Issue を作成することでループを完了する

Warp 社内の ウォーク ファクトリーは、マーケティングサイトである warp.dev への変更のうち約 75% を自動化しています。Warp Terminal（GitHub スター 65k、アクティブ開発者約 100 万人、ネイティブ Rust で 100 万行）とは異なり、マーケティングサイトは比較的シンプルなアプリです。「自動化」とは、人間による変更内容の説明（Slack やタスクトラッカー経由）を除き、人間の介入を最小限に抑えつつ、ファクトリーを通じて人間のインプットからリリースまでを完結させることを指します。

ラン

シンプルなプロジェクトで基本的なループが確立できた後にのみ、より複雑なプロジェクトへとスケールアップすべきです。ファクトリーのスケールには、より堅牢なインフラが必要になります。

具体的には、スケールに伴い以下のボトルネックが発生します：

大規模プロジェクトでリモート開発環境を機能させるのは難しい。リポジトリ数、コード行数、サービス依存関係の増加はすべて自動化を困難にする
スキルやコードなどが増えるにつれ、ファクトリーへの変更が開発にとってプラスになっているのか、それとも単なる混乱（churn）を生んでいるだけなのかを判断するのが難しくなる
より複雑なコードベースでエージェントが作業するため、より強力なモデルが必要になり、エージェントの実行時間も長くなるため、コストリスクが高まる傾向にある。モデルルーティングやハーネスの選択がより重要になる
重要なユーザー向けアプリにファクトリーアプローチを導入するほど、セキュリティと監査の重要性が増す
アプリのステークホルダーが増えると、人間の調整と承認プロセスも増える。マルチプレイヤー入力と監査証跡を許容するファクトリーソリューションが必要になる
inevitably PR が積み上がり始めるため、何がコードレビューの対象となるか、エージェント型検証と QA をどのように活用するかについての明確な戦略が必要になる
本番環境に出荷される変更が高品質であり、クラッシュしていないことなどを保証するために、ループを閉じるためのより堅牢なツールが必要になる

スケールしたファクトリーを機能させることは、私の見解では、今後数年間で最も興味深いソフトウェアエンジニアリングの課題の一つになるでしょう。ソフトウェアエンジニアリングはファクトリーエンジニアリングへと変化しつつあります。ファクトリーを堅牢かつ信頼性が高く、自己改善的なものにできる組織は、より低いコストでより多くの成果物をリリースでき、競争優位性を獲得できます。

ファクトリーを本当にスムーズに稼働させるには、相当な投資が必要です。Warp では、これをファクトリースタックの完全な構築と捉えています：

各レイヤーの詳細については、こちらの記事で解説しています：

https://x.com/zachlloydtweets/status/2097739116720910619

必ずしも明白ではないが、特に注目すべき重要なポイントをいくつか挙げます：

Factories-as-code：重要な選択肢の一つは、ファクトリーをコードとして定義することです。これにより、異なるファクトリー構成をテストし、どれが最も効率的で高品質かを検証できます。
マルチモデル & マルチハーネス：ファクトリーが最新のモデル（フロンティアモデルとオープンウェイトモデルの両方）を使用でき、Claude Code や Codex などの異なるコーディングエージェントハーネスを利用できるようにしておくべきです。
データ所有権：ファクトリーから出力されるすべてのデータを保存し、自社で所有することを確保すべきです。これはファクトリーの運用を改善するための生材料となります。

完全に稼働しているファクトリーの特徴は、それが閉ループであり、計測可能で改善可能なシステムであることです。これが目標であるべきです。そのようなシステムでは、全員が同じコンテキストに基づき、公開された状態で、完全に監査・監視された形で作業を行います。エージェント自体がシステムを駆動するスキルや設定を観察し、改善案を提案します。プラットフォームエンジニアは、システムを拡張してすべての内部システムと統合することができます。エンジニアリングリーダーは生産性指標を確認し、改善のためにどのような変更が行われているかを理解できます。全体が「フィーリング」ではなく、実証的に運用されています。

Warp では、このビジョンに一歩ずつ近づいています。毎日、私たちは公開された環境で作業し、ファクトリーをチューニングし、コストを下げてスループットと品質を向上させています。