⚡️ 2026年ソフトウェアファクトリー標準 — Zach Lloyd, Warp.dev

WarpのZach Lloyd（CEO）は、AIエージェントがソフトウェア開発を担う「software factory（ソフトウェア工場）」という概念を提唱し、AI Engineer（AIE）カンファレンスでの講演がバイラルヒットした人物である。本エピソードでLloydは、software factoryとは何か、なぜ単なる「エージェントをたくさん使うこと」とは違うのか、そして企業がそれを導入する際に実際に何が必要になるのかを、自社プラットフォーム「Warp Factories」のデモを交えながら詳細に語っている。ホストのswyx（Shawn Wang）が冒頭で「みんなが自分たちのためにこれを構築しようとしている」と述べたように、factoryという言葉は今や業界のバズワードになりつつあるが、Lloydの主張はその曖昧さに明確な定義を与えるものだ。

Lloydの定義によれば、software factoryとは「クラウド上に存在するエージェント的システムであり、チームやプロダクトのためにソフトウェアを構築する各エージェントの役割が定義され、一定の自律性を持ち、測定可能でクローズドループな系」である。重要なのは、それがコードとして宣言的に定義され、バージョン管理され、測定され、改善され続ける「実体」であるという点だ。単にエージェントを多用してソフトウェアを出荷している状態を「うちの工場」と呼ぶ企業が多い中で、Lloydは「それは工場ではない、定義されたワークフローと計測系を持つ具体的なシステムだ」と反論する。本ダイジェストでは、factoryの構成要素、スタック構造、コスト最適化の実例、そして「factory engineering」という新たな職種の可能性までを順に追う。

2:23software factoryとは何か——曖昧な比喩から「測定可能な実体」へ

Lloydがまず強調するのは、software factoryを「漠然とした自動化の寄せ集め」から「具体的で測定可能なもの」へと引き上げる必要性である。企業が相談に来るとき、多くは「エージェントをたくさん使ってソフトウェアを出荷している、これがうちの工場だ」と語るが、Lloydはそれを否定する。工場とは、コードで定義され、実行可能で、パフォーマンスを測定できる具体的な対象であるべきだという。Warp Factoriesの設計では「1プロダクトサーフェスにつき1つのfactory」という原則を採る。モバイルアプリ、サーバーアプリなど、プロダクトの表面ごとに工場が存在し、その工場はリポジトリ群、必要なスキル、MCP（Model Context Protocol、エージェントが外部ツールと接続するための規格）、そしてワークフローを持つ。

ワークフローはYAMLファイルとしてコードで定義される。どのリポジトリを使えるか、どのMCPや統合が接続されているか、といった情報がすべて一箇所に記述される。これはTerraformがインフラを宣言的に定義するのと同じ発想であり、バージョン管理、ブランチ、ロールバックといったソース管理の利点をそのまま得られる。さらにLloydが「極めてクールだ」と繰り返すのは、工場がコードで定義されているがゆえに、コーディングエージェント自身がその定義に対してプルリクエストを出し、工場そのものを改善できるという点である。これは自己改善ループの基盤になる。

利用者には2つのペルソナがいる。1つはプロダクトエンジニアで、既存のツール——Slack、Linear、Jira、GitHub、API、MCP——を通じて工場に作業を投入する。もう1つは工場を構築・運用する側で、主にプラットフォームチームやDevExチーム、あるいはエンジニアリングマネージャーやCTOだ。Lloydは「これは日常のエンジニアが使うツールではない」と明言する。作業アイテムが工場に入ると、事前定義されたワークフローが起動する。トリアージ、スペック作成、実装といった段階を経てコードが生まれる。この「1つのシステムにすべてが集約される」ことが、後述する観測性と測定の前提となる。

Lloydが「閉ループ系」と呼ぶ所以は、すべてのエージェント会話と成果物が中央に蓄積されることにある。デモでは、Warp社内のモバイルアプリ開発において、あるエンジニアがSlackで開始したタスクの全記録——会話ログ、computer useのスクリーンショット、オーケストレーションエージェントの各ステップ——がリアルタイムで閲覧できる様子が示された。現在ほとんどの企業では、エンジニアが各自のターミナルでClaude CodeやCodexを個別に使っており、こうした中央集約は存在しない。Lloydの主張は、この集約こそがエージェント開発を「バイブス」から「計測」へと移行させる鍵だというものである。

8:00観測・測定・チューニング——DORAメトリクスからコストper PRまで

中央集約されたデータは、複数の次元で分析できる。第1にアウトプット。従来のDORAメトリクスに加え、「マージされたPRごとに人間が何回介入したか」という自動化度の指標、スループットが測れる。第2にコスト。Lloydは「企業と話すとコストは非常に重要だ」と述べ、PRあたりのコストをモデル・スキル・自動化・SDLC上の位置ごとにスライスして追跡できることを強調する。第3に、エージェント自体の品質を評価する「scorer（スコアラー）」あるいは「オンラインeval」と呼ぶ仕組みだ。

スコアラーはLLM as a judgeの形式を取る。判定モデルを選び、プロンプトを定義し、サンプリングレートを設定する。Warpは汎用的に有用なスコアラーを標準提供する一方、企業固有の失敗モードに対応するカスタムスコアラーもコードで定義できる。デモで示された例は「冗長なテスト」の検出だった。コーディングエージェントは実装過程で不要なテストを書き、そのままコードベースに残してしまうことが多く、これがコードを肥大化させトークンを浪費する。スコアラーは過去のエージェント会話（runs）を遡って採点し、「チームのどこでエージェントがテストを書きすぎているか」を可視化する。Lloydはこれを「チーム全体を見渡す賢いエージェント群が、コーディングセッションの質を監視している」状態だと説明する。

さらにLloydは「self improvement（自己改善）」のループを披露する。スコアラーが失敗を検出すると、別のエージェント群がその失敗パターンを分析し、工場定義そのものへの変更を提案する。デモの例では、トリアージ工程で「サブエージェントを起動して調査すべきだった」失敗ケースが54件見つかり、改善エージェントが工場定義に対するプルリクエストを作成した。工場がコードで定義されているからこそ、コーディングエージェントが工場自体を修正できるというわけだ。Lloydは次のステップとして、提案された変更を過去のrunsにリプレイして「本当に改善されるか」を検証する機能を構想中だと語る。これが実現すれば、観測・測定・チューニングの完全な学習ループが完成する。

最後に「ベンチマーク」機能が示される。自社の実際のコーディングエージェントrunsから、フロントエンド作業など特定領域のタスクセットをキュレートし、それを異なる設定のマトリクスに対してリプレイする。Lloydはモデルだけでなくハーネス（エージェントの実行基盤）も変えるべきだと主張し、Warp自身のハーネスに加えてClaude Code、Codex、Piなどと比較できるようにしている。デモではコスト対正解率の散布図が示され、GPT-5系のあるモデルは正解率95%だが平均6ドル、GLMのあるモデルは93%で2ドルといった具合に、SWE-benchやTerminal-benchの公開結果と同様の形式でありながら「自社の実runsに基づく」結果が得られる。この情報はモデルルーティングやハーネスルーティングの戦略に直接フィードできる。Lloydの言葉を借りれば、これは「推測の領域から、factory engineeringというエンジニアリングの領域へ」の移行である。

19:23スタックとしてのfactory——宣言的定義・データ層・計算層・改善層・オーケストレーター

Lloydはfactoryを6層のスタックとして整理する。最下層は「宣言的なコードとしての工場定義」で、これはTerraform的だと繰り返す。バージョン管理されたSDLC（AI-DLC、PDLCなど呼び方は何でもよいとLloydは言う）のビューが得られ、ブランチを切ってテストし、変更をリバートできる。そしてコードであるがゆえにエージェントが改善提案を出せる。Lloydはこれを「自己改善するsoftware factoryの土台」と位置づける。

第2層はデータ層で、エージェントが生み出すすべての情報を集約する場所だ。Slackで始まりLinearに続きGitHubのコードレビューコメントへと至る一連の相互作用が、最終的にマージされたコードを生み、ときにサーバークラッシュまで引き起こす。Lloydは、その全経路をエージェント（あるいは人間）が遡って診断できることが重要だと説く。第3層はデータの取り込み口で、MCPの接続機構に加え、組織が大きくなるほど「マーケティングチームがアクセスできるMCPとエンジニアリングチームのそれ」を分けるアクセス制御の複雑さが生じると指摘する。

第4層は計算層で、エージェントのサンドボックス提供者をプラガブルにすべきだとLloydは主張する。WarpはNamespaceを主要プロバイダーとして使うが、Daytona、Modal、E2Bなどに差し替えられる設計だ。デフォルトはLinuxサンドボックスでよいが、iOSアプリのテストのようにcomputer useが必要な場合はMac VMを動かしてシミュレータを操作する必要がある、といった要件の違いも説明される。推論についてもWarpは極めてオープンな姿勢を取る。企業がAnthropic、OpenAI、Googleとの既存コミットメントを使い切りたいという要望に応え、自前の推論プロバイダーを接続することも、Warp経由で推論を購入することもでき、さらにPiなどACP互換のハーネスを自前で持ち込むことさえ可能だという。

第5層が改善層で、前述のスコアラーやベンチマーク、自己改善ループがここに属する。LloydはWarp社内の実例として、factory導入初期はPRあたり約80ドルかかっていたと明かす。高性能なOpusを不要な箇所で使い、トリアージエージェントに過剰なモデルを割り当て、サブエージェントを必要以上に多用していた。内部でのチューニングとテストの結果、コストはPRあたり15〜20ドルまで下がり、直近1ヶ月でPRのスループットは40%向上、リバート率は上昇しなかったという。Lloydはこの「観測し、測定し、チューニングする」アプローチに強い自信を示す。最上層がオーケストレーターで、工場定義を読み込み、作業を各段階へ進め、適切なモデルを呼び、スキルをロードし、自動化を発火させる。Lloydは「オーケストレーターがプラットフォーム全体だと言う人もいるが、それは一部にすぎない」と釘を刺す。

そしてアクセスポイント。Warpの哲学は「工場を企業の既存ナレッジワークツールに持ち込む」ことにある。Warp社内では作業の約60%がSlackから始まるという。ただしタスクトラッカーから始める方が適する場合も、ターミナルのClaude Codeで作業してからスペックを工場に投入する方が適する開発者もいる。だからこそAPI駆動・MCP駆動で、工場自体を「ヘッドレスなインフラ」として多様な入口を持つ存在にする。Lloydはこのスタックを「CI/CDの1つ後ろの層に位置する、開発者インフラスタックの新しい要素」と表現する。

27:02誰のためのものか——規模の閾値と「サブスク回し」の経済学

swyxが「CTOとしてこの6層すべてが必要なのか」と問うと、Lloydは「誰のためのものかによる」と答える。明確なのは、数人規模のチームには不要だという点だ。「Claude CodeのサブスクかCodexのサブスクを使って、ただ速く進めばいい。これはやるな」とLloydは言い切る。導入が意味を持ち始めるのは概ね5〜10エンジニアあたりが下限で、そこから大企業まで広がる。ただし企業規模が大きくなるほど実装作業は増え、純粋なプラグアンドプレイでは済まなくなる。一方、10〜100エンジニアの成長期スタートアップでSlack、Linear、Jiraといった「ハッピースタック」（Lloydの造語）を使っているなら、かなりセルフサーブで即座に価値が出るという。

ここでswyxが持ち出したのが「サブスク回し」の話だ。多くの小規模企業が200個ものサブスクをローテーションしながら使っているといい、swyxは「API従量課金はサブスク群に比べて5〜50倍高くつく」と指摘する。Lloydは「それができるなら最も安い方法だが、他の多くの利点を失い、スケールしない。ある規模を超えれば確実に許されなくなる」と応じる。swyxは「200ドルのプランで8,000ドル分のAPIが使えるのは馬鹿にならない」と付け加え、これがモデル提供者による実質的な補助金であることを示唆した。

この経済学はLloydが「純粋なコーディングエージェント事業には入りたくない」と明言する理由でもある。APIコストがサブスクより桁違いに高い以上、その上に競争力のあるコーディングエージェントを築くのは難しい。LloydはCursorを引き合いに出し、「彼らはそれを成し遂げ、完璧な出口を得てモデルラボになった。経済性を完全に理解していたからだ」と評する。Warp Factoriesはトークンの再販売ではなく「コーディングエージェントの最適化・生産性プラットフォーム」を売るもので、そこが強みだという。swyxが独立系コーディングエージェントとしてCognition、OpenCode、Factoryの名を挙げると、Lloydは「彼らがどうやるのか分からない」と率直に述べた。

適合しない顧客についてもLloydは正直だ。非常に特殊な自社インフラを持つ企業、たとえばUberやRampのように大規模な内部開発者チームを抱え自前で構築する企業は、現時点ではWarpの顧客としては難しいという。これは製品の限界というより、規模と内製志向の組み合わせが外部プラットフォームの居場所を狭めるという構造的な問題である。

33:37factory engineeringという新職種——エンジニアの役割はどう変わるか

LloydがAIE Codeでの講演で扱うテーマは「factory engineeringが進む世界でエンジニアであるとはどういうことか」である。彼はエンジニアリングを2種類に分ける。1つはプロダクトエンジニアリング——工場を通じて機能を出荷する仕事。もう1つはfactory engineering——ソフトウェアを直接作るのではなく、ソフトウェアを作るシステムを設計・運用する仕事だ。Lloydは後者を「新しい専門分野」と位置づけ、そのツールとは何か、エンジニアはどうスキルを磨けば「システムをエンジニアリングする側」に回れるのかを講演で掘り下げるという。

この構図は、本エピソード全体を通底するメッセージと一致する。Lloydが繰り返したのは「バイブスから計測へ」という移行だ。Twitterでは毎日のように新しいモデルやハーネスの優劣が話題になるが、Lloydの主張は「PIかClaude CodeかCursorか」を主観で論じる段階を卒業し、自社の実runsに基づくベンチマークとスコアラーで科学的に判断せよというものである。そのためには工場がコードで定義され、すべての会話と成果物が保存され、観測可能で測定可能でなければならない。Lloydが「すべてが保存され、観測可能で、測定可能な状態に到達すること。そこから初めてエージェント改善にエンジニアリングの厳密さを適用できる」と述べた箇所が、この思想の核心である。

Warpは自社の実践をそのまま製品化している点でも特徴的だ。PRあたり80ドルから15〜20ドルへのコスト削減、スループット40%向上、リバート率横ばいという数字は、自社の工場を自社のツールで測定した結果である。Lloydは「我々はこれを常に使っている」と述べ、顧客に対しても「適切なモデルとスキルで工場をチューニングし、PRあたりコストを時間とともに下げ、コストを人別・自動化別・SDLC上の位置別にスライスできるようにすべきだ」と助言する。これはベンダーの売り込みというより、自分たちが実践している手法の開示に近い。

Lloydはまた、工場がコードで定義されていることの意味を「自己改善の前提条件」として強調した。エージェントが工場定義にプルリクエストを出せるという仕組みは、定義がコードでなければ成立しない。そして将来的には、提案された変更を過去のrunsにリプレイして検証する機能を加えることで、「提案→検証→採用」のループが自動化される。Lloydはこれを「システムに組み込まれた完全な学習ループ」と呼ぶ。エンジニアの仕事は、この学習ループが正しく回るようにプリミティブを設計し、スコアラーを整備し、ベンチマークをキュレートすることになる。ソフトウェアを直接書く時間は減り、ソフトウェアを生み出す系を設計する時間が増える——これがfactory engineeringの実像だ。

結びに

本エピソードが残すのは、「software factory」という言葉に実体を与えるフレームワークである。Lloydの貢献は、漠然とした自動化の寄せ集めを、コードで定義され、バージョン管理され、観測され、測定され、自己改善する6層のスタックとして描き出した点にある。宣言的定義、データ集約、MCPによる取り込み、プラガブルな計算層、スコアラーとベンチマークによる改善層、オーケストレーター、そして多様なアクセスポイント。この整理は、Warpを使うか否かに関わらず、自前で工場を構築しようとする企業にとっての設計図になる。swyxが「ここまでリードすれば、Warpを使わない人までWarpを作ろうとする」と評したのは誇張ではない。

実践面でも具体的だ。PRあたり80ドルから15〜20ドルへのコスト削減、スループット40%向上、リバート率横ばいというWarp社内の数字は、観測・測定・チューニングというアプローチの有効性を示す証拠として重い。一方でLloydは、5〜10エンジニア未満には不要だと明言し、UberやRampのような内製志向の大企業には向かないと認める。サブスク回しの経済学についても、それが最も安い方法でありつつスケールしないという現実を率直に語った。ベンダーCEOの話として聞くべき部分はあるが、自社実践の開示と不適合顧客の明示は、この種のインタビューとしては異例に誠実である。

そして最も重要なのは、これが単なるツールの話ではなく職種の話になっている点だ。プロダクトエンジニアリングとfactory engineeringの分離、そして「ソフトウェアを作るシステムをエンジニアリングする」という新たな専門性の提示は、AI時代のエンジニアのキャリアを考える上での示唆に富む。モデルやハーネスの優劣をバイブスで論じる段階から、自社の実データで測定する段階へ。その移行を支えるインフラと方法論を、Lloydは具体的なデモと数字で示してみせた。

要点

• Lloydの定義するsoftware factoryは「クラウド上のエージェント的システムで、役割が定義され、一定の自律性を持ち、測定可能でクローズドループな系」であり、単なるエージェントの多用とは明確に区別される。
• 工場はYAMLで宣言的に定義され、Terraformのようにバージョン管理・ブランチ・リバートが可能。コードであるがゆえにエージェント自身が工場定義にプルリクエストを出して自己改善できる。
• Warp社内ではPRあたりコストを約80ドルから15〜20ドルへ削減し、直近1ヶ月でPRスループット40%向上、リバート率は上昇しなかった。
• スコアラー（LLM as a judgeによるオンラインeval）で「冗長なテスト」などの失敗モードを遡って採点し、改善エージェントが工場定義の修正を提案するループが動作している。
• ベンチマークは自社の実runsをモデル×ハーネスのマトリクスにリプレイするもので、GPT-5系が正解率95%・平均6ドル、GLM系が93%・2ドルといった自社固有のコスト対正解率データからモデルルーティングを設計できる。
• 導入が意味を持つのは概ね5〜10エンジニア以上。それ未満はClaude CodeやCodexのサブスクを使う方が速く、UberやRampのような内製志向の大企業には向かない。
• API従量課金はサブスク群より5〜50倍高くつくため、Lloydは純粋なコーディングエージェント事業から距離を置き、Warp Factoriesを「最適化・生産性プラットフォーム」として位置づけている。
• Lloydはプロダクトエンジニアリングとfactory engineeringを分離し、後者を「ソフトウェアを作るシステムをエンジニアリングする」新職種として提示。AIE Codeの講演でそのスキルとツールを掘り下げる。