# 2026年のソフトウェアファクトリー標準 — Zach Lloyd（Warp.dev）

- 番組: [Latent Space: The AI Engineer Podcast](https://ai-curator.jp/podcasts/shows/cmv3z5bz700015o10zwiyz4qc)（Latent.Space）
- 元のタイトル: ⚡️ The 2026 Software Factory Standard — Zach Lloyd, Warp.dev
- 配信日: 2026年11月4日
- 長さ: 34分
- 要約作成日: 2026年11月4日
- トピック: [#ソフトウェアファクトリー](https://ai-curator.jp/topics/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%95%E3%82%A1%E3%82%AF%E3%83%88%E3%83%AA%E3%83%BC) [#コーディングエージェント](https://ai-curator.jp/topics/%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#LLM-as-a-judge](https://ai-curator.jp/topics/LLM-as-a-judge) [#ベンチマーク](https://ai-curator.jp/topics/%E3%83%99%E3%83%B3%E3%83%81%E3%83%9E%E3%83%BC%E3%82%AF) [#Infrastructure as Code](https://ai-curator.jp/topics/Infrastructure%20as%20Code) [#MCP](https://ai-curator.jp/topics/MCP)
- URL: https://ai-curator.jp/podcasts/cmw1b3r3400015p10kq310n3v

## 要約

Warp の創業者 Zach Lloyd が、クラウド上でエージェントを動かす「ソフトウェアファクトリー」の定義と構成要素を解説した回。ファクトリーをコードで宣言し、エージェントの会話を集約して計測・評価・ベンチマークし、自己改善ループを回す考え方を紹介する。Warp 社内ではPRあたりのコストが約80ドルから15〜20ドルに下がったと述べている。対象は5〜10人規模以上のチームで、小規模ならサブスク利用で十分とも語った。

## ポイント

- ソフトウェアファクトリーとは、クラウド上でエージェントの役割とワークフローをコードで定義し、一定の自律性を持たせた、計測可能なクローズドループのシステムだと定義している。
- プロダクトの面ごとに1つのファクトリーを持ち、YAMLでリポジトリ、スキル、MCP、連携先を宣言する。Slack、Linear、Jira、GitHub、API/MCP から作業を投入できる。
- 全エージェントの会話と成果物を集約すると、DORA指標、自動化度、スループット、コスト、LLM-as-a-judge による「スコアラー」で品質を測れる。
- ベンチマーク機能で、過去の実行を異なるモデルやハーネス（Claude Code、Codex、Pi など）で再生し、コストと正答率のトレードオフを自社データで比較できる。
- Warp 社内では当初PRあたり約80ドルだったコストが15〜20ドルに下がり、PRスループットは1か月で40%向上、リバート率は上がっていないという。
- 対象は5〜10人以上のチームで、数人規模ならサブスク利用のほうが速く経済的だと述べている。API従量課金はサブスクの5〜50倍高いという見方も示した。

## 章立て

- [01:02] **ソフトウェアファクトリーの定義** — Zach はファクトリーを、エージェントの役割を定義した自律的でクローズドループなクラウドシステムと説明する。曖昧な自動化の寄せ集めではなく具体的なものだと強調する。
- [04:04] **コードで定義するワークフローと投入口** — YAMLでリポジトリやMCPを宣言し、Slack、Linear、GitHubなど既存ツールから作業を投入する仕組みを紹介する。
- [07:15] **トレース集約と指標・スコアラー** — 全エージェントの会話を集約し、DORA指標、コスト、LLM-as-a-judge による評価で改善点を見つける方法を示す。
- [14:32] **自己改善ループとベンチマーク** — エージェントがファクトリー定義へPRを出す自己改善と、過去の実行をモデルやハーネスを変えて再生するベンチマークを説明する。
- [18:46] **ファクトリーのスタック構成** — 宣言的定義、データ収集、MCP、プラガブルな計算層、推論、改善層、オーケストレーター、アクセスポイントという層構造と、コスト削減の実績を語る。
- [26:58] **対象規模と批判への答え** — 5〜10人以上が目安で、小規模ならサブスクで十分。独自基盤を持つ大企業は不向きとし、サブスクとAPIのコスト差にも触れる。
- [33:05] **ファクトリーエンジニアリングと告知** — ソフトウェアを作る仕組み自体を設計する新しい職能について語り、採用情報と発信先を案内する。

## 解説記事

Latent Space の本エピソードでは、Warp の創業者 Zach Lloyd が、AIE で話題になった「ソフトウェアファクトリー」の考え方を、画面を見せながら解説した。多くの企業が社内でエージェント基盤を作ろうとしている中、何を揃えるべきかを具体的な層構造で示した回である。

#### ソフトウェアファクトリーとは何か

Zach はファクトリーを、チームやプロダクトのためにエージェントの役割を定義したクラウド上のシステムと位置づける。一定の自律性を持ち、計測可能で、チームが継続的にチューニングできるクローズドループであることが要件だという。

彼によれば、多くの企業は自動化を場当たり的につなぎ合わせたり、エージェントをたくさん使っていることを「ファクトリー」と呼んだりしている。これに対し Warp は、プロダクトの面（モバイルアプリ、サーバーなど）ごとに1つのファクトリーを持ち、扱うリポジトリ、スキル、MCP、ワークフローをYAMLでコード定義するべきだと主張する。ワークフローにはトリアージ、仕様化、実装といった、チームがすでにやっている工程を対応させる。

#### 既存ツールから投入し、全トレースを集める

利用者は Slack、Linear、Jira、GitHub、API、MCP といった普段のツールから作業項目を投入する。Warp 社内では作業の約60%が Slack から始まるという。

重要なのは、こうして動いたエージェントの会話や成果物が一箇所に集まる点だ。Zach によれば、多くの企業では各エンジニアが手元で Claude Code や Codex を使っており、この集約ができていない。集約されたデータから、DORA指標、PRごとに人が介入した回数などの自動化度、スループット、コストを見られる。コストは人別、自動化別、開発工程別にも切り分けられる。

#### 評価とベンチマーク

さらに「スコアラー」と呼ぶオンライン評価がある。過去の実行を LLM-as-a-judge（LLMを採点者にする手法）で後から採点するもので、判定モデル、プロンプト、サンプリング率を設定する。例として、不要なテストを書き残す失敗パターンの検出が挙がった。スコアラーはコードで定義でき、顧客固有の失敗モードにも対応できる。

ベンチマークでは、過去の実行を集めてモデルやハーネス（Claude Code、Codex、Pi など）の組み合わせで再生し、コストと正答率の図を得る。デモでは、あるモデルが正答率95%で平均6ドル、別のモデルが93%で2ドルという例が示された。この結果をモデルのルーティング戦略に反映できるという。

さらに自己改善ループとして、失敗パターンを見つけたエージェントがファクトリー定義に対するPRを出す仕組みも紹介された。たとえば、トリアージ工程でサブエージェントを起動できればよかった事例が54件あるといった提案だ。提案の効果を過去の実行で再生して検証する機能は、今後の目標だと述べている。

#### 推奨するスタック構成

Zach は構築者向けに層構造を示した。最下層は、Terraform のようにファクトリーを宣言的にコード化することで、バージョン管理、ブランチでの検証、ロールバック、エージェントによる改善提案が可能になる。その上に、会話と成果物を集めるデータ層、MCP の接続と組織ごとのアクセス制御、差し替え可能な計算層が載る。計算層は Warp では Namespace が主だが、Daytona、Modal、E2B なども使える設計にすべきだという。iOS のテストには Mac VM が必要になる。

推論は柔軟で、自社の推論プロバイダーを接続するか Warp 経由で購入でき、ACP 互換のハーネスも持ち込める。その上に改善層、ワークフローを進めるオーケストレーター、そして Slack などのアクセスポイントがある。

成果として、Warp 社内では当初PRあたり約80ドルだったコストが、高価なモデルの使用やサブエージェントの多用を見直して15〜20ドルになったという。PRスループットは1か月で40%増え、リバート率は上がっていないと述べている。

#### 誰に向くか

Zach は、数人の小規模チームには過剰で、サブスクの利用で十分だと明言する。目安は5〜10人以上で、10〜100人の成長期スタートアップは Slack と Linear や Jira といった定番構成が多く、比較的セルフサーブで導入できるという。大企業では導入作業が増える。また Uber や Ramp のように独自基盤を作り込む企業は、あまり適さないと述べた。

コスト面では、API従量課金はサブスクの5〜50倍高いという見方を示し、200ドルのプランで8,000ドル分のAPI相当を使えるとも語った。そのため、自社はトークン再販ではなく、コーディングエージェントの最適化と生産性のプラットフォームを提供する立場だと説明している。

#### まとめ

本エピソードの核心は、エージェント活用を「雰囲気」から「計測」へ移すという主張だ。ファクトリーをコードで定義し、トレースを集め、スコアラーとベンチマークで改善するという流れは、特定製品に関係なく社内基盤を設計する際の参考になる。数値は Warp 自身の報告なので割り引いて見る必要があるが、コストを人別・工程別に追跡し、モデルやハーネスを自社データで比較するという発想は実践しやすい。次回の AIE Code では、「ソフトウェアを作る仕組み自体を設計する」ファクトリーエンジニアリングという職能が主題になる見込みである。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: Latent Space: The AI Engineer Podcast「⚡️ The 2026 Software Factory Standard — Zach Lloyd, Warp.dev」