AI駆動開発の次の段階: ソフトウェアファクトリー

前書き

最近、Claude Codeの開発者であるFelix Riesebergさんの記事『AIモデルを扱う人類のための「志を高く持つ」チュートリアル』を読みました。その考え方に刺激を受けたので、少し引用して紹介します。

記事によると、Claudeは最近、新しい惑星の発見にも一役買ったそうです。
それなのに、私たちの多くはいまだに「日本で一番高い山は？」のような、単純な使い方にとどまっています。

記事は、その原因が使う側の私たちにあると指摘しています。
「自分の限界をLLMの限界だと思い込み、苦手なことには手を出さない」 からです

だからこそ、何かを始めるときは無理だと決めつけず、LLMと一緒に挑戦してみるのが良いと思います。

記事のメッセージをひと言でまとめると、「ソフトウェア開発に野心を持て」 です。

そこで私は、アプリを自分で作るのをやめて、
アプリを作る仕組みのほうを作ることにしました。
この記事では、いま取り組んでいるソフトウェアファクトリーについて紹介します。

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

簡単に言えば、アイデアをチケットにして渡すと、アプリの開発を進めてくれる仕組みのことです。

これは新しい概念ではありません
数年前からDevinのようなSaaSがあり、今ではCodex cloudやClaude Codeのクラウドセッション(旧 Web)、GitHub Copilot coding agentでも似たことができます。自作して社内に展開している会社も多いです。

ただ、それぞれが独自に実装しているため、用語が定まっていません。
そこで共通の言葉を作ろうとしているのがMatt Pocockさんです。
Mattさんは「Total TypeScript」で知られるTypeScriptの教育者で、最近は「AI Hero」でAIを使った開発を教えています。スター数30万超えのエージェントスキル集「mattpocock/skills」の作者でもあります。

2026年10月21日には、ソフトウェアファクトリーを設計するための用語集をスキルにまとめ、次のPRとして提出しました(以下「用語集」)。

用語集では、ソフトウェアファクトリーを次のように定義しています。

チケット・PR・スケジュールを入力として、マージ済みのコードを生産するエージェントの仕組み。ユーザーが選んだリモートのインフラ上で動く。

これだけ聞くと「それならClaude Codeを使えばいいのでは？」と思うかもしれません。
ファクトリーの中身にもClaude Codeは使えます。違いは動かし方にあります

用語集の定義では、1回の実行は人の介入を待たずに終わります。
人がチケットやPRを更新すると、それをきっかけに次の実行が始まります。実行するマシンは使い捨てで、前回の実行の記憶はチケットトラッカー、Gitホスト、オーケストレーターにしか残りません。
Codex cloudやClaude Codeのクラウドセッションのような製品も、用語集ではランナーの選択肢の1つという扱いで、部品を自分で選んで組み合わせるのが前提です。

人の主な仕事は、チケットを書くこととレビューです。
手元のPCで対話し続ける必要はなく、チケットは自分で選んだリモートのインフラ上で実装されていきます。

このPRは10月31日にマージされて software-factory スキルになりましたが、in-progress フォルダに置かれていて、まだ作りかけの扱いです。まず用語を整理し、そのうえで自分でソフトウェアファクトリーを作るときに何を気にすべきかを見ていきましょう

ソフトウェアファクトリーの構成パーツ

用語集では、構成パーツを「タスクと実行」と「サービス」の2つのグループに分けています。

「タスクと実行」は、ファクトリーの中で何がどう動くかを表すグループです。
「サービス」は、ファクトリーがつながる外部の部品のグループで、それぞれに製品を選んではめ込みます。

パーツの詳しい定義は次のとおりです。

タスクと実行

用語	意味
タスク	ファクトリーがこなす仕事の種類。一度定義して何度も実行する。レビュー、調査、実装、ラチェット(チェックを少しずつ厳しくしていく作業)など。対象はチケット、PR、コードベース全体のいずれか
トリガー	実行を始めるきっかけ。チケットトラッカーやGitホストでの変更、オーケストレーターの時計、別の実行
実行	1つのタスクを1台のランナーで1回動かしたもの。中身はブラックボックスとして扱い、人を待たずに終わる
ランナー	実行が動く使い捨てのマシン。実行が終わると何も残らない

サービス

用語	役割
チケットトラッカー	チケットの置き場所で、人とファクトリーの接点。人はチケットを書いて仕事を頼み、コメントでエージェントとやりとりする。人がチケットを変更すると実行が始まる
チケットソース	ファクトリーの外からチケットを作るもの。フィードバックボタン、監視、エラートラッカー、受信箱など
Gitホスト	ブランチ、PR、レビューの置き場所
オーケストレーター	トリガーを受け取ってランナー上で実行を始め、各実行が待機中か、動いているか、終わったかを記録する
オブザーバビリティ基盤	ランナーがログ、トレース、状態を送る先で、人が実行の中身を確認するために使う。ランナーやオーケストレーターの製品で足りることも多く、なくてもよい

パーツ同士のつながり

人がチケットトラッカーにチケットを書くと、それがトリガーになり、オーケストレーターがランナーの上で実装タスクを実行します。

実行はGitホストにドラフトPRを作成して終わり、そのPRがトリガーになって自動レビュータスクの実行が始まります。レビューで問題が見つかれば、今度は修正タスクの実行が始まります。

実行のつなぎ方は2通りあります。
オーケストレーターが次の実行を直接始める方法と、実行がチケットやPRを書き換え、その変更をトリガーにする方法です。

組み合わせの例

用語集には、Mattさんが挙げた3つの構成が並んでいます。

枠	すべてGitHub	Linearでチケット管理	自作トラッカー
チケットトラッカー	GitHub Issues	Linear	自作アプリ
チケットソース	フィードバックボタン	フィードバックボタン、監視	フィードバックボタン、監視
Gitホスト	GitHub	GitHub	GitHub
オーケストレーター	GitHub Actions	自前のサーバーとDB	自作アプリ
ランナー	Actionsのランナー	Actions、E2B、Daytona、VPSのいずれか	自作アプリ、またはサンドボックス
オブザーバビリティ基盤	なし(Actionsの実行ページで足りる)	LLMトレーシング基盤	自作アプリ

すべてGitHubの構成では、GitHub Actionsがオーケストレーター、ランナー、オブザーバビリティ基盤の3役を兼ねています。

サービスは買い、タスクは作る

Mattさんの方針は「サービスは買い、タスクは作る」です。
サービスは汎用品で、ファクトリーごとの設計はタスクのほうに表れるからです。

チケットトラッカーも既製品が勧められています。
堅牢で、使い慣れている人が多く、社外のユーザーも招待しやすいためです。

自作ファクトリーの紹介

用語集を元に、私が実際に作ったファクトリーを紹介します。
チャットで困りごとを相談すると、デザインの確認を経て、触れるモックアプリが届く仕組みです。

構成要素

パーツ	自作ファクトリーでの担当
チケットトラッカー	GitHub Issues。ラベル foundry が付いたものが自動化の対象
チケットソース	ポータルのチャット。BedrockのClaudeがヒアリングする。Amazon Transcribeで音声でも相談できる
Gitホスト	GitHub
オーケストレーター	GitHub Actions(agent-design、agent-build、ci、preview など)
ランナー	Actionsの使い捨てUbuntu上で動くClaude Code(claude-code-action、Bedrock東京リージョン)
オブザーバビリティ基盤	ポータルが進捗を表示するだけ

組み合わせの例の「すべてGitHub」の構成に、チャットのチケットソースを足した形です。

状態はGitHubにしか持たせていないのでDBもなく、ポータルの進捗表示も、そのつどIssue、PR、チェック、ワークフロー実行の状態から計算しています。

リポジトリは1つのモノレポです。apps/ にポータルと生成したアプリが並び、packages/ にアプリ間で使い回す共通部品を置いています。ワークフローは .github/workflows/、Claude Codeに渡すスキルは .claude/skills/ にあります。

インフラはAWSに構築していて、ポータルとアプリの配信はS3とCloudFront、ポータルのAPIはLambdaです。Actionsには長期のアクセスキーを置かず、GitHubのOIDCでロールを引き受けて、BedrockのClaudeもそのロールで呼びます。

タスクの流れ

依頼した場合、基本全自動になりますが、デザイン確認と公開確認の2つで、人の判断が入ります。

1. ポータルのチャットでClaudeがヒアリングします。「この内容で依頼する」を押すと、GitHub Appがラベル foundry 付きのIssueを作成します。
2. ラベルをきっかけに agent-design が動き、Claude Codeが仕様書と画面ごとのHTMLを作ってデザインPRを作成します。PRにはプレビューのURLが自動でコメントされます。
3. 人がプレビューを確認して「このデザインで進める」を押すと、デザインPRがマージされます(人の判断1)。直したい点があれば、PRにコメントしてから agent-design を再実行すると、やり直せます。
4. デザインPRのマージをきっかけに agent-build が動き、承認済みのデザインからNext.jsのモックを作って実装PRを作成します。
5. CIが通ると「公開する」が押せるようになります。押すと実装PRがマージされ(人の判断2)、Issueがクローズされてアプリが公開されます。プレビューと作業ブランチは自動で削除されます。

大事なのはブレーキ

ファクトリーを作って、動かすこと自体は、難しくありません。
難しいのは、成果物を信頼できる状態にすることで、そのためにブレーキが要ります。

用語集には、ファクトリーを設計するときの助言として「Start slow(ゆっくり始める)」という項目があります。そこでは、トリガーをアクセルに、自動チェック、自動レビュー、人のレビューの3つをブレーキにたとえ、最初はブレーキを効かせながら少しずつ動かすことを勧めています。MattさんもXの投稿で、ブレーキでエージェントを制約して出力の質を上げてはじめて、信頼できるようになると書いています。

今回のファクトリーには、3つのうち2つのブレーキを入れています。1つ目は自動チェックで、型チェック、lint、ビルドをCIで必須にし、通らなければ「公開する」を押せないようにしています。
2つ目は人のレビューで、タスクの流れにある2回の判断がこれにあたります。ただし、人が確認しているのはコードではなくプレビューです。

ファクトリーを育てる

ファクトリーを作れたら、次は改善と拡張です。工場に例えれば、開発者はその「工場長」です。

工場長の仕事は主に3つあります。

1. 工程（タスク）を足す
2. マニュアル（スキル）を直す
3. 部品（コンポーネント）を増やす

1. 工程（タスク）を足す：困りごとから始める

用語集の作者であるMattさんは、最初から完璧を目指さず、現場の困りごとが出るたびに工程を足していくやり方を勧めています。多くのファクトリーは1つのタスクから始まり、課題が出るたびに新しいタスクをつないで育ちます。困りごとの内容に応じたタスクの追加例を挙げます。

• 人のレビューで同じ指摘が繰り返されるなら、今回は入れていない3つ目のブレーキとして、PR作成時に動く「自動レビュータスク」を足します。
• ファクトリーの実行自体が失敗するなら、エラーログをチケット化して修正PRまで作る「Fixタスク」を足します。ファクトリー自身を書き換えるタスクなので、工場長のレビューを必須にします。
• コードベースの乱れが目立ってきたら、毎晩、直近の変更からリファクタリング候補を洗い出してチケット化する「Architectureタスク」を足します。

2. マニュアル（スキル）を直す：指摘を取り込む

日々の開発で受けたレビュー指摘は、マニュアルに書き足してファクトリーに取り込みます。今回ランナーとして採用しているClaude Codeは実行時にスキルを読み込むため、スキルを直せばそのままファクトリーの精度が上がります。

この改善もファクトリー自身に手伝わせます。PRコメントや手動で修正した箇所をファクトリーが集めてスキルの修正案をPRで作成し、工場長はそれをレビューしてマージします。

用語集のタスク例にある「振り返りタスク（Retro）」がこれにあたります。「PRが10件マージされるごとに1回」といった周期でログやチケットを分析し、ファクトリー自身の指示を直すPRを作ります。

3. 部品（コンポーネント）を増やす：作れる範囲を広げる

生成したアプリはすべて同じモノレポの apps/ に入るため、packages/ にある共通部品はすべてのアプリから利用できます。

共通部品が増えれば、ファクトリーが作れるアプリの幅も広がります。共通部品を直せば、それを利用するすべてのアプリにその修正が反映されます。

まとめ

Felixさんの記事は、次の言葉で締めくくられています。

自己効力感は新しい問題ではありませんが、いまはより大きな意味を持っています。能力が数週間ごとに跳ね上がる世界では、これまで考えもしなかったこと、可能だと信じていなかったことを実現するための技術が必要です。

ソフトウェアファクトリーも、そうした技術の1つだと思います。
アプリを1つずつ作る手を少し止めて、まずは1つのタスクからなるファクトリーを動かしてみてください。